Grounding Contract: Hợp Đồng Chống Hallucination Trong RAG
Retrieval không tự động chống được hallucination. Grounding (đúng với context) và factuality (đúng với sự thật) là 2 trục khác nhau - cần 2 cơ chế kiểm soát khác nhau.
Thuộc chuỗi bài: RAG Pipeline: 5 Quyết Định Định Hình Chất Lượng Câu Trả Lời
Gắn thêm một retriever vào LLM và ta dễ tưởng rằng hallucination đã được giải quyết - dù sao model giờ cũng có tài liệu thật để dựa vào thay vì chỉ dữ liệu huấn luyện. Nhưng chưa giải quyết được đâu. Một model có context liên quan trong tay vẫn có thể phớt lờ nó, trộn lẫn nó với kiến thức nền không liên quan, hoặc trả lời những câu hỏi mà context chưa bao giờ đề cập tới - tất cả đều được nói ra với đúng mức tự tin như khi nó trả lời đúng.
Grounding là tính chất của một câu trả lời có thể truy vết ngược lại được về đúng context đã cấp cho nó. Đây là điều kiện cần cho một hệ RAG đáng tin cậy, nhưng tự bản thân nó chưa đủ - và coi nó là toàn bộ giải pháp chính là chỗ nhiều nỗ lực chống hallucination âm thầm thất bại.
Sơ Đồ Hợp Đồng Grounding
Retrieval Một Mình Không Chống Được Hallucination
Đưa cho model context liên quan không ép buộc nó chỉ dùng đúng context đó - không có gì trong kiến trúc của một pipeline RAG ngăn model quay về dùng kiến thức tham số (parametric knowledge) từ dữ liệu huấn luyện, nhất là khi context lấy về không đầy đủ hoặc chưa trả lời trọn vẹn câu hỏi. Nghiên cứu của Zep về giảm hallucination cho LLM nói rõ điều này: grounding là điều kiện cần cho việc generate đáng tin cậy, không phải điều kiện đủ. Nếu không có một chỉ dẫn tường minh ràng buộc model chỉ dùng context được cấp, retrieval chỉ đơn giản đưa cho model thêm nguyên liệu để tuỳ chọn sử dụng - chứ không buộc model chỉ được dùng đúng nguyên liệu đó.
Grounding Và Đúng Sự Thật Là Hai Trục Khác Nhau
Nghiên cứu Contextual Retrieval của Anthropic đưa ra một sự phân biệt đáng ghi nhớ: factuality (câu trả lời có đúng với thế giới thật không?) và grounding/faithfulness (câu trả lời có được context được cấp hỗ trợ không?) là hai tính chất tách biệt, và một câu trả lời có thể rơi vào bất kỳ tổ hợp nào của hai trục này một cách độc lập. Một câu trả lời grounded-nhưng-sai nghĩa là retrieval và generation của bạn hoạt động đúng như thiết kế, nhưng bản thân tài liệu nguồn đã lỗi thời hoặc sai - đây là vấn đề chất lượng dữ liệu. Một câu trả lời đúng-nhưng-không-grounded trông ổn trên bề mặt nhưng nghĩa là model đã vươn ra ngoài context bạn cấp, điều này vô hình cho tới đúng lần nó vươn tới thứ sai. Hai failure mode khác nhau, hai cách sửa khác nhau - gộp chung chúng lại nghĩa là đang sửa sai chỗ.
Vì Sao "Chỉ Trả Lời Từ Context" Phải Là Một Chỉ Dẫn Tường Minh
Dễ nghĩ rằng một model được huấn luyện tốt sẽ tự nhiên bám sát vào những gì được cấp, nhưng hướng dẫn của Zep coi chỉ dẫn "chỉ trả lời từ context được cấp" là một bước bắt buộc, không phải một tinh chỉnh tuỳ chọn. Nếu không bị ràng buộc, một model đủ năng lực thường cố gắng hữu ích tối đa - lấp đầy khoảng trống trong context chưa đầy đủ bằng suy luận nghe có vẻ hợp lý thay vì nói "thông tin được cấp không đề cập tới điều này". Bản năng đó thường là một điểm mạnh; nhưng trong một pipeline RAG nơi mọi claim cần audit được ngược về nguồn, đó chính xác là hành vi cần tắt đi một cách tường minh.
Ma Trận Grounding × Đúng Sự Thật
"Chính sách hoàn tiền: khách hàng có 30 ngày kể từ ngày mua để yêu cầu hoàn tiền." (tài liệu hiện hành)
Tôi có bao nhiêu ngày để yêu cầu hoàn tiền?
Bạn có 30 ngày kể từ ngày mua để yêu cầu hoàn tiền.
Câu trả lời khớp đúng với context, và context bản thân nó cũng đúng với chính sách thật - đây là trường hợp lý tưởng, cả 2 trục đều đạt.
Kiểm Tra Grounding Ở Mức Claim, Không Phải Mức Cả Câu Trả Lời
Một phán quyết nhị phân "câu trả lời này có grounded không" bỏ lỡ trường hợp phổ biến: một câu trả lời phần lớn grounded nhưng lọt vào đúng một chi tiết không grounded. Đơn vị phân tích hữu ích hơn là claim nguyên tử (atomic claim): tách một câu trả lời được sinh ra thành từng khẳng định sự thật riêng lẻ, rồi kiểm tra từng khẳng định một cách độc lập với context đã lấy về. Cách này tốn công hơn một lần kiểm tra pass/fail cho cả câu trả lời, nhưng đó là cách duy nhất bắt được đúng failure mode nơi model grounding đúng 9 trên 10 claim rồi âm thầm bịa ra claim thứ 10 - loại lỗi mà một lần review cả câu trả lời nhiều khả năng bỏ sót hoàn toàn.
Một Lỗi Grounding Thật Sự Trông Như Thế Nào Trong Production
Trên thực tế, các claim không grounded hiếm khi tự lộ diện. Chúng được viết ra với đúng độ trôi chảy và tự tin như các claim grounded, thường nằm ngay cạnh thông tin chính xác trong cùng một câu trả lời, và có xu hướng xuất hiện đúng ở những câu hỏi mà context lấy về mỏng nhất - cũng chính là nơi một team ít có khả năng đã review thủ công output nhất. Đây là lý do grounding cần một cơ chế kiểm tra có hệ thống thay vì spot-check vài transcript ngẫu nhiên: lỗi tập trung đúng vào những trường hợp dễ bị bỏ qua nhất.
Tỷ Lệ Claim Được Support Theo Từng Lớp Kiểm Soát
Grounding score = (số claim được context hỗ trợ) / (tổng số claim trong câu trả lời)
Ví dụ minh hoạ trên một câu trả lời có 5 claim - không phải số đo từ một benchmark cụ thể.
Model tự do trộn kiến thức nền vào câu trả lời khi context thiếu chi tiết - một số claim đúng nhưng không có gì trong context xác nhận được.
Chỉ dẫn giảm đáng kể việc model tự bịa thêm, nhưng không loại bỏ hoàn toàn - vẫn còn claim lọt qua không được context hỗ trợ.
Câu trả lời có claim không được support bị chặn hoặc gắn cờ trước khi tới người dùng, thay vì chỉ trông cậy vào việc model tự giác tuân thủ chỉ dẫn.
Chỉ dẫn 'chỉ trả lời từ context' giảm hallucination nhưng không đảm bảo 0% - kiểm tra claim-level tự động là lớp phòng vệ thứ hai, không phải tùy chọn thay thế.Grounding ≠ Đúng Sự Thật
Grounding score đo việc câu trả lời có trung thành với context hay không - nó không đo việc context đó có đúng với thế giới thật hay không. Một câu trả lời đạt 5/5 grounding vẫn có thể sai nếu bản thân context đã lỗi thời (xem ma trận grounding × đúng sự thật ở trên).
Dựng Hợp Đồng Grounding Vào Pipeline Của Bạn
Một hợp đồng grounding có 3 lớp, và bỏ qua bất kỳ lớp nào cũng làm yếu toàn bộ hệ thống: một chỉ dẫn tường minh ràng buộc generation chỉ dùng context được cấp (và nói rõ model nên trả lời gì khi context không đủ, thay vì để trường hợp đó không được định nghĩa); một bước kiểm tra tự động ở mức claim chạy trước khi câu trả lời tới người dùng, gắn cờ hoặc chặn các câu trả lời có claim không được support; và một vòng phản hồi ngược về error analysis, vì một đợt tăng đột biến câu trả lời không grounded ở một loại câu hỏi cụ thể thường trỏ tới một khoảng trống retrieval - tài liệu đúng đơn giản là chưa từng có mặt - chứ không phải một vấn đề generation cần sửa bằng prompt engineering.
Những Sai Lầm Thường Gặp Về Grounding
Một vài sai lầm lặp đi lặp lại: cho rằng chỉ cần retrieval là đủ chống hallucination và bỏ qua hẳn chỉ dẫn context-only tường minh; coi một câu trả lời grounded là mặc nhiên đúng mà không bao giờ kiểm tra bản thân context nguồn có chính xác hay còn hiện hành hay không; chạy kiểm tra grounding ở mức cả câu trả lời và bỏ lỡ lỗi từng claim đơn lẻ chôn trong một câu trả lời nhìn chung ổn; và coi một đợt tăng câu trả lời không grounded là vấn đề prompt trong khi thực ra đó là tín hiệu cho thấy retrieval không đưa lên đúng tài liệu cho loại câu hỏi đó. Grounding là một hợp đồng được thực thi bằng chỉ dẫn tường minh và kiểm tra có hệ thống - không phải một tính chất tự nhiên xuất hiện chỉ vì đã gắn thêm retriever vào pipeline.