Khi ứng dụng cần AI quyết định trong 100 mili giây, có nhất thiết phải dùng chatbot?

Một khách hàng vừa gửi tin nhắn đến bộ phận hỗ trợ của một ứng dụng tài chính: “Mình chuyển tiền rồi nhưng tài khoản vẫn chưa nhận được.”

Trước khi nhân viên đọc được tin nhắn, hệ thống cần xác định yêu cầu thuộc nhóm nào để chuyển đến đúng bộ phận. Nếu là vấn đề nạp tiền, yêu cầu được đưa vào hàng đợi thanh toán. Nếu là lỗi đăng nhập, hệ thống chuyển sang nhóm hỗ trợ tài khoản. Những trường hợp không rõ ràng sẽ được chuyển cho nhân viên kiểm tra.

Nghe có vẻ đơn giản, nhưng giả sử ứng dụng phải xử lý hàng nghìn yêu cầu mỗi phút và muốn hoàn thành bước phân loại trong khoảng 100 mili giây. Chúng ta có nên gửi từng tin nhắn đến một chatbot, chờ mô hình phân tích rồi trả về một đoạn văn giải thích?

Trong nhiều trường hợp, câu trả lời là không.

Không phải mọi bài toán cần trí tuệ nhân tạo đều cần một hệ thống có khả năng trò chuyện. Khi ứng dụng chỉ cần chọn một trong vài phương án đã biết, cách thiết kế phù hợp có thể khác hoàn toàn với việc xây dựng một chatbot. Sự khác biệt này ảnh hưởng trực tiếp đến tốc độ phản hồi, chi phí vận hành và độ tin cậy của sản phẩm.

1. Khi một quyết định nhỏ trở thành vấn đề lớn của hệ thốngLiên kết tới mục này

Hãy tiếp tục với ví dụ phân loại yêu cầu hỗ trợ khách hàng. Một ứng dụng có thể nhận những tin nhắn như “Không đăng nhập được”, “Tiền đã trừ nhưng chưa cộng vào tài khoản” hoặc “Lệnh của mình vẫn đang chờ xử lý”.

Mục tiêu của backend không phải tạo ra một câu trả lời dài và tự nhiên. Nó chỉ cần xác định một trong bốn kết quả: ACCOUNT, PAYMENT, ORDER hoặc OTHER.

Nếu dùng một Large Language Model (LLM) thông qua API tạo sinh thông thường, chúng ta có thể yêu cầu mô hình đọc nội dung và trả về một nhãn phân loại. Cách này hoàn toàn khả thi, đặc biệt khi hệ thống đã sử dụng LLM cho nhiều chức năng khác.

Tuy nhiên, mô hình vẫn phải thực hiện một quy trình suy luận và tạo phản hồi, dù kết quả cuối cùng chỉ là một từ. Ngoài thời gian xử lý của mô hình, ứng dụng còn chịu độ trễ mạng, thời gian thiết lập và truyền yêu cầu, cũng như chi phí kiểm tra kết quả trả về.

Ở quy mô nhỏ, sự khác biệt có thể không đáng kể. Nhưng khi thao tác này nằm trên đường xử lý chính của hàng nghìn yêu cầu, độ trễ và chi phí của từng lần gọi sẽ cộng dồn.

Giả sử một dịch vụ tiếp nhận 1.000 yêu cầu mỗi giây. Nếu mỗi yêu cầu đều phải chờ một dịch vụ phân loại bên ngoài, tốc độ xử lý và số lượng yêu cầu đang chờ sẽ phụ thuộc đáng kể vào thời gian phản hồi của dịch vụ đó. Khi thời gian chờ tăng, backend có thể cần nhiều kết nối đồng thời hơn và phải xử lý thêm các tình huống timeout, retry hoặc quá tải.

Đây là lúc một câu hỏi tưởng chừng nhỏ trở thành bài toán kiến trúc: Chúng ta thực sự cần mô hình tạo ra câu trả lời, hay chỉ cần nó đưa ra một quyết định có giới hạn?

2. Decisions API: Khi AI không cần viết câu trả lời dàiLiên kết tới mục này

Ngày 22/10/2026, OpenAI công bố Decisions API chính thức khả dụng rộng rãi (Generally Available). API này được thiết kế cho những tác vụ cần đánh giá thông tin và đưa ra kết quả có cấu trúc, chẳng hạn phân loại nội dung, lựa chọn hành động hoặc chấm điểm mức độ ưu tiên.

Khác với một chatbot được thiết kế để tạo ra phản hồi ngôn ngữ tự nhiên, Decisions API yêu cầu developer xác định trước câu hỏi và dạng kết quả mong muốn.

Hiện API hỗ trợ ba loại quyết định chính:

• predicate: Ước lượng xác suất một điều kiện là đúng, chẳng hạn hình ảnh sản phẩm có dấu hiệu hư hỏng hay không.
• choice: Chọn một phương án trong tập giá trị đã định nghĩa, chẳng hạn yêu cầu thuộc nhóm ACCOUNT, PAYMENT, ORDER hay OTHER.
• score: Đánh giá một đầu vào theo các mức độ có thứ tự, chẳng hạn mức độ ưu tiên xử lý của một ticket.

Trong ví dụ hỗ trợ khách hàng, choice là lựa chọn tự nhiên nhất vì hệ thống cần xác định một nhóm nghiệp vụ cụ thể.

Theo công bố chính thức của OpenAI, Decisions API sử dụng GPT-6 Luna và có thể xử lý một số tác vụ quyết định nhanh hơn tới 10 lần so với cùng mô hình thông qua Responses API. Đây là kết quả so sánh do nhà cung cấp công bố, không có nghĩa mọi ứng dụng sẽ nhanh hơn 10 lần hoặc luôn đáp ứng mục tiêu 100 mili giây.

Một điểm quan trọng khác là Decisions API không tự động thực hiện hành động nghiệp vụ. Nó cung cấp kết quả đánh giá để ứng dụng quyết định bước tiếp theo. Nếu mô hình phân loại một yêu cầu là PAYMENT, backend vẫn chịu trách nhiệm kiểm tra dữ liệu, phân quyền và chuyển yêu cầu đến đúng hệ thống.

Điều này giúp phân tách hai trách nhiệm: AI hỗ trợ diễn giải thông tin khó xử lý bằng quy tắc cố định, còn application code kiểm soát các hành động được phép thực hiện.

Tuy nhiên, Decisions API không phải lựa chọn mặc định cho mọi tác vụ. Nếu cần trích xuất một cấu trúc JSON phức tạp, tạo nội dung hoặc thực hiện một chuỗi công việc nhiều bước, Responses API cùng Structured Outputs hoặc tool calling có thể phù hợp hơn.

3. Trước khi dùng AI, hãy hỏi liệu một rule engine đã đủ tốt chưaLiên kết tới mục này

Một trong những sai lầm dễ gặp khi xây dựng sản phẩm AI là bắt đầu bằng câu hỏi “Nên dùng mô hình nào?” trước khi xác định bài toán có thật sự cần mô hình học máy hay không.

Giả sử hệ thống cần phân loại yêu cầu dựa trên một trường request_type mà frontend đã gửi lên. Nếu giá trị này được kiểm tra hợp lệ và phản ánh chính xác nghiệp vụ, backend chỉ cần một câu lệnh switch hoặc một bảng ánh xạ. Gọi AI trong trường hợp ấy thường không tạo thêm giá trị.

Nhưng nếu khách hàng nhập một đoạn mô tả tự do như “Mình đặt lệnh mua bạc rồi mà không thấy cập nhật”, việc phân loại trở nên khó hơn. Người dùng có thể diễn đạt cùng một vấn đề bằng nhiều cách, viết tắt, sai chính tả hoặc kết hợp nhiều ý trong một câu. Một tập quy tắc từ khóa đơn giản có thể không đủ để xử lý tất cả trường hợp.

Khi đó, chúng ta có ít nhất ba hướng tiếp cận:

Không có phương án nào luôn tốt nhất.

Rule engine có thể rất nhanh và dễ kiểm chứng, nhưng chi phí duy trì sẽ tăng nếu nghiệp vụ chứa hàng trăm ngoại lệ khó mô tả bằng điều kiện cố định. Ngược lại, một mô hình AI có thể xử lý ngôn ngữ linh hoạt hơn nhưng không bảo đảm phân loại đúng trong mọi trường hợp.

Một thiết kế thực tế có thể kết hợp cả hai. Những yêu cầu có cấu trúc và chắc chắn được xử lý bằng quy tắc. Những mô tả tự do được chuyển đến bộ phân loại AI. Các trường hợp có độ tin cậy thấp hoặc liên quan đến giao dịch nhạy cảm sẽ được chuyển cho nhân viên kiểm tra.

Cách tiếp cận này không cố đưa AI vào mọi bước. Nó sử dụng AI tại những nơi khả năng diễn giải ngôn ngữ thực sự giúp giải quyết vấn đề mà logic truyền thống khó xử lý.

4. Thiết kế một hệ thống phân loại yêu cầu hỗ trợ có thể chạy trên productionLiên kết tới mục này

Hãy xây dựng một ví dụ giả định bằng Go: một dịch vụ nhận tin nhắn từ khách hàng và xác định bộ phận hỗ trợ phù hợp.

Ở mức đơn giản nhất, hệ thống có thể nhận yêu cầu như sau:

{
  "message": "Tôi nạp tiền nhưng tài khoản chưa cập nhật"
}

Kết quả mà ứng dụng mong muốn là một nhãn nghiệp vụ:

{
  "category": "PAYMENT"
}

Nếu sử dụng Decisions API, backend có thể gửi nội dung tin nhắn cùng câu hỏi dạng choice, trong đó các lựa chọn được định nghĩa trước. Mô hình trả về phương án được chọn và thông tin xác suất, độ tin cậy để ứng dụng đánh giá.

Tuy nhiên, phần khó của một hệ thống production không nằm ở việc gọi API thành công. Nó nằm ở cách xử lý khi kết quả không rõ ràng hoặc dịch vụ AI không phản hồi.

Giả sử khách hàng viết: “Mình không vào được tài khoản để kiểm tra khoản tiền vừa chuyển.” Tin nhắn này có thể liên quan đồng thời đến ACCOUNT và PAYMENT. Nếu backend bắt buộc chọn một nhóm mà không cho phép xử lý trường hợp mơ hồ, yêu cầu có thể bị chuyển sai bộ phận.

Một phương án an toàn hơn là cho phép kết quả OTHER hoặc chuyển sang hàng đợi cần phân loại thủ công khi độ tin cậy không đạt ngưỡng. Ngưỡng này không nên được chọn tùy ý; developer cần đánh giá trên những tin nhắn đã được gắn nhãn để xác định mức đánh đổi phù hợp giữa phân loại sai và chuyển quá nhiều yêu cầu cho con người.

Với hệ thống yêu cầu độ trễ thấp, chúng ta còn phải thiết kế rõ latency budget — khoảng thời gian tối đa dành cho từng thành phần.

Ví dụ, nếu mục tiêu là p95 của toàn bộ API không vượt quá 100 mili giây, team có thể lập một ngân sách thử nghiệm:

Đây chỉ là mục tiêu thiết kế, không phải số liệu đo được. Đặc biệt, 70 mili giây cho lời gọi AI bên ngoài có thể không khả thi trong nhiều điều kiện mạng hoặc vùng triển khai. Nếu benchmark thực tế không đáp ứng, hệ thống phải thay đổi kiến trúc hoặc điều chỉnh yêu cầu thay vì mặc định rằng mô hình nhanh hơn sẽ giải quyết mọi vấn đề.

Một lựa chọn là không đặt bước phân loại AI trên đường xử lý đồng bộ. API tiếp nhận yêu cầu, lưu ticket và phản hồi ngay rằng hệ thống đã ghi nhận. Sau đó, một worker thực hiện phân loại bất đồng bộ và chuyển ticket đến bộ phận phù hợp.

Với bài toán hỗ trợ khách hàng, cách làm này thường đáng cân nhắc vì người dùng không nhất thiết cần biết bộ phận tiếp nhận ngay trong cùng một HTTP request. Nhưng với một ứng dụng điều khiển bằng giọng nói, nơi hệ thống phải phản ứng gần như tức thì, việc chờ quyết định có thể ảnh hưởng trực tiếp đến trải nghiệm.

Độ trễ tốt nhất không phải lúc nào cũng đến từ một mô hình nhanh hơn. Đôi khi, nó đến từ việc không bắt người dùng chờ một công việc chưa cần hoàn thành ngay.

5. Đo lường thế nào để biết AI thực sự tốt hơn?Liên kết tới mục này

Một API mới có thể công bố tốc độ xử lý ấn tượng, nhưng điều đó chưa đủ để kết luận nó phù hợp với hệ thống của mình.

Trước khi triển khai, developer nên chuẩn bị một tập dữ liệu kiểm thử phản ánh cách khách hàng thực sự sử dụng sản phẩm. Chẳng hạn, lấy 1.000 tin nhắn đã được ẩn thông tin cá nhân và gắn nhãn bởi người có hiểu biết nghiệp vụ. Tập dữ liệu nên bao gồm tin nhắn ngắn, câu viết sai chính tả, yêu cầu mơ hồ và những trường hợp có nhiều ý cùng lúc.

Sau đó, chạy cùng một tập dữ liệu qua các phương án: rule engine, Decisions API và một LLM tạo sinh. Kết quả cần được so sánh dựa trên nhiều khía cạnh:

Độ chính xác: Mỗi phương án phân loại đúng bao nhiêu trường hợp? Nhóm nào dễ bị nhầm lẫn nhất? Nếu yêu cầu liên quan đến tiền bị chuyển sai, tác động có lớn hơn một ticket thông thường không?

Độ trễ: Thời gian phản hồi ở p50, p95 và p99 là bao nhiêu? Có sự khác biệt khi chạy ở những vùng hạ tầng khác nhau hoặc khi tăng số lượng request đồng thời không?

Chi phí: Tổng chi phí cho một triệu yêu cầu là bao nhiêu, bao gồm phí API, hạ tầng, lưu trữ, vận hành và công sức xử lý các trường hợp phân loại sai?

Độ tin cậy: Khi dịch vụ AI timeout, trả lỗi hoặc bị giới hạn lưu lượng, hệ thống có tiếp tục hoạt động được không? Có cơ chế fallback, retry và giới hạn số lần thử để tránh làm tình trạng quá tải nghiêm trọng hơn không?

Cần lưu ý rằng confidence do mô hình trả về không nhất thiết tương ứng trực tiếp với xác suất dự đoán đúng trong dữ liệu thực tế. Ngưỡng quyết định phải được kiểm tra và hiệu chỉnh bằng tập dữ liệu có nhãn, đặc biệt khi các loại lỗi có mức độ ảnh hưởng khác nhau.

Một mô hình nhanh hơn nhưng thường xuyên chuyển sai yêu cầu thanh toán có thể tạo ra nhiều chi phí vận hành hơn một phương án chậm hơn đôi chút nhưng đáng tin cậy. Tương tự, một mô hình có độ chính xác cao nhưng thường xuyên vượt quá latency budget cũng có thể không phù hợp với luồng tương tác thời gian thực.

Vì vậy, tiêu chí lựa chọn nên là chất lượng quyết định trong giới hạn thời gian, chi phí và rủi ro mà sản phẩm chấp nhận được, thay vì chỉ nhìn vào benchmark tốc độ của nhà cung cấp.

Kết luận: Đừng biến mọi quyết định thành một cuộc hội thoại với AILiên kết tới mục này

Hãy quay lại tin nhắn của khách hàng ở đầu bài: “Mình chuyển tiền rồi nhưng tài khoản vẫn chưa nhận được.”

Để chuyển yêu cầu ấy đến đúng bộ phận, hệ thống không nhất thiết phải tạo ra một đoạn giải thích dài. Nó cần hiểu đủ ngữ cảnh để đưa ra một lựa chọn phù hợp, đồng thời biết khi nào thông tin chưa đủ để quyết định chắc chắn.

Decisions API mở ra một lựa chọn đáng chú ý cho những ứng dụng cần AI thực hiện các tác vụ đánh giá có giới hạn. Tuy nhiên, công nghệ mới không làm mất đi giá trị của rule engine, mô hình phân loại truyền thống hay những nguyên tắc thiết kế backend đã được kiểm chứng.

Một hệ thống tốt có thể sử dụng AI cho phần diễn giải ngôn ngữ, dùng code thông thường để thực thi quy tắc nghiệp vụ và chuyển những trường hợp không chắc chắn cho con người. Sự kết hợp ấy thường thực tế hơn việc cố giải quyết toàn bộ vấn đề bằng một mô hình duy nhất.

Khi xây dựng sản phẩm AI, câu hỏi quan trọng không phải là mô hình có thể làm được bao nhiêu việc, mà là ứng dụng thực sự cần nó làm điều gì.

Đôi khi, cách sử dụng AI thông minh nhất chính là biết những chỗ không cần đến AI.

---

Nguồn tham khảoLiên kết tới mục này

1. OpenAI — Build more responsive apps with the Decisions API (22/10/2026): https://openai.com/index/decisions-api/
2. OpenAI API Documentation — Decisions: https://developers.openai.com/api/docs/guides/decisions
3. OpenAI API Documentation — Latency optimization: https://developers.openai.com/api/docs/guides/latency-optimization
4. OpenAI API Documentation — Model selection: https://developers.openai.com/api/docs/guides/model-selection
5. OpenAI API Documentation — Structured model outputs: https://developers.openai.com/api/docs/guides/structured-outputs

Các tình huống về ứng dụng tài chính, dữ liệu ticket, ví dụ latency budget và benchmark trong bài đều là minh họa thiết kế, không phải kết quả thử nghiệm thực tế. Hiệu năng và chi phí cần được đo trên hệ thống cụ thể trước khi đưa ra quyết định triển khai.

Tân Mít — Technology, AI & Software Engineering

https://thanhtanmit.com