输出过滤的规则引擎是怎么工作的？

一条由 AI 大模型生成的回答，在送到你屏幕上之前还要过一道关卡，输出过滤的规则引擎就在这道关卡里工作。它决定哪些话能出、哪些话要改、哪些话不能说。

可以把它想成机场安检：人和行李都要过机，明令禁止的当场拦下，存疑的交人工复检。这个类比的失效之处在于，安检对象是固定的物，规则引擎面对的是千变万化的语句，同一个意思可以有无数种说法，规则既要盯字面也要防变体。带走一个判断：规则引擎管的是「明确红线」，而不是替模型做所有判断。

规则引擎的输入和输出

输入是待放行的文本流，通常连同它的来源与场景信息一起送进来。

输出是处置决定：放行、替换、打标、拦截或转人工。引擎内部拿着两样东西做判断：一份规则库，写明什么命中什么处置；一个匹配器，负责在文本里找命中点。整个交换单位是「一条规则对一段文本」，简单直接，也便于逐条复盘。

一条规则从匹配到处置的过程

规则命中分几步：先做精确匹配，命中词表里的词条；再做模式匹配，抓形近、谐音、拆字这类变体；命中后按规则等级选择处置——轻微的替换或打标，严重的直接拦截并返回统一话术。处置记录会流入用量与审计体系，账目的走向见服务端怎么记录 token 用量？账单的来源。被拦截的请求有的还会计入限流口径，计数规则见请求的限流计数是怎么清零的？每一步都讲透。

规则和模型的分工边界

规则引擎管「明确不能说的」，命中即处置，快而确定；模型自身的对齐训练管「灰色地带的判断」，靠语义理解拿捏分寸。两者是接力关系：模型先产出，规则兜底复核。豆包和通义千问在产品说明里都强调多层内容防护，指的就是这种组合。

规则从哪来同样值得了解。一部分来自平台的安全基线，全量租户统一执行；一部分来自使用方的自定义需求，比如把业务术语列入保护词表，防止被误改误删。自定义规则通常有数量和长度上限，写得越具体越不容易误伤——「不许改产品型号」不如「保留型号中的字母与数字原样」来得精准。粒度细化到词句级，处置才能精准到该动的地方动、不该动的地方不动。输入侧的对应关口是另一条线，见敏感词拦截在哪个环节？从原理到落地。

规则太严或太松，各是什么表现

太严的表现是误伤：正常表述被替换成星号，或整段回答被拦，体验直线下降；太松的表现是漏网：变体写法绕过字面匹配，不该出现的内容流到用户面前。好系统的做法是把规则做成可调的分层清单，配合定期复盘误拦和漏拦案例，逐步收紧或放宽。资料块与来源标注在进入回答前同样受这套规则约束，资料侧见长文本的预处理发生在哪一步？切块与标注，来源侧见上下文里的引用标记是怎么加的？来源标注。

规则引擎的四个处置档位：

• 放行：无命中，原文送出
• 打标：命中低风险项，留痕不改动
• 替换：局部词句被遮蔽或改写
• 拦截：整段退回，返回统一话术

档位越高，触发条件越严格。

关于输出过滤，再多问三句

• 过滤发生在生成前还是生成后？：两侧都有，生成前过滤输入，生成后再对正文复核一遍，本文讲的是后一侧。
• 被替换的内容能还原吗？：不能，替换在输出侧完成，用户拿到什么就是什么。
• 规则库多久更新一次？：由平台运营节奏决定，通常随新风险出现而滚动更新。

规则引擎像个不显眼的守门员，多数时候你感觉不到它，这正是它工作正常的证据。