日期:2026-07-28
我们网关承接的业务里,有相当一部分是"对外生成内容":电商文案、客服话术、自动生成的报告。早期这些内容生成后直接返回业务,靠人工抽检把关。结果出过几次小事故:一篇自动生成的促销文案里混进了违禁的绝对化用语,发出去被平台警告;一封对外报告里出现了不该外泄的内部代号。人工抽检覆盖率低、滞后,等发现已经对外了。我们意识到,对外内容的合规不能靠"事后抽检",必须在网关输出侧加一道实时关卡。
我们在网关的输出侧接了一道"敏感词与品牌词实时检测"关卡。大模型生成的文本在返回业务之前,先过检测:内置多层词库——法律法规违禁词(如绝对化用语、违禁表述)、品牌负面/竞品词、以及客户自定义的业务敏感词。命中后按等级处置:高危违禁词直接拦截并返回安全兜底话术;中危品牌词做替换或转人工;低危做告警留痕。词库支持热更新,运营改词库不需要重启网关。所有命中都留痕(脱敏后),可供合规审计回溯。
第一,检测的实时性。这道关卡不能明显增加返回延迟,我们用"多模式匹配(AC 自动机)+ 分层词库"做单次扫描,覆盖 thousands 级词条的耗时控制在毫秒级。第二,分级处置的体验权衡。高危直接拦,中危不硬拦(否则正常内容也发不出),改成替换或转人工,把"误杀"控制在可接受范围。第三,词库热更新。词库变更频繁,我们做成配置中心推送,网关无感加载新词库,避免重启带来的服务中断。第四,命中留痕与可审计。命中记录脱敏后入库,保留"谁、调了什么模型、命中了什么词、怎么处置的",合规出问题能回溯。
案例片段(已脱敏): 敏感词分级处置的配置(示意):
yaml filters: - layer: legal # 法律法规违禁词 action: block # 高危直接拦截 fallback: "内容含违禁表述,已拦截" - layer: brand_negative # 品牌负面/竞品词 action: replace # 中危替换 - layer: custom_biz # 客户自定义敏感词 action: alert_and_log # 低危告警留痕 hot_reload: true # 词库热更新,无需重启
上线后一个季度:对外内容里被系统拦截的高危违禁词命中,月均数十起,全部在输出前被拦下,未再发生"发出去才被发现"的事故;中危品牌词的替换/转人工处置占比约八成,误杀(正常内容被误拦)控制在很低比例;合规审计对输出内容的通过率提升明显。检测本身增加的端到端延迟在毫秒级,业务无感。数字脱敏示意,口径一致。
对外内容合规的第一条:输出侧实时兜底,先于事后抽检——内容一旦发出去,事故就发生了,拦在门前才是真防护。第二,检测要快,用多模式匹配单次扫描,别让合规关卡变成延迟瓶颈。第三,分级处置优于一刀切拦截,高危才硬拦,中危替换/转人工,否则误杀会让业务方抵触。第四,词库要热更新,运营改词库不能重启网关。第五,命中必须留痕且脱敏,合规出问题能回溯责任。这套"实时检测—分级处置—热更新—留痕审计",是网关对外内容治理的标配。
对外内容这道关卡,本质是"把合规从人脑搬到网关"。我们做过对比:人工抽检时代,覆盖率不到两成,且永远是"发出去才发现";实时检测后,高危违禁词在输出前就被拦,对外事故基本归零。合规从事后救火变成事前拦截,成本结构完全变了。
但要提醒的是,分级处置比一刀切拦截难做也更重要——我们一开始把所有敏感词都设成硬拦截,结果正常文案频繁被误杀,业务方意见很大,后来改成高危拦截、中危替换、低危留痕,才平衡下来。合规不是把门关死,而是把风险挡在门外、把正常内容放进来。留痕则是最后一道保险:真出问题,能说清谁、调了什么模型、命中了什么词、怎么处置的,审计才站得住。对做对外生成业务的团队,这道网关关卡建议作为标配,而不是可选项。
还有一个实践细节:敏感词库我们分层维护,法律法规层由合规团队统一管,品牌层由市场部管,客户自定义层由业务自己加,三层独立更新互不影响。以前混在一起,改一个词要全等所有方确认,迭代极慢。分层后,业务侧发现新的敏感表述能自己加、自己热更新,响应从"走流程一周"变成"改完即生效"。治理的敏捷性,往往比规则本身更重要——词库跟不上业务,再严的关卡也是马后炮。我们也建议定期回看命中留痕,把高频误杀的词降权,把漏掉的补充进去。
站在合规治理的高度看,这道关卡的价值不止于"拦住坏内容",更在于把"对外内容的责任"从个人转移到了系统。以前文案发出去出问题,追责到具体运营;现在系统留了痕、做了分级处置,责任可界定、可复盘。这对管理上是大事,AI 生成内容规模越大,越不能靠人盯人。我们也建议把命中留痕定期导出给合规团队做抽检,反向校准词库:误杀多的词降权,漏掉的补充,让关卡越用越准。合规治理是闭环,不是一锤子配置,这点很多团队上线时容易忽略。