一個內部 HR 問答機器人，把早就下架的舊版育嬰假規定，回給了一位正在查自己權益的員工。新規定其實在內網掛了好幾個月，但機器人從來沒有重新索引過那份文件。更麻煩的是，沒人發現它答錯了——後台儀表板只看「系統有沒有回應」「回應快不快」，沒有任何一個指標在盯「答案的來源是不是最新的」。連結正常、模型有回、語氣也很篤定，只有那個數字是錯的。
這正是 RAG 企業導入失敗最典型的樣子。它很少是轟轟烈烈地壞掉，而是在 Demo 階段一切完美、一進真實環境就開始小規模、不易察覺地出錯。市場上的數據其實相當一致——大約有七到八成的企業 RAG 專案，根本走不到正式上線那一步；麻省理工學院 2025 年的一份報告更直接指出，約 95% 的企業生成式 AI 試行案，最終沒能帶來可衡量的營收或損益影響。問題是，這些失敗的原因其實高度重複——而且幾乎都不在模型本身。
如果你已經在評估、或正在試跑 RAG，這篇要做的不是再講一次「RAG 是什麼」，而是把這些專案卡關、夭折的真正原因攤開來看——每一個失敗模式長什麼樣、背後有哪些可佐證的數字、以及該怎麼拆解。先從一個最反直覺的事實講起——絕大多數的失敗，根本不是模型不夠聰明。
為什麼 RAG 在 Demo 完美，一上線就出錯？
答案其實出乎很多人意料——問題幾乎都不在大型語言模型，而在它前面那條沒人想顧的資料管線。有一個被反覆引用的觀察是，約八成的 RAG 失敗可以追溯到資料的擷取與切片環節，而不是模型本身。很多團隊花了好幾週在調 prompt、換模型，檢索層卻每三次查詢就悄悄撈錯一次脈絡——他們調的根本不是出問題的地方。
Demo 之所以漂亮，是因為它跑在一個被精心挑過的小資料集上：十份格式乾淨的文件、幾個事先想好的問題、一個剛建好還沒過期的向量庫。這種環境下，RAG 看起來無所不能。
真實環境則完全是另一回事。文件數量從幾十份跳到幾十萬、甚至上百萬份；格式從乾淨的 Word 檔，變成多欄排版的 PDF、塞滿圖表的技術手冊、上千列的試算表；文件還會不斷被改版、被刪除、被重新發佈。Demo 隱藏的所有問題，到了這個規模全部一次浮上來。
也因為這樣，把失敗歸咎於「模型不夠強」往往是最大的誤判。你換一個更貴的模型，檢索層撈回來的還是錯的脈絡，模型只會用更流暢的語氣，把錯誤答案講得更有說服力。接下來這五個原因，就是這條管線最常斷掉的五個地方。
原因一，資料沒準備好，再強的模型也救不回來
第一個、也是最被低估的失敗原因，是企業以為自己「有很多資料」，卻沒發現那些資料根本還沒準備好被檢索。業界對這點的共識很一致——RAG 專案的失敗，多數源自「資料沒準備好」，而非技術不到位。「進去的是垃圾、出來的就是垃圾」這句老話，在 RAG 上幾乎是字面成立。
問題出在企業資料天生的三個特性。第一，它是非結構化的——乾淨的單欄文字檔，跟 OCR 容易在版面邊界出錯的多欄 PDF、滿是示意圖與表格的手冊，全混在一起。如果你的管線只吃得下「漂亮的純文字」，那些真正關鍵的知識（往往藏在表格、圖說、附註裡）就會整批被漏掉。第二，它是分散的，文件散在雲端硬碟、聊天工具、信箱、wiki、CRM、程式碼倉庫裡，沒有一個統一入口。第三，它很髒，同一份 SOP 有三個版本、命名規則各自為政、段落結構殘缺。
對策不是先去比較哪個 embedding 模型最強，而是先回頭整理資料。一個務實的做法，是在導入前花兩到四週做資料盤點：刪掉過期版本、統一命名規則、補齊段落結構，並把真正要進知識庫的核心文件圈出來。這一步聽起來不性感，卻是整個專案品質的天花板——後面所有環節再精巧，都補不回一開始就餵錯的資料。
原因二，切片切壞了，檢索就一路錯下去
第二個原因藏在一個很技術、卻決定成敗的動作裡——切片（chunking）。把長文件切成小塊再向量化，這一步切得好不好，直接決定檢索層撈得準不準。前面提到「約八成失敗追溯到擷取與切片」，這裡就是重災區。
舉一個很具體的場景。一份 30 頁的合約被切成 60 個小塊，檢索系統找到了第 47 塊，裡面寫著「承租方應就……向出租方負賠償責任」。看起來像一條完整條款，但對律師來說它是個殘缺片段——「承租方」的定義在第 2 頁、賠償範圍還被第 21 頁的某個條款限縮。模型只拿到中間那一塊，自然會給出一個看似完整、實則漏掉前提的答案。
另一個常見災情是表格。PDF 解析器經常把一張表壓平成一排管線符號，任何 embedding 模型都讀不出它的意義。於是答案明明在第 14 頁的某個儲存格裡，模型卻只能從旁邊那段「大致相關」的文字硬湊一個回覆。
對策有兩層。其一是結構感知的解析：用能辨識標題、段落、表格、圖片的解析器，把表格以保留欄列關係的形式（例如 HTML）餵進去，模型才有機會對到「第三級的逾期罰款是多少」這種落在儲存格裡的答案。其二是父子層級切片：用小塊去「找」、用大塊去「理解」——比對時命中一條小條款，回傳時帶回它所屬的整個段落。處理合約這類充滿交叉引用的文件，幾乎一定得走這條路，否則就會落得跟客戶解釋「為什麼機器人漏掉一條關鍵條款」。
原因三，資料一過期，引用反而放大了錯誤
第三個失敗模式，是最隱形、也最危險的一種——資料新鮮度的落差。開頭那個育嬰假機器人就是典型——文件被重新發佈了，向量庫裡卻還留著舊版的切片。
它的機制值得拆開看。檢索系統是用「語意相似度」在排名，而不是用「索引時間」。所以當新舊兩個版本同時存在，舊版那塊的用詞如果剛好更貼近使用者的問法，它反而會贏過新版被排到最前面。一個不看時間的重排器，會永遠忠實地回傳那塊 18 個月前的舊內容。
危險的地方在於，這種錯誤會被「引用來源」這件事放大。企業 RAG 最致命的失敗模式，從來不是答錯，而是「看起來很對的答錯」。當 AI 的回覆附上了引用、標注了日期，使用者會因為「它有附來源」而更信任它——但如果引用的是舊版資料，這份信任反而成了錯誤的擴音器。在金融合規、法規審查、醫療問答這類零容錯的場景裡，一次這樣的錯就足以讓基層單位徹底不再信任系統。
對策是讓「時間」進到排名邏輯裡。每一個切片都要帶上「最後更新時間」這個 metadata，並在最終排序前，對相關性分數疊加一個隨時間衰減的新鮮度權重——越舊的內容，分數被壓得越低。更進一步，可以加一道回覆驗證（grounding check），在模型生成初步答案後，用第二層機制逐句確認「每一句陳述，是不是都能在召回的來源裡找到依據」，把對不上的內容攔下來、重查或標記，而不是直接送到使用者面前。一個連「這塊資料上次更新是什麼時候」都答不出來的檢索系統，本來就不該拿去處理會變動的文件。
原因四，沒有評估機制，你根本不知道哪裡壞了
第四個原因，是一個結構性的盲區——多數團隊沒有任何系統化的方式，去衡量自己的檢索品質。近期一份調查讓人有點沮喪——大約 70% 在生產環境跑 RAG 的團隊，對「檢索品質」沒有任何系統化的評估。他們可能有一個對「最終答案好不好」做評分的 LLM 評審，但沒有任何東西，在盯著檢索層本身的退步。
少了這層評估會怎樣？前面講的三個失敗——撈到舊資料、切片切碎、表格漏抓——你全都偵測不到。儀表板是綠的，因為它量的根本不是壞掉的那一塊。你會一直靠「客戶抱怨」來發現品質問題，而那通常已經太遲。
真正要盯的是兩個檢索層指標。一個是召回率（context recall）：撈回來的這幾塊，到底包不包含回答問題所需要的事實。另一個是精確率（context precision）：撈回來的這幾塊裡，有多少比例是真正相關的。研究也顯示，檢索失敗本來就是最主要的錯誤來源——依設定不同，它可以佔到全部問題的一成到將近一半。換句話說，光看「答案順不順」遠遠不夠，問題的大宗其實發生在更前面的檢索階段。
對策說起來不難、做起來卻需要紀律。核心動作是建一組大約 200 題的「黃金測試集」，每次只要換了 embedding 模型、改了切片設定、換了重排器，就重跑一次，看召回率與精確率有沒有退步。工具不是難點，難的是願意把這套評估綁進每一次改動的流程裡。沒有它，你等於閉著眼睛在飛，而儀表板的綠燈只是因為它沒在量真正會壞的東西。
原因五，把它當一次性專案，而不是要長期維運的系統
第五個失敗原因，比較像是觀念上的——團隊照著教學文，串了一個 embedding、一個向量庫、一個 LLM 呼叫，就以為大功告成。但這套「單一路徑」的架構，撐不過真實需求的疊加。
看看需求是怎麼長出來的。產品端要求附上引用來源，於是你需要切片層級的 metadata；法務要求依使用者身分做文件權限控管，於是你需要在檢索前先過濾身分；維運端想知道帳單為什麼突然暴衝，於是你需要逐筆查詢的成本追蹤；有人在全員會議上問「為什麼問第三季財報，它引用的是第一季的文件」，於是你又繞回新鮮度的問題。一個真正能上線的系統，通常有七個必要環節：結構化的擷取層、帶 metadata 的切片層、混合檢索（語意＋關鍵字）、重排器、新鮮度與權限過濾、能附引用的生成層，以及一個在背景對線上流量持續評估的迴圈。這些沒有一個是可選的，而它們全都是 Demo 階段被省略、上線第三週開始付代價的部分。
這裡還有一個跟組織有關、卻決定成敗的選擇——自建還是找夥伴。麻省理工學院那份報告裡有個耐人尋味的數字——有外部夥伴協作的導入案，成功率約是 67%，而純內部自建只有約 33%，相差一倍。這不是說自建一定不行，而是說 RAG 的落地，深度仰賴領域專家與實作團隊之間的緊密協作；把它丟給一個沒有專責資源、又邊做邊摸的內部小組，失敗的機率自然高出許多。
對策是兩件事。一是選對起點：別一上來就想把全公司的知識都灌進去，先從客服 FAQ、內部 IT 支援、人資政策問答這種「高頻、低風險、好衡量」的場景開跑，這類情境有明確的 KPI（解題率、回覆時間），能快速累積信心與數據。二是把它當產品養：上線不是終點，要持續追蹤檢索命中率、答案正確率、使用者滿意度，設好儀表板、定期回看。RAG 從來不是「上線即完工」的專案。
把這五個原因連起來看，真正的訊號是什麼
把五個原因排在一起，會浮現一條共同線索——RAG 的成敗，不取決於你選了哪個模型，而取決於模型前面那條管線有沒有被認真對待。資料準備、切片策略、新鮮度治理、評估機制、整體架構——任何一環草率帶過，使用者最終看到的，就是那種「看起來很專業、但答案是錯的」危險回覆。
這也解釋了為什麼那麼多專案停在 Demo 與正式上線之間的那道牆前面。Demo 只需要照顧好被挑過的十份文件；生產環境要照顧的是會變動、會擴張、格式混亂的幾十萬份文件，外加每一筆查詢的權限、成本與新鮮度。前者是展示，後者是工程。
值得注意的是，這條牆並非無法跨越。同一批調查也顯示，當企業把 RAG 當成一套需要被治理、被持續評估的系統來經營，而不是一個一次性的技術 Demo，落地的成功率會明顯不同——Google Cloud 一份涵蓋三千多位企業決策者的調查就提到，較早投入代理式 AI 的企業中，有約 88% 至少在一個生成式 AI 應用場景上看到了回報。差別從來不在技術本身有多前沿，而在執行的紀律：你是把它當一個會壞、需要被量測、需要被維運的系統，還是當一個上線就能放著不管的功能。
下一次有人拿著一個跑得又快又篤定的 RAG Demo 來找你，記得問一句最能戳破幻覺的話——把它指向真正的文件庫，它還答得對嗎。