Azure AI Search（二）：Hybrid Search 與 RRF 演算法

在上一篇文章中，我們看見了 Vector Search (向量搜尋) 的強大：它能聽懂「請假」和「特休」是同一回事。同時我們也解答了實務上的抉擇：如果只是想幫現有的關聯式資料庫加上向量能力，Azure SQL Database 是個輕量的好選擇。

但是，如果你正在打造一個企業級的 RAG 知識庫，純靠 Vector Search 絕對會讓你栽跟頭。

為什麼？讓我們看一個最經典的電商/料號搜尋案例：「尋找 iPhone 15 Pro 手機殼」。

純 Vector Search 的致命傷：失控的相近語意

當你把「尋找 iPhone 15 Pro 手機殼」轉成向量去搜尋時，會發生什麼事？

Vector Search 會找到「語意最相近」的長相。於是，它可能會把「三星 S24 手機殼」排到很前面！因為在多維向量空間裡，「某個旗艦機的手機殼」這個概念，跟「另一個旗艦機的手機殼」距離非常非常近。更慘的是，它可能還會大魚大肉全撈回來，包括「iPhone 15 (無 Pro) 手機殼」、「iPad Pro 防護套」，因為它們的語意相似度 (Cosine Similarity) 分數都高達 0.8 以上。

這時候，精確的客人或工程師就會崩潰：「我明明找的是 iPhone 15 Pro，你給我三星幹嘛？」

這就是純 Vector Search 的致命傷：它會為了追求「整體語意相似」，而忽視了句子中某些「絕對不能妥協的關鍵字」 (例如特定的產品型號、特定的錯誤代碼 Err-505)。

救星降臨：Hybrid Search (混合搜尋)

既然 Keyword Search (BM25) 擅長精準抓字，而 Vector Search (KNN) 擅長理解語意，那為什麼不兩個都要呢？

微軟 Azure AI Search 提供了一鍵開啟的 Hybrid Search 功能。當使用者發出一次 Query 時，系統會在底層兵分兩路：

左路 (Keyword)：用 BM25 演算法，找出所有確實包含 "iPhone", "15", "Pro", "手機殼" 這些關鍵字的文章。這能保證絕對不會出現三星。
右路 (Vector)：用 Embedding 模型轉成向量，去廣泛捕捉「防摔衣」、「保護套」等同義詞，這能保證不會因為客人沒打「防摔殼」而錯殺商品。

聽起來很完美，對吧？但真正的難題現在才開始。

世界級難題：「分數維度不同，怎麼比？」

左路搜完，拿到了一份清單。排在第一名的文章，BM25 分數是 8.5。右路搜完，也拿到一份清單。排在第一名的文章，Cosine 分數是 0.91。

請問：8.5 跟 0.91，誰比較贏？

這就像是在問「時速 100 公里」跟「氣溫 30 度」誰比較大一樣。不同演算法的分數，根本在不同的數學維度，無法直接相加比較。如果我們硬湊，就會出現某一遍的分數永遠壓死另一邊的慘案。

揭密 Azure AI Search 核心：RRF (倒數排名融合)

為了解決這個不同維度分數無法相加的問題，資訊檢索領域有一個大名鼎鼎的演算法，同時也是 Azure AI Search 混合搜尋的心臟：RRF (Reciprocal Rank Fusion，倒數排名融合)。

RRF 的天才之處在於：它不在乎「你的絕對分數有多高」，它只在乎「你在你的那份清單裡，排第幾名」！

算式非常簡單： RRF Score = 1 / (k + BM25 的排名) + 1 / (k + Vector 的排名) (註：k 是一個常數，通常設為 60，用來平滑極端值)

圖說：RRF 演算法就像一個漏斗，它無視原生分數的量級，只拿「名次」來算積分。

RRF 是如何運作的？以 iPhone 手機殼為例：

假設有一篇文章《頂級 iPhone 15 Pro 防摔手機殼體驗》：

在 Keyword 榜單上：它因為完全命中關鍵字，排第 3 名。
在 Vector 榜單上：它因為語意極度相近，排第 2 名。它的 RRF 總分就會是 1/(60+3) + 1/(60+2) = 0.032。

而那篇討人厭的《三星 S24 手機殼》：

在 Keyword 榜單上：因為沒有 "iPhone" 關鍵字，它排在第 4 名（甚至落榜）。
在 Vector 榜單上：語意很像，排在第 1 名。它的 RRF 總分只有 1/(60+4) + 1/(60+1) = 0.032。

神奇的事情發生了！當一份文件同時被 Keyword 和 Vector 兩位評委看好（都在前幾名）時，它的 RRF 積分疊加效果會非常驚人，瞬間擊敗那些「偏科生」。最終呈現給使用者的結果，不僅包含了使用者要的精確型號，還網羅了所有的同義詞。

實戰開發建議：什麼時候該調整權重？

在 Azure AI Search 的實戰開發中，我們能透過設定檔去微調這兩股力量的平衡。雖然 RRF 解決了名次融合的問題，但有時候我們還是會刻意讓天平傾斜：

調兵遣將的三大情境

高度技術文件、醫療料號、法律條文：請將 Keyword 的權重調高，或是開啟 Strict Match。因為在這些場景裡，「Err-500」跟「Err-501」只差一個字，卻是完全不同的災難，容不得 Vector 胡亂聯想。
客服 FAQ、社群論壇、模糊問答：這時候可以大膽依賴 Vector。客人可能會輸入各種奇形怪狀的錯字或口語，Keyword 根本抓不到，需要 Vector 的強力包容。
RAG (Retrieval-Augmented Generation) 知識庫：通常建議 50% / 50% 預設值的 Hybrid Search。讓 RRF 自動幫你找出那份既精準、又有廣度的神聖 Context，再餵給 LLM 生成回答。

下一步：Top 50 選出來了，然後呢？

透過 Hybrid + RRF 的雙劍合璧，我們已經能從十萬篇文件裡，精準且不漏接的篩選出前 50 篇「最棒」的候選名單。

但問題來了：這前 50 篇，真的每一篇都是最核心的解答嗎？如果我只挑前 3 篇餵給 OpenAI 生成答案，會不會剛好錯過了排在第 5 名的那個完美段落？

如果把 50 篇全部塞給 OpenAI... 老闆看到 API 帳單應該會直接昏倒（而且 Token 爆表反而容易引發幻覺）。

為了這「找資料的最後一哩路」，微軟祭出了 Azure AI Search 最可怕的終極殺招。我們將在系列最終回揭曉：Semantic Ranker (語意重排) 讓 LLM 驚呼完美。