文件存在，不代表答案已經準備好
業務問：「這個客戶的方案包含一年維護嗎？」搜尋結果有一份舊簡報、一張最新報價單，還有兩個月前的會議紀錄。簡報寫包含，報價單把維護列為選購，會議紀錄又提到這位客戶可以例外處理。
這是一個假設情境。即使 AI 找到了三份文件，也還需要知道：客戶最後簽的是哪一版？會議裡的提議是否已核准？哪份資料能作為承諾的依據？
公司文件很多，常代表工作發生過、內容被留下來，卻不一定代表這些紀錄已整理成可直接使用的知識。人查資料時會碰到的版本衝突與背景缺漏，也會進入 AI 的回答流程。
因此，看到錯誤答案時，值得先沿著資料走一遍：答案是否真的存在？系統有沒有讀進去？搜尋是否找對段落？最後的回答有沒有保留原來的條件？每一段出問題，需要的修正都不同。
先分辨問題停在哪一層
企業問答通常包含幾個步驟：取得授權資料、解析內容、建立搜尋索引、檢索相關段落，再把這些內容交給模型組織回答。採用 RAG，也就是檢索增強生成的系統，會把搜尋結果當成回答的參考資料。這不等於資料已經正確，也不保證模型一定依據資料回答。[1]
排查時，應讓維護者能看到實際讀入的文字、檢索到的段落與最後回覆。只有聊天畫面，通常不足以判斷錯在哪裡。
| 問題所在 | 可能看到的現象 | 先檢查什麼 |
|---|---|---|
| 原始資料 | 同事也找不到明確依據，或文件彼此矛盾 | 可信來源、核准狀態與適用條件 |
| 解析與匯入 | PDF 開得出來，系統裡卻缺字、亂序或沒有表格 | 抽取文字、OCR、表格結構及匯入錯誤 |
| 檢索 | 資料已存在，卻一直找到相近但不適用的內容 | 名稱、識別碼、篩選條件、切分與搜尋設定 |
| 回答 | 找對段落，卻省略限制或混用版本 | 輸入給模型的內容、回答要求及驗證方式 |
| 更新與權限 | 新規則沒有出現，或使用者看到不該看的內容 | 同步狀態、停用與刪除處理、查詢授權 |
例如系統把掃描表格讀成錯誤順序，換一個更大的語言模型，仍然可能在錯誤資料上推論。若問題是索引沒有更新，反覆改提示詞也無法讓它取得尚未匯入的新規則。
從真正會問的問題，決定第一批資料
一次把整個雲端硬碟匯入，會把歷史文件、草稿與不同部門的慣用語一起帶進來。對第一版系統來說，很難知道它究竟應該答對哪些問題。
可以先選一個工作範圍，例如某一類產品的售後服務。整理近期實際出現的問題，並為每題寫出可接受的答案、必要條件、可信來源與負責人。
「保固多久？」需要先確認產品型號與購買日期；「能否免費更換？」還要確認故障情況與排除條件。這些問題應一起記錄，不要只留下看似簡單的標準答案。
如果沒有足夠資訊就不能判斷，要在驗收答案中寫清楚應追問什麼。若現有文件根本沒有依據，則列為待補資料，交由有權決定的人確認。
這份問題清單同時界定第一版的範圍。範圍外的問題，系統可以說明尚未涵蓋，並提供適當的聯絡窗口。團隊也能依實際需求決定下一批要補哪些知識。
版本與適用條件，要跟著內容一起被找到
檔名寫著「最新」並不足以判斷有效性。一份今天上傳的簡報，可能引用去年的規則；另一份較早建立的合約，則可能仍適用於特定客戶。
整理時，應區分文件建立時間、最後修改時間與規則生效時間，再補上適用產品、客戶類別、核准狀態、維護人及原始連結。這些欄位有助於系統篩選，也方便人核對。
歷史資料仍有用途。例如查詢去年某張訂單的承諾，就可能需要當時有效的版本。關鍵是保留適用時間與關係，避免把現行規則直接套在所有歷史情境。
假設政策寫著「購買後三十日內，符合指定條件者可以免費更換」。如果切成片段時只留下「可以免費更換」，期限與限制就可能在檢索時遺失。應依內容結構保留必要上下文，讓規則、對象與排除條件能一起被理解。
切分大小沒有適用所有文件的固定答案。微軟的文件切分指引列出依長度、結構與語意分段等方法，也強調標題與上下文的保留。實作時需要用實際問題比較，而不能只選一個字數就當作完成。[2]
表格尤其需要核對：價格屬於哪個方案、單位是每人還是每月、備註適用哪些欄位。如果解析後這些關係消失，應先修正資料表達，再測試問答。
搜尋要同時理解問法，也認得精確名稱
員工可能問「那台舊款能不能換零件」，文件卻使用正式產品名稱與型號。只靠字面相同，可能找不到；只靠語意相似，又可能找到另一台外觀接近的設備。
可以整理常用稱呼、縮寫與正式名稱的對照，並保留產品型號、訂單編號等識別欄位。需要精確比對的地方，應使用欄位查詢與適用條件，避免完全交給語意相似度判斷。
檢索結果應同時顯示來源、版本與適用範圍。若找到兩份互相衝突的規則，系統應依已建立的優先順序處理；沒有優先規則時，就列出衝突並轉交確認。
另外，文件回答與即時查詢需要區分。服務政策可以從文件取得，但目前庫存、訂單是否已付款、帳號是否開通，通常需要查詢具備授權的業務系統。上個月匯出的報表，不能當成現在的狀態。
當問題需要即時資料時，可以讓系統轉用指定查詢工具，並顯示查詢時間。若尚未串接，就明確說明資料範圍，讓使用者知道接下來要去哪裡確認。
答案需要能核對，也需要知道何時停下來
一段回答附有連結，仍可能沒有回答對問題。連結可能只是主題相關，實際文字卻沒有支持該項承諾；也可能引用正確頁面，卻省略了例外條件。
可用的回答應讓人辨認：結論依據哪一段、適用哪些條件、還缺少什麼資訊，以及下一步由誰確認。對重要問題，可以要求先列出適用條件，再給結論。
回到維護方案的例子，系統應先確認客戶與簽約版本。如果只找到一般方案介紹，就只能說明一般條件，不能據此斷言這位客戶已購買維護。
當依據不足時，合適的回覆可能是：「目前找到一般方案說明，但未取得此客戶簽署的報價或合約，尚無法確認維護範圍。」接著提供需要補充的資料或負責窗口。
也不要直接把模型自述的信心當成正確率。實際可靠程度，需要用有標準答案的案例評估，並檢查引用、條件與版本是否符合要求。
權限要在資料進入回答之前檢查
同一個問題，不同角色可能有不同的可見範圍。一般業務可看公開報價，不一定能看採購成本；外部合作夥伴可查交付文件，不一定能看其他客戶的資料。
權限應由系統依身分與資料規則執行，限制可被檢索及送入模型的內容。只在提示詞寫「不要透露機密」，不足以取代存取控制。微軟的文件層級權限說明，也將查詢時依使用者或群組篩除未授權文件列為一種實作方式。[3]
測試不只要看使用者能否打開原始檔案，也要確認摘要、引用、快取與聊天紀錄不會露出未授權內容。帳號移除或權限變更後，相關索引與快取也需要有更新或失效機制。
文件內容本身則應被當成參考資料。即使其中寫了要求忽略規則、傳送資料或執行操作的文字，也不能因此取得系統權限。問答與可執行的操作，應各自受到後端控制。
用一份問題集驗收，再安排日常維護
驗收時，可以保留一組固定問題，涵蓋直接查詢、需要多份資料、名稱模糊、規則衝突、資料缺漏、歷史版本與權限限制。每題記錄預期行為，包含什麼情況應追問、拒絕或轉交。
| 測試類型 | 要確認的結果 |
|---|---|
| 有明確依據 | 答案、適用條件與來源相符 |
| 需要補資訊 | 先追問必要欄位，沒有自行猜測 |
| 文件衝突 | 依明確規則處理，或指出衝突並轉交 |
| 沒有資料 | 說明目前缺口，沒有編造承諾 |
| 不同權限 | 未授權內容沒有進入回答或引用 |
| 資料變更 | 新版本能被查到，停用或刪除內容按規則退出使用 |
每次出錯，都先分類：原始資料缺漏、解析錯誤、檢索失準、回答偏離，或同步與權限問題。分類後再修改，才能知道改善來自哪裡。更換模型、調整切分或新增資料後，也要重新跑過既有問題，確認原本答對的項目沒有退步。
上線後，需要指定知識維護人、技術維護人與問題接手者。政策更新時，由誰核准內容；系統同步失敗時，由誰處理；使用者發現錯誤時，又在哪裡回報。這些責任應跟著系統一起交付。
第一版可以只支援一個產品系列或一項內部流程。等到來源能核對、更新有人負責、錯誤能被定位，再逐步擴大。當下一位同事問起同樣的問題，團隊能得到可追溯、符合當下情境的回答，文件才開始發揮共同知識的作用。