上下文窗口扩展到 100 万 token 时，哪些现有业务场景会发生质变？

先说会发生质变的场景

当窗口从几万扩到 100 万 token，最直接的变化是“一次性把整个材料喂进去”从不可能变成可行：

• 整本书 / 长文档分析：几百页的书、超长合同、研究报告可以整篇放进上下文做问答、摘要、条款比对，不必先切块再拼；
• 整库代码理解与重构：把一个项目的大量源码同时放入，模型能在全局视野下回答“这个函数被谁调用、改了会影响哪里”，做跨文件重构和审查；
• 海量日志 / 数据排查：把大段日志、监控数据一次性给模型定位异常，而不是人工先筛；
• 超长会话记忆与多轮 Agent：助手能记住极长的对话历史和工具调用轨迹，长程任务里不容易“失忆”；
• 跨大量文档的综合：同时纳入几十份文档做横向对比、归纳，模型能看到全貌而非检索回来的零散片段。

这些场景的共同点是：信息需要被整体看待，过去靠分块 + 检索拼接，丢失全局关联；现在可以直接整体输入。

它对 RAG 意味着什么

长上下文弱化了对 chunk 式 RAG 的依赖——当材料本身不大（一本书、一个仓库），直接全量喂入比“切块—向量化—检索—拼接”这条链路更简单、也更少因检索召回不全而漏信息。但这不是全面替代，原因有三：

1. 成本与延迟：输入越长，token 成本和首字延迟都显著上升；把百万 token 全塞进去处理一个小问题极不划算，RAG 只取相关片段反而更快更省；
2. 知识规模：企业知识库可能是 TB 级、且持续更新，远超任何窗口，必须靠检索从外部库里捞；RAG 还便于增量更新和数据隔离；
3. 精准与可控：RAG 能给出明确的引用来源、做权限过滤、控制喂给模型的内容，可解释性和可控性更强。

“大海捞针”这个坑

长窗口不等于长窗口里每个位置都被“读懂”。实测中存在 lost in the middle（中段信息丢失）现象：放在开头和结尾的信息更容易被准确利用，中间部分的细节容易被忽略。所以“塞得进”不代表“用得好”，关键信息的摆放位置、必要的结构化与提示仍然重要——这也是上下文工程要解决的问题。

结论

百万 token 让“整体输入”的场景发生质变，长上下文与 RAG 不是谁取代谁，而是按场景分工、长期共存：材料有限、要全局理解时用长上下文；知识库庞大、要精准可控可溯源、要省成本时用 RAG；很多生产系统会把两者结合——先检索缩小范围，再用长窗口承载更完整的上下文。