先做可驗證 POC，再談整間公司的知識庫。
RAG 的重點不是把文件全部丟進去，而是能不能找對來源、引用正確、在不確定時拒答，並遵守不同使用者的權限。
-
盤點
整理來源、更新責任與存取權限
先排除過期、重複與不該被搜尋的內容，再定義誰可以問到什麼。
-
驗證
用真實問題測命中、引用與拒答
以已知答案的問題建立測試集，逐項檢查來源是否正確，不只看回答讀起來順不順。
-
交付
留下可更新、可追查、可人工覆核的流程
文件更新、失敗案例與權限變更都要有明確處理方式，避免做成一次性展示。
先把證據與邊界做清楚，再讓 AI 回答。
公開案例可核實 Frank 有把多來源資料、證據缺口與人工決策整理成可追查系統的經驗；這不是把它包裝成已完成的 RAG 客戶案例。
- 驗證核心
- 來源 / 引用 / 拒答 / 權限
- 公開邊界
- 不宣稱未公開的導入成果
企業 RAG 是否值得做，先看四個現實條件。
文件品質、問題範圍、權限與驗收方式，比選哪一個模型更早決定專案能不能成功。
RAG 和一般聊天機器人差在哪裡？
RAG 會先從核准的知識來源找資料，再依來源回答；驗收重點包含引用是否正確，以及沒有證據時是否拒答。
什麼情況不適合現在做？
文件大量過期、權限尚未釐清，或團隊沒有代表性問題與負責維護內容的人時，應先整理資料。
費用與時程怎麼估？
先依文件量、來源種類、權限層級、問題範圍與既有系統評估；小範圍 POC 通過後再決定擴充，不先承諾一個不可靠的固定價。
資料安全怎麼處理？
第一階段可用去識別化樣本；正式導入前要先確認資料存放、模型供應商、權限與保留政策，不要求你在初談時交出帳密或完整機密文件。
如何驗收？
先建立真實問題測試集，檢查回答、引用、拒答與權限隔離；雙方同意的條件通過才進下一階段。
先挑一組最常被問的問題，做小範圍驗證。
第一次只需要說明文件來源、使用者與問題情境；是否適合做 RAG，會先直接判斷。