Những bài học chưa được dạy về RAG: Cosine Similarity không phải là nền tảng duy nhất

Trong thế giới của các mô hình ngôn ngữ lớn (LLM), kiến trúc RAG (Retrieval-Augmented Generation) thường được mặc định là: nhúng (embed) câu hỏi, trả về top-k kết quả dựa trên độ tương đồng Cosine, và tùy chọn rerank. Tuy nhiên, bài viết này từ Towards Data Science đưa ra một quan điểm hoàn toàn trái ngược: Retrieval (truy xuất) thực chất là bài toán lọc dữ liệu trên các bảng cấu trúc, không phải là tìm kiếm văn bản thuần túy.

Pipeline cơ bản mà bài viết này phản đối

Pipeline truyền thống thường thực hiện: chia nhỏ tài liệu (chunking), nhúng mọi đoạn văn, nhúng câu hỏi và xếp hạng theo Cosine. Cách tiếp cận này làm mất đi cấu trúc vốn có của tài liệu. Thay vào đó, tác giả đề xuất giữ tài liệu dưới dạng line_df (dataframe các dòng) và toc_df (dataframe mục lục), sau đó chạy song song ba tín hiệu truy xuất:

1. Keyword trên các dòng.
2. TOC Reasoning (suy luận mục lục).
3. Embedding Cosine.

Cuối cùng, một LLM sẽ đóng vai trò trọng tài để xếp hạng kết quả.

6 bài học "không được dạy" về truy xuất RAG

1. Truy xuất là lọc, không phải tìm kiếm

Thay vì tìm kiếm dựa trên độ tương đồng liên tục (cosine, BM25) với ngưỡng cắt top-k, hãy coi đây là bài toán SQL. Câu hỏi có các cột, tài liệu có các cột, và truy xuất chính là phép JOIN. Việc lọc (filter) cho phép bạn có một "dấu vết kiểm toán" (audit trail) rõ ràng: điều kiện lọc là mã nguồn có thể kiểm tra được, thay vì sự mơ hồ của không gian vector.

2. Tách biệt Anchor (Điểm neo) và Context (Ngữ cảnh)

Việc nhồi nhét mọi thứ vào một chunk duy nhất là sai lầm.

• Anchor: Vị trí chính xác nơi câu trả lời nằm (thường tìm qua từ khóa).
• Context: Lượng văn bản xung quanh cần thiết để hiểu câu trả lời.
  Bằng cách tách biệt hai khái niệm này, bạn có thể lấy được độ chính xác cao mà không làm mất ngữ cảnh.

3. Embeddings nên là bước cuối cùng

Đừng để embedding làm bước đầu tiên. Các tín hiệu rẻ tiền như từ khóa (keyword) và mục lục (TOC) nên được ưu tiên. Chỉ sử dụng embedding khi các phương pháp trên thất bại do lệch từ vựng (vocabulary mismatch).

4. Từ khóa chứng minh sự vắng mặt, Embedding thì không

Nếu tìm kiếm từ khóa trả về kết quả rỗng, bạn có thể khẳng định câu trả lời không tồn tại. Ngược lại, với embedding, ngay cả khi không có kết quả, nó vẫn trả về các đoạn văn "gần nhất" về mặt toán học, dễ khiến LLM bị ảo giác (hallucination) và đưa ra câu trả lời sai.

5. Co-occurrence (Sự đồng xuất hiện) hiệu quả hơn BM25 trên tập dữ liệu hẹp

Trên các tập dữ liệu doanh nghiệp nhỏ, BM25 thường bị nhiễu bởi tần suất từ ngữ. Thay vào đó, hãy ưu tiên các dòng chứa cả từ khóa và giá trị (ví dụ: "deductible" và "$1000"). Tín hiệu về hình thái câu trả lời này mạnh hơn nhiều so với tần suất xuất hiện từ đơn lẻ.

6. Sử dụng LLM để suy luận trên Mục lục (TOC)

Đừng bỏ qua TOC. Việc đưa toàn bộ toc_df vào một LLM nhỏ để hỏi xem mục nào chứa câu trả lời là một phương pháp cực kỳ hiệu quả. Nó giúp xử lý các trường hợp diễn đạt khác nhau (ví dụ: "exit early" trong câu hỏi tương đương với "Termination" trong mục lục).

Kết luận

Thay vì lạm dụng embedding, hãy tập trung vào cấu trúc tài liệu. Ba tín hiệu: Keyword trên line_df + Suy luận trên toc_df + Embedding fallback là công thức tối ưu cho RAG doanh nghiệp. Cách tiếp cận này không chỉ tăng độ chính xác mà còn tiết kiệm chi phí đáng kể vì phần lớn các truy vấn có thể được giải quyết mà không cần đến LLM hoặc embedding đắt đỏ.

Nguồn tham khảo chi tiết và các notebook thực hành có sẵn trên GitHub: doc-intel/notebooks-vol1.