RAG · 微调 · 长上下文 — 我的问题该用哪个：论文实际测量了什么，以及没有人测量过什么

引言 — 先说答案
三种方式解决的并不是同一个问题
微调能注入知识吗 — 两篇论文看似截然相反的原因
- 在照单全收农业论文的数字之前
- 以及，硬把新知识塞进去会发生什么
长上下文在哪里崩塌 — 位置、长度、词汇
RAG 比长上下文便宜吗 — Self-Route 实际测量的东西
但基准测试本身已被污染 — 本文最重要的部分
2026 年的变化 — 缓存不会让长上下文变成免费
那么该看什么 — 你实际能测量的东西
什么时候不该用
没有人回答的问题
结语
参考资料

引言 — 先说答案

「我们想拿自己的文档做一个聊天机器人，该用 RAG、该做微调，还是干脆把所有东西都塞进 100 万 token 的上下文里就行?」这大概是 LLM 架构领域被问得最多的问题。而搜索出来的答案，大多是一棵没有任何出处的决策树。「需要最新信息就 RAG，需要风格就微调」 — 话不算错，但靠它什么也决定不了。因为它没有回答为什么、到什么程度、在哪里崩塌。

所以本文只用测量过的东西来回答。先把结论写在前面。

这三者从一开始就不是竞争关系。 微调无法向模型注入新的事实 — 这是多篇论文反复测量得到的结果。所以如果问题出在「知识」上，选项实际上只有两个。
剩下的选择(RAG vs 长上下文)，几乎由一个你可以亲手测量的属性决定 — 你的语料库上 recall@k 曲线在哪里饱和。这不是什么基准测试，而是一个下午就能测出来的数字。
还有必须诚实的部分 — 在我确认过的范围内，没有任何研究在同一个公共基准上比较过这三种方式。每篇论文用的是不同的模型、不同的数据集、不同的指标。所以不能把 A 论文的数字和 B 论文的数字摆在一起比较。

下面是依据。每个数字测了什么、没测什么，我都会一并写明。

三种方式解决的并不是同一个问题

首先要把轴理清楚。这三种方式经常被并排摆放，但实际上它们改变的是不同的东西。

微调改变的是权重。它是改变模型如何回答的工具。
RAG 改变的是提示词里放什么。只放检索挑出来的片段。
长上下文改变的同样是提示词里放什么。只不过不挑，全放。

也就是说，RAG 和长上下文是同一条轴(往提示词里放什么)的两个极端，而微调在另一条轴上。Gekhman 等(arXiv:2405.05904)的结论句最凝练地表达了这个格局 — 论文写道，结果支持这样一种观点：大型语言模型的事实知识大部分是在预训练中获得的，而微调教会模型的是更高效地使用这些知识。

如果这句话成立，那么「用微调让模型学会内部文档」这个计划从出发点就选错了工具。可实务中也流传着看起来正相反的案例研究。得先把这个矛盾解开。

微调能注入知识吗 — 两篇论文看似截然相反的原因

否定的一方。 Ovadia 等的 "Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs"(arXiv:2312.05934)正面测量了知识注入。结论很明确 — 无监督微调也能带来一些改进，但 RAG 一贯胜过它；无论是训练时见过的既有知识，还是全新的知识，都是如此。而且模型很难通过无监督微调学到新的事实信息。

肯定的一方。 Microsoft 的 "RAG vs Fine-tuning: Pipelines, Tradeoffs, and a Case Study on Agriculture"(arXiv:2401.08406)看起来正相反。按摘要的原话 — 微调让准确率提升了 6 p.p. 以上，且与 RAG 叠加后又提升了 5 p.p.。

两个结果冲突吗? 不冲突。它们测的是不同的干预。

Ovadia 等所说的微调是无监督微调，也就是持续预训练(continual pre-training)。论文明确写道，这项研究通篇使用这种方式。即把原文文本原样摆上、让模型预测下一个 token。更重要的是论文把有监督微调(指令微调)直接排除出候选时写下的理由 — 指令微调并不必然教给模型新知识，因此仅靠指令微调无法成为知识注入问题的解法。

而农业论文的流水线是用 Q&A 对做微调。先从文档生成问答对，再拿它们去训练。这是完全不同的干预。

所以梳理下来是这样：「微调」这一个词至少指向两种不同的操作，而两篇论文各测了其中一种。博客文章把这两者混在一起引用，于是制造出「微调有时行、有时不行」这种没有结论的结论。

在照单全收农业论文的数字之前

既然要引用肯定一方的证据，就得把这份证据的局限也一并看清，这才公平。论文的 Table 18 是这样的。

模型                       微调    准确率      +RAG
Llama-2-chat 13B                  76% ±2%    75% ±2%
Vicuna                            72% ±2%    79% ±2%
GPT-4                             75% ±3%    80% ±4%
Llama2 13B                  O     68% ±3%    77% ±2%
GPT-4                       O     81% ±5%    86% ±2%

算术完全正确。以 GPT-4 为准，75% → 81% 对应摘要里的「6 p.p. 以上」，81% → 86% 对应「RAG 再加 5 p.p.」。不过有三点必须指出。

误差范围互相重叠。 75% ±3% 的区间是 72~78，81% ±5% 的区间是 76~86。两者在 76~78 的区间重叠。而且论文没有定义这个 ± 值是标准差还是置信区间，也没有给出显著性检验。把 6 p.p. 读成「确凿的改进」，就超出了证据的范围。
领域微调反而落败的案例就在表里。 用农业数据微调过的 Llama2 13B 是 68%，低于通用指令微调模型 Llama-2-chat 13B 的 76%。(不过出发的检查点不同 — 前者用的是基座模型，后者用的是 chat 模型。即便如此，「用领域数据微调就能在领域任务上赢」这个直觉并不自动成立，这一点是明确的。)
训练标签是 LLM 的生成物，打分者也是 LLM。 微调用的答案是给 Llama2-13B-chat 接上 RAG 生成的，评估由 GPT-4 完成。换句话说，这个实验在相当程度上更接近「把 RAG 流水线的输出蒸馏(distill)进模型」。

以及，硬把新知识塞进去会发生什么

Gekhman 等(arXiv:2405.05904)在这里又往前走了一步。他们控制微调样本中引入新知识的比例并观察，发现含有新知识的样本，比与模型已有知识一致的样本学得明显更慢。而一旦最终学会了，这些样本又会让模型的幻觉倾向线性增加。

照搬论文的表述 — 结果表明，通过微调引入新的事实知识是有风险的。「学得慢，学会之后幻觉变多」这个组合在实务中是最糟的。因为它表现为训练损失在下降、生产环境的质量却在变差。

实务启示：不要把经常变化的事实用微调塞进去。微调应该用来改变行为 — 格式、语气、领域术语、输出结构。至于用 LoRA 做这些时超参数如何互相纠缠，我在 LoRA rank 与学习率一篇里另行展开。

长上下文在哪里崩塌 — 位置、长度、词汇

那全塞进去不就行了? 上下文窗口都 100 万 token 了。这里有三个互不相同、且已被测量的失败模式。

位置。 Liu 等的 "Lost in the Middle"(arXiv:2307.03172)改变相关信息的位置来测性能。结果就是广为人知的 U 形曲线 — 相关信息位于输入的开头或结尾时性能最高，位于长上下文的中间时性能大幅下降。论文还钉死了一点：这种现象在明确标榜长上下文的模型上同样出现。

长度。 Databricks 的 "Long Context RAG Performance of Large Language Models"(arXiv:2411.03538)对 20 个开源和商用模型，把上下文长度从 2,000 token 变到 128,000 token(可能时到 200 万)，跑了 RAG 工作流。用了三个领域数据集。核心结果就在摘要里 — 检索更多文档确实可能提升性能，但在超过 64k token 的长度上还能保持一致准确率的模型，即便在最新的 SOTA 里也寥寥无几。

正文更具体。在分析的大多数模型上，RAG 性能上升的区间只到 16k~32k token。Qwen 2 70B 到 64k 还能保持一致的准确率，Llama 3.1 405B 从 32k 之后开始下滑，GPT-4-0125-preview 在 64k 之后下滑。

更有意思的是失败的方式因模型而异。Claude 3 Sonnet 频繁以版权顾虑为由拒绝回答；Gemini 1.5 Pro 因为过于敏感的安全过滤器，在长上下文上任务失败；Mixtral-8x7B 吐出重复或随机的内容；DBRX 在 16k 以上经常不遵循指令、径自把内容摘要掉。也就是说，连「长上下文会变差」这句话都不是单一现象 — 拒答、安全过滤、重复、无视指令，分别出现在不同的模型上。

词汇。 NoLiMa(arXiv:2502.05167)是最让人不舒服的结果。论文指出，既有的 needle-in-a-haystack 测试在针和草堆之间存在字面上的词汇重合，模型可以利用这一点把任务变简单。于是他们把问题与针之间的词汇重叠压到最低来设计测试，对 13 个宣称支持 128K 以上的模型评估的结果是：在短上下文上表现很好的模型，随长度增加性能大幅下降。在 32K 处，11 个模型跌到自己短上下文基线的 50% 以下，连位居最前列的 GPT-4o 也从近乎完美的 99.3% 基线掉到 69.7%。

这里有个重要的推论：通过了 needle-in-a-haystack，并不是长上下文能用的证据。 那个测试一直允许词汇重合这条捷径。真实的问题通常不会和文档用同样的词。

诚实的局限：上述三项研究评估的模型都属于 2023~2024 年代(NoLiMa 于 2025 年修订)。用同样的方法论在 2026 年的前沿模型上重测、看同样的曲线是否复现的公开研究，我没有找到。

RAG 比长上下文便宜吗 — Self-Route 实际测量的东西

成本方面被引用最多的，是 Google 的 Self-Route 论文(Li 等，arXiv:2407.16833)。来看实际的表。以 Contriever 检索器为准、9 个数据集的平均。

Gemini-1.5-Pro       LC 49.70 | RAG 37.33 | Self-Route 46.41 | token 38.39%
GPT-4O               LC 48.67 | RAG 32.60 | Self-Route 48.89 | token 61.40%
GPT-3.5-Turbo        LC 32.07 | RAG 30.33 | Self-Route 35.32 | token 38.85%

读法是这样的。资源充足时，LC 一贯胜过 RAG — 49.70 对 37.33 不是小差距。但 Self-Route(简单的问题走 RAG，只有 RAG 判断「无法回答」的才走 LC)只用 LC 的 38~61% 的 token，就能逼近 LC。

为什么行得通，才是这篇论文真正的发现 — 63% 的查询上模型预测完全相同，70% 的查询上分数差小于 10。论文还补了一句：相同的预测未必就是正确答案，RAG 和 LC 不仅倾向给出相同的正确答案，也倾向犯同样的错误。也就是说，在大多数问题上，这两种方式从一开始就无从区分。没有理由用贵的那个。

成本数字要小心引用。 论文正文写道，Gemini-1.5-Pro 上成本降低了 65%，GPT-4O 上降低了 39%。GPT-4O 的算术严丝合缝 — 用了 61.40% 的 token，节省 38.6%，四舍五入就是 39%。可 Gemini-1.5-Pro 用的是 38.39% 的 token，节省应当约为 61.6%；在使用 Dragon 检索器的 Table 2 里，token 比例也是 37.87%(约节省 62.1%)。论文所说的 65%，与论文自己的表格有约 3 p.p. 的出入。 不是大问题，但在把「65%」照抄过去之前，应该知道这一点。

还有一个决定性的局限：这篇论文用的模型是 gpt-3.5-turbo-0125、gpt-4o-2024-05-13、Gemini-1.5-Pro。是 2024 年的模型。数据集是 LongBench(平均上下文约 7k 个单词)和 ∞Bench(平均约 100k token)，这里说的「长上下文」不是 100 万 token，而是 7k~100k。

到了 2026 年有了后续研究。"Route Before Retrieve"(arXiv:2605.10235，2026 年 5 月)指出，Self-Route 是先尝试 RAG、失败了才转向 LC 的被动回退，并提出在检索之前就用元数据(文档类型、长度、开头片段)先决定路由。这个方向本身就是一个信号：在保留 Self-Route「不同问题用不同工具」这一洞察的同时，把它的成本进一步压低。

但基准测试本身已被污染 — 本文最重要的部分

有一个发现，动摇了到目前为止的全部数字。

"Long Context vs. RAG for LLMs: An Evaluation and Revisits"(arXiv:2501.01880)在重新审视既有研究时，指出了它们核心洞察之间的不一致。然后做了一件非常简单、却没有人做过的事 — 把不需要外部上下文也能答对的问题过滤掉。 逻辑是这样的：现代 LLM 仅凭参数里编码的知识就能回答许多问题，所以要判断在长文档上哪种方式更有帮助，就必须只留下模型在没有上下文时答不对的问题。过滤用 GPT-4o，并采用严格的 exact-match 打分。

结果如下。

数据集             全部问题    保留问题   保留率
Coursera                172          54     32%
NQ                    1,109         373     34%
NovelQA               2,283         869     38%
2WikiMHQA             2,300       1,036     45%
HotpotQA              2,200       1,113     51%
MultiFieldQA            150         121     81%
NarrativeQA           2,211       1,880     85%
QASPER                2,718       2,674     98%
QuALTY                2,725       2,725    100%
TOEFL-QA                962         962    100%
MultiDoc2Dial           158         158    100%
─────────────────────────────────────────────
合计                 19,188      13,628     71%

Natural Questions 的保留率是 34%。 换句话说，NQ 的问题约有三分之二，GPT-4o 一点上下文都不给也能答对。Coursera 是 32%，NovelQA 是 38%。

为什么这是致命的 — 在这些基准之上测「RAG vs 长上下文」的分数时，分数的相当一部分测的其实是模型的预训练知识，而不是检索。而前面引用的 Databricks 研究所用的三个数据集里，恰好就有 NQ。

由此得出的实务结论，是本文最重要的一条。你的内部文档不在模型的预训练数据里。 所以不能把公开基准上得出的 RAG 对 LC 的比例，原样搬到你的语料库上。在基准上，模型早已知道相当一部分答案；在你的语料库上，它一个都不知道。条件不同。

补充一点，这篇论文自身的结论也与先前的研究有微妙差异 — 在 QA 基准、尤其是基于维基百科的问题上，LC 大体胜过 RAG；基于摘要的检索与 LC 相当，基于分块的检索落后。但在基于对话的查询和一般性查询上，RAG 占优。也就是说，「RAG 赢/输」会随数据集种类而反转。

2026 年的变化 — 缓存不会让长上下文变成免费

Self-Route 的成本模型很简单。论文自己写道，LLM API 的定价通常基于输入 token 数，所以 token 用得少就便宜多少。在 2024 年这是对的模型。

在那之后，提示词缓存普及了。把稳定的前缀(prefix)放进缓存，复用时便宜得多。以 Anthropic 文档化的自家结构为例，缓存读取约为基础输入价格的 0.1 倍，缓存写入在 5 分钟 TTL 下是 1.25 倍、1 小时 TTL 下是 2 倍。可缓存的最小前缀长度也因模型而异(例如 Opus 4.8 是 4,096 token，Sonnet 4.6 是 2,048 token)。于是自然会冒出反问 — 如果语料库稳定、查询反复出现，把它整个放进缓存，Self-Route 的成本逻辑不就崩了吗?

只在部分程度上成立。 2026 年 3 月的 "Beyond the Context Window"(arXiv:2603.04814)实际测了这件事。这项研究建立了把提示词缓存计算在内的成本模型，对比了基于事实的记忆系统(Mem0)与长上下文推理。核心句子是这个 — 长上下文推理即便应用了缓存，每一轮也要支付随上下文长度成正比增长的成本；而记忆系统的每轮读取成本，在一次性的写入阶段之后几乎固定。

测量值如下(LongMemEval，500 段对话，平均上下文 101,601 token)。

                        成本
记忆写入(1次)       $0.0435 / 对话      (共 $21.76，500 段对话)
记忆读取            $0.0013 / 查询      (共 $0.65，500 个问题)
LC GPT-5-mini       $0.0293 / 请求      (共 $14.79，504 个请求)
LC 首轮(模型值)     $0.0265
─────────────────────────────────────────────────────────────
盈亏平衡: 约 10 轮 (100k 上下文)。N=20 时记忆便宜 26%。
上下文越长，平衡点从 13 轮 -> 9 轮下移。

算术没问题($21.76 除以 500 是 $0.0435，$14.79 除以 504 是 $0.0293)。所以，轮数少时长上下文便宜，轮数多时检索便宜。 缓存只能压低这条曲线的斜率，无法反转它的方向。

不过引用这篇论文时，有件事必须一起说。在准确率上，长上下文赢得很彻底。

数据集            记忆系统   LC GPT-5-mini   LC GPT-OSS-120B
LoCoMo                57.68           92.85            81.69
PersonaMem v2         62.48           69.75            60.50
LongMemEval           49.00           82.40            48.20

LoCoMo 上是 57.68 对 92.85，LongMemEval 上是 49.00 对 82.40。便宜的一方在准确率上输得很惨。论文也写了原因 — 传入完整历史时所有细节都被保留，而记忆流水线把约 101,600 token 的对话压缩成每用户平均 2,909 token 的原子事实，压缩过程中的信息损失不可避免。

适用范围的限定：这项研究测的是持续型对话智能体的记忆系统，不是文档语料库的 RAG。关于成本结构的洞察(「检索是每轮固定，长上下文即便缓存也随长度成正比」)可以泛化，但准确率数字是对话记忆基准上的。不能照搬。

缓存本身的效果有单独的测量。"Don't Break the Cache"(arXiv:2601.06007)在横跨三家提供商的 500 多个智能体会话上测量缓存，报告成本节省在 41% 到 80% 之间、TTFT 改善在 13% 到 31% 之间。不过这篇论文测的同样是智能体式工具调用负载(DeepResearch Bench)，并写明在全上下文缓存策略下 TTFT 没有改善、甚至出现轻微退化。而且如论文自己所言，就作者们所知，此前并不存在在多轮智能体任务上量化这种成本节省的先行研究。

那么该看什么 — 你实际能测量的东西

现在是决策规则。这里的核心是别读基准测试，去测你自己的语料库。而要测的第一个数字只有一个。

第 1 步：画出 recall@k 曲线(这几乎决定一切)

Databricks 论文放进附录的表，实际上就是这套方法论的模板。用 text-embedding-3-large 按上下文长度测每个数据集的 recall@k。

上下文长度           2k     4k     8k    16k    32k    64k    96k   128k
Databricks DocsQA  0.547  0.856  0.906  0.957  0.978  0.986  0.993  0.993
FinanceBench       0.097  0.287  0.493  0.603  0.764  0.856  0.916  0.916
NQ                 0.845  0.992  1.000  1.000  1.000  1.000  1.000  1.000

照论文的解读 — 每个数据集检索 recall 饱和的上下文长度各不相同。NQ 在 8k 就早早饱和，DocsQA 和 FinanceBench 分别在 96k 和 128k 饱和。

这条曲线就是你的答案。

如果在小 k 就饱和(像 NQ 那样) — 答案是局部的。检索在 8k 以内就已经把全部依据拿了回来。长上下文什么也给不了，只会增加干扰文档(distractor)。用 RAG。 在这里加长上下文是纯粹的损失。
如果一直涨到 96k~128k(像 FinanceBench 那样) — 依据散布得很广。这是长上下文唯一可能值回票价的区域。不过有条件(见第 2 步)。
如果到最后也没有变好 — FinanceBench 在 128k 也只有 0.916，到不了 100%。要么检索是瓶颈(分块、嵌入的问题)，要么这从一开始就不是检索能解的问题。若是后者，先试混合检索与重排序；还不行的话，你的问题要求的可能不是「检索」而是「综合」 — 那才是该考察 Graph RAG 的时点。

而且 Databricks 论文附上的警告必须一起读 — 检索准确率单调增加，但这并不意味着 RAG 准确率也单调增加。加长上下文，recall 上升、生成变差。所以最优点不在两端，而在中间的某个位置。这只有把曲线画出来才找得到。

测法并不难。准备 50~100 个已知正确文档的问题，改变 k，数正确文档进入前 k 的比例即可。这是不需要调用 LLM 的纯检索指标，又便宜又快。

第 2 步：确认模型在那个长度上扛得住

第 1 步得出「涨到 96k」，并不等于塞 96k 就行。在 Databricks 的测量里，大多数模型在 16k~32k 就已经见顶回落。而如 NoLiMa 所示，一旦问题和文档的词汇不重合，大多数模型在 32K 就崩了。你的问题会和文档用同样的词吗? 通常不会。

第 3 步：看更新频率

语料库经常变化的话，微调直接出局(每次变化都要重训)。长上下文的缓存收益也随之消失(前缀一变缓存就失效，而默认 TTL 是分钟级)。在频繁变化的语料库上，RAG 是默认值。

第 4 步：是知识还是行为

「用我们的语气回答」/「只按这个 JSON schema 输出」/「理解这些领域缩写」→ 微调。「这份文档里写了什么」→ 检索。别把这两件事混在一起。Ovadia 和 Gekhman 的结果说的正是这一点。

第 5 步：按轮数计算预算

同一份上下文你会问多少次? 借用 "Beyond the Context Window" 的结构 — 轮数少则长上下文便宜，轮数多则检索便宜。100k 上下文下的盈亏平衡点约在 10 轮。一份文档只问一个问题，长上下文可能占优；同一个语料库要接几千个查询，检索则是压倒性的。

什么时候不该用

通常最值得引用的部分在这里。

不要用微调注入事实。 学得慢，学会之后幻觉变多(Gekhman 等)。把内部 wiki 拿去微调的项目，几乎总是选错了工具。
不要因为上下文窗口是 100 万就用长上下文。 窗口大小是容量，不是能力。按 NoLiMa 的测量，在 32K 处 13 个模型里有 11 个跌破自己基线的一半。
不要拿通过了 needle-in-a-haystack 当依据。 那个测试允许词汇重合的捷径。
recall 在小 k 就饱和时，不要加长上下文。 只会增加干扰文档，一头栽进 lost-in-the-middle。
不要把公开基准上的 RAG 对 LC 比例搬到你的语料库上。 NQ 的问题约有三分之二不用上下文就能解。你的文档不是这样。
本文的数字同样不是你语料库的答案。 它们全都来自别人的语料库、别人的模型。

没有人回答的问题

这是需要诚实写下的部分。以下是在我确认过的范围内，公开研究尚未回答的问题。

没有研究在同一个公共基准上比较过这三种方式。 RAG 对 LC(Self-Route、2501.01880)和 RAG 对微调(Ovadia、农业论文)各自存在，但用的是互不相同的模型、数据集、指标。所以「RAG 比 LC 低 12 分、微调能加 6 p.p.，那 RAG+微调就…」这类计算不成立。本文也没有做。
没有研究在 2026 年的前沿模型上、把缓存也计入之后重测 RAG 对 LC。 Self-Route 用的是 2024 年的模型和基于 token 的成本模型。缓存感知的成本模型由 2603.04814 建立，但对象是对话记忆，不是文档 RAG。
连缓存对智能体工作负载的效果，都是最近才被测量的。 2601.06007 明确写道，就作者们所知，此前没有在多轮智能体任务上量化这种成本节省的先行研究。
缺少对不同微调方式的知识注入效果做受控比较的研究。 无监督持续预训练(Ovadia)和有监督 Q&A 微调(农业)从未在同一份数据、同一套评估下被比较过。所以「有监督 Q&A 微调是否就能注入知识」仍然悬而未决 — 农业论文的证据误差范围重叠，标签还是 LLM 的生成物。

这些空白的存在本身，在实务上就很重要。如果有人断言「研究表明 RAG 比微调好 X%」，请问一句：那个 X 是用哪种微调、在什么数据上测出来的。

结语

这个问题的常见答案之所以没用，不是因为它错，而是因为它无法用于决策。「要最新信息就 RAG」没错，但我无从知道我的问题是否属于这种情况。

只留下测量过的东西，图景就整理成这样。微调不是知识注入工具 — 这一点在多篇论文中被反复确认，看起来相反的案例研究测的是另一种干预。长上下文在位置、长度、词汇三条轴上各自崩塌，大多数模型的实际极限比广告上的窗口尺寸小一个数量级。RAG 和长上下文在大多数查询上本来就给出同样的答案 — 按 Self-Route 的测量，63% 完全相同。而这一切数字所依赖的基准，其三分之一到三分之二的问题不给上下文也能解。

所以实务的答案不是去读更多的基准测试，而是亲手画出那一条曲线。你的语料库、你的 50 个问题、改变 k 测 recall。在小 k 饱和就用 RAG；一路涨到头就考察长上下文，但要确认模型在那个长度上扛得住；到头也不涨，就别怪检索，回头重新审视问题定义。

先有问题，才有工具。而那个问题的性质，不写在别人的论文里，只写在你的数据里。