GIGO và QIQO trong RAG: Chất lượng đầu ra bắt đầu từ dữ liệu đầu vào

Tóm tắt nhanh

RAG không tự biến một kho tài liệu lộn xộn thành câu trả lời chính xác.

• GIGO — Garbage In, Garbage Out: dữ liệu, truy vấn hoặc tài liệu truy xuất kém sẽ làm tăng nguy cơ tạo ra câu trả lời kém.
• QIQO — Quality In, Quality Out: dữ liệu tốt, retrieval tốt và context rõ ràng tạo điều kiện để mô hình trả lời chính xác hơn.

Tuy nhiên, QIQO không phải lời bảo đảm. Ngay cả khi được cung cấp tài liệu đúng, mô hình vẫn có thể hiểu sai, bỏ sót hoặc tạo ra thông tin không được nguồn hỗ trợ.

1. RAG không phải máy lọc rác

RAG thường được mô tả bằng ba bước:

Câu hỏi → truy xuất tài liệu → LLM tạo câu trả lời

Kiến trúc này giúp mô hình sử dụng kiến thức bên ngoài thay vì chỉ dựa vào thông tin đã học trong tham số. Nghiên cứu nền tảng của Lewis và cộng sự cho thấy RAG có thể tạo nội dung cụ thể và giàu tính thực tế hơn mô hình chỉ sử dụng trí nhớ nội tại.

Nhưng RAG chỉ đưa tài liệu vào context. Nó không mặc định kiểm chứng rằng:

• tài liệu có chính xác hay không;
• tài liệu có còn hiệu lực hay không;
• đoạn được lấy có thực sự trả lời câu hỏi hay không;
• các nguồn có mâu thuẫn với nhau hay không.

Vì vậy, nếu hệ thống lấy nhầm thông tin, LLM có thể diễn đạt thông tin sai đó thành một câu trả lời rất tự nhiên và thuyết phục.

Đó chính là GIGO trong RAG.

2. “Garbage” có thể xuất hiện ở mọi tầng

Kho dữ liệu kém chất lượng

Nếu knowledge base chứa tài liệu cũ, trùng lặp, thiếu nguồn gốc hoặc mâu thuẫn, retriever không có cơ sở tốt để lựa chọn.

Một nghiên cứu về chất lượng dữ liệu trong RAG xác định các vấn đề có thể xuất hiện xuyên suốt quá trình trích xuất, chuyển đổi dữ liệu, tìm kiếm và sinh câu trả lời. Đáng chú ý, nhiều vấn đề hình thành từ những bước đầu tiên rồi tiếp tục lan truyền xuống toàn bộ pipeline.

Ví dụ:

Chính sách hoàn tiền mới đã có hiệu lực, nhưng knowledge base vẫn lưu cả phiên bản cũ mà không có ngày áp dụng.

Retriever có thể lấy đúng chủ đề nhưng sai phiên bản.

Chunking làm mất ngữ cảnh

Một tài liệu đúng vẫn có thể trở thành đầu vào kém nếu bị chia đoạn không hợp lý.

Nếu câu quy định nằm ở một chunk nhưng điều kiện ngoại lệ nằm ở chunk khác, hệ thống có thể chỉ lấy được một nửa sự thật. Khi đó, LLM không hẳn “bịa”; nó đang tổng hợp từ một context bị cắt thiếu.

Vì thế, chất lượng dữ liệu trong RAG không chỉ là nội dung có đúng không, mà còn bao gồm:

• cấu trúc tài liệu;
• metadata;
• kích thước và ranh giới chunk;
• khả năng giữ lại quan hệ giữa các đoạn.

Các khảo sát về RAG cũng xem indexing, retrieval và augmentation là những thành phần cần được tối ưu đồng thời, thay vì chỉ tập trung vào model.

Query kém tạo ra retrieval kém

Retriever tìm tài liệu dựa trên những gì người dùng hỏi, không phải những gì người dùng thực sự đang nghĩ.

Một truy vấn như:

“Chính sách nghỉ thế nào?”

không cho biết người dùng đang hỏi về nghỉ phép năm, nghỉ ốm, nghỉ không lương hay chính sách của quốc gia nào.

Khi query mơ hồ hoặc chứa lỗi nhập liệu, chất lượng retrieval có thể giảm đáng kể. Benchmark QE-RAG cho thấy lỗi chính tả, thiếu từ hoặc sai từ trong câu hỏi là một vấn đề riêng cần được đánh giá khi xây dựng RAG thực tế.

Do đó, query rewriting và query classification thường quan trọng không kém việc lựa chọn embedding model.

Retrieval đúng chủ đề nhưng không chứa đáp án

Similarity cao không đồng nghĩa với usefulness cao.

Một tài liệu có thể sử dụng rất nhiều từ giống câu hỏi nhưng không chứa thông tin cần thiết. Nghiên cứu về đánh giá retrieval cho RAG cho thấy nhãn relevance truyền thống chỉ có tương quan hạn chế với hiệu quả cuối cùng của hệ thống. Một tài liệu “liên quan” theo công cụ tìm kiếm chưa chắc giúp LLM trả lời đúng.

Đây là lỗi phổ biến:

Retriever lấy được tài liệu nói về “quy trình hoàn tiền”, nhưng câu hỏi lại cần “thời gian tiền về tài khoản”.

Chủ đề đúng, đáp án vẫn thiếu.

3. Nhiều context hơn chưa chắc tốt hơn

Một cách xử lý quen thuộc là tăng top_k: lấy thêm tài liệu rồi hy vọng đáp án nằm đâu đó trong context.

Nhưng context dài hơn có thể tạo thêm nhiễu.

Nghiên cứu Lost in the Middle cho thấy khả năng sử dụng thông tin của mô hình phụ thuộc vào vị trí của thông tin trong context. Nội dung quan trọng nằm giữa một context dài có thể bị khai thác kém hơn nội dung nằm ở đầu hoặc cuối.

RAGAS vì vậy xem context relevance là một tiêu chí quan trọng: context nên tập trung và chứa càng ít thông tin không cần thiết càng tốt.

Mục tiêu không phải là:

Lấy thật nhiều tài liệu.

Mà là:

Lấy đủ bằng chứng cần thiết, ít trùng lặp và ít nhiễu nhất có thể.

4. QIQO không có nghĩa “đầu vào tốt chắc chắn đầu ra tốt”

QIQO nên được hiểu là một nguyên tắc thiết kế:

Đầu vào càng đáng tin cậy, xác suất tạo ra đầu ra tốt càng cao.

Nó không phải một phương trình tất định.

RAGTruth đã ghi nhận gần 18.000 câu trả lời được tạo bằng RAG và cho thấy mô hình vẫn có thể sinh ra các phát biểu không được context hỗ trợ hoặc mâu thuẫn với tài liệu đã truy xuất.

Nói cách khác:

Quality In tạo điều kiện cho Quality Out, nhưng vẫn cần kiểm soát quá trình generation.

Một hệ thống tốt phải đánh giá riêng:

• Context precision: tài liệu lấy về có thực sự hữu ích không?
• Context recall: đã lấy đủ bằng chứng cần thiết chưa?
• Faithfulness: câu trả lời có bám sát context không?
• Answer relevance: câu trả lời có giải quyết đúng câu hỏi không?

Đây cũng là cách các framework như RAGAS tách retrieval quality khỏi generation quality.

5. GIGO trong RAG không hoàn toàn tuyến tính

Không phải mọi tài liệu nhiễu đều gây ảnh hưởng giống nhau.

Một nghiên cứu khá thú vị cho thấy tài liệu có vẻ liên quan nhưng không chứa đáp án có thể gây hại nhiều hơn tài liệu hoàn toàn ngẫu nhiên. Trong một số thiết lập thử nghiệm, việc thêm tài liệu ngẫu nhiên thậm chí còn cải thiện độ chính xác.

Điều này không phủ nhận GIGO. Nó cho thấy “garbage” trong RAG không thể chỉ được định nghĩa bằng similarity score.

Chất lượng của một tài liệu phải được đánh giá dựa trên câu hỏi thực tế:

Tài liệu này có giúp mô hình tạo ra câu trả lời đúng và có căn cứ hay không?

6. Từ GIGO sang QIQO trong production

Một pipeline RAG đáng tin cậy nên có các lớp kiểm soát sau:

Trước retrieval

• loại tài liệu lỗi thời và trùng lặp;
• lưu source, ngày cập nhật và phiên bản;
• chunk theo cấu trúc nội dung;
• chuẩn hóa hoặc viết lại query khi cần thiết.

Sau retrieval

• sử dụng reranker;
• lọc đoạn không chứa bằng chứng;
• loại nội dung trùng lặp;
• phát hiện nguồn mâu thuẫn;
• không ép hệ thống phải trả lời khi thiếu dữ liệu.

Sau generation

• kiểm tra từng claim với context;
• bắt buộc citation ở các nội dung quan trọng;
• đo faithfulness và answer relevance;
• chuyển cho con người kiểm duyệt trong các tác vụ rủi ro cao.

Các phương pháp như Corrective RAG bổ sung một bộ đánh giá retrieval để phát hiện tài liệu kém chất lượng và kích hoạt hành động sửa chữa. Self-RAG tiến thêm một bước bằng cách để mô hình tự quyết định khi nào cần retrieval và tự đánh giá bằng chứng cũng như câu trả lời của mình.

Kết luận

Trong RAG, chất lượng câu trả lời không bắt đầu từ prompt cuối cùng. Nó bắt đầu từ kho dữ liệu, metadata, chunking, query và tài liệu được truy xuất.

GIGO nhắc chúng ta rằng LLM không thể cứu một pipeline dữ liệu yếu.

QIQO nhắc chúng ta rằng muốn cải thiện đầu ra, trước tiên phải cải thiện chất lượng của từng đầu vào.

Công thức thực tế có thể viết ngắn gọn như sau:

Clean corpus + đúng query + đủ bằng chứng + context ít nhiễu + kiểm tra faithfulness = RAG đáng tin cậy hơn.

Không phải cứ đổi sang model lớn hơn là hệ thống sẽ tốt hơn. Đôi khi, thứ cần sửa trước tiên chỉ là tài liệu mà model đang được phép đọc.

References

[1] Patrick Lewis et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. arXiv:2005.11401.

[2] Yunfan Gao et al. Retrieval-Augmented Generation for Large Language Models: A Survey. 2023. arXiv:2312.10997.

[3] Nelson F. Liu et al. Lost in the Middle: How Language Models Use Long Contexts. 2023. arXiv:2307.03172.

[4] Shahul Es et al. RAGAS: Automated Evaluation of Retrieval-Augmented Generation. 2023. arXiv:2309.15217.