把答案放在上下文中间，模型就会漏掉吗？一次提前停止的对照试验

把资料塞进请求，并不意味着模型一定能利用里面的每一条事实。问题是：当模型没找到答案时，怎样区分资料位置、资料缺失与请求本身失败？

这次先把问题收窄成一个可核对的任务：从一组虚构项目记录中，返回指定项目的交接编号。对同一份资料，仅移动含答案的那一行，再加入完全没有答案的对照。

结果先说清楚：计划 48 次，实际尝试 29 次。26 次正常返回均符合预期，接着连续 3 次 HTTP 429 触发停止。剩下 19 次未执行。 这是一轮未完成的试验；没有观察到已返回样本答错，不等于已经证明位置无关。

查看工程与复现说明 · 逐次请求与响应记录 · 实验档案

1. 先排除一个混淆：缓存不是证据

上一份 KV Cache 拆解讨论了“请求提供什么”与“推理怎样复用计算”的区别。这里不讨论模型记住了上一次对话什么：每次请求只有固定 system 和当前 user，没有历史问答。

服务返回的 cached_tokens 也不能说明答案来自长期记忆。它不是本轮的自变量，更不能代替对完整请求内容的检查。

本轮的灵感来自 Lost in the Middle：该论文在其所评测的任务与模型上报告，相关信息所处位置可能影响表现。我们的任务、模型、材料长度与样本规模均不同，不能把这轮小试验称为论文复现。

2. 构造一个答案可独立核对的任务

示例事实是：

虚构项目记录：松塔试验项目的交接编号为 QX-7319。

六个项目名称与编号全部是人为生成的实验材料，不对应真实企业或设备。期望答案来自冻结的 cases.json，不由另一个模型评分。

每份上下文包含 60 行干扰记录。它们也带有项目标识和形似 NX-4000 的编号。目标事实不能仅凭“全文唯一一个编号”被找出来，模型需要匹配问题中的项目名称。

三个含答案条件使用同一组 61 行资料，只移动目标行：

条件	目标行位置（从 0 开始）	其他材料
beginning	0	相同的 60 行干扰记录
middle	30	相同的 60 行干扰记录
end	60	相同的 60 行干扰记录
absent	没有目标事实	用一行无关记录代替目标事实

问题始终放在资料后面。因此实验改变的不只是行号，也改变了目标事实与最终问题的距离；不能声称已经分离出某个注意力机制的作用。

absent 用来检查没有证据时是否拒答。该条件的替代句与事实句并非精确等长，故它是缺失对照，不是另一组严格等长的位置条件。

3. 请求、评分和预算怎样冻结

本轮配置为 Agnes 的 agnes-2.5-flash、temperature 0、max_tokens 512。请求约为 4298–4301 个 UTF-16 字符，这里统计的是序列化后的请求 JSON，包含提示、字段与材料，绝不是上下文 token 长度。

代码和材料先提交，再发请求。运行清单记录代码版本、JDK 版本及输入 SHA256。完整的 48 项顺序保存在 plan.json，使用固定 seed 20260928 打乱条件顺序。

• 6 个事实 × 4 个条件 × 2 次重复，共 48 次上限。
• 顺序调用，不自动重试。
• 连接超时 10 秒，读取超时 90 秒。
• 连续 3 次请求或协议失败即停止。
• 接口正常返回后，先检查 assistant 和 finish_reason=stop，再评分正文。

读取超时限制单次阻塞读取，不是整个请求的硬截止时间。temperature 0 也不能保证托管服务每次位级一致。

评分不依赖主观“差不多对了”：

正文	有答案条件	absent 条件
精确期望编号	correct	incorrect（无证据猜测）
UNKNOWN	abstention	correct_abstention
另一个合法编号	incorrect	incorrect
解释段落或其他格式	format_error	format_error

正文评分前只移除首尾空白，不自动抽取编号或修复回答。HTTP 429、协议异常、网络失败走另一条路径，不会计入模型答错。记录中 transport_error 是较宽泛的程序分类，要结合 errorCode 读；本轮三个错误均为 http_429。

4. 真正观察到了什么

执行时间为 2026-09-28 15:52:59 至 15:56:38 UTC。逐条重算后的结果如下：

条件	计划	已尝试	正常返回	其中正确答案／正确拒答	HTTP 429	未执行
beginning	12	8	8	8	0	4
middle	12	8	6	6	2	4
end	12	7	6	6	1	5
absent	12	6	6	6	0	6
合计	48	29	26	26	3	19

前 26 次请求有有效输出；第 27–29 次返回 429，随后程序停止。429 的具体限额原因未从记录确认，不推断为余额不足，也没有换密钥绕过限制。

有答案的 20 份返回均匹配编号；6 份 absent 返回均为 UNKNOWN。它们是条件于正常响应的观察值。由于两次重复属于同一组材料，26 份响应也不是 26 个独立难题。

返回的 usage 累计为 prompt_tokens 74,476、completion_tokens 2,567、total_tokens 77,043。这个和只覆盖带 usage 的响应，不是账户账单，也不包含未返回 usage 的请求的未知消耗。

5. 为什么不能据此宣布“中间位置没问题”

这里至少有五个限制。

1. 试验没有跑完。 组间样本量不平衡，停止后不能将剩余项补成成功或失败。
2. 任务可能太容易。 六组资料结构规则，答案短，问题要求精确匹配；不等于多文档推理或长篇自然文本。
3. 材料并不长。 请求字符数不是 token 数，更不意味着覆盖了模型的长上下文能力边界。
4. 单次托管模型配置。 没有比较其他模型、模型快照、不同服务负载或其他温度。
5. 不能归因到内部机制。 最终答案不暴露模型如何寻找证据，不足以解释注意力分配。

因此本轮可以说的是：在这份固定短材料、已正常返回的样本中，三个位置都出现了正确检索，缺失对照出现了正确拒答。目前没有足够证据比较位置差异大小。

这也说明，实验没有出现预期中的错误，并不是白做。它帮助识别了下一轮需要提高的任务难度，以及请求可用性这个必须单独记录的因素。

6. 从代码到证据，怎样自己核对

工程放在 Java 仓库的 experiments/01-context-position，而不是混进博客前端。它与 Demo 04 共用 Java 8 / Gson 的技术基础，但研究问题不同。

进入目录后先执行不访问 API 的检查：

mvn -q compile
mvn -q exec:java -Dexec.args=--self-test
mvn -q exec:java -Dexec.args=--dry-run

92 项离线断言覆盖目标唯一性、位置、材料一致性、无答案泄露、评分及预算。另一个可选的 Node.js 审计脚本独立读取已保存记录：

node audit.mjs evidence/20260928-l1

它重算每个请求 hash、实际字符数、条件组合、正文评分与停止条件，再核对 summary.json。Gson 将温度保存为 0.0，审计时保留这个序列化差异，避免把“JSON 语义一样”误当成“请求字节一样”。

需要重新实测时，自行设置 AGNES_API_KEY 后，使用新的输出目录：

mvn -q exec:java "-Dexec.args=--run evidence/my-run"

这条命令最多发送 48 次计费请求。不要覆盖旧证据，也不要把新协议的结果拼回这一轮。密钥只从进程环境读取；仓库没有保存请求头、密钥或推理正文。

7. 下一轮先改什么

下一轮需要先重新约定协议：加入合理的请求间隔与明确的 429 处理策略，再增加材料长度和自然文本干扰。保持同一案例的条件配对，并把“是否收到完整响应”与“完整响应是否正确”分开统计。

只有当这些条件稳定后，比较开头、中间、末尾才有解释空间。本轮不继续追加请求去追求一个更好看的完成数；现有 29 份记录已经足够公开说明方法、观察和边界。

如果你从 Java 入门文章一路读到这里，可以用三个问题检查自己的理解：答案到底有没有进入请求？请求有没有成功返回？返回答案是否有证据支持？ 这三个问题要分别回答。