无人值守流水线应限制提示词自改

无人值守的 LLM 批处理一旦失败，该不该让模型自己改提示词？作者的答案是：运行时只能在人工事先批准的方案里调整，失败反馈也必须来自固定模板。否则，一次自动重试就可能把未经审查的新逻辑送进生产流程。

这篇文章的价值在于把两件事分开了：控制模型调用过程，与保证模型答对。作者提出的控制器能限制长度、调用次数和修改范围，但收据提取实验也暴露了一个问题：验证器太宽松，通过率再高，也可能交付错误结果。

自动重试可以调整什么，边界由谁决定

作者把人工批准的任务配置包叫作 envelope，可以理解为某个任务版本的执行边界。里面包含不可变规则、允许的步骤图、可选计划、失败反馈模板，以及尝试次数、超时、提示词长度和同类失败重复次数等限制。人按版本批准这个包，不用逐条审核运行时生成的提示词。

每条记录先从包里组装提示词，再调用模型，由确定性验证器返回通过或失败检查 ID。通过就接受结果，记录提示词哈希；失败则按失败类别写入模板指令。同一类别出现新失败时，替换旧指令，而不是继续追加。

这里的 ledger 是一份按类别更新的失败记录。它保留当前需要修正的问题，不保存越积越长的聊天历史。

提示词布局也有约束：稳定指令放在 system role，原始文档每次保持逐字节一致；只有计划、失败记录和简短提醒可以变化，而且都必须来自 envelope。

单条记录触及尝试上限、重复失败或重复计划阈值，或者出现未批准计划、提示词超限，就触发熔断，转向有限的兜底方案。每个兜底项最多执行一次，不能回到主循环，全部失败后交给人工。另一个批次级断路器监控异常队列比例，以及已接受结果抽样中的漏检错误，必要时暂停整批任务。

在签名校验和部署假设成立时，控制器能提供三个保证：提示词长度有上限，单条记录一定结束，计划与反馈不会越出批准范围。

这三个保证约束的是执行过程，不是答案质量。

原始文档中的恶意指令仍需数据标记规则和验证器处理。作者没有宣称解决了提示词注入，人工也仍要审核版本、处理异常记录和抽查通过结果。

收据实验修好了什么，又没证明什么

试验使用 CORD v1，数据集采用 CC BY 4.0 许可，出自 Park 等人在 NeurIPS 2019 workshop 的工作。任务提取九个金额字段和菜单行。模型看到的是从词框重建的文本，没有看到收据照片。「干净记录」仅指所有参考值都在文本中原样出现，不代表字段容易判断。

模型是本地量化的 qwen3-8k，temperature 为 0.3，上下文为 8192 tokens。控制器、单次调用和朴素重试共享 envelope、模型与温度，种子分别为 0、1、2。朴素重试只是重发相同提示词，不携带失败指令。

envelope v2 要求按票面复制，生成上限为 512 tokens。在前 100 条干净训练收据上，三个种子都留下相同的六条异常记录，控制器一条也没救回来。第二次加入的指令与首次要求重复，没有提供新的修正信息。

作者检查这六条后才编写 v3：两条因菜单过长导致 JSON 截断，另外四条涉及带 @ 的单价、同时打印单价和行总价，以及把标签一起复制，例如把 5.000 写成 Total Rp 5.000。v3 将生成上限提高到 1024 tokens，并收紧模板；它有新的哈希，在运行前重新批准。

同样的 100 条训练记录，v3 全部通过。其中五条旧失败在每个种子下都被第二次的模板反馈修复；另一条截断菜单在提高生成上限后首次就通过了。train-00103 还出现了连锁问题：较大的上限先暴露出被截断掩盖的菜单原文错误，第二次反馈才修好它。

使用相同 v3 配置的朴素重试没有救回那五条。这个结果支持「重试需要新增有效信息」，却不能证明类型化模板比任何额外提示都好。作者没有测试「只传失败检查 ID」和「追加完整失败输出」这两个对照。

84 条未用于编写 v3 的干净测试收据上，控制器异常率为 2.4–3.6%，即 2–3 条；单次调用与朴素重试均为 7.1–9.5%，即 6–8 条，且两者在每个种子下的异常记录集合一致。配对精确检验的 p 值为 0.0625–0.125，未达到 0.05 的显著性门槛；只有四到五对结果不一致，样本不足以确认或排除真实差异。还有两条测试记录在所有控制器种子下都失败了。

方向值得继续验证，结论还不能写成「泛化有效」。

为什么全部通过，仍然可能大量出错

验证器的标准很松：金额去掉货币符号和千位分隔符后，只要在收据某处出现就通过；菜单名只检查是否为子串。它没有实现算术校验，因此把税额填到总额里，也可能过关。

训练样本中，v2 抽取的 14 条已接受记录，有 11 条与 CORD 标注不一致，Wilson 95% 区间约为 52–92%；v3 则为 10/14，区间约为 45–88%。人工检查同样的 14 条 v3 记录，判错 8 条，区间约为 33–79%。

测试集里，作者取一个控制器种子按运行顺序得到的前 14 条已接受记录，全部至少有一个字段与标注不一致。即便是 14/14，其区间下界仍约为 78%。这不是随机抽样，也没有人工复核，不能直接当成整个测试集的错误率；但足以说明验证器通过和提取正确相距很远。

接受率首先反映验证器放行了多少结果，不能直接替代准确率。

长度方面，首次提示词约 388 tokens，第二次约 506–653 tokens，远低于 8192-token 窗口。长度限制几乎没有受到压力。作者没有运行追加完整失败历史的对话式基线，因此实验没有证明它在长文档或长度竞争中占优。原先设定的规则遵循对照和人工投入上限实验也没有按定义完成。

我的判断

我认可作者把「运行时调整」限制在预审范围内。对输出直接进入代码处理的批任务，这能明确哪些变化可以自动发生，哪些变化必须进入版本审核。模型即使不听话，也不能让外部控制器失去次数和长度边界。

但 envelope 的收益要和维护成本一起看。写得太窄，合理修复也被挡住；写得太宽，审批又可能流于形式。作者没有统计编写耗时，也没有固定计划、只改变 ledger 来测试，无法拆清计划选择和反馈模板各自贡献了多少。

常见替代方案「固定提示词加严格验证器」仍然值得先做。如果它已经够用，运行时切换计划只会增加维护面。当前实测支持的是：重复相同提示词修不好这些系统性失败，人工检查后写出的具体反馈能修好已观察到的问题。至于类型化形式是否更优、能否降低总人工成本，仍缺少对照数据。

能拿来做什么

• 在 Node 批量提取或文档处理任务中，把提示词、失败模板、调用上限和兜底方案一起版本化，记录版本哈希，让异常结果能追溯到具体配置。
• 将失败反馈按字段或规则类别保存，同类问题覆盖旧反馈，并设置总尝试次数和单次超时，避免任务反复携带整段输出继续重试。
• 验证结构化输出时，同时检查字段归属和业务关系。例如金额出现在原文中，只能证明它有出处，还需要判断它是否属于目标字段，以及相关金额能否对上。
• 给已接受结果保留抽样复核。调整模板后，用未参与修改的样本比较固定提示词、相同提示词重试和模板反馈重试，把通过率、错误率与人工投入分别记录。