大模型的卡片上写着上下文 128K，很多人立刻换算成十二万汉字，然后整本小说往里塞。这个换算从头就是错的。
误区一：128K token 就是十二万汉字
错在哪：把 token 和汉字按一比一换算。token 是分词后的碎片，中文一字常常占一到两个 token，英文一个词可能只占一个 token，数字和代码的切分又另有一套。128K token 装中文，实际字数远到不了十二万。
正确说法：换算比例取决于模型的分词器，中文场景下 128K token 大致对应几万字符，用模型自带的计数器估才算数。具体换算问题可以看token 数等于字数的误区。
误区二：窗口塞满等于句句被读到
错在哪：以为窗口是硬盘，装进去就原样存着。实际上注意力机制对长序列的分配会衰减，排在中间和后面的内容，被注意到的权重可能明显低于开头。
正确说法：长文档要做切片和分层摘要，把关键信息提到显眼位置。指望一口气塞满就得到完整理解，结果往往是细节丢失。
一个可操作的检查办法：把文档里的关键事实分别藏在开头、中段和结尾，各问一次。如果三段都能答对，说明窗口利用良好；如果中段开始出错，就该换成分段喂入的策略，而不是继续加长窗口。
窗口大小的宣传口径也不统一。有的标的是总上下文，有的把提示和回复分开算，还有的按「有效长度」报。对比不同产品时，先确认口径一致，否则数字不可比。Kimi 以长文档能力被大家讨论，豆包、腾讯元宝的窗口规格也写在各自的产品文档里，用之前先查清口径。
误区三：开头的内容一定记得最牢
错在哪：默认模型对开头有压倒性优势。位置对注意力的影响并非单调，中间段的信息有时反而更容易被忽略，具体表现和模型架构、训练数据分布有关。
正确说法：别赌位置，要主动设计。重要结论放开头，论据放中段，结尾再总结一遍，这符合模型的读取习惯，也是稳妥的工程做法。
三个位置的表现不同，处理方式也该不同。
| 文档位置 | 注意力表现 | 稳妥做法 |
|---|---|---|
| 开头 | 通常是系统提示和任务说明，模型靠它定方向 | 放关键指令与重要结论 |
| 中段 | 权重可能明显低于开头，中间段信息有时反而更容易被忽略 | 放论据，提问时把要点复述一遍 |
| 结尾 | 当前问题在这里，模型围着它生成答案 | 再总结一遍，把问题放在结尾 |
| 全文一次塞满 | 塞进去不等于句句被读到，中段开始出错 | 换成分段喂入或两级摘要 |
上下文长度还和单价绑在一起。窗口开得越大，单次请求可计费的 token 上限越高，很多平台按实际使用量计费，但也有按窗口档位收费的。选型时把「窗口档位」和「实际用量」一起看，才不会为用不到的长度付钱。
还有一个折中方案是「两级摘要」：先把长文按章节摘要，再把摘要拼起来问整体问题。牺牲一点细节，换来稳定的覆盖度，多数场景下比硬塞原文更可靠。多数平台也提供上下文占用的可视化，提交前就能看到还剩多少余量，值得用起来。
工具层面也能帮忙。给长文档配一个「定位问答」流程：先问模型第几章讲了什么，再顺着章节往下追，比直接问全文细节准确得多。分段喂入时保留章节标题，模型更容易建立结构感。
- 128K token：装中文约几万字符，不是十二万字
- 窗口：塞得满不等于读得全
- 位置：中间段可能被忽略，别赌排序
- 姿势：切片、提关键、结尾再总结
窗口大小还受部署条件制约：量化能省显存，也就影响了能开多长的窗口，可以看Q4 量化的常见误区；不少轻量版本会配更小的窗口，可以对照蒸馏版的常见误解理解。
关于上下文窗口的三个常问问题
- 上下文越长模型就越强吗？：窗口是能力的一部分，但有效利用长窗口同样依赖切片策略和提示设计，不是堆长度就有效。
- 为什么同样的文档，两个模型反应不同？：分词器和注意力实现都有差异，能塞进去的量和读出来的细节都会不同。
- 超长文档的正确姿势是什么？：先切片，再逐段提问或摘要，最后汇总，比一次性塞满更稳。
