为什么夜间任务输出总漏掉文档最后三分之一？

为什么一个夜间摘要任务，产出的摘要读起来信心十足，却总是忽略每份文档的最后三分之一？没有崩溃，没有触发重试，队列到早上就清空了，唯一的症状是有人发现第九段根本没进输出。有人用48小时追这一类bug，最后发现有用的不是修复本身，而是任务被允许离开本机之前先跑的那个探针。

先换个角度看，问题才变得可解。多数团队只给模型的输出加监控，从不监控模型实际收到的输入。如果网关裁掉了长提示、丢了系统消息，或者悄悄截断了对话历史，日志里显示的仍是你发出的请求，而不是被服务的请求。于是问题变成：只用你手上已有的端点，怎么证明载荷完整到达？

没被测量的失效模式

静默截断之所以难缠，是因为它降低质量却不降低可靠性。错误率保持为零，p95延迟看着健康，结构化JSON照样能解析——它只是在回答一个比你提问更短的问题。重试会让情况更糟，因为每次重试都重发同一份超大载荷，又在同一位置被重新截断。

值得区分三种变体，因为每种需要不同的补救：

• 尾部截断：提示的结尾被切掉，最后的指令或收尾上下文消失。
• 头部或系统消息丢失：系统消息被丢弃或被摘要掉，语气和输出契约随之漂移。
• 中部截断：模型看到开头和结尾，却丢了中间，这是肉眼最难察觉的一种。

分词器库告诉你你以为的预算是多少，它不会告诉你服务路径做了什么。这两个数字恰恰在你最需要的时候分道扬镳。

金丝雀：两个随机token加一份JSON契约

这个探针刻意做得很无聊。在系统消息里放一个随机token，在用户消息最末尾再放一个，然后要求模型把两者原样回显成JSON。如果头部金丝雀回来了、尾部没回来，就是尾部截断；如果系统金丝雀消失，说明有东西吃掉了系统提示。

探针把max_tokens故意设得很低。你只为四个token的回显付费，不是为答案付费，所以探针便宜到可以在每次模板变更时都跑一遍。

判定结果分四种：两个都回来说明正常；只有尾部回来是系统消息丢失；只有头部回来是尾部被切；两个都没回来则两者皆失。

用翻倍法校准预算，而不是靠猜

探针在短载荷上跑通后，用经验方法找有效上限。从一个小样本开始，把填充内容翻倍，在第一个非正常判定处停下。这个转折点才是真正在意的数字，它是服务路径的属性，不是分词器版本的属性。

把同一轮扫描连跑两次做对比。如果相同尺寸下两次运行的判定结果翻转，说明端点负载均衡在异构后端之间，此时应把边界钉在观测到的最低上限，而不是平均值。

免费额度在这一步确实派上用场。有免费模型访问和免费服务器选项，才能反复跑翻倍扫描而不必惦记花费——当端点是付费的时候，这种扫描本身就是刻意浪费的。

48小时现场计划

两天被切成四块，只有最后一块碰生产代码：

1. 第0至2小时，基线。在500字符的样本上跑探针。如果这一步就失败，停下：问题在请求契约，不在截断。
2. 第2至10小时，扫描并记录。跑翻倍扫描，把首次失败的尺寸和判定结果写入文件，用提示模板的哈希作为键。
3. 第10至36小时，回放真实输入。从日志里取十份真实载荷，按真实尺寸喂给测试装置，max_tokens仍然设低，记录判定。发丝级的案例会在这里冒出来，通常表现为对仅略微超限文档的尾部截断。
4. 第36至48小时，接入守卫。加一个预检，模板哈希变化时重跑一次探针，并拒绝把载荷超过已记录上限的批次入队。

判定结果只有映射到凌晨两点你愿意执行的动作才有用。五种情况里只有一种真的和token有关，另外两种是更大的预算永远修不好的契约bug——这正是靠分词器计数去猜会浪费大量时间的原因。

局限，以及谁该跳过

要诚实说明金丝雀的适用范围。它证明载荷完整到达、输出契约存活，但对答案质量、幻觉率、延迟一无所知。它也无法可靠检测中部截断，因为两个哨兵都能存活，而提示的中心被丢弃。

以下情况大概应该跳过这套方法：

• 载荷始终远低于上限，没有截断可抓。
• 已经掌控服务栈，能直接读取分词器和截断配置。
• 端点出于安全原因会剥离或改写随机token，判定会变得嘈杂而非有信息量。
• 需要的是质量回归测试，那属于评测装置，不是金丝雀。

如果命中其中任何一条，把这两天花在黄金集评测上，让这个探针只当五分钟的冒烟测试，而不是一个项目。

值得重复的两件事：一是在碰应用代码之前先跑扫描，因为它产出一个可以据以设防的数字，而不是一个怀疑；二是把记录的上限绑定到提示模板的哈希，这样一次粗心的编辑会让测量失效，而不是悄悄活得比测量更久。

要改的是顺序：下次会先写系统消息丢失那个分支，因为系统消息被丢掉的样子，和模型不再遵循指令一模一样，为此曾把几个小时浪费在责怪模型上，而真正缺的是自己的载荷。

当提示里的最后一条指令悄悄从未到达，你的任务会怎么做？如果无法从已经保留的日志行里回答这个问题，两个token的金丝雀是一种便宜的办法，能在读者发现之前先知道答案。