长上下文与 RAG：谁更好，要看条件

比较两种方案，要同时看质量和成本；结论只到测过的模型、任务和预算为止。

这一页为什么在这里

第四站的第三个决策点：长上下文和 RAG，谁更好？2024 年的一项系统比较给出了一个带条件的答案：资源充足时长上下文平均更好，RAG 便宜得多；混合做法用不到四成的 token 就接近长上下文；换一个窗口小的模型，排序就变了：混合反而最好。带走的判断：质量和成本一起看，改变结论的条件要写出来。

第 1 步：表（2024；LongBench 与 ∞Bench 的平均分；RAG 每题取 5 段、每段 300 词）：模型（窗口）｜长上下文｜RAG。Gemini-1.5-Pro（窗口 100 万）49.7｜37.3。一行：资源充足时，长上下文平均更好。
第 2 步：加一列“混合：先 RAG，模型自认答不了再换长上下文”与“混合用的 token（长上下文＝100%）”：46.4｜38%。一行：63% 的问题，两种做法的预测一字不差。
第 3 步：加一行 GPT-3.5-Turbo（窗口 1.6 万）32.1｜30.3｜35.3｜39%；标注：这一行混合最好。一行：改变结论的条件：模型（窗口多大）、任务、预算。

先比较质量

2024 年有一篇比较研究：资源够的时候，长上下文的平均表现比 RAG 好。

表格 Gemini-1.5-Pro 一行的 49.7 与 37.3。

加入成本与混合路线

但把成本放进来，RAG 便宜得多。作者最后提了一个混合办法：先检索，模型判断材料不够时，再换成长上下文。在 Gemini-1.5-Pro 上，混合只用了长上下文不到四成的 token，分数从 49.7 降到 46.4。

新出现的混合得分和 token 用量两列。

改变结论的条件

换成窗口只有 1.6 万的 GPT-3.5-Turbo，混合反而最好。所以“谁更好”没有一句话的答案，要看模型、任务和预算。读这类比较的习惯是：先看它比了什么、花了多少，再看结论能推到哪。

GPT-3.5-Turbo 一行高亮的 35.3，以及两种窗口条件。

这么一来，“这一次放什么进托盘”就成了要专门设计的事。

2024 年有一篇比较研究：资源够的时候，长上下文的平均表现比 RAG 好。

设置（Li 等，2024）。 在 LongBench 与 ∞Bench 的长文本任务上，比较同一个模型的两种用法：长上下文（整篇材料放进窗口）与 RAG（每题检索 5 段、每段 300 词放进输入）。指标是各数据集分数的平均。

结果（表 1）。 Gemini-1.5-Pro：长上下文 49.7，RAG 37.3。资源充足时，长上下文平均更好；但 RAG 的输入短得多，成本低得多。

混合（Self-Route）。 先用 RAG，让模型判断“凭这些材料能不能回答”；答不了的再换长上下文。Gemini-1.5-Pro 上得 46.4，只用了长上下文 38% 的 token。依据是一个观察：63% 的问题，两种做法给出的预测完全一致，这些题用 RAG 就够了。

换一个模型。 GPT-3.5-Turbo（窗口约 1.6 万 token）上：长上下文 32.1，RAG 30.3，混合 35.3（用 39% 的 token），这一行混合最好。窗口小的模型装不下全文，长上下文的优势就小了。

带走的判断。 “长上下文还是 RAG”没有脱离条件的答案：模型（窗口多大、长文本能力多强）、任务（信息是否集中、是否要综合全文）、预算（token 成本）都会改变结论。一个可复查的比较，要写清提供了哪些材料、花了多少资源、用什么指标。

注意口径。 这里的数都取自原文表 1；正文 §4.3 另有不同汇总方式的数，不要混用。

教学构造：表格的排法与“改变结论的条件”一行是课件做的。
Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach：Li 等，EMNLP 2024 Industry Track；数值取 arXiv 2407.16833v2 表 1（LongBench 与 ∞Bench 平均；RAG 取 5 段、每段 300 词；Self-Route 的分数与 token 比例；63% 预测一致）。作者报告，来源支持；不混用 §4.3 的汇总值。