游戏举报审核该选哪个LLM接口？先定错误底线再谈延迟

做游戏内举报分类的 Node.js 聊天机器人，选 LLM 接口的顺序常常被搞反了。真正该先问的不是"哪家模型最强"，而是"这条审核路径能容忍的最坏分类错误是什么"，然后再测延迟能不能塞进人工复核队列。

换句话说，接口选型是一份路由契约：普通举报走快速第一遍，证据模糊的走更严格的路径，模型没法给出有依据的标签时，明确返回"弃权"。一份打磨得漂漂亮亮的对话补全结果，不是审计记录。队列本身才是产品。

要防的失败长什么样

一条游戏内举报通常包含一段短消息、一个截图引用，以及玩家自己选的分类。分类器只做三种操作结果：让举报继续排队、转给高级审核员、触发别处定义的即时安全策略。它不是最终裁判——这个边界很关键，因为一个自信但错误的标签，可能在人工看到证据之前就改变了玩家账号状态。

主要失败模式不难列举，难的是别太晚才发现：

• 低延迟模型漏掉隐晦骚扰，产生假阴性；
• 高质量模型耗时太长，流量高峰时复核队列越堆越长；
• 重试导致审核事件重复，因为 worker 没有幂等键；
• 供应商超时被记成策略决定，而不是基础设施故障；
• 提示词改版改变了标签分布，却没有评测跑出来暴露它。

最后一条容易被当成提示词维护的小事，其实也是存储问题。系统只保留最新标签，就没有持久办法解释同一份举报为何在部署后分类不同；当审核员对边界案例提出异议时，这段缺失的历史最刺眼。

在这个工作流里，质量和延迟是耦合的。阈值属于游戏自己的策略和复核容量，不该从厂商示例里抄，也不该因为某张基准表好看就定下来。

接口先于品牌

分类器需要：对阻塞实时工作流的举报提供同步请求；对积压处理提供有边界的异步路径；能校验的结构化输出；以及把每次尝试关联到同一个审核事件的办法。一个接口如果在队列截止时间内给不出可靠答案，它的原始质量对那条路径毫无意义。

一层薄适配器能让服务其余部分不依赖这些细节。适配器应返回带类型的决定或操作性错误，绝不能悄悄把超时转成"升级"或"放行"。在 Node.js 里，这层边界可以放在 fetch 或某个 SDK 后面，但持久化和错误规则必须一致：按 schema 校验响应，存请求哈希和幂等键，把供应商响应与策略决定分开保存，好让审计者分清模型返回了什么、应用又允许了什么。

批处理是另一个角色。批量端点适合回放评测数据、分类那些晚几秒几分钟也无所谓的历史举报；它替代不了控制实时复核队列的同步路径。异步处理有自己独立的生命周期，这条边界应当保留，而不是藏在一个通用的 classify 函数后面。

契约定下来之后，再拿真实候选在同一个数据集和截止时间下比较。OpenAI 的 Responses 与 Batch 接口、Anthropic 的 Messages API、Google 的 Gemini generate-content API，在请求 schema、模型目录、结构化输出细节和异步能力上各不相同。这些差异是工程约束，不是封一个通用冠军的理由。

比较要回答具体问题：某家可能在一行领先、在另一行落后。语言质量出色但尾部延迟不稳的接口，不适合做实时分类器；高风险类别召回弱但速度快的接口，也许只适合升级前的分诊。评测框架里至少跑两个适配器，生产流量则按实测的策略阈值路由，而不是靠一句模糊的多供应商承诺。

没有适合所有路径的接口。同步端点不适合大批量回放，纯批量接口不适合等审核决定的聊天机器人。在队列截止时间内给不出可校验标签的模型，就该待在升级路径上，或者干脆不进入这个工作流。这个取舍是有意的：更高召回会吃掉更多延迟和审核人力，更快的路径接受更多不确定性，就需要更强的升级规则。

别只比较成功的请求。把畸形输出、限流、连接重置、截止超时、空证据引用都算进去，测试要断言每种情况都落进一个已知的操作状态。重试预算也是延迟预算的一部分：三次重试能把名义上 800 毫秒的超时，变成排队好几秒的队列事件。

可辩护的决定要存什么

最小可用记录是只追加的：事件 ID、接收时间戳、输入哈希、脱敏输入或引用、策略版本、提示词版本、模型修订号、请求尝试次数、结果、置信度（若提供）、延迟、失败码。原始响应只在游戏的留存与隐私政策下保存；永久存下一切不是审计策略。

把不可变证据和可变工作流状态分开。审核员可以改派单、标记已解决，但这类更新不该重写模型的原始结果。幂等键由审核事件和分类器修订号派生，写入成功后再发布下游决定。如果进程在模型调用之后、写入之前崩溃，worker 必须能判断自己是在重放一次尝试，还是在创建新的一次。

数据库和对象存储在这里分工不同：数据库支撑队列查询和事务性状态迁移，对象存储按明确的生命周期规则保留更大的证据文件。两者都修不好一个缺失的关联 ID。持久化只有在记录仍然可解释时才有用。

上线规则可以很紧凑：先准备一个离线集，覆盖普通举报、边界语言、对抗性措辞、缺失证据和已复核过的结果，冻结标签和评测代码。对每个候选适配器测分类别质量、尾部延迟、弃权率和畸形输出率。然后影子跑实时流量，真人审核员继续做真实决定。

一条路由要同时过两道门才放行：质量下限和延迟上限。为提示词、schema、适配器和策略各保留一个明确的回滚修订号。发布后盯标签分布，突然的偏移可能意味着输入漂移或运行时变化，哪怕请求成功率依然很高。

所以这个 Node.js 工作流里最好的 LLM 接口，是满足某条审核路径实测契约的那一个。更慢、质量更高的路由服务模糊举报；更快的路由做低风险分诊；两者都不该被允许抹掉不确定性。