Vì Sao Phần Lớn Các Bản POC AI Không Bao Giờ Lên Được Production

Cứ mỗi quý chúng tôi lại nhận được một phiên bản của cùng một yêu cầu: khách hàng xây dựng một bản proof of concept (POC) AI trong vài tuần, nó chạy tốt trong demo, và giờ ban lãnh đạo muốn nó "lên production vào quý tới". Phần lớn những cuộc trò chuyện đó kết thúc với cùng một phát hiện khó chịu — POC trả lời câu hỏi "liệu cái này có chạy được không", còn yêu cầu production lại đang trả lời một câu hỏi hoàn toàn khác: "liệu cái này có hoạt động ổn định, cho mọi người dùng, dưới tải thực tế, mà không cần kỹ sư túc trực canh chừng hay không." Đó là hai dự án khác nhau, không phải hai giai đoạn của cùng một dự án.

Một POC tối ưu cho sai biến số

Một proof of concept được xây dựng để chứng minh rằng một model hay pipeline có thể tạo ra kết quả tốt trên một tập input đã được chọn lọc kỹ. Đó là một điều hợp lý và hữu ích để chứng minh. Nhưng nó có nghĩa là tiêu chí thành công của POC — "này, nó trả lời tốt 20 câu hỏi thử nghiệm này" — gần như không liên quan gì đến tiêu chí thành công ở production, vốn gần với "nó xử lý được 100.000 input đa dạng mỗi ngày, đôi khi bị lỗi định dạng, đôi khi mang tính đối kháng, trong ngân sách độ trễ cho phép, với chi phí doanh nghiệp có thể duy trì được."

Ba khoảng trống xuất hiện hầu như mọi lần:

• Đa dạng input. POC được test với các input sạch, có định dạng tốt do chính đội ngũ chọn. Traffic production bao gồm tài liệu lỗi định dạng, câu hỏi mơ hồ, văn bản không phải tiếng Anh, và những input được thiết kế riêng để phá hệ thống (dù có ác ý hay không).
• Khả năng quan sát lỗi. Trong một POC, một output sai được người chạy demo phát hiện ngay. Ở production, một output sai được đưa thẳng đến người dùng, và ai đó phải xây dựng hệ thống giám sát từ trước để thậm chí biết được điều đó đã xảy ra.
• Chi phí ở quy mô lớn. Một POC gọi API LLM 50 lần một ngày gần như không tốn gì. Cùng mẫu hình gọi đó ở tần suất 500.000 lần một ngày là một khoản mục chi phí mà đội tài chính sẽ hỏi tới — và thường buộc phải thay đổi kiến trúc (caching, dùng model nhỏ hơn cho các case dễ, gộp batch) vốn không nằm trong thiết kế ban đầu.

Tính năng AI production cần một bộ khung đánh giá, không phải cảm nhận chủ quan

Mảnh ghép thiếu lớn nhất chúng tôi thấy ở các dự án AI bị đình trệ là một cách đo lường chất lượng có thể lặp lại được. Một POC được đánh giá bởi ai đó đọc output rồi nói "ừ, trông ổn đấy". Cách đó không scale được, và nó không cho bạn biết liệu một thay đổi prompt hay nâng cấp model có làm mọi thứ tốt hơn hay tệ hơn.

Một bộ khung đánh giá production tối thiểu cần:

1. Một tập test đã gán nhãn với ít nhất 100-200 ví dụ thực tế (hoặc gần giống thực tế) có đáp án đúng hoặc chấp nhận được đã biết trước, lý tưởng là bao gồm cả các trường hợp biên và các ví dụ khó đã biết, không chỉ những case dễ.
2. Chấm điểm tự động — khớp chính xác khi có thể, và dùng LLM-as-judge hay chấm theo rubric khi output mang tính mở. Cách này không hoàn hảo, nhưng nhất quán, và đó chính là điều cho phép bạn so sánh trung thực hai phiên bản của một hệ thống.
3. Cổng chặn regression trong CI — nếu một thay đổi về prompt, model, hay retrieval làm điểm đánh giá tụt xuống dưới một ngưỡng, nó chặn deploy giống như một unit test thất bại vẫn làm.

Không có điều này, các đội ngũ rốt cuộc thực hiện thay đổi dựa trên vài ví dụ ai đó tình cờ thử, và chất lượng âm thầm suy giảm qua nhiều tháng mà không ai nhận ra cho đến khi khách hàng phàn nàn.

Câu hỏi về con người trong vòng lặp (human-in-the-loop) phải được trả lời rõ ràng

Mọi tính năng AI production đều cần một quyết định rõ ràng về việc con người nằm ở đâu trong vòng lặp, và "để sau tính" không phải là một câu trả lời — đó thường là cách những sự cố hoàn toàn có thể tránh được lại xảy ra. Với tính năng trích xuất tài liệu của một khách hàng trong lĩnh vực fintech, chúng tôi đặt một ngưỡng độ tin cậy rõ ràng: bất cứ điều gì model chấm dưới 85% độ tin cậy được chuyển cho người review, và mọi thứ trên ngưỡng đó đi thẳng qua, kèm một mẫu kiểm toán hàng tháng trên các case được tự động duyệt để bắt kịp hiện tượng trôi (drift). Chính quyết định thiết kế đơn lẻ đó — con người ở đâu, và trong điều kiện nào — thường là khác biệt giữa một tính năng doanh nghiệp tin tưởng và một tính năng bị âm thầm tắt đi sau sự cố đầu tiên.

Đừng nhầm lẫn "con người trong vòng lặp" với "con người chặn mọi thứ"

Đưa mọi thứ qua review của con người không phải là một sự thỏa hiệp "giữ an toàn" — nó thường có nghĩa là tính năng AI không bao giờ mang lại lợi ích hiệu suất mà nó được xây dựng để đạt được, và hàng đợi review trở thành điểm nghẽn mới. Mục tiêu là một ngưỡng được hiệu chỉnh, dựa trên bộ khung đánh giá nói trên, chứ không phải một tấm lưới an toàn bao trùm làm mất đi mục đích ban đầu.

Dành ngân sách cho những phần không xuất hiện trong demo

60% công việc kém hào nhoáng của AI production là: logic retry và fallback khi API model timeout hoặc bị giới hạn tần suất; ghi log mọi cặp input/output để debug và kiểm toán, với việc xử lý PII đúng cách; đánh version cho prompt và model để có thể rollback một thay đổi tệ; và giám sát chi phí kèm cảnh báo trước khi một vòng lặp chạy sai đốt hết ngân sách API của cả tháng chỉ trong một ngày. Không điều nào trong số này xuất hiện trong demo, nhưng tất cả đều bắt buộc trước khi một tính năng có thể được tin tưởng với người dùng thật và tiền thật đang bị đặt cược.

Những đội ngũ đi từ POC đến production nhanh nhất không phải là những đội có model hào nhoáng nhất. Họ là những đội đã xác định phạm vi POC ngay từ đầu như một bước kiểm tra tính khả thi, không phải một tính năng hoàn chỉnh, và dành ngân sách riêng — cả về thời gian lẫn kỳ vọng — cho công việc đánh giá, giám sát, và xử lý lỗi biến một bản demo thành thứ doanh nghiệp có thể tin cậy. Giai đoạn thứ hai đó của công việc chính là nơi chúng tôi dành phần lớn thời gian dự án cho các dự án AI, và đó hiếm khi là phần khách hàng dự đoán trước khi bắt đầu.