RAG trả lời “Không có trong tài liệu” phải đưa ra bốn loại bằng chứng
Trong các hệ thống RAG doanh nghiệp, câu trả lời “không tìm thấy” không được phép mơ hồ — nó phải được chứng minh bằng bốn loại bằng chứng tương ứng với bốn thành phần của pipeline. Bài viết phân tích cách biến một câu trả lời phủ định khô khan thành một chuỗi bằng chứng kiểm chứng được: báo cáo độ phủ tài liệu, bộ từ khóa từ chuyên gia, kết quả quét toàn bộ văn bản, và đoạn trích gần nhất kèm lý do vì sao không phải là câu trả lời.
RAG trả lời “Không có trong tài liệu” phải đưa ra bốn loại bằng chứng
Câu trả lời hữu ích nhất mà một hệ thống RAG có thể đưa ra đôi khi lại là “điều đó không có trong tài liệu này.” Nhưng khi được hỏi, mô hình thường có xu hướng trả lời bừa, vì vậy câu trả lời “không tìm thấy” trung thực phải được xây dựng có chủ đích, chứ không phải hy vọng là nó sẽ tự xảy ra. Việc khiến hệ thống nói “không” — và nói đúng khi nó làm vậy — khó hơn nhiều so với việc khiến nó nói “có.”
Bài viết này là một phần bổ sung trong series Enterprise Document Intelligence, series xây dựng một hệ thống RAG doanh nghiệp từ bốn thành phần (brick). Nó giải thích cho câu trả lời “tôi không biết”: một câu trả lời sai một cách tự tin là một lỗi (bug), một câu trả lời “không có câu trả lời” trống rỗng cũng tệ gần như vậy, và mỗi thành phần trong bốn thành phần cần đưa ra một loại bằng chứng tương ứng.
Sơ đồ minh họa pipeline RAG bốn thành phần và vai trò của câu trả lời phủ định
Vấn đề: “Không tìm thấy” là một phán quyết, không phải một lời xin lỗi
Hãy hỏi chatbot của một doanh nghiệp: “AI tiêu thụ bao nhiêu điện năng trên toàn cầu?” và nó sẽ trả lời: “Tôi không thể tìm thấy câu trả lời trong tài liệu này.” Hỏi lại với cách diễn đạt khác, kết quả vẫn như cũ. Lúc này, hầu hết người dùng sẽ bỏ cuộc và chuyển sang Google.
Hệ thống đã làm đúng — tài liệu nó vận hành là báo cáo Commodity Markets Outlook (tháng 4/2025) của Ngân hàng Thế giới, một báo cáo kinh tế 63 trang về giá dầu, nông sản và kim loại. Mức tiêu thụ điện của AI không hề có trong đó. Không có câu trả lời nào để tìm. Hệ thống đã không nói dối.
Nhưng người dùng lại không học được điều gì hữu ích. Họ không thể biết liệu pipeline đã tìm kiếm ở mọi nơi cần thiết hay chỉ bỏ cuộc sau một lần tìm kiếm embedding nông cạn. “Tôi không thể tìm thấy câu trả lời” là một phán quyết cần phải đi kèm với một sự bảo vệ — nếu không, nó bị đọc như một sự thất bại, chứ không phải một sự thật.
Bốn thành phần, bốn loại bằng chứng — không thể thiếu bất kỳ loại nào
Lập luận chính được nén trong một bảng đơn giản:
| Thành phần | Bằng chứng cần đưa ra | Vai trò của nó |
|---|---|---|
| Parsing (Trích xuất cấu trúc) | Báo cáo tổng hợp: tổng số trang, số trang có chữ, số ảnh đã OCR, số tham chiếu chéo chưa giải quyết | Chứng minh pipeline đã “đọc” toàn bộ tài liệu, không bỏ sót phần nào |
| Question Parsing (Phân tích câu hỏi) | Bộ từ khóa đã được chuyên gia phê duyệt, bao gồm đầy đủ biến thể, từ đồng nghĩa | Chứng minh hệ thống đã tìm kiếm đúng “ngôn ngữ” mà câu trả lời có thể tồn tại |
| Retrieval (Truy hồi) | Danh sách đầy đủ mọi dòng văn bản khớp với từ khóa trên từng trang — không phải top-k, không chấm điểm | Bằng chứng trực tiếp cho thấy không có đoạn văn nào chứa câu trả lời, hoặc nếu có thì ở xa nhau |
| Generation (Sinh phản hồi) | Lược đồ phản hồi có cấu trúc với lý do, danh sách các đoạn gần nhất và giải thích vì sao chúng không phải là câu trả lời | Biến “không có câu trả lời” thành một phản hồi hữu ích, kiểm chứng được |
Phần còn lại của bài viết đi qua từng thành phần theo thứ tự, sau đó gắn chúng lại với nhau trong tình huống báo cáo CMO / câu hỏi về tiêu thụ điện của AI.
Bảng chi tiết bốn loại bằng chứng cần thiết cho một câu trả lời phủ định có thể bảo vệ được
Parsing (Trích xuất cấu trúc): Bảng dữ liệu quan hệ chính là bằng chứng
Chi phí của một lần trích xuất thiếu sót là không đối xứng. Dương tính giả (trích xuất nhiễu) khiến quá trình truy hồi lộn xộn hơn nhưng có thể sửa chữa được ở giai đoạn sau. Âm tính giả (không trích xuất được một token thực sự) lại im lặng: phán quyết “không có câu trả lời” sẽ trông có vẻ đúng, nhưng nó sai. Câu trả lời tồn tại; pipeline chỉ đơn giản là không thấy nó.
Tin tốt là thành phần parsing đã tạo ra chính xác dữ liệu mà một tuyên bố vắng mặt cần. Đầu ra của hàm parse_pdf không phải là một bức tường chữ; nó là một tập hợp nhỏ các DataFrame quan hệ. line_df là bảng trung tâm: mỗi dòng văn bản trên toàn tài liệu, kèm số trang, tọa độ bounding box và loại dòng đã phát hiện (văn xuôi, tiêu đề, hàng bảng, chú thích hình).
Để đưa ra phán quyết “không có câu trả lời”, chúng ta không viết hàm parsing mới. Chúng ta tổng hợp dữ liệu từ các bảng đã tồn tại sẵn:
out = parse_pdf(pdf_path) # tạo line_df, image_df, page_df, toc_df, ...
parse_coverage = {
"pages_total": len(out["page_df"]),
"pages_with_text": out["line_df"]["page_num"].nunique(),
"images_total": len(out["image_df"]),
"toc_entries": len(out["toc_df"]),
"cross_refs_total": len(out["cross_ref_df"]),
"objects_registered": len(out["object_registry"]),
}
Với báo cáo CMO tháng 4/2025: 63 trang, tất cả đều có chữ, 426 hình ảnh được đăng ký, 9 mục lục, 76 tham chiếu chéo. Các con số này định danh các bề mặt mà một tuyên bố vắng mặt phải rà soát.
Ba nơi mà một tuyên bố “không có” vẫn cần kiểm tra ngoài line_df:
- Hình ảnh chứa chữ: Biểu đồ thường chứa nhãn trục và chú giải dưới dạng chữ trong ảnh, không phải ký tự văn bản.
image_dfđăng ký mọi hình ảnh; một bước OCR sẽ thêm cộtocr_textvào bảng này. Báo cáo độ phủ cần ghi rõ đã OCR bao nhiêu hình. - Bảng dữ liệu: Một con số trong ô của bảng được phân tích với các ô xung quanh cùng hàng, không liên quan đến từ phía trên trang.
object_registryđánh dấu trang nào chứa bảng để truy hồi có thể quét theo cột. - Tham chiếu chéo chưa giải quyết: Mọi tham chiếu “xem phụ lục B”, “hình 3.D” đều nằm trong
cross_ref_df. Nếu mục tiêu không tồn tại trongobject_registry, đó là một lỗ hổng — có thể câu trả lời đang ẩn nấp ở đó.
Question Parsing (Phân tích câu hỏi): Liệt kê đầy đủ từ vựng
Bước truy hồi chỉ tốt bằng những từ khóa mà nó quét. Nếu chuyên gia liệt kê “AI” nhưng quên mất “trí tuệ nhân tạo” (artificial intelligence), việc truy hồi sẽ bỏ sót mọi dòng diễn đạt khái niệm bằng chữ đầy đủ.
Chuyên gia biết từ vựng của họ
Trong RAG doanh nghiệp, chuyên gia hầu như luôn biết từ khóa của lĩnh vực mình. Đây là trường hợp đơn giản và bao phủ hầu hết câu hỏi. Họ liệt kê khái niệm mà câu trả lời sẽ nhắc đến, và với mỗi khái niệm, họ liệt kê các biến thể: từ đồng nghĩa, viết tắt, từ viết tắt, dạng tiếng Anh/Pháp/Đức nếu kho ngữ liệu đa ngôn ngữ.
Ví dụ cho câu hỏi CMO / tiêu thụ điện AI:
| Khái niệm | Biến thể |
|---|---|
| AI | AI, artificial intelligence, machine learning, deep learning, neural network, GenAI, generative AI, LLM, large language model |
| Tiêu thụ điện | electricity, power consumption, energy use, kWh, MWh, TWh, electrical load, power demand, electricity demand |
| Trung tâm dữ liệu | data center, data centre, datacenter, server farm, hyperscaler, cloud infrastructure |
Đây chính là lược đồ concept_keywords_df — cấu trúc dữ liệu tương tự điều khiển việc truy hồi thông thường cũng điều khiển tuyên bố vắng mặt. Chữ ký là giống hệt nhau; chỉ có cách diễn giải kết quả thay đổi.
Phân cụm khái niệm (Concept Clustering) như một lưới an toàn
Trường hợp hiếm gặp là chuyên gia không chắc mình đã liệt kê đủ mọi biến thể. Lưới an toàn mang tính thuật toán: phân cụm token trong kho ngữ liệu theo độ tương đồng embedding, sau đó phơi bày các cụm mà từ khóa của chuyên gia nằm trong đó, và hỏi xem có thành viên cụm nào nên được thêm vào.
Đầu ra là một danh sách đề xuất, không phải một quyết định cuối cùng. Chuyên gia quyết định thêm gì. Thuật toán phân cụm chỉ hé lộ điều chuyên gia có thể chưa nghĩ tới; chuyên gia là người xác nhận những gì thực sự thuộc về bộ từ khóa.
Retrieval (Truy hồi): Quét toàn bộ, không phải lấy top-k
Với một câu hỏi bình thường, truy hồi trả về top-k: vài trang hoặc dòng có khả năng chứa câu trả lời nhất. Với một tuyên bố vắng mặt, cách tiếp cận này thất bại. Hệ thống không thể chứng minh câu trả lời không tồn tại bằng cách chỉ nhìn vào 10 trang quan trọng nhất. Nó phải nhìn vào mọi trang có nhắc đến bất kỳ khái niệm nào trong danh sách.
Hàm quét thay đổi hình dạng: trả về một DataFrame, không phải danh sách xếp hạng. Mỗi dòng là một bằng chứng: “Trên trang P, dòng L, biến thể V của khái niệm C được tìm thấy trong đoạn trích S.” Độ lớn của kết quả quyết định bản chất phán quyết:
- Không có dòng nào cho một khái niệm → bằng chứng mạnh rằng tài liệu hoàn toàn không đề cập khái niệm đó.
- Nhiều dòng nhưng không bao giờ cùng xuất hiện → bằng chứng trung bình: các khái niệm tồn tại nhưng không có đoạn văn nào nói về giao điểm của chúng.
- Các dòng cùng xuất hiện → bằng chứng yếu về sự vắng mặt. Bước tạo sinh sẽ phải nhìn vào các đoạn trích và quyết định liệu chúng có trả lời câu hỏi hay chỉ chạm đến nó.
Với báo cáo CMO tháng 4/2025, kết quả là rõ ràng. Quét toàn bộ 7.829 dòng của báo cáo: không có một kết quả trùng khớp nào cho khái niệm AI, chỉ một vài kết quả rải rác cho “điện” ở trang 30-31, và không có bất kỳ sự trùng lặp nào giữa các khái niệm — điện ở trang 30-31 không liên quan đến AI ở bất kỳ đâu.
Generation (Sinh phản hồi): Phản hồi “không trả lời” có cấu trúc kèm lý do
Thành phần cuối cùng nhận báo cáo độ phủ parsing, bộ từ khóa đã xác thực và danh sách kết quả quét, biến chúng thành phản hồi thực sự người dùng thấy. Lược đồ dữ liệu phản chiếu AnswerWithEvidence, nhưng các trường hoạt động khác đi.
Trường hợp báo cáo CMO / tiêu thụ điện AI, mô hình sinh ra một JSON có cấu trúc với đầy đủ thông tin. Người đọc khi nhận được phản hồi này sẽ học được ba điều cùng lúc:
- Hệ thống đã tìm kiếm “AI” dưới chín tên gọi khác nhau và không tìm thấy một kết quả nào trong toàn bộ 63 trang.
- Có một đoạn văn liên quan đến điện, nhưng nó nói về nhu cầu điện do than đá của Ấn Độ, không phải về AI.
- Nếu người dùng muốn câu trả lời thực sự, báo cáo CMO là kho tài liệu sai để hỏi — họ nên chuyển sang báo cáo IEA “Electricity 2024”.
Câu trả lời “không” lúc này trở thành một phản hồi hữu ích.
Mô tả cách một phản hồi “không có câu trả lời” có cấu trúc giúp người dùng hiểu được lý do và định hướng tiếp theo
Nơi khung này dừng lại: Ba trường hợp ranh giới
Khung trên không xử lý mượt mà ba trường hợp, xếp theo thứ tự quan trọng:
Câu trả lời một phần: Một câu hỏi có thể có một phần câu trả lời trong kho tài liệu và một phần nằm ngoài. Phản hồi đúng không phải là một “có” tự tin hay một “không” sạch sẽ; nó là một câu trả lời một phần có cấu trúc, cho thấy những gì đã tìm được và nói rõ những gì chưa tìm thấy.
Câu hỏi mơ hồ: Hỏi “Còn về độ phủ thì sao?” mà không có ngữ cảnh — hệ thống không thể quét vì không có tập khái niệm xác định. Phản hồi đúng là một yêu cầu làm rõ, không phải một câu trả lời “không”.
Câu hỏi thù địch hoặc ngoài phạm vi: “Ý nghĩa cuộc sống là gì?” trên một kho tài liệu về chính sách bảo hiểm. Hệ thống có thể nói “không trả lời được” một cách chính xác, nhưng việc bỏ công tạo báo cáo độ phủ parsing và danh sách đoạn trích gần nhất là lãng phí.
Các trường hợp này chia sẻ một cấu trúc chung: lược đồ “không trả lời” ở trên là hình dạng đúng cho các tuyên bố vắng mặt, nhưng nó không phải là hình dạng đúng cho mọi đầu ra “tôi không thể giúp.” Việc coi nó như một trong ba trạng thái (có / một phần / không) sẽ xử lý sự biến thiên một cách gọn gàng.
Kết luận: Kỷ luật tương tự, trên cùng bốn thành phần
Một câu trả lời “không” đáng tin cậy không phải là một câu duy nhất; nó là một chuỗi bằng chứng mà bốn thành phần tạo ra cùng nhau. Parsing báo cáo độ phủ, question parsing báo cáo bộ từ khóa chuyên gia, retrieval báo cáo kết quả quét, generation báo cáo đoạn trích gần nhất và lý do vì sao nó không trả lời. Người dùng thấy được công việc đã làm và có thể tranh luận về từng bước — về parsing, về bộ từ khóa, về đoạn trích gần nhất.
Điểm lớn hơn mang tính đối xứng với phần còn lại của series. Câu trả lời “có” có thể kiểm chứng được khi lược đồ buộc mô hình trích dẫn bằng chứng của nó; câu trả lời “không” có thể kiểm chứng được khi lược đồ buộc pipeline phơi bày quá trình tìm kiếm của chính nó. Đó là cùng một kỷ luật trên cùng bốn thành phần, và cả hai đầu ra đều có cấu trúc rõ ràng — đây chính là điều tạo nên sự khác biệt giữa một hệ thống RAG “hữu ích khi nó biết” và một hệ thống “đáng tin cậy ngay cả khi nó không biết.”
