AI 知识
上下文窗口科普：标称 1M tokens 的模型实际能用多少
各家模型都宣传几十万到上百万 token 的上下文，但有效容量、注意力质量与计费都会打折。这篇文章把上下文窗口的常见误区一次讲清。
- 发布时间
- 阅读时长
- 2 分钟
- 来源
- —
「1M 上下文」已经是新模型的标配宣传语。但把一百万 token 塞进去，和这一百万 token 都被模型有效利用，是两回事。这篇按「是什么、差在哪、怎么办」的顺序讲。
上下文窗口是什么
简单说，它是模型单次对话能「看见」的全部内容长度上限：系统提示词、历史对话、检索进来的资料、你的提问，全部加在一起算。超了就要截断或压缩，通常丢的是最早的内容。
标称容量 ≠ 有效容量
长文本评测里有个经典现象叫「迷失在中间」：放在上下文中部的信息，被正确利用的概率明显低于头部和尾部。也就是说，塞满 100 万 token 不等于模型对每个细节都一样敏感。实践中比较稳妥的假设是：把标称容量打折扣看待，关键信息要么放开头，要么放开头和结尾各一份。
长上下文的三个隐性成本
- 计费档位：不少厂商对超过阈值（常见 200K 上下）的请求按更高档位计费，单价可能翻倍。
- 延迟：输入越长，首 token 响应越慢，对交互式应用影响明显。
- 注意力稀释：无关内容越多，模型对关键内容的把握越差，输出质量会悄悄下降。
实用策略
多数场景不需要硬吃长上下文。常用的四类办法：
| 场景 | 建议做法 |
|---|---|
| 知识库问答 | 检索（RAG）取最相关片段，控制在数万 token 内 |
| 长文档分析 | 先分段摘要，再基于摘要提问 |
| 持续会话 | 定期压缩历史，保留结论丢掉过程 |
| 大代码库 | 按文件/模块按需加载，而不是整仓塞入 |
选型时怎么看这个指标
把上下文窗口当成「上不封顶的容量保险」来理解比较合适：日常任务几十 K 足够，超过 200K 的需求先想想是不是该用检索。站内 模型库 可以按上下文窗口筛模型，配合自己的任务量级选就行。