128K 上下文实际能用多少：打个六折再算

三个吃掉窗口的东西

第一是输出。多数模型的输入加输出不能超过窗口，你让它写三千字，输入就得留出位置。

第二是历史。多轮对话每轮都把前面重发一遍，聊二十轮，历史就占了几万 token。

第三是系统提示词和各种插件说明。有些产品默认塞了一大段，你看不见，但它占额度。

所以有效输入大约是标称值的六到七成。按这个数做规划，比按标称值靠谱。

把一份长文档给模型，问开头的内容，它答得准；问结尾的，也还行；问正中间的，经常含糊。

注意力分配本来就不均匀。文档越长，中间段落在整个上下文里占的权重越低。

应对办法有两个：把关键信息挪到开头或结尾；或者先分段摘要，再基于摘要问。后者更稳，代价是多花一次调用。

判断一份材料要不要分段，看两个数：总长度，和打算问几个问题。长度超过五万 token 且问题超过三个，分段几乎一定更准。只问一个问题，整份塞进去反而省事。

按长度计价的话，一次塞十万 token 和分十次各塞一万，总输入量一样，但单次价格可能不同，延迟差更明显。

塞得越满，首字返回越慢。要即时反馈的交互场景，长上下文会直接毁掉体验。

还有命中率问题：塞得越满，它挑中正确段落的概率越低。材料不是越多越好，无关内容会把要找的那一段淹没。

一个实测经验：同样的材料，删掉三成无关段落再给，答案的准确率反而更高。前提是你能判断哪些无关。

补充一句分块策略比窗口大小更影响效果。按小节切、每块带标题、检索时按标题过滤，比硬塞一整本效果好。

单份合同：两三万字，加上追问，准备五万 token 的余量就够。

一整本技术手册：直接放弃整本塞，改成建索引后检索。

一整月的会议记录：先按会议分别摘要，再做月度汇总。一次性塞进去，它给你的结论会很空。

一条经验：超过窗口一半的材料，先想怎么切，别想怎么塞。

窗口越大是不是越好？

对一次性的长文档分析是。对日常问答没意义，还更贵更慢。为偶尔一次的需求买大窗口，不划算。

为什么它说读了全文，但答案只覆盖前半部分？

它确实收到了全文，但注意力不均匀。让它按章节逐段输出摘要，再合并，覆盖率会明显提高。

分段之后前后文丢了怎么办？

每段带上标题和所属章节，必要时把上一段的结论作为下一段的背景。切片要保留结构信息，不能只按字数切。