你的資料真的需要 RAG 嗎？三組 Baseline 實測告訴你
200 份文件的知識庫，該不該用 RAG？在投入向量資料庫和 embedding pipeline 之前，我先跑了三組對照實驗。結果：小資料集不需要 RAG，但關鍵字搜尋不是替代方案 — 語義歧義會讓檢索徹底崩壞。
200 份文件的知識庫，該直接塞還是建 RAG？
我手上有一個 200 份文件的知識庫，包含 64 份核心文件（14 份專案技術文件 + 50 篇 WordPress 文章）和 136 份公開 AI 技術文件。目標是建一個問答系統，讓使用者可以用自然語言查詢這些文件的內容。
直覺反應是「上檢索增強生成（RAG, Retrieval-Augmented Generation）」— 建 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 方案。
Context Stuffing 93 分最高，關鍵字搜尋 59 分崩壞
總分一覽
| 方法 | 總分（/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 檔比 14 檔表現更好 — 更多資料反而更好
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）。
中文 bigram 切分產生大量無意義 token，加劇匹配噪音
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）。結論穩健。
462K tokens 塞不進 200K context window — 這就是 RAG 存在的理由
200 份文件合計約 764K 字元，估算約 462K tokens，是標準 200K context window 的 2.3 倍。即使用 1M context window 的 Claude Opus 4.6，也會佔用近一半的 context，加上上下文衰減（context rot，隨 token 數增加準確度和召回率下降）和成本問題，Context Stuffing 在這個規模下不可行。
當資料量超過 context window 能處理的範圍，你需要先檢索再注入，而不是全部塞進去。
我的觀點
三組實驗的結論可以濃縮成三句話：
第一，小資料集不需要 RAG。64 份文件、150K tokens 以內，Context Stuffing 直接拿到 93 分。省掉 embedding、向量資料庫、檢索 pipeline 的建置成本，直接塞進去效果更好。
第二，關鍵字搜尋不是 RAG 的替代方案。在中英文混合、主題多樣的知識庫上，語義歧義會讓關鍵字搜尋在跨文件和推理類問題上徹底崩壞。你需要的是語義檢索（向量搜尋），不是更好的關鍵字搜尋。
第三，先做 baseline 再做系統。如果我一開始就跳進 RAG pipeline 的建置，我不會知道 Context Stuffing 在小資料集上已經夠好，也不會知道關鍵字搜尋的失敗模式長什麼樣。Baseline 實驗花的時間不多，但它讓你在投入建置成本之前，就知道上限在哪、問題在哪。
在你建系統之前，先用最簡單的方法跑一次，看數據告訴你什麼。
常見問題 FAQ
Context Stuffing 的 93 分是不是已經夠好了？為什麼還需要 RAG？
93 分是在 64 份文件的規模下取得的。當文件量成長到 200 份（462K tokens），Context Stuffing 物理上塞不進去。而且即使塞得進去，每次查詢都發送 462K tokens 的成本也不可接受。RAG 解決的是規模化問題，不是品質問題。
AI 自評的分數可信嗎？
在這次實驗中，80% 的自評與人工覆核一致，偏差在 ±1 分以內且無系統性偏差。但這不代表所有場景都可以只靠自評 — 本次覆核樣本只有 5 題。正式的評估系統應該要有更大的人工覆核比例。關鍵是：自評可以作為快速迭代的工具，但不能作為最終的品質標準。
這些結論可以推廣到其他知識庫嗎？
核心結論（小資料集不需要 RAG、關鍵字搜尋有語義歧義問題）有普遍性。但具體的分數臨界點會因資料特性而異 — 純英文知識庫的關鍵字搜尋可能表現更好，專業領域的知識庫可能需要更少的文件就觸發上下文衰減。建議在你自己的資料上跑一次 baseline，用你的數據做判斷。