Tìm kiếm Hybrid: BM25 vs Vector (và vì sao bạn cần cả hai)
Một nhân viên hỗ trợ gõ "SKU-4471" vào chatbot RAG của bạn. Bốn kết quả trả về. Tất cả đều sai một cách tự tin. Một mô hình embedding đa dụng không có lý do gì để đặt chính xác chuỗi đó gần chính nó trong không gian vector. Chính một kiểu thất bại duy nhất đó là lý do tìm kiếm hybrid tồn tại, và cũng là lý do các đội ngũ cứ mãi đặt một câu hỏi cụ thể: làm sao để thực sự kết hợp BM25 và vector search mà không phải trông chừng một nút tinh chỉnh mãi mãi?
Nếu bạn đang đánh giá công cụ RAG nói chung, bài tổng hợp các công cụ RAG tốt nhất của chúng tôi bao quát cả hệ sinh thái xung quanh.
Những điểm chính
- BM25 tìm các kết quả khớp từ khóa chính xác (SKU, mã lỗi); vector search tìm văn bản tương đồng về khái niệm, chứ không phải chuỗi giống hệt.
- Tìm kiếm hybrid kết hợp cả hai, thường qua Reciprocal Rank Fusion (RRF), và vượt trội hơn bất kỳ phương pháp đơn lẻ nào trên các tập truy vấn hỗn hợp.
- Trên benchmark WANDS, RRF thuần đạt 0,7068 NDCG (so với 0,6983 của BM25); tinh chỉnh đẩy lên 0,7497, tức tăng 7,4%.
- Postgres/pgvector có thể chạy tìm kiếm hybrid một cách bản địa qua
ts_rank+ pgvector, không cần cơ sở dữ liệu vector chuyên dụng.
Tìm kiếm Hybrid là gì? (BM25 + Vector, kết hợp)
Tìm kiếm hybrid chạy BM25 và vector search như hai lượt truy xuất riêng biệt trên cùng một truy vấn, sau đó gộp hai danh sách kết quả đã xếp hạng thành một đầu ra duy nhất bằng một thuật toán hợp nhất, phổ biến nhất là Reciprocal Rank Fusion. Đây không phải một phương pháp truy xuất thứ ba; nó là một lớp điều phối nằm trên hai phương pháp sẵn có.
Sự phân biệt đó quan trọng vì một phần không nhỏ lưu lượng tìm kiếm quanh chủ đề này đánh đồng BM25 và vector search như thể chúng là một. Không phải vậy. BM25 là một hàm chấm điểm thưa, dựa trên từ khóa, có nguồn gốc từ ngành truy xuất thông tin những năm 1970. Vector search là tìm kiếm tương đồng dày, dựa trên embedding, và chỉ trở nên khả thi ở quy mô lớn trong thập kỷ qua. Tìm kiếm hybrid xem chúng như hai đầu vào bổ trợ cho nhau, chứ không phải hai kỹ thuật cạnh tranh, và hợp nhất đầu ra của chúng thay vì chọn trước một bên thắng.
BM25 vs Vector vs Hybrid: So sánh nhanh
| Tiêu chí | BM25 (Thưa/Từ vựng) | Vector Search (Dày/Ngữ nghĩa) | Hybrid |
|---|---|---|---|
| Giỏi nhất ở | Thuật ngữ chính xác, token hiếm, ID | Diễn giải lại, từ đồng nghĩa, khái niệm | Cả hai kiểu truy vấn |
| Thất bại ở | Câu hỏi diễn giải lại, hiện tượng đồng nghĩa | SKU, mã lỗi, từ viết tắt | Kho ngữ liệu không có cả hai kiểu mẫu |
| Xử lý khớp chính xác (SKU, ID, mã lỗi) | Có | Không | Có |
| Xử lý diễn giải lại và từ đồng nghĩa | Không | Có | Có |
| Cần mô hình embedding | Không | Có | Có |
| Cần tinh chỉnh | Tham số k1, b | Cách chia chunk, chọn mô hình | Phương pháp hợp nhất (RRF/alpha) |
| Hồ sơ độ trễ điển hình | Từ dưới mili giây đến vài ms | Từ thấp đến trung bình ms (tùy thuộc ANN) | Tổng của cả hai, cộng thêm chi phí hợp nhất |
| Ví dụ hỗ trợ bản địa | Elasticsearch, Postgres ts_rank | Qdrant, Pinecone, pgvector | Weaviate, Qdrant, Elasticsearch |
Trên benchmark thương mại điện tử WANDS, chỉ riêng BM25 đạt 0,6983 NDCG và chỉ riêng vector search đạt 0,6953 (gần như hòa). Phép hợp nhất RRF thuần, không cần tinh chỉnh theo từng kho ngữ liệu, đạt 0,7068, một mức tăng khiêm tốn 1,2% so với BM25 đơn thuần. Benchmark của Doug Turnbull cũng kiểm thử một biến thể đã tinh chỉnh, chồng thêm một cú hích (boost) cho tên sản phẩm lên trên RRF, và phiên bản đó đạt 0,7497, tức tăng 7,4%. Đáng để trung thực về con số bạn đang trích dẫn: chỉ riêng RRF đã cho bạn một lợi thế nhỏ nhưng có thật ngay khi xuất xưởng; con số 7,4% lớn hơn đòi hỏi tinh chỉnh theo miền cụ thể mà hầu hết các đội đều bỏ qua trong ngày đầu tiên. Cả BM25 lẫn vector search đều không áp đảo khi đứng một mình; chúng bao phủ các kiểu thất bại khác nhau, và hợp nhất chúng sẽ khép cả hai khoảng trống cùng lúc.
Cơ chế của BM25: Tìm kiếm từ khóa thực sự chấm điểm độ liên quan ra sao
BM25 chấm điểm tài liệu theo tần suất xuất hiện của thuật ngữ, được cân nhắc với độ hiếm của thuật ngữ đó trên toàn bộ kho ngữ liệu, sau đó chuẩn hóa theo độ dài tài liệu. Robertson và Zaragoza đã trình bày hình thức hóa này trong bài báo năm 2009 của họ "The Probabilistic Relevance Framework: BM25 and Beyond". Đây là một bản cải tiến của TF-IDF, không phải thứ thay thế nó.
Hai tham số kiểm soát phần lớn hành vi của BM25. k1 (thường là 1,2-2,0) kiểm soát độ bão hòa tần suất thuật ngữ: nó giới hạn mức độ mà việc lặp lại một từ sẽ đẩy điểm lên, để một tài liệu nói "invoice" 40 lần không tự động xếp trên một tài liệu nói từ đó 4 lần trong một đoạn văn chặt chẽ, liên quan hơn. b (mặc định 0,75) kiểm soát chuẩn hóa theo độ dài tài liệu: nó quyết định BM25 phạt các tài liệu dài nặng tay đến mức nào vì chúng tự nhiên chứa nhiều lần khớp thuật ngữ hơn.
Đặt sai b là một lỗi tinh chỉnh có thật và phổ biến. Tài liệu kỹ thuật ngắn (nhật ký lỗi, tiêu đề sản phẩm) cần b thấp hơn vì phương sai độ dài nhỏ; nội dung dài (trang tài liệu hướng dẫn, bài viết) thường cần b gần với giá trị mặc định hơn. Điểm yếu cốt lõi của BM25 là sự lệch pha từ vựng: nếu người dùng hỏi "làm sao để tôi lấy lại tiền" và tài liệu chỉ ghi "chính sách hoàn tiền", BM25 không tìm thấy token chung nào và không trả về gì hữu ích.
Cơ chế của Vector Search dày (và nơi nó gãy)
Vector search ánh xạ văn bản thành các embedding có số chiều cố định bằng một mô hình, sau đó tìm các vector lân cận qua độ tương đồng cosine hoặc tích vô hướng, thường được tăng tốc bằng một chỉ mục láng giềng gần nhất xấp xỉ. HNSW là thuật toán thống trị trên Weaviate, Qdrant và Milvus, đánh đổi một lượng nhỏ recall để đổi lấy tốc độ vượt trội ở quy mô lớn.
Đây chính là thứ khắc phục vấn đề lệch pha từ vựng của BM25: "lấy lại tiền" và "chính sách hoàn tiền" nằm gần nhau trong không gian embedding ngay cả khi không có token chung nào, vì mô hình nắm bắt ý nghĩa chứ không phải dạng bề mặt. Việc chọn đúng mô hình ở đây cực kỳ quan trọng. Xem hướng dẫn của chúng tôi về chọn mô hình embedding phù hợp, và bài phân tích cách chúng tôi so sánh embedding của Voyage, OpenAI và Cohere nếu bạn đang cân nhắc các lựa chọn.
Nhưng truy xuất dày có một điểm mù riêng, và nó là hình ảnh phản chiếu điểm mù của BM25. Khi chúng tôi xây hệ thống RAG cho khách hàng, lỗi khớp chính xác mà chúng tôi gặp thường xuyên nhất chẳng hề xa lạ. Đó là một nhân viên hỗ trợ hỏi một mã đơn hàng hoặc SKU cụ thể, và chỉ mục vector tự tin trả về một thứ gì đó tương đồng về ngữ nghĩa nhưng sai. Một mô hình embedding đa dụng không có lý do gì để đặt "SKU-4471" hoặc "ERR_CONN_RST" gần chính nó trong không gian vector so với một token liên quan nhưng sai, vì những chuỗi như vậy hiếm khi xuất hiện như các khái niệm riêng biệt, tách biệt trong dữ liệu huấn luyện. BigData Boutique ghi nhận chính xác kiểu thất bại này bằng các ví dụ về SKU và mã lỗi của chính họ. Đây là một hiện tượng đã được xác lập vững chắc và được chứng thực độc lập trên khắp các hệ triển khai RAG, không phải một lỗi kỳ quặc xảy ra một lần.
Cách kết hợp BM25 và Vector Search: RRF vs Hợp nhất có trọng số Alpha
Có hai cách thực sự để hợp nhất kết quả BM25 và vector, và gần như không ai viết về tìm kiếm hybrid lại đối chiếu chúng một cách rõ ràng. Reciprocal Rank Fusion (RRF), từ bài báo SIGIR 2009 của Cormack, Clarke và Buettcher, vận hành trên thứ hạng: score = sum(1 / (k + rank_i)) trên mỗi danh sách kết quả, với k thường đặt là 60. Vì nó chỉ quan tâm đến vị trí chứ không phải điểm thô, RRF xử lý sự chênh lệch thang đo giữa điểm không bị chặn của BM25 và khoảng 0-đến-1 của tương đồng cosine mà không phàn nàn gì, và nó không cần tinh chỉnh theo từng kho ngữ liệu.
Hợp nhất có trọng số alpha (lồi) hoạt động khác: final = alpha * dense_score + (1 - alpha) * sparse_score, vận hành trên điểm đã chuẩn hóa thay vì thứ hạng. Nó có thể phản ánh độ lớn của độ tin cậy tốt hơn (một kết quả vector ở độ tương đồng 0,95 trông thực sự mạnh hơn một kết quả ở 0,61), nhưng nó đòi hỏi tinh chỉnh alpha theo từng kho ngữ liệu, và việc tinh chỉnh đó hỏng một cách thầm lặng khi phân phối điểm của bạn dịch chuyển (mô hình embedding mới, kho ngữ liệu được đánh chỉ mục lại, hỗn hợp truy vấn khác).
Trong thực tế, lựa chọn quy về việc bạn tin tưởng mức độ hiệu chuẩn điểm của mình đến đâu. Chạy BM25 nguyên bản với một mô hình embedding đơn lẻ, ổn định, phương pháp trọng số alpha có thể nhỉnh hơn một chút về xếp hạng vì nó dùng khoảng cách điểm thực tế chứ không chỉ vị trí. Nhưng mức hiệu chuẩn đó trôi dạt nhiều hơn mọi người tưởng. Thay một phiên bản mô hình embedding mới, chia lại chunk tài liệu, hoặc thêm một lượt xếp hạng lại (reranking) ở thượng nguồn, và phân phối điểm dày của bạn dịch chuyển. Chẳng ai bị gọi dậy lúc nửa đêm khi alpha=0,6 không còn là giá trị đúng; thứ hạng chỉ lặng lẽ tệ đi một chút, và rất dễ bỏ lỡ trừ khi bạn chạy các bài eval truy xuất thường xuyên. RRF tránh hoàn toàn chuyện này vì nó không bao giờ nhìn vào điểm thô, chỉ nhìn vị trí thứ hạng, nên một lần đánh chỉ mục lại hay đổi mô hình không thể làm nó hỏng thầm lặng theo cách mà phương pháp trọng số alpha có thể hỏng.
RRF không cần tinh chỉnh theo từng kho ngữ liệu; trọng số alpha cần được trông chừng liên tục khi dữ liệu của bạn thay đổi.
Các engine chia rẽ về mặc định. Weaviate phơi bày cả RRF lẫn một tham số alpha mà bạn đặt tường minh. Elasticsearch cung cấp RRF bản địa qua API retriever của nó (hãy xác nhận chính xác phiên bản bị chặn trong hệ triển khai của bạn; tính năng này hạ cánh vào dòng 8.x). Qdrant hỗ trợ RRF bản địa qua Query API của nó. Tính năng hybrid của Pinecone thường dựa trên tổ hợp lồi có trọng số alpha thay vì phơi bày RRF trực tiếp. Nếu bạn không chắc nên với lấy cái nào, hãy bắt đầu với RRF. Đó là lựa chọn mặc định ít phải bảo trì hơn.
RRF từ số 0: Một ví dụ Python không phụ thuộc nhà cung cấp
Mọi mẫu code RRF mà chúng tôi tìm thấy trong các hướng dẫn cạnh tranh đều bị khóa vào SDK của một nhà cung cấp: client của Weaviate, client của Qdrant, client của Pinecone. Đây là một phiên bản không phụ thuộc framework mà bạn có thể thả vào bất kỳ stack nào, với k=60 làm giá trị mặc định chuẩn:
def reciprocal_rank_fusion(result_lists, k=60):
"""
result_lists: list of ranked lists, each a list of document IDs
ordered from most to least relevant.
k: RRF constant (60 is the standard default from Cormack et al., 2009).
Returns: list of (doc_id, fused_score) sorted descending by score.
"""
scores = {}
for result_list in result_lists:
for rank, doc_id in enumerate(result_list, start=1):
scores[doc_id] = scores.get(doc_id, 0.0) + 1.0 / (k + rank)
return sorted(scores.items(), key=lambda item: item[1], reverse=True)
# Example usage:
bm25_hits = ["doc_9", "doc_2", "doc_14", "doc_1"]
vector_hits = ["doc_2", "doc_1", "doc_9", "doc_30"]
fused = reciprocal_rank_fusion([bm25_hits, vector_hits])
for doc_id, score in fused:
print(f"{doc_id}: {score:.4f}")Đó là toàn bộ thuật toán. Không SDK, không khóa chặt vào nhà cung cấp, và nó hoạt động bất kể hai danh sách xếp hạng của bạn đến từ Elasticsearch và một chỉ mục Faiss, hay từ ts_rank của Postgres và pgvector. Nếu bạn tự chạy mô hình thay vì gọi API, hãy xem chạy mô hình embedding cục bộ với Ollama.
Postgres + pgvector: Tìm kiếm Hybrid không cần cơ sở dữ liệu vector chuyên dụng
Bạn không cần một cơ sở dữ liệu vector chuyên dụng để chạy tìm kiếm hybrid. Theo một benchmark pg_textsearch/pgvector của nhà phát triển Pedro Alonso (Postgres 17, pg_textsearch 1.3.0, pgvector 0.8.2, embedding nomic-embed-text, tập dữ liệu BEIR SciFact), một phiên bản Postgres đơn lẻ chạy ts_rank bản địa chỉ đạt 0,07 NDCG@10, thua xa 0,69 của BM25, 0,66 của pgvector và 0,70 của hybrid, tất cả trong cùng một phiên bản, với RRF hybrid đạt trung vị khoảng 11,5ms.
Con số 0,07 đó là dấu hiệu nhận biết: ts_rank tích hợp sẵn của Postgres là một bộ xếp hạng theo mật độ bao phủ, không phải BM25 thực sự. Nếu bạn muốn chấm điểm BM25 thật trong Postgres, bạn cần một extension. pg_textsearch, VectorChord và ParadeDB đều thêm kiểu xếp hạng chuẩn BM25 mà ts_rank bản địa không cung cấp. Ghép một trong số chúng với pgvector cho độ tương đồng dày, hợp nhất hai danh sách đã xếp hạng bằng hàm RRF ở trên, và bạn có tìm kiếm hybrid trong một phiên bản Postgres duy nhất mà không cần chạy hạ tầng riêng biệt.
Đại khái đây là diện mạo của cặp đôi đó trong một truy vấn đơn lẻ, kết hợp một hạng từ vựng từ một extension có khả năng BM25 với một khoảng cách vector từ pgvector:
WITH lexical AS (
SELECT id, ts_rank_cd(body_tsv, query) AS rank
FROM documents, plainto_tsquery('english', 'refund policy') query
WHERE body_tsv @@ query
ORDER BY rank DESC LIMIT 50
),
semantic AS (
SELECT id, embedding <=> '[0.012, -0.045, ...]' AS distance
FROM documents
ORDER BY distance LIMIT 50
)
SELECT * FROM lexical
FULL OUTER JOIN semantic USING (id);Đưa cả hai tập kết quả vào hàm RRF ở trên và bạn có tìm kiếm hybrid trong một phiên bản Postgres. Giới hạn trung thực: cách này trụ vững tốt đến mức vài triệu dòng, nhưng Postgres không được xây như một engine truy xuất chuyên dụng. Bạn tự chịu trách nhiệm tinh chỉnh chỉ mục, ts_rank_cd thuần vẫn không phải BM25 thật nếu không có extension, và bạn không có sẵn reranking tích hợp hay hỗ trợ đa vector mà Weaviate hoặc Milvus cung cấp bản địa. Nếu kho ngữ liệu của bạn ở cỡ nhỏ đến vừa và bạn đã chạy Postgres, cách này tiết kiệm cho bạn cả một mảnh hạ tầng thứ hai. Vượt quá vài chục triệu tài liệu, hoặc nếu bạn cần reranking nâng cao, một engine chuyên dụng mới đáng đồng tiền.
Nếu bạn đang cân nhắc Qdrant, Chroma hay pgvector cho stack của mình nói chung, đó là một quyết định riêng biệt với chính phương pháp hợp nhất. Xem so sánh Qdrant, Chroma và pgvector của chúng tôi để biết các đánh đổi.
Những cơ sở dữ liệu vector nào hỗ trợ tìm kiếm Hybrid bản địa?
Hầu hết các cơ sở dữ liệu vector hiện đại giờ đều cung cấp tìm kiếm hybrid ngay khi xuất xưởng, nhưng phương pháp hợp nhất mà chúng mặc định khác nhau một cách có ý nghĩa.
| Engine | Hỗ trợ Hybrid bản địa | Phương pháp hợp nhất | Ghi chú |
|---|---|---|---|
| Weaviate | Có | RRF hoặc trọng số alpha | Phơi bày cả hai, bạn chọn theo từng truy vấn |
| Qdrant | Có | RRF | Qua Query API |
| Elasticsearch | Có | RRF | Qua API retriever |
| OpenSearch | Có | Chuẩn hóa + tổng có trọng số | Dùng "bộ xử lý chuẩn hóa" |
| Vespa | Có | Hợp nhất bản địa | Một trong những engine sớm nhất hỗ trợ điều này |
| Milvus | Có | Đa vector + BM25 thưa | Hybrid qua API tìm kiếm kết hợp |
| pgvector + Postgres | Có (với một extension) | RRF thủ công (xem ở trên) | Cần extension ts_rank/BM25 để chấm điểm từ vựng thật |
Hãy xác minh chính xác phiên bản bị chặn trước khi bạn cam kết. Các tính năng hybrid đã hạ cánh nhanh chóng trên khắp các engine này trong suốt năm 2026, và hình dạng API thay đổi qua từng bản phát hành. Để có một quyết định mua hàng rộng hơn ngoài cơ chế hợp nhất, hãy xem bài tổng hợp đầy đủ về các cơ sở dữ liệu vector tốt nhất của chúng tôi.
Tìm kiếm Hybrid có đáng với sự phức tạp?
Tìm kiếm hybrid đúng đắn về mặt kiến trúc khi kho ngữ liệu của bạn có cả các mẫu khớp chính xác (SKU, ID, thuật ngữ hiếm) lẫn các truy vấn mang tính khái niệm, được diễn giải lại. Nếu kho ngữ liệu của bạn không có cả hai (nội dung thuần tường thuật, không có định danh nào mà người ta tìm bằng chuỗi nguyên văn), bạn có thể đang thêm sự phức tạp hợp nhất để đổi lấy một mức tăng mà bạn hầu như không nhận thấy.
Hãy nghĩ xem "chỉ tường thuật" thực sự trông như thế nào: một kho lưu trữ blog công ty, một wiki kỹ thuật nội bộ đầy những runbook nặng văn xuôi, một trang tài liệu không ai tìm theo mã sản phẩm hay số vé. Trong những kho ngữ liệu đó, chỉ riêng vector search thường đã mang lại cho bạn phần lớn giá trị, và bước hợp nhất chỉ thêm một lượt truy xuất thứ hai cùng một tham số mà giờ đây ai đó phải sở hữu, để đổi lấy một mức tăng làm tròn thành nhiễu. So sánh điều đó với một hệ thống vé hỗ trợ hay một danh mục thương mại điện tử, nơi SKU, mã đơn hàng và mã model xuất hiện trong truy vấn của người dùng thật thường xuyên. Đó mới là bài kiểm tra thực sự: rút mười truy vấn thật từ nhật ký của chính bạn và đếm xem có bao nhiêu câu chứa một định danh chính xác mà một mô hình embedding dựa trên diễn giải sẽ không bao giờ đặt đúng vị trí. Số 0, bỏ qua hybrid. Nhiều hơn một hoặc hai, hãy xây nó.
Tìm kiếm hybrid không phải một bản nâng cấp phổ quát, nếu kho ngữ liệu của bạn không có SKU, ID hay tra cứu thuật ngữ hiếm, bạn có thể đang thêm sự phức tạp hợp nhất để đổi lấy một mức tăng mà bạn sẽ không bao giờ nhận thấy.
Chi phí là có thật nhưng có giới hạn: một lượt truy xuất thứ hai, một bước hợp nhất, và một tham số trọng số mà giờ đây ai đó phải sở hữu. Chúng tôi cố tình không trích dẫn một con số độ trễ ở đây, vì những con số trôi nổi ngoài kia đến từ những hệ thống không nêu tên trên phần cứng không nêu tên, và hệ thống của bạn sẽ khác. Hãy đo trên chính kho ngữ liệu của bạn trước khi quyết định. Hai luồng Hacker News nắm bắt đúng sự căng thẳng của người thực hành ở đây: "Hybrid Search Is Just the Beginning: Optimizing the R in RAG" và "Better RAG Results with Reciprocal Rank Fusion and Hybrid Search". Cả hai luồng đều phản bác việc áp dụng hybrid như một thực hành tốt nhất mang tính sùng bái hàng hóa (cargo-cult) mà không kiểm tra trước xem kho ngữ liệu của bạn thậm chí có những kiểu truy vấn mà nó được thiết kế để giải hay không. Trước khi xây, đáng để hiểu cách thực sự đo chất lượng truy xuất: các con số NDCG và recall@k chỉ có ý nghĩa khi đối chiếu với chính kho ngữ liệu của bạn, không phải một tập dữ liệu benchmark.
Quan điểm của chúng tôi: mặc định chọn hybrid cho bất kỳ hệ thống RAG nào phục vụ truy vấn hỗ trợ người dùng cuối, thương mại điện tử hoặc vé. Những khối lượng công việc đó gần như luôn trộn lẫn định danh với ngôn ngữ tự nhiên. Bỏ qua nó với các kho ngữ liệu chỉ có tường thuật (tài liệu dài, wiki dạng kể chuyện) cho đến khi bạn đã đo được một khoảng trống thực sự mà truy xuất đơn phương pháp để ngỏ.
Về tác giả
Mert Batur là Đồng sáng lập của Techsy.io, nơi đội ngũ triển khai các AI agent, hệ thống tự động hóa và pipeline giọng nói/SDR cho khách hàng B2B. Anh viết về stack công cụ LLM mà đội Techsy thực sự dùng trong production. Kết nối trên LinkedIn.
Câu hỏi thường gặp
Hybrid search trong RAG là gì?
Tìm kiếm hybrid chạy truy xuất BM25 (từ khóa) và vector (ngữ nghĩa) như các lượt riêng biệt trên cùng một truy vấn, sau đó gộp hai danh sách đã xếp hạng bằng một thuật toán hợp nhất, thường là Reciprocal Rank Fusion. Nó bắt được cả truy vấn khớp chính xác lẫn truy vấn khái niệm được diễn giải lại, những thứ mà không phương pháp đơn lẻ nào xử lý được một mình.
BM25 có giống vector search không?
Không. BM25 là tìm kiếm từ vựng thưa, chấm điểm độ trùng khớp và độ hiếm của thuật ngữ chính xác. Vector search là tìm kiếm ngữ nghĩa dày dùng embedding và phép toán tương đồng. Chúng là hai phương pháp truy xuất khác nhau với thế mạnh trái ngược, còn tìm kiếm hybrid kết hợp chứ không thay thế bất kỳ phương pháp nào.
Làm sao để kết hợp BM25 và vector search?
Chạy cả hai phương pháp truy xuất một cách độc lập trên cùng một truy vấn, sau đó hợp nhất hai danh sách kết quả đã xếp hạng, phổ biến nhất là bằng Reciprocal Rank Fusion, vốn cộng tổng 1 / (k + rank) trên mỗi danh sách. Tổ hợp điểm có trọng số alpha là lựa chọn thay thế, nhưng nó cần tinh chỉnh theo từng kho ngữ liệu mà RRF thì không.
Reciprocal Rank Fusion (RRF) là gì?
RRF là một thuật toán hợp nhất từ bài báo SIGIR 2009 của Cormack, Clarke và Buettcher, kết hợp nhiều danh sách đã xếp hạng bằng cách cộng tổng 1 / (k + rank) cho mỗi tài liệu, với k thường đặt là 60. Nó hoạt động trên vị trí thứ hạng chứ không phải điểm thô, nên nó giữ được ổn định trước sự chênh lệch thang đo giữa các phương pháp truy xuất.
Sự khác biệt giữa RRF và hợp nhất có trọng số alpha là gì?
RRF kết hợp các thứ hạng và không cần tinh chỉnh theo từng kho ngữ liệu. Hợp nhất có trọng số alpha kết hợp các điểm đã chuẩn hóa bằng một tham số alpha có thể tinh chỉnh, thứ có thể phản ánh độ lớn của độ tin cậy tốt hơn nhưng đòi hỏi tinh chỉnh lại liên tục mỗi khi phân phối điểm dịch chuyển, chẳng hạn sau một lần đánh chỉ mục lại hoặc đổi mô hình.
Khi nào tôi nên dùng tìm kiếm hybrid thay vì chỉ vector search?
Hãy dùng tìm kiếm hybrid khi truy vấn của bạn trộn lẫn các định danh chính xác (SKU, mã đơn hàng, mã lỗi) với các câu hỏi ngôn ngữ tự nhiên, mang tính khái niệm; các hệ thống hỗ trợ, thương mại điện tử và vé thường như vậy. Bỏ qua nó với nội dung chỉ có tường thuật, không có định danh, nơi sự phức tạp hợp nhất thêm vào có thể không cho thấy mức tăng nào đo được.
Vì sao vector search bỏ lỡ các khớp chính xác như SKU hay mã lỗi?
Các mô hình embedding học từ những mẫu ngôn ngữ tổng quát, và những chuỗi như "SKU-4471" hay "ERR_CONN_RST" hiếm khi xuất hiện như các khái niệm riêng biệt, tách biệt trong dữ liệu huấn luyện. Mô hình không có lý do đủ mạnh để đặt chuỗi chính xác đó gần chính nó hơn là gần một token liên quan về ngữ nghĩa nhưng sai.
Những cơ sở dữ liệu vector nào hỗ trợ tìm kiếm hybrid bản địa?
Weaviate, Qdrant, Elasticsearch, OpenSearch, Vespa và Milvus đều cung cấp tìm kiếm hybrid bản địa tính đến năm 2026, dù phương pháp hợp nhất mặc định của chúng khác nhau (RRF vs trọng số alpha vs chuẩn hóa). Postgres với pgvector cũng có thể chạy tìm kiếm hybrid, nhưng cần một extension BM25 vì ts_rank bản địa không phải BM25 thật.
Tìm kiếm hybrid có đáng với sự phức tạp thêm vào?
Với các kho ngữ liệu trộn lẫn truy vấn khớp chính xác và khái niệm, có. RRF thuần đã vượt bất kỳ phương pháp đơn lẻ nào trên benchmark WANDS (0,7068 so với 0,6983 của BM25), và một biến thể đã tinh chỉnh đạt mức tăng 7,4% (0,7497). Với các kho ngữ liệu chỉ có tường thuật, không có định danh, lượt truy xuất thứ hai và việc tinh chỉnh hợp nhất mà nó cần có thể lớn hơn cả mức tăng mà bạn sẽ không nhận thấy. Hãy đo trước khi cam kết.
Postgres/pgvector có thể làm tìm kiếm hybrid mà không cần cơ sở dữ liệu vector chuyên dụng không?
Có. Ghép pgvector cho độ tương đồng dày với một extension BM25 thật như pg_textsearch, VectorChord hoặc ParadeDB (chỉ riêng ts_rank bản địa chỉ đạt 0,07 NDCG@10 trong benchmark pg_textsearch/pgvector của Pedro Alonso, so với 0,70 của hybrid), sau đó hợp nhất hai danh sách đã xếp hạng bằng RRF, tất cả bên trong một phiên bản Postgres.
Cả hai phương pháp truy xuất đều để ngỏ những khoảng trống thực sự khi chạy một mình: BM25 bỏ lỡ diễn giải lại, vector search bỏ lỡ định danh chính xác, và hợp nhất chúng bằng RRF là cách ít phải bảo trì hơn để khép cả hai. Nếu bạn đang cân nhắc tự xây hay mời một đội đã từng triển khai truy xuất RAG trước đó, hướng dẫn đầy đủ về xây dựng ứng dụng RAG của chúng tôi bao quát bước tiếp theo, hoặc liên hệ nếu bạn muốn Techsy cùng xây với bạn.