长上下文能力是模型越长越好吗？工程和成本上的代价是什么？

先这样答

不是免费升级，每一项能力背后都是真金白银。计算量：标准注意力的计算量随序列长度平方增长，上下文从 4K 扩到 128K， naive 实现下注意力开销涨了上千倍。显存：KV 缓存的大小和序列长度成正比，长上下文并发服务时显存先爆。精度：模型对超长输入中间部分的利用率下降，关键信息埋在中间时召回变差，这就是所谓 lost in the middle 现象。延迟：prefill 阶段要处理完整个输入才能出第一个 token，长输入直接拖慢首字响应。

工程上的应对分模型内和模型外两层。模型内：稀疏注意力减少无效 token 参与，KV 缓存量化压缩显存，滑动窗口加少量全局注意力兼顾局部和远程依赖。模型外：不让模型硬吞长文档，先做分层检索，粗筛出相关段落再送模型，模型上下文留给真正需要推理的内容；对话历史用滚动摘要压缩，老内容降密度保留。

产品层面的正确姿势是「按需长上下文」：常规请求走短上下文的高效路径，只有确实需要全量知识的任务才展开长输入，并且对长输入单独计价。

面试官会怎么追问

• 「lost in the middle 怎么缓解？」 输入组织上，把关键信息放头尾这些模型注意力强的位置；工程上，长文档先检索后生成，让进入上下文的都是高相关内容；提示词上，明确指路「根据第几部分回答」帮助模型定位。
• 「KV 缓存压缩有哪些做法？」 量化到低精度、淘汰注意力分数低的 token、把老段的 KV 合并池化。要说明各自的精度代价，量化有失真风险，淘汰错了会丢信息。
• 「业务上什么时候真需要长上下文？」 整本书问答、超长代码库的跨文件理解、几小时的会议转写分析、法律合同的全局一致性检查。判断标准是「任务结论依赖跨距离信息的关联」，只是输入长但答案在局部，用检索就够了。

回答的坑

• 把上下文长度当营销数字念。能讲清平方复杂度和 KV 膨胀的代价，才算懂推理成本。
• 遇到长输入就想着塞满上下文。先检索后生成是默认正解，长上下文是补充手段不是首选。