企業導入 RAG 完整實戰指南 — 從「要不要做」到「做完怎麼評估」
企業有一堆內部文件想做智慧問答，第一個問題不是「怎麼建 RAG」而是「需不需要 RAG」。這篇用實測數據走完從評估、建置、診斷到優化的完整流程 — 200 份文件、20 題測試、五組對照實驗，最終結論：RAG 的價值不是比 Context Stuffing 更好，而是能處理 Context Stuffing 處理不了的規模。
問題起點：你的資料真的需要 RAG 嗎？
RAG（Retrieval-Augmented Generation）是目前企業 AI 導入最熱門的方向之一。但在投入建置成本之前，有一個更根本的問題：你現有的資料量，真的需要 RAG 嗎？
很多企業的知識庫其實沒那麼大。50 份內部文件、100 篇技術文檔 — 這些可能直接塞進 LLM 的 context window 就能用，完全不需要建什麼向量資料庫和檢索 pipeline。
以下是我用實際數據走完整個評估流程的記錄。
第一步：評估現有方案夠不夠用
Context Stuffing：直接把文件塞進去
最簡單的方案：把所有文件完整內容塞進 LLM 的 prompt，讓它直接回答。不需要建任何 pipeline。
實測結果：
- 14 份文件（約 25K tokens）：88 分（滿分 100）
- 64 份文件（約 121K tokens）：93 分 — 更多資料反而更好，因為跨文件問題有更多上下文可以交叉比對
93 分已經非常好了。如果你的知識庫在這個規模以內，直接 Context Stuffing 就是最佳方案，省掉整個 RAG pipeline 的建置成本。
關鍵字搜尋：最簡單的檢索方案
如果資料量太大塞不進去，最直覺的替代方案是關鍵字搜尋 — 用 TF-IDF 加權找相關段落，只把最相關的幾段塞進 prompt。
實測結果：59 分。
表面上看「還行」，但拆開來看問題很嚴重。跨文件問題只有 1.80 分（滿分 5），有三題直接拿 0-1 分。根因是語義歧義 — 同一個中文詞在不同語境中含義完全不同，關鍵字搜尋無法區分。查「技術選型決策」匹配到 AI 決策支持的文章，查「Blog-Writer 拆分」匹配到遊戲行銷裡的「區分成兩種類型」。
結論：關鍵字搜尋在中文多主題環境下嚴重失效。你需要的不是更好的關鍵字搜尋，是語義檢索。
第二步：資料規模的臨界點在哪
Context Stuffing 效果好但有物理上限 — LLM 的 context window 裝不下太多文件。臨界點在哪？
這個知識庫有 200 份文件，總計約 764K 字元、估算 462K tokens。標準 context window 是 200K tokens，462K 是上限的 2.3 倍，物理上不可能全塞進去。即使用 1M context window，佔用近一半的空間加上 context rot（token 數增加時準確度下降），也不實際。
判斷方法很簡單，不需要真的跑一次超量的 prompt：
| 資料規模 | 估算 tokens | vs 200K 上限 | Context Stuffing 可行性 |
|---|---|---|---|
| 14 份文件 | ~25K | 13% | 完全可行，效果好 |
| 64 份文件 | ~121K | 60% | 可行，接近上限 |
| 200 份文件 | ~462K | 230% | 不可行 |
中文的 token 效率比英文差約 3-4 倍（一個中文字約佔 1.5 tokens），這在估算時很容易被忽略。50 篇中文文章佔了 350K tokens，但只是 25% 的文件數。
第三步：建 RAG 系統的六個技術決策
確認需要 RAG 之後，建置過程中每一步都有選型要做。六個關鍵決策的 trade-off 簡要說明：
| 決策項 | 選擇 | 核心 trade-off |
|---|---|---|
| Chunking 策略 | 混合式（標題 + 固定長度） | 中英文混合知識庫需要兼顧兩種文件結構 |
| Chunk Size | 500 字元 + 100 overlap | 太大含噪音、太小失上下文，500 是中文的平衡點 |
| Embedding Model | multilingual-MiniLM（384 維） | 效果不是最好但免費、輕量、中英文雙語支援 |
| 向量資料庫 | ChromaDB | 本地免費適合 PoC，生產環境需要換 Pinecone 等雲端方案 |
| 搜尋策略 | Hybrid（向量 + BM25 + RRF） | 語義搜尋和精確匹配互補，比純向量或純 BM25 都好 |
| Top-K | 先 5 再 10 | 少了會遺漏跨文件答案，多了會引入噪音 |
每個決策都沒有唯一正確答案，取決於你的資料特性。但有一個共同邏輯：PoC 階段先選能跑的，確認方向對了再選跑得好的。
第四步：建完之後不是看總分，要做品質診斷
RAG 第一版跑完 20 題測試，拿了 77 分。比 Context Stuffing 的 93 分低。
如果只看總分，結論似乎是「RAG 不夠好」。但這個結論沒有行動價值 — 你不知道該改什麼。所以我做了逐題的品質診斷：標記 100 個 chunks（20 題 × 5 chunks）的相關性，分類失敗模式。
結果非常清楚：
| 失敗模式 | 佔比 | 說明 |
|---|---|---|
| Retrieval Failure | 33% | 搜尋找到完全不相關的段落 |
| Coverage Failure | 27% | 找到部分相關但資訊不完整 |
| Generation Failure | 0% | LLM 回答能力完全不是瓶頸 |
| 無失敗 | 40% | 檢索和回答都良好 |
Generation Failure = 0 是最重要的發現。它意味著：不要花時間升級 LLM，把資源全部投在改善檢索上。這個診斷直接決定了優化方向 — 不做的事跟做的事一樣重要。
第五步：針對性優化
根據診斷結果，我選了兩個優化：
Query Rewriting：在搜尋前讓系統把使用者問題改寫成 2-3 個版本，從不同角度描述同一個資訊需求，再分別搜尋合併結果。解決「使用者問題的語言跟知識庫的語言有落差」的問題。
Top-K 從 5 增到 10：讓更多段落有機會被納入，解決「正確段落存在但排名在 6-15 名之間被排除」的問題。
同時評估了 Reranker 和 Metadata Filtering，決定不做。原因是 20 題的測試集太小，同時改太多變數會分不清效果來源，容易 overfitting。控制變數比追求最高分更重要。
優化結果
| 指標 | 優化前 | 優化後 | 改善 |
|---|---|---|---|
| 總分 | 77 | 88 | +14.3% |
| Retrieval Failure | 5 題 | 2 題 | -60% |
| 無失敗題目 | 6 題 | 11 題 | +83% |
| Type A（單一文件） | 4.60 | 5.00（滿分） | +0.40 |
| Type B（跨文件） | 3.20 | 4.20 | +1.00 |
只改了檢索前處理（Query Rewriting）和參數（Top-K），不動 LLM、不動 Embedding Model、不動向量資料庫，分數就從 77 拉到 88。驗證了「問題在檢索端」的診斷結論。
最終結論：不同規模下的最佳方案
| 方法 | 總分 | 能處理規模 | 建置成本 | 適用場景 |
|---|---|---|---|---|
| Context Stuffing | 88-93 | < 150K tokens | 零 | 小型知識庫，直接用最省事 |
| 關鍵字搜尋 | 59 | 任何規模 | 低 | 不推薦用於中文多主題環境 |
| RAG v1（基本配置） | 77 | 無上限 | 中 | 大型知識庫的起步方案 |
| RAG v2（+ Query Rewriting） | 88 | 無上限 | 中 | 大型知識庫的推薦方案 |
簡單的決策樹：
- 資料量 < 100K tokens：直接 Context Stuffing。不需要建任何 pipeline，效果最好。
- 100K-200K tokens：Context Stuffing 可能還行（如果有 1M context window），但開始有成本和 context rot 壓力。可以開始評估 RAG。
- > 200K tokens：RAG 是唯一可行方案。實測能達到 Context Stuffing 95% 的效果（88 vs 93），而且能處理 3.8 倍的資料量。
RAG 的真正價值不是「比 Context Stuffing 更好」，而是「能處理 Context Stuffing 處理不了的規模」。在 context window 裝得下的範圍內，Context Stuffing 幾乎一定比 RAG 好。只有當資料量超過臨界點，RAG 才變成必要選項。
我的觀點
走完這整個流程，最大的體會是：AI 系統的品質管理跟傳統軟體完全不同。
傳統軟體出 bug，看 log 找根因，修完跑測試確認。AI 系統的「bug」不是非黑即白的 — 它是「這題拿 2 分而不是 5 分」。你需要一套不同的品質診斷方法：標記檢索品質、分類失敗模式、從失敗模式推導優化方向。這套方法論跟技術無關，是管理能力。
另一個反直覺的結論是：在評估 AI 方案時，先做最簡單的 baseline 比先建最完整的系統有效率得多。如果我一開始就跳進 RAG pipeline 的建置，我不會知道 Context Stuffing 在小資料集上有多強，也不會知道關鍵字搜尋在中文環境下的失敗模式。這些 baseline 花的時間不多，但它們定義了 RAG 需要超越的標準，也揭示了每種方案的弱點。
對企業來說，導入 RAG 的正確順序是：先驗證需求（你的資料量真的塞不下嗎？）→ 再建 baseline（最簡單的方案效果如何？）→ 然後建 RAG → 做品質診斷 → 針對性優化。跳過前兩步直接建 RAG，是最常見的浪費。
系列文章導引
這篇是完整流程的總覽。如果你想深入特定環節，以下是系列中其他六篇文章：
RAG 之前你該知道的事：四種資料檢索方法完整比較
向量搜尋、BM25、Hybrid Search、知識圖譜的原理和 trade-off。適合想搞懂 RAG 底層在做什麼的讀者。
你的資料真的需要 RAG 嗎？三組 Baseline 實測告訴你
Context Stuffing 88-93 分、關鍵字搜尋 59 分的完整實驗數據。為什麼小資料集不需要 RAG。
建一條 RAG Pipeline 之前，你需要做的六個技術決策
Chunking、Embedding、向量資料庫、搜尋策略的選型記錄。每個決策寫清楚考量和犧牲。
RAG 實測：用 200 份文件跑出來的數據，跟你想的不一樣
RAG 77 分 vs Context Stuffing 93 分的正確解讀。不同規模下的最佳方案選擇。
RAG 系統的 77 分怎麼來的？一次完整的 Retrieval 品質診斷
逐題拆解 100 個 chunks 的檢索品質。Generation Failure = 0 的發現和失敗模式分類方法論。
RAG 優化實戰：Query Rewriting 怎麼把分數從 77 拉到 88
診斷後的優化決策過程。為什麼選 Query Rewriting、為什麼不做 Reranker、20 題樣本的局限性。
常見問題 FAQ
企業導入 RAG 需要多少工程資源？
PoC 階段一個人就能做。RAG pipeline 的程式碼本身不複雜，用 Python 幾百行就能跑起來。真正需要投入的不是寫程式，而是資料整理（確保文件格式一致、品質夠好）和品質評估（設計測試題、做診斷、決定優化方向）。生產環境的運維和擴展才需要工程團隊。
這些數據適用於其他產業嗎？
方法論適用，具體數字不適用。這個知識庫是中英文混合的 AI 技術文件，你的知識庫可能是純中文的法律文件或英文的客服記錄，每種資料特性的最佳參數都不同。但「先做 baseline → 建 RAG → 診斷 → 優化」的流程是通用的。建議在你自己的資料上跑一次，用你的數據做判斷。
RAG 之外還有其他選項嗎？
有。如果你的資料是高度結構化的（例如資料庫、知識圖譜），Text-to-SQL 或圖查詢可能比 RAG 更合適。如果你的問答場景很固定（例如 FAQ），簡單的意圖分類 + 模板回覆可能就夠。RAG 最適合的是「大量非結構化文件 + 開放式問答」的場景。不要把 RAG 當成萬能解 — 先搞清楚你的場景特性，再選方案。