Mười Không Phải Một Trăm: Vì Sao Mọi Bộ Phát Hiện Ảo Giác AI Đều Thất Bại Với Lỗi Số
Bài viết phân tích một lỗ hổng nghiêm trọng trong các hệ thống phát hiện ảo giác (hallucination) của mô hình ngôn ngữ lớn: chúng gần như mù hoàn toàn với các lỗi sai về số liệu. Tác giả đã thử nghiệm 5 loại phương pháp phát hiện phổ biến và chỉ ra rằng tất cả đều có AUROC dưới 0.75 khi đối mặt với lỗi thay đổi một chữ số. Từ đó, ông đề xuất một giải pháp mã nguồn mở tên groundlens, kết hợp so khớp ngữ nghĩa cho từ ngữ và so sánh số học cho các con số, hoạt động hiệu quả hơn hẳn mà không cần huấn luyện thêm.

Mười Không Phải Một Trăm: Vì Sao Mọi Bộ Phát Hiện Ảo Giác AI Đều Thất Bại Với Lỗi Số
Một ngân hàng vận hành hệ thống RAG phía sau chatbot chăm sóc khách hàng. Người dùng hỏi về một hóa đơn, tài liệu truy xuất ghi tổng nợ là 10.000 đô la, nhưng chatbot lại trả lời là 1.000 đô la. Lỗi sai một chữ số tưởng chừng đơn giản này lại là "tử huyệt" của mọi công cụ phát hiện ảo giác hiện đại — từ bộ đo độ tương đồng vector đến các mô hình phán xét bằng LLM. Thử nghiệm thực tế trên 5 họ phương pháp cho thấy không một công cụ nào hoạt động đủ tốt ở ngưỡng vận hành thực tế của một hệ thống sản xuất, và giải pháp nằm ở một ý tưởng cũ nhất trong khoa học máy tính: so sánh từng phần tử, không so sánh bản tóm tắt.
Vấn Đề Nằm Ở Đâu?
Tác giả bài viết đã dành một tuần để đo lường cách các công cụ phát hiện ảo giác tiêu chuẩn xử lý lỗi sai số, và một tuần tiếp theo để trả lời câu hỏi quan trọng hơn: liệu chúng có hoạt động ở mức độ mà một hệ thống sản xuất thực sự yêu cầu hay không. Câu trả lời ngắn gọn là không. Không phải các bộ phát hiện đã huấn luyện, không phải bộ phán xét LLM, không phải mô hình entailment, và cũng không phải thứ mà chính ông tự xây dựng.
Thử nghiệm được thực hiện trên bộ dữ liệu RAGTruth với 200 mẫu: 100 câu trả lời đúng và 100 bản sao có một chữ số bị thay đổi (ví dụ 1.000 thay vì 10.000, 35 thay vì 53). Kết quả gần như tuyệt đối:
- Bộ phán xét LLM kiểu Ragas: AUROC = 0.57
- Độ tương đồng embedding: AUROC = 0.51
- Mô hình entailment: AUROC = 0.59
- LettuceDetect (span detector): AUROC = 0.58
- MiniCheck (state-of-the-art): AUROC = 0.75
Bốn trên năm phương pháp gần như không nhìn thấy vấn đề. Chỉ có MiniCheck cho thấy tín hiệu khiêm tốn. Còn bộ phán xét LLM thậm chí còn tệ hơn cả tung đồng xu.
Vì Sao Chúng Đều Sai Lầm?
Các phương pháp hiện tại chủ yếu nén câu trả lời thành một vector và đo khoảng cách đến ngữ cảnh. Một câu trả lời 60 từ sai chỉ một chữ số sẽ tạo ra vector gần như giống hệt câu trả lời đúng — độ tương đồng cosine lên tới 0.99. Lỗi tan biến như một giọt mực trong hồ nước.
"Bộ mã hóa câu được huấn luyện với mục tiêu làm sụp đổ các diễn giải (paraphrase) — hai cách nói cùng một ý phải nằm ở cùng một chỗ. Mục tiêu đó khiến retrieval hoạt động, nhưng cũng chính nó vứt bỏ độ lớn (magnitude) — thứ duy nhất phân biệt 1.000 và 10.000."
Các bộ mã hóa tổ chức văn bản theo từ vựng, chủ đề và cấu trúc. Không bao giờ theo chân lý. Trong khi đó, LLM judge lại mắc lỗi khác: mô hình đi kiểm tra có cùng điểm mù với mô hình gây lỗi — nó đọc để tìm sự hợp lý, chứ không phải để so sánh từng con số.
Sơ đồ so khớp từng từ giữa tài liệu nguồn và câu trả lời, cho thấy từ "1,000" không tìm thấy sự hỗ trợ nào và bị điểm 0.00
Hình 1: So khớp từng từ giữa tài liệu nguồn (trái) và câu trả lời (phải). Từ được so khớp theo ngữ nghĩa, số được so sánh theo giá trị sau chuẩn hóa định dạng. Từ "1,000" sai tìm thấy không gì và nhận điểm 0.00 — một báo động rõ ràng, trong khi điểm trung bình 0.79 trông vẫn rất bình thường.
Giải Pháp Cổ Điển Nhất: So Khớp Từng Phần
Khi con người kiểm tra một câu trả lời so với tài liệu, chúng ta không tóm tắt cả hai rồi so sánh bản tóm tắt. Chúng ta lấy từng mảnh của câu trả lời và tìm kiếm nó trong tài liệu: "hóa đơn" — có, "tổng nợ" — có, "1.000" — không có trong tài liệu. So sánh xảy ra ở độ phân giải của lỗi: từ đối từ, để token sai không bao giờ bị làm mờ bởi các token lân cận.
Tác giả đóng gói ý tưởng này thành thư viện mã nguồn mở có tên groundlens — không cần huấn luyện, không cần nhãn, không cần gọi API, chỉ một forward pass của một encoder đông lạnh bạn đã có, cộng thêm một biểu thức chính quy. Mỗi câu trả lời mất khoảng 70 mili giây trên CPU.
Không Có Bộ Phát Hiện Vạn Năng
Khi chạy trên 5 bộ dữ liệu: bộ lỗi sai số tự tạo, RAGTruth QA, HaluEval QA, và hai tập con FinanceBench và PubMedQA của HaluBench, kết quả cho thấy một bức tranh rõ ràng:
Biểu đồ AUROC trên 5 bộ test, cho thấy mỗi phương pháp chỉ thắng ở đúng bộ dữ liệu mà nó được xây dựng cho
Hình 2: AUROC trên 5 bộ test. Mỗi phương pháp thắng ở đúng chỗ mà cấu trúc của nó hướng tới, và thua ở mọi nơi khác. Không có một bộ phát hiện ảo giác vạn năng nào — chỉ có những chuyên gia và ít nhất một lớp lỗi (FinanceBench với giá trị tính toán) mà không một công cụ nào hoạt động.
Đọc bảng theo đường chéo: span detector thắng ở sân nhà, MiniCheck thắng ở bộ paraphrase, LLM judge thắng ở bộ y tế (vì đó là lỗi kết luận sai, không phải sai sự thật). Nhưng ở lỗi sai số — lớp lỗi phổ biến nhất trong tài chính — hầu như không ai thắng.
Con Số Quyết Định Trong Vận Hành
Trong sản xuất, chúng ta không xếp hạng, chúng ta chạy ở một ngưỡng vận hành: "bắt ít nhất 95% câu trả lời sai". Vậy câu hỏi quyết định là: bao nhiêu câu trả lời đúng sẽ bị gắn cờ sai khi yêu cầu độ nhớ (recall) 95%?
Đồ thị mỗi chấm là một phương pháp trên RAGTruth QA: trục ngang là AUROC (hệ số báo cáo), trục dọc là tỷ lệ dương tính giả khi yêu cầu recall 95%
Hình 3: Mỗi chấm là một phương pháp trên RAGTruth QA. Trái sang phải: thứ hạng của nó — con số các bài báo công bố. Dưới lên trên: tỷ lệ câu trả lời đúng bị gắn cờ khi yêu cầu bắt 95% ảo giác — con số mà hàng đợi review phải gánh chịu. Góc bóng mờ dưới cùng bên phải là khu vực "có thể triển khai" — và nó trống rỗng.
Kết quả tốt nhất trên toàn bộ lưới là tỷ lệ dương tính giả 0.65 ở mức recall 95%. Con số cao hơn 0.65 là rủi ro. Hãy tưởng tượng một hệ thống nơi 15% câu trả lời có lỗi: ở recall 95% và tỷ lệ dương tính giả 0.65, bạn sẽ gắn cờ 69.5% tổng lưu lượng. Chỉ 1 trên 5 cờ là lỗi thật, 4 cờ còn lại là công sức đổ sông đổ bể — và bạn vẫn bỏ lọt 1 lỗi trong 20. So với việc rà soát mọi thứ, bạn chỉ mua được 30% giảm khối lượng review với cái giá 5% tỷ lệ bỏ sót.
Xóa Bằng Chứng, Kiểm Tra Lại
Một bộ phát hiện grounding được thiết kế để so sánh câu trả lời với nguồn. Vậy hãy chạy thử nghiệm đối chứng: đưa cho nó câu trả lời mà toàn bộ bằng chứng đã bị xóa sạch, xem nó còn hoạt động được bao nhiêu.
- RAGTruth QA (đúng sân nhà): 0.817 → 0.635 với evidence xóa sạch
- FinanceBench (ngoài phân phối): 0.551 → 0.415 (dưới cả ngẫu nhiên!)
- PubMedQA (ngoài phân phối): 0.525 → 0.480
Trên sân nhà, LettuceDetect giữ 0.635 AUROC mà không cần một mẩu bằng chứng nào: 43% hiệu suất trên ngẫu nhiên của nó không hề cần đến grounding. Nó đã học được dấu vân tay phong cách của những ảo giác trong corpus: độ dài, độ cụ thể, cách diễn đạt. Đó là một đặc trưng thật, nhưng hoàn toàn mang tính địa phương. Ra ngoài phân phối, nó không chỉ mờ dần — nó đảo ngược.
Kết Luận: Ngừng Trao Phán Quyết, Hãy Trao Dấu Chỉ
Không một thứ nào chúng ta đo lường xứng đáng nhận được một "phán quyết" — một khẳng định mang theo tỷ lệ lỗi mà mọi bảng số ở trên cho thấy bạn không thể chi trả. Hãy trao dấu chỉ (marks). Không phải "câu trả lời này sai" mà là "ba từ này là những từ mà nguồn của bạn ủng hộ yếu nhất, và đây là thứ gần nhất trong nguồn cho từng từ đó."
"Một ngưỡng cho bạn biết một câu trả lời tệ, và khi nó sai, bạn phải trả giá. Một danh sách từ chỉ cho bạn biết nơi cần nhìn, và khi nó sai, bạn chỉ mất ba mươi giây nhìn lại."
Groundlens làm điều đó với mục đích không có ngưỡng: pip install "groundlens[encoder]". Đây là một hướng đi đúng — kết hợp sức mạnh ngữ nghĩa của embedding với độ chính xác tuyệt đối của số học — để những hệ thống RAG trong ngân hàng, bệnh viện và doanh nghiệp thực sự đáng tin cậy khi nói về con số.


