RAG 与长上下文
两条路线的性能取舍与路由式混合方案选型依据
核心要点：
- 两条路线都解决"给模型喂大量外部信息"，一个检索片段、一个全塞窗口
- 资源充足时长上下文准确率更高，但有效长度被严重高估
- RAG 在成本、延迟、知识库规模、实时更新上有硬优势
- 主流不是二选一，而是路由式混合（Self-Route / Pre-Route）
- 决策看知识库规模、查询类型、成本预算、更新频率
本文讲 RAG 与长上下文的取舍与混合，不展开 RAG 检索器/embedding/重排的内部机制（那是 RAG 工程专题）。RAG 检索到的长文档若仍超窗口，可先做输入压缩再喂模型。
RAG 和长上下文在解同一个问题吗？
是——两者都在回答"模型如何用上训练时没见过的大量外部信息"，只是路径相反。 RAG（检索增强生成）先从知识库检索相关片段，只把片段喂给模型；长上下文则把整批文档直接塞进扩大的 context window，让模型自己在全文里找。
- RAG：外部知识留在库里，按需检索 → 输入短，但依赖检索召回质量。
- 长上下文：外部知识全进窗口 → 不漏检索，但输入长、成本高。
所以在"读长文档/多文档问答/知识库 QA"这类场景，RAG 和长上下文是一道选择题，而非互补。
长上下文一定更准吗？
资源充足时长上下文准确率普遍高于 RAG，但"有效上下文长度"被严重高估，长输入下准确率会断崖。
正面对比上长上下文领先：Google 的系统研究中，长上下文比 RAG 在 Gemini-1.5-Pro 上高 12.4pp、GPT-4O 上高 16.1pp[1]；另一项 13,628 题的评测中长上下文 56.3% vs RAG 49.0%[2]。
但 NoLiMa 评测揭示这种领先有前提[3]：13 个声称支持 128K+ 的模型里，11 个在 32K 长度时准确率已跌到短上下文基线的 50% 以下，GPT-4o 从 99.3% 跌到 69.7%。根因是 attention 在缺乏字面词汇匹配时难以可靠定位信息——长上下文的"宣称长度"不等于"有效长度"（评测细节见 09-评测与现状）。Databricks 的测试也显示部分模型超出饱和点后性能显著下降[4]。
成本、延迟、扩展、更新：RAG 强在哪？
长上下文赢在准确率，RAG 赢在系统经济性——成本、延迟、知识库规模、实时更新四项全面占优。
| 维度 | RAG | 长上下文 |
|---|---|---|
| 准确率（资源充足） | 受检索召回质量限制，偏低 | +12-16pp，但有效长度被高估 |
| 单请求 token / 成本 | 低，只喂检索片段 | 高，全量塞窗口 |
| 延迟（TTFT） | 低，输入短 | 高，prefill 随输入 token 线性增长 |
| 知识库规模 | 无理论上限（向量库/倒排索引） | 受 context window 硬约束（当前约 2M） |
| 知识更新 | 实时 / 增量 | 每次请求重传全量文档 |
| 工程复杂度 | 高，需维护检索栈 | 低，直接塞窗口 |
@tbl-longctx-rag-compare RAG 与长上下文的多维对比
成本与延迟的量级差距尤其大：检索片段只有数百到数千 token，而全量长上下文动辄百万 token，单请求成本相差数个数量级；prefill 的 $O(n^2)$ 也让长上下文的 TTFT 远高于 RAG（02-第一性挑战）。对高频更新的知识库，长上下文每次重传全文的成本不可接受。
不二选一时怎么混合？
业界 2024-2025 的共识是路由式混合——用便宜的 RAG 兜住多数查询，只在 RAG 答不好时才升级到昂贵的长上下文。
| 方案 | 类别 | 机制 | 收益 |
|---|---|---|---|
| Self-Route[1] | 路由 | 先跑 RAG，模型自判能否回答，不能则升级到全上下文 | 约 57-77% 查询由 RAG 兜住（按模型），token 降至长上下文的 38-61%，准确率接近纯长上下文 |
| Pre-Route[5] | 路由 | 检索前基于文档元数据用推理链决策走哪条 | 路由准确率最高 0.84（Self-Route 0.52），长上下文调用率 33%→20%，可蒸馏到 1.7B 小模型 |
| LongRAG[6] | 检索改造 | 检索单元从 ~100 token 扩到 4K token，语料压缩 30×，配长上下文 reader | NQ recall +19pp、HotpotQA +25pp，免训练 |
| OP-RAG[7] | 检索改造 | 保持检索块在原文中的顺序，不按相关性打乱 | 呈倒 U 型曲线；Llama3.1-70B 用 48K token 达 F1 47.25，超过全上下文 117K token 的 34.26 |
| retrieve-then-read + 长上下文 reader[8] | reader | top-k 文档填进长上下文窗口做整体阅读/列表精排 | 免训练强基线，可替代 cross-encoder 重排器 |
@tbl-longctx-rag-hybrid RAG 与长上下文的混合架构
两个反直觉发现值得注意：
- Self-Route[1]：被动路由就能在准确率几乎不降的前提下省下约 40-60% token——多数查询其实 RAG 就够。
- OP-RAG[7]：检索量并非越多越好，存在最优点（倒 U 型），而保持原文顺序的中等检索量反而胜过把全文塞进窗口。
怎么选？决策框架
先看知识库能否装进窗口、是否高频更新，再按成本与查询类型细分。
| 场景 | 推荐 |
|---|---|
| 知识库 ≤ 窗口（如 64K）且静态 | 纯长上下文（最简单） |
| 知识库远超窗口 或 高频更新 | 纯 RAG（硬约束决定） |
| 中间地带 + 成本敏感 | Self-Route / Pre-Route 路由 |
| 文档顺序对答案重要 | OP-RAG |
| 超大规模语料 | LongRAG |
| 单跳事实查询 | RAG 足够 |
| 多跳 / 全局聚合推理 | 长上下文偏好 |
@tbl-longctx-rag-decision RAG / 长上下文 / 混合的决策框架
Takeaway
| 知识点 | 核心结论 |
|---|---|
| 同一问题 | RAG 与长上下文都解决"喂模型外部长信息"，检索片段 vs 全塞窗口 |
| 准确率 | 资源充足时长上下文 +12-16pp，但有效长度被高估，长输入下断崖 |
| RAG 硬优势 | 成本、延迟、知识库规模、实时更新四项占优 |
| 混合是主流 | Self-Route/Pre-Route 路由：RAG 兜底，长上下文兜难题 |
| Self-Route | 多数查询走 RAG，省约 40-60% token，准确率近纯长上下文 |
| OP-RAG | 检索量倒 U 型，保序中等检索胜过全文塞窗口 |
| 决策主轴 | 知识库规模 + 更新频率 + 成本 + 查询类型 |
@tbl-longctx-rag-takeaway 全文要点
参考资料
- Li et al., Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach, EMNLP 2024 Industry Track. https://arxiv.org/abs/2407.16833 长上下文 vs RAG 准确率对比，提出 Self-Route，token 降至长上下文的 38-61%（按模型）。
- Li et al., Long Context vs. RAG for LLMs: An Evaluation and Revisits, 2025. https://arxiv.org/abs/2501.01880 13,628 题规模评测，长上下文 56.3% vs RAG 49.0%。
- Modarressi et al., NoLiMa: Long-Context Evaluation Beyond Literal Matching, ICML 2025. https://arxiv.org/abs/2502.05167 11/13 模型在 32K 跌破短上下文基线 50%，GPT-4o 99.3%→69.7%。
- Databricks, Long Context RAG Performance of LLMs, 2024. https://www.databricks.com/blog/long-context-rag-performance-llms 多模型在不同 context length 的性能降点测试。
- Route Before Retrieve: Activating Latent Routing Abilities of LLMs (Pre-Route), 2025. https://arxiv.org/abs/2605.10235 检索前主动路由，路由准确率 0.84，长上下文调用率降至 20%。
- Jiang et al., LongRAG: Enhancing Retrieval-Augmented Generation with Long-context LLMs, 2024. https://arxiv.org/abs/2406.15319 检索单元扩到 4K token，语料压缩 30×，NQ/HotpotQA recall 大幅提升。
- Yu et al., In Defense of RAG in the Era of Long-Context Language Models (OP-RAG), 2024. https://arxiv.org/abs/2409.01666 保序检索的倒 U 型曲线，48K token F1 47.25 超过全上下文 117K 的 34.26。
- Jin et al., Long-Context LLMs Meet RAG: Overcoming Challenges for Long Inputs in RAG, ICLR 2025. https://arxiv.org/abs/2410.05983 retrieve-then-read 系统研究，检索重排为免训练强基线。