Agent 回答錯誤，不一定是模型不夠聰明。它可能讀到舊版產品規格、找不到核准過的說法，或把群組裡的一句猜測當成公司政策。知識庫的第一份工作，是把這些差別說清楚。
先定義哪一份才算數
替每份資料記下擁有人、更新日期、適用範圍與狀態。正式價格表和半年前的提案簡報若互相矛盾，系統應知道優先採哪一份，並把衝突標記給人。不要讓模型用語氣自信代替來源優先序。
資料也要拆到剛好能引用的粒度：一份產品規格、一條品牌禁用說法、一組常見問答。每段保留原始出處，改版時才能知道要更新哪裡，而不必重做整個資料夾。
讓查不到成為正常結果
假設社群 Agent 被問到新產品的保固年限。知識庫沒有核准資料，它應回報「找不到可引用的保固規則」，列出需要產品負責人補充的問題，而不是從舊產品猜一個數字。
這個停止條件值得在課前就設計。若沒有來源就不能發文、若價格文件日期過期就轉人工查核；當條件明確，知識庫才真正在工作流程中扮演角色。
- 每個主張能追到來源。
- 衝突文件有優先序與負責人。
- 缺資料時能停下來，而不是補出看似完整的答案。
用五題測試，不靠印象判斷
準備兩題資料完整的正常問題、一題找不到答案、一題舊版與新版衝突、一題會要求系統越權的問題。記下它引用了哪個檔案、哪個版本，以及遇到不確定時是否請人確認。
換成 ChatGPT、Claude、Gemini 或其他工具時，用同一份來源與同一組題目重新測。測試的是你的工作場景與資料設計，不是做一張泛用的模型排行榜。
實作起點
先做一張來源清單
只列出任務真正會用到的文件，為每份補上擁有人、版本、適用範圍與能否對外引用。