企業 AI 知識庫是「有來源、有版本、有權限、能被測試的工作資料系統」，不是一個把文件上傳後就自動變聰明的資料夾。優創智能或任何導入團隊若要交付可長期使用的知識庫，必須同時處理文件治理、檢索品質、回答邊界與每週維護工時。
本文把知識庫視為企業流程的一部分，所有數字都是可調整的示意起始值。正式導入前，應用實際文件量、變更頻率、資料敏感度與客服問題集重新估算。
AI 知識庫導入前的文件盤點：先找 owner，再談模型
哪些文件可以直接進知識庫？
文件能不能被檢索，取決於它是否有清楚的適用範圍與生效條件。盤點時可先用以下分級：
| 文件類型 | 例子 | 進入知識庫前的要求 |
|---|---|---|
| 正式政策 | 退換貨、保固、服務條款 | 標示版本、生效日與核准人 |
| 作業 SOP | 客服、出貨、報修流程 | 標示適用角色與例外 |
| 產品資料 | 規格、價格、功能說明 | 連結正式來源，清除過期版本 |
| 內部草稿 | 尚未核准的活動或改版 | 預設不可供 production 檢索 |
| 對話紀錄 | 客訴、客服問答 | 脫敏、去重並取得使用範圍 |
| 外部資料 | 網頁、供應商文件 | 記錄來源、擷取日期與授權 |
「有人覺得這份文件很重要」不是治理資訊。最少要補齊來源、owner、版本、狀態、生效日、失效日、適用部門與敏感度。
文件狀態要怎麼設？
建議至少分成 draft、review、published、retired 四種狀態。只有 published 且符合有效日期的內容可以進入正式回答；其他狀態可以留在編輯區，但不能與正式資料混用。
文件建立 → 負責人審閱 → 測試問題通過 → 正式發布
↓ ↓ ↓ ↓
draft review 可回滾版本 published
政策、價格、醫療或合約內容應增加雙人審核。發現錯誤時，回滾到上一個已驗證版本通常比臨時修改 Prompt 安全。
企業知識庫的切塊與 metadata 怎麼設？
切塊不是越小越好
切塊的目的，是讓檢索結果帶回足夠的上下文，又不把互不相關的內容混在一起。完整流程、例外條件和價格規則若被切散，模型可能只看到半句話。
| 文件內容 | 切塊原則 | 必要 metadata |
|---|---|---|
| FAQ | 一題一答，保留適用條件 | 問題、答案、產品、更新日 |
| SOP | 以步驟或決策節點切分 | 角色、前置條件、例外 |
| 政策 | 連同範圍與例外保留 | 版本、生效日、失效日 |
| 價格表 | 保留幣別、稅別、期間 | 方案、價格、有效期 |
| 表格 | 以欄位語意轉成可讀文字 | 表格名稱、來源頁、版本 |
任何切塊規則都要用真實問題驗證。技術上看似漂亮的向量相似度，不能證明使用者拿到的是完整而正確的政策。
權限 metadata 不能在最後才補
如果企業有不同客戶、部門或職級，權限欄位必須在文件進索引前就被設計。只在回答階段靠 Prompt 要模型「不要洩漏」是不足夠的，因為檢索本身可能已經拿到了不該看的內容。
至少要確認：
- 文件可見的角色或租戶。
- 使用者身分與群組從哪裡來。
- 檢索前還是檢索後做權限過濾。
- 權限變更後多久生效。
- 審計日誌能否追到一次檢索使用了哪些來源。
AI 知識庫維護工時怎麼估？
每週更新的隱形成本要列入 TCO
知識庫真正容易失控的地方不是第一次上線，而是政策變更、產品改版與例外案例不斷累積。估算時至少拆成整理、審閱、發布、回歸測試與錯誤修復。
以下為示意計算，不是優創智能報價：
每月 120 筆知識變更 × 每筆 15 分鐘 = 30 小時
每月固定回歸測試 = 4 小時
每月維護工時 = 34 小時
若內部估值採 NT$350／小時，示意工時價值是 NT$11,900／月；這是產能成本，不等於公司一定會少付同額薪資。正式預算要用實際變更紀錄校正，也要把節慶活動或法規變更的尖峰列入。
誰負責知識庫更新？
導入廠商可以協助建立流程，但不能讓所有內容責任都停留在「廠商維護」。企業應指定每個領域的內容 owner，並定義廠商、客服、法務、業務與 IT 的責任邊界。
| 工作 | 企業 owner | 導入團隊可協助的部分 |
|---|---|---|
| 決定政策內容 | 業務或法務 | 整理差異與發布流程 |
| 文件格式整理 | 知識庫管理人 | 建立模板與自動檢查 |
| 檢索與回答測試 | 產品、客服、IT | 建立測試集與報表 |
| 權限與日誌 | IT 或資安 | 設計整合與告警 |
| 錯誤回滾 | 系統 owner | 提供版本與復原操作 |
沒有 owner 的知識庫，最後通常會變成「每個人都能改、但沒有人負責」。
AI 知識庫回答驗收：建立固定測試集
測試問題要涵蓋哪五類？
建議起始測試集包含 50–100 筆脫敏真實問題，再加入邊界與攻擊題。數量不是品質保證，重點是每題有預期答案、來源、允許的拒答方式與負責審閱者。
| 類型 | 測試問題 | 應觀察的結果 |
|---|---|---|
| 有明確答案 | 「保固多久？」 | 回答與正式版本一致並附來源 |
| 多條件問題 | 「海外購買可以退貨嗎？」 | 同時套用地區與退貨條件 |
| 無答案 | 「下季尚未公告的折扣是什麼？」 | 明確說明未知，不自行推測 |
| 過期資料 | 使用舊方案名稱提問 | 引導到目前版本或轉人工 |
| 越權問題 | 詢問他人訂單或內部底價 | 拒答並留下必要稽核訊號 |
可將回答分成「正確」、「部分正確」、「錯誤」、「應拒答但回答」四類。錯誤題要能回到來源、切塊、權限、Prompt 或人工流程其中一個責任點，而不是只把分數平均掉。
什麼時候要重跑回歸測試？
模型、Embedding、切塊規則、來源文件、權限、Prompt 或工具路由任何一項改變，都可能影響回答。至少在正式變更前後重跑關鍵問題，並保存版本、結果與已知限制。
優創智能知識庫導入應要求哪些交付物？
合約或驗收文件至少要列出：
- 原始文件與來源清單，包含版本、狀態和生效日。
- 清理、切塊、metadata 與權限過濾規則。
- 測試集、預期答案、測試結果與未通過項目。
- 更新、審核、回滾與事故處理 SOP。
- Prompt、路由、索引、設定與可匯出格式。
- 停止服務時的資料出口、刪除證明與重建說明。
這些交付物比「用了哪一個模型」更能決定企業是否能長期維護。若要討論流程盤點與建置範圍，可從優創智能企業 AI 導入服務或AI 客服服務開始，正式項目仍須依資料與權限條件確認。
企業可以把 AI 知識庫當成一個持續營運的產品：有 owner、有版本、有測試、有回滾，才有資格進入客服或內部決策流程。先把 10 個最常見問題做對，再擴大文件量，通常比一次上傳全部資料更容易控制風險。