RAG 實測：用 200 份文件跑出來的數據，跟你想的不一樣
大部分人以為 RAG 一定比傳統方案好。實測數據告訴你不是這樣 — RAG 拿 77 分，Context Stuffing 拿 93 分。但 RAG 是唯一能處理 462K tokens 規模的方案。這篇用四組實驗的數據，拆解不同規模下該選什麼方案。
實驗配置
知識庫：200 份文件（64 份專案文件 + 136 份公開 AI 技術文件），總計約 764K 字元、估算 462K tokens。經過混合式 Chunking 後產生 1,880 個 chunks。
RAG pipeline 配置：paraphrase-multilingual-MiniLM-L12-v2 做 embedding（384 維）、ChromaDB 做向量儲存、Hybrid Search（向量 + BM25 + RRF k=60）取 top-5 chunks。
測試題目：20 題，四種類型 — Type A 單一文件直接回答、Type B 跨文件綜合、Type C 推理判斷、Type D 知識庫外問題（測拒答能力）。每題 1-5 分，AI 自評後做人工覆核驗證。
四組實驗結果
| 方法 | 資料量 | 總分（/100） | Type A 單一文件 | Type B 跨文件 | Type C 推理 | Type D 拒答 |
|---|---|---|---|---|---|---|
| R1：Context Stuffing 14 檔 | 14 檔 / ~25K tokens | 88 | 4.80 | 3.80 | 4.00 | 5.00 |
| R2：Context Stuffing 64 檔 | 64 檔 / ~150K tokens | 93 | 4.80 | 4.60 | 4.40 | 4.80 |
| B：關鍵字搜尋 64 檔 | 64 檔 / top-5 段落 | 59 | 3.80 | 1.80 | 2.40 | 3.80 |
| RAG Hybrid 200 檔 | 200 檔 / top-5 chunks | 77 | 4.60 | 3.20 | 3.20 | 4.40 |
數據解讀：別只看總分
RAG 輸給 Context Stuffing 是正常的
RAG 77 分 vs Context Stuffing 93 分，差 16 分。表面上看 RAG「更差」，但這個比較不公平。Context Stuffing 把所有文件完整塞進 prompt，LLM 能「看到」全部資訊，回答品質自然最高。問題是它塞不下。
64 檔的 Context Stuffing 已經佔了約 150K tokens，接近 200K context window 的上限。200 檔的 462K tokens 是 200K 上限的 2.3 倍，物理上不可能做 Context Stuffing。即使用 1M context window，每次查詢發送 462K tokens 的成本和 context rot（token 數增加時準確度下降）也讓它不實際。
正確的解讀是：RAG 用 2% 的資訊量（5 個 chunks vs 全部文件），達到了 83% 的效果（77 vs 93），而且是唯一能處理這個規模的方案。
Hybrid Search 大幅改善關鍵字搜尋的崩壞
RAG Hybrid 77 分 vs 純關鍵字搜尋 59 分，提升 31%。改善最大的是跨文件問題（Type B：3.20 vs 1.80）。向量搜尋的語義理解補了 BM25 的語義歧義盲點。
但 Hybrid 也沒完全解決問題。Type B 的 3.20 分對比 Context Stuffing 的 4.60，仍然有差距。原因是 top-5 chunks 對跨文件問題來說不夠 — 答案可能分散在 8-10 個段落裡。
RAG 的亮點和弱點
亮點：Q7 事實查核機制拿滿分
這是 Hybrid Search 發揮得最好的一題。系統從三個不同文件找到互補資訊 — article-writer 的 CLAUDE.md 有查核步驟、multi-agent 文章有人機分工設計、content-pipeline 文章有查核維度定義。三個 chunk 拼在一起，完整覆蓋了事實查核機制的全貌。
這正是 Hybrid Search 的價值：向量搜尋找到語義相關的「事實查核」段落，BM25 找到包含精確術語的段落，RRF 把兩者的結果合併，最終覆蓋率比任何一種單獨搜尋都高。
弱點一：BM25 的關鍵字陷阱
Q8 問的是「Act 1 專案對齊了目標職缺的哪些能力」，RAG 只拿 1 分。原因是 BM25 被「Act」這個詞誤導，匹配到了一篇關於美國晶片法案（CHIPS and Science Act）的文章，以及一篇「AI 曼哈頓計畫」的文章。5 個 chunks 裡有 3 個完全無關。
這是 BM25 在 Hybrid Search 裡的副作用：它會把高頻但語境錯誤的匹配推進 RRF 的候選池，如果向量搜尋那邊也沒找到正確段落，最終結果就會偏離。
弱點二：抽象問題檢索困難
Q6 問「技術選型決策和理由」，只拿 2 分。問題在於「技術選型決策」是一個抽象概念，在文件裡不會有一段文字明確寫著「這是一個技術選型決策」。相關資訊分散在 HANDOFF、CLAUDE.md、troubleshooting 等多個文件的多個段落裡，每段只涵蓋一個面向。Top-5 的限制讓系統只能撈到冰山一角。
不同規模下的最佳方案
| 資料規模 | 推薦方案 | 理由 |
|---|---|---|
| < 50 份文件 / < 50K tokens | Context Stuffing | 直接塞進去效果最好，不需要建任何 pipeline |
| 50-100 份 / 50K-150K tokens | Context Stuffing（如果塞得下） | 在 1M context window 下仍然可行，效果優於 RAG |
| 100-200 份 / 150K-500K tokens | 視情況而定 | 如果有 1M context window 且能接受成本，可以繼續塞；否則需要 RAG |
| > 200 份 / > 500K tokens | RAG（Hybrid Search） | Context Stuffing 物理上不可行，RAG 是唯一選項 |
關鍵判斷點不只是「塞不塞得下」，還有成本和 context rot。即使 1M context window 塞得下 462K tokens，每次查詢都發送這麼多 token 的 API 費用，以及隨 token 數增加的準確度衰減，都需要納入考量。
後續優化方向
77 分不是 RAG 的上限，而是 v1 的 baseline。明確的優化路徑：
增加 Top-K。從 5 增加到 10，看跨文件問題（Type B）和推理問題（Type C）能改善多少。代價是更多噪音和更多 token 消耗。
加 Reranker。在 RRF 合併後、送進 LLM 前，用 cross-encoder 對 top-K 結果做精排。Reranker 的計算量比 embedding 大，但它看的是 query-document pair 而非獨立的 embedding，精度更高。
調整 Chunk Size。測試 300 和 800 字元的效果差異。300 可能讓精確查詢更準，800 可能讓跨段落的上下文更完整。
升級 Embedding Model。從 multilingual-MiniLM（384 維）升級到 bge-m3（1024 維），看語義精度的提升能帶來多少分數改善。
我的觀點
這組實驗最重要的結論不是「RAG 比 Context Stuffing 差」，而是不同方案適用於不同規模，沒有萬能解。
如果你的知識庫小到可以塞進 context window，就直接塞，不要花時間建 RAG pipeline。如果你的知識庫大到塞不進去，那 RAG 不是可選項而是必選項 — 77 分不完美，但 0 分（因為塞不下而無法回答）更差。
而在 RAG 內部，Hybrid Search 比純關鍵字搜尋好 31%，這不是「略有改善」而是「質的差別」。關鍵字搜尋在跨文件問題上崩壞到 1.80 分，Hybrid 至少拉到 3.20 分。語義檢索不是「更好」而是「必要」。
最後，先跑 baseline 再建系統這個方法論，我在每一輪實驗中都受益。如果我一開始就跳進 RAG，我不會知道 Context Stuffing 在小資料集上有多強，也不會知道關鍵字搜尋的失敗模式長什麼樣。先用最簡單的方法跑一次，讓數據告訴你問題在哪，比閉著眼睛建系統有效率得多。
常見問題 FAQ
RAG 77 分算好嗎？
作為 v1 baseline 算是合理的起步點。單一文件問題（Type A）拿到 4.60 分已經接近 Context Stuffing 的水準。弱點集中在跨文件和推理問題上，而這些恰好是最有優化空間的方向（增加 Top-K、加 Reranker）。77 分是地板不是天花板。
Context Stuffing 93 分，為什麼不直接用它就好？
因為它不能 scale。93 分是在 64 份文件的前提下取得的。當文件量成長到 200 份（462K tokens），Context Stuffing 塞不進 200K 的 context window。即使用 1M context window，成本和 context rot 也讓它不實際。RAG 解決的是「我的知識庫在成長，我需要一個能 scale 的方案」這個問題。
BM25 的關鍵字陷阱怎麼解決？
短期可以用 stopword 過濾（把「Act」這類高歧義詞加入停用詞表）。中期可以加 Reranker，讓 cross-encoder 在看到完整 query-document pair 後重新排序，把語境不符的結果降權。長期可以考慮 query expansion — 用 LLM 把使用者問題改寫成多個變體，增加檢索覆蓋率。