超级管理员
楼主
现在的模型动不动就支持 100 万 token 上下文。但实际用过的人都知道，标称长度和好用长度之间，差着十万八千里。
真相一：中段遗忘（lost in the middle）是真实存在的。
大量测试都指向同一个现象：模型对上下文开头和结尾的内容记忆最好，对中间部分的召回明显下降。你把一份 300 页的文档整个塞进去，然后问一个只有第 150 页能回答的问题，它很可能答不上来，或者给出看似合理但错误的内容。
应对方法：
- 重要的信息放在开头或结尾，不要埋在中间。
- 长文档先做结构化处理，给每部分加标题和小结。模型对有结构的文本召回更好。
- 不要指望一次塞进去解决所有问题。分段处理再汇总，可靠性通常更高。
真相二：成本是线性的，效果是递减的。
上下文每增加一倍，成本大约也增加一倍。但效果不是——信息越多，信噪比越低，模型的注意力被稀释。把 10 万 token 的相关资料和 90 万 token 的无关资料一起喂进去，结果通常比只喂那 10 万要差。
应对方法：
- 先检索，再填充。这是 RAG 的核心思路，也是长上下文场景下依然正确的做法。
- 设定上下文预算。给每类任务定一个上限，超出就说明检索环节没做好。
- 定期清理对话历史。多轮对话里，早期的内容往往已经无关了。
真相三：注意力不等于理解。
模型「看到」了某段内容，不代表它正确使用了这段内容。尤其是当上下文里有互相矛盾的信息时，模型未必能做出正确判断，反而可能被误导。
应对方法：
- 不要在上下文里放互相冲突的材料。如果必须放，明确标注哪个是最新最权威的。
- 关键结论要求模型给出依据位置，然后自己核一遍。
- 对结果做验证，尤其是涉及数字、日期、版本号的。
什么时候该用长上下文，什么时候该用 RAG：
适合长上下文：
- 单次任务需要通读全文（总结、对比、找出矛盾）。
- 材料总量可控，比如几十页的文档。
- 需要理解文档内部结构和逻辑关联的任务。
适合 RAG：
- 知识库远大于上下文窗口。
- 每次查询只涉及其中一小部分。
- 需要引用来源、可追溯。
- 知识频繁更新。
两者结合才是常态： 用检索把候选范围缩小到几万 token，再用长上下文能力做深度理解。这不是二选一。
一个务实的建议： 别把长上下文当成「不用做检索了」的理由。它是检索之后的工具，不是替代检索的方案。真到了必须塞 100 万 token 才能解决问题的地步，先想想是不是任务拆解方式有问题。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。