談到企業文件查詢，RAG 是我想接著整理的方向。因為要看的不只是答得準不準，這一階段先把用途、責任與風險想清楚，再決定 PoC 要從哪裡開始。

RAG 會先找出相關文件片段，再由語言模型整理回答。有來源可以對照，確實比較容易查證，但回答仍可能出錯。因此，正式文件與具權責人員的判斷，還是要保留下來。

本篇名詞小筆記

• RAG：檢索增強生成（Retrieval-Augmented Generation），先從核准資料中找出相關片段，再由語言模型組織回答。
• PoC：概念驗證（Proof of Concept），用有限範圍與測試資料確認想法是否可行。
• AI Use Case：AI 使用情境，記錄使用者、資料來源、輸出用途、風險、覆核與停止條件。
• 受控文件：經過核准、有版本與有效日管理的正式文件，改版與作廢都要留下紀錄。

今天要解決的問題

找一份 SOP，和判斷產品能不能放行，需要承擔的責任差很多。但放在同一個問答畫面裡，這個差別不一定看得出來。因此，我會先想使用者會拿答案做什麼。用途要先分清楚，後面的設計才有方向。

所以，我想先把幾件事寫下來：哪些用途允許、哪些不能用、誰要覆核，以及回答錯誤會影響什麼。

架構師視角：先界定允許與禁止的用途

整理用途清單時，我會特別看答案會不會直接帶出後續動作。如果涉及過帳、放行或權限核准，就需要更清楚的控制與責任安排，不能只當成一般文件查詢。

一開始，我會先評估 SOP、系統文件、FAQ、架構決策與教育訓練資料的查詢。下面這幾類影響比較大的用途，則必須由具權責人員覆核，不能交給 RAG 自動決定：

• 影響產品安全的專業判斷。
• ERP 過帳及交易資料修改。
• 產品放行與品質異常結案。
• 權限核准及法規符合性判定。
• 對外發佈具有法律、品質或客戶承諾效果的內容。

圖 Day 21-1：企業 RAG 流程。

資料不足時，能清楚說明查不到，或請人協助確認，我認為也是系統需要學會完成的一件事。所以圖的最後，我也把拒答放進來。

用途寫進規範之後，還要看看系統怎麼配合。該阻擋的操作、該提示的限制，都要有實際做法。下一篇會再把這部分接到資料與權限控制。

工程師視角：導入前要準備的控制項

開始之前，我會先整理 AI Use Case 清冊、風險登錄、資料來源白名單、角色與資料範圍矩陣、人工覆核及事件通報方式。每一項都找到負責人，也確認之後怎麼檢查。

每個用途，再補上使用者、資料來源、輸出用途、錯誤影響與人工覆核者。發生問題時要有共同依據，所以我也想保留停止條件，提早寫好：什麼情況要先暫停？

風險評估應包含資料敏感度、答案用途、使用範圍，以及是否會觸發後續操作。可先選低風險的內部唯讀查詢來驗證。涉及個資、品質系統、產品安全、對外承諾或自動交易時，則需提高審查與驗證要求；風險無法控制的用途，應排除在使用範圍外。

策略取捨與限制

文件會改版，權限與模型也會調整，這些都需要持續維護。評估時把資料整理、索引同步與回答品質檢查的時間一起算進來，才知道後面能不能照顧得好。

驗證方式與衡量指標

這一階段，我想先完成下面這些準備，讓 PoC 驗收有清楚的範圍：

等 PoC 實際測完，再來整理準確率與效能。之後分享結果需要清楚的依據，所以現在先把題目與計算方式準備好。

今天先整理到這裡

今天先把 RAG 想用在哪裡、哪些事情不能交給它，以及由誰負責整理清楚。下一篇，再一步一步走到資料、權限與 PoC 的驗證方式。

參考資料

1. NIST, NIST AI RMF，查閱日期：2026-10-04。
2. ISO, ISO/IEC 42001，查閱日期：2026-10-04。