在推動 AI 導入企業的過程中，身為架構師（AI Automation Builder），你一定會遇到大老闆提出的靈魂拷問：
「你這套系統叫 ChatGPT 去分析公司的財務報表和客戶名單，這些機密如果被外流到網路上，誰要負責？」
這就是為什麼你絕對不能叫公司員工把法務文件直接貼到網頁版 ChatGPT。要解決這個痛點，並讓 AI 精準讀取上萬頁的企業內部規章，你必須學會 RAG（Retrieval-Augmented Generation，檢索增強生成） 技術，以及極強大的無程式碼平台 —— Dify 或是 Coze。
但先講一句最重要的判斷：RAG 解決的是「找得到、答得出出處」，不是「答得對」。 這兩件事之間的落差，就是多數企業知識庫上線三個月後被員工放生的原因。
什麼是 RAG 技術？為什麼它能解決幻覺與資安？
RAG 不是新的模型，而是一種讓生成式 AI 在回答之前先去查資料的架構。概念就像是讓 AI 「先去公司的內部圖書館找書，翻到那一頁，然後只照著那一頁的內容回答。」
- 安全隱私：文件會經過切碎並存放在企業自己管理的向量資料庫（Vector Database） 中（不需要懂程式，Dify 這類平台已經包裝好了）。原始文件不會進到公開的網頁版聊天介面，也不會落在員工個人帳號裡。想理解底層原理，可以延伸看 RAG 技術解析與向量資料庫的選型考量。
- 消滅幻覺：如果系統在企業圖書館裡找不到答案，你可以強制命令 AI 說：「資料庫中無此規定」，從根本上緩解 AI 最為人詬病的「一本正經胡說八道」。
要澄清一件事：資料不出門 ≠ 沒有風險
「自架就安全」是這個題目最常見的誤解。RAG 架構本身會引入兩個新的風險面：
- 權限外洩：知識庫是扁平的，只要你把薪資結構、人事考核放進同一個庫，任何員工都問得出來。這是實務上最常發生、也最傷的一種事故。
- 提示注入：被檢索的文件若含有惡意指令，模型有可能照著文件裡的指示行動，這就是 Prompt Injection（提示注入）的攻擊面。只要知識庫會吃外部來的檔案，就必須把這件事納入設計。
🧭 什麼情況適合做 RAG？什麼情況我不建議做
適合的四種狀況
- 文件量大到人找不動：上千頁的規章、歷年合約範本、產品手冊。
- 問題高度重複：同一批問題每週都有人問人資、問客服。
- 答案有明確出處：正確答案就寫在某份文件的某一段，只是沒人找得到。
- 文件會更新：這正是 RAG 勝過微調的地方，換掉文件就等於換掉知識。
我不建議做的四種狀況
- 文件本身就是亂的、互相矛盾的。 RAG 不會幫你整理公司，它只會忠實地把矛盾放大——上午引 A 版、下午引 B 版。該先做文件治理，不是先建知識庫。
- 只有二三十頁的規章。 直接貼進對話的上下文就好；建向量庫、調切塊、養維運完全不划算。不要為了「我們有做 AI」而做 RAG。
- 需要精準計算的場景。 薪資、稅額、年資、加班費——RAG 找得到條文，但算術與跨規則推導是它最弱的一環。請讓它「引出條文＋叫人去算」，不要讓它給數字。
- 沒有人願意長期維護知識庫。 沒有 owner 的知識庫，六個月後就是一座資料墳場。這是我最常勸退的一種：它不是技術問題，是組織問題。
🧰 導入前一定要先處理的三件事
技術部分半天就能做完，這三件才真正決定成敗：
1. 文件治理：每份文件都要有 owner 與版本
最常見的災難是舊版規章還留在庫裡。 員工問「特休怎麼算」，AI 忠實地引用了早已廢止的舊版，還附上出處看起來非常可信。上線前先定下三件事：每份文件誰負責、目前有效版本是哪一份、舊版由誰下架。做法可參考資料治理的實務指南。
2. 權限分層：不是所有人都該查得到所有文件
薪資結構、人事考核、董事會紀錄、客戶名單，一旦跟員工手冊放在同一個知識庫，就等於對全公司公開。正確做法是依存取權限切成不同知識庫，而不是靠 Prompt 叫 AI「不要回答薪資問題」。 用提示詞當權限控管，是這題最危險的偷懶。
3. 驗收題庫：上線前先寫好標準答案
準備 30 到 50 題涵蓋常見與刁鑽情境的問題，每題附上正確答案與應該引用的文件。它有兩個用途：上線前驗收，以及日後換模型、調切塊參數時的回歸測試。沒有題庫，你只能靠「感覺變好了」判斷，那不叫驗收。
🧠 Dify 實戰：打造新人報到員工手冊機器人
對人資部與行政部來說，每天回答「特休怎麼請？請產假要附什麼證明？颱風天可以報加班嗎？」這種重複且繁雜的問題是極大的痛點。
我們來示範如何利用開源的 Dify，建置一隻專屬企業 HR 機器人：
第一步：上傳並清理知識庫（Knowledge）
- 在 Dify 後台建立一個新的知識庫命名為「2026_全公司規章與假表」。
- 上傳公司歷年下來雜亂無章的 PDF：包含保險理賠文件、休假規則、部門輪值班表。
- 【關鍵點】資料清理：RAG 就像一個腸胃系統，Garbage In, Garbage Out（垃圾進，垃圾出）。如果在上傳前，你的 PDF 裡面藏了一堆錯字、或是格式亂七八糟的浮水印，AI 會找不到答案。確保上傳的文件都是純文字或是乾淨的 Markdown 格式，你的機器人會聰明十倍。
第二步：設定大腦運轉邏輯（Prompt Engineering）
在 Dify 的對話設定區，你不是在寫普通的指令，而是在設計這個機器人的個性與底線。
實用系統提示詞（System Prompt）：
# 角色定義
你是本公司內部最溫暖、專業的資深 HR 助理「Amy」。
你的任務是協助解答全體員工針對出勤、休假與福利的疑問。
# 工作準則 (極度嚴格)
1. 只能回答與【人事規章】相關的問題。如果員工問你公司午餐哪家好吃、或是技術部門的程式碼問題，請委婉回絕並說超出了你的職責範圍。
2. 當員工詢問請假天數或算薪資時，請務必先在你的回答末端附上「根據《[引用的知識庫文件名稱]》，您享有...」的字樣，增加公信力。
3. 若你的知識庫沒有答案，或者碰到任何牽涉重大勞資爭議、性騷擾申訴的關鍵字，請停止分析，並提供人事主管（Mark, 分機 1234）的聯絡方式，建議人員親自溝通。第三步：發布與整合（Publishing）
Dify 或是 Coze 做完機器人後，不用請工程師寫前端介面。它會直接生出一段 iframe 或是給你的網頁連結，甚至有的提供一鍵發布到 Slack 或 LINE 官方帳號的外掛。員工們只要打開公司的群組，就能隨時召喚這個永遠不會請假休假的高品質 HR。
AI 架構師的進階挑戰：多知識庫切換
當你為公司建置成功一個 HR 機器人後，老闆可能會貪心地要求：「能不能有一隻萬能機器人，又懂法務合約、又懂財務報表、還懂所有產品規格？」
這時候，千萬不要把所有不相干的資料全部丟進化糞池般的一個超大知識庫。AI 會把「財務部休假規定」跟「行政部休假規定」搞混。
AI 架構師的專業在於：利用 Dify 的「工作流（Workflow）」或是「意圖識別（Intent Recognition）」功能。先讓一個小型 LLM 判斷：
- 使用者問的是錢 👉 去撈財務知識庫
- 使用者問的是法律 👉 去撈法務知識庫
擁有這種將複雜的知識歸檔、並且精準引導 AI 去拿對資料的能力，就是幫助企業實現「第二大腦」落地的最高境界。順帶一提，多知識庫切換同時也是權限分層最自然的實作位置——分流的那一刻，就順便決定了這個人能撈哪幾個庫。
💰 Dify vs Coze：平台選擇指南
| 比較維度 | Dify（開源） | Coze（字節跳動） |
|---|---|---|
| 部署方式 | 可自架伺服器（Docker） | 純雲端 SaaS |
| 資料主權 | 完全掌控，資料不出公司 | 存放在字節跳動的雲端 |
| 發布管道 | 網頁、API、iframe | LINE、Discord、網頁 |
| 適合場景 | 對資安要求高的企業 | 快速做出能用的 Bot |
| 技術門檻 | 中等（需會 Docker 基礎） | 低（全圖形化操作） |
關鍵判斷： 如果老闆的第一句話是「資料不能外流」，選 Dify 自架；如果只是想做一個內部問答 Bot 快速驗證價值，先用 Coze 這類全雲端平台做出 MVP 再說。
但自架不是免費的。 自架換來的是資料主權，付出的是伺服器、備份、升級與有人要負責維運——對沒有 IT 人力的中小企業來說，這筆隱形成本經常大於授權費。如果公司連誰負責更新 Docker 都答不出來，我不建議自架。
🧠 進階技巧：讓 RAG 機器人回答更精準的三個秘訣
1. 切塊大小（Chunk Size）影響生死
把 PDF 切太大（例如整頁為一塊），AI 找到的段落會太雜；切太小（每句一塊），又會失去上下文。建議起步設定：每塊 500–800 個字元，重疊 100 字元，再根據實際測試微調。
2. 文件格式決定回答品質
掃描版的 PDF（影像檔）AI 完全讀不到，必須先用 OCR 工具轉成文字。排版混亂的 Word 檔效果也差——最好統一轉成乾淨的 Markdown 格式再上傳。
3. 測試要用「刁鑽問題」
不要只測「特休有幾天」這種簡單題。要測：「如果我到職滿半年但中間請了兩個月留停，特休怎麼算？」——這種跨規則的問題最容易暴露 RAG 的弱點。
✅ 怎麼判斷你做對了：四個驗收訊號
- 引用率：多少比例的回答真的附上了出處文件名稱。沒附出處，等同沒有經過檢索。
- 拒答率：該說「資料庫中無此規定」時它有沒有說。拒答率太低比太高更危險——什麼都敢答的知識庫，比常說不知道的傷害大得多。
- 抽查正確率：拿上線前那份題庫每月重跑一次，看分數有沒有掉。
- 員工有沒有繞過它：如果大家還是直接去問人資，代表它答得不夠好或不夠快，不是同事不配合。
坦白說，RAG 現階段做不好的事
- 跨文件推理與計算：要同時翻三份文件、再做一次加減乘除的問題，答錯機率很高。
- 表格與掃描檔：複雜的合併儲存格、影像式 PDF 仍是主要失分來源。
- 「哪一版才是最新的」：模型沒有時間概念，判斷不了版本先後，只能靠你在文件治理端解決。
- 否定式問題：「哪些情況不能請家庭照顧假」這類問句，檢索召回率明顯比正面問句差。
想學習如何用零代碼工具串接自動化流程？或者回到 AI 架構師技能樹總覽看更多進階應用。
❓ 常見問題 FAQ
RAG 和 Fine-tuning（微調）有什麼不同？該選哪個？
RAG 是「讓 AI 查資料再回答」，Fine-tuning 是「把知識灌進 AI 的腦袋裡」。對企業來說，RAG 幾乎永遠是首選——因為文件會更新，RAG 只要換掉知識庫就好；Fine-tuning 每次改資料都要重新訓練，成本高且速度慢。除非你需要改變 AI 的「語氣風格」（例如讓它永遠用台語回答），才需要考慮微調。
上傳的文件會被拿去訓練模型嗎？
要看你走哪條路。員工直接把文件貼到公開的網頁版聊天介面，資料怎麼被使用取決於該服務的個人版條款，企業幾乎無法控管；透過商用 API 串接時，主流供應商的企業條款一般會另外規範。但這是合約問題，不是技術問題——簽約前請自己打開該平台當期的資料使用政策頁面確認，不要相信任何部落格的轉述（包括這一篇）。這也正是企業該走 RAG 架構、而不是放任員工自行操作的核心原因。
知識庫可以放多少文件？
自架版基本上取決於你的伺服器與向量資料庫容量；雲端版則各家都有文件數與容量上限，而且會隨方案調整，請直接看官方當期的方案頁面，不要用文章裡寫死的數字編預算。比較值得注意的是另一件事：文件放越多，檢索精準度不見得越好。 與其把所有東西倒進同一個庫，不如依主題與權限切成幾個小庫。
機器人答錯怎麼辦？會不會誤導員工？
這是導入前最重要的設計：在 System Prompt 中加入「如果知識庫找不到答案，請回覆：抱歉，我無法確認這個問題，建議您聯繫人事部門」。同時開啟引用來源功能，讓每個回答都附上出處文件名稱，方便員工自行驗證。另外建議在介面上明講「本回覆僅供參考，以人事公告為準」——這不是免責話術，是讓員工知道該在什麼時候多問一句。
要不要自架？中小企業怎麼判斷？
判斷標準只有一個：公司有沒有人能長期負責維運。 有 IT 人力、又處理高敏感資料，自架合理；沒有專責人力的話，自架換來的資料主權，會被「沒人更新、沒人備份、出事沒人修」吃光。先用雲端版跑三個月驗證真的有人在用，再談要不要搬回來，順序不要顛倒。
建好之後多久要維護一次？
實務上建議兩個節奏：規章或產品資料一有異動就立刻更新知識庫（這要寫進負責人的例行工作，不能靠想到才做），另外每季用驗收題庫重跑一次回歸測試。知識庫的品質是會隨時間衰退的——不是模型變差，是公司的文件變了而庫裡沒跟上。