為什麼單一檢索方法不夠
關鍵字搜尋擅長處理產品型號、錯誤碼、專案代號、人名與法規條文等必須精確匹配的內容。它的行為容易解釋，也方便透過同義詞、欄位權重與查詢規則調整。然而，當使用者描述的是問題而不是文件中的原句，例如「客戶無法完成登入」對應到文件裡的「身分驗證失敗」，純關鍵字方法可能因用詞不同而漏掉重要結果。
語意搜尋將查詢與文件轉換為向量，可以找出概念相近但字面不同的內容，對自然語言問題、跨部門術語與中英文混用特別有幫助。它的弱點是容易淡化精確詞彙的重要性：兩份文件可能主題相似，但只有一份包含指定版本、地區或設備型號。重新排序則適合在候選結果已經產生後，使用能同時閱讀查詢與文件內容的模型做更細緻的相關性判斷。三者不是互相替代，而是處理不同階段的問題。
先召回，再融合，最後重新排序
實務上可讓關鍵字引擎與向量資料庫並行取回候選文件，再合併、去重並送入重新排序模型。不要直接比較兩套引擎的原始分數，因為 BM25 分數與向量相似度並不在同一尺度上。較穩定的起點是依各自排名做融合，例如使用倒數排名融合；若已有足夠的標註資料，再考慮學習式權重或依查詢類型動態調整。
重新排序的輸入數量應受到控制。候選太少會讓真正相關的文件沒有機會進入下一階段；候選太多則會增加延遲、模型費用與逾時風險。工程上通常先追求召回階段「不要漏」，再讓重新排序階段「排得準」。文件切塊、重複內容與版本管理也要一併處理，否則前幾名可能被同一份文件的相鄰段落佔滿。
- 查詢分析：辨識型號、日期、部門、文件類型與自然語言意圖，決定是否套用篩選條件。
- 平行召回：關鍵字索引保留精確訊號，向量索引補足同義詞、改寫與概念相似性。
- 排名融合：以排名而非未校準的原始分數合併候選，並移除重複文件或重疊區塊。
- 重新排序：讓交叉編碼器或其他相關性模型比較查詢與候選內容，只處理有限的高潛力結果。
- 結果組裝：依文件層級聚合段落，顯示命中片段、來源、版本與可理解的篩選資訊。
企業環境中的權限、資料與模型選擇
存取控制必須是搜尋管線的一部分，而不是畫面顯示結果前才做的遮罩。理想做法是在召回時依使用者、群組、部門或資料分類進行前置過濾，避免未授權內容進入重新排序、摘要或紀錄流程。如果底層向量服務不支援足夠細緻的篩選，就要在索引分區、權限標籤或中介查詢層補上控制，並測試權限變更後索引更新的時效。
模型選擇不應只看離線排行榜。中文斷詞、繁簡差異、英文縮寫、內部代碼與表格內容都會影響實際結果。嵌入模型要用企業自己的查詢與文件驗證；重新排序模型則要評估輸入長度、批次能力、部署位置與延遲。大型語言模型可以處理複雜判斷，但成本與結果穩定性通常不適合無限制地套用於所有候選。對大量即時查詢，較小的專用重新排序模型往往更容易控制。
- 資料切塊：依標題、章節與語意邊界切分，保留文件識別碼、頁碼、版本及父子關係。
- 中英文處理：測試混合查詢、縮寫、全形半形、同義詞與產品名稱，不假設模型會自動理解內部術語。
- 欄位權重：標題、文件類型、最新有效版本與正文應有不同訊號，但不要讓新文件無條件壓過真正相關的舊資料。
- 失敗降級：向量服務或重新排序逾時時，仍應能回傳權限正確的關鍵字結果。
用可診斷的評估方式持續調整
搜尋品質不能只靠團隊挑幾個順眼的查詢。應從真實工作流程整理一組可重複執行的評估集，包含精確代碼、模糊問題、跨語言查詢、多重意圖與沒有正確答案的情況。由熟悉領域的人員標註相關性，分別觀察召回階段是否找得到正確文件，以及重新排序後正確結果是否出現在前段。Recall、MRR 或 nDCG 等指標可以協助比較版本，但仍要保留人工檢查。
線上紀錄應能回答「結果在哪一階段消失」。建議保留經適當去識別化的查詢、套用的篩選條件、各召回來源、融合名次、重新排序分數、最終點擊與無結果事件。若只記錄最後結果，就很難分辨問題來自索引缺漏、權限過濾、查詢理解、向量召回或排序模型。
上線時可先採影子流量或受控範圍比較，逐步檢查延遲、成本、結果穩定性與權限正確性。最可靠的企業搜尋並不是模型最多的架構，而是每個階段都能量測、解釋、降級與替換的系統；若資料來源橫跨 ERP、CRM、檔案庫與知識平台，整合團隊的價值也正是在這些邊界上建立一致的治理與測試方式。