审核机器人可靠性，关键在输出契约

举报审核聊天机器人最容易出问题的地方，可能不是模型不够聪明，而是结果到了业务系统里，没人检查它是否真的可用：字段错了、标签含义变了，或者重试一次，审核结论也跟着变了。

作者给出的方案，是把分类过程拆成四层，用明确的输出契约、人工兜底和评估集约束模型。对准备在 Node.js 服务里接入审核助手的团队，这篇文章的价值在于：把关注点从「选哪个模型」拉回「什么结果才允许进入业务流程」。

先定义审核政策，再讨论模型能力

作者最初把问题当成模型选型，后来发现，代价高的故障来自字段格式、模糊的政策标签，以及重试前后不一致的结果。不过，原文没有提供故障数量或成本数据，这属于作者的实践判断。

举报文本也不是一道干净的选择题。它可能引用辱骂内容，夹带举报人的指控，描述截图，或者把多条举报粘在一起。系统首先得分清：哪些是被举报内容，哪些只是举报人的转述。

因此，输出词汇要由产品政策提前确定。示例中的 decision 只有 allow、review、escalate，policy_area 只有 harassment、sexual_content、violence、unknown。

这里有个关键区别：unknown 是政策领域的合法值，不是第四种审核决定。空白、矛盾或超出政策范围的输入应当如何处理，也需要明确，不能让模型用一个自信的猜测填补空缺。

review 同样必须有固定含义。它究竟表示「业务要求人工检查」，还是「模型自己拿不准」？两者混用，评估准确率就失去了统一标准。

聊天机器人可以向客服解释分类，但解释不能暗中产生第二份相互冲突的结论。业务系统应该围绕同一个经过校验的分类对象运转。

四层运行时，分别守住什么边界

作者将流程拆成输入规范化、模型调用、契约校验、队列路由。每层都有自己的测试和遥测，方便区分故障究竟来自输入、接口，还是模型结果。

其中最值得保留的是校验与路由代码：它让「模型返回成功」和「业务允许使用」成为两个独立判断。

from dataclasses import dataclass
from typing import Any

ALLOWED_DECISIONS = {"allow", "review", "escalate"}
ALLOWED_AREAS = {"harassment", "sexual_content", "violence", "unknown"}

@dataclass
class Classification:
    decision: str
    policy_area: str
    confidence: float
    evidence: list[str]

def validate_classification(value: Any) -> Classification | None:
    if not isinstance(value, dict):
        return None

    decision = value.get("decision")
    area = value.get("policy_area")
    confidence = value.get("confidence")
    evidence = value.get("evidence")

    if decision not in ALLOWED_DECISIONS or area not in ALLOWED_AREAS:
        return None
    if not isinstance(confidence, (int, float)) or not 0 <= confidence <= 1:
        return None
    if not isinstance(evidence, list) or not all(
        isinstance(item, str) for item in evidence
    ):
        return None

    return Classification(
        decision=decision,
        policy_area=area,
        confidence=float(confidence),
        evidence=evidence,
    )

def route(result: Classification | None) -> str:
    if result is None:
        return "human_review"
    if result.decision == "escalate" or result.confidence < 0.70:
        return "human_review"
    return "automated_queue"

要看清 result.confidence < 0.70 这一行：0.70 只是示例政策阈值，需要结合漏掉升级处理的代价、增加人工审核的成本来确定。

代码还有一个容易误读的地方：review 并不会直接触发 human_review。按当前实现，高置信度的 review 会进入 automated_queue。原文没有交代该队列后续如何处理，所以业务标签与队列去向之间，还需要补齐定义。

校验的能力也有边界。它能检查枚举、数值范围和证据数组类型，却没有验证证据是否真的出现在输入中。空证据数组也能通过。结构合格，只代表结果可以被程序读取，不能证明分类正确。

接进 Node.js 后，重试、流式和评估要一起设计

作者建议为供应商接口包一层适配器：接收消息、Schema 描述、超时和请求标识，返回经过验证的分类，或者有明确类型的失败。供应商专属字段留在适配器内部，业务代码只处理稳定的输入输出。

有些 API 提供原生结构化输出控制，有些更依赖提示词和响应后的校验。原文没有具体比较供应商，也没有给出可直接运行的 Node.js 实现，重点是接口边界。

流式输出适合逐步展示解释，但半截 JSON 不能作为审核决定。只有最终对象通过验证，才能提交分类。Batch API 则属于异步批处理路径，适合历史数据回填和离线评估，不能直接拿来解决交互聊天的延迟问题。

重试也要区分原因。超时、限流、临时故障，与「响应到了但分类结构不合格」是不同事件。后者即使重新请求，也必须记录尝试，避免语法修好了，决定变了，却只留下最后一次结果。接口支持时可以附加幂等键，但原文没有承诺重复生成会得到相同分类。

验证这些设计，不能只看端到端通过率。作者建议用审核人员达成共识的样本建立评估集，包含边界案例和对抗表达；固定一部分做回归，再保留较新的样本检查漂移。每条至少记录预期决定、政策领域、证据是否可接受，以及是否需要人工审核。

标签一致率和安全路由应当分开评分。 多转人工可能降低自动化覆盖率，却改善实际审核表现；这项取舍应该出现在评估表里。

生产日志则记录请求标识、政策版本、Schema 版本、延迟、重试次数、校验结果、路由和可获得的 Token 数量。unknown 增多可能来自政策变化、输入格式变化或模型更新；结构通过率稳定，也可能伴随升级召回率下降。

成本也要一起算。提示词省下的 Token，如果换来更多人工返工，整体未必便宜。

我的判断

我赞成把输出契约放在模型选型前面。对于审核分类，枚举、兜底路径和审计记录，确实比聊天回复是否流畅更接近业务要求。

但原文是一套工程建议，没有给出模型对比、评估集规模、准确率、延迟或成本结果。标题里的「可靠」，以及开头关于 2026 年最佳 LLM API 的判断，都没有对照实验支撑，应当按经验之谈理解。

示例也不能直接作为完整生产规则。除了证据真实性没有验证，代码还没有展示空输入、合并举报和政策外输入的具体处理。模型给出的 confidence 是否经过校准，也没说清；不能把 0.70 当作已经验证过的安全线。

和单纯在提示词里要求 JSON 相比，这套方案明确了失败后的去向；和原生结构化输出相比，它进一步覆盖了业务路由与人工反馈。两者可以组合使用。真正需要团队投入的，是定义政策、维护评估集，以及持续接收审核人员的纠错意见。

能拿来做什么

• 在 Node.js 审核接口里，把模型调用、结果校验和队列路由分开，让超时、结构错误、低置信度分别留下记录。
• 在前端聊天界面中，允许解释逐步展示，但只在最终分类通过校验后更新审核状态，避免把中间输出呈现为正式结论。
• 和审核人员一起补齐 review、escalate、unknown 的处理规则，先解决标签与队列去向的歧义，再调整自动化范围。
• 用真实举报形态建立固定回归集，分别记录标签一致性、证据质量、人工路由和复核结果，再决定是否修改 0.70 阈值。