Tại sao chỉ tìm kiếm vector là chưa đủ: Truy xuất kết hợp cho RAG

Trang chủ InfoQ Bài viết Tại sao chỉ tìm kiếm Vector là chưa đủ: Truy xuất kết hợp cho RAG AI, ML & Kỹ thuật dữ liệu Tại sao chỉ tìm kiếm Vector là chưa đủ: Truy xuất kết hợp cho RAG Ngày 02/6/2026 Đọc trong 17 phút Bởi Aaditya Chauhan Được đánh giá bởi Srini Penchikala Viết bài cho InfoQ Thỏa mãn sự tò mò của bạn. Giúp hơn 550.000 nhà phát triển cấp cao trên toàn cầu luôn dẫn đầu mỗi tháng. Liên hệ Nghe bài viết này - 0:00 Âm thanh sẵn sàng phát Trình duyệt của bạn không hỗ trợ phần tử âm thanh. 0:00 0:00 Bình thường1.25x1.5x Thích Danh sách đọc Những điểm chính Vector embeddings (nhúng vector) là các công cụ xấp xỉ tuyệt vời trong việc tìm kiếm nội dung có ý nghĩa tương tự, nhưng lại yếu kém một cách có hệ thống trong việc phân biệt các thực thể cụ thể như số phiên bản, mã lỗi và tên cờ tính năng. Các truy vấn trong thực tế hiếm khi thuộc hoàn toàn vào các danh mục ngữ nghĩa hoặc từ vựng; hầu hết là các truy vấn kết hợp yêu cầu cả ý nghĩa và khớp chính xác, đây là lúc phương pháp truy xuất đơn lẻ thất bại. BM25 (viết tắt của Best Matching 25) là một hàm xếp hạng cung cấp độ chính xác mà embeddings không thể có được. Nó sử dụng ba cơ chế: tần suất tài liệu nghịch đảo (IDF), là trọng số của các token phân biệt hiếm; bão hòa tần suất thuật ngữ; và chuẩn hóa độ dài tài liệu. Reciprocal Rank Fusion (RRF) kết hợp kết quả BM25 và vector mà không gặp khó khăn trong việc chuẩn hóa điểm số. Nó hoạt động dựa trên vị trí xếp hạng, thưởng cho các tài liệu mà cả hai công cụ truy xuất đều đồng ý. Một ngăn xếp truy xuất trong thực tế được phân lớp. BM25 cộng với tìm kiếm vector được kết hợp với RRF và tùy chọn theo sau là giai đoạn reranking (xếp hạng lại) bằng cross-encoder để đạt được lợi ích liên quan cuối cùng trên một tập hợp ứng viên nhỏ. Gần đây, công ty của bạn đã ra mắt một công cụ tìm kiếm tổng hợp nội bộ, một hệ thống duy nhất, được phát triển bằng Retrieval Augmented Generation (RAG), bao gồm các vấn đề tồn đọng của công ty, tài liệu thiết kế, tài liệu ra mắt, runbook và các bản sửa lỗi (COE). Các kỹ sư, PM và quản lý truy vấn nó thông qua giao diện trò chuyện được hỗ trợ bởi LLM. Các nhóm cũng sử dụng nó như một công cụ MCP, để các trợ lý mã hóa AI của họ có thể trực tiếp lấy ngữ cảnh. Sau đó, một thành viên nhóm trực ban trong nhóm hỗ trợ sản xuất gõ: "runbook để bật cờ tính năng payment_v2_enforce trong sản xuất" và trợ lý trò chuyện lại bảo họ tắt nó đi. Về mặt nội bộ, hệ thống xếp hạng tài liệu theo độ tương đồng của embedding. Đối với mô hình embedding, hai runbook trông gần như giống hệt nhau. Chúng có cùng tên cờ, cùng dịch vụ, cùng từ vựng và ngữ cảnh xung quanh tương tự. Kỹ sư trực ban không thấy trực tiếp xếp hạng này. Họ thấy câu trả lời của trợ lý trò chuyện được tạo ra từ các kết quả top-K mà công cụ truy xuất trả về (và đôi khi runbook đúng thậm chí không nằm trong top-K). Câu trả lời tốt nhất là bị pha loãng và tệ nhất là sai một cách tự tin. Các nhà tài trợ liên quan Nếu đã xây dựng một hệ thống tìm kiếm sử dụng nhúng (embedding), tình huống này có thể quen thuộc. Hệ thống nắm bắt được ý chính nhưng lại bỏ sót những chi tiết nhỏ, cụ thể thực sự quan trọng. Truy vấn trên đòi hỏi hai điều: hiểu biết ngữ nghĩa về "feature flag runbook" và khớp chính xác với thao tác (enable so với disable). Tìm kiếm vector chỉ xử lý được yêu cầu đầu tiên. Đây không phải là lỗi trong mô hình nhúng; đây là cách hoạt động của độ tương đồng vector. Nhúng tìm những thứ tương tự với truy vấn, không phải những thứ khớp chính xác. Vì truy xuất cung cấp K kết quả hàng đầu cho LLM làm ngữ cảnh, nên xếp hạng quan trọng ngang với khả năng gợi nhớ (recall). Việc câu trả lời đúng có mặt trong K kết quả hàng đầu là chưa đủ nếu câu trả lời sai được xếp hạng cao hơn. Giải pháp không phải là thay thế nhúng, mà là kết hợp chúng với đối sánh từ khóa cổ điển trên văn bản thực tế để cả sự liên quan về mặt khái niệm và đối sánh thuật ngữ chính xác đều đóng góp vào xếp hạng cuối cùng. Nơi các đường ống RAG chỉ dựa vào vector bị lỗi Để hiểu tại sao tình huống này xảy ra, cần nhìn tổng thể vào toàn bộ đường ống. Một đường ống RAG có ba giai đoạn, như thể hiện trong Hình 1. Hình 1. Một đường ống RAG điển hình có ba giai đoạn: phân đoạn (chunking), truy xuất (retrieval) và tạo sinh (generation). (Nguồn: do tác giả tạo) Các yếu tố trong Hình 1 có thể được định nghĩa như sau: Phân đoạn chia nguồn dữ liệu thành các đơn vị có thể lập chỉ mục. Truy xuất nhận truy vấn của người dùng, tìm kiếm trên các phân đoạn đó và trả về K phân đoạn liên quan nhất. Tạo sinh cung cấp các phân đoạn đó cho một LLM làm ngữ cảnh và yêu cầu nó tạo ra câu trả lời. Giả sử giai đoạn đầu tiên và thứ ba hoạt động chính xác. Các tài liệu được chia tại các ranh giới hợp lý và LLM dựa trên ngữ cảnh được cung cấp để đưa ra câu trả lời mà không bị "ảo giác". Giai đoạn truy xuất là nơi xảy ra lỗi từ phần giới thiệu. Bộ truy xuất nhúng truy vấn, so sánh nó với các vector tài liệu đã lập chỉ mục và trả về bất kỳ tài liệu nào gần nhất trong không gian nhúng. Sự gần gũi trong không gian nhúng có nghĩa là sự tương đồng về ngữ nghĩa, không phải sự đồng nhất. Hai runbook cho cùng một feature flag, một để bật (enable) và một để tắt (disable), nằm rất gần nhau trong không gian nhúng. Cách diễn đạt của chúng chỉ khác nhau một từ trong số nhiều từ và mô hình nhúng tạo ra các vector gần như giống hệt nhau cho văn bản gần như giống hệt nhau. Bộ truy xuất không thể phân biệt chúng một cách đáng tin cậy. Vì vậy, khi người dùng yêu cầu runbook để bật cờ, runbook để tắt đôi khi là tài liệu gần hơn và bộ truy xuất hiển thị nó với độ tin cậy tương tự như khi nó truy xuất đúng tài liệu. Đó là điểm phá vỡ, nơi cùng một không gian vector và cùng một cơ chế tính điểm.