Custom RAG cho doanh nghiệp: Kiến trúc 3 lớp chống ảo giác (zero-hallucination)

Câu trả lời ngắn: Bạn không chống ảo giác (hallucination) của RAG bằng cách đổi sang một model "xịn" hơn — bạn chống bằng kiến trúc vận hành. Trong các dự án enterprise Nhật (bảo hiểm, khu vực công), tôi dùng một khung 3 lớp kiểm soát: chặn ở input, ràng buộc ở retrieval, và review ở output. Cách này đẩy tỷ lệ trả lời sai về gần như bằng không ở những domain không cho phép sai — thay vì kỳ vọng model "tự nhiên thông minh".

TL;DR (Executive Summary)

  • Bài toán: Triển khai Custom RAG / AI Chatbot cho 5 tập đoàn bảo hiểm lớn và một dự án AI khu vực công tại Nhật — nơi một câu trả lời sai (hallucination) không phải "bug nhỏ" mà là rủi ro pháp lý và mất uy tín (FSA compliance).
  • Giải pháp: Một khung 3 lớp (3-Tier Review) — kiểm soát đầu vào, ràng buộc truy hồi (retrieval grounding), và human-in-loop ở đầu ra — thay vì phụ thuộc vào "độ thông minh" của LLM.
  • Kết quả: Giảm ~40% chi phí vận hành chăm sóc khách hàng, đồng thời giữ độ chính xác và tính tuân thủ ở mức enterprise — sống ổn định qua toàn bộ vòng đời 3 năm.

Hallucination thực ra là gì — dưới góc nhìn vận hành?

Đa số bài viết định nghĩa hallucination theo kiểu học thuật: "mô hình sinh ra thông tin không có thật". Định nghĩa đó đúng nhưng vô dụng khi bạn phải chịu trách nhiệm vận hành.

Dưới góc nhìn một Delivery Manager / System Architect, tôi định nghĩa lại: hallucination là khi hệ thống trả lời một cách tự tin về thứ nó không có cơ sở dữ liệu để khẳng định. Vấn đề cốt lõi không phải "model bịa" — mà là hệ thống không có cơ chế thừa nhận "tôi không biết".

Trong môi trường SME, một câu trả lời sai có thể chỉ gây khó chịu. Trong môi trường bảo hiểm Nhật, một chatbot tư vấn sai điều khoản hợp đồng có thể kéo theo trách nhiệm pháp lý. Hai bài toán này không cùng một class rủi ro, nên không thể dùng chung một kiến trúc.

Vì sao "dùng model xịn hơn" không giải quyết được?

Đây là cái bẫy phổ biến nhất. Khi chatbot bịa, phản xạ đầu tiên là "đổi sang model mạnh hơn". Nhưng model mạnh hơn chỉ bịa thuyết phục hơn — nó không tự biết khi nào nên im lặng.

Lý do thật: hallucination phần lớn không sinh ra ở bước generate, mà ở bước retrieval. Nếu hệ thống truy hồi nhầm tài liệu, hoặc truy hồi được tài liệu rỗng nhưng vẫn ép model trả lời, thì model "ngoan" mấy cũng sẽ lấp khoảng trống bằng phỏng đoán. Đây là lý do tôi luôn nói: RAG là bài toán kiến trúc dữ liệu, không phải bài toán chọn model. (Tôi đã viết kỹ tư duy này trong bài Tư duy hệ thống trong giải quyết bài toán kinh doanh.)

Khung 3 lớp chống ảo giác (3-Tier Review Framework)

Đây là framework tôi áp dụng cho các hệ thống Custom RAG enterprise. Mỗi lớp chặn một loại sai khác nhau — và quan trọng là chúng độc lập, không lớp nào gánh hết trách nhiệm.

Lớp 1 — Kiểm soát đầu vào (Input Gating)

Trước khi câu hỏi chạm tới LLM, hệ thống phân loại: câu này có nằm trong phạm vi hệ thống được phép trả lời không? Câu ngoài phạm vi (out-of-scope) bị chặn ngay và chuyển hướng — thay vì để model cố trả lời rồi bịa.

Với dữ liệu phi cấu trúc (PDF hợp đồng, văn bản scan), lớp này còn bao gồm OCR + auto-screening: chuẩn hoá tài liệu nguồn và loại bỏ phần nhiễu trước khi đưa vào index. Rác đầu vào = rác đầu ra, không model nào cứu được.

Lớp 2 — Ràng buộc truy hồi (Retrieval Grounding)

Đây là lớp quan trọng nhất nhưng hay bị bỏ qua. Nguyên tắc: model chỉ được trả lời dựa trên tài liệu đã truy hồi, và phải trích dẫn được nguồn. Nếu retrieval trả về độ tương đồng dưới ngưỡng (không tìm thấy tài liệu đủ liên quan), hệ thống bắt buộc trả lời "không có thông tin" — chứ không chuyển sang chế độ phỏng đoán.

Nói cách khác: tôi thiết kế để hệ thống được phép nói "tôi không biết". Đó là tính năng, không phải lỗi.

Lớp 3 — Human-in-loop ở đầu ra (Output Review)

Ở domain rủi ro cao, không phải câu trả lời nào cũng bắn thẳng ra khách. Những câu chạm vùng nhạy cảm (điều khoản, số tiền, cam kết pháp lý) được route qua review của con người trước khi gửi. Phần lớn câu hỏi thường gặp vẫn tự động hoá hoàn toàn để giảm tải; chỉ phần "đắt" mới cần người.

Chính thiết kế này — tự động hoá phần rẻ, giữ người ở phần đắt — là cái giúp giảm ~40% chi phí vận hành mà không đánh đổi bằng rủi ro compliance.

Khi nào KHÔNG cần kiến trúc này?

Tôi không tin vào việc áp một kiến trúc nặng cho mọi bài toán. Khung 3 lớp này không cần thiết nếu:

Với những trường hợp đó, một RAG đơn giản hoặc thậm chí không cần RAG là lựa chọn đúng. Tôi đã nói về cái bẫy "đốt tiền vào AI sai chỗ" trong bài Automation thất bại: những bài học.

Kiến trúc 3 lớp dành cho khi một câu trả lời sai có cái giá thực sự — và đó chính là lúc nó đáng từng đồng.

Câu hỏi thường gặp

Hỏi: RAG có loại bỏ hoàn toàn hallucination không? Không có hệ thống nào đảm bảo 0% tuyệt đối. Nhưng với kiến trúc 3 lớp — input gating, retrieval grounding bắt buộc trích nguồn, và human-in-loop ở vùng rủi ro — bạn có thể đẩy rủi ro về mức chấp nhận được cho enterprise, và quan trọng hơn là kiểm soát được khi nó xảy ra (truy vết được lý do).

Hỏi: Nên fine-tune model hay dùng RAG cho dữ liệu doanh nghiệp? Trong hầu hết case enterprise tôi gặp, RAG thắng: dữ liệu thay đổi liên tục (cập nhật điều khoản, tài liệu mới), fine-tune lại tốn kém và khó truy vết nguồn. RAG cho phép cập nhật tri thức bằng cách cập nhật index, và luôn trích dẫn được nguồn — yếu tố bắt buộc khi cần compliance.

Hỏi: Chi phí lớn nhất khi xây Custom RAG enterprise nằm ở đâu? Không phải ở model hay hạ tầng — mà ở chuẩn hoá dữ liệu nguồn (Lớp 1) và thiết kế ngưỡng/luồng review (Lớp 2–3). Đây là phần "không sexy" nhưng quyết định hệ thống sống hay chết. Đội nào báo giá chỉ tính tiền model thường là đội chưa từng vận hành RAG thật trong môi trường khắt khe. Tôi mổ xẻ chính cái retrieval engine bên dưới — chunking, hybrid search, reranking và bảng eval có số — trong bài Bên trong một Custom RAG chạy được: từ chunking đến retrieval eval.

Nếu bạn đang cân nhắc đưa AI/RAG vào một quy trình mà sai số có cái giá thật — và cần một người từng chịu trách nhiệm kiến trúc loại hệ thống này từ đầu đến vận hành — bạn có thể xem thêm năng lực AI Automation, đọc các câu chuyện dự án thực tế, hoặc gửi bài toán hệ thống để cùng trao đổi.

Nguyễn Phúc Nguyên Châu
Delivery Manager / System Architect
14 năm kinh nghiệm kiến trúc và vận hành hệ thống cho thị trường Việt – Nhật