Lỗi thường gặp & hướng nâng cao
Bảng chẩn đoán dùng khi hệ thống RAG hoạt động không như mong đợi, và những hướng mở rộng khi RAG cơ bản không còn đủ.
Cách chẩn đoán có hệ thống
Với mỗi câu trả lời sai, đi theo đúng thứ tự của pipeline và dừng ở chữ “không” đầu tiên:
- Tài liệu có chứa đáp án không? Nếu không — vấn đề là dữ liệu, không phải RAG.
- Đáp án có nằm trọn trong một chunk không? Nếu bị cắt đôi hoặc thiếu ngữ cảnh — sửa chunking.
- Chunk đó có được truy xuất (trong top-k) không? Nếu không — sửa truy xuất: hybrid, embedding, biến đổi câu hỏi.
- Chunk đó có vào prompt không? Có thể bị rerank loại, bị ngưỡng loại, hoặc bị cắt vì ngân sách token.
- Có trong prompt mà vẫn trả lời sai? Sửa prompt, thứ tự ngữ cảnh, hoặc đổi mô hình sinh.
Bảng triệu chứng → nguyên nhân → cách sửa
| Triệu chứng | Nguyên nhân thường gặp | Cách sửa |
|---|---|---|
| Trả lời “không biết” dù tài liệu có | Truy xuất bỏ sót; câu hỏi dùng từ khác tài liệu; mã/tên riêng | Hybrid search, thêm tiêu đề vào chunk, multi-query, kiểm tra ngưỡng quá cao |
| Trả lời sai nhưng nghe rất thuyết phục | Đoạn nhiễu gần nghĩa; mô hình suy diễn vượt nguồn | Rerank, giảm k, prompt buộc trích dẫn, đo faithfulness |
| Trích dẫn tài liệu cũ, hết hiệu lực | Nhiều phiên bản cùng tồn tại; index không cập nhật | Metadata phiên bản/ngày hiệu lực, lọc bản mới nhất, đồng bộ index khi tài liệu đổi |
| Câu trả lời thiếu một nửa | Thông tin trải trên nhiều chunk; bảng bị cắt | Chunk theo cấu trúc, cha–con, gộp đoạn liền kề, tăng k có kiểm soát |
| Người dùng thấy thông tin không được phép xem | Không lọc quyền lúc truy xuất; cache dùng chung | Lọc ACL trong truy vấn vector store, khoá cache theo quyền, kiểm thử phân quyền trong CI |
| Câu “so sánh”, “tổng hợp”, “liệt kê tất cả” trả lời kém | Top-k đoạn không bao phủ được toàn bộ kho | Tách câu hỏi, truy xuất nhiều bước, dữ liệu có cấu trúc + SQL, hoặc GraphRAG |
| Chậm, tốn tiền | k lớn, ngữ cảnh dài, nhiều bước LLM phụ | Rerank rồi giảm k, ngân sách token, cache, mô hình nhỏ cho bước phụ, streaming |
| Kết quả một ngôn ngữ kém hẳn ngôn ngữ khác | Mô hình embedding/rerank yếu ở ngôn ngữ đó; chuẩn hoá Unicode khác nhau giữa câu hỏi và chỉ mục | Chọn mô hình đa ngôn ngữ đã đo trên chính câu hỏi tiếng đó; đưa cả hai phía về NFC; tách từ phù hợp cho BM25 |
| Hành xử lạ khi gặp một số tài liệu | Prompt injection nằm trong nội dung truy xuất | Bọc ngữ cảnh, chỉ dẫn “dữ liệu không phải lệnh”, kiểm soát nguồn, giới hạn quyền hành động |
| Các nguồn mâu thuẫn nhau | Tài liệu chưa đồng bộ giữa phòng ban | Ưu tiên nguồn chính thức/mới hơn qua metadata; cho mô hình nêu rõ mâu thuẫn kèm nguồn |
Hướng nâng cao
Contextual retrieval
Trước khi embed, dùng LLM viết một câu tóm tắt ngữ cảnh cho từng chunk (“Đoạn này thuộc mục X của tài liệu Y, nói về…”) rồi ghép vào chunk. Tốn chi phí lập chỉ mục một lần, đổi lại truy xuất chính xác hơn với các đoạn khó hiểu khi đứng riêng.
Agentic RAG
Thay vì một lượt “truy xuất → trả lời”, LLM tự quyết định: có cần tìm không, tìm gì, tìm ở nguồn nào (tài liệu, SQL, API), đọc kết quả rồi tìm tiếp. Mạnh với câu hỏi nhiều bước, nhưng khó kiểm soát độ trễ, chi phí và khó đánh giá hơn.
GraphRAG
Trích các thực thể và quan hệ từ tài liệu thành đồ thị tri thức, kèm tóm tắt theo cụm chủ đề. Hữu ích cho câu hỏi tổng quan cả kho (“các chủ đề chính trong phản hồi khách hàng?”) mà top-k đoạn văn không trả lời được.
Dữ liệu có cấu trúc
Với số liệu trong cơ sở dữ liệu, cho LLM sinh truy vấn SQL (có kiểm soát, chỉ đọc, giới hạn bảng) thường chính xác hơn nhiều so với embed các bảng số.
Tổng kết khoá học
Sạch, có cấu trúc, có metadata
Chất lượng đầu vào đặt giới hạn trên cho mọi thứ phía sau.
Hybrid + rerank + lọc quyền
Nơi quyết định phần lớn câu trả lời đúng hay sai.
Dựa nguồn, trích dẫn, dám từ chối
Prompt rõ ranh giới dữ liệu và chỉ dẫn.
Đo từng tầng, mọi thay đổi
Bộ câu hỏi vàng và theo dõi production.