发布时间：2026-10-09T04:00:01.177Z
各家模型把上下文窗口越做越长，百万token成为宣传标配。但长上下文的计算成本、检索效率、注意力稀释都是现实问题，实测聊聊真正适合的场景。 长上下文是模型厂商最爱宣传的参数之一，百万token窗口已经成了旗舰标配。宣传归宣传，实际用起来，长上下文的价值和限制都要说清楚。 先算算百万token是什么概念。大概相当于几百页文档，或者几十万字的中文内容。理论上，把整本书、整年的聊天记录、一整个代码仓库都塞进一次对话是可能的。这个能力的宣传价值很足。 但真实使用有代价。第一是成本，上下文越长，每次调用的计费越高，百万token输入一次的成本是普通对话的几十倍。第二是速度，超长输入的处理时间明显变长，交互体验变差。第三是质量，注意力机制在超长序列上会“稀释”，模型对文档开头和中间的内容记忆变差，只对最近输入的部分敏感，这就是常说的“大海捞针”问题。 实测的感受：一万token以内，模型对上下文的利用基本充分；十万token级别，开头内容开始被遗忘，需要主动提及才能引导模型注意；百万token级别，多数场景下模型真正有效利用的只有尾部一小部分。 所以长上下文的正确用法不是“全塞进去”，而是配合检索：先把大量资料做索引，检索出相关片段喂给模型。这个思路叫RAG，它的效果在超长场景下反而比硬塞全文更好，成本也低得多。 什么时候长上下文真有用：处理需要全局理解的单一长文档，比如整本合同的审阅、长代码库的理解，这时候塞全文比检索更合适。什么时候别用：知识库问答、海量文档分析，老老实实上RAG。 选模型的时候，别把百万token当唯一指标，结合自己的任务类型看：单文档深度处理看上下文长度，多文档综合分析看检索能力。参数表里数字好看，不如实际任务跑得准。