wen aidev
Published on

Azure AI Search（三）：Semantic Ranker 終極語意重排

Table of Contents

經歷過了第一篇的 Vector Search 探討以及第二篇的 Hybrid Search (混合檢索) 洗禮後，我們的 RAG (Retrieval-Augmented Generation) 系統已經具備了兼顧「絕對關鍵字」與「廣泛同義詞」的頂級搜尋能力。

在十萬份文件大海中，Hybrid Search 和 RRF 演算法就像一張巨大且精細的漁網，成功幫我們把最相關的 Top 50 份文件給撈了上來。

但接下來，你面臨了一個非常現實的問題：這 50 份文件，你要怎麼餵給 OpenAI？

為什麼不把 Top 50 全丟給 OpenAI？

很多初學 RAG 的開發者，會直接把這 50 篇文章塞進 Prompt 裡，跟 LLM 說：「根據以下這五十篇文章，回答客戶的問題」。

千萬不要這麼做。這會引發三大災難：

  1. Token 破產：50 篇文章可能高達數萬個 Token，每一次問答光是輸入成本就讓你頭皮發麻。
  2. 效能極差：處理幾萬個 Token，API 的回覆時間可能會拖長到十幾秒以上，使用者體驗歸零。
  3. 迷失在中間 (Lost in the middle)：這是 LLM 界的著名論文結論。當上下文太長時，LLM 很容易記住開頭和結尾，卻完全忘記中間的內容，導致嚴重的幻覺與漏答。

所以，最佳實踐是：我們只能挑這 50 篇裡面的「前 3 到 5 篇」給 OpenAI。

但問題又來了：Hybrid Search 給我們的前 3 名，真的是「最適合拿來生成答案」的前 3 名嗎？

L1 Retrieval 到 L2 Semantic Ranker 漏斗架構

圖說：在兩階層檢索架構中，L1 追求的是「快與廣」，L2 追求的則是「深度理解與排名矯正」。

Azure AI Search 終極殺招：Semantic Ranker (L2)

我們需要一個「閱讀理解能力跟 GPT-4 一樣好，但專注於做排名」的裁判，來幫這 50 篇文章做最後的二次精煉。這就是 Azure AI Search 的獨門必殺技：Semantic Ranker (語意重排器)。

這個機制的底層，是微軟直接動用了他們研發的深度語言模型 (Deep Language Models) 來作為搜尋引擎的 L2 (Level 2) 守門員。

L1 (Retriever) 與 L2 (Ranker) 的分工哲學

  • L1 (Retriever / 粗篩)：這是我們上一篇介紹的 Hybrid + RRF。它的任務是追求速度與召回率 (Recall)。它要在幾十毫秒內，從十萬筆資料中刷出 50 筆。為了快，它使用的是相對粗糙的向量距離或字詞比對。
  • L2 (Ranker / 精煉)：這就是 Semantic Ranker 的主場。它的任務是追求極致的精準度 (Precision)。微軟的大型語言模型會把這 50 篇文章「真正地讀懂」，然後進行交叉比對與重新排序 (Re-ranking)。

Semantic Ranker 怎麼做到「真正讀懂」？

假設你搜尋：「出差搭計程車可以報帳嗎？」

L1 (Hybrid) 撈回來的前三名可能是：

  1. 《計程車車資請領單》 (Keyword 全中，但只有表格沒有規定)
  2. 《出差膳雜費報支要點》 (語意很像，但內容都在講吃飯)
  3. 《本年度差旅費報支懶人包》 (排在第三，但第 5 頁確實寫了計程車報帳規定)

如果直接拿前兩名去問 OpenAI，它只會回答你：「資料裡沒有提到計程車能否報帳。」

但如果開啟了 Semantic Ranker，它會發揮語言模型的「閱讀理解」能力。它看完這 50 篇後會發現：「哇！這份排在第 3 (甚至第 15 名) 的懶人包裡面，有一段話完完全全就是在回答使用者的問題！」

這時候，Semantic Ranker 就會粗暴地把這篇懶人包拉到排行榜的第一名。

隱藏的驚喜：Captions & Answers

除了重新洗牌之外，Semantic Ranker 在回傳結果時，還會佛心附贈 Captions (高反差的摘要重點片段) 和 Answers (直接嘗試回答問題的簡短結論)。很多時候，你的 RAG 系統甚至不需要呼叫 OpenAI，光靠 Semantic Ranker 給的 Answer 就能直接秀在 UI 上了！

架構選型的最後一塊拼圖：成本

看完了 Semantic Ranker 的威力，你是不是覺得：「太棒了！我要把所有搜尋都加上這個功能！」

且慢。強大的火力是有代價的。既然底層動用了微軟的語言模型，Semantic Ranker 是需要額外計費的。雖然有免費額度 (Free tier 包含每月 1000 次 requests)，但在企業級應用中，每一次開啟 Semantic Rank 都意味著運算成本。

實戰上的成本與效能妥協策略：

在架構設計上，我們通常會採取這種策略：

  1. 普通關鍵字搜尋 (例如搜員工工號、特定料號)：只走 L1 (BM25)，便宜、極快。不需要用火箭筒打蚊子。
  2. 高價值的知識問答 (例如法規查詢、醫學指引)：走 L1 (Hybrid) -> 篩出 50 筆 -> 經過 L2 (Semantic Ranker) -> 抽排名前 3 筆 -> 餵給 OpenAI。

這樣既能保證 LLM 拿到的是「沒有雜訊的最強 Context」，又能把運算資源跟 Token 成本花在刀口上。

總結

回到我們這三部曲最初的問題：「我需要為了 RAG 去開一台 Azure AI Search 嗎？」

如果你想要的是：

  1. 不會因為查「iPhone 15 Pro」而出來「三星 S24」的精確度 (Hybrid Search)
  2. 不用自己寫一堆 SQL 去處理兩邊分數對不上的融合問題 (RRF)
  3. 在送給 LLM 之前，還有一道微軟大神幫你做閱讀理解與二次排列的保險 (Semantic Ranker)

那麼，Azure AI Search 絕對值得你在架構圖中，為它留一個不可撼動的核心位置。

(Azure AI Search 全面解析系列 完結)

留言討論