如果您在以關鍵字為基礎的系統中搜尋「authentication」，系統可能會漏掉只提到「login security」的文件，因為兩者沒有任何完全相符的字詞。語意搜尋則有相反的弱點。如果您搜尋的是特定識別碼，例如驗證錯誤碼 ERROR_401_EXPIRED，系統可能會優先顯示廣泛相關的登入失敗內容，反而將包含該確切錯誤碼的文件排在較後面。

正式環境中的搜尋系統需要同時具備兩者：使用關鍵字搜尋精確詞彙、使用語意搜尋理解意義，再透過合併步驟將兩者的排名整合成一份清單。這種組合稱為混合搜尋（hybrid search），目前已成為 RAG 系統的標準檢索策略。

接下來，我們將逐一說明每種方法的運作方式、各自的限制，以及混合搜尋如何將兩者合併。

什麼是關鍵字搜尋（Keyword Search）？

關鍵字搜尋，也稱為詞彙搜尋（lexical search），會將查詢中的字詞與文件中的字詞進行比對。大多數實作都會使用 BM25 評分演算法。當文件包含更多查詢詞、這些詞在整個文件集合中較為罕見，且文件沒有填入大量不相關文字時，BM25 會給予較高排名。像「revenue」這種常見詞彙，幾乎會出現在每一頁財報中，因此比對到它所帶來的權重很低。相較之下，ERROR_401_EXPIRED 這類字串只會出現在某一份執行手冊中，因此 BM25 會將這項比對視為強烈訊號。

這種機械式的行為正是關鍵字搜尋的優勢。只要確切識別碼、錯誤碼、產品名稱和引號中的詞組出現，關鍵字搜尋就能找到它們。它的執行速度快，搜尋結果也容易向使用者和稽核人員說明：文件之所以符合，是因為其中包含您輸入的字詞。

什麼是語意搜尋（Semantic Search）？

語意搜尋比較的是意義，而不是拼字。它會使用嵌入模型將文字轉換成向量，代表相關概念的向量會在空間中彼此靠近。查詢也會被轉換成向量，接著搜尋引擎會傳回向量距離最近的文件，通常會使用餘弦相似度（cosine similarity）進行衡量。

詞彙不再是限制。搜尋「authentication」時，即使「login security」文件沒有使用相同字詞，系統仍會擷取該文件，因為這兩個片語位於相同的語意鄰域。使用者也能以自然語言提出完整問題，例如「How do I let users sign in with their Google account?」，並擷取與查詢幾乎沒有共同字詞的 OAuth 文件。

兩種方法各自的限制

這兩個引擎幾乎會在相反的情境下失效，也正是讓它們成為理想搭配的原因。

關鍵字搜尋會在詞彙不一致時失效。文件撰寫者和搜尋者很少會選用完全相同的字詞。支援人員輸入「refund policy」，但文件寫的是「returns and reimbursements」，此時 BM25 給予的分數可能接近零。關鍵字搜尋也沒有意圖模型，因此無法判斷「How do I cancel my plan?」和「subscription termination steps」其實是在尋找相同的答案。

語意搜尋會在精確字串上失效。嵌入模型會將文字壓縮成一般性的意義，而罕見 token 在這個壓縮過程中會失去原本的識別性。錯誤碼、零件編號、縮寫，以及人名或產品名稱，往往會擷取到外觀相似的內容，而非精確的比對結果。搜尋「OpenEdge 12.8 release notes」時，系統可能會傳回鄰近版本的版本資訊，因為這兩份文件在語意上幾乎相同。

第二種失效模式是我們看到團隊最容易低估的問題。示範通常使用自然語言問題，因此語意搜尋看起來幾乎無懈可擊；直到真實使用者將發票號碼或錯誤碼貼到搜尋欄位中，問題才會浮現。

什麼是混合搜尋（Hybrid Search）？

混合搜尋會針對每個查詢同時執行兩種引擎，再將兩份排名清單合併成一份。由於 BM25 分數和餘弦相似度位於不同的尺度上，直接比較兩者沒有意義，因此合併步驟需要謹慎處理。倒數排名融合（Reciprocal Rank Fusion）會使用排名位置，而不是分數，藉此避開尺度問題。每份文件會依照其在各清單中的排名獲得分數；同時在兩份清單中名列前茅的文件，累積的分數最高，並升至頂端。

大多數實作都會提供兩種訊號之間的權重設定。對於充滿錯誤碼的支援知識庫而言，偏重關鍵字搜尋會更有幫助；對於使用者以自然語言查詢的政策 Wiki，偏重語意搜尋則更合適。我們會先從均衡的設定開始，只有在觀察到真實查詢失敗後，才進行調整。

混合搜尋為何對 RAG 如此重要

RAG 流程只能根據檢索階段提供給它的段落產生答案。如果檢索階段漏掉相關段落，LLM 就看不到該段內容，也無法引用它。無論提示工程或模型品質多麼出色，都無法挽救從未進入上下文的資訊。

以「What was revenue guidance for FY 2026?」這個問題為例。語意檢索會找出討論財務展望與指引的段落，而關鍵字檢索則能確保精確比對到「FY 2026」，讓模型引用正確的會計年度，而不是語意相似但年份不同的內容。兩者結合後，就能同時擷取相關段落，以及 LLM 產生準確答案所需的精確細節。

Progress Agentic RAG 中的混合搜尋

Progress Agentic RAG 平台預設會同時執行關鍵字搜尋和語意搜尋。該平台由 NucliaDB 驅動，將語意搜尋、關鍵字搜尋、metadata 搜尋與知識圖譜遍歷整合在同一個儲存區中，因此我們不需要在向量資料庫旁另外維護關鍵字索引，也不必自行撰寫合併邏輯。

Search 設定面板可直接設定倒數排名融合（Reciprocal Rank Fusion）。我們可以依據使用者的搜尋方式，以及他們需要擷取的資訊類型，調整權重，讓語意搜尋結果優先於關鍵字搜尋結果，或反過來設定。

總結

關鍵字搜尋能快速且可預測地比對確切字詞；語意搜尋則能跨越不同詞彙，比對文字背後的意義。兩者各自在對方擅長的地方失效。混合搜尋會同時執行兩種搜尋，再透過倒數排名融合（Reciprocal Rank Fusion）合併排名，因此已成為 RAG 的預設檢索策略。Progress Agentic RAG 開箱即用地提供這項功能，並且只需調整一項設定即可完成融合權重配置。

如需更多詳細資訊並開始使用 Progress Agentic RAG，請參考以下資源：

常見問題

語意搜尋一定比關鍵字搜尋好嗎？

不一定。當查詢的措辭與文件不同時，語意搜尋通常更具優勢；而當查詢包含錯誤碼、產品名稱或引號中的詞組等精確字串時，關鍵字搜尋則更有效。兩者可以互相彌補對方的盲點，因此正式環境中的系統通常會將兩者合併。

混合搜尋中的倒數排名融合（Reciprocal Rank Fusion）是什麼？

倒數排名融合（Reciprocal Rank Fusion，RRF）是一種將關鍵字搜尋與語意搜尋排名清單合併的演算法。由於兩種引擎使用的文件評分尺度不相容，RRF 不會採用原始分數，而是根據文件在各清單中的排名位置給予分數。在兩份清單中排名都很高的文件，會在融合後的排名中升至頂端。包括 Progress Agentic RAG 在內的許多系統，也允許使用者提高其中一份清單的權重。

執行混合搜尋時，需要分開的關鍵字索引和向量資料庫嗎？

這取決於您使用的技術堆疊。許多團隊會將 Elasticsearch 這類關鍵字引擎與向量資料庫搭配使用，再於應用程式程式碼中合併結果。這種方式可行，但會讓基礎架構加倍，並且需要維持兩份索引同步。NucliaDB 這類統一儲存區會在資料擷取時，同時為兩種搜尋模式建立文字索引，因此混合搜尋可透過單一查詢，對同一份索引執行。