标准回答
长上下文的代价
超长上下文能把更多资料直接塞进 prompt，省去检索系统，简单直接。但它有几个硬伤：注意力存在「迷失在中间」现象，处于上下文中部的信息容易被忽略；推理成本随上下文长度上升，长文档每次调用都很贵；窗口再大也有上限；而且塞进去的知识是静态的，无法实时更新、也难溯源。
RAG 的互补价值
RAG 按问题按需检索，只把最相关的片段喂给模型，token 消耗小、延迟可控；底层知识库可随时增删改，支持实时更新与超大规模语料；返回片段带来源，便于 grounding 与引用核查。代价是整体效果强依赖检索（embedding、分块、rerank）的质量，召回不准会直接拖垮回答。
实践结论
不是「有了长上下文就不要 RAG」，而是结合使用：先用 RAG 把候选范围缩小到高相关片段，再放进（适度的）长上下文窗口让模型综合推理。选型看知识规模、时效要求和成本预算——知识海量、更新频繁、要可溯源就更靠 RAG。
常见误区
⚠️ 常见踩坑
别认为「窗口够大就能无脑全塞」——既贵又受 lost-in-the-middle 影响，且无法解决知识时效与溯源；也别把 RAG 当万能，检索质量差时长上下文反而更稳，需按场景权衡。
追问
追问 1：什么场景更适合长上下文而非 RAG？
单一文档内的深度推理、需要全局连贯理解（如长篇代码库审阅、整本合同对比、跨段落推理）且文档量可控、不要求实时更新时，长上下文更直接，避免分块切断语义。知识海量、频繁更新、要溯源的场景则更适合 RAG。
追问 2：如何缓解长上下文的「迷失在中间」问题？
把最关键信息放在上下文开头或结尾、用结构化标记和摘要突出重点、对长文档先做压缩/重排序只保留高相关段落（本质又回到检索），以及选用经过长上下文专门训练、位置编码改进的模型，都能减轻中段信息被忽略。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。