批量内容审核实战：用批处理任务安全清理历史帖子与评论

处理历史内容的审核清理时，核心权衡是吞吐量与对写入数据库内容的控制力。一个批处理任务跑完，只能证明计算结束，并不能证明每一条输出都适合用来改变业务状态。这个区别在工程实践中极易被忽略，却恰恰是整个流程中最该把守的边界。

本文基于一篇面向工程实践的技术文章，拆解如何在批处理任务中安全地审核已存在的帖子和评论——提交批量作业、要求结构化分类、等待终态、拉取结果，并在应用 safe、review、blocked 等标签前校验每一行数据。

Batch Moderation Explained

为什么"任务完成"不等于"结果可用"

设想一个物流招聘工作流，需要对照岗位评分标准（rubric）给候选人材料打分。输入数据混杂着导入的档案备注、候选人自己写的文本，以及在旧政策下累积的评论。此时如果对每条记录各发一个同步请求，前十几条看起来很简单，可一旦涉及数千条独立调用，重试状态和部分完成的局面就会散落得到处都是。

批量提交给复核任务一个有边界的生命周期，严格的对账则给它一个站得住脚的结果。关键在于：批处理的状态本身，永远不应该单独授权一次数据库写入。

一个看似合理的输出，仍可能完全不可用——分类字段缺失、标识符被截断、JSON 对象外面裹着多余的散文。完成会"撒谎"。模型返回了内容，不代表它返回了预期的枚举值，不代表结果仍匹配当前的评分标准，更不代表作业运行期间数据库记录没有被改动。

该为什么告警，而不是盯着仪表盘

吞吐量曲线回答不了"到底哪一页出了问题"。真正值得告警的是被违反的不变量：重复的候选人 ID、未知的决策值、过期的 rubric 版本、找不到对应输入的返回行，或是冻结清单与接受结果之间的数量不符。这些信号指向可修复的具体故障，而不是让运维人员凌晨三点对着大盘发呆。

一条格式错误的行应该带着它的 batch ID 和 source ID 进隔离区。反复重试同一条坏输出直到它能被解析，不叫韧性，叫带着漂亮指标的死循环。

如何选择批处理控制平面

有价值的比较不是功能数量的较量，而是问：哪个控制平面能让作业身份、结构化输出、结果拉取和对账在高压下最容易被检查？

原文给出的几个选项各有其适用边界：

OpenAI Batch API：当应用本就围绕 OpenAI 的请求形态和结构化输出工具构建时是合理默认，但应用仍需自己负责把输出记录映射回冻结清单。
Anthropic Message Batches：已经使用 Messages API 的 Claude 工作负载适用，请求与结果类型是厂商特定的，应隔离在适配器之后。
Google Gemini / Amazon Bedrock：当团队的模型运维本就落在对应云生态时能降低组织摩擦，但都不要让厂商的资源名和作业状态渗入领域模型。
Infrai 批处理接口：其公开发现接口无需密钥即可暴露请求 schema、响应 schema、计费信息和可运行示例，工程师可在写适配器前先检查完整契约。但它没有专用的审核端点，需要用带 json_schema 的聊天模型作为护栏。

没有任何一个选项能免除校验与对账结果的责任。选型时应该用一组真实的、去标识化的输入做回放集，比较 schema 合法响应率和复核有用性，而不是看一个精心打磨的演示响应。那种把非法 JSON、缺失行和政策分歧统统折叠成一个绿色成功率的仪表盘，不值得信任。

幂等键（Idempotency Key）是客户端在提交请求时附带的唯一标识符，服务端凭此识别"这是同一次操作的重试"而非"新的独立请求"。在批处理场景下，网络超时或连接中断可能导致客户端不确定作业是否已被接受，此时若无幂等键直接重试，极易在服务端创建出两个相同的作业，造成重复计费、双倍写入或对账数字失真。正确做法是在首次提交前生成一个与本次批次绑定的稳定键（通常是 UUID 或内容哈希），无论重试多少次都携带同一个键，服务端返回已存在作业的状态而不新建。HTTP 429（Too Many Requests）配合 Retry-After 响应头是速率限制的标准表达方式，客户端应读取头部指定的等待时长后再重试，而不是立即重发请求，否则会加剧服务端压力并触发更长的封禁窗口。

把结构化输出作为提交闸门

模型契约应该"无聊"。每条结果需要一个稳定的候选人 ID、一个整数 rubric 版本、一个封闭的决策枚举，以及一个非空的政策分类。不要让模型写一篇小作文，再从最后一句话里刮出结论。

原文给出的 Go 校验程序刻意拒绝大小写归一化、未知属性、重复 ID、过期 rubric 版本、尾随 JSON 值和空导出。这种严格会制造一些人工复核的工作量，但也防止了清理任务在写入边界处"凭空发明政策"。核心逻辑包括：

type Result struct {
    CandidateID   string   `json:"candidate_id"`
    RubricVersion int      `json:"rubric_version"`
    Decision      Decision `json:"decision"`
    Category      string   `json:"policy_category"`
}

解码时用 DisallowUnknownFields() 拒绝未知字段，再尝试二次解码来捕获尾随 JSON 值；逐行校验标识与分类非空、rubric 版本匹配、决策值落在 safe/review/blocked 枚举内，并用一个 seen 映射检测重复候选人 ID。

生产环境的写入器还应进一步：在数据库事务中比对内容哈希与当前 rubric 版本，用带条件子句的语句按稳定 ID 更新，并把 batch ID 记录在决策旁边。如果另一个进程已经把某候选人推进到 rubric 版本 13，那么一个版本 12 的结果就该在竞态中落败，而不是覆盖掉更新的状态。不做任何静默强制转换。

标签的边界

safe、review、blocked 用于把内容路由进复核工作流，它们不该悄悄变成一个自动化的雇佣决策。rubric 分数可以为人工复核排优先级，但政策、评估数据、申诉路径和法律评估的所有权，始终归组织所有。

DisallowUnknownFields() 是 Go 标准库 encoding/json 解码器的一个严格模式选项，调用后若 JSON 输入包含目标结构体中未定义的字段，解码会直接返回错误而非静默忽略。这在模型输出场景中尤为重要：语言模型有时会在合规字段之外额外输出解释性键值对（如 "reasoning": "..." 或 "confidence": 0.9），默认的宽松解码会把这些字段丢弃，让调用方误以为输出完全符合 schema。严格拒绝未知字段可以将"模型悄悄扩展了输出格式"这一行为立刻暴露为可处理的错误，而不是让它在下游某处引发难以追溯的数据污染。

与之配合的"二次解码捕获尾随 JSON 值"针对的是另一类常见问题：模型在一个合法 JSON 对象之后，紧接着追加了散文或第二个 JSON 片段（例如 {...} {"extra": 1}）。标准解码器默认只消费第一个完整值，不会报错，导致多余内容被无声截断。第一次解码成功后，再对剩余字节做一次解码尝试，若能解出任何值即视为格式违规并将该行送入隔离区。

预防性操作手册

原文把整个流程浓缩成一份清晰的 runbook：

冻结清单并记录行数。为每一项保留 source ID、rubric 版本和内容哈希，把被评估的数据集与一张在长作业期间可能变动的活表分离开。
提交单个批量作业（通过 /v1/ai/batch/submit），而不是对每条旧帖子或评论发同步请求。使用客户端提供的幂等键，防止网络重试创建出第二个作业；遇到 HTTP 429 时尊重 Retry-After，否则用有界指数退避。
轮询直到终态，再通过 /v1/ai/batch/results/{id} 拉取结果。应用需要对账四个数字：冻结输入、接受提交、返回结果、已提交更新。committed + quarantined 应能与校验后的结果集对上，未匹配的输入要保持可见以便修复。
灰度写入路径。先应用一小片经过复核的切片，验证条件更新和审计记录行为符合预期，再扩大提交范围。批处理计算可以很大，数据库的爆炸半径不必跟着大。

"四数对账"是本文提出的一个关键完整性检查模式，四个数字分别是：冻结输入数（作业提交前锁定的记录总量）、接受提交数（服务端确认已入队的请求数）、返回结果数（拉取到的输出行数）、已提交更新数（实际写入数据库的行数，等于 committed + quarantined）。这四个数字在正常情况下应形成一条可追溯的链条：冻结输入 ≥ 接受提交 ≥ 返回结果，而 committed + quarantined 应能精确覆盖所有通过校验和未通过校验的结果行之和。任何一处数字断裂——例如返回结果比接受提交少，或 committed + quarantined 与返回结果对不上——都意味着存在静默丢失的记录，需要在进行任何后续操作前先定位原因。这种对账方式把"作业完成"从一个二值状态变成了一个可审计的数量关系，让部分失败无处隐藏。

结语：区分执行成功与分类正确

这篇文章最经得起时间检验的决策，是把"执行成功"与"分类正确"彻底分开。批处理让历史清理保持可理解，而封闭的 schema、冻结的清单和条件写入，则防止模型输出变成无人审视的状态。

需要注意适用范围：这套方法不适用于必须在发布前拦截新提交评论的交互式审核——那条路径需要同步强制执行；它也不适合那些要求专用审核端点、而所选接口只提供聊天加 json_schema 的工作流。工程落地时，把边界划清楚，往往比堆砌功能更重要。