「我們公司的資料都在 PDF、Google Drive、Notion、LINE 和同事腦袋裡，這樣可以做 AI 知識庫嗎？」
可以先做。但要分清楚兩件事：做出一個能回答幾題的 demo，和做出一個團隊敢用、客戶能信任的系統，不是同一個標準。
AI 知識庫最常被低估的，不是模型，而是資料治理。檔案丟進去很快，真正花時間的是確認哪份才是最新版、誰能看、答案從哪裡來、錯了誰修、文件更新後多久會同步。
資料很散不是不能開始。更實際的做法是先縮小範圍，整理一組高價值資料，用真實問題驗證，再決定要不要擴大。
AI 知識庫到底在做什麼？
多數企業 AI 知識庫不是重新訓練一個專屬模型，而是讓系統在回答前，先從公司的文件中找出相關片段，再把那些片段提供給模型生成答案。這類做法常被稱為 RAG。
流程可以簡化成四步：
- 讀取公司允許使用的文件
- 把內容切成可搜尋的片段並建立索引
- 使用者提問時，先找出最相關的資料
- 根據找到的內容回答，附上來源或轉給真人
它的好處是資料可以更新，也比較容易追溯答案。但 RAG 不是「把資料丟進去就不會亂答」。如果原始文件互相矛盾、版本過期、段落缺乏上下文，搜尋再準也可能拿到錯的內容。
如果你還在判斷公司第一個 AI 專案要做什麼，可以先看企業想導入 AI，第一個專案該做哪一個。知識庫適合有明確高頻問題、穩定資料來源與人工審核流程的場景。
資料很散，可以先做到什麼程度？
可以把導入分成三個層次。
| 階段 | 目標 | 資料要求 |
|---|---|---|
| 概念驗證 | 確認幾類問題能不能被回答 | 一小組代表性文件即可 |
| 內部試用 | 讓特定團隊在工作中使用 | 來源、版本與權限要初步整理 |
| 正式上線 | 對員工或客戶提供穩定服務 | 需有同步、監控、維護與例外處理 |
資料散亂時，最合理的是先做概念驗證。不要一開始就匯入整個雲端硬碟，也不要先承諾能回答所有公司問題。
先選一個範圍，例如：
- 業務常問的產品規格
- 客服重複回答的售後問題
- 新人常查的內部 SOP
- 專案經理常找的交付規範
- 維修人員使用的故障排查手冊
範圍越清楚，越容易知道系統有沒有用。
導入前要整理哪 5 件事？
1. 來源：答案應該相信哪裡？
先建立資料來源清單。不是把所有檔案列完，而是找出會影響答案的正式來源。
| 欄位 | 要記錄什麼 |
|---|---|
| 資料名稱 | 產品手冊、FAQ、SOP、合約範本 |
| 位置 | Drive、Notion、網站、資料庫、內部系統 |
| 負責人 | 誰能確認內容正確 |
| 使用情境 | 客服、業務、內部教育、技術支援 |
| 敏感程度 | 公開、內部、部門限定、機密 |
| 更新頻率 | 不定期、每月、每季、事件觸發 |
同一個問題如果在官網、簡報與客服話術各有一版，要先指定哪一個是正式來源。否則 AI 可能引用舊簡報，真人卻以官網新規則為準。
2. 版本：哪些內容已經過期？
企業文件最常見的問題不是沒有資料，而是資料太多、太舊。
匯入前至少分成三類：
- 現行：可以直接用於回答
- 待確認：可能有用，但需要負責人審核
- 停用：過期、重複或不得再引用
不要期待 AI 自己看日期就知道新版一定正確。有些檔名有日期，有些沒有；有些新版只改了一段，舊版仍在共享資料夾。系統需要明確的版本規則。
也要處理生效日。例如價格將在下個月調整，AI 何時開始回答新價格？舊規則要不要保留給歷史案件？這些都不是模型能替公司決定的。
3. 權限：誰可以問到什麼？
內部 AI 知識庫一旦把多個來源接在一起，權限風險會比單一資料夾更高。
常見情況包括：
- 業務看得到公開產品資料，但不該看到人事文件
- 一般員工看得到 SOP，但不該看到客戶合約
- 客服能查訂單說明，但不能查其他客戶個資
- 外部聊天機器人只能使用公開 FAQ
- 管理者可以看完整來源與同步紀錄
要先決定系統是「所有人共用同一套資料」，還是會依帳號、部門、角色套用不同權限。
個資、合約、薪資、醫療、財務或客戶機密，不應該因為方便就整批丟進同一個索引。先做資料分級，再設計存取方式。
4. 結構：文件能不能被正確切開與理解？
模型看得到文字，不代表它看得懂文件關係。
幾種常見問題：
- 掃描 PDF 沒有可選取文字
- 表格跨頁，欄位與數值被拆散
- 標題寫「方案 A」，下一頁只剩價格沒有方案名
- 每段都用「本產品」「上述規則」，離開原頁就沒有上下文
- 圖片裡有重要流程，但沒有文字說明
- FAQ 一題包含多個不同情境
整理時可以優先做這些事：
- 補清楚標題與章節
- 一段只處理一個主要問題
- 把關鍵表格轉成可讀的結構化資料
- 為圖片、流程圖補文字說明
- 保留產品、版本、地區、生效日等 metadata
- 將過長文件拆成可獨立理解的主題
不是每份文件都要重寫。先處理最常被問、回答錯誤成本最高的那一批。
5. 維護：誰負責讓答案不過期？
AI 知識庫不是一次性匯入專案。只要產品、價格、流程、法規或人員會變，資料就需要更新。
要先定義：
- 文件更新後是自動同步還是人工發布
- 多久同步一次
- 刪除來源後，索引多久移除
- 誰能核准新內容
- 使用者如何回報錯誤答案
- 哪些問題一定轉真人
- 系統要保留哪些問答與來源紀錄
如果沒有維護責任，知識庫上線三個月後就會開始失真。最後不是沒人用，就是團隊每次都要再確認一次，省下的時間又被拿回去。
哪些資料不該直接整批匯入？
「資料越多，回答越準」不是必然。錯誤資料越多，搜尋雜訊也越多。
下面幾類資料要先處理：
多個版本的相同文件
保留正式版，舊版若有歷史用途，要加上明確狀態與適用時間。
沒有上下文的聊天紀錄
LINE、Slack、Email 裡可能有好答案，也可能有臨時決定、個人意見與已撤回承諾。聊天紀錄適合拿來找常見問題，不適合直接當正式知識來源。
含敏感資訊的完整資料夾
不要因為接 Drive 很方便，就把整個共享空間一起同步。先以 allowlist 指定資料夾與文件，比事後阻擋安全。
只有圖片或複雜排版的 PDF
先測試文字擷取與 OCR。尤其報價表、規格表與流程圖，畫面看得懂，機器抽出來可能已經失去欄位關係。
沒有人負責的文件
找不到內容負責人的資料，遇到矛盾時就沒人能裁決。這類文件可以先放在待確認區，不要直接進正式回答範圍。
怎麼知道 AI 知識庫真的有用？
不要只測「它會不會回答」。要用真實問題建立測試集。
可以先收集 30 到 100 題常見問題，包含：
- 文件裡有明確答案的問題
- 需要組合兩段資料的問題
- 文件裡沒有答案的問題
- 問法模糊或拼錯字的問題
- 涉及權限或敏感資料的問題
- 應該轉真人的問題
再觀察：
| 指標 | 要看什麼 |
|---|---|
| 找對來源 | 引用的文件與段落是否正確 |
| 回答正確 | 有沒有扭曲、補寫或混用版本 |
| 知道不答 | 沒資料時能不能清楚說不知道 |
| 權限正確 | 不同角色是否只看到允許內容 |
| 節省時間 | 使用者查資料是否真的變快 |
| 可維護 | 更新文件後能不能在預期時間生效 |
如果只拿三個漂亮問題做 demo，很容易高估效果。正式系統要測的是模糊、例外與沒有答案時的行為。
對外客服與內部知識庫，標準不一樣
內部使用時，員工可以看來源、修正答案、回報問題。對外客服則直接影響客戶信任，標準應該更嚴格。
對外前至少要有：
- 清楚限制回答範圍
- 顯示或保留來源
- 敏感問題阻擋
- 低信心時轉真人
- 錯誤答案回報
- 問答紀錄與定期抽查
- 價格、合約、退換貨等高風險問題的特殊規則
如果目標是網站 AI 客服，可以接著看該不該把 ChatGPT 接到自家網站與AI 客服真的要花多少。前者幫你判斷場景，後者拆建置與持續成本。
結論
企業資料很散，仍然可以做 AI 知識庫。重點不是先把所有資料整理完，而是先選一個明確範圍，找出正式來源，用真實問題驗證。
要從 demo 走到穩定上線，至少要處理五件事：來源、版本、權限、結構、維護。少了任何一項，系統都可能看起來會回答，實際卻沒人敢用。
先整理最常用、最有價值、有人負責的資料。二十份乾淨文件，通常比兩千份過期檔案更適合當起點。
如果你想評估現有 Drive、Notion、PDF 能不能做 AI 知識庫，可以直接私訊我。先用 30 分鐘把資料來源、使用者與風險範圍盤清楚，再決定要不要做概念驗證。
