Hybrid Search 是什麼？混合搜尋如何結合關鍵字與語意搜尋

一句話說明

Hybrid Search（混合搜尋）是同時用關鍵字比對和語意理解兩種方式搜尋，再把兩邊的結果合併排序，取兩者的優點。

什麼是 Hybrid Search？

你在公司的知識庫裡搜尋「ERR_CONNECTION_REFUSED 錯誤處理方式」。用語意搜尋的話，它會理解你想找「連線被拒絕的錯誤排除方法」，可能找到一篇標題是「網路連線問題排查指南」的文件——意思對了，但不是你要的那個特定錯誤代碼。用關鍵字搜尋的話，它會精確找到包含「ERR_CONNECTION_REFUSED」這串文字的文件——命中了特定錯誤碼，但可能漏掉一篇用不同措辭描述相同解法的文件。

Hybrid Search 做的就是把這兩種搜尋結合在一起。同時跑關鍵字搜尋和語意搜尋，然後把兩邊的結果合併成一份排序好的清單。這樣你既能精確命中特定的錯誤代碼，又能找到意思相關但用語不同的文件。

這在 RAG 系統中特別重要。RAG 的品質取決於搜尋的品質——如果搜尋階段找到的文件不對，後面 LLM 再厲害也沒用，因為它參考的資料是錯的。Hybrid Search 是目前 RAG 系統中公認最能兼顧精確度和召回率的搜尋方式。

兩種搜尋的差異

要理解 Hybrid Search，先搞清楚它結合的兩種搜尋各自的特性：

比較項目	關鍵字搜尋（BM25）	語意搜尋（向量）
比對方式	字面比對，計算詞頻和文件頻率	意思比對，計算向量距離
同義詞處理	找不到（除非手動設同義詞表）	自動理解
專有名詞/代碼	精確，完全匹配	可能模糊化
跨語言	不支援	支援（看模型）
建置成本	低（Elasticsearch、Lucene）	中高（需要 Embedding 模型和向量資料庫）
搜尋延遲	非常低	稍高
適合場景	精確查找、已知關鍵字、代碼搜尋	自然語言問答、模糊查詢

關鍵字搜尋最常用的演算法是 BM25（Best Matching 25）。它比簡單的字串比對更進一步，會考慮詞頻（一個詞在文件中出現幾次）、逆文件頻率（一個詞在所有文件中有多常見）和文件長度。常見的詞（如「的」「是」）權重低，罕見的詞（如特定的錯誤代碼）權重高。

語意搜尋靠的是 Embedding，把文字轉成高維度的向量，用向量之間的距離（通常是餘弦相似度）來判斷相關性。「蘋果手機維修」和「iPhone 螢幕更換」在向量空間中會靠在一起，即使字面上完全不同。

Hybrid Search 怎麼運作？

Hybrid Search 的流程是這樣的：

第一步，把使用者的查詢同時送進兩個搜尋引擎：關鍵字搜尋引擎（如 BM25）和語意搜尋引擎（如向量資料庫）。

第二步，兩個引擎各自回傳一份排序好的結果清單。關鍵字搜尋回傳按 BM25 分數排序的文件，語意搜尋回傳按向量距離排序的文件。

第三步，用融合演算法把兩份清單合併成一份。這是 Hybrid Search 的核心——怎麼合併決定了最終搜尋品質。

常見的融合演算法

Reciprocal Rank Fusion（RRF）：這是最常用的方法。它不看分數，只看排名。公式是：

RRF(d) = Σ 1 / (k + rank(d))

對每份結果清單，一個文件的 RRF 分數 = 1 / (k + 它在該清單中的排名)。k 是一個常數（通常設 60）。最後把所有清單的 RRF 分數加總。

RRF 的好處是不受個別搜尋引擎分數尺度的影響。BM25 的分數範圍和向量相似度的分數範圍差很多，直接比較沒有意義。RRF 只用排名，避開了這個問題。

加權分數融合（Weighted Score Fusion）：把兩個引擎的分數標準化到 0-1 之間，然後用加權平均合併。例如：

final_score = α × keyword_score + (1-α) × semantic_score

α 的值決定了偏向哪邊。α = 0.7 表示偏向關鍵字搜尋，α = 0.3 表示偏向語意搜尋。α 的最佳值需要根據你的資料和使用場景來調整。

向量資料庫的內建支援

目前主流的向量資料庫大多已經內建了 Hybrid Search 功能：

Weaviate：支援 BM25 + 向量搜尋的混合模式，用 RRF 或加權融合，可以透過 alpha 參數調整比重。

Qdrant：支援 sparse vector（用於關鍵字搜尋）和 dense vector（用於語意搜尋）的組合搜尋，用 RRF 融合。

Pinecone：支援 sparse-dense vector 的混合搜尋。

Milvus：透過 RRFRanker 或 WeightedRanker 支援多路搜尋結果融合。

Elasticsearch：從 8.x 版開始支援 kNN 向量搜尋，可以和傳統的 BM25 搜尋結合使用。

實作範例

用 LangChain 搭配 Weaviate 做 Hybrid Search：

from langchain_weaviate import WeaviateVectorStore
from langchain_openai import OpenAIEmbeddings
import weaviate

client = weaviate.connect_to_local()
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")

vectorstore = WeaviateVectorStore(
    client=client,
    index_name="Documents",
    text_key="content",
    embedding=embeddings,
)

retriever = vectorstore.as_retriever(
    search_type="hybrid",
    search_kwargs={"alpha": 0.5, "k": 5}
)

results = retriever.invoke("ERR_CONNECTION_REFUSED 錯誤處理")

alpha=0.5 表示關鍵字和語意搜尋各佔一半權重。alpha=1.0 是純語意搜尋，alpha=0.0 是純關鍵字搜尋。

用 Qdrant 做 Hybrid Search：

from qdrant_client import QdrantClient, models

client = QdrantClient(url="http://localhost:6333")

results = client.query_points(
    collection_name="documents",
    prefetch=[
        models.Prefetch(
            query=sparse_vector,
            using="keywords",
            limit=20,
        ),
        models.Prefetch(
            query=dense_vector,
            using="semantic",
            limit=20,
        ),
    ],
    query=models.FusionQuery(fusion=models.Fusion.RRF),
    limit=5,
)

什麼時候該用 Hybrid Search？

Hybrid Search 在以下場景特別有幫助：

企業知識庫搜尋：企業文件通常混合了專業術語、代碼、縮寫和自然語言描述。純語意搜尋可能模糊化專業術語，純關鍵字可能漏掉用不同說法描述的相關文件。混合搜尋兩者兼顧。

技術文件查詢：搜尋錯誤代碼、函式名稱、設定參數時需要精確匹配。搜尋「怎麼解決記憶體不足」時需要語意理解。技術文件常常兩者都需要。

多語言環境：台灣的技術文件常常中英混用（「請確認 API endpoint 的 timeout 設定」）。語意搜尋對混合語言有優勢，但特定的英文術語用關鍵字搜尋更準。

RAG 系統：在 RAG 管道中，搜尋品質直接決定了 AI 回答的品質。Hybrid Search 比單一搜尋方式能找到更完整的相關文件，減少幻覺的機會。

不需要 Hybrid Search 的場景：

如果你的查詢都是精確查找（產品編號、訂單號碼），純關鍵字搜尋就夠了。

如果你的查詢都是開放式的自然語言問答，而且資料中沒有需要精確匹配的術語或代碼，純語意搜尋可能就足夠。

資料量很小（幾百筆以內），兩種搜尋的差異不大，用哪種都行。

台灣使用情境

台灣企業在導入 Hybrid Search 時有幾個特別的考量：

繁體中文分詞：關鍵字搜尋（BM25）依賴分詞。繁體中文的分詞比英文複雜。Elasticsearch 預設的中文分詞器效果一般，建議使用 ik 分詞器或 jieba 並載入繁體中文詞庫。分詞品質直接影響關鍵字搜尋的效果。

中英混合查詢：台灣的技術文件和客服對話常常中英混用。Hybrid Search 在這個場景特別有價值——關鍵字搜尋可以精確匹配英文術語（如「OAuth 2.0」「REST API」），語意搜尋可以理解中文的描述部分。

法規文件搜尋：台灣的法規條文用語和一般人的說法差很遠。律師或 MIS 要找某個法規時可能記得條號（關鍵字搜尋精確匹配），也可能只記得大概的內容（語意搜尋理解意思）。Hybrid Search 讓兩種找法都能用。

安全考量與限制

使用 Hybrid Search 需要注意幾個面向：

效能開銷：同時跑兩種搜尋加上結果融合，延遲會比單一搜尋方式高。在延遲敏感的場景，需要評估是否可以接受。主流向量資料庫的 Hybrid Search 延遲通常在幾十毫秒到幾百毫秒之間，對大多數 RAG 應用來說可以接受。

儲存成本：需要同時維護關鍵字索引和向量索引，儲存空間大約是純向量搜尋的 1.5-2 倍。對大型知識庫來說，儲存成本需要考慮。

調參複雜度：α 值（關鍵字和語意搜尋的權重比）沒有一個放之四海皆準的最佳值。需要根據你的資料和查詢類型來調整。建議用一組代表性的查詢做評估，找到效果最好的 α 值。

資料安全：語意搜尋需要把文件內容轉成 Embedding 向量。如果使用外部的 Embedding API（如 OpenAI），文件內容會被送到外部伺服器。機敏文件的 Embedding 建議用本地模型生成。

不是萬能的：Hybrid Search 提升了搜尋品質，但不保證一定找到最相關的結果。搜尋品質還受到 Chunking 策略、Embedding 模型品質、資料品質等因素影響。

怎麼開始？

如果你正在建立 RAG 系統，想加入 Hybrid Search：

評估需求：看看你的查詢類型。如果主要是自然語言問答，先用純語意搜尋可能就夠了。如果查詢中經常包含特定的術語、代碼或專有名詞，Hybrid Search 會明顯改善效果。
選擇向量資料庫：優先選擇內建 Hybrid Search 功能的向量資料庫（Weaviate、Qdrant、Milvus、Pinecone）。這比自己實作融合邏輯簡單得多。
從 α = 0.5 開始：先用關鍵字和語意各半的權重，看效果如何。然後準備一組測試查詢（至少 20-30 個），分別嘗試 α = 0.3、0.5、0.7，比較搜尋品質。
注意中文分詞：如果你的資料是繁體中文，確認關鍵字搜尋的分詞器能正確處理。測試幾個常見的查詢，看分詞結果是否合理。
搭配 Reranking：Hybrid Search 之後，可以再加一層 Reranking 來進一步優化結果排序。兩者搭配是目前 RAG 搜尋的最佳實踐。

知識檢測

讀完文章後，測試一下你對這個主題的理解。

常見問題

Hybrid Search 一定比純語意搜尋好嗎？

通常是，但不是絕對的。多項研究和實際案例顯示，Hybrid Search 在大多數場景下比單一搜尋方式的效果更好。但如果你的資料和查詢都是純自然語言（沒有專有名詞、代碼、精確術語），純語意搜尋的效果可能和 Hybrid Search 差不多。建議用你自己的資料測試比較。

RRF 和加權分數融合該用哪個？

RRF 通常是較安全的選擇，因為它不受兩種搜尋引擎分數尺度差異的影響。加權分數融合需要先做分數標準化，標準化的方式會影響最終結果。如果你不確定，先用 RRF。

可以結合超過兩種搜尋方式嗎？

可以。有些系統會結合三種甚至更多的搜尋方式，例如：BM25 + dense vector + sparse vector（SPLADE）。融合的原理相同，RRF 本身就支援合併任意數量的排序清單。但每多加一種搜尋方式就增加一份延遲和複雜度，需要衡量收益。

Hybrid Search 和 Reranking 的差別是什麼？

Hybrid Search 是在搜尋階段結合兩種搜尋方式來取得更好的初始結果。Reranking 是在搜尋之後，用更精確的模型（通常是 Cross-Encoder）重新排序結果。兩者不衝突，在 RAG 管道中通常是先 Hybrid Search 取得候選文件，再用 Reranking 精排。

參考資料

Weaviate Hybrid Search — Weaviate 官方 Hybrid Search 文件
Qdrant Hybrid Search — Qdrant 官方混合搜尋文件
Reciprocal Rank Fusion (RRF) 論文 — Cormack et al. RRF 原始論文
Pinecone Hybrid Search — Pinecone Hybrid Search 文件