Gartner 在 2024 年就示警，到 2025 年底，至少三成的生成式 AI 專案會在完成概念驗證後直接被砍掉，原因不外乎資料品質太差、風險控管沒到位、成本一路墊高，或是根本說不出具體效益。等到更完整的調查出爐，數字甚至更不樂觀，麻省理工學院（MIT）一份研究整理了三百多個公開部署案例後發現，大約九成五的企業生成式 AI 試行案，連可以衡量的營收或損益改善都端不出來。
RAG（檢索增強生成）常被當成生成式 AI 落地的解方，理由很直覺，讓模型回答之前先去查公司自己的文件，答案應該會更準、更貼近實際業務。但攤開這幾份研究就會發現，RAG 企業導入失敗的模式，跟其他生成式 AI 專案高度重疊，而且原因幾乎都不在模型本身。
如果你已經在評估或正在試跑 RAG，這篇不會再重複「RAG 是什麼」，而是把 MIT、Gartner，以及史丹佛大學三份各自獨立、方法也不同的研究攤開來對照，看它們合起來指向哪幾個真正的卡關點。先從這三份數據到底怎麼來的講起，再一項項拆開它們發現了什麼。
MIT、Gartner、史丹佛，這三份研究各自在查什麼？
三份研究的樣本與做法都不一樣，合起來看才有意思。MIT 那份研究由該校媒體實驗室的 Project NANDA 在 2025 年 7 月發表，底層資料來自 300 多個已經公開的 AI 部署案例、52 場訪談，以及 153 份問卷調查，調查範圍是整體生成式 AI 專案，不只鎖定 RAG。不過值得注意的是，企業想讓生成式 AI 的回答貼近自家業務，絕大多數做法都是接上一套檢索機制，讓模型先查公司的文件庫再回答，這正是 RAG 的核心設計，所以這份研究的發現，對 RAG 專案同樣成立。
Gartner 則是長期追蹤企業導入生成式 AI 現況的市場研究機構，他們在 2024 年提出的預測是，到 2025 年底，至少三成的生成式 AI 專案會在概念驗證後被直接放棄，原因鎖定在資料品質、風險控管、成本，以及效益不明這四項。
史丹佛大學法學院的 RegLab 研究團隊做法完全不同，他們挑了 202 個真實法律查詢題目，拿去測試市面上主打檢索增強架構的商用法律 AI 工具，再由法律專家一題一題人工評分正確與否。這是三份研究裡唯一直接針對 RAG 架構做受控測試的一份，結果特別值得放進來對照。
三份研究角度不同，但攤開來看，最先浮出來的關卡都落在同一個環節上，那就是資料整理得夠不夠。
敗因排第一的是資料，不是模型
Gartner 那份預測裡，擺在第一位的敗因是資料品質，不是模型能力，這個順序本身就值得多想一層。企業手上的文件天生就不是設計來給 AI 讀的，合約、財報、技術手冊常常是多欄排版的 PDF，重要數字藏在表格與圖說裡；同一份規章可能還躺著兩三個版本，散在雲端硬碟、內部 wiki、信箱附件各處，沒有一個統一入口。
只要餵進去的文件零散、過期、格式跑掉，拆出來的每一小塊就注定殘缺，這也是為什麼 RAG 對資料品質特別敏感。RAG 的整套邏輯是先把文件拆成小塊、轉成向量，再靠語意相似度去檢索，前面切壞了，後面沒有一關能補救。企業容易誤判的地方在於，他們看到自己文件庫裡「資料很多」，就以為資料已經準備好了，卻沒發現「資料多」跟「資料能被準確檢索」其實是兩回事。
換一顆更貴的模型救不了這個問題，檢索層撈回來的內容如果本來就是錯的或過期的，模型只會用更流暢的語氣，把答錯的內容講得更有把握。這也是為什麼 Gartner 會把資料品質列在敗因第一位，也是為什麼砸更多預算在模型上，常常換不到對應的效果。
資料只是第一關，MIT 那份研究還多挖出一層，同樣的資料問題，擺在不同的組織方式底下，結果可以差到一倍。
自己關起門硬幹，成功率只有找外部夥伴的一半
MIT 那份研究另一個發現同樣值得放大看，企業選擇跟外部廠商合作或直接採購現成工具，專案成功率大約六成七；完全靠內部團隊從零打造，成功率只有約三成三，兩者相差將近一倍。
差距不在「自己做」這件事本身有問題，而在於 RAG 真正要落地，高度仰賴領域專家與實作團隊之間反覆磨合。懂法規的人要跟懂檢索架構的人坐在一起，才調得出「這句話該不該信」的判斷標準；內部小組如果沒有專責資源、還要邊做邊摸索，自然比不上長期在這個領域反覆試錯過的外部團隊。
這個發現對正要導入的企業來說是很直接的提醒，與其把 RAG 當成一次性的內部專案硬啃，不如及早找有實作經驗的技術夥伴一起打磨。這裡的重點不是要不要花錢外包，而是有沒有讓真正懂業務內容的人，參與到檢索邏輯怎麼設計這件事裡。
不過，就算找對了人、資料也整理好了，還有一關常被忽略，那就是檢索結果看起來很有依據，不代表它真的正確。
檢索附上引用，不代表答案就是對的
史丹佛大學 RegLab 團隊那份測試特別值得細看，因為它是三份研究裡唯一直接把「附上引用來源的 RAG 工具」拿去跟人工評分核對答案的一份。他們挑了兩款主打檢索增強架構的商用法律 AI 工具，測試結果是答案裡摻雜錯誤或編造內容的比例，分別落在一成七與三成三之間；同一批題目換成沒有接上檢索機制、直接問一般大型語言模型，錯誤比例反而衝到四成三。
這組數字合起來想講的是同一件事，接上檢索、附上引用來源，確實能大幅壓低出錯機率，但沒辦法把出錯機率壓到零。危險的地方也在這裡，當一個回答附上了引用、標注了出處，使用者會因為「它有附來源」而更放心，但引用的段落如果本身就過期，或是被挑錯了脈絡，這份信任反而會變成錯誤的放大器。在法規遵循、財務審查、醫療問答這類零容錯場景裡，一次「看起來有憑有據」的答錯，足以讓第一線人員從此不再相信整套系統。
會出現這種狀況，某種程度上也是因為多數企業根本沒有機制，能在它變成使用者客訴之前先攔下來。
多數企業手上，沒有盯住檢索品質的儀表板
Gartner 提到的四個放棄原因裡，「風險控管沒到位」常常具體指向同一件事，企業根本沒有系統化的方法，去衡量自己的 RAG 系統檢索到的內容夠不夠準。多數團隊會做的頂多是找人幫「最終答案好不好」打分數，卻沒有任何機制在盯著檢索這一層本身有沒有在退步。
少了這層把關會發生什麼事？撈到過期資料、切片切得七零八落、表格數字被漏抓，這些問題全部偵測不到，團隊只會一直等到使用者回報答案有問題，才發現系統早就在悄悄出錯，而那通常已經太遲。
業界目前比較成熟的做法，是針對檢索層本身盯兩個指標：一個是撈回來的內容夠不夠完整，有沒有涵蓋回答問題需要的事實；另一個是撈回來的內容夠不夠乾淨，裡面混了多少跟問題無關的雜訊。具體做法是先準備一組已知標準答案的測試題，每次調整了切片方式、換了檢索模型，就重新跑一次，確認這兩個指標有沒有退步，而不是只看模型講得順不順。這套流程不難懂，難的是願不願意把它綁進每一次調整的日常裡。
這些數字，對正要導入 RAG 的你代表什麼？
把這幾個發現串起來看，對正要導入 RAG 的企業，大概有四件事可以先做。
- 先從風險低、頻率高的場景切入：例如客服常見問題、內部 IT 支援、人資政策問答，這類場景就算偶爾答錯，後果也還可控，能讓團隊在真正碰到法規遵循、財務審查這種零容錯場景之前，先把檢索邏輯磨順。
- 把資料整理排在最前面，而不是最後才補：文件版本要不要統一、過期內容有沒有先下架，這些工作看起來瑣碎，卻決定了後面所有環節的天花板在哪裡。
- 別把 RAG 當成一個人或一個小組能關起門完成的任務：及早找懂業務內容、也懂檢索架構的夥伴一起磨，MIT 的數字已經說得很清楚，這一步能不能做到，直接影響專案成不成。
- 從上線第一天就建起檢索品質的量測機制：別等使用者抱怨才回頭查，RAG 不是裝好就能放著不管的功能，它是一個會隨著文件變動、需要持續被檢查的系統。
下一次評估 RAG 的提案擺上桌，先別急著比較模型參數，反倒該先問清楚，資料整理有沒有排進時程、有沒有懂業務的人參與檢索邏輯設計、上線後打算怎麼持續檢查它有沒有跑偏。造成 RAG 企業導入失敗的，往往不是技術本身撐不住，而是這幾個環節，從一開始就沒人真的去顧。