POC chạy ngon — sao lên production lại "trật ray"?

Mười team thử GenAI, chín team có demo đẹp. Nhưng từ demo đến production là một hành trình mà nhiều team Việt Nam đang kẹt giữa đường.

Cái demo đẹp nhất thường chết trước

Bạn đã bao giờ thấy một POC chạy mượt trên laptop, cả phòng vỗ tay, rồi ba tháng sau vẫn nằm im trong repo chưa? Mình thấy hoài.

Chuyện này không lạ. Hầu hết các team đều vượt qua giai đoạn "chứng minh AI làm được" khá nhanh. Gọi API, nối prompt, demo trước sếp — xong. Nhưng từ lúc demo xong đến lúc user thật dùng hàng ngày, đó mới là đoạn đường gập ghềnh mà ít ai chuẩn bị trước.

AWS gần đây chia sẻ framework Path-to-Value (P2V) — nói thẳng ra thì đây là bản đồ cho hành trình từ "ý tưởng" đến "tạo ra giá trị thật". Và điểm đáng chú ý nhất không phải là phần technology, mà là phần mà hầu hết team bỏ qua: governance, integration, và success metrics.

Ga "POC" ai cũng dừng được — vấn đề là đoạn sau

Mình lấy ví dụ cụ thể. Giả sử team bạn 5 người, đang xây một chatbot hỗ trợ nội bộ cho công ty logistics. Tuần đầu, bạn nối GPT-4 với vài tài liệu nội bộ qua RAG, demo chạy ngon lành. Sếp gật đầu, "triển khai đi."

Rồi thực tế ập đến:

• Data access: Tài liệu nội bộ nằm rải rác — SharePoint, Google Drive, hệ thống ERP cũ. Mỗi nguồn một cách xác thực khác nhau.
• Security: Ai được hỏi gì? Nhân viên kho không nên thấy dữ liệu tài chính. Phân quyền trong RAG pipeline? Chưa ai nghĩ đến lúc làm POC.
• Monitoring: Chatbot trả lời sai thì sao? Ai review? Bao lâu phát hiện?

Đây chính là lúc đầu máy vẫn chạy nhưng không ai bẻ ghi — cả đoàn cứ thế lao thẳng vào ngõ cụt.

Từ Sài Gòn đến Đà Nẵng — cùng một bài toán

Team fintech 8 người ở TP.HCM xây agent tự động phân loại ticket hỗ trợ khách hàng. POC mất 2 tuần, accuracy trên tập test nội bộ rất ổn. Nhưng khi đưa vào production:

• Ticket thật có tiếng lóng, viết tắt, mix tiếng Anh-Việt — model bối rối.
• Không có feedback loop: khi agent phân loại sai, không ai đánh dấu lại để cải thiện.
• Chi phí API tăng gấp ba so với dự tính vì prompt thật dài hơn nhiều so với test set.

Họ mất thêm 2 tháng chỉ để xử lý ba vấn đề này. Bài học: POC test feasibility, nhưng production test endurance.

Team edtech 3 người ở Đà Nẵng dùng open-source model chạy qua Ollama để tạo quiz tự động từ bài giảng. POC chạy local ngon. Nhưng lên production:

• Cần serve cho vài trăm giáo viên cùng lúc — một máy không kham nổi.
• Chuyển sang vLLM để serving, nhưng infra team chỉ có... chính họ.
• Cuối cùng họ chọn hybrid: cloud API cho giờ cao điểm, self-host cho off-peak.

Quyết định đó không nằm trong bất kỳ POC nào — nó chỉ xuất hiện khi bạn đối mặt với traffic thật.

Thử ngay chiều nay: audit khoảng cách POC–Production

Nếu team bạn đang có một POC chạy được, hãy dành 2 tiếng làm bài tập này:

Bước 1: Liệt kê tất cả data sources mà POC đang dùng. Đánh dấu nguồn nào là "dữ liệu sạch chuẩn bị sẵn" vs "dữ liệu production thật."

Bước 2: Trả lời 3 câu hỏi:

• Ai sẽ dùng system này hàng ngày? (không phải "ai xem demo")
• Khi output sai, ai chịu trách nhiệm và quy trình xử lý là gì?
• Chi phí chạy 1 tháng ở production load ước tính bao nhiêu?

Bước 3: Vẽ bảng 2 cột — "POC có" vs "Production cần" — rồi đếm số dòng chênh lệch.

Nếu bảng đó có hơn 5 dòng khác biệt, bạn chưa sẵn sàng lên production. Và đó hoàn toàn bình thường — quan trọng là biết mình đang ở đâu trước khi chạy tiếp.

Cái bẫy tên "demo-driven development"

Mình gặp một pattern lặp đi lặp lại: team demo thành công, được duyệt budget, rồi... tiếp tục build thêm feature mới thay vì hardening feature cũ. Mỗi sprint thêm một khả năng mới, nhưng không sprint nào dành cho monitoring, error handling, hay user feedback loop.

Bản chất thật sự: team đang lắp thêm toa mới trong khi đoạn ray phía trước còn chưa được đặt xong.

Framework P2V gợi ý cách tiếp cận khác — thay vì chạy nhanh về phía trước, hãy đảm bảo mỗi giai đoạn đều có "definition of done" rõ ràng trước khi sang giai đoạn kế. Nghe chậm, nhưng thực tế lại nhanh hơn vì bạn không phải quay lại sửa.

Nếu bạn đang dùng open-source stack — LangChain, LlamaIndex, hay bất kỳ framework nào — thì việc tự build phần governance và monitoring lại càng quan trọng hơn, vì không có managed service nào lo hộ phần đó. Như mình đã chia sẻ trong bài về agent không biết đọc — thiếu nền tảng thì xây gì cũng lung lay.

Một dòng duy nhất mang về

POC là vé lên tàu. Production mới là hành trình. Và phần khó nhất chưa bao giờ là đầu máy có mạnh không — mà là có ai lo đường ray phía trước hay chưa.

Đừng tin mình, thử audit cái POC đang nằm trong repo team bạn đi rồi biết.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng