Hybrid Search là gì?

Hybrid search (tìm kiếm lai) là một kỹ thuật truy xuất thông tin vận hành song song tìm kiếm từ vựng (thường là BM25) và tìm kiếm vector ngữ nghĩa, sau đó hợp nhất các kết quả đã được xếp hạng của chúng — phổ biến nhất là bằng Reciprocal.

TL;DR

Hybrid search chạy truy xuất từ khóa (BM25) và truy xuất vector (dense vector) cùng lúc, rồi hợp nhất hai danh sách xếp hạng thành một. Phía từ khóa nắm bắt các thuật ngữ chính xác, định danh (identifiers). Đồng thời, các token hiếm gặp. Phía vector nắm bắt các cách diễn đạt tương đương (paraphrases) và khớp nối các khái niệm (conceptual matches). Đối với hầu hết các hệ thống RAG trong môi trường thực tế (production), truy xuất lai là lựa chọn mặc định — chỉ dùng vector hay chỉ dùng từ khóa đều có những điểm mù riêng mà phương pháp kia có thể bù đắp.

Định nghĩa

Hybrid search là một kỹ thuật truy xuất thông tin kết hợp hai hoặc nhiều phương thức truy xuất — điển hình là một công cụ truy xuất từ vựng thưa (sparse lexical retriever) và một công cụ truy xuất ngữ nghĩa dày (dense semantic retriever) — thành một danh sách kết quả được xếp hạng chung. Mỗi công cụ truy xuất sẽ độc lập chấm điểm các tài liệu dựa trên cùng một truy vấn, sau đó một bước hợp nhất (fusion step) sẽ gộp các bảng xếp hạng đó lại thành một thứ tự cuối cùng trước khi trả về cho client.

Cấu hình phổ biến nhất là kết hợp BM25 (một hàm xếp hạng dựa trên tần suất thuật ngữ dạng thưa, được dùng bởi Elasticsearch, OpenSearch, Lucene. Đồng thời, Postgres FTS) với dense vector retrieval (tìm kiếm láng giềng gần nhất - nearest-neighbor search qua các vector nhúng (learned embeddings) sinh ra từ các mô hình như BGE, E5, OpenAI text-embedding-3, hay Cohere Embed). Quá trình hợp nhất (fusion) thường dựa trên một trong hai thuật toán: Reciprocal Rank Fusion (RRF) hoặc hệ kết hợp lồi (convex combination) từ các điểm số đã chuẩn hóa.

Hybrid search đôi khi còn được gọi là sparse-dense retrieval, lexical-semantic search, hoặc fusion search. Bất kể các thuật ngữ tiếp thị, nguyên lý cốt lõi không thay đổi: chạy song song nhiều công cụ truy xuất bổ trợ cho nhau và sử dụng một thuật toán hợp nhất có nhận biết thứ hạng (rank-aware fusion) để quyết định kết quả nào sẽ được xếp hạng cao nhất.

Tại sao Hybrid Search lại quan trọng

Tìm kiếm thuần vector hay thuần từ khóa đều có những hạn chế ngược nhau. Đồng thời, những sai lệch này lập tức bộc lộ khi triển khai trên một khối lượng tài liệu (corpus) thực tế với người dùng thực.

Hạn chế khi chỉ dùng vector: Công cụ truy xuất dense nén ngữ nghĩa vào một không gian vector có số chiều cố định (fixed-dimensional). Sự nén này làm mất đi các chi tiết cụ thể. Số định danh (identifiers), mã phiên bản, mã lỗi, mã sản phẩm (SKU), trích dẫn điều lệ, tên lệnh, các chữ viết tắt (acronyms). Đồng thời, các token hiếm đều dễ dàng bị hội tụ về các biểu diễn vector tương tự nhau, dẫn đến khả năng đối khớp yếu. Ví dụ, một truy vấn "Chính sách PTO" bằng vector có thể truy xuất các tài liệu về "kỳ nghỉ (vacation time)" nhưng lại bỏ lỡ các tài liệu chứa chính xác từ viết tắt PTO — đây là một lỗi thường gặp trong các hệ thống RAG dành cho doanh nghiệp.

Hạn chế khi chỉ dùng từ khóa: BM25 hoạt động theo cơ chế túi từ (bag-of-words). Nó không hiểu rằng "hủy đăng ký (cancel my subscription)" và "ngừng thanh toán (stop billing)" chia sẻ cùng một ý định (intent). Nó không thể vượt qua rào cản từ đồng nghĩa, cấu trúc diễn đạt, hay đa ngôn ngữ nếu không có quá trình mở rộng truy vấn (query expansion). Đối với các câu hỏi bằng ngôn ngữ tự nhiên, việc chỉ dùng BM25 sẽ làm giảm đáng kể khả năng thu hồi (recall).

Hybrid search giải quyết những hạn chế đó. Bằng cách chạy song song và hợp nhất hai hệ thống, một tài liệu chỉ cần có một tín hiệu tốt từ một trong hai hệ thống để được lọt vào tập ứng viên (candidate set). Đồng thời, nếu có cả hai tín hiệu, nó sẽ được xếp hạng rất cao. Tài liệu của Azure AI Search chỉ rõ rằng kỹ thuật hybrid kết hợp với xếp hạng ngữ nghĩa (semantic ranking) mang lại "những cải tiến đáng kể về độ phù hợp (search relevance)" trên cả các bộ dữ liệu benchmark và trong thực tế. Các nền tảng như Elastic, Weaviate, OpenSearch, MongoDB Atlas, và Redis đều tích hợp hybrid search như một tính năng cốt lõi.

Đặc biệt đối với AI search và RAG, chi phí của việc truy xuất thiếu một phân đoạn (chunk) là rất cao: LLM không thể trích dẫn thông tin mà nó không được cung cấp. Hybrid search làm tăng xác suất đưa được phân đoạn chính xác vào tập top-k đầu ra, từ đó tác động trực tiếp đến khả năng tạo sinh câu trả lời chính xác và có cơ sở (grounded) của LLM.

Cách thức hoạt động

Một pipeline Hybrid search điển hình có bốn bước: chuẩn bị truy vấn, truy xuất song song, hợp nhất (fusion), và có thể có xếp hạng lại (reranking).

flowchart LR
    Q["Truy vấn người dùng (User query)"] --> QE["Chuẩn bị truy vấn
(tokenize + embed)"]
    QE --> BM25["BM25 retriever
(thưa / từ vựng)"]
    QE --> DENSE["Dense retriever
(vector ANN)"]
    BM25 --> R1["Danh sách xếp hạng A"]
    DENSE --> R2["Danh sách xếp hạng B"]
    R1 --> FUSE["Hợp nhất (Fusion)
(RRF hoặc convex combo)"]
    R2 --> FUSE
    FUSE --> RR["Xếp hạng lại (Cross-encoder)
(Tùy chọn)"]
    RR --> TOPK["Kết quả Top-k"]

Chuẩn bị truy vấn. Câu hỏi đầu vào được tạo token (tokenize) cho công cụ lexical và tạo embedding cho công cụ dense. Từ cùng một chuỗi đầu vào, hai biểu diễn khác nhau được tạo ra — một cho BM25 và một tập vector số thực (float) cho truy xuất dense.

Truy xuất song song. BM25 chấm điểm các văn bản qua tính toán tần suất thuật ngữ (term frequency), tần suất nghịch đảo tài liệu (inverse document frequency). Đồng thời, chuẩn hóa chiều dài (length normalization). Trong khi đó, truy xuất dense tìm kiếm các láng giềng gần nhất xấp xỉ (approximate nearest-neighbor - ANN) trong cơ sở dữ liệu vector thông qua các thuật toán như HNSW hoặc IVF. Mỗi công cụ truy xuất sẽ trả về danh sách top-k của riêng nó (thường k=100 trước quá trình hợp nhất).

Hợp nhất (Fusion). Đây là bước kết hợp hai danh sách kết quả. Hai thuật toán phổ biến nhất là:

Thuật toán	Cơ chế hoạt động	Ưu điểm	Nhược điểm
Reciprocal Rank Fusion (RRF)	score(d) = Σ 1 / (k + rank_i(d)) với k≈60	Độc lập với thang điểm (Score-agnostic); không yêu cầu chuẩn hóa; ít bị ảnh hưởng bởi nhiễu (outliers); hoạt động tốt ngay lập tức (zero-shot)	Bỏ qua độ lớn của điểm số; không thể đặt trọng số ưu tiên cho một hệ thống truy xuất cụ thể; nhạy cảm với hằng số `k` ở một số quy mô
Kết hợp lồi (Convex combination - CC)	score(d) = α · norm(bm25) + (1-α) · norm(dense)	Cho phép điều chỉnh trọng số (weighting); có khả năng thích ứng thông qua một tham số; thường vượt trội hơn RRF nếu α được tinh chỉnh kỹ	Cần bước chuẩn hóa thang điểm (normalization); tham số α cần được điều chỉnh tùy theo từng tập dữ liệu (domain)

RRF được đề xuất bởi Cormack và cộng sự trong báo cáo tại hội nghị SIGIR năm 2009 và hiện là thuật toán mặc định trên nhiều nền tảng lớn như Azure AI Search, OpenSearch 2.19+, Elasticsearch và MongoDB Atlas. Các nghiên cứu gần đây cho thấy thuật toán kết hợp lồi (convex combination) nếu được tinh chỉnh thông số có thể mang lại hiệu suất tốt hơn RRF ở cả không gian in-domain và out-of-domain, nhưng đòi hỏi tài nguyên để tinh chỉnh trọng số α.

Xếp hạng lại bằng Cross-encoder (Tùy chọn). Nhiều hệ thống thực tế bổ sung thêm một mô hình cross-encoder (như bge-reranker, Cohere Rerank, hoặc MiniLM) để chấm điểm lại 50 đến 100 tài liệu top đầu bằng cách phân tích đồng thời cặp truy vấn - tài liệu. Kỹ thuật này tốn nhiều tài nguyên tính toán hơn so với truy xuất ban đầu nhưng giúp cải thiện đáng kể chỉ số NDCG do hệ thống có thể đánh giá ngữ cảnh trực tiếp thay vì chỉ dựa trên các vector độc lập.

Kết quả cuối cùng trả về hệ thống sẽ bao gồm các định danh tài liệu (document IDs) để ứng dụng có thể hiển thị kết quả hoặc cung cấp cho Mô hình Ngôn ngữ Lớn (LLM).

So sánh: Cấu trúc Thuần Lexical, Thuần Semantic và Hybrid

Mỗi phương pháp truy xuất có những thế mạnh riêng. Bảng dưới đây tóm tắt sự khác biệt:

Đặc tính	Thuần Lexical (BM25)	Thuần Semantic (Dense vector)	Hybrid (BM25 + Dense + Fusion)
Mức độ khớp chính xác (Exact-term)	Cao	Thấp - Trung bình	Cao
Khả năng xử lý từ đồng nghĩa (Paraphrase)	Thấp	Cao	Cao
Xử lý token đặc thù (SKU, mã lỗi, từ viết tắt)	Rất tốt	Kém	Rất tốt
Truy vấn ngôn ngữ tự nhiên dài	Trung bình	Rất hiệu quả	Rất hiệu quả
Khả năng khởi động (Cold-start)	Chạy ngay (Works zero-shot)	Cần mô hình embedding phù hợp	Chạy ngay (Works zero-shot)
Kích thước chỉ mục (Index size)	Nhỏ	Lớn (vector floats + ANN graph)	Rất lớn (Kết hợp cả hai)
Độ trễ truy vấn (Query latency)	Rất thấp	Thấp - Trung bình	Cao hơn một chút (do xử lý song song)
Chi phí vận hành (Operational cost)	Thấp	Cao (Chi phí embedding + RAM)	Cao nhất
Điểm yếu chính (Failure mode)	Kém khi gặp từ đồng nghĩa hoặc diễn giải khác	Khó nhận diện danh từ riêng và định danh	Hai hệ thống bổ trợ lẫn nhau

Khi hoạt động độc lập, BM25 có chi phí rất thấp. GitHub nổi tiếng với việc sử dụng BM25 cho tính năng tìm kiếm mã nguồn trên hơn 100 tỷ tài liệu, cho thấy nó cực kỳ hiệu quả khi so với các giải pháp AI đắt đỏ. Tuy nhiên, nếu xây dựng một hệ thống FAQ để xử lý các câu hỏi đa dạng của khách hàng, truy xuất vector (dense retrieval) lại thể hiện ưu thế vượt trội.

Đối với các dự án lưu trữ tài liệu tổng hợp, hồ sơ dự án, hoặc cơ sở tri thức, Hybrid search là giải pháp cân bằng và tối ưu nhất. Chi phí tính toán bổ sung là hoàn toàn xứng đáng với giá trị từ việc truy xuất thông tin chính xác.

Triển khai thực tiễn

Hầu hết các công cụ tìm kiếm cấp doanh nghiệp hiện nay đều hỗ trợ Hybrid search mặc định. Mặc dù cấu hình chi tiết có thể khác nhau, nguyên lý vận hành chung vẫn tuân theo cơ chế truy xuất song song và hợp nhất.

Elasticsearch / OpenSearch: Hỗ trợ sẵn RRF trong core engine. Plugin Neural Search từ phiên bản 2.19 của OpenSearch tích hợp RRF để kết hợp truy vấn Boolean, k-NN và dense vector nhằm tối ưu hóa relevance. Elasticsearch cũng cung cấp khả năng kết hợp BM25 và module k-NN một cách liền mạch.

Azure AI Search: Cung cấp tính năng truy vấn lai, thực thi song song BM25 và vector search, sau đó hợp nhất qua RRF. Người dùng có thể bật tính năng semantic ranking (sử dụng cross-encoder) để thực hiện bước xếp hạng lại nâng cao.

Weaviate: Hỗ trợ kết hợp truy xuất sparse (như BM25) với truy xuất dense, cho phép sử dụng RRF truyền thống hoặc tinh chỉnh hệ số trọng số α. Tài liệu của Weaviate khuyến nghị cấu hình này cho hầu hết các trường hợp sử dụng RAG.

Pinecone: Tính năng sparse-dense của Pinecone cho phép lưu trữ và truy vấn đồng thời vector sparse và vector dense trên cùng một chỉ mục, cung cấp một hệ thống kết hợp hiệu quả và tối ưu hiệu suất.

Vespa: Hỗ trợ linh hoạt thông qua hàm nativeRank và dotproduct, cho phép kết hợp các điểm số lexical và semantic theo nhiều phương pháp lập trình phức tạp.

MongoDB Atlas: Module Atlas Vector Search tích hợp cơ chế $rankFusion để tự động kết hợp truy vấn $search (BM25) và $vectorSearch (Dense) thông qua RRF.

Redis: Redis Stack cung cấp lệnh FT.HYBRID. Điều này cho phép kết hợp điểm số tương đồng vector (vector similarity) với điểm số văn bản thuần túy (full-text scoring) một cách trực tiếp.

Các khuyến nghị triển khai:

Thuật toán hợp nhất: Sử dụng RRF với hằng số k=60 làm cấu hình mặc định an toàn cho các tập dữ liệu lớn nếu bạn không có dữ liệu đánh giá để tinh chỉnh.
Kích thước tập ứng viên (per-retriever k): Lấy top k=100 từ mỗi công cụ truy xuất trước khi hợp nhất, sau đó chọn top 10-20 kết quả cuối cùng cho LLM.
Mô hình Embedding phù hợp: Lựa chọn mô hình embedding phù hợp với lĩnh vực (domain). Sự sai lệch về domain (ví dụ: dùng mô hình y tế để xử lý tài liệu kỹ thuật) sẽ làm giảm đáng kể hiệu suất của truy xuất vector.
Sử dụng Cross-encoder: Nếu hệ thống yêu cầu độ chính xác cao và số lượng kết quả top k cuối cùng ít (≤10), việc sử dụng cross-encoder reranker là cực kỳ cần thiết.
Đo lường bằng chỉ số chuẩn: Sử dụng các chỉ số như Recall@K, MRR, hoặc NDCG cùng với tập dữ liệu được dán nhãn (labeled judgment set) để đánh giá khách quan hiệu năng của pipeline truy xuất thay vì chỉ dựa vào phản hồi của LLM.

Các ví dụ ứng dụng

Tìm kiếm mã sản phẩm (SKU): Với truy vấn "XPS-9520-i7", hệ thống BM25 sẽ tìm chính xác mã SKU này, trong khi truy xuất vector có thể đề xuất các dòng máy tương đương. Hybrid search sẽ đặt kết quả khớp chính xác lên vị trí đầu tiên và sử dụng các kết quả vector cho các vị trí tiếp theo.

Tra cứu tài liệu Nhân sự (Chính sách PTO): Truy xuất vector sẽ tìm thấy các điều khoản liên quan đến "thời gian nghỉ phép (vacation time)", trong khi BM25 sẽ tìm chính xác từ khóa "PTO". Hybrid search trả về một danh sách toàn diện bao gồm cả hai khía cạnh.

Tra cứu mã nguồn: Khi tìm "useEffect cleanup memory leak", BM25 bắt chính xác các từ khóa, trong khi truy xuất vector có thể hiểu các mô tả về vòng đời component ngay cả khi thuật ngữ không khớp hoàn toàn. Sự kết hợp này mang lại cả tài liệu chính thức và các bài viết kỹ thuật liên quan.

Xử lý sự cố kỹ thuật (IT Support): Khách hàng báo cáo lỗi: "cập nhật hệ điều hành thất bại với mã 0x80070005". BM25 tìm chính xác mã lỗi, trong khi hệ thống vector phân tích phần mô tả sự cố để đối chiếu với các tài liệu hỗ trợ. Hybrid search cung cấp giải pháp khắc phục chính xác.

Nghiên cứu Pháp lý: Khi tra cứu "GDPR Quyền được lãng quên", BM25 tìm chính xác từ khóa trong Điều 17, còn truy xuất vector có thể tìm thấy các tài liệu nói về "xóa dữ liệu" hoặc "thu hồi sự đồng ý". Hybrid search bao phủ cả văn bản luật và các diễn giải liên quan.

Thương mại điện tử Đa ngôn ngữ: Tìm kiếm sản phẩm bằng tiếng Anh trong cơ sở dữ liệu đa ngôn ngữ. BM25 tìm chính xác từ khóa tiếng Anh, trong khi mô hình vector đa ngôn ngữ có thể đối khớp với các sản phẩm tương đương ở ngôn ngữ khác.

Các lỗi triển khai phổ biến

Coi Hybrid search là giải pháp hoàn hảo không cần tối ưu. Một lỗi phổ biến là cho rằng Hybrid search sẽ giải quyết mọi vấn đề. Nếu BM25 không được cấu hình ngôn ngữ phù hợp (analyzer/stemmer) hoặc mô hình vector không phù hợp với domain, kết quả cuối cùng vẫn sẽ kém chất lượng. Hybrid search cần được đo lường thực tế thay vì kỳ vọng mù quáng.

Thiếu chuẩn hóa khi dùng Kết hợp lồi (Convex combination). Khi sử dụng phương pháp kết hợp điểm số, việc không chuẩn hóa thang điểm (ví dụ qua z-score normalization hoặc Min-max) giữa BM25 (có thể không giới hạn) và cosine similarity (từ -1 đến 1) sẽ khiến một hệ thống hoàn toàn lấn át hệ thống còn lại. RRF tránh được lỗi này do đặc tính không phụ thuộc vào độ lớn điểm số (score-agnostic).

Cố định thông số k=60 cho mọi trường hợp. Mặc dù RRF thường dùng k=60 làm mặc định, hằng số này có thể không tối ưu cho các tập dữ liệu có quy mô đặc thù. Khi hệ thống yêu cầu độ chính xác cao, hằng số k cần được tinh chỉnh (sweep) thông qua các tập đánh giá (held-out judgment set).

Đổ lỗi cho LLM thay vì pipeline truy xuất. Khi ứng dụng RAG trả về câu trả lời sai (hallucination), nguyên nhân thường là do hệ thống Hybrid search đã thất bại trong việc truy xuất văn bản cần thiết và đưa nó vào tập top-k. Các chỉ số Recall@K và NDCG cần được ưu tiên đánh giá ở tầng truy xuất trước khi tùy chỉnh LLM.

Bỏ qua chiến lược phân đoạn văn bản (Chunking). Hybrid search vận hành trên các đoạn văn bản (chunks). Nếu phân đoạn quá lớn, độ chính xác của BM25 sẽ giảm. Nếu quá nhỏ, truy xuất vector sẽ mất ngữ cảnh (context). Chiến lược chunking theo ngữ nghĩa (semantic chunking) là bắt buộc.

FAQ

Q: Hybrid search có luôn tốt hơn truy xuất vector thuần túy (pure vector search)?

Không hoàn toàn. Trong các trường hợp tập dữ liệu rất đồng nhất về từ vựng và mô hình vector đã được fine-tune kỹ lưỡng cho domain đó, truy xuất vector thuần túy có thể đạt hiệu suất tương đương với Hybrid search với độ phức tạp hệ thống thấp hơn. Nên đánh giá dựa trên dữ liệu thực tế thay vì mặc định sử dụng Hybrid search cho mọi ứng dụng đơn giản.

Q: Tại sao Reciprocal Rank Fusion (RRF) lại được ưa chuộng như vậy?

RRF được ưa chuộng vì nó không yêu cầu chuẩn hóa điểm số, rất ổn định trước các kết quả nhiễu. Đồng thời, không cần quá trình huấn luyện thông số (zero-shot). Nhờ việc kết hợp dựa trên thứ hạng (rank) thay vì độ lớn điểm số (score magnitude), RRF dễ dàng triển khai ở quy mô lớn trên các nền tảng như Azure và Elasticsearch.

Q: Phương pháp kết hợp lồi (Convex combination) có thể thay thế RRF không?

Có thể. Nếu có đủ dữ liệu đánh giá (judgment data) để tinh chỉnh thông số trọng số α một cách chính xác, hệ thống kết hợp lồi thường vượt trội hơn RRF. Tuy nhiên, nó đòi hỏi quá trình huấn luyện và điều chỉnh liên tục, do đó RRF vẫn là lựa chọn ưu tiên cho các hệ thống cần triển khai nhanh.

Q: Sự khác biệt giữa Hybrid search và RAG là gì?

Hybrid search chỉ là thành phần truy xuất thông tin (Retrieval) bên trong kiến trúc Retrieval-Augmented Generation (RAG). Hybrid search chịu trách nhiệm tìm kiếm các tài liệu phù hợp nhất từ cơ sở dữ liệu, sau đó RAG sẽ sử dụng nội dung của các tài liệu này làm ngữ cảnh (context) để Mô hình Ngôn ngữ Lớn (LLM) tạo ra câu trả lời cuối cùng.

Q: Việc sử dụng một cơ sở dữ liệu vector riêng biệt có bắt buộc cho Hybrid search không?

Không. Nhiều cơ sở dữ liệu hiện đại như Elasticsearch, OpenSearch. Đồng thời, PostgreSQL (với pgvector) có khả năng thực thi cả tìm kiếm toàn văn bản (full-text) và tìm kiếm vector trên cùng một hệ thống. Việc sử dụng cơ sở dữ liệu vector độc lập (như Pinecone hay Milvus) thường phụ thuộc vào yêu cầu về hiệu suất mở rộng quy mô.

Q: Chi phí của Hybrid search so với truy xuất vector thuần túy như thế nào?

Việc bổ sung thêm tìm kiếm từ khóa (BM25) vào một hệ thống truy xuất vector hiện có tốn rất ít chi phí bổ sung về mặt tài nguyên CPU và lưu trữ (index footprint). Phần lớn chi phí (tạo vector embedding, lưu trữ vector HNSW, và tài nguyên bộ nhớ) đã nằm ở thành phần truy xuất vector. Do đó, nâng cấp từ pure vector lên Hybrid search thường có chi phí rất hợp lý.

Q: Khi nào nên sử dụng thêm Cross-encoder reranker?

Nên sử dụng cross-encoder khi tập kết quả cuối cùng cần độ chính xác cực kỳ cao, số lượng kết quả trả về cho LLM ít (k ≤ 10). Đồng thời, hệ thống có thể chấp nhận một độ trễ (latency) tăng thêm (thường vài trăm mili-giây). Cross-encoder hiệu quả nhất khi được dùng để sắp xếp lại danh sách top 50-100 kết quả đã được lọc bởi Hybrid search ban đầu.

Q: Hybrid Search có giống với cách các công cụ AI search engine hoạt động không?

Về nguyên lý cơ bản là tương tự. Các hệ thống lớn như Perplexity hoặc AI Overviews sử dụng cấu trúc phân tầng kết hợp cả đối khớp từ khóa chính xác và ý nghĩa ngữ nghĩa. Việc tối ưu hóa nội dung web để tương thích với cả hai phương thức tìm kiếm này (còn gọi là "citation-readiness") chính là nền tảng của chiến lược Tối ưu hóa Công cụ Trả lời (AEO).