Bí mật bẩn của RAG: Tại sao tìm kiếm vector của bạn là chưa đủ

Nhóm Cộng đồng BigGo
Bí mật bẩn của RAG: Tại sao tìm kiếm vector của bạn là chưa đủ

Sau khi xử lý hơn 5 triệu tài liệu trên các ứng dụng pháp lý và nghiên cứu, các nhà phát triển đang phát hiện ra rằng các hệ thống RAG sẵn sàng cho sản xuất đòi hỏi nhiều hơn rất nhiều so với chỉ tìm kiếm tương đồng vector. Sự đồng thuận trong cộng đồng nổi lên từ các cuộc thảo luận gần đây cho thấy các triển khai thành công dựa vào một ngăn xếp kỹ thuật tinh vi có hiệu suất vượt trội hẳn so với các phương pháp cơ bản.

Cuộc cách mạng sắp xếp lại thứ hạng

Điều bắt đầu như một tìm kiếm vector đơn giản đã phát triển thành các hệ thống truy xuất đa giai đoạn phức tạp, với việc sắp xếp lại thứ hạng nổi lên như một nâng cấp có tác động lớn nhất. Các nhà phát triển báo cáo rằng việc thêm một mô hình sắp xếp lại chuyên biệt—mô hình này sắp xếp lại thứ tự kết quả tìm kiếm dựa trên mức độ liên quan đến truy vấn cụ thể—có thể bù đắp cho nhiều điểm yếu khác trong một thiết lập RAG. Cấu hình điển hình bao gồm việc đưa 50 đoạn dữ liệu ứng viên vào bộ sắp xếp lại và nhận về 15 đoạn liên quan nhất.

5 dòng mã có giá trị nhất mà bạn sẽ thêm vào. Thứ hạng của các đoạn dữ liệu thay đổi rất nhiều, nhiều hơn những gì bạn mong đợi.

Phương pháp này tỏ ra hiệu quả hơn đáng kể so với việc chỉ dựa vào độ tương đồng cosine giữa các embedding, vì các bộ sắp xếp lại hiểu được sự liên quan về ngữ cảnh thay vì chỉ sự tương đồng ngữ nghĩa.

Những Yếu Tố Tạo Ra Sự Khác Biệt (Xếp Hạng ROI)

  1. Query Generation - LLM tạo ra nhiều truy vấn ngữ nghĩa + từ khóa để xử lý song song
  2. Reranking - Đầu vào 50 chunks → đầu ra 15 chunks mang lại kết quả tối ưu
  3. Chiến Lược Chunking - Logic tùy chỉnh đảm bảo các đơn vị logic mà không bị ngắt giữa câu
  4. Metadata Injection - Thêm tiêu đề, tác giả, v.v. vào ngữ cảnh LLM giúp cải thiện câu trả lời
  5. Query Routing - Phát hiện các câu hỏi không phải RAG để xử lý thay thế

Vượt ra ngoài việc chia nhỏ cơ bản

Trong khi sắp xếp lại thứ hạng mang lại những cải thiện nhanh chóng, chiến lược chia nhỏ dữ liệu vẫn là yếu tố quan trọng nhất nhưng tốn nhiều thời gian. Các hệ thống sản xuất yêu cầu logic chia nhỏ tùy chỉnh hiểu được cấu trúc tài liệu, đảm bảo các đoạn dữ liệu đại diện cho các đơn vị logic thay vì các phần tách văn bản tùy ý. Cộng đồng nhấn mạnh rằng các đoạn dữ liệu không bao giờ được ngắt giữa câu hoặc giữa từ, và mỗi đoạn phải hoạt động như một đơn vị thông tin tự chứa.

Nhiều nhóm đang vượt ra ngoài các bộ tách văn bản đơn giản, với một số sử dụng LLM để tạo ra các bản tóm tắt và trích xuất thông minh. Cách tiếp cận truy xuất theo ngữ cảnh của Anthropic, bao gồm các bản tóm tắt tài liệu đầy đủ cùng với các đoạn dữ liệu, đã thu hút được sự quan tâm nhờ duy trì ngữ cảnh rộng hơn trong khi vẫn cho phép truy xuất chính xác.

Tạo và mở rộng truy vấn

Các nhà phát triển phát hiện ra rằng các truy vấn của người dùng thường không nắm bắt được đầy đủ ngữ cảnh cần thiết cho việc truy xuất hiệu quả. Giải pháp: sử dụng LLM để tạo ra nhiều biến thể ngữ nghĩa và từ khóa khác nhau của truy vấn gốc, sau đó xử lý chúng song song. Kỹ thuật này, được gọi là mở rộng truy vấn, làm tăng đáng kể phạm vi truy xuất mà không cần dựa vào điểm số tìm kiếm kết hợp được tính toán.

Một triển khai tạo ra ba biến thể truy vấn khác biệt trong một lần gọi LLM duy nhất, đảm bảo tính đa dạng thay vì sự tương đồng. Các kết quả từ các tìm kiếm song song sau đó được kết hợp bằng cách hợp nhất thứ hạng nghịch đảo, tạo ra một tập hợp các tài liệu ứng viên mạnh mẽ giải quyết truy vấn từ nhiều góc độ.

Ngăn xếp truy xuất đầy đủ

Cộng đồng phần lớn đã chuyển dịch khỏi tư duy kho vector là giải pháp từng thống trị các triển khai RAG ban đầu. Các hệ thống sản xuất hiện nay thường kết hợp:

  • Tìm kiếm kết hợp kết hợp vector dày đặc và BM25 thưa thớt cho các thuật ngữ kỹ thuật
  • Tiêm siêu dữ liệu để cung cấp manh mối ngữ cảnh cho LLM
  • Định tuyến truy vấn để xử lý các câu hỏi không phải RAG thông qua các phương pháp thay thế
  • Nhiều mô hình embedding và chiến lược truy xuất

Như một nhà phát triển tại Microsoft lưu ý, Rất ít nhà phát triển nhận ra rằng bạn cần nhiều hơn chỉ là tìm kiếm vector, vì vậy tôi vẫn dành nhiều bài nói chuyện của mình để nhấn mạnh ngăn xếp truy xuất ĐẦY ĐỦ cho RAG. Azure AI Search và các giải pháp doanh nghiệp khác hiện đã tích hợp trực tiếp các khả năng này vào nền tảng của họ.

Các Thành Phần của Production RAG Stack

Thành Phần Lựa Chọn Ban Đầu Lựa Chọn Cuối Cùng Insight Chính
Vector Database Azure → Pinecone Turbopuffer Giá rẻ, hỗ trợ tìm kiếm từ khóa gốc
Reranker Không có → Cohere 3.5 Zerank Ít được biết đến nhưng hiệu quả
Embedding text-embedding-large-3 Giữ nguyên Không thử nghiệm các phương án khác
Chunking Unstructured.io Tùy chỉnh Quan trọng cho hiệu suất
Query Processing Truy vấn đơn Tạo đa truy vấn Xử lý song song với reranking

Những câu hỏi mở và Hướng đi tương lai

Bất chấp những tiến bộ này, một số thách thức vẫn chưa được giải quyết. Chi phí tính toán của các mô hình sắp xếp lại lớn đặt ra mối lo ngại về khả năng mở rộng, thúc đẩy việc khám phá các mô hình chuyên biệt nhỏ hơn như Qwen3-reranker. Cũng có những cuộc tranh luận đang diễn ra về việc liệu có nên sử dụng các bộ sắp xếp lại chuyên biệt so với các LLM đa mục đích để chấm điểm mức độ liên quan hay không, với sự đánh đổi giữa chi phí, tốc độ và độ chính xác.

Cộng đồng cũng đang thử nghiệm các cách tiếp cận tinh vi hơn như định tuyến truy vấn đến các mô hình embedding khác nhau dựa trên loại nội dung, và sử dụng nhiều bộ sắp xếp lại theo trình tự hoặc song song. Một số nhà phát triển đang vượt ra ngoài RAG truyền thống hoàn toàn để hướng tới tìm kiếm tác nhân sử dụng các công cụ như grep và tìm kiếm nguồn thời gian thực bên cạnh việc truy xuất truy thống.

Sự tiến hóa vẫn tiếp tục khi các nhóm cân bằng các yêu cầu cạnh tranh về độ chính xác, độ trễ và chi phí trong các môi trường sản xuất, nơi người dùng mong đợi sự hiểu biết gần như con người từ các hệ thống truy xuất tài liệu của họ.

Tham khảo: Production RAG: what I learned from processing 5M+ documents