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 自評後做人工覆核驗證。

RAG 77 分 vs Context Stuffing 93 分：四組實驗結果

RAG 用 2% 資訊量達到 83% 效果 — 規模才是關鍵

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 比純關鍵字搜尋提升 31%

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 的限制讓系統只能撈到冰山一角。

不同規模下的最佳方案

關鍵判斷點不只是「塞不塞得下」，還有成本和上下文衰減。即使 1M context window 塞得下 462K tokens，每次查詢都發送這麼多 token 的 API 費用，以及隨 token 數增加的準確度衰減，都需要納入考量。

77 分不是上限，而是 v1 baseline — 四個優化方向

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，成本和上下文衰減也讓它不實際。RAG 解決的是「我的知識庫在成長，我需要一個能 scale 的方案」這個問題。

BM25 的關鍵字陷阱怎麼解決？

短期可以用 stopword 過濾（把「Act」這類高歧義詞加入停用詞表）。中期可以加 Reranker，讓 cross-encoder 在看到完整 query-document pair 後重新排序，把語境不符的結果降權。長期可以考慮查詢擴展（query expansion）— 用 LLM 把使用者問題改寫成多個變體，增加檢索覆蓋率。