Cách an toàn và đơn giản nhất để đưa mô hình ngôn ngữ vào ứng dụng là: giao diện gửi yêu cầu về máy chủ của chính bạn, máy chủ ghép câu lệnh, gắn khoá bí mật rồi mới gọi API của nhà cung cấp, nhận kết quả, kiểm tra và trả về giao diện. Trình duyệt hay ứng dụng điện thoại không bao giờ cầm khoá API và không bao giờ nói chuyện thẳng với nhà cung cấp.
Bài này dành cho lập trình viên đã quen làm ứng dụng web hoặc API thông thường, nay được giao thêm một nút “tóm tắt”, “gợi ý trả lời” hay “hỏi trợ lý” vào sản phẩm. Bạn sẽ có sơ đồ ba tầng, cấu trúc một lần gọi, đoạn mã mẫu bằng Python ở dạng HTTP chung, danh sách giới hạn cần đặt cho từng người dùng và trình tự làm bản đầu tiên trong vài ngày.
Vì sao không gọi API AI thẳng từ trình duyệt hay ứng dụng điện thoại
Cám dỗ đầu tiên của nhiều người khi thử nghiệm là viết lời gọi API ngay trong mã JavaScript chạy ở trình duyệt, vì nhanh và khỏi dựng máy chủ. Vấn đề là mọi thứ chạy ở phía người dùng đều đọc được: chỉ cần mở công cụ dành cho nhà phát triển, xem thẻ mạng, khoá API hiện ra nguyên văn trong phần đầu yêu cầu. Ứng dụng điện thoại cũng vậy, khoá nhúng trong gói cài đặt có thể bị bóc ra bằng công cụ dịch ngược phổ biến. Một khi khoá lọt ra ngoài, ai cầm nó cũng gọi được mô hình và hoá đơn tính vào tài khoản của bạn.
Lý do thứ hai ít được nghĩ tới: khi giao diện gọi thẳng, bạn mất chỗ đứng ở giữa. Không có chỗ để kiểm người dùng đã đăng nhập chưa, đã dùng quá hạn mức hôm nay chưa, đầu vào có dài bất thường không, câu trả lời có cần lọc trước khi hiển thị không. Bạn cũng không ghi được nhật ký để sau này tra cứu khi khách phàn nàn rằng trợ lý trả lời sai.
Lý do thứ ba là khả năng thay đổi. Câu lệnh hệ thống, tên mô hình, nhiệt độ, cách ghép dữ liệu đều là thứ bạn sẽ chỉnh nhiều lần trong tháng đầu. Nếu chúng nằm ở máy chủ, bạn sửa một chỗ là mọi người dùng có ngay. Nếu chúng nằm trong ứng dụng điện thoại, mỗi lần sửa là một lần phát hành bản mới và chờ người dùng cập nhật, trong khi bản cũ vẫn chạy câu lệnh cũ.
Kiến trúc tối thiểu: ba tầng, mỗi tầng một việc
Sơ đồ dưới là khung đủ dùng cho phần lớn tính năng AI đầu tiên của một sản phẩm nhỏ. Bạn chưa cần hàng đợi, chưa cần cơ sở dữ liệu véc-tơ, chưa cần dịch vụ riêng cho AI.
| Tầng | Làm gì | Không làm gì |
|---|---|---|
| Giao diện (web hoặc ứng dụng) | Thu dữ liệu người dùng nhập, gửi về điểm cuối của máy chủ bạn, hiển thị kết quả, báo đang xử lý | Không cầm khoá API, không tự ghép câu lệnh hệ thống, không gọi nhà cung cấp |
| Máy chủ của bạn | Xác thực người dùng, kiểm hạn mức, cắt độ dài đầu vào, ghép câu lệnh, gọi API với khoá trong biến môi trường, kiểm định dạng kết quả, ghi nhật ký | Không tin đầu ra của mô hình là đúng, không chạy thẳng mã hay câu SQL mô hình sinh ra |
| Nhà cung cấp mô hình | Nhận câu lệnh, sinh câu trả lời, trả về kèm số token đã dùng | Không biết người dùng của bạn là ai, không biết quy tắc nghiệp vụ trừ khi bạn ghi vào câu lệnh |
Điểm mấu chốt của sơ đồ là máy chủ đứng giữa giữ mọi quyết định. Về sau khi cần thêm tìm kiếm trong tài liệu riêng, gọi công cụ hay lưu đệm, bạn đều gắn vào tầng giữa này mà giao diện không phải đổi gì. Đổi nhà cung cấp mô hình cũng chỉ đụng tới một hàm ở máy chủ, nếu ngay từ đầu bạn gói lời gọi API vào một hàm riêng thay vì rải khắp các điểm cuối.
Một lần gọi mô hình gồm những gì
Tên mô hình. Mỗi nhà cung cấp có nhiều mô hình khác nhau về tốc độ, chất lượng và mức phí. Đặt tên mô hình trong cấu hình, không viết cứng rải rác trong mã, để đổi được nhanh khi nhà cung cấp ngừng một phiên bản.
Câu lệnh hệ thống. Đoạn chỉ dẫn cố định do bạn viết: vai trò của trợ lý, phạm vi được trả lời, giọng văn, định dạng đầu ra. Có hãng đặt nó là một tin nhắn mang vai trò system, có hãng tách thành trường riêng; kiểm tài liệu chính thức của hãng bạn dùng.
Danh sách tin nhắn. Lượt nói của người dùng và của trợ lý theo thứ tự. Mô hình không tự nhớ cuộc trò chuyện trước; muốn nó biết bối cảnh, máy chủ phải gửi lại các lượt cũ cần thiết trong mỗi lần gọi.
Giới hạn độ dài đầu ra. Số token tối đa mô hình được sinh. Đặt vừa đủ cho việc, vừa để kiểm soát chi phí, vừa để tránh một câu trả lời dài vô tận làm treo giao diện.
Tham số lấy mẫu. Nhiệt độ thấp cho việc cần ổn định như phân loại, trích xuất; cao hơn một chút cho việc cần đa dạng như gợi ý tiêu đề. Bắt đầu với giá trị mặc định của hãng rồi mới chỉnh.
Kết quả trả về. Ngoài nội dung, phản hồi thường có lý do dừng (hết độ dài hay đã xong) và số token vào ra. Hãy lưu hai thông tin này vào nhật ký; chúng là dữ liệu bạn cần khi tối ưu chi phí và gỡ lỗi câu trả lời bị cụt.
Đoạn mã mẫu ở máy chủ: gói lời gọi vào một hàm
Dưới đây là khung bằng Python với thư viện requests, viết theo dạng HTTP chung để bạn thấy cấu trúc, không bám vào bộ thư viện riêng của hãng nào. Địa chỉ điểm cuối, tên trường và cách xác thực thật sự phải lấy từ tài liệu chính thức của nhà cung cấp bạn chọn, vì mỗi hãng một khác và có thể đổi theo phiên bản.
Phần đầu đọc cấu hình từ biến môi trường: API_URL = os.environ["AI_API_URL"], API_KEY = os.environ["AI_API_KEY"]. Hàm chính nhận câu lệnh hệ thống và tin nhắn người dùng: def goi_mo_hinh(he_thong, tin_nhan, toi_da=600):. Bên trong, bạn dựng một từ điển payload gồm tên mô hình, câu lệnh hệ thống, danh sách tin nhắn và giới hạn đầu ra, rồi gọi r = requests.post(API_URL, json=payload, headers={"Authorization": "Bearer " + API_KEY}, timeout=30), tiếp theo là r.raise_for_status() và return r.json(). Tiêu đề xác thực trên chỉ là dạng phổ biến; có hãng dùng tên tiêu đề khác.
Ba chi tiết trong khung này đáng giữ dù bạn đổi ngôn ngữ. Thứ nhất là tham số timeout: thiếu nó, một lần nhà cung cấp chậm có thể giữ tiến trình máy chủ của bạn rất lâu. Thứ hai là raise_for_status để lỗi HTTP không bị nuốt và trả về giao diện một chuỗi rỗng khó hiểu. Thứ ba là mọi điểm cuối trong ứng dụng đều gọi qua hàm goi_mo_hinh, nên khi thêm thử lại, lưu đệm hay đổi hãng, bạn chỉ sửa một nơi. Với PHP hay Node.js, cấu trúc y hệt: một hàm, đọc khoá từ môi trường, có thời hạn chờ, ném lỗi rõ ràng.
Giới hạn cần đặt cho từng người dùng ngay từ bản đầu
Tính năng AI tốn tiền theo mỗi lần dùng, khác với phần lớn tính năng thường gần như miễn phí khi đã chạy. Thiếu giới hạn, chỉ một tài khoản tò mò hay một đoạn mã tự động là đủ đốt ngân sách tháng trong một buổi tối. Những hàng rào sau nên có trước khi mở cho người dùng thật:
- Bắt buộc đăng nhập với tính năng AI, hoặc nếu cho khách vãng lai thử thì giới hạn theo địa chỉ IP và có thêm bước chống máy tự động.
- Hạn mức theo người dùng theo ngày, đếm bằng số lần gọi hoặc tốt hơn là tổng token; hết thì báo rõ bằng chữ, không im lặng thất bại.
- Cắt độ dài đầu vào ở máy chủ: ô nhập cho phép bao nhiêu ký tự thì máy chủ cũng chặn đúng chừng đó, đừng chỉ tin thuộc tính maxlength ở giao diện.
- Giới hạn độ dài đầu ra trong mỗi lần gọi, như đã nói ở trên.
- Trần chi tiêu ở tài khoản nhà cung cấp: phần lớn bảng điều khiển của các hãng cho đặt mức cảnh báo hoặc mức chặn theo tháng; kiểm tính năng hiện hành của hãng bạn dùng.
- Nhật ký mỗi lần gọi: mã người dùng, thời điểm, số token vào ra, thời gian chờ, lý do dừng, có lỗi hay không. Nội dung câu hỏi chỉ lưu nếu chính sách quyền riêng tư của bạn cho phép và người dùng đã được báo.
Nếu người dùng có thể dán dữ liệu khách hàng hay hồ sơ nội bộ vào ô nhập, hãy ghi rõ trên giao diện rằng nội dung được gửi tới nhà cung cấp mô hình, và nhắc họ che thông tin cá nhân, số tài khoản, bí mật kinh doanh trước khi gửi. Về phía bạn, đọc điều khoản dữ liệu của gói API đang dùng để biết dữ liệu có được lưu hay dùng để huấn luyện không.
Trình tự làm tính năng AI đầu tiên trong vài ngày
Đây là thứ tự đã giúp nhiều nhóm nhỏ ra được bản chạy thật mà không phải đập đi làm lại. Ví dụ giả định: một phần mềm quản lý cửa hàng ở Cần Thơ muốn thêm nút “viết mô tả sản phẩm” từ tên và vài đặc điểm.
- Viết rõ việc AI làm bằng một câu, kèm năm ví dụ đầu vào và đầu ra mong muốn do người trong nghề viết tay. Đây sẽ là bộ kiểm đầu tiên.
- Thử câu lệnh bằng tay trong giao diện chat hoặc bảng thử nghiệm của nhà cung cấp, với đúng năm ví dụ đó, cho tới khi kết quả đạt.
- Viết hàm goi_mo_hinh ở máy chủ, đọc khoá từ biến môi trường, có thời hạn chờ, có ghi nhật ký.
- Viết điểm cuối nhận tên và đặc điểm sản phẩm, kiểm đăng nhập và hạn mức, cắt độ dài, gọi hàm, trả kết quả.
- Làm giao diện: nút bấm, trạng thái đang xử lý, chỗ hiện kết quả cho người dùng sửa trước khi lưu, nút thử lại.
- Cho năm đến mười người dùng thật thử trong một tuần, đọc nhật ký, đếm số lần họ phải sửa nhiều.
- Chỉnh câu lệnh, thêm ví dụ vào bộ kiểm cho những ca hỏng, rồi mới mở rộng cho mọi người.
Để ý bước năm: kết quả AI nên hiện ra để người dùng sửa, không tự lưu thẳng vào dữ liệu. Với bản đầu, đặt con người ở vòng kiểm cuối là cách rẻ nhất để tránh những câu trả lời sai lọt vào sản phẩm.
Khi nào chưa nên thêm AI vào sản phẩm
Không phải tính năng nào gắn AI cũng tốt hơn. Nếu việc có quy tắc rõ ràng và cần đúng tuyệt đối, như tính tiền, kiểm mã số thuế hợp lệ, phân quyền, thì mã thông thường nhanh hơn, rẻ hơn và không bao giờ “sáng tạo”. Gọi mô hình để làm việc mà một câu lệnh điều kiện làm được là trả tiền cho sự bất định.
Nên cân nhắc kỹ khi sai một lần gây hại lớn: trả lời khách về chính sách hoàn tiền, nêu thông tin y tế, tính toán tài chính. Những chỗ này nếu vẫn dùng AI thì phải có người duyệt, hoặc giới hạn AI ở việc soạn nháp. Cũng chưa nên thêm khi bạn chưa có cách đo xem tính năng có ích không; không có số liệu, nhóm sẽ tranh cãi bằng cảm giác.
Ngược lại, AI hợp với những việc ngôn ngữ mềm mà người dùng vẫn đang làm tay: viết nháp, tóm tắt, phân loại phản hồi, trích thông tin từ văn bản tự do, gợi ý trả lời. Bắt đầu từ một việc nhỏ như vậy, đo được, sửa được, rồi mới mở rộng.
Câu hỏi thường gặp
Có thể dùng hàm serverless thay cho máy chủ riêng không?
Được. Hàm serverless của các nền tảng đám mây vẫn là tầng máy chủ của bạn: nó giữ khoá trong biến môi trường và đứng giữa giao diện với nhà cung cấp. Lưu ý thời hạn chạy tối đa của hàm, vì câu trả lời dài có thể vượt mặc định, và nhớ vẫn phải có xác thực cùng hạn mức người dùng.
Ứng dụng điện thoại có cách nào cầm khoá an toàn không?
Không có cách nào thật sự an toàn để nhúng khoá API dùng chung trong ứng dụng phát cho công chúng. Làm rối mã chỉ làm chậm kẻ muốn bóc khoá. Cách đúng là ứng dụng gọi máy chủ của bạn bằng phiên đăng nhập của người dùng, máy chủ mới gọi nhà cung cấp.
Có nên dùng bộ thư viện chính thức của hãng thay vì gọi HTTP trực tiếp không?
Nên, khi bạn đã chọn hãng. Bộ thư viện chính thức thường lo sẵn xác thực, thử lại và kiểu dữ liệu. Gọi HTTP trực tiếp hữu ích khi muốn hiểu cấu trúc hoặc dùng ngôn ngữ chưa có thư viện. Dù cách nào, vẫn gói vào một hàm riêng của bạn.
Có cần lưu lịch sử trò chuyện của người dùng không?
Chỉ khi tính năng cần nhớ bối cảnh, như trợ lý hỏi đáp nhiều lượt. Nếu lưu, hãy báo cho người dùng, đặt thời hạn xoá, cho họ tự xoá, và không lưu lâu hơn mức cần. Tính năng một lượt như viết mô tả sản phẩm thì chỉ cần lưu số liệu sử dụng.
Mỗi lần gọi mất bao lâu và giao diện nên xử lý thế nào?
Từ dưới một giây tới vài chục giây, tuỳ mô hình và độ dài câu trả lời. Giao diện cần trạng thái đang xử lý rõ ràng, nút huỷ, và thông báo bằng chữ khi quá thời hạn. Với câu trả lời dài, cân nhắc trả về dần từng phần để người dùng thấy chữ chạy ngay.
Đổi sang nhà cung cấp khác có khó không?
Không khó nếu từ đầu bạn gói lời gọi vào một hàm và lưu câu lệnh tách khỏi mã. Phần tốn công nhất thường là chạy lại bộ kiểm để xem câu lệnh cũ có còn hợp mô hình mới không, vì mỗi mô hình phản ứng với cùng câu lệnh hơi khác nhau.