AI Engineer onepage/ Data readiness
速讀 · 設計取捨 · 實務清單Leo Platzer & Jeff Koss · Deasy Labs / Collibra · 20:36
這支影片在講：RAG 上線前，先把文件資料變成可用的資料
小型 POC 能回答問題，不代表企業文件庫能工作。真正卡住 chatbot 的往往不是模型，而是重複、衝突、過期與不該被取用的文件。
Published: 2026-10-05Video ID: wzWNYDY7toc
01 / 問題
40 份文件可以，8 萬份就崩
手挑檔案的 chatbot POC 看似成功；接上完整 SharePoint 後，雜訊與矛盾內容讓檢索品質失真。
02 / 反轉
文件品質不只看是否有內容
重複、衝突與過期都會占走 context window；敏感資料若未先識別，也不該進入回答路徑。
03 / 解法
把治理做成可驗證的資料層
用 taxonomy、metadata、引用證據與 confidence，配合資料切片與排程更新，讓檢索結果可追溯、可刷新。
Signals
四個會改變 RAG 設計的訊號
Corpus
80,000
案例中的 SharePoint 文件規模；不能再靠手工挑選與規則維護。
Noise impact
80%
當約三成 corpus 過期或重複，agent 取回的 context 最多可有八成無用。
Recall
約 2×
清理資料後，多跳 RAG 評估的 recall 約提升一倍。
Cycle time
月 → 天
AI 輔助分類與標記，把整理與上線準備從數月壓縮到數天。
Core story
讓 POC 卡在生產前的三個資料陷阱
陷阱 1
只把文件「收進來」，沒有判斷它是否值得取用
RAG 對文件沒有天然的真偽或新鮮度判斷。缺少 taxonomy 與 metadata 時，模型看到的是混在一起的候選答案，而不是已被整理過的知識。
陷阱 2
把 duplicate、conflict、stale 當成搜尋問題
這些是資料品質問題：相同政策有多個版本、內容互相矛盾、舊文件仍被檢索，都會把 context window 擠滿，並提高錯答機率。
陷阱 3
清理一次後，就假設語料庫不會再變
企業文件會持續新增與過期；需要資料切片、排程 refresh 與可回看的品質檢查，否則新鮮度會再次成為隱形故障。
Design choices
這不是清檔案，而是為 agent 建一層證據鏈
分類要能說明「為何」自動 taxonomy 與 metadata tagging 不只輸出標籤，也要保存 evidence 與 confidence，才能抽查、修正與建立信任。
先標出資料暴露風險敏感資料偵測應位於 chatbot 之前；先識別與過濾，不要把權限判斷交給回答時的 prompt。
把品質切成可操作的 slice依領域、敏感度、文件類型或擁有者切片，讓團隊能分批驗收與更新，而不是一次面對整個 corpus。
評估必須連到檢索結果以 multi-hop RAG recall 等任務指標驗證清理效果；否則「標籤做完」只是流程完成，還不是產品改善。
Checklist
準備擴大 RAG 前，先問團隊這五題
每筆文件是否有來源、擁有者與更新時間？沒有這些欄位，就無法處理 freshness，也難以對答案負責。
重複與衝突內容有沒有被找出並決定優先版本？先降低噪音，才能讓模型把有限 context 花在正確內容上。
自動標記是否附帶 evidence 與 confidence？這讓人工可快速審核低信心項目，而非重做所有分類。
敏感資料是否在索引／檢索前就被治理？把安全控制前移，避免「回答得很好」卻不該回答的結果。
資料清理是否以 RAG 任務評估證明成效？將資料品質連結到 recall、faithfulness 與人工處理成本，才知道投入是否值得。
Source video