审查

审查接口一般用于文本安全分类或输入预检查。需要时先在模型广场查看对应模型。

这类接口更适合放在“内容进入主模型之前”或“内容发布出去之前”，而不是替代业务本身的人工判断。

很多业务第一次接审查接口时，容易直接把它理解成“自动封禁器”。
更稳的理解方式是：它先给你一个风险信号，帮助你在真正进入聊天、发布、存档或自动执行之前，多一道判断。

创建审查 POST

地址：POST https://xiaolan.ainb.plus/v1/moderations

常用请求参数

• model：审查模型
• input：待检查文本

大多数情况下，先从单段文本开始测试最稳。
如果后续需要批量检查，再按你的业务把长内容拆段处理。

第一次测试时，最好顺手准备两条样本：

• 一条明显正常的文本
• 一条你预期更容易命中风险类别的文本

这样你更容易看懂返回结构，也更容易知道这套模型当前是不是已经正常工作。

示例请求

先把 MODEL 替换成模型广场里实际可用的 Moderation 模型名：

MODEL="替换成模型广场里的 Moderation 模型名"

curl https://xiaolan.ainb.plus/v1/moderations \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <你的 API Key>" \
  -d "{\"model\":\"$MODEL\",\"input\":\"需要检查的文本\"}"

响应

常见字段包括：

• 是否命中风险
• 命中类别
• 各类别分值

实际字段结构会和当前模型能力有关，但排障时通常先看“是否命中”和“命中了哪一类”就够了。

如果你的业务后面还要做阈值判断，再继续看各类别分值。
第一次接通时，不建议一上来就把阈值写死，因为不同模型、不同语料下，分数分布可能会差很多。

使用位置

常见放在这些环节：

• 用户输入进入聊天模型前
• 内容发布前
• 批量导入知识库前
• 自动化脚本执行高风险操作前

如果你已经有主聊天模型，可以把审查理解成它前后的“守门环节”：

• 前置审查：先检查输入值不值得继续送进主模型
• 后置审查：先检查输出内容是否适合继续展示、保存或转发

使用建议

• 审查结果只作为风控信号，不要替代业务判断
• 命中类别要结合上下文处理
• 批量内容先分段，再逐段检查
• 是否支持图片或更复杂输入，以模型广场和当前模型实际能力为准

如果你准备真的把它接进生产流程，再多做一步：
先拿自己业务里已经知道答案的一小批样本跑一遍，看看哪些类别容易误报、哪些阈值更适合你自己的内容环境。

常见问题

模型不可用

审查模型和聊天模型不是一类。回模型广场确认是否有可用的 Moderation 模型。

分数怎么看

分数越高，命中对应类别的可能性越高。不同模型的阈值不一定完全相同，生产使用前先用自己的样本校准。

也正因为阈值不是天然统一的，所以不要把别人的阈值教程原样搬过来就上线。
先用你自己的文本样本试一轮，通常会比照抄一条固定数字可靠得多。

为什么主聊天模型可用，但审查接口不可用

审查模型和聊天模型通常不是同一种模型能力。聊天能用，不代表当前 Key 自动拥有审查模型权限。先回模型广场确认可用模型，再检查这把 Key 的分组和模型权限。