上下文窗口是真的吗：一条"针"测出截断与摘要

上下文窗口是模型规格里最容易虚标的一项。原因很简单：标 200K 不需要成本，真的支持 200K 需要显存和推理优化。中转站如果在中间做了截断、摘要或分段，你从表面上完全看不出来——请求成功，输出通顺，只是它没读到你放在中间的内容。

一、为什么测"中间"

长上下文模型的注意力在开头和结尾最强，中间最弱。这是公开研究里反复出现的现象（"lost in the middle"）。所以：

• 把针放在开头，几乎都能答对，测不出问题。
• 把针放在结尾，也容易答对。
• 把针放在中间偏前（约 22.5%），能同时测出"截断"和"注意力衰减"。

本站检测台的第三项检查就放在约 22.5% 位置，上限 6 万字符，避免请求本身太大导致超时。

二、具体怎么做

1. 准备一段填充文本（不要用重复字符，模型会识别出重复并跳过）。
2. 在开头写一句控制指令："记住编号 QX-7421。"
3. 在约 22.5% 处插入一句："这里的编号是 QX-7421。"
4. 结尾提问："开头提到的编号是多少？"

如果模型答对，说明它至少读到了开头和中间。如果答错或说"没有提到"，说明中间被截断或摘要了。

注意：针要放在自然文本里，不要单独一行加粗，否则模型可能把它当成标题跳过。

三、三种常见的"造假"方式

1. 硬截断

超过某个长度直接切掉，只保留前面 N 个 token。表现是：针放在 30% 之后，永远答不出来。

2. 摘要压缩

中间部分被总结成一段短文本。表现是：问细节答不出，问大意能答出。这种最难发现，因为它不是"失败"，而是"降级"。

3. 分段检索

把长输入切成多段，只把最相关的段喂给模型。表现是：问整体结构能答，问具体位置的具体内容答不出。这类实现常见于"支持 1M 上下文"的站点。

四、判读标准

第四种最危险：它给出一个看起来合理的编号，但和你放的完全不一样。这说明模型在猜，而不是在读。所以针的内容要足够随机（例如 QX-7421），不能是"123"这种模型会随口编的。

五、多测几个位置

单点只能说明"这个位置有问题"。要画出一条曲线，至少在 10%、22.5%、50%、75%、90% 五个位置各测一次。

如果一个模型在 10% 和 90% 都对，只有 50% 错，这是注意力衰减，属于模型本身的特性。如果 50% 之后全错，这是截断，属于服务端的问题。

六、成本的考虑

长上下文测试很贵：一次 100K token 的请求，按 Claude 的价格约 0.3 美元。所以不要天天跑。

建议：

• 换新站时跑一次，确认声明的窗口不是虚的。
• 换模型时跑一次，确认同一家站对不同模型的处理一致。
• 出问题时跑一次，作为证据。

不需要定期跑。上下文能力不会一夜之间变化，除非站点换了上游。

七、本站怎么做的

检测台的第三项检查会：

1. 先发一个短的控制请求，确认模型能正常工作。
2. 再发一个带针的长请求，针在约 22.5% 位置，总长不超过 6 万字符。
3. 比对回答里是否包含针的编号。
4. 给出 PASS / WATCH / FAIL，并附上实际用的字符数和回答片段。

这项检查会消耗较多 token，页面上有提示。如果你的 Key 余额不多，可以先跳过这项，只跑前两项。

八、一句话总结

上下文窗口不是一个数字，是一个"在多深的位置还能准确取回信息"的曲线。标称值只是上限，有效值要靠针测出来。