批处理结果按位置拼接，近六成标签错配
作者将 Claude 批处理返回结果按位置与输入配对，导致 5000 条数据中 2940 条标签错配，类别分布统计却未暴露问题。修复关键是用稳定主键设置 custom_id，并增加逐条真值核验。
原文暂未完整获取，基于公开信息的快读
一批客服工单的标签分布看起来正常，逐条核验却暴露了错配。dev.to 作者分享了一次 Claude 批量标注事故：他们把返回结果按位置拼回输入，导致 5000 条数据中 2940 条标签挂到了错误工单上。基于这批标签训练的分类器，差点被上线。
目前能确认什么
据作者提供的节选，Claude Message Batches API 的结果顺序不保证与提交顺序一致，文档要求通过 custom_id 关联请求。作者虽然设置了这个字段，读取结果时却丢掉了它，最终用 zip(tickets, labels) 按位置配对。
代码还先过滤了 14 条失败结果。即使返回顺序恰好正确，删除中间项也会让后续配对错位；zip 又会按较短列表结束，剩余工单便静默漏标。
类别分布正常，不能证明标签贴对了样本。
标签列被打乱后，各类别的数量和比例仍可保持不变。作者另行人工标注了 200 条工单，核验时发现一致率只有 41.5%，才追查到关联逻辑。这里要区分：结果位置改变，不一定造成标签错误，不同工单可能恰好属于同一类。
我的判断
对做批量标注、内容分类或离线评测的程序员，这件事最直接的提醒是：把返回结果当作需要按键关联的数据表。请求时用稳定主键设置 custom_id，回收时按键写入，并检查重复、缺失和未知 ID；失败项也应保留对应身份，进入明确的处理分支。
验证则需要两层：ID 核对检查关联是否完整，独立人工真值集检查标签是否正确。只从同一批自动标注数据切出验证集，无法充分证明标签可靠。
节选中的修复代码尚未展示完整，错误、过期、取消结果如何重试，以及重试后如何避免重复写入，都还没说清。能借鉴的是主键关联和逐条核验原则，不能据此认定完整流水线已经处理好了这些边界。