業務剛改完報價，為什麼 AI 還在引用上個月的版本？

因為把檔案放進知識庫只是開始；沒有版本與發布規則，AI 仍可能從舊資料找到看似合理的答案。

下午，業務準備回覆客戶的詢價，先問內部 AI 最新的服務範圍。它很快給出一份完整答案，卻混入已經取消的方案。追查後才發現，新舊簡報、對話紀錄與 Word 檔都被放在同一個資料夾，沒有人知道哪一份才是目前有效的依據。

翔懂AI的判斷是：私有知識庫不是「把所有檔案餵給模型」的倉庫，而是一套讓團隊辨識目前規則、查到來源並能撤回錯誤內容的工作方式。RAG（檢索增強生成）會先從資料中找相關段落，再交給模型組織回答；所以資料是否有效，直接影響回答是否可靠。

要先整理哪些資料，AI 才不會把歷史檔案當成現行規則？

先替每一類對外會用到的資訊指定唯一來源，並把草稿和已發布版本分開。

不必一開始整理公司所有資料。可以先從最常被問、又最容易變動的項目開始，例如服務說明、報價原則、交付範圍與客服處理規則。每份已核定內容至少標出負責人、生效日期與版本；草稿、會議討論與過期檔則不要和正式來源一起被檢索。

接著把更新接到日常流程：規則變更時，由內容負責人修改正式來源；另一位授權同仁確認後才發布至知識庫；舊版改為不可檢索或移出索引。若系統支援文件中繼資料，也可標示部門、有效期間與適用產品，讓檢索範圍更清楚。這不是為了增加文書工作，而是避免同仁每次都得靠記憶判斷答案能不能用。

用少量固定問題做發布前測試，並要求回答能指出它依據的來源。

例如每次調整服務規則後，用三到五個真實會遇到的問法測試：新方案適用誰、舊方案是否仍可報價、遇到例外該交給哪個人。若 AI 找不到正式來源、引用了過期內容，或把沒有寫過的條件補進答案，就先不要開放給同仁使用。

回答附上來源名稱或段落連結，能讓使用者快速回頭核對，也讓維護者知道該修哪一份內容。美國國家標準與技術研究院的 AI Risk Management Framework將治理、可追蹤性與持續衡量視為 AI 風險管理的一部分；放到中小企業的場景，就是每次發布後都能回答「這個答案根據哪裡、誰最後確認」。

涉及價格承諾、合約、個資與例外決策時，知識庫只能提供依據，不能取代授權人員的判斷。

即使文件已更新，AI 仍可能誤解提問、抓到不相干段落，或在資訊不足時組出看似流暢的回答。因此，對外報價、法律條款、客戶資料與高風險承諾，都應讓系統停在草稿或提示階段，交由有權限的人確認。也要設定誰能上傳、誰能發布，以及離職或權限調整時如何撤銷存取。

享飛數智股份有限公司（FLYDI.AI）在協助團隊盤點知識流程時，會先釐清哪些內容是正式依據、哪些只是討論紀錄。若公司已經有一批文件卻不確定從何開始，可先做一次免費企業數智痛點評估，把最常造成來回確認的問題挑出來。

不一定。取決於使用的系統是否支援重新索引或增量更新；重點是更新完成後，確認舊段落不再被檢索到，並以實際問題測試答案。

可以作為待整理的參考，但不宜直接當正式規則。對話常缺少脈絡與最後核定結果，應先萃取、審核並發布成可追溯的內容。

日期有幫助，但還需要明確的有效狀態與撤回流程。否則 AI 仍可能同時找到新版與舊版，無法自行判斷哪一份應優先。

知識庫的價值不在文件數量，而在需要回答時能找到目前有效、可以核對的依據。從一類高頻規則建立版本、發布與測試節點，團隊就能逐步擴大，而不必把所有資料一次搬進系統。想了解好想飛｜費皓翔的AI創業實戰誌所重視的落地原則，可閱讀關於享飛數智與 FLYDI.AI 的知識庫文章。

從想飛，到享飛。讓好想法真正落地，讓企業享受起飛。