长上下文与 RAG：窗口越大，检索越没用了吗

先给结论：窗口越大，检索不是越没用，而是越「专」了。截至 2026-10-29，主流前沿模型普遍提供百万级上下文窗口，Anthropic 官方文档甚至已把 1M 窗口列为多数模型的默认配置并按标准定价计费；但同步积累的评测证据表明，模型「能有效利用」的上下文远小于「能装下」的上下文，而全量直塞的成本与延迟在语料规模面前很快失控。事实层面的分工越来越清楚：窗口解决「读得下、读得透」，检索解决「找得到、找得起」——本系列前几篇讲的 Embedding、Reranker、查询改写，解决的都是后半个问题。下面按「进展 — 成本 — 分工 — 决策」四步展开。

窗口狂飙：三年从 8K 到千万级

长上下文的窗口竞赛速度惊人：

三年里窗口上限涨了三个数量级。「RAG 已死」的说法正是在 2024 年初 Gemini 1.5 Pro 公布百万窗口后开始流传，代表观点如研究者符尧所称「长文本正在取代 RAG」；Databricks 也在 2024 年末的研究里给出边界条件——语料小于 128K token（Gemini 为 2M）时，可以跳过检索直接全文进窗口。

宣称的窗口，不等于有效的窗口

问题在于，宣称窗口是「能塞进去」的上限，「用好」是另一回事。

• Lost in the middle（Liu 等，2023）：把相关信息放在上下文开头或结尾时性能最高，放中间则显著下降，呈 U 形曲线；作者结论是「当前语言模型并不能稳健地利用长输入中的信息」。
• RULER（NVIDIA，2024）：用 13 个任务测「有效上下文长度」，以 Llama2-7B 在 4K 的成绩为及格线。结果：GPT-4 宣称 128K、有效 64K；Yi-34B 宣称 200K、有效 32K；ChatGLM-6B 宣称 128K、有效仅 4K；LWM 宣称 1M、有效不足 4K。
• NoLiMa（Adobe Research，2025）：去掉「针」与「问题」之间的字面重合，逼模型靠语义关联找信息。13 个宣称 128K 以上窗口的模型里，11 个在 32K 时就跌破短文本基线的一半；即便是表现最好的 GPT-4o，也从 99.3% 掉到 69.7%。
• Context Rot（Chroma，2025）：18 个模型（含 GPT-4.1、Claude 4、Gemini 2.5、Qwen3）在「重复抄写」这类最简单的任务上，性能仍随输入变长持续退化；问题与线索的语义相似度越低，退化越快。把 113K 的全量输入聚焦成 300 token 左右的相关片段后，所有模型成绩都明显更好。

值得注意的是，这些不是 RAG 厂商的一面之词：传统「大海捞针」测试的高分依赖字面匹配，而 RULER、NoLiMa、Context Rot 分别来自 NVIDIA、Adobe Research 与向量库厂商 Chroma，结论互相印证；Anthropic 官方文档如今也直接写明「更多上下文并不自动更好」（context rot）。我的概括是：宣称窗口衡量显存与架构，有效窗口衡量注意力质量，两者常差一到两个数量级。

论战现场：双方各看到了什么

「RAG 已死」不是一句玩笑，而是一场持续两年的正面交锋。主张方——如研究者符尧「长文本正在取代 RAG」的判断，以及 Databricks「语料小于 128K 可跳过检索」的结论——看到的是窗口上限的涨速远超索引技术的改进速度：为「找得到」付出的切块、嵌入、检索链路，在百万窗口面前可能只是过渡期的工程债。反对方——向量数据库厂商 Zilliz 与 Elasticsearch、以及微软 OP-RAG 论文的作者——看到的则是另一组事实：数十万 token 的单次推理延迟以数十秒计；检索的成本优势随请求频次持续放大；倒 U 形曲线说明塞得越多未必答得越好。到 2026 年，双方立场实际已在合流：长上下文质量占优但更贵，RAG 便宜且可控，混合路由可以两全——SELF-ROUTE 的数据是这一共识最早的定量注脚。我的判断是，这场争论的真正产出不是谁埋葬谁，而是把「何时该检索」从立场之争变成了可以量化的工程决策。

一笔成本账：塞得下，不等于读得起

第二笔账是钱和时间。注意力计算量随序列长度平方增长，KV 缓存随每个历史 token 线性膨胀——长上下文不是「一次付费、随便读」，而是每次请求都按全量长度重新计费、重新计算。

定价层面，「跨过 200K 触发长上下文加价」曾是行业惯例：

Databricks 算过一笔更直观的账：单次 128K token 的查询输入，Gemini 1.5 Pro 约 $0.16，GPT-4o 约 $0.32，o1-preview 高达 $1.92——这还只是一次提问。对照 RAG：建好索引后，每次请求只需把几千 token 的检索块送进窗口。两种方案的成本结构对比：

要如实补充另一面：加价正在退潮（Claude 1M 已转标准定价），提示缓存又能把重复前缀的成本砍掉一大截。但 Anthropic 官方文档同时提醒：缓存只改变付费方式，不减少窗口占用，长前缀的显存压力与首字延迟一分不少。所以这笔账的准确读法不是「长上下文贵得用不起」，而是成本差距在缩小、但结构劣势仍在——语料规模越大、请求频次越高，检索摊薄成本的优势就越明显。

混合架构：窗口管精读，检索管找得到

性能与成本两条线放在一起，答案自然指向混合。关键研究都指向同一个形态：

• SELF-ROUTE（EMNLP 2024）：充足资源下，长上下文平均确实优于 RAG（Gemini-1.5-Pro 高 7.6%，GPT-4o 高 13.1%）；但让模型先自评「检索片段够不够答」，够就把查询路由回 RAG，结果在性能基本持平的前提下省下 39%–65% 的成本——Gemini 上有 81.74% 的查询根本不需要全量长文。
• OP-RAG / In Defense of RAG（微软，2024）：随着塞入内容增多，答案质量先升后降呈倒 U 形；按原文顺序保留少量相关块的检索增强，用远少于全量的 token 反而拿到更高质量。
• Elastic 实测：不经过滤、把海量内容直接灌进大窗口，效果劣于先用检索过滤再生成。

工程上的分工因此清晰：小库精读用长窗口，大库与跨源靠检索，智能体用检索为窗口瘦身。单篇长文档的精读、一次代码评审、百页以内的语料，直接进窗口免索引，全局视野是检索给不了的；万级文档、多部门权限、时效性数据，则必须走检索。智能体场景里，两者协作更紧：用检索把历史对话和工具结果压缩成小片段，把宝贵的有效窗口留给当前任务，Anthropic 官方文档推荐的上下文编辑与压缩正是这个思路（智能体侧的展开见本系列 Agentic 检索一篇）。

flowchart TD
    Q["用户问题进来"] --> A["查询分析与改写"]
    A --> B{"语料规模与问题类型"}
    B -->|"小语料：单文档或百页内"| C["免索引：整篇进长窗口精读"]
    B -->|"大语料：多来源、高频访问"| D["混合检索：向量加关键词多路召回"]
    D --> E["Reranker 重排，取前 K 块"]
    E --> F{"检索片段够不够答"}
    F -->|"够"| G["窗口内生成答案"]
    F -->|"不够，需全量细读"| H["按需扩窗：相关章节整段进窗口"]
    C --> G
    H --> G
    G --> I["附引用溯源，返回用户"]

决策清单：什么场景选什么

常见误区

误区一：窗口大等于能全读。NoLiMa 显示多数模型 32K 就把短文本基线丢了一半，RULER 里宣称 1M 的模型有效长度可能不足 4K，Context Rot 连抄写任务都不放过。把百万窗口当百万有效注意力用，是当前最贵的误解。

误区二：检索过时了。窗口解决的是「读」，检索解决的是「找」：海量语料装不进任何窗口；权限、审计、溯源、增量更新是窗口天然做不了的工程需求；高频请求下全量直塞的账单结构也不成立。Zilliz 的类比准确：大内存的发展并不意味着硬盘的淘汰。

误区三：大海捞针满分等于长文能力。传统的大海捞针测试靠字面重合就能拿高分，NoLiMa 证明一旦要求语义关联，成绩立刻塌方。看长上下文评测，先看它有没有去掉字面捷径。

最后回到标题的问题：窗口越大，检索没有越没用，而是从「替模型读全文」退到「替模型省注意力、省成本」——这是分工的深化，不是某一方的葬礼。

参考资料

1. Lost in the Middle: How Language Models Use Long Contexts — 「中间迷失」现象的原始论文，位置 U 形曲线的出处。
2. RULER: What's the Real Context Size of Your Long-Context Language Models? — 有效上下文长度的系统测量，宣称与有效差距的量化证据。
3. NoLiMa: Long-Context Evaluation Beyond Literal Matching — 去掉字面匹配后长上下文成绩的塌方现场。
4. Context Rot（Chroma Research） — 18 个模型在简单任务上的长输入退化报告。
5. Long Context RAG Performance of LLMs（Databricks） — 「语料小于 128K 可跳过检索」与单次长查询成本数字的出处。
6. RAG or Long-Context LLMs? A Comprehensive Study and Hybrid Approach — SELF-ROUTE 混合路由，长上下文性能优势与成本账的对照实验。
7. In Defense of RAG in the Era of Long-Context Language Models — 倒 U 形质量曲线与按序检索反超全量直塞的证据。
8. Gemini API 官方定价页 — 「超 200K 整单按高档计费」的第一手定价证据。

本文为技术科普，不构成选型建议的唯一依据。