YAOAIM / CONCEPT VISUALTHE QUESTION / 核心問題
把文件丟進 AI，就能回答公司問題嗎？
先看一個虛構工作情境，再依序檢查適用界線、準備材料與驗收方式。內容是判斷框架，實際做法須依你的資料、權限與工作責任確認。
ILLUSTRATED WORKFLOW / 情境示意
虛構情境：客服查詢內部服務規則
以下僅說明可能的知識檢索設計，不代表 YAOAIM 已開通知識庫產品或連到任何客戶資料。
- STEP 01
文件
服務說明、處理規則和舊版公告散在三個資料夾，部分內容只有主管可看。
- STEP 02
檢索
先依使用者權限找出可看的有效文件，再擷取相關段落供問答參考。
- STEP 03
核對
回答附文件名稱與版本；沒有可靠依據或內容衝突時，改請文件負責人確認。
01 / 文件準據
先選出誰說了算的文件
知識庫最常見的風險不是回答得不流暢，而是流暢地引用舊資料。每類問題需要指定權威來源、文件負責人、生效日期與失效方式。若服務條款已更新，舊簡報不能因為文字更完整就繼續當答案。
可先做一份文件清單：名稱、用途、負責人、對象、版本、更新日期與停用條件。找不到責任人的文件，先不要放進可對外使用的回答範圍。
- 準據
- 同一問題有多份文件時，哪份優先？誰能確認？
- 版本
- 內容更新後，舊版要保留供稽核，還是停止被檢索？
- 時效
- 臨時公告何時失效？失效後是否需要重新審查答案？
02 / 存取權限
先限制可檢索內容，再產生回答
若一般客服不能讀主管資料夾，問答介面也不能藉由搜尋結果透露其中內容。權限檢查必須套用在取得文件的階段，而不只是在回答最後加一句「請勿洩漏」。
權限要跟角色和資料來源同步變更。員工調職、離職、專案結束或文件改列機密時，原先的存取權限和相關快取都需要檢查。實作方式取決於實際系統；設計時先把誰能看什麼寫清楚。
- 角色
- 一般員工、主管、外部合作方各能看到哪些文件類別？
- 隔離
- 客戶 A 的資訊不可在客戶 B 的搜尋與回答中出現。
- 撤銷
- 權限收回、文件刪除或更新後，舊內容何時不再可用？
03 / 回答品質
回答要能追到來源，也要允許說不知道
對每個重要答案，顯示可核對的文件名稱、段落與版本資訊。若找不到依據，應回答「目前資料不足」並指出下一步，而不是把一般常識說成公司的正式政策。
測試資料要包含同義問法、過期文件、互相矛盾的說明、無答案問題與權限外提問。答案看似正確仍要抽查來源；引用到不該看的文件就是失敗。
04 / 持續維護
知識庫是一套內容維護工作，不是一次匯入
指定誰審查新增文件、誰修正錯誤答案、誰處理使用者回報。每次更新重要規則時，應重跑相關問題，確認新舊版本不會同時被當成有效答案。
第一版可以只涵蓋少量高頻、低風險問題。等文件治理與權限測試站穩，再擴大到跨部門知識或對外問答。
DECISION / 何時開始
哪些情況適合？哪些先緩一緩？
先判斷當前條件是否足夠，再決定要實作、補資料，或先把現有流程整理好。
適合開始
- 有明確文件負責人，且常見問題能對應到可核對的文件。
- 資料來源的權限、版本與更新責任可以說清楚。
- 使用者能接受找不到答案時由人接手，而非強求每題都有回覆。
先緩一緩
- 同一主題的文件彼此衝突，且沒有人能決定準據。
- 文件包含敏感資料，但無法區分使用者或客戶的可見範圍。
- 期待一次上傳所有檔案後就無需維護。
MAKE IT REVIEWABLE / 帶回去用
準備清單與驗收條件
把討論變成可檢查的材料，才知道第一版要做到哪裡。
開始前準備
- 01建立首批文件清單，標示負責人、版本、生效日與可見角色。
- 02選定一小組高頻問題及其有效依據。
- 03定義無答案、來源衝突與過期文件的回覆方式。
- 04列出新增、更新、撤銷與刪除文件的維護責任。
- 05準備不同角色的測試帳號與權限外提問。
怎麼算完成
- 01每個可回答的測試問題都能追到有效且有權存取的來源。
- 02無權查看的文件不會出現在搜尋結果、引用或回答中。
- 03文件失效後，測試問題不再引用舊版作為現行規則。
- 04找不到依據或來源衝突時，系統標示待確認並交由指定人員處理。
NEXT STEP / 下一步
依你現在需要的深度，繼續往下看
指南提供準備方向；實際工作範圍與責任界線，需要在需求盤點與文件中確認。
原始文件延伸參考
以下為官方原始文件，供進一步查核設計原則；不代表本網站採用該平台或已實作其功能。
- Microsoft Learn：文件層級存取控制 官方技術文件，說明檢索時依使用者身分限制可見文件的作法。