公司知識 · 實作指南
產品編號不能只靠語意相似
精確識別碼與自然語言需求不同，應在同一測試中分別驗證。
分清兩種查詢意圖
客戶查找指定零件編號，不是尋找意思相近的產品。Microsoft 混合搜尋文件介紹文字與向量檢索的結合；對小型分銷商而言，本文建議把精確識別碼列為主要測試。保留標點、前導零與供應商別名，並確認近似結果只能作提示，不能當成精確答案。只有一個字元不同的產品，可能對應完全不同的規格或服務責任。
加入混合語言的實際問法
測試可使用假設問法，例如中文描述加英文型號、拼錯產品名稱，以及正確編號搭配已過期簡介。把識別碼正確與描述相關分開評估：編號對了，文件版本仍可能錯誤。資料集應同時放入核准文件及看似合理的干擾項，讓系統真正表現出區分能力，而不是因為資料庫只有一份文件就自然答對。這亦有助發現別名管理的缺口。
流程一覽
不要讓猜測決定必要篩選
在組合答案前套用核准狀態、客戶範圍及有效日期等業務條件，不能只靠語言模型遵守邊界。結果卡應顯示識別碼與版本，沒有精確結果時提供可控下一步，例如要求照片、查供應商目錄或交同事處理。不要默默換成類似產品。試點尤其應測試「沒有答案」的情況，確認助手願意承認缺口，而非以流暢語句完成不可靠建議。
衡量最後交接是否正確
量度員工最後是否選中正確項目，以及需要多少核對時間。排序分數是診斷工具，不是完整成效。新增目錄或命名方式時，把曾經失敗的問題保留為回歸測試。混合設計並非自動優勝；只有受控比較顯示精確和描述性查詢更可靠，而且投入與成本可接受，才值得採用。若簡單編號搜尋已足夠，就不必強行加入生成答案。
一次精確識別挑戰
準備只差一個字元的相似編號，同時放入新舊參考資料，請業務負責人確認哪些應精確匹配、哪些只能提示、哪些必須沒有答案。這些差異應在介面清楚呈現，不能藏在相關分數裡。最後用實際匯入流程確認不會因助手選錯近似項目，就直接新增或更新正式產品紀錄。
來源與延伸閱讀
編輯原則
本系列以 AI 輔助原創撰寫，並對照連結的公開來源。實作建議與假設情境屬編輯分析，並非客戶實績。來源發布日期及產品細節可能與本系列整理日期不同。