企業的知識庫 AI，是讓員工用自然語言提問，系統先從公司內部文件找出相關段落，再交給生成式 AI 依這些段落組織回答並附上出處，這種做法稱為檢索增強生成（RAG）。建置可以分五步：盤點文件來源與負責人、整理格式與版本、建立索引與權限篩選、用題庫驗證回答與引用、上線後持續更新。決定品質的關鍵不只是選哪個模型，更在於文件是否正確、是否為現行版本，以及系統是否只讓每個人查到自己有權看的內容。本文聚焦內部文件問答，對外客服機器人的做法另有不同考量。
企業 AI 知識庫的運作方式
Microsoft Learn 對 RAG 的說明是：一種透過將回應建立在專有內容基礎上，擴展大型語言模型能力的模式。一次問答大致經過四段：
- 員工提出問題，系統以問題到文件索引中檢索。
- 索引在建立時已把大型文件切分成段落，讓每個段落能獨立比對，找出相關的幾段。
- 相關段落與問題一起送給模型，模型依這些內容組織回答。
- 回答附上引用的文件，讓員工點回原文確認。以 OpenAI 的檔案搜尋為例，回應會帶有檔案引用。
它和知識管理系統是上下層關係：分類、版本與審核制度屬於知識管理系統的範圍，AI 知識庫是建在這些內容上的查詢方式。給客戶使用的機器人要處理轉真人與對外回覆責任，可參考AI 聊天機器人的做法。
準備事項：盤點文件來源與負責人
先列出要放進知識庫的文件，每一類填寫五個欄位：
- 來源：標準作業程序、規章制度、產品手冊、內部常見問答、教育訓練教材、合約範本。
- 現行版本存放處：雲端硬碟、內網、文件管理系統或個人電腦，同一份文件有多處時指定一處為準。
- 負責人：內容有誤或規定改變時，由誰修正。
- 機密等級：全員可看、部門限定、主管限定或不放入知識庫。
- 更新頻率：例如價目與流程常變，規章較少變動。
草稿、已失效的版本，以及含大量個人資料但員工查詢用不到的檔案，先排除在外。一開始挑一個部門、一類高頻問題試行，比一次匯入全部檔案容易看出問題。
文件整理：格式、版本與中繼資料
AI 只能依文件內容回答，文件本身混亂，回答就會混亂。整理重點如下：
- 掃描檔轉成文字：圖片型的 PDF 先做文字辨識並校對，表格轉成欄位清楚的格式。
- 一份文件一個主題：用清楚的標題與小標分段，檢索切分時段落才不會混入無關內容。
- 刪除重複與舊版：新舊兩版同時存在，系統可能引用到舊規定。Open Worldwide Application Security Project（OWASP）也把互相衝突的資料來源列為向量檢索的風險之一。
- 補上中繼資料：每份文件標註部門、機密等級、生效日與負責人。以 OpenAI 的檔案搜尋為例，可以依檔案的中繼資料篩選搜尋結果，這些標籤之後也是權限篩選的依據。
- 把口頭知識寫下來：常被問、但沒有文件的問題，先由負責人寫成問答，再放進知識庫。
建置步驟：從選架構到試點上線
- 選擇架構：文件已集中在協作平台時，可以先評估平台內建的 AI 功能，以 Microsoft Copilot 為例，官方說明它只會顯示個別使用者至少具有檢視權限的組織資料。需要整合多個來源、自訂權限或嵌入公司系統時，透過模型供應商的 API 與檢索服務自建。
- 匯入文件與中繼資料：從指定的現行版本存放處匯入，保留文件網址或編號，回答才能連回原文。
- 建立索引：設定文件切分方式與要保存的欄位，標題、生效日與機密等級都要跟著段落存。
- 設定權限篩選：檢索時依提問者身分過濾，做法見下一節。
- 訂回答規則：只依檢索到的內容回答、找不到相關文件時直接說明查無資料、每個回答附出處。
- 接上使用介面：放在員工已經在用的內網或後台，沿用公司帳號登入。
- 小範圍試點：先開放給一個部門，蒐集答錯與答不出的問題再擴大。
權限分級：檢索之前先過濾
權限要在檢索階段處理，而不是讓模型讀完所有文件後再「不要說出來」。做法是每個段落帶著可閱讀的群組標籤，查詢時只檢索提問者所屬群組可以看的段落。以 Azure AI 搜尋的安全性篩選為例，官方說明它根據包含群組或使用者識別碼的字串篩選結果，而這些識別碼本身未經驗證或授權，所以應用程式必須先透過公司登入確認使用者身分與群組，再帶入查詢。
使用平台內建功能時，要先整理既有的檔案權限。Microsoft 說明 Copilot 會顯示使用者有檢視權限的資料，並提醒要用 SharePoint 等權限模型確保正確的人存取正確的內容；過去「全公司可檢視」的資料夾，就可能被查到。OWASP 對向量檢索的建議也一致：細緻的存取控制、具權限感知的向量儲存、資料集依使用者群組分區，並保留檢索紀錄。
驗證回答：題庫、引用與拒答測試
上線前準備一份題庫，題目來自員工實際問過的問題，每題寫下正確答案與應該引用的文件，逐題檢查：
- 答案是否正確：和負責人確認，不只看語氣是否流暢。
- 引用是否對應：出處要指向現行版本，而不是舊版或無關文件。
- 查無資料時是否拒答：問知識庫沒有的事，應回答找不到，而不是自行推測。
- 權限是否生效：用一般員工帳號詢問主管限定的內容，確認查不到。
- 是否被文件中的指令影響：在測試文件放入「忽略前面的規則」這類文字，確認回答不受影響。
答錯時先檢查是文件缺漏、舊版沒刪，還是切分方式讓段落斷在關鍵處，優先修文件，再調整檢索設定。
個資、提示注入與上線後維護
個人資料保護法第二十條規定，非公務機關對個人資料的利用，原則上應於蒐集之特定目的必要範圍內為之，條文另列有可做特定目的外利用的情形，第六條所規定的特種個資則另有規範。把客戶或員工資料放進知識庫前，先確認這樣的利用是否在原本的蒐集目的內，非必要的個資欄位不要入庫。OWASP 說明，模型讀取網站或檔案等外部來源時可能發生間接提示注入，RAG 與微調都無法完全緩解，建議把模型權限限制在必要範圍，高權限操作保留人工確認。送給 API 的資料怎麼被處理，依各供應商的資料政策評估。
上線後，文件修改要觸發重新索引；人員離職或調動時同步調整群組；定期整理答不出與被回報錯誤的問題，交給文件負責人補充。以上為概念整理，個資與資安的實際適用，以主管機關公告或專業意見為準。
常見問題
AI 知識庫會不會把公司資料拿去訓練模型？
依服務與方案而定。以 Microsoft Copilot 為例，官方說明透過 Microsoft Graph 存取的提示、回應和資料不會用來訓練基礎模型。自建時要逐一確認所用 API 的資料使用政策與保存期間。
AI 知識庫的回答可以完全相信嗎？
不能。即使有檢索文件，模型仍可能理解錯誤或引用舊資料。回答附上出處讓員工核對，涉及合約、財務或法規的內容，應由負責人確認後再使用。
文件很多，要一次全部放進去嗎？
不建議。先挑一個部門的高頻問題與對應文件試行，確認回答品質、權限與更新流程都正常，再逐步加入其他部門，比較容易找出問題來源。
不同部門的機密文件可以放在同一個知識庫嗎？
可以，但要在檢索時依提問者的群組過濾，並確認身分由公司登入驗證。機密程度很高、只有少數人能看的文件，也可以分開建立獨立的索引。
建好之後要怎麼維護？
每份文件指定負責人，修改後重新索引；定期整理答不出或答錯的問題補充文件；人員異動時同步更新群組權限，並移除已失效的文件。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
建議先盤點一個部門的常見問題與對應文件，標出負責人與機密等級，再決定用平台內建功能或自建。京采可以協助規劃內部知識庫的系統架構、公司帳號登入與權限群組，透過 API 串接模型與檢索服務，並把查詢介面整合進既有內網或後台。可參考網頁設計服務，或與我們聯繫討論文件與權限現況。
