Aegis内容审核平台化建设之路

在当今时代，内容安全重要性不言而喻，一旦不合规的内容未经审核或被审核漏放，并得以传播，将引发舆情，导致平台承担首要责任，轻则处罚整顿，重则停业下架。例如，"内涵段子"和"笑果"就是因对审核没有给予足够的重视，最终导致了被封杀下架的结果，因此必须加强对内容安全的监管和审核力度，确保平台上的内容符合法律法规和道德标准。

B站涉及内容生产的业务繁多，包括稿件、视频、专栏、小视频、动态等，而这些内容都需要经过审核，为此，各业务线纷纷开发和维护自己的审核后台，重复造轮子，导致了资源的浪费。为了解决这个问题，我们需要一个统一的内容审核平台，业务方只需要简单接入该平台，就能方便迅速地完成审核流程，并使用通用的审核周边体系，例如机审、质检、监控、数据等。

审核平台从2018年开始建设，经过五年的摸索与演进，已经从第一个动态业务接入发展到了基本覆盖B站所有50+业务。正如其名"Aegis"所象征的那样，这个平台像古希腊神话中的大神宇宙的盾一样，成为了所有业务线生产到消费链路中至关重要的一环，为保护最好的B站提供了强大的支持。

本文将回溯审核平台的发展历程，从最初的MVP版本到功能成熟、稳定运行的通用平台。这个平台为上千审核人员提供服务，每日处理超百万资源。其强大的功能和稳定性确保了内容审核的高效进行，为维护良好的内容生态做出了重要贡献。

从立项开始，审核平台的目标就是实现全公司内容生产业务的接入，满足各类场景需求。为了实现该目标，平台采用接入简单、通用的解决方案进行设计，能够满足不同类型和规模的业务需求。

平台与业务解耦，预定义送审字段，如果有实时数据依赖则需要业务方提供展示API，确保平台获取实时的审核数据，从而保证审核的准确性和及时性。业务方提供HTTP接口用于平台回调通知审核结果，这样，平台可以与业务系统进行通信，将审核结果及时反馈给业务系统。

^图1-1

如上图1-1所示，平台预定义了oid、content、extra1-3、extra1s-3s和metadata等字段，供业务方用户审核信息上报。除metadata外，其余字段均支持搜索。平台会向业务方回调操作结果、封禁结果和通知状态等信息。业务方根据结果实现后续逻辑，例如开放、打回并通知用户等。

送审核心API：

• Add：送审将创建资源，如果资源已存在，将更新资源并将审核流程重置到初始节点和待审状态。

• Update：仅更新资源信息，不会改变审核流程及状态。

• Cancel:用于取消资源，如用户删除或业务方判断无需再审等。资源将结束审核流程，并关闭相关任务。

流转模型，负责维护业务的审核流程与流转逻辑，我们选择了有色Petri网，它是扩展的Petri网，可以描述并发、异步和并发的流程，引入颜色到库所（Place）和变迁（Transition）中，用于表示不同的含义，这使得它可以更好地描述和分析实际业务流程。

每个业务都有自己的审核流程，如一审→二审等，业务接入时，可根据业务实际需求，进行有色Petri网进行建模。

^图1-2

如上图1-2所示，每个审核阶段都可以表示为一个库所，并且可以根据具体的业务需求为每个库所分配不同的颜色。变迁可以表示为审核步骤之间的转换，例如一审到二审，并且自由地添加、删除或修改库所和变迁，以适应不同的审核流程，比如新增三审，一审二审并行审核等。

对于多人审核的情况，为了避免冲突和提高审核效率，使用任务系统进行任务分配是一个很好的解决方案。

平台使用分布式锁来实现任务唯一分配，可以确保在并发情况下，每个审核后台都能获取到唯一的任务。这种任务分配方式可以避免多个审核后台同时操作同一份任务列表，减少了冲突的可能性，提高审核效率。

^图1-3

最终实现的服务架构如下：

^图1-4

如上图1-4所示，aegis-admin为后台admin服务，用于业务管理、资源管理、流程管理、任务管理等，aegis-job为异步服务，用于消费业务方送审资源并进行资源创建、任务生命周期管理、监控、日志统计、权重计算以及等。

整个流程大致如下：

1. 业务方需要与平台事先约定送审字段、回调接口和审核流程定义。

2. 在平台配置完成后，业务方通过databus上报审核内容。

3. aegis-job负责监听并调用aegis-admin创建资源。

4. aegis-admin资源创建完成，驱动流程将开始流转，并通过databus向aegis-job发送创建任务消息。

5. aegis-job根据任务进行权重计算，并创建任务。

6. 审核/运营人员可以通过查询或任务分发来领取任务并提交。

7. 最终，结果将通过回调接口同步给业务方。

18年11月平台MVP上线，并接入动态业务，实现了动态审核的托管，这是平台接入的第一个业务，自此之后平台开始迅速接入其他如单话、评论、弹幕等业务。

^图1-5

 在平台不断承接业务的过程中，我们发现业务方需要根据某些条件来区分先发或先审，或者根据某些条件判断是否需要进审，解决此类需求的两种常见方案是：

• 将规则硬编于应用程序代码中；

• 在业务后台定制各自的配置页面，一般仅可修改数值。

以上方案的问题在于，随着审核运营策略的调整，业务方往往需要修改代码或配置文件，并需要重新发布版本以使决策生效。这存在灵活性差、响应慢、风险高等问题。

因此，我们通过规则引擎，将业务规则和业务侧解耦，将业务方的进审策略统一放在策略中心服务进行维护。策略中心作为业务方和审核平台的中间层，承担数据转换、规则匹配、最终响应等能力。业务方只需要无脑推送资源到审核平台即可。

由于我们的团队使用的是GO技术栈，虽然开源社区提供了像Drools这样成熟的规则引擎组件，但这些组件并非使用GO语言编写，对我们来说是“黑盒”，需要一定的学习成本和维护风险。因此，我们选择自研实现。

规则引擎核心在于规则的定义与解析，我们通过使用Golang的基础库AST包，将预定义的表达式DSL转换为树形的代码结构AST(抽象语法树)。然后，通过遍历AST来进行计算求值，实现了策略中心服务最核心的规则引擎组件。

例如，如果定义的规则条件为"years > 20 && uid > 30"，将其解析为如下AST结构，如下图2-1所示：

^图2-1

在遍历AST时，如果遇到的不是叶子节点，那么它是一个二元表达式节点，一定包含X、Y和OP。我们递归遍历X和Y，如果遇到叶子节点，则进行因子求值比较运算。最终，在遍历结束之后，将输出整个规则的结果，以决定资源是否需要进审。

我们定义了一套DSL协议，由于核心的规则引擎使用AST包实现，因此需要以Golang语法标准的条件判断语句为基础，不可使用Golang语言预定义的关键字如"type"、"func"等。

此外，我们还实现了自定义函数，如"in"、"between"、"contain"、"intersect"等。同时，我们也实现了用于规则判断的因子，包括业务方送审基础因子以及基于基础因子额外查询的数据第三方因子，例如粉丝数、昵称等。

通过DSL表达式来配置进审策略，研发只需要较低的成本即可操作，但对于审核运营来说，这可能难以推广。此外，配置复杂且容易出错，容易导致安全问题。因此，我们实现了页面配置化，以便于审核运营人员以简单、易懂的方式进行配置。如下图2-2所示，审核仅需要选择因子并配置条件，以及条件命中结果未命中结果，即可完成策略调整。

^图2-2

独立的线程持续轮询监听规则的变化，并将变更实时加载到内存中，以便规则引擎能够立即重新应用，从而实现秒级别的变更。

^图2-3

整体流程图如上图2-3所示，业务方送审会先经过策略中心服务，策略中心会根据进审规则进行判断，最终得到“进审”或“不进审”的结果，并将该结果同步返回给业务方。如果结果为“进审”，则会上报审核信息到审核平台，以进行后续流程。

基于此，我们将现有的弹幕和评论进审策略进行整合，并对后续接入的业务进行统一维护。这不仅可以减轻业务方的负担，还能实现全站实时管控。在紧急舆情时期，产品运营人员可以直接进行策略变更。相比以往需要向各个业务方提出需求、进行开发、测试和上线等流程，至少需要1天甚至2-3天的情况，这种方案大大缩短了时间，并提高了站内的安全保障。

随着业务的不断接入，我们的审核量级迅速攀升至每天100万以上，这时我们遇到了以下问题：

• 审核任务池的拆分非常困难，因为任务池和流程节点之间是一对一的关系。如果要拆分任务池，我们就需要调整流程，并拆分多个流程节点。这种做法将原本不属于流程问题的问题用流程来解决，使得问题更加复杂化。

• 系统负载逐渐升高，由于初期没有设计分库分表，导致单表数据量级很大，频繁出现慢查询等问题，收到审核卡慢等问题反馈。

• 从微服务的角度出发，随着人审功能需求的不断增加以及团队成员的扩大，进行服务拆分是非常必要的。

因此，我们开发了工作台模块，引入了TiDB数据库，以降低分表对业务复杂带来的成本。该模块提供以下能力：

• 任务池拆分，产品审核可以方便灵活的根据送审资源特征如分区、视频时长等来拆分或合并任务池，来达到内容聚合与隔离，解决之前审核任务池拆分复杂、成本高等问题；

• 任务分发，按权重大小实现有序分发，权重策略可灵活调整，保障高优内容快速过审，提高审核效率；

由于业务送审内容变动、突发事件的出现、审核职责调整等原因，任务池进审条件可能会发生变化，同时也会存在任务池拆分和整合的诉求。在此之前，这些调整都需要研发人员接入支持，配置信息分散，容易出错。因此，我们提供拆分配置化能力，同时开放给产品和运营使用，大大降低了接入成本。

^图3-1

^图3-2

如上图3-1所示，任务池和审核节点是N:1的关系，资源会经过每个任务池的关联策略，如果命中则会进入对应的任务池。同时，审核运营可以灵活根据审核节点进行任务池拆分，如上图3-2所示，新增任务池并配置关联策略，即可快速拆分新任务池。

工作台在任务分发设计的初版基础上，对权重和分发进行优化，如下图3-3所示：

^图3-3

• 权重值是一个int64数字，根据bit位划分为三部分：优先级、创建时间和排序，业务送审后，根据上报数据进行权重计算，在分发时按照权重大小进行有序分发。

• 为了提高分发性能，每次审核员拉取任务时，都会预分配N个（N可配置）。这样理论上可以将锁抢占率降低到1/N。

• 为了避免审核员领取任务后长时间不进行审核，任务会被加入延迟队列。如果在一定时间内仍未审核，该任务将从个人任务池中释放，并放入公共池中进行重新分发。

该模式被称为拉模式，其本质是抢占式。如果“供小于需”，则会出现不公平现象，即手快的审核员会获得更多的任务，而手慢的审核员则一直抢不到任务。

为了解决拉模式的不公平问题，我们抽象出了sheduler调度器的概念，该调度器会监听审核员的登入登出，并基于审核人员的画像数据及当前任务池的负载情况，主动给审核员推送任务，如下图3-4所示：

这样，在“供小于需”的情况下，能够保证审核员处理任务相对均衡，避免出现部分审核员无法领取到任务的情况。

我们发现，各条业务线的各个任务池的进审量各不相同，有些任务池积压，有些则空闲。审核人力分配也存在滞后现象。为了更好地提高人效并维持大盘m60(m60是指过审时长60分位，60%任务的过审时间)的过审效率，我们进行了混排机制。

如上图3-5所示，A、B、C三个任务池会统一分发审核员，并且会保证每个任务池M60的指标不受影响。

^图3-6

我们对视频一审进行了混排实验，如上图3-6所示。在混排前，低风险任务池的m60受积压量影响，当积压量高时，人力无法处理所有任务，m60明显上升；而当积压量低时，人力充足，m60却非常低，存在一定的浪费。在混排后，m60的波动更加稳定，在同等人力情况下，审核效率提升了10分钟左右，67%的时间段低于单排。

审核是一场权衡安全与效率的博弈，其中安全是底线，效率是目标，机审在追求效率的大目标中扮演着至关重要的角色。

随着B站的持续发展，内容形式和数量呈现爆发式增长。如果所有内容都交由人工处理，成本高，效率低。因此，AI算法能力在审核场景中的应用应运而生，也就是我们所说的机审。

根据内容类型的不同，我们可以将机审分为三类：文字机审、图片机审和视频机审：

• 文字机审，即处理文本形式的内容。这种形式的内容机器处理效率极高，准确率也较高，因此文字机审的应用场景较为灵活。机审耗时通常为毫秒级别。在B站中，评论、点播弹幕、直播弹幕等业务应用较多；

• 图片机审，即处理图片形式的内容。图片的内容变化较大，简单的图片可能只有几个字，而复杂的图片可能包含多层复杂内容。因此，图片的机审效率和准确性难以明确，需要关注具体场景并使用合适的模型。机审耗时从毫秒到秒不等。在B站中，动态业务、专栏业务等应用较多；

• 视频机审，即处理视频形式的内容。视频可以看作是一系列帧图片的集合，因此以视频为机审单元时耗时较高，通常为秒级甚至分钟级别。在B站中，稿件视频、素材视频等业务中应用较多。

 针对不同类型的内容，审核平台的机审能力实现可以分为同步机审和异步机审两种方式。这两种方式主要区别在于通信方式。

• 同步机审：通过接口可以实时获取机审结果，主要应用于文本及简单图片的场景中。

• 异步机审：通过消息通知的方式获取机审结果，主要应用于复杂图片以及视频等场景的业务中。

实现方式会根据具体业务的内容形式的不同而选择同步或异步方式，同时也会受到一些历史背景的影响，可能导致同步机审和异步机审同时存在。

机审的完整能力由审核平台和AI算法团队共同提供。

AI算法团队提供更底层的模型能力，主要包括对内容进行风险打分、产生风险提示等。

审核开发团队则负责机审能力的工程化落地，包括根据风险分数做出审核结果的决策、对高危内容的机审豁免、以及提示信息的输出展现等。

机审的整体过程如上图4-1所示：

1. 用户生成内容后，首先在业务侧生成资源，并推送审核平台

2. 审核平台首先做进审策略的判断，策略中包含同步机审的结果同时同步返回业务方

3. 对于需要进审的资源，会根据业务的审核流程进行分发。如果是需要机审的资源，则发送异步消息同步算法团队，即异步机审；否则直接推人审

4. 算法团队处理完后，将机审结果同样异步返回审核平台，审核平台根据风险分数、豁免条件等做最终机审结果的结算

5. 机审结算结果如果需要人审，则继续推送人工审核，否则直接将审核结果同步业务方

机审的本质是发现风险的能力。随着机审的不断进步，它不仅能够对用户增量的数据进行风险判定，还会对已开放的存量数据进行分析，例如对历史高播放量内容进行模型风险判定。对于识别出的风险数据，需要推送给人审进行进一步审核。

审核平台提供了配置化的接入能力，打通了机审召回的AI送审、人工审核、回调业务方的完整流程。这进一步发挥了机审在内容安全领域的作用。

^图4-2

机审召回的整体过程如上图4-2所示：

1. 算法团队对满足阈值的资源过风险模型

2. 命中风险模型的资源推送审核平台，审核平台进行人审分发和审核结果结算

3. 审核平台将人审结果同步给业务方，业务方变更资源状态

在审核平台中，审核资源在进入平台后可能需要经过多轮审核流程，例如机器审核、先发后审、先审后发、一审、二审等环节。根据审核结果，这些资源可能会被开放给用户或者被锁定（由于不符合规范）。这个流程的运转需要依赖于流程网来控制。

最初，审核平台是基于有色Petri网理论实现的一套流程网。然而，这种实现方式的代码复杂度高，与业务代码紧密耦合，导致迭代成本高。此外，配置化学习成本较高，操作难度大，容易出错。

因此，我们基于BPMN理论实现了一套新的流程服务。这套服务能够更好地控制审核流程的运转，降低代码复杂度和耦合度，降低迭代成本，并简化配置化学习过程，减少出错的可能性。

BPMN指业务流程建模标注（Business Process Modeling Notation），它是一套规范标准，通过一些基本图形元素来组合成一个业务流程图（Business Process Diagram），流程服务采用了BPMN的核心元素来构建流程网，将BPMN的元素转换为DOT脚本后，通过DSL语义将其转换为后端数据模型。

以评论回查业务为例：

上图是流程服务根据DSL语义，编写符合BPMN规范以及稿件业务流程诉求的DOT脚本后，所生成的评论回查审核流程图。

• 分支优先级: 提供优先级配置，当多个分支条件都命中时，会返回最高优先级分支。

• default分支:用来兜底，不需要配置条件，完美避免卡流程问题。

• 支持按条件配置: 通过指定的条件，如是否为特殊分区等信息，来进行流程扭转。

它具有如下功能和特点：

• 提供非常简单的API供业务方接入及快速定位问题

• 采用了CQRS架构：从而将流程网管理平台和流程引擎解耦，避免影响彼此功能：

1.流程网管理平台用于流程网管理，服务于管理人员，条件查询场景多

2.流程引擎服务于业务方，量级大，无需关系查询场景

• 高性能：

1.DOT流程网本地缓存，绝大部分逻辑基于内存运行，少量操作依赖taishan-kv存储，处理速度快

2.使用taishan-kv存储，用来保存流程实例信息

• 热部署：监听流程网变更，实时加载到内存

• 多版本管理，灰度上线，支持回滚

• 支持复杂条件扭转，支持并行流程

在审核平台接入流程服务后，所有存量业务已经成功完成从Petri网到新流程网的迁移，日常涉及到业务流程迭代变更的需求可降至分钟级支持，并通过热部署实时生效，提高了流程变更的效率；同时提供了灰度及回滚功能保证功能的稳定性。

平台能力进一步得到完善，具备多种辅助审核安全的功能，可以在多个业务线上开箱即用。

质检是一种在审核流程中引入的二次审核方式。随着业务的发展和复杂性增加，传统的一次审核流程难免会出现审核准确性不足、漏洞或错误等问题。为了确保审核结果的高质量和准确性，质检作为一种补充手段逐渐得到应用。

引入质检机制后，可以期望在审核流程中获得更好的结果。通过发现和修正审核错误，减少了因审核不准确而可能引发的问题。此外，质检还可以帮助标准化审核标准和流程，确保审核决策的一致性和可比性。最终，这种改进有助于提升审核的效率和效果，为业务运营提供更可靠的支持。

为了确保内容安全，每一条内容都需要经过人工的审核确认。审核的准确性至关重要，同时对审核结果的二次核验也是必要的。然而，考虑到审核人力成本、审核效率和用户体验等因素，通常采用审核后质检的方式来进行二次确认，但这具有一定的滞后性，造成的影响难以消除。因此，需要一种预防性的功能，可以针对重点内容进行二次核验，确保重点内容有多人交叉审核确认，降低高危内容漏放的风险。

如上图6-2所示，通过采用一种透明无感知的交叉双盲审核方法，对一些高危资源的审核提前进行多重交叉审核，及时发现问题，避免高危内容被漏放。

在日常审核工作中，审核员可能会出现因主观因素或专业能力问题而导致的风险内容评判标准不一、审核不准确的情况。这类问题通常采用审核后质检的方式来评估。然而，这种方法存在滞后性，只能对审核人员进行事故归责教育，已造成的影响无法消除，风险也无法提前预判规避。因此，我们参考军事演习中的红蓝对抗模式，将其引入到审核系统中，将一线审核员视为红军守方，对抗服务视为蓝军攻方。蓝方通过伪装风险内容送审来考验红方审核能力，以攻促防，提高审核安全性。

^图6-3

与传统的审核培训方式对比，审核红蓝对抗采用红蓝题目和对抗任务的方式进行场景模拟，采用以攻促防让审核员更加接近实战，能较好的体现出一线审核面临的真实威胁，也能更好地发现审核员在安全正向建设中的不足。

其他一些辅助工具，例如知识库、特征库、新人模式、工时管理、消息推送和数据报表等，由于篇幅限制，这里不再详细阐述。

• https://pkg.go.dev/go/[email protected]

• https://www.graphviz.org/doc/info/lang.html

• https://www.bpmn.org/

• https://link.springer.com/chapter/10.1007/0-8176-4488-1_2

以上是今天的分享内容，如果你有什么想法或疑问，欢迎大家在留言区与我们互动，如果喜欢本期内容的话，欢迎点个“在看”吧！