Xây dựng nền tảng cho LLM chạy production: Bài học từ lỗi ảo giác của AI agent

Khi các mô hình ngôn ngữ lớn (LLM) bước vào môi trường production, câu hỏi không còn là "làm sao để chạy được" mà là "làm sao để chạy đáng tin cậy". Aditya Mulik, tác giả bài viết trên InfoQ, đã rút ra bài học này từ chính thất bại của đội ngũ mình.

Khi AI agent "bịa" ra dữ liệu không tồn tại

Câu chuyện bắt đầu với một hệ thống gợi ý tồn kho — nơi AI agent được giao nhiệm vụ đọc dữ liệu kho và đề xuất hành động cho người dùng. Mọi thứ vận hành trơn tru cho đến khi agent bắt đầu đưa ra những gợi ý dựa trên sản phẩm không hề tồn tại, hoặc trích dẫn số liệu sai lệch so với nguồn dữ liệu gốc.

Đây chính là hiện tượng ảo giác (hallucination) — vấn đề quen thuộc nhưng cực kỳ nguy hiểm khi hệ thống được dùng để ra quyết định thực tế. Điều đáng chú ý là lỗi không nằm ở mô hình, mà ở cách đội ngũ tổ chức toàn bộ stack LLM.

Sai lầm cốt lõi: coi LLM là bài toán của ứng dụng

Theo tác giả, sai lầm phổ biến nhất là mỗi nhóm ứng dụng tự xây dựng lớp tích hợp LLM riêng: tự viết prompt, tự quản lý phiên bản, tự xử lý đầu ra. Ban đầu cách này có vẻ nhanh, nhưng khi số lượng ứng dụng tăng lên, hàng loạt vấn đề xuất hiện:

• Prompt bị phân mảnh, không ai biết phiên bản nào đang chạy ở đâu
• Đầu ra không được kiểm soát, mỗi nơi parse JSON theo một kiểu
• Chi phí token không thể truy vết, không biết ứng dụng nào đang đốt ngân sách
• Không có cơ chế chặn trước khi lỗi lan ra người dùng

"Chúng tôi nhận ra vấn đề không phải là mô hình dở. Vấn đề là chúng tôi đang đối xử với LLM như một thư viện, chứ không phải như hạ tầng."

Giải pháp: biến stack LLM thành hạ tầng nền tảng

Bước ngoặt đến khi đội ngũ chuyển sang mô hình LLM platform dùng chung — một lớp hạ tầng tập trung phục vụ mọi ứng dụng trong tổ chức. Nền tảng này cung cấp ba nhóm dịch vụ cốt lõi.

Prompt registry và quản lý phiên bản

Thay vì để prompt nằm rải rác trong code, toàn bộ prompt được đưa vào một registry trung tâm có đánh phiên bản. Mỗi thay đổi prompt đều có thể rollback, so sánh và kiểm thử. Điều này giúp đội ngũ trả lời được câu hỏi: "Prompt nào đang tạo ra kết quả tệ?" — thay vì mò mẫm trong log.

Kiểm soát schema đầu ra

Đây là tuyến phòng thủ trực tiếp chống ảo giác. Thay vì tin tưởng agent trả về đúng định dạng, nền tảng bắt buộc đầu ra phải khớp một schema đã định. Nếu agent bịa ra sản phẩm không có trong kho, hoặc trả về trường dữ liệu sai kiểu, request bị từ chối ngay thay vì lọt tới người dùng.

Cách tiếp cận này biến "niềm tin vào mô hình" thành "kiểm chứng bằng hạ tầng" — nguyên tắc cốt lõi khi đưa bất kỳ hệ thống AI nào vào production.

Quy trách nhiệm chi phí token theo request

Mỗi lời gọi LLM đều được gắn nhãn: ứng dụng nào, tính năng nào, người dùng nào. Nhờ đó, chi phí token trở thành một chỉ số vận hành minh bạch thay vì một hoá đơn mờ cuối tháng.

Điều này đặc biệt quan trọng với các doanh nghiệp Việt Nam, nơi ngân sách cho AI thường eo hẹp và việc lãng phí token có thể âm thầm đội chi phí lên gấp nhiều lần.

Bài học cho đội ngũ kỹ thuật

Tác giả đúc kết một số nguyên tắc đáng lưu ý:

• Tách biệt prompt khỏi code ứng dụng ngay từ đầu, đừng đợi đến khi hỗn loạn
• Schema enforcement là bắt buộc, không phải tính năng phụ — nó là tuyến phòng thủ đầu tiên chống ảo giác
• Đo lường chi phí theo thực thể nghiệp vụ (request, người dùng, tính năng), không chỉ theo tổng
• Xây dựng nền tảng sớm hơn bạn nghĩ, vì chi phí refactor về sau luôn đắt hơn

Ý nghĩa với thị trường công nghệ Việt Nam

Khi ngày càng nhiều startup và doanh nghiệp Việt Nam tích hợp LLM vào sản phẩm, bài toán "platform hóa" này sẽ nhanh chóng trở nên quen thuộc. Các đội ngũ đang ở giai đoạn thử nghiệm POC có thể tận dụng giai đoạn này để thiết kế đúng ngay từ đầu — thay vì lặp lại vòng lặp "xây nhanh, sửa chậm" mà tác giả đã trải qua.

Với những đội chưa có nguồn lực xây nền tảng riêng, các giải pháp mã nguồn mở như LangSmith, LiteLLM hay Helicone có thể là điểm khởi đầu hợp lý để tiết kiệm thời gian.

Điểm mấu chốt vẫn không đổi: LLM trong production là bài toán hạ tầng, không chỉ là bài toán mô hình.