Hệ thống RAG của bạn trả lời sai — không phải vì LLM kém, mà vì retriever bỏ sót tài liệu đúng. Vector search giỏi hiểu ngữ nghĩa nhưng thất bại với tên sản phẩm, mã SKU hay thuật ngữ chuyên ngành. BM25 giỏi khớp từ khóa chính xác nhưng mù với câu hỏi mơ hồ. Kết hợp cả hai — đó là Hybrid Search RAG.
Theo nghiên cứu của Ailog RAG (2025), hybrid search với reranking đạt MRR 66.43% so với 56.72% khi chỉ dùng semantic search — tăng 9.3 điểm phần trăm. Bài viết này giải thích cơ chế hoạt động, công thức RRF, và cách triển khai với LangChain trong dự án thực tế.
Key Takeaways - Hybrid Search kết hợp BM25 (sparse) + vector (dense) qua Reciprocal Rank Fusion (RRF), tăng nDCG@10 trên BEIR từ 43.42 lên 52.59 — cải thiện 20.9% (arxiv 2502.20245, 2025). - BM25 vẫn thắng semantic search khi query chứa mã sản phẩm, tên riêng, hoặc jargon kỹ thuật chưa có trong tập embedding. - Thêm cross-encoder reranking sau hybrid retrieval tăng thêm 23.4% so với hybrid-alone (Synthimind, 2025). - LangChain
EnsembleRetrievertích hợp RRF sẵn — triển khai hybrid search chỉ cần ~10 dòng code. - RAG market đang tăng 49.1% CAGR từ $2.33B (2025) lên $11B (2030) — đầu tư vào retrieval quality là đầu tư chiến lược.
[INTERNAL-LINK: tổng quan về RAG doanh nghiệp → pillar page /rag-doanh-nghiep]
Tại Sao RAG Thuần Vector Thường Bỏ Sót Câu Trả Lời Đúng?
Dense retrieval hiện outperform BM25 tới 15–25% trên BEIR benchmark tổng thể, nhưng BM25 vẫn thắng trên 2 trong 14 bộ dataset và đặc biệt mạnh với truy vấn chứa từ khóa chính xác (Ailog RAG, 2026). Điều này nghĩa là nếu bạn chỉ dùng vector search, bạn đang để lộ một điểm mù lớn.
Ba trường hợp điển hình vector search thất bại
Câu hỏi có mã cụ thể: User hỏi "hợp đồng SKU-4892 điều khoản bảo hành là gì?" — embedding model không encode mã SKU-4892 thành vector riêng biệt có ý nghĩa. BM25 tìm ngay document chứa chuỗi đó.
Tên sản phẩm / brand mới: Nếu công ty vừa ra mắt sản phẩm tên "Orion Pro" nhưng embedding model chưa thấy trong training data, vector của "Orion Pro" và "Orion" có thể gần giống nhau dù chỉ một cái đúng.
Thuật ngữ kỹ thuật nội bộ: Từ viết tắt nội bộ ("SOW", "NDA", "PO-7") hay jargon ngành hẹp không nằm trong vocabulary của embedding model sẽ bị encode thành vector tương đồng với những từ không liên quan.
Quan sát thực tế: Trong các RAG deployment cho khách hàng tài chính, hơn 30% câu hỏi thất bại đến từ query chứa mã giao dịch hoặc tên sản phẩm nội bộ — đây là lý do hybrid search gần như bắt buộc với enterprise RAG.
Hybrid search giải quyết bằng cách chạy song song: BM25 bắt những gì vector bỏ sót, vector bắt những gì BM25 không hiểu về ngữ nghĩa. RRF sau đó hợp nhất hai danh sách kết quả.
[INTERNAL-LINK: cách chọn embedding model phù hợp → bài a14-04 về embedding models]
BM25 Hoạt Động Như Thế Nào và Khi Nào Nó Tốt Hơn Semantic Search?
BM25 (Best Match 25) là thuật toán ranking xác suất tính điểm document dựa trên tần suất từ khóa có điều chỉnh độ dài, đạt baseline nDCG@10 trung bình 43.42 trên toàn bộ BEIR benchmark — thấp hơn dense retrieval nhưng vẫn là "hard to beat" trên nhiều tập dữ liệu keyword-heavy (arxiv 2502.20245, 2025).
Cơ chế tính điểm BM25
Công thức cốt lõi:
score(q, d) = Σ IDF(tᵢ) × [f(tᵢ,d) × (k₁+1)] / [f(tᵢ,d) + k₁×(1-b+b×|d|/avgdl)]
- IDF(tᵢ): Inverse Document Frequency — từ hiếm trong corpus được trọng số cao hơn
- f(tᵢ,d): Term frequency trong document — xuất hiện nhiều = điểm cao hơn, nhưng giảm dần
- k₁ (mặc định 1.2): kiểm soát mức độ bão hòa của term frequency
- b (mặc định 0.75): chuẩn hóa độ dài document
- |d|/avgdl: tỷ lệ độ dài document so với trung bình corpus
Kết quả là vector sparse — chỉ các chiều tương ứng với từ xuất hiện trong query có giá trị khác 0. Tổng kích thước vector bằng vocabulary size (~50K chiều) nhưng hầu hết là zero.
So sánh BM25 vs Dense Retrieval
| Tiêu chí | BM25 (Sparse) | Dense (Embedding) |
|---|---|---|
| Kích thước vector | ~50K chiều, gần hết = 0 | 768–4096 chiều, tất cả ≠ 0 |
| Bắt được | Khớp từ khóa chính xác | Ngữ nghĩa, paraphrase |
| Index | Inverted index (nhanh) | HNSW / IVF ANN |
| Từ ngoài vocab | Thất bại | Generalize qua embedding |
| Tốt nhất cho | Mã, tên riêng, jargon | Câu hỏi tự nhiên, mơ hồ |
Đây là lý do cả hai không thể thay thế nhau — chúng bổ sung cho nhau.
[INTERNAL-LINK: hướng dẫn cài đặt Qdrant cho vector storage → bài a14-03 về Qdrant]
Kiến Trúc Hybrid Search RAG — Pipeline 3 Giai Đoạn Hoạt Động Như Thế Nào?
Hybrid retrieval cung cấp thêm 2–5% nDCG so với dense-only, đặc biệt rõ rệt trên out-of-domain queries — đây là điểm mấu chốt cho enterprise RAG khi tài liệu nội bộ thường "xa" với distribution của embedding model (Ailog RAG, 2026).
Pipeline chuẩn gồm 3 giai đoạn:
Query → [BM25 Retriever] → Top-K₁ documents ─┐
→ [Dense Retriever] → Top-K₂ documents ─┤→ [RRF Fusion] → Top-N → [LLM]
(tùy chọn) [Reranker] → Top-M documents ──┘
Giai đoạn 1: Song song hai retriever
Với mỗi query, hệ thống kích hoạt đồng thời:
- BM25 Retriever: tìm qua inverted index, trả về top-K₁ documents theo score BM25
- Dense Retriever: tính embedding của query, ANN search trong vector store, trả về top-K₂ documents theo cosine similarity
Thông thường K₁ = K₂ = 10–20 tùy use case.
Giai đoạn 2: RRF Fusion
Hợp nhất hai danh sách thành một ranked list duy nhất qua Reciprocal Rank Fusion (chi tiết ở phần tiếp theo).
Giai đoạn 3: (Tùy chọn) Reranking
Cross-encoder reranker score từng cặp (query, document) từ top-N của RRF, lọc xuống top-M tốt nhất trước khi đưa vào LLM.
Kinh nghiệm triển khai: Bắt đầu với K=10 cho cả hai retriever và N=20 sau RRF. Nếu context window LLM cho phép, tăng lên K=15, N=30. Reranker chỉ cần thiết khi độ chính xác là ưu tiên tuyệt đối và latency có thể thêm 100–300ms.
RRF (Reciprocal Rank Fusion) — Công Thức Hợp Nhất Kết Quả Là Gì?
RRF từ OpenSearch cho thấy latency tốt hơn so với score-normalization hybrid (p50 nhanh hơn 1.62%, p99 nhanh hơn 0.78%) dù NDCG@10 trung bình thấp hơn 3.86% — đây là trade-off hợp lý cho production system cần throughput cao (OpenSearch Engineering Blog, 2025).
Công thức RRF
RRF_score(d) = Σᵢ 1 / (k + rankᵢ(d))
- d: document cần tính điểm
- k: hằng số (mặc định = 60)
- rankᵢ(d): vị trí của document d trong danh sách thứ i (1-indexed)
- Σᵢ: tổng qua tất cả N danh sách retriever
Ví dụ tính toán
Giả sử BM25 trả về document A ở rank 1, dense retrieval trả về A ở rank 3:
RRF_score(A) = 1/(60+1) + 1/(60+3) = 0.01639 + 0.01587 = 0.03226
So với document B chỉ xuất hiện ở BM25 rank 2:
RRF_score(B) = 1/(60+2) = 0.01613
Document A thắng vì được cả hai retriever đồng thuận — đây chính là sức mạnh của RRF.
Tại sao k=60 là mặc định?
Giá trị k=60 được chọn qua thực nghiệm để giảm ảnh hưởng của các document ở top rank tuyệt đối. Nếu k nhỏ (vd k=5), tài liệu xếp hạng 1 trong một list sẽ áp đảo hoàn toàn. Nếu k lớn (vd k=200), sự khác biệt giữa rank 1 và rank 10 gần như biến mất.
Ưu điểm RRF vs Score Normalization: RRF không cần chuẩn hóa score giữa BM25 (scale tùy ý) và cosine similarity (0–1). Đây là vấn đề lớn vì hai scale hoàn toàn không tương đương — RRF giải quyết bằng cách bỏ qua giá trị score, chỉ dùng thứ hạng.
Cách Triển Khai Hybrid Search RAG với LangChain — Code Step-by-Step
Với LangChain EnsembleRetriever, hybrid search chỉ cần ~10 dòng code thay vì tự implement RRF. Đây là cách triển khai nhanh nhất cho production RAG.
Cài đặt dependencies
pip install langchain langchain-community langchain-openai qdrant-client rank-bm25
Bước 1: Khởi tạo BM25 Retriever
from langchain_community.retrievers import BM25Retriever
from langchain.schema import Document
# Load documents đã split thành chunks
docs = [
Document(page_content="Sản phẩm SKU-4892 bảo hành 24 tháng..."),
Document(page_content="Chính sách đổi trả trong vòng 30 ngày..."),
# ...
]
bm25_retriever = BM25Retriever.from_documents(docs, k=10)
Bước 2: Khởi tạo Dense Vector Retriever
from langchain_openai import OpenAIEmbeddings
from langchain_community.vectorstores import Qdrant
from qdrant_client import QdrantClient
embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
client = QdrantClient(url="http://localhost:6333")
vector_store = Qdrant.from_documents(
docs,
embeddings,
url="http://localhost:6333",
collection_name="hybrid_rag_docs",
)
vector_retriever = vector_store.as_retriever(search_kwargs={"k": 10})
Bước 3: Kết hợp với EnsembleRetriever (RRF)
from langchain.retrievers import EnsembleRetriever
# weights=[0.5, 0.5] = cân bằng; điều chỉnh nếu domain thiên về keyword/semantic
ensemble_retriever = EnsembleRetriever(
retrievers=[bm25_retriever, vector_retriever],
weights=[0.5, 0.5]
)
Bước 4: Tích hợp vào RAG Chain
from langchain_openai import ChatOpenAI
from langchain.chains import RetrievalQA
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
qa_chain = RetrievalQA.from_chain_type(
llm=llm,
retriever=ensemble_retriever,
return_source_documents=True,
)
result = qa_chain.invoke({"query": "Bảo hành sản phẩm SKU-4892 bao nhiêu tháng?"})
print(result["result"])
Tinh chỉnh weights theo domain
| Domain | BM25 weight | Dense weight | Lý do |
|---|---|---|---|
| Legal / Hợp đồng | 0.6 | 0.4 | Nhiều điều khoản, mã điều luật cụ thể |
| Customer Support | 0.4 | 0.6 | Query tự nhiên, paraphrase nhiều |
| E-commerce | 0.65 | 0.35 | SKU, tên sản phẩm, mã hàng |
| Knowledge Base | 0.45 | 0.55 | Mix giữa khái niệm và keyword |
[INTERNAL-LINK: hướng dẫn xây dựng RAG pipeline hoàn chỉnh với Qdrant → bài a14-05]
Có Nên Thêm Reranking Sau Hybrid Search Không? Benchmark và Trade-Offs
Thêm cross-encoder reranking trên top-N kết quả của hybrid retrieval cho thấy cải thiện 23.4% so với hybrid-alone trên BEIR benchmark, với MRR tăng từ 66.43% lên ~73% (Synthimind, 2025). Câu hỏi là: latency và cost có xứng đáng không?
Cross-encoder Reranking hoạt động như thế nào?
Bi-encoder (embedding model thông thường) encode query và document riêng rẽ rồi tính cosine similarity — nhanh nhưng không capture tương tác giữa hai văn bản. Cross-encoder nhận đầu vào là cặp [query, document] và chạy full attention qua cả hai — chính xác hơn nhưng tốn O(n) inference.
Pipeline điển hình: 1. Hybrid retriever trả về top-50 candidates 2. Reranker score từng (query, doc) trong top-50 3. Lấy top-5 hoặc top-10 để đưa vào LLM prompt
from langchain.retrievers import ContextualCompressionRetriever
from langchain_cohere import CohereRerank
# Cohere Rerank v3.5 — Tier 3 model, tốt nhất cho production
compressor = CohereRerank(model="rerank-v3.5", top_n=5)
compression_retriever = ContextualCompressionRetriever(
base_compressor=compressor,
base_retriever=ensemble_retriever,
)
Khi nào nên thêm reranking?
Phân tích trade-off: Reranker thêm 100–300ms latency nhưng tiết kiệm cost vì LLM nhận ít document hơn. NVIDIA ước tính reranking giảm 21.54% chi phí LLM inference so với gửi toàn bộ retrieved docs.
| Tiêu chí | Dùng Reranking | Không dùng |
|---|---|---|
| Ưu tiên | Accuracy tuyệt đối | Latency thấp |
| Context window | Nhỏ, cần chọn lọc | Rộng, chấp nhận nhiều doc |
| Budget | Có thể chịu thêm API call | Tối ưu chi phí |
| Domain | Pháp lý, y tế, tài chính | Chatbot nội bộ, FAQ |
[INTERNAL-LINK: case study RAG cho customer support với Qdrant → bài a14-06] [INTERNAL-LINK: chiến lược triển khai AI doanh nghiệp → Hub A AI doanh nghiep]
Câu Hỏi Thường Gặp
Hybrid Search RAG khác gì với RAG thông thường?
RAG thông thường chỉ dùng vector search (dense retrieval) để tìm tài liệu liên quan. Hybrid Search RAG chạy song song cả BM25 (sparse, keyword-based) và vector search (dense, semantic), sau đó dùng RRF để hợp nhất kết quả. Cải thiện MRR tới 9.3 điểm phần trăm so với dense-only (Ailog RAG, 2025).
BM25 có cần fine-tune không?
BM25 không cần fine-tune — đây là thuật toán thống kê không có trọng số học được. Bạn chỉ cần điều chỉnh hai hyperparameter: k₁ (mặc định 1.2, kiểm soát term frequency saturation) và b (mặc định 0.75, kiểm soát length normalization). Với hầu hết use case enterprise, giá trị mặc định là đủ tốt.
Dùng vector database nào hỗ trợ hybrid search sẵn?
Qdrant, Weaviate, Elasticsearch và Azure AI Search đều hỗ trợ hybrid search native với BM25 + vector, tích hợp RRF sẵn trong engine. Qdrant gọi là "sparse-dense fusion", Elasticsearch có knn + query combined. Nếu dùng pgvector (PostgreSQL), bạn cần tự implement BM25 riêng qua pg_trgm hoặc full-text search.
[INTERNAL-LINK: so sánh Qdrant với các vector database khác → bài a14-03 Qdrant]
RRF có thể điều chỉnh để ưu tiên BM25 hay vector không?
Có. LangChain EnsembleRetriever nhận tham số weights=[w1, w2] — ví dụ weights=[0.7, 0.3] để ưu tiên BM25 hơn. Ngoài ra, Weighted RRF (WRRF) cho phép nhân hệ số trực tiếp vào score RRF. Điều chỉnh dựa trên domain: legal/finance thường thiên về BM25 (0.6–0.7), conversational support thiên về dense (0.6–0.7).
Hybrid Search có làm tăng latency đáng kể không?
BM25 và dense retrieval chạy song song, nên latency tổng bằng max(BM25_time, dense_time), không phải tổng. BM25 trên inverted index cực nhanh (dưới 10ms cho 100K documents), nên bottleneck thực sự vẫn là ANN search của vector store. Hybrid search thường thêm 5–15ms so với vector-only. Reranking thêm 100–300ms nếu dùng cloud API như Cohere.
Kết Luận
Hybrid Search RAG không phải optimization phức tạp — đây là baseline nên có cho bất kỳ hệ thống RAG production nào. Vector search đủ dùng cho demo, nhưng khi tài liệu nội bộ chứa mã sản phẩm, tên hợp đồng hay jargon kỹ thuật, BM25 là lớp bảo vệ không thể thiếu.
Pipeline 3 bước: BM25 + Dense → RRF fusion → (tùy chọn) Reranking cho kết quả BEIR nDCG@10 tăng 20.9% và MRR tăng 9.3 điểm phần trăm. LangChain EnsembleRetriever giúp triển khai trong vài chục phút.
Thị trường RAG đang tăng trưởng 49.1% CAGR, đạt $11B vào 2030 (Grand View Research, 2025) — đầu tư vào retrieval quality ngay hôm nay là lợi thế cạnh tranh dài hạn.
[INTERNAL-LINK: tìm hiểu toàn bộ chiến lược RAG cho doanh nghiệp → pillar /rag-doanh-nghiep] [INTERNAL-LINK: hướng dẫn Claude AI cho doanh nghiệp → Hub B bài Claude cho doanh nghiep]
Bài viết thuộc cluster A14 — RAG Doanh Nghiệp. Cập nhật lần cuối: 01/05/2026.