顧客問「適合敏感肌、無香料、預算一千元內的商品」，AI 卻推薦含香料或不同市場價格，不能只改 prompt。回答經過 query 理解、商品檢索、filter、ranking、即時資料與生成多層，任何一層都可能失真。
排錯的第一步是保存完整 trace，讓同一問題可以重播，而非只留下聊天截圖。
先重現使用情境
記錄原 query、locale、market、currency、登入狀態、時間、裝置、conversation context、filter、模型、prompt、index 和工具版本。價格與庫存會變，重播需保留當時結果或 snapshot，才能判斷原回答是否錯誤。
確認顧客說的「錯」是哪一種：沒有商品、商品不相關、違反條件、事實錯、舊狀態、理由不可信或漏掉更佳選項。不同錯誤需要不同 owner。
檢查商品來源資料
直接查 product/variant、metafield、market publication、price、inventory 和 policy。若來源就缺成分或相容性，修 PIM/Shopify 並重建索引；不要只加一條 prompt 例外。資料設計可沿用 商品資料供 AI 使用。
同一欄位多來源衝突時，確認權威順序和同步時間。前台已更新但 index 還沒更新，屬於 freshness 問題，需要監控 webhook、queue 和重建。
拆開檢索與生成
拆開檢索與生成時，團隊可先釐清 RAG 知識系統 的資料、檢索、引用與生成邊界，再保存搜尋實際回傳的候選、score、filter 和 rank。正確商品根本沒進候選，調整 query、synonym、embedding、keyword、filter 或索引；正確候選存在卻被回答忽略，才檢查 prompt、context 長度和生成邏輯。
混合搜尋要知道 keyword 與 semantic 各自貢獻。SKU、型號和精確規格通常需要 lexical 訊號；用途與自然語言可用 semantic 補充。沒有單一 ranking 適合所有 query。
硬條件交給確定性規則
預算、尺寸、庫存、market、過敏原、相容性和配送限制，不應只靠模型理解後自由遵守。將條件轉成結構化 filter，工具端驗證每個推薦。缺值不等於符合，尤其是健康與安全屬性。
若沒有完全符合商品，回答哪個條件無法滿足，詢問顧客是否願意放寬。不能自行移除限制再把結果說成符合。
回答附上可驗證來源
商品事實連到當前商品頁、規格或政策，內部 trace 保存 field-level provenance。引用頁若沒有支撐該句，顯示連結也無法提升可信度。價格和庫存標示查詢時間，交易前重新確認。
來源衝突、資料過期或 retrieval confidence 低時，降低斷言、要求補充或轉人工。良好拒答能避免顧客依錯誤商品資訊下單。
建立錯誤分類與 owner
資料缺漏交商品/PIM；索引延遲交平台；query 理解與 ranking 交搜尋；生成錯誤交 AI；market 和交易狀態交商務後端；政策內容交營運。Ticket 帶 trace ID、影響 query、嚴重度和回歸案例。
客服回報介面讓顧客選「不相關、條件不符、資訊錯、已缺貨」並可補充原因。自由文字先去識別再進分析，不能把單一回饋直接變成全域規則。
固定評測集持續回歸
收錄熱門、長尾、拼字、繁簡、混合語言、SKU、比較、無答案、硬條件、惡意 prompt 與多輪問題。每題保存允許商品、禁止商品、必要事實、來源與可接受拒答。依市場和品類分層，避免平均分數掩蓋高風險錯誤。
指標包含 retrieval recall、硬條件違反、事實支撐、引用正確、無答案處理與人工評分。模型、prompt、index、schema 或商品資料變更後都跑同一套；重大違反採零容忍或停止發布。
上線監看真實分布
離線測試不會包含所有新商品與顧客語言。監看無結果、改問、快速離開、商品點擊、回報、轉人工和成交後退貨，抽樣高流量與高風險回答。站內傳統搜尋的零結果治理可參考 Shopify 搜尋零結果。
AI 搜尋排錯的核心是讓每句推薦能追到資料與工具。只要 trace、硬條件與評測完整，團隊就能修正真正故障的那一層，避免每次答錯都靠 prompt 補丁堆疊。