AI知識庫總是答非所問，是模型不行還是文件檢索出了問題？

一、先把“回答不好”變成可復現的問題

請業務人員記錄真實提問，不要事後把問題改成與文件標題一致的問法。一次故障記錄至少包含使用者身份、提問時間、原始表述、實際回答、預期依據和錯誤影響。例如同樣問“如何申請退款”，訂閱產品和專案制服務可能適用不同條款；不說明產品和合同版本，所謂標準答案也不可靠。先讓系統詢問缺失條件，可能比增加檢索片段更有效。

把問題分成有明確依據、需要跨段組合、條件不完整、資料衝突、沒有依據和許可權受限幾類。測試中保留俗稱、編號、縮寫和口語問題，並把除錯集與驗收集分開。若每輪都拿同一組演示問題除錯，結果越來越好可能只是適配了這些問題，不能說明新員工或客服面對新問題時仍能得到可靠幫助。

二、沿著原檔案到片段檢查資訊是否丟失

逐級檢視原始檔、解析文字和索引片段。掃描頁可能漏識別負號，跨頁表格可能丟掉幣種與表頭，附件中的例外條件可能與正文分開。常見問題不是“大模型不懂業務”，而是它最終看到的文字已經沒有業務條件。對於合同、產品說明和制度檔案，應保留頁碼、條款編號、適用物件、有效期和可追溯來源，不能只有一串沒有出處的向量片段。

用單條制度做演示時，可以故意把“適用新客戶”與費率表拆開，觀察系統是否錯誤應用到全部客戶。這是測試設計，不是知華客戶實測結果。修復時比較按標題分段、父子片段和必要的上下文補全；不要簡單認為段越長越完整。長片段還可能把不同版本、無關附件和互相矛盾的規則一起送入模型。

三、區分沒有召回和召回後排序靠後

如果正確原文已在索引中，先看它是否進入候選結果。型號、單號、專業術語可對照關鍵詞檢索，含同義表達的問題可對照語義檢索，再根據樣本比較混合方案。正確片段根本沒進入候選集，後續重排無法憑空恢復它；若候選已有依據，但被大量相似材料擠出上下文，才更適合檢查重排、去重和後設資料過濾。

Dify等平臺提供檢索測試、混合檢索和重排等能力，但有這些開關不等於開啟後一定更準。記錄每輪改變的變數、候選數量、相關性和延遲，使用同一驗收集複測。不要同時更換模型、切分和索引後只報告最終結果，否則難以確定哪一步真正有效，下一次知識更新出問題也無法快速回退。

四、原文正確時，檢查生成是否改變了條件

將最終送入模型的上下文與回答逐句核對：是否遺漏例外條件、混淆時間範圍、把建議說成承諾，或把兩個產品的規定合併。回答應區分依據、推斷和待確認事項，引用盡量對應具體結論。只有引用連結而沒有內容對應關係，不能作為可信度證明。上下文存在相互衝突的有效規則時，應展示衝突並交給負責人確認。

“請不要胡編”不能替代許可權、資料治理和驗證。對於缺乏依據的問題，允許明確說無法確認；對於業務使用者確實需要結果的任務，提供補充資料、轉人工或查詢正式系統的路徑。還要避免過度拒答：把所有問題都拒絕可能減少錯誤，卻沒有產生業務價值，正確拒答與有依據任務的完成率應分別評估。

五、用明確分母的評測表代替籠統準確率

下面僅是計算示例，不是客戶成績：100個測試問題中，80個有授權依據，12個本來就沒有答案，8個無訪問許可權。如果在80個可回答問題中找到72個的正確證據，則這組樣本的證據召回覆蓋為72/80；如果最終有60個回答滿足業務要求，則有依據問題的回答達標為60/80。這兩個比例不相同，均不能推出另外20個問題處理正確。

另外統計無答案問題的合理拒答、許可權受限問題的資料洩露、引用可核對性和人工修改工時。關鍵風險應單列，不能被平均分掩蓋。樣本較小時只把結果當作該測試集的觀察，不推廣成所有未來輸入的準確率。驗收保留每題結果、錯誤原因、模型和索引版本，便於業務複核與下一輪迴歸。

六、知識更新、撤權和上線責任決定長期效果

源系統釋出新版本、刪除檔案或調整部門許可權後，索引與快取應在約定視窗同步，失敗要告警並保留重試記錄。只上傳新增檔案卻不處理舊版本失效，會使同一問題逐漸出現多個答案。測試員工離職、跨客戶查詢和引用附件下載，確保許可權覆蓋原文、檢索、快取與匯出，而不是隻在聊天頁面隱藏按鈕。

最佳化服務應交付問題清單、對照配置、解析樣本、評測集、執行說明和遺留風險。業務負責人維護內容有效性，技術方維護同步、索引和迴歸。報價按資料複雜度、可復現條件、介面與執行責任評估，不按“調幾個引數”估算。若基礎知識缺失或業務規則尚未統一，先治理資料往往比重新採購模型更有價值。

官方資料與核對範圍

參考資料核對日期：2026-09-12。平臺能力會隨版本、套餐、地區和許可權變化；資料用於說明技術能力，不代表搜尋量、知華客戶成果或原廠合作資質。

• Dify官方：知識處理、檢索測試與重排能力