百度信誉认证中台架构解析
导读：百度信誉认证是以人工智能、企业大数据等技术能力为基础，搭建的面向企业、机构以及个人等主体的核验系统化服务平台，旨在为不同行业和业务领域提供身份识别、反欺诈、信息核验等系列产品能力及一体化解决方案。百度信誉认证，涵盖风控与增信两大核心服务，主要为信息分发平台、互动文娱平台、行业垂类、知识垂类、商业产品等提供合规的客户与可信的内容。其业务目标在于：围绕生产者及其提供的内容和服务，构建百度信誉认证生态，让用户放心的在百度获取信息和服务。
全文5460字，预计阅读时间 12分钟。
一、背景
百度信誉认证的业务目标在于：围绕生产者及其提供的内容和服务，构建百度信誉认证生态，让用户放心的在百度获取信息和服务。其中：风控能力，通过提供准入门槛，降低业务风险，解决的是“它是谁，出了问题该找谁”的业务痛点；增信能力，则通过增信背书，提升信任度，比如：通过个人用户身份职业认证、机构用户官方认证来认证生产者的身份职业社会位置，通过兴趣爱好者认证来认证生产者提供内容的领域专业性。
图（1）
二、业务架构全景
百度信誉认证是以人工智能、企业大数据等技术能力为基础，搭建的面向企业、机构以及个人等主体的核验系统化服务平台，旨在为不同行业和业务领域提供身份识别、反欺诈、信息核验等系列产品能力及一体化解决方案。通过对生产者客观身份，所在领域，生产能力，影响力等维度判断，输出认证结果，为业务提供准入筛选等风控作用。除此之外，通过认证信息的对外披露，为内容和服务的提供者提升可信度，辅助用户的选择和决策。它的总体架构如下图（2）所示：
图（2）
（1）接入层：通过统一认证标识，实现屏蔽业务方的多帐户体系对系统的影响；提供统一的系统鉴权能力，最大粒度减少业务方在接入层的实现成本；
（2）认证方案：为满足业务方的不同认证诉求，我们提供了多种类的认证方案供业务方选择，如资质类、行业类、网站类等；如果已有的认证方案不能满足业务方诉求，则可以通过更小粒度的认证能力进行重新组合，组合成新的认证方案来服务于业务方；
（3）能力地图：认证中台历经多年，沉淀了很多认证能力，这些能力既可以独立为企业或个人提供认证服务，也可以通过流程引擎的配置来组成为某种复杂的认证方案来提供服务。随着网络科技和信息的不断变化，认证中台的能力地图也一直在不断丰富；
（4）共享技术：在能力地图不断丰富的同时，认证中台在技术上也在持续沉淀出各种技术组件，这些技术组件的复用可以使认证中台在接入业务时的开发效率大大提升；
（5）最下层是百度的大数据和各种基础架构（如BOS、BDRP等）是认证中台搭建的基石。
百度信誉认证产品详解如下图（3）所示：
风控能力，细分为资质认证、实名认证、实地认证等，认证方式丰富多样，可以满足业务方业务准入需求；
增信能力，则涵盖身份职业认证、官方认证、兴趣领域认证、V认证等，认证通过后将进行认证结果展示。
图（3）
三、认证中台技术架构
为了满足业务上持续、快速的发展需求，提升各业务方的接入效率，研发团队将认证平台的技术架构全面中台化，在2019年完成了认证中台一期的搭建，沉淀了越来越丰富的认证能力和认证方案。总体技术架构如图（4）所示：
图（4）
（1）能力管理：目标是基于现有业务、以及未来可能的业务进行服务抽象和业务剥离，包含能力标准制定、能力的注册和发现、能力的管控和度量等。目前已沉淀认证能力包括：对公认证、资质认证、身份职业认证等。
（2）方案管理：能力是基础，认证方案才是我们最终提供给前台业务的载体。方案建设的思路是对认证的业务进行场景化方案的沉淀，在这一层实现能力的编排、方案的自动化自建等。目前已提供机构类的资质认证方案、电子营业执照认证方案等、个人类实名认证方案等；
（3）共享数据：实现认证数据和结果的互认互通，减少业务方和中台方的重复开发，实现一次认证，多处复用；
（4）可视化的中控平台：当前是由移动开发者中心来承接。作为中台能力的门户，承载方案介绍、能力视图等功能，也是业务接入入口，业务方需在此申请具体的服务接口、配置QPS等；
（5）中台能够对服务进行分流、限流甚至是降级，避免不同级别的业务间互相造成影响；流量监控可以实时的知道各种的流量情况，比如消息流量，接口调用流量等；服务的调用，很可能因为网络或宕机之类的原因造成数据不一致，通过业务一致性平台，可以提供运营工具来配置想要监控或定位哪个业务的哪些数据的一致性，这些手段的目标都是要确保中台的稳定性达到标准或更高。
四、核心认证能力介绍
4.1 统一认证
2020年，跟随公司战略脚步，MEG所有内容生产者要实现帐号打通，内容进入统一数据流分发， B端统一百家号品牌。包括号体系统一（百家号）、昵称统一、认证统一、主页统一及数据流统一。
百度信誉为所有B端内容生产者提供统一认证服务，一期为各业务提供通用认证服务，包括实名认证、身份职业认证、官方认证、兴趣领域认证、加V认证。
在此背景下，认证中台研发团队考虑，可以为所有的B端业务方提供一套统一的认证解决方案，目标是尽量减少各业务方的接入成本、各研发团队间的联调成本，实现快速上线。最终，统一认证架构如下图（5）所示：
图（5）
（1）数据获取与转换：每一种认证服务（比如身份职业认证、兴趣领域认证等）的数据源均来源于各业务方，我们提供多种数据接入方式（同步拉取、离线拉取、DTS等），尽量不让业务方有多余的开发工作。我们会把每一个业务方的数据进行预处理（处理规则配置化）。
（2）核心计算逻辑处理：它的工作是要把元数据（比如 1、2、3）按照配置好的规则换算成每一个计算维度（如B、C、D）的值，再根据每一种认证服务的准入和释出规则（比如 B>C>D）来进行结果聚合，来计算出当前是否符合准入或释出。
（3）统一巡查：对于那些已经完成认证服务的业务方的用户来说，它的认证结果不是一成不变的，如果它已经符合释出规则，则要将它及时进行释出。统一巡查的工作就是要实现巡查的快速、准确，设置熔断机制和下线机制，产出释出报表和邮件。
（4）数据变更处理：认证结果是通过bigpipe进行异步下发，业务方只需订阅对应的bp消息来完成结果接收。
当前，统一认证服务已覆盖百度B端的开号准入、获取权益等业务场景，提供多元化认证服务，并在百家号、好看、知道、汽车等业务落地。
4.2 资质认证中心
认证中台能力的孵化沉淀，第一个也是最重要的一个就是面向资质的资质认证中心。资质认证是认证中台中最重要，使用最多，样式最多变，业务逻辑最复杂的认证能力；大约3/4相关的认证能力，都是与资质认证有关。仅一个医疗项目，涉及到的行业资质就超过50项。
资质类认证过程为：1. 认证中台为业务方提供各种类型的资质的提交功能；2. 业务方提交内容后由认证中台完成机审/人审；3. 认证结果同步至业务方。认证过程比较简单，但复杂之处在于：随着产品线接入的越来越多，业务的差异化越发明显，各业务的提交模式，交互方式都有所不同；并且这些变化因子之间又存在着复杂的交互关系。作为中台我们不希望为简单功能做过多定制化开发，既浪费时间和人力，也不符合中台发展方向。
那么问题就是：如何满足这些业务需求？如何破解人力的不足？如何解决研发人员业务理解成本的负担？以及如何让用户通过更高效，体验更好的方式进行认证。
就像软件工程经典著作《人月神话》中所说的，在解决软件工程的的根本问题上，没有银弹。一套最合适的架构设计和对架构的实现，才是破解问题的关键。
既然定制需求越来越多，那么是否可以抽象出最小粒度模板？是否可以通过快速、灵活组装这些模板以实现一个提交模块？就像玩七巧板玩具一样。即：产品方案 = 不同认证能力的组合+复用。
设计思路如下图（6）所示：
图（6）
（1）数据抽象与流程抽象：我们把认证数据抽象为最小粒度，比如：营业执照是一个完整的认证项，这个认证项包括三个字段：编号、照片、有效期；每一个字段对应某一种数据类型，比如编号是文本类型；同时可以为每一个字段在该类型上设置属性，比如文本类型的编号有最小和最长的长度限制。
（2）数据复用与自动渲染：当某一用户在某一个业务里已经提交过某个认证项的数据时，当另外一个业务有相同认证项时，无需重复定义认证项、重复提交，既节省开发时间，也提升用户体验。自动渲染是指在（1）中我们将认证项定义好字段、类型、属性后，前端会根据约定自动生成一个对应的提交模板，无需再定制化进行前端的开发；
（3）平台化与自助管理：所有的认证项的定义、组合、设置，完全可以由产品经理同学在平台上自主完成，自主设置上下线，全程无需研发同学参与。
在此思路的指导下，我们实现了通用资质认证平台。平台分为三个部分，如下图（7）所示：
图（7）
（1）认证项的配置管理模块：实现认证数据统一管理，配置化完成，资质提交页模板自动生成
（2）产品认证逻辑引擎模块：通过服务分发，将不同的认证逻辑分发到不同的服务处理。在服务处理过程中，针对通用逻辑，直接走通用的认证流程，对于通用认证不能处理的逻辑，通过实现统一的服务接口，实现少量的代码，即可将个性逻辑融入到整个系统中。在认证服务执行的前后，还设置了不同的监听接口，对于一些复杂的认证逻辑，通过实现监听接口实现。比如，对于对公账户验证这样的认证，用户提交对公信息可以通过通用的数据提交检索逻辑完成，但是信息提交完成后还需要跟百付宝交互，让百付宝打款，打款的逻辑就可以在后置监听中实现。总之，通过接口，实现整体框架的统一性；
（3）通用服务模块：抽取了共用逻辑，实现数据接口模板化，减少重复开发
认证内容的自动化生成，本质上是一个面向抽象过程的系统的设计；由以往的面向需求开发，变成面向角色开发。系统的Usercase从面向用户扩展为：产品设计师，UI交互设计师，数据模版设计者，审核模版设计者，触发器规则设计者，巡查项规则设计者，最后才面向用户。这些角色在资质中心通过组合的脚手架，可以快速建立起一个资质认证产品。
4.3 流程引擎
有了这些脚手架搭建出来的各种解决方案。并不能直接换成可运行的系统。对于研发人员来说，需要在知识储备中，保存大量有关业务流程的内容，在很多项目中，流程问题往往占据软件问题的多数。如何把中台开发者从业务理解的知识海洋中解脱出来。于是我们设计了这样一套工作流引擎，来实现认证能力的编排。引擎的核心构成是决策节点和路由器，流程配置中心以及插件容器。
对于流程设计者的建模方式为：1.梳理->2.设计建模→3.模拟。引擎运行在ODP扩展上，面向phper开发者更加友好，基于zk做配置服务，可以在运行时做流程升级和下发；节点预留同步+异步触发器，实现多实例协同执行。
流程引擎的设计思路如下图（8）所示：
图（8）
（1）每一个服务都是一个独立组件，可单独开发和部署。
（2）支持普通节点、决策节点、聚合节点等多种节点类型，以满足业务的各种需求；
（2）通过引擎的自动流转来实现一个完整的认证解决方案，减少过多业务逻辑代码的耦合。
4.4 智能化认证
从2017年开始，随着内容生态的客户规模爆发式增长，我们意识到现行的认证方案必将成为制约业务发展的瓶颈；我们开始尝试通过AI的手段来创新认证方案；当时用paddlepaddle上跑分类模型，做OCR识别文字内容。当时正值熊掌号品牌快速建设期，我们将抛出来的分别识别模型，应用在熊掌号的机审之上，一定程度上提高了审核的效率，降低了审核的工作量。
对于用户来说，申请方式仍然没有发生质的变化，以上是提交资质，等待人工审核结果。同时，资质类别支持的太少，泛化能力有限。
研发团队进一步分析，认证的本质是什么？简单来说认证就是对经营资质，经营人员，经营场所的信息进行收集，鉴别真伪。在之前，我们为此开发了大量mis系统。这些认证过程，在本质上是有明确的规则可循，可以作为AI的应用方向。为了实现多样复杂的认证信息的采集，我们需要认证端具备手机APP一样的原生能力，并且需要具备较好的迁移能力。在我厂小程序还在内测阶段我们便开发出第一版基于小程序的智能认证解决方案。
由于印刷、光线、遮挡等实际原因；最开始我们自己的识别模型厂内IDL资质模版识别，以及对比厂外的识别模型，在生产环境下最常见的资质整体召回率都不足80%,无法达到落地推广能力要求。在分析无法召回的badcase时，发现人可以准确的推断出来 不清晰的字是什么，是因为知识储备+推理；虽然我们无法让机器具备人所具备的知识体系，但是我们可以利用企业信用大数据，通过在数据上的能力，去补齐在识别度上的短板。
图（9）
由此，我们进一步推出了资质智能认证服务，如图（10）所示：
图（10）
资质智能认证是认证中台提供一种基于企业信用大数据，图像识别技术等提供的常见资质的的认证解决方案；从资质识别，分类，官方数据验证。在交互上，可提供面向后台的机审服务API，面向用户/客户的智能认证小程序。
把全量企业信息在ES中建立索引，将识别的内容进行相似度检索，对相似数据再做二次认证，官方比对。整体资质准确率：98%；证照类的认证效率大幅提升，现已经在多个产品线里广泛使用。
五、发展与思考
未来，在业务上，我们将持续深耕内容认证，探索服务认证，让用户在百度获取的内容和服务更加准确可信。在技术上，认证中台研发团队会通过细分认证节点等方式来提升认证的效率，进一步加大智能机审的能力，减少人工认证成本；在标签覆盖上会由被动等待用户申请，变为主动挖掘潜力用户，从而推进这些用户进一步成为优质内容生产者，进而为百度贡献更多更好的优质内容，服务于网民。
招聘信息