企業 RAG 為什麼常答錯？換模型也救不了的三件事
企業 AI 落地研究所｜Casper／Max｜2026-10-08 建稿，預定 2026-10-11（週日）08:00–09:00（台北）錄製。
錄製資訊（不口播）
依據 訪綱 與 選題卡與來源紀錄，對應 backlog T-012。來源查閱日 2026-10-08。
主線：開場先丟兩個答錯情境當 hook，接著講三種錯（找不到、找到舊的、找到不該看的），再講怎麼量、權限、版本，最後接回 Casper 的地端六原則、ASR 與 Token／ROI，結尾給帶走動作與訂閱 CTA。稿面口白約 5,500 字，以每分鐘約 220～260 字照念約 22～25 分；加上停頓、即興與【待 Max 補】段落，主段落暫估 30～36 分，未試念。要壓到 30～34 分：第 5 段整段略過（第 4 段末已帶到撤權），第 6 段略過「中小企業／買現成」兩輪、第 7 段只留第一輪問答。
hook 的兩個情境是假設情境，不是某家公司真實事件。報帳規則例子取自數位時代文章（叡揚合作企劃），不是 Max 的經驗。以下標 【待 Max 補】 的地方，錄前由 Max 提供或改寫；沒有提供就照現稿的保守說法講，不替 Max 編造數字或客戶案例。Casper 實驗室設備是否口播，由 Casper 決定。
0｜Hook：兩個答錯的情境
Casper： 同一個問題，業務問公司的 AI，拿到的是去年的報價；換一個人問，看到了他根本不該看的檔案。這兩個錯，換一個更強的模型都救不了。
歡迎來到企業 AI 落地研究所。今天我們要聊企業 RAG，也就是公司內部的 AI 知識庫，為什麼常常答錯。很開心一樣邀請到 Max。Max，你最常聽到企業抱怨 AI 知識庫哪裡不好用？
Max： 最常聽到的就是「它亂講」。可是拆開來看，大部分不是模型在亂講，是它拿到的資料就不對。我會分成三種：該找的文件沒找到、找到的是舊版本、找到了你不該看的東西。
Casper： 那大家第一個反應，通常是換一個更強的模型？
Max： 對，因為換模型最簡單，改一個設定就好。可是剛剛那三種錯，模型根本看不到正確的文件，它再聰明也只能根據錯的資料回答。所以說，今天想跟大家聊的是：先把檢索量清楚，再來決定要不要換模型、要不要買設備。
【待 Max 補】若有 COMMEET／Ankey 可公開的一句實例，放在這裡；沒有就略過。
1｜RAG 是什麼？為什麼不全部丟給模型
Casper： 先幫第一次聽到的觀眾解釋一下，RAG 是什麼？
Max： RAG 的英文是 Retrieval-Augmented Generation，中文叫檢索增強生成。白話講就是兩步：先從公司的資料裡找出跟問題相關的幾段，再把這幾段交給模型，請它根據這些內容回答。
例如說開書考試。書很厚，你要先翻到對的那一頁，才寫得出對的答案。RAG 前面那個「翻書」的動作，就是檢索。
Casper： 那為什麼不乾脆把公司所有文件都丟給模型？現在模型不是可以讀很長嗎？
Max： 有三個現實問題。一個是長度，公司文件動輒幾十萬份，不可能每次全部塞進去；尤其自己架在公司裡的模型，能讀的長度通常比雲端小。再來是錢，塞進去的每一個字都要算 Token。最後是權限，全部丟進去，就沒辦法分「這個人能看、那個人不能看」。
Casper： 那我們平常在 NotebookLM 上傳幾份文件問問題，也算 RAG 嗎？
Max： 概念很接近。數位時代有一篇文章，作者把財務部的報帳規則丟進 NotebookLM，結果還是答錯。原因是規則用顏色標重點，那套標色只有財務部的人看得懂。所以說，文件是寫給人看的，不一定寫給 AI 看。整理文件，本身就是 RAG 工作的一部分。
Casper： 你剛剛說「找出相關的幾段」。這個「段」是怎麼來的？
Max： 系統會先把文件切成一小塊一小塊，英文叫 chunk，再替每一塊建索引。切法很重要。例如說一份報帳規則，裡面有一張表，上面寫「交通費」，下面寫上限金額。如果切的時候剛好把表頭跟數字切開，找到的那一塊就只有數字，沒有說是哪一項，模型就只能猜。
Casper： 所以文件怎麼切，也會影響答得對不對就對了？
Max： 對，而且這一步通常在你看不到的地方。驗收的時候，要請廠商讓你看到「它到底找了哪幾塊」，不要只看最後的答案。
來源：數位時代 2026-09-29（叡揚合作企劃）作者自述；口播說「文章作者提到」，不說成 Max 或 COMMEET 經驗。
2｜天花板在檢索：三份測試怎麼說
Casper： 你一直說天花板不在模型，在檢索。這有數據嗎？還是工程師的直覺？
Max： 有幾份今年的測試都指向同一件事。第一份叫 EnterpriseRAG-Bench，是做 RAG 產品的 Onyx 做的。他們模擬一家公司，大約五十一萬份文件，有 Slack、Email、Jira、Confluence，還有會議逐字稿。而且刻意放了放錯地方的、幾乎重複的、互相矛盾的資料，就像真的公司。
Casper： 結果呢？
Max： 很有意思。最傳統的關鍵字檢索，答對率大約七成；大家很熟的向量檢索，大約只有五成。而且文件越多，越難找到該找的那份。要提醒一下，Onyx 自己也賣 RAG 產品，資料也是模擬的。
Casper： 所以向量資料庫不是萬靈丹就對了？
Max： 對，它擅長「意思相近」，但企業很多問題是料號、合約編號、人名，這種反而關鍵字找得比較準。很多團隊會兩種一起用，再加一層重新排序，英文叫 reranker。
第二份是 Kapa 十月初公布的，一千題真實企業問題。最好的做法也只到 0.65。但光是加一個 reranker，就從 0.41 拉到 0.50。這比換模型便宜很多。同樣，Kapa 也是賣檢索產品的，資料跟評分都是他們自己的。
Casper： 那如果不要檢索，讓 AI 自己像工程師一樣，下指令去翻資料夾呢？
Max： 這兩份測試都有試。EnterpriseRAG-Bench 裡，讓 AI 自己下指令去找的做法，答對率大約六成，比關鍵字還低一點，而且最長一題要花十分鐘。Kapa 那邊，用最強的模型只靠 grep 硬找，可以做到 0.61，但慢了大約五倍，每一題還要讀很多內容。所以說，讓 AI 自己翻不是不行，但慢、貴，而且不一定比較準。
Casper： 那第三份呢？
Max： 第三份是一篇預印本，測了九個模型。只要情境是索引過期、權限被擋，或者拿到別人對話的資料，九個模型的成功率全部是零。這就是今天開場講的：資料錯了，換哪一個模型都一樣。
Casper： 可是模型越來越強，這問題會不會自己消失？
Max： 模型會變強，但它不會知道「沒被找出來的那份文件」寫了什麼，也不會知道這份規定上個月已經作廢。這些是資料跟檢索的事，不是模型的事。
來源：EnterpriseRAG-Bench（arXiv 2605.05253，Onyx，模擬資料）；Kapa Company Knowledge Bench（2026-10-02，廠商自測）；LayerRAG-Bench（arXiv 2607.27353，單一作者預印本、合成情境）。不念排行榜分數。
3｜怎麼量：找到了沒、引用對不對、會不會說不知道
Casper： 好，如果我是 IT 主管，明天要驗收一套 AI 知識庫，我要量什麼？
Max： 先準備題目。題目要來自員工真的問過的問題，例如說客服常被問的、業務常找的、新人最常問 HR 的。每一題先標好：正確答案在哪一份文件、哪一個版本。
Casper： 請廠商幫忙出題可以嗎？
Max： 可以參考，但不要只用廠商的題目。廠商出的題目，很容易剛好都答得出來。
有了題目，再來是量三件事。第一個是命中率，該找的那份文件有沒有被找出來。再來是引用對不對，它附上的出處，真的支持它的答案嗎？最後是會不會說不知道，資料裡沒有答案的時候，它是老實說找不到，還是自己編一個。
Casper： 要多少題才夠？
Max： 我會建議先從一個部門、大約五十題開始。【待 Max 定題數】這不是研究上的門檻，是一個做得完的起點。重點是題目固定下來，之後換模型、換切法、加 reranker，都拿同一批題目重跑，才知道到底有沒有變好。
Casper： 所以先有一份考卷，再來談換誰去考就對了？
Max： 對，沒有考卷，所有的「變好了」都只是感覺。
Casper： 那「答對」誰來判斷？五十題每一題都要人看嗎？
Max： 一開始建議要人看，最好是那個部門真的懂業務的人。之後可以讓另一個模型先幫忙評分，但還是要抽一部分給人複查，因為評分的模型也會看錯。再來是多久重跑一次，我會建議每次換模型、換切法、或者文件大改版的時候，都重跑一次，把結果記下來。
Casper： 聽起來像在幫 AI 建一個品管流程。
Max： 對，就是品管。工廠出貨前會抽檢，AI 回答也一樣。
來源：iT 邦幫忙 Day 22 社群文的 PoC 指標表；EnterpriseRAG-Bench 有「資料裡沒有答案」題型。
4｜權限：AI 用誰的身分去找資料
Casper： 開場講到「看到不該看的檔案」。這種事真的會發生嗎？
Max： 有一個真實報導。VentureBeat 九月初寫過一個案子：義大利一家微軟合作夥伴，自己用 Azure OpenAI 做了一個郵件助理，所有評測都過了。後來他們用一個低權限的帳號去問同樣的問題，結果 AI 把那個帳號在 SharePoint 根本打不開的內容拿出來了。
Casper： 為什麼會這樣？
Max： 因為他們的流程，是用「建索引的那個帳號」去找資料。那個帳號權限很大，什麼都看得到。後來的修法，是在查詢的當下，用提問者本人的權限先過濾，再把結果交給模型。要說清楚，這不是 Azure 本身的漏洞，是自建流程繞過了原本的權限機制。
Casper： 那在 prompt 裡寫一句「不要給沒權限的人看」不就好了？
Max： 不行。那等於先把機密文件給模型看，再拜託它保密。OWASP 有一份 RAG 安全清單，原則講得很清楚：權限要跟著每一段資料走，在檢索的當下檢查，查不到權限就回空的。
Casper： 那員工離職或調部門，AI 什麼時候才知道？
Max： 這就是另一個坑。很多系統是定期把權限同步過來，例如說一天同步一次，那撤權到同步之間就有空窗。AWS 這週的文章也在談這件事，他們的做法改成查詢的當下回原系統核對。
Casper： 那如果我們用的是開源的，例如 Open WebUI 呢？
Max： Open WebUI 的知識庫，是用群組來分享讀寫權限。選工具的時候要問清楚：權限的單位是「整個知識庫」，還是「每一份文件」？如果是整個知識庫，就要照部門拆開來建。RAGFlow 最新的 1.0 預覽版，也自己寫了團隊權限還沒支援。【待 Max 確認：Open WebUI 能不能自動繼承原系統的逐檔權限】
所以說，最簡單的測試是：同一批題目，用高權限跟低權限兩個帳號各跑一次。結果不一樣才是對的。
Casper： 我舉一個情境，你幫我看看。假設公司把人事規章、獎金辦法都放進同一個知識庫，一般員工問「今年年終怎麼算」，會發生什麼事？
Max： 如果權限沒有做到每一份文件，它很可能把主管才看得到的獎金試算表也找出來，然後很熱心地幫你整理。模型沒有做錯事，它只是用了它拿得到的資料。所以說，要擋，要在「拿得到」這一關就擋掉，不是在回答那一關。
來源：VentureBeat 約 2026-09-01；OWASP RAG Security Cheat Sheet；AWS 2026-10-07；Open WebUI RBAC 文件；RAGFlow v1.0.0-rc1（2026-09-29）release notes。不念 Cioffi 案「約六成郵件」。
5｜新舊版本：AI 拿到過期的 SOP（可略）
Casper： hook 裡另一個錯，是拿到去年的報價。檔案更新了，AI 不是會自己知道嗎？
Max： 不一定。最常見的狀況是新版、舊版同時被找出來，模型就挑了一份比較像的。再來是刪除，來源的檔案刪掉了，可是切好的段落、向量、快取還留著，就還查得到。
Casper： 那要怎麼防？
Max： 文件要有生效日跟作廢狀態，檢索的時候優先現行版本；新舊有衝突，就把衝突標出來給人看。來源刪除，要連動把索引裡的東西一起刪。所以說，這其實是文件管理的老問題，只是 AI 讓它更明顯。
來源：EnterpriseRAG-Bench 矛盾資料題型；LayerRAG 索引過期情境；Open WebUI v0.11.4 metadata 帶入引用來源。
6｜地端設備：Casper 六原則對到 RAG
Casper： 接下來談設備。我上週在群組整理了地端 LLM 部署的六個原則：記憶體容量、記憶體頻寬、算力、軟體堆疊、模型架構，還有服務併發。容量決定裝不裝得下，頻寬決定每秒吐幾個字，算力管長輸入跟批次處理，軟體看是 CUDA 還是 Metal、用 vLLM 還是其他引擎，架構看是 Dense 還是 MoE，併發看多少人同時用還撐得住。Max，這跟你的地端架構對得上嗎？
Max： 對得上。【待 Max 補：自己的地端架構，例如模型、推論引擎、介面、索引、ASR 怎麼搭】
如果是做 RAG，我會特別看兩個。RAG 每一題都會把檢索到的內容塞進去，輸入很長，所以處理長輸入的那一段，英文叫 prefill，會先吃緊。再來是很多人同時問的時候，每個人的上下文都要佔記憶體，也就是 KV Cache，這是你講的併發。【待 Max 確認此推論】
Casper： 所以 RAG 跟一般聊天比，壓力在不同地方？
Max： 可以這樣理解。還有一個常被忘記的：RAG 不只一個大模型，還有把文字轉成向量的 embedding 模型、還有 reranker，也都要算資源。整套大概是：介面，例如 Open WebUI；推論引擎，例如 Ollama 或 vLLM；索引；embedding 跟 reranker；如果要收會議錄音，再加語音辨識。
Casper： 那 MoE 呢？我在群組裡講，總參數決定裝不裝得下，啟用參數決定每個 token 算多少。
Max： 對企業選型來說，MoE 的好處是同樣的記憶體，可以跑出比較快的回應；但你還是要有足夠的記憶體把整個模型放進去。所以說，先用剛剛那份考卷確認檢索值得跑，再用你這六個原則挑設備，順序不要反過來。
Casper： 那中小企業呢？一台 Mac Studio 或 DGX Spark，夠不夠撐一個部門的知識庫？
Max： 這個我不想直接給一個數字，因為要看幾個人同時用、用多大的模型、每題塞多少內容。我的建議是拿剛剛那份考卷，模擬部門裡最忙的時段，讓好幾個人同時問，看回應時間能不能接受。量到了，再談要不要加設備。
Casper： 如果不想自己架，買現成的雲端服務呢？
Max： 也是一個選項。例如說 Cloudflare 十月初把 AI Search 正式上線，公開的價格是每一千次語意查詢 0.75 美元，十一月才開始計費。這可以當成「買現成」的參考價。但不管自己架還是買，那份考卷跟權限測試都一樣要做。
錄製備註：Casper 實驗室設備（RTX 5090、Mac Studio、DGX Spark、採購中 PRO 6000）由 Casper 決定是否口播。不報價、不講回本年限、不念 tokens/s；地端不以省錢立論（T-001）。
7｜ASR：會議錄音也是資料來源
Casper： 你在群組裡把 ASR 也放進這次的主題。語音辨識跟 RAG 有什麼關係？
Max： 很多公司的決策只存在會議裡，沒有寫成文件。錄音要先轉成文字，才進得了知識庫，這一步就是 ASR。剛剛那份 EnterpriseRAG-Bench，也把會議逐字稿列為企業資料的一種，而且是平均最長的。
問題是，轉錯一個產品代號、一個客戶名字，後面檢索就找不到。台灣開會又常常國台英夾雜。
Casper： 台灣有在地的選擇嗎？
Max： 聯發科研究跟陽明交大有開源 Breeze ASR 系列，25 是台灣華語，26 是台語轉華語字幕。可以拿來試，但一定要用自己公司的錄音測過。再來是權限，會議逐字稿誰能查，應該跟「誰參加了這場會」走。
Casper： 錄音這件事，是不是還要先跟大家講好？
Max： 對，要先告知、取得同意，這是另一個題目，今天先不展開。但至少要記得，錄音進了知識庫，就等於多了一個可以被查的資料來源。
來源：EnterpriseRAG-Bench 資料組成；Breeze-ASR-26 model card（台語、合成訓練資料）。不念 CER 數字，不說商用等級。錄音告知與同意帶一句即可。
8｜Token 與 ROI：現在到底能省多少
Casper： 最近大家很愛講 Token。RAG 的帳單到底花在哪裡？
Max： 很多人以為是使用者那一句問題，其實大頭常常是檢索塞進去的內容。Kapa 那份測試裡，只靠 grep 硬找的做法，每題大約回傳四萬個 tokens；精簡的檢索大約五千個。差了八倍。一樣，這是 Kapa 自己的數字。
Casper： 那地端不就不用付 Token 了？
Max： 不用付 API 的 Token，但有設備、電費、維運的人力。我們頻道一直的立場是：地端不要用省錢當理由，要用資料不能送出去、用量很穩定這種理由來談。
Casper： 那老闆問 ROI，要怎麼算才不會被打槍？
Max： 有一句話我很喜歡：單價最便宜，不等於每個任務最便宜。重試、塞太多內容、最後還要人去收拾，都要算進去。所以我會把分母換成「答對、而且附上正確出處的題數」，再去跟員工自己找資料要花的時間比。不要一開始就喊省下幾個人。
Casper： 那回到 Muse 那份清單的問題：現在到底能省多少？
Max： 老實說，沒有一個通用的數字，每家公司的文件跟問題都不一樣。我能說的是有幾個地方可以控制。檢索找得準，就不用塞那麼多內容進去；再來是常問的問題可以快取；還有簡單的問題交給小一點的模型。這些都要回到考卷去量，省了錢但答錯變多，就不是真的省。
【待 Max 補】COMMEET／Ankey 若有可公開的 before／after，放在這裡；沒有就不舉數字。
來源：Kapa 2026-10-02；round3 引 CloudZero；T-001、T-002、T-004。
9｜收尾與 CTA
Casper： 今天跟 Max 聊了企業 RAG。整理一下：AI 知識庫答錯，多半是三種錯——找不到、找到舊的、找到不該看的，換更強的模型救不了。所以要先有一份考卷，量命中率、引用正確率、會不會說不知道；權限在檢索的當下用提問者的身分過濾；新舊版本要有生效日跟作廢。地端設備可以用六個原則來挑，但先確認檢索值得跑。
Max，如果觀眾聽完只能做一件事，你建議做什麼？
Max： 這個禮拜挑一個部門，收集大概五十個員工真的問過的問題，標好答案在哪一份文件。然後用高權限、低權限兩個帳號各跑一次。量完，再決定要換模型、加 reranker、整理文件，還是買設備。
Casper： 謝謝 Max 今天的分享。如果你是企業主、主管或 IT 負責人，歡迎訂閱我們企業 AI 落地研究所，也歡迎在留言區告訴我們，你公司的 AI 最常答錯哪一類問題，我們挑幾題下一集來拆解。我們就下一集再見。
錄製備註：「挑幾題下一集來拆解」需 Casper 確認願意承諾，否則改為「我們會整理大家的留言」。