Demo ngon, production sập — lỗi ở đâu?

Hệ thống AI chạy ngon trên máy bạn nhưng sập trên production? Ba "triệu chứng bệnh" phổ biến và cách chữa trị trước khi quá muộn.

Bạn, mình, và cái prompt "chạy ngon trên máy tui"

Bạn có từng demo hệ thống AI trước sếp, nó trả lời mượt như lụa, rồi đúng ngày go-live thì nó... hallucinate giữa cuộc họp với khách hàng không? Mình thì có. Hai lần.

Vấn đề không nằm ở model. Vấn đề nằm ở chỗ: chúng ta đang đối xử với hệ thống AI như phần mềm truyền thống — deploy xong là xong. Nhưng AI không phải phần mềm truyền thống. Nó giống một bệnh nhân cần theo dõi liên tục hơn là một cỗ máy lắp xong chạy mãi.

Hôm nay mình muốn thử thách bạn: trong 3 cách tiếp cận production AI dưới đây, bạn đang ở đâu — và bạn nên ở đâu?

Cách 1: "Prompt rồi cầu nguyện"

Đây là cách phổ biến nhất. Bạn viết prompt, gọi API, nhận output, trả về user. Không validate. Không fallback. Không monitoring.

Hình dung thế này: giả sử team bạn 5 người đang build một chatbot hỗ trợ khách hàng cho sàn thương mại điện tử. Prompt ngon, demo chạy tốt. Nhưng lên production, khách hỏi "đơn hàng tui đâu rồi?" — model tự bịa một mã vận đơn. Không ai phát hiện cho đến khi khách gọi hotline mắng.

Triệu chứng: output sai nhưng nhìn rất tự tin. Giống bác sĩ kê toa nhầm mà viết chữ rất đẹp — bạn không nghi ngờ cho đến khi uống thuốc.

Ưu điểm: Nhanh, rẻ, ship được ngay.
Nhược điểm: Bạn đang chơi xổ số với dữ liệu của khách hàng.

Cách 2: Validator sandwich — "khám trước, khám sau"

Đây là pattern mà mình thấy các team nghiêm túc bắt đầu áp dụng. Ý tưởng đơn giản lắm: trước khi gửi input vào model, bạn validate. Sau khi nhận output từ model, bạn validate lần nữa. Hai lớp bảo vệ kẹp model ở giữa — như bánh mì kẹp thịt vậy.

Ví dụ cụ thể: team backend ở một startup fintech Việt Nam build tính năng phân loại giao dịch bằng LLM. Họ thêm:

Kết quả? Số lượng response lỗi format giảm rõ rệt. Quan trọng hơn, không còn trường hợp model vô tình trả về thông tin nhạy cảm của khách.

Ưu điểm: Kiểm soát được cả đầu vào lẫn đầu ra, dễ debug.
Nhược điểm: Cần effort thiết kế schema trước, thêm chút latency (nhưng thường không đáng kể).

Cách 3: Observable pipeline — "phòng ICU cho AI"

Đây là level mà ít team Việt Nam mình biết đã đạt tới, nhưng nếu hệ thống AI của bạn serve hàng nghìn request mỗi ngày, bạn cần nó.

Đặt ngược lại vấn đề: validator sandwich giúp bạn chặn output lỗi, nhưng nó không cho bạn biết tại sao lỗi tăng đột biến sáng thứ Hai. Observable pipeline thì có. Bạn monitor toàn bộ — latency mỗi bước, token usage, tỷ lệ retry, cost per request, và quan trọng nhất: drift detection (khi model bắt đầu trả output khác hẳn pattern bình thường).

Thêm vào đó là hai "bộ phận cấp cứu":

Ưu điểm: Bạn biết chính xác hệ thống "ốm" ở đâu, khi nào.
Nhược điểm: Setup phức tạp, cần invest thời gian ban đầu.

Cái bẫy mà team nào cũng dính ít nhất một lần

Bẫy lớn nhất không phải kỹ thuật — mà là tâm lý "demo xong là ship".

Mình từng chứng kiến một team 3 dev ở Đà Nẵng build agent tự động review PR bằng Claude. Demo quá đẹp: agent comment chi tiết, phân loại bug, suggest fix. Cả team hào hứng push lên production repo chính.

Tuần đầu: ngon lành.
Tuần hai: agent bắt đầu comment nhảm vào PR không liên quan — vì không ai sanitize diff input đúng cách.
Tuần ba: dev trong team bắt đầu ignore mọi comment từ AI — kể cả comment đúng.

Bài học ở đây rất rõ: output của model là untrusted, y hệt user input. Bạn sẽ không bao giờ eval() trực tiếp input từ user, đúng không? Thì cũng đừng trust output từ model mà không validate.

Như mình đã chia sẻ trong bài về agent (bài "Agent đang ốm — nhưng không ai đưa đi khám"), vấn đề observability cho AI không phải thứ xa xỉ nữa — nó là tiêu chuẩn tối thiểu.

Toa thuốc nhanh — không cần refactor cả hệ thống

Không cần đập đi xây lại. Ba việc nhỏ, bắt đầu từ chiều nay:

Bước 1: Thêm output schema validation

Dùng Zod (TypeScript) hoặc Pydantic (Python) để define schema cho mọi response từ LLM. Nếu response không match → retry tối đa 2 lần → trả fallback.

from pydantic import BaseModel

class SentimentResult(BaseModel):
    sentiment: str  # "positive" | "negative" | "neutral"
    confidence: float
    reasoning: str

Bước 2: Wrap API call trong circuit breaker

Python có pybreaker, Node.js có opossum. Khi model API timeout liên tục, circuit tự mở ra và trả cached response hoặc thông báo lỗi thân thiện — thay vì để user chờ đến timeout.

Bước 3: Log có cấu trúc, không log "cho có"

Mỗi request qua pipeline, log: input hash, output schema pass/fail, latency, token count, cost estimate. Một file JSON structured log đủ để bạn grep ra ngay sáng thứ Hai hệ thống có "sốt" hay không.

Nếu bạn muốn thử local trước khi đốt tiền API, GLM 5.1 đang là một lựa chọn open-source đáng chú ý cho coding và agentic workflow — chạy được trên máy cá nhân với llama.cpp và CUDA support.

Nếu là mình, mình sẽ...

Bắt đầu từ Cách 2. Validator sandwich cho bạn phần lớn giá trị với effort vừa phải. Sau đó dần bổ sung monitoring và circuit breaker khi traffic tăng.

Đừng cố build "hệ thống production hoàn hảo" ngay từ ngày đầu. Hệ thống AI giống bệnh nhân mãn tính hơn là cảm cúm — không chữa một lần là khỏi, mà cần khám định kỳ và điều chỉnh liên tục. Cái quan trọng nhất là bạn biết nó đang ốm trước khi user phát hiện.

Spoiler: không có silver bullet — nhưng có silver lining: mỗi lần hệ thống sập là một lần bạn hiểu nó rõ hơn bất kỳ tài liệu nào.

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

Nguồn tham khảo