Tại sao chỉ dùng Vector Search là chưa đủ: Giải pháp Hybrid Retrieval cho RAG

Bài viết phân tích những hạn chế của các pipeline RAG chỉ dựa vào tìm kiếm vector và giải pháp nâng cấp thông qua Hybrid Retrieval. Bằng cách kết hợp thuật toán BM25 với kết quả vector search sử dụng Reciprocal Rank Fusion (RRF), hệ thống có thể xử lý hiệu quả cả truy vấn ngữ nghĩa và khớp chính xác từ khóa.

Trong bối cảnh phát triển hệ thống AI hiện đại, Retrieval-Augmented Generation (RAG) đã trở thành một kiến trúc phổ biến để bổ sung kiến thức cho các mô hình ngôn ngữ lớn (LLM). Tuy nhiên, nhiều kỹ sư vẫn gặp phải những vấn đề đau đầu khi hệ thống của họ trả lời sai một cách tự tin, dù dữ liệu đúng đã có trong cơ sở dữ liệu.

Vấn đề thường không nằm ở mô hình ngôn ngữ, mà ở giai đoạn truy xuất (retrieval). Bài viết này sẽ đi sâu vào lý do tại sao chỉ dựa vào Vector Search là chưa đủ và tại sao Hybrid Retrieval (kết hợp tìm kiếm từ khóa và vector) mới là giải pháp tối ưu cho môi trường sản xuất (production).

Khi pipeline RAG chỉ dùng Vector gặp lỗi

Hãy tưởng tượng một tình huống thực tế: Một kỹ sư trực hệ thống (on-call) cần tìm runbook để bật (enable) một feature flag tên là payment_v2_enforce trong môi trường production. Họ hỏi hệ thống tìm kiếm nội bộ của công ty.

Thay vì hướng dẫn bật flag, trợ lý AI lại trả lời hướng dẫn tắt (disable) nó. Tại sao lại như vậy?

Pipeline RAG điển hình

Một pipeline RAG điển hình bao gồm ba giai đoạn: Chunking (chia nhỏ tài liệu), Retrieval (truy xuất) và Generation (tạo câu trả lời). Trong trường hợp này, lỗi xảy ra ở giai đoạn Retrieval.

Hệ thống xếp hạng tài liệu dựa trên sự tương đồng của embedding (vector). Đối với mô hình embedding, hai runbook — một cái để bật và một cái để bật — trông gần như giống hệt nhau. Chúng có cùng tên flag, cùng tên dịch vụ, từ vựng tương tự và ngữ cảnh xung quanh giống nhau. Sự khác biệt duy nhất là từ "enable" và "disable" là quá nhỏ bé so với tổng thể nội dung, khiến vector của chúng gần như trùng khớp.

Kết quả là runbook sai (disable) có thể được xếp hạng cao hơn runbook đúng (enable), và LLM dùng dữ liệu này để tạo ra câu trả lời sai lầm.

Vấn đề cốt lõi: Embeddings là công cụ xấp xỉ

Mô hình embedding như BERT chuyển văn bản thành các vector số để nắm bắt ý nghĩa ngữ nghĩa. Các văn bản có ý nghĩa tương tự sẽ tạo ra các vector gần nhau trong không gian đa chiều. Điều này tuyệt vời khi người dùng tìm kiếm theo khái niệm, nhưng lại trở thành vấn đề về độ chính xác (precision) khi cần khớp chính xác thực thể.

Không gian Embedding

Trong không gian vector, các mục có ngữ nghĩa tương tự sẽ tụ tập lại thành các cụm (cluster). Bên trong một cụm, việc phân biệt giữa các thực thể cụ thể (ví dụ: runbook bật vs tắt flag) trở nên rất khó khăn.

Có ba loại truy vấn chính mà chúng ta cần xem xét:

Truy vấn ngữ nghĩa (Semantic Queries): Ví dụ: "Giao thức của chúng ta khi một vùng (region) bị offline là gì?". Embeddings xử lý rất tốt việc này vì nó nắm bắt ý nghĩa chứ không phải khớp từng từ.
Truy vấn khớp chính xác (Exact-Match Queries): Ví dụ: Dán một mã lỗi ERR_PAYMENT_GATEWAY_TIMEOUT. Vector search có thể thất bại vì nó không thể phân biệt rõ ràng mã này với các mã lỗi tương tự khác (như ERR_PAYMENT_GATEWAY_REJECTED). Tìm kiếm từ khóa (keyword search) mới là giải pháp đúng ở đây.
Truy vấn lai (Hybrid Queries): Đây là loại phổ biến nhất trong thực tế. Ví dụ: "Rollback runbook cho triển khai phiên bản v3.2". Người dùng cần cả sự hiểu biết ngữ nghĩa (runbook rollback) và khớp chính xác từ khóa ("v3.2", "rollback").

BM25 cung cấp độ chính xác nơi Embeddings xấp xỉ

Để khắc phục điểm yếu của vector search, chúng ta cần một đối tác: BM25. Đây là hàm xếp hạng xác suất nằm ở trái tim của các công cụ tìm kiếm cổ điển như Elasticsearch hay OpenSearch.

BM25 hoạt động xuất sắc ở nơi vector search thất bại nhờ ba cơ chế:

Inverse Document Frequency (IDF): Đánh giá trọng số dựa trên độ hiếm của thuật ngữ. Các từ phổ biến như "dịch vụ" hay "triển khai" có trọng số thấp, trong khi các token đặc biệt và hiếm như "v3.2", "ERR_PAYMENT_GATEWAY_TIMEOUT" hay tên feature flag sẽ có trọng số rất cao.
Term Frequency (TF) Saturation: Kiểm soát tác động của các thuật ngữ lặp lại, ngăn chặn việc tài liệu "nhồi nhét" từ khóa chiếm đoạt vị trí cao.
Length Normalization: Chuẩn hóa độ dài tài liệu để đảm bảo sự công bằng giữa các đoạn văn bản (chunks) dài và ngắn trong hệ thống RAG.

Tìm kiếm lai với Reciprocal Rank Fusion (RRF)

Bây giờ chúng ta có hai phương pháp truy xuất mạnh mẽ: Vector search (cho ngữ nghĩa) và BM25 (cho từ khóa chính xác). Vấn đề đặt ra là làm sao để kết hợp hai danh sách kết quả này thành một?

Thách thức lớn là điểm số của chúng không tương đồng: độ tương đồng cosine nằm trong khoảng [-1, 1], trong khi điểm BM25 là không giới hạn. Việc chuẩn hóa (normalization) điểm số là rất phức tạp.

Đây chính là nơi Reciprocal Rank Fusion (RRF) phát huy tác dụng. RRF bỏ qua hoàn toàn điểm số thô và chỉ dựa vào thứ hạng (rank position).

Sơ đồ Hybrid Retrieval

Công thức của RRF rất đơn giản: RRF_Score(d) = Σ 1 / (k + rank_r(d))

Trong đó k là một hằng số (thường là 60). Cơ chế này thưởng cho các tài liệu mà cả hai phương pháp truy xuất đều xếp hạng cao. Nếu một tài liệu xuất hiện ở top 1 của cả BM25 và Vector, điểm số của nó sẽ được cộng dồn và vượt trội so với các tài liệu chỉ được một phương pháp ủng hộ.

RRF hoạt động như thế nào trên các loại truy vấn

Với truy vấn ngữ nghĩa: Vector search tìm đúng tài liệu ở vị trí số 1. BM25 có thể tìm thấy nó ở vị trí thấp hơn. RRF sẽ giữ tài liệu đúng ở vị trí top nhờ sự đồng thuận từ Vector.
Với truy vấn khớp chính xác: BM25 tìm chính xác mã lỗi ở vị trí số 1. Vector search có thể bị nhầm với các mã lỗi tương tự. RRF vẫn giữ đúng kết quả ở top 1 nhờ BM25.
Với truy vấn lai: Đây là nơi RRF tỏa sáng nhất. Ví dụ với câu "Rollback runbook cho v3.2", BM25 có thể ưu tiên từ khóa "v3.2", còn Vector ưu tiên ngữ nghĩa "runbook". Một mình mỗi phương pháp có thể xếp sai tài liệu (ví dụ đưa ra runbook "rollout" thay vì "rollback"). Nhưng RRF, bằng cách kết hợp thứ hạng, sẽ đẩy tài liệu thỏa mãn cả hai điều kiện (rollback và v3.2) lên vị trí cao nhất.

Triển khai Hybrid Retrieval trong thực tế

Các hệ thống RAG trong môi trường sản xuất hiện nay đang chuyển dịch sang kiến trúc Hybrid Retrieval. Các nền tảng lớn như Perplexity hay Glean đều sử dụng các biến thể của kiến trúc này.

Triển khai với Elasticsearch

Elasticsearch và OpenSearch hiện đã hỗ trợ Hybrid Retrieval nguyên bản thông qua Retriever API (từ phiên bản 8.13+).

Cấu hình Index: Bạn cần cả trường văn bản cho BM25 và trường vector dày đặc (dense_vector) cho embedding.

PUT /rag_knowledge_base
{
  "mappings": {
    "properties": {
      "title":   { "type": "text" },
      "content": { "type": "text", "analyzer": "standard" },
      "content_vector": {
        "type": "dense_vector",
        "dims": 768,
        "index": true,
        "similarity": "cosine"
      }
    }
  }
}

Truy vấn Hybrid với RRF: Bạn có thể chạy cả hai truy xuất và hợp nhất chúng trong một yêu cầu duy nhất:

POST /rag_knowledge_base/_search
{
  "retriever": {
    "rrf": {
      "retrievers": [
        {
          "standard": {
            "query": { "match": { "content": "rollback runbook for v3.2 deployment" } }
          }
        },
        {
          "knn": {
            "field": "content_vector",
            "query_vector": [0.12, -0.45, ...],
            "k": 50,
            "num_candidates": 100
          }
        }
      ],
      "rank_constant": 60
    }
  }
}

Tối ưu hóa và Reranking

Rank Constant (k): Thông số này kiểm soát độ giảm của đóng góp thứ hạng. Giá trị mặc định là 60. Giảm nó xuống (20-30) sẽ ưu tiên độ chính xác cao cho các kết quả top đầu. Tăng nó lên (80-100) sẽ ưu tiên độ bao quát (recall).
Reranking với Cross-Encoder: Sau khi RRF lấy ra khoảng 20-50 ứng viên hàng đầu, việc sử dụng một mô hình Cross-Encoder để xếp hạng lại (rerank) có thể cải thiện đáng kể độ liên quan cuối cùng. Cross-Encoder xử lý cặp truy vấn-tài liệu cùng lúc, cho phép nắm bắt các mối quan hệ tinh vi mà các embedding độc lập không thể làm được.

Kết luận

Vector embeddings giải quyết vấn đề khái quát hóa trong tìm kiếm, trong khi BM25 giải quyết vấn đề độ chính xác với các từ khóa cụ thể. Không có phương pháp nào là đủ cho một hệ thống RAG sản xuất hoàn chỉnh.

Hybrid search với RRF không phải là một giải pháp tạm thời cho các hạn chế của mô hình hiện tại, mà là cách tiếp cận kiến trúc đúng đắn cho các hệ thống cần xử lý cả truy vấn khái niệm và khớp chính xác. Nếu bạn đang vận hành pipeline RAG chỉ với embeddings, bạn đang bỏ lỡ chất lượng truy xuất. Hãy thêm BM25, hợp nhất với RRF và cân nhắc giai đoạn reranking để tận dụng tối đa khả năng của hệ thống.