AI Agent 應用2026.03.24

你的資料真的需要 RAG 嗎？三組 Baseline 實測告訴你

200 份文件的知識庫，該不該用 RAG？在投入向量資料庫和 embedding pipeline 之前，我先跑了三組對照實驗。結果：小資料集不需要 RAG，但關鍵字搜尋不是替代方案 — 語義歧義會讓檢索徹底崩壞。

問題背景：我有一個知識庫，想做問答系統

我手上有一個 200 份文件的知識庫，包含 64 份核心文件（14 份專案技術文件 + 50 篇 WordPress 文章）和 136 份公開 AI 技術文件。目標是建一個問答系統，讓使用者可以用自然語言查詢這些文件的內容。

直覺反應是「上 RAG」— 建 embedding、向量資料庫、檢索 pipeline。但在投入這些建置成本之前，一個更根本的問題是：我的資料量真的需要 RAG 嗎？

為了回答這個問題，我設計了三組 baseline 實驗，用最簡單的方法先摸清楚上限和下限在哪裡。

實驗設計

測試題目：20 題、四種類型

設計了 20 題測試問題，分為四種類型，測試不同的檢索能力：

Type A — 單一文件直接回答（5 題）：答案存在於某一份文件中，不需要跨文件整合。測試基本的資訊定位能力。
Type B — 跨文件綜合（5 題）：答案需要整合多份文件的資訊。測試系統能不能把分散的資訊拼起來。
Type C — 推理判斷（5 題）：答案不直接寫在文件裡，需要根據內容做推理。測試理解深度。
Type D — 知識庫外問題（5 題）：答案不在知識庫中。測試系統能不能誠實說「我不知道」，而不是編造答案。

每題 1-5 分，由 AI 自評後再做人工覆核。

三組 Baseline

Baseline A-R1：Context Stuffing（14 份文件） — 把 14 份專案文件的完整內容直接塞進 prompt，讓 AI 逐題回答。約 78 KB / 7,300 words。

Baseline A-R2：Context Stuffing（64 份文件） — 把全部 64 份文件塞進 prompt。約 415 KB / 18,300 words / 估計 120,000-150,000 tokens。用的是 Claude Opus 4.6 的 1M context window。

Baseline B：關鍵字搜尋（64 份文件） — 把 64 份文件切成 1,583 個段落，用 TF-IDF 加權的關鍵字搜尋找 top-5 段落，只用這 5 段回答。模擬最簡單的 RAG 方案。

實驗結果

總分一覽

方法	總分（/100）	平均	Type A	Type B	Type C	Type D
A-R1：Context Stuffing 14 檔	88	4.40	4.80	3.80	4.00	5.00
A-R2：Context Stuffing 64 檔	93	4.65	4.80	4.60	4.40	4.80
B：關鍵字搜尋 64 檔	59	2.95	3.80	1.80	2.40	3.80

發現一：更多資料反而更好

64 檔（93 分）比 14 檔（88 分）表現更好，提升主要來自 Type B 跨文件問題（3.80 → 4.60）。50 篇 WordPress 文章為很多問題補充了關鍵上下文 — 比如文章裡記錄的 MBA 背景、拆分決策邏輯、效能優化過程 — 這些資訊在 14 份專案文件裡是缺失的。

直覺上會擔心「塞太多會干擾 AI」，但實測是相反的。更多相關資料讓 AI 有更多線索去交叉比對，而 Claude 的 1M context window 處理 150K tokens 時並沒有明顯的品質衰減。

發現二：關鍵字搜尋在中英文混合場景崩壞

關鍵字搜尋的 59 分表面上看「還行」，但拆開

來看問題很嚴重。Type B 跨文件問題只有 1.80 分（滿分 5），有三題直接拿 0-1 分。原因是語義歧義：

查「技術選型決策」→ 匹配到一篇寫 AI 決策支持的無關文章
查「Blog-Writer 拆分演變」→ 匹配到遊戲行銷文章裡的「區分成兩種類型」
查「Act 1 專案對齊目標」→ 匹配到一篇「專案管理工具比較」的舊文章

這不是偶然。在中英文混合、主題多樣的知識庫裡，同一個中文詞在不同語境中含義完全不同。關鍵字搜尋無法區分這些語境，只要表面字詞吻合就會匹配，產生大量 false positive。

發現三：中文 tokenization 加劇問題

Baseline B 用的是 bigram（兩字切分）做中文 tokenization。但中文 bigram 會產生大量無意義的 token — 比如「從最初的單一工具到拆分」會被切成「從最」「最初」「初的」「的單」「單一」⋯⋯這些碎片可能在任何文章中偶然匹配，嚴重稀釋了真正有意義的關鍵字信號。

人工覆核：AI 自評可信嗎？

三組 baseline 都是 AI 自評分數，這本身就需要驗證。我抽了 5 題做人工覆核（每種 Type 各取一題，選分數變化最大或最值得驗證的題目），逐一比對 AI 回答與知識庫原文。

結果：15 個評分中，12 個（80%）覆核建議與自評相同，3 個可能偏差 ±1 分，偏差方向不一致（有偏高也有偏低），不存在系統性偏差。

更重要的結論是：即使把所有偏差都調整，三方排名不變。 R2（93→91）> R1（88→89）>> B（59）。結論穩健。

那 200 份文件全塞得進去嗎？

不行。200 份文件合計約 764K 字元，估算約 462K tokens，是標準 200K context window 的 2.3 倍。即使用 1M context window 的 Claude Opus 4.6，也會佔用近一半的 context，加上 context rot（隨 token 數增加，準確度和召回率下降）和成本問題，context stuffing 在這個規模下不可行。

這就是 RAG 存在的理由：當資料量超過 context window 能處理的範圍，你需要先檢索再注入，而不是全部塞進去。

我的觀點

三組實驗的結論可以濃縮成三句話：

第一，小資料集不需要 RAG。64 份文件、150K tokens 以內，context stuffing 直接拿到 93 分。省掉 embedding、向量資料庫、檢索 pipeline 的建置成本，直接塞進去效果更好。

第二，關鍵字搜尋不是 RAG 的替代方案。在中英文混合、主題多樣的知識庫上，語義歧義會讓關鍵字搜尋在跨文件和推理類問題上徹底崩壞。你需要的是語義檢索（向量搜尋），不是更好的關鍵字搜尋。

第三，先做 baseline 再做系統。如果我一開始就跳進 RAG pipeline 的建置，我不會知道 context stuffing 在小資料集上已經夠好，也不會知道關鍵字搜尋的失敗模式長什麼樣。Baseline 實驗花的時間不多，但它讓你在投入建置成本之前，就知道上限在哪、問題在哪。

這個方法論適用於任何技術選型：在你建系統之前，先用最簡單的方法跑一次，看數據告訴你什麼。