AI product: xử model sau cùng

AI product: xử model sau cùng

Muốn triển khai AI feature bền hơn, đừng bắt đầu bằng câu hỏi chọn model nào. Hãy quyết định lớp kỹ thuật nào đáng xây trước.

Cuộc họp triển khai AI feature thường có một khoảnh khắc rất quen: ai đó mở laptop, chiếu bảng so sánh model, rồi cả phòng bắt đầu tranh luận GPT, Claude, Gemini hay Llama. Mười lăm phút sau, chưa ai nói user nào được phép gọi AI, log lưu ở đâu, lỗi trả về thế nào, và ai chịu tiền khi prompt bị spam.

Nói thẳng ra thì: model là bị cáo nổi tiếng nhất trong phiên tòa, nhưng không phải chứng cứ duy nhất.

Nếu bạn là developer hoặc tech lead đang xây hệ thống AI thật, câu hỏi đúng không phải “model nào thông minh nhất?”. Câu hỏi đúng hơn là: team mình đang thiếu lớp kỹ thuật nào để biến một model call thành product feature đáng tin?

Sơ đồ minh họa cho bài AI product: xử model sau cùng

Sơ đồ tóm tắt ý chính của bài viết.

Khái niệm cần đổi: AI feature không phải một API call

Từ ngoài nhìn vào, AI product trông rất gọn. User gõ câu hỏi, app trả lời. Developer gọi model API, nhận text, render lên UI. Xong.

Nhưng trong production, một AI feature thường là chuỗi nhiều lớp:

Đọc danh sách này hơi khô, nhưng nó quyết định sống còn. Model giỏi mà permission lỏng thì AI có thể trả lời dựa trên tài liệu user không được xem. Prompt hay mà không có tracing thì khi output sai, bạn chỉ biết “nó sai”, không biết sai do retrieval, do model, do template hay do dữ liệu nguồn.

Đây là điểm nhiều team hiểu nhầm: AI feature không chết vì model dở nhiều bằng chết vì hệ thống quanh model không có kiểm soát.

Vì sao chuyện này đáng quan tâm ở team Việt Nam

Ở nhiều team nhỏ, triển khai AI thường bắt đầu bằng một demo nội bộ. Một dev làm prototype cuối tuần, gọi API, nối vào Slack hoặc web app, mọi người thấy “ổn áp”. Rồi demo ấy bị kéo thẳng vào roadmap.

Vấn đề không nằm ở demo. Demo là cần thiết. Vấn đề là team dùng tiêu chuẩn demo để ra quyết định production.

Hình dung thế này: bạn xây chatbot hỏi đáp tài liệu nội bộ cho công ty. Bản thử nghiệm dùng một service account có quyền đọc toàn bộ folder. Trong buổi demo, mọi người hỏi vài câu là ra đúng. Nhưng khi đưa cho cả công ty dùng, bạn mới gặp các câu hỏi khó chịu:

Lúc này, việc đổi model chỉ giống như thay luật sư giữa phiên xử trong khi hồ sơ chứng cứ vẫn thiếu trang. Có thể giúp một chút, nhưng không giải quyết gốc.

Framework quyết định: 5 lớp cần xét trước khi đổi model

Mình hay dùng một khung đơn giản cho team builder: P-R-O-V-E. Không phải để đặt tên cho vui, mà để ép cuộc họp kỹ thuật đi qua đủ các câu hỏi vận hành.

P — Permission: AI được biết gì?

Nếu feature của bạn đụng tới dữ liệu nội bộ, permission phải đi trước prompt.

Câu hỏi cần chốt:

Quyết định thực tế: nếu chưa có permission chắc, đừng build chatbot tổng công ty. Hãy bắt đầu bằng phạm vi hẹp: một nhóm, một kho tài liệu, một loại câu hỏi.

R — Retrieval: model lấy chứng cứ từ đâu?

Retrieval là lớp tìm thông tin liên quan để đưa vào prompt. Với RAG, model không chỉ dựa vào trí nhớ đã train, mà được đưa thêm tài liệu đúng ngữ cảnh.

Nhưng retrieval không tự nhiên đúng. Bạn cần quyết định:

Ví dụ cụ thể: với tài liệu chính sách nhân sự, câu trả lời phải ưu tiên bản mới nhất. Nếu retrieval lôi cả chính sách cũ và mới vào prompt, model có thể trộn hai bản rồi trả lời rất tự tin. Lỗi này không sửa bằng prompt “hãy cẩn thận” được; bạn phải xử ở indexing và ranking.

O — Orchestration: request đi qua những bước nào?

Orchestration là cách điều phối nhiều bước: kiểm tra input, tìm tài liệu, gọi model, kiểm tra output, ghi log, trả kết quả.

Một pipeline tối thiểu có thể trông như sau:

ai_feature_pipeline:
  input:
    validate_user: true
    redact_sensitive_fields: true
  retrieval:
    filter_by_permission: true
    top_k: 5
  generation:
    route_by_task: true
    timeout_seconds: 20
  output:
    cite_sources: true
    block_if_no_evidence: true
  observability:
    log_prompt_version: true
    trace_request_id: true

Đây không phải cấu hình copy-paste để chạy ngay, mà là checklist thiết kế. Nếu pipeline của bạn chưa trả lời được từng dòng này, model mới hơn cũng chỉ làm lỗi chạy nhanh hơn.

V — Validation: biết đúng sai bằng cách nào?

Evaluation pipeline là bộ quy trình đo chất lượng: test set, tiêu chí chấm, review thủ công, hoặc so sánh giữa các phiên bản.

Với AI feature, validation không nên chỉ là “mình hỏi thử thấy đúng”. Bạn cần ít nhất ba nhóm câu hỏi:

  1. Câu dễ, có đáp án rõ.
  2. Câu mơ hồ, cần hỏi lại hoặc từ chối.
  3. Câu nguy hiểm, dễ lộ dữ liệu hoặc bịa.

Nếu feature ảnh hưởng tới chỉ số sản phẩm, bạn còn cần cách thử nghiệm cẩn thận. Sequential testing là kiểm định cho phép nhìn kết quả nhiều lần trong quá trình chạy mà vẫn kiểm soát rủi ro kết luận nhầm, nếu thiết kế đúng. Switchback experiment là kiểu thử nghiệm bật/tắt theo khung thời gian, hữu ích khi user cùng dùng chung tài nguyên như capacity model premium.

Không phải team nào cũng cần triển khai thống kê phức tạp ngay. Nhưng mọi team cần đồng ý trước: “điều kiện nào thì ship, điều kiện nào thì rollback?”.

E — Economics: chi phí hỏng ở đâu?

AI cost không chỉ là giá mỗi token. Nó nằm ở cache miss, retry, model routing sai, request quá dài, và user dùng feature theo cách bạn không dự đoán.

Các câu hỏi nên hỏi trước khi launch:

Với team nhỏ, economics không cần dashboard hoành tráng ngay. Nhưng cần cost guardrail — rào chắn chi phí — ở mức tối thiểu: quota, alert, và log đủ chi tiết để biết ai đang đốt tiền.

Ai nên xây lớp nào trước?

Không có một thứ tự chung cho mọi team. Nhưng có thể ra quyết định theo rủi ro chính.

| Nếu rủi ro lớn nhất là... | Ưu tiên xây trước | Tạm hoãn |
|---|---|---|
| Lộ dữ liệu nội bộ | Permission, safety checks, logging | Model routing phức tạp |
| Trả lời sai tài liệu | Retrieval, citations, evaluation set | Fine-tuning |
| Chi phí khó kiểm soát | Caching, quota, model routing | Multi-agent workflow |
| Debug quá mù mờ | Tracing, prompt versioning, structured logs | Thêm model mới |
| Không biết feature có hiệu quả không | Experiment design, success metrics | Scale rollout |

Điểm quan trọng: mỗi lớp kỹ thuật là một quyết định đầu tư, không phải món trang trí kiến trúc.

Nếu bạn chỉ có hai tuần, đừng cố xây full platform. Hãy chọn lớp làm giảm rủi ro lớn nhất cho use case hiện tại.

Một buổi chiều để soi lại AI feature

Nếu team bạn đã có prototype, dành một buổi chiều làm “đối chất” với hệ thống. Không cần viết lại hết.

Checklist gọn:

  1. Vẽ đường đi của một request

Từ lúc user bấm nút đến lúc response hiện ra. Ghi rõ bước nào gọi external API, bước nào đọc database, bước nào ghi log.

  1. Gắn nhãn dữ liệu nhạy cảm

Prompt có chứa email, hợp đồng, thông tin khách hàng, lương, source code riêng không? Nếu có, log đang lưu thế nào?

  1. Tạo 20 câu test cố định

Bao gồm câu đúng, câu thiếu dữ liệu, câu hỏi vượt quyền, câu dễ gây hallucination — tức trả lời bịa nhưng nhìn có vẻ hợp lý.

  1. Đặt một ngân sách lỗi

Không cần con số đẹp. Chỉ cần thỏa thuận: lỗi nào chấp nhận được, lỗi nào phải rollback ngay.

  1. Chốt điều kiện đổi model

Ví dụ: chỉ đổi model nếu evaluation set cải thiện rõ, latency không phá trải nghiệm, và chi phí không vượt ngưỡng team đã đặt.

Sau bước này, bạn sẽ thấy rất nhiều cuộc tranh luận “model nào tốt hơn” tự biến mất. Vì hội đồng xét xử đã có chứng cứ: log, test case, chi phí, quyền truy cập, và hành vi thật của user.

Bẫy cuối: biến kiến trúc thành nghi lễ

Có một cực đoan ngược lại: thấy production AI phức tạp quá, team bắt đầu xây platform khổng lồ trước khi có user thật.

Cũng không ổn.

Nếu feature chỉ tóm tắt ghi chú cá nhân, bạn chưa cần orchestration nhiều tầng. Nếu dữ liệu không nhạy cảm và traffic thấp, self-host phức tạp có thể làm team chậm hơn. Nếu bài toán chưa chứng minh được value, đừng dành cả tháng tối ưu model routing.

Cách nghĩ mình khuyên dùng: build lớp bảo vệ theo mức độ rủi ro, không theo độ hào nhoáng của architecture diagram.

Sau bài này, điều bạn nên nghĩ khác là: chọn model không phải quyết định đầu tiên, mà là quyết định nằm trong một hồ sơ kỹ thuật lớn hơn. Product AI đáng tin đến từ hệ thống biết kiểm chứng, giới hạn, quan sát và sửa sai.

Kết lại gọn: model có thể là ngôi sao trên bục khai báo, nhưng production mới là nơi tuyên án.

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

Nguồn tham khảo