模型输出的内容审核规则怎么定

模型上线后，最常卡住的不是「要不要审」，而是「审到什么程度、谁来兜底」。松了出事，紧了用户骂，规则还天天被新话术绕过。这篇把输出审核从口径、分层、判定、兜底到复盘串成一条线，给出可照着改的规则骨架和排查顺序，并说明哪些情况下这套分层不适用，需要另做处理。

模型上线之后，内容审核最容易卡住的地方往往不是「要不要审」，而是「审到什么程度、谁来兜底」。规则定松了，一旦出事就是大事故；定太紧，用户体验直线下降，客服工单堆成山。更麻烦的是，新话术、新玩法天天在变，规则写完就开始过时。

这篇不聊抽象原则，直接给一套从口径、分层、判定、兜底到复盘的制定思路，配可照着改的规则骨架和排查顺序。先说清楚这套分层在什么情况下不适用——如果产品面向的是专业用户、高风险工具场景，或者输出直接对外发布，那分档和兜底策略都得另做处理，不能照搬。

先定口径：审谁、审什么、谁说了算

很多团队一上来就写规则细节，结果写到一半发现大家讨论的压根不是同一个场景。先花半天把口径对齐，后面能省掉好几周的返工。口径要回答三个问题：审的是哪种输出、边界画在哪、出事谁拍板。

面向公众发布

输出会被大范围传播，审核标准最严，任何模糊地带默认走保守档

面向单个用户

一对一会话，标准可以适度放宽，但涉及人身安全、违法指引的仍需硬拦

仅供内部流转

给团队成员自己用的，重点是防止误操作和泄露，风格类约束可以松一些

「不可接受」和「需提醒」之间的界线，一定要能用一句人话复述出来。如果一线同学看了规则还是不知道该拦还是该放，那就说明界线没画清楚。常见做法是拿十个真实样本过一遍，看大家判断是否一致，不一致的地方就是界线模糊的点。

• 把三类输出场景分别写清楚，各自的松紧档位不混用
• 用一句人话描述不可接受的门槛，让非技术同学也能复述
• 明确规则解释权归属：产品、法务还是安全，新场景由谁拍板
• 口径固化成文档并打版本号，每次改动留记录，能追溯是哪一次改的

把审核拆成四层：输入、生成中、输出、事后

把审核当成一个单点去设计，排查问题时就会找不到北。更靠谱的做法是拆成四层，每层负责不同的事，判定结果串成一条链，出事后能还原是哪一层放过去的。

输入层管的是用户怎么问，输出层管的是模型怎么答，这两层的规则千万别混着写，否则日志里看不出问题出在哪个环节。生成中做拦截适合那些一旦生成出来就来不及补救的场景，输出前做最终判定是最后一道闸，事后层负责兜住漏网的。

1. 每层写清动作拦下来之后干什么，只能在拒答、改写、加提示、转人工里选一种，写死在规则里
2. 串联判定链每层记录自己的判定结果和规则 ID，保证出事后能还原完整链路
3. 验证分层有效拿一批已知的有问题样本，看它们分别在哪一层被拦，发现某层长期没拦到东西就要检查是不是形同虚设

规则怎么写才好维护：条件、动作、例外三段式

规则写成一团，过两个月自己都看不懂。建议每条规则固定三段：条件、动作、例外。条件只写一个触发点，动作写死一种处理方式，例外单独列一节说清楚什么时候不套用这条。

• 每条规则只写一个触发条件，避免复合条件导致排查时定位困难
• 条件里避免「敏感」「不当」这类没有边界的词，换成可观测的描述
• 动作要可观测：替换词、整段拒答、降级为带提示的答复，写死一种
• 例外单独列，写清什么情况不套用、判断依据是什么、谁有权决定

给每条规则编一个稳定 ID，日志、工单、复盘文档都引用这个 ID。这样过一段时间回头看，你能知道哪条规则最常触发、哪条几乎没生效过。ID 别用会变的东西命名，用编号加简短描述就行。

规则示例结构：
ID: OUT-012
条件: 输出包含可执行的操作步骤且涉及危险行为
动作: 整段拒答并附安全提示
例外: 面向专业从业者的合规教学场景，需人工审核标记后放行

分档与优先级：哪些必须硬拦，哪些只提示

规则不是只有拦和不拦两种状态，中间还有一大片「提示档」。按后果分档比较直观：涉及人身安全、违法指引、未成年人相关的，走硬拦；风格偏好、措辞争议这类，走提示就够了。

硬拦和提示的比例要定期看。提示占比长期过高，说明规则定得过宽或者过严，用户会觉得处处被提醒，体验很差。反过来说，硬拦占比突然飙升，先别急着高兴，很可能是条件写得太宽，把正常对话也拦了。

有一种情况分档要整体上提：面向专业用户的高风险工具类产品。这类用户本身有一定的判断力，但一旦被误导后果更严重，很多在其他场景下属于提示档的内容，在这里应该上提到硬拦。判断依据是「用户能否自行识别风险」，不能就往上提一档。

兜底与灰度：模型拿不准的时候怎么办

模型不是每次都能给出高置信度的判断，拿不准的时候怎么处理，是审核规则里最容易被忽略的一环。默认策略应该是走更保守的一档，而不是默认放行。放行错了是事故，保守错了顶多是体验问题。

1. 给低置信度留退路置信度低于阈值时，自动切到更保守的处理动作，而不是按原判定执行
2. 灰度上线新规则先在一部分流量上跑，观察误拦率和用户反馈，确认没问题再全量
3. 写清降级顺序服务不可用时先保什么、先停什么，按影响面排序，别等到出事才讨论

兜底不等于只有拒绝这一个选项。改写、补免责说明、引导到人工渠道，都是可选的兜底动作。具体选哪个，取决于这条规则对应的风险类型：事实性错误适合改写或补说明，安全类风险适合直接拒答。路径别只留一条，留一条后备通道。

留证与复盘：日志记什么，多久看一次

日志是审核规则的眼睛，但记什么很有讲究。记触发规则 ID、时间、输入摘要和最终动作就够了，别记全文。全文日志本身就是一个新的泄露面，一旦日志被拿到，等于把用户的对话全暴露了。

• 记规则 ID、时间戳、输入摘要和最终动作，不记完整对话内容
• 评审节奏按触发量定，触发量大的规则按周看，量小的按月抽查
• 误拦样本单独攒一个池子，这是下一轮改规则最有价值的输入
• 复盘结论要落回规则文档，只开会不改文档等于白做

误拦样本比漏拦样本更值得关注，因为漏拦很难被发现，而误拦会被用户投诉。每次复盘挑几条典型的误拦样本，看是条件写太宽、还是例外没覆盖到，然后针对性改一条规则。一次改一到两条，改多了出问题说不清是哪条引起的。

盯住哪几个数：判断规则是不是在正常工作

光看一个指标容易被误导，建议三类数一起看：硬拦量、提示量、申诉量。三者同时看，才能判断规则是变严了还是变松了，还是只是流量结构变了。

单日波动别急着改规则。先排除两类干扰：一是流量结构变化，比如某个渠道涌入大量新用户；二是上游接口异常，比如模型版本换了导致的输出风格漂移。具体阈值和当时的对照数字，到站内榜单与真实用量榜核对，别凭感觉拍板。

申诉量和提示量的比值突然走高，通常说明规则和用户预期脱节了。这时候要看的是申诉内容集中在哪一类，如果集中在同一类场景，那就是那一条规则需要调整例外。

上线与迭代节奏：别想一次定死

第一版规则宁可少而准，先覆盖最明确的几类，再靠真实样本慢慢往外扩。上来就写几十条规则，大概率一半是拍脑袋想的，跑起来全是误拦。

• 第一版只覆盖最明确的几类风险，宁少勿滥
• 每次改动只动一到两条规则，便于归因
• 规则版本和模型版本分开记录，避免答得不好时找不到责任方
• 面向内部和面向公众的产品，迭代节奏可以不同，别用一套排期

规则版本和模型版本分开记这件事，很多团队吃过亏。模型换了之后答复风格变了，触发规则的数量跟着波动，如果两个版本混在一个编号体系里，根本分不清是规则的锅还是模型的锅。分开记，排查时一眼就能定位。