導讀：百度信譽認證是以人工智能、企業大數據等技術能力爲基礎，搭建的面向企業、機構以及個人等主體的核驗系統化服務平臺，旨在爲不同行業和業務領域提供身份識別、反欺詐、信息覈驗等系列產品能力及一體化解決方案。百度信譽認證，涵蓋風控與增信兩大核心服務，主要爲信息分發平臺、互動文娛平臺、行業垂類、知識垂類、商業產品等提供合規的客戶與可信的內容。其業務目標在於：圍繞生產者及其提供的內容和服務，構建百度信譽認證生態，讓用戶放心的在百度獲取信息和服務。

一、背景

百度信譽認證的業務目標在於：圍繞生產者及其提供的內容和服務，構建百度信譽認證生態，讓用戶放心的在百度獲取信息和服務。其中：風控能力，通過提供准入門檻，降低業務風險，解決的是 “它是誰，出了問題該找誰” 的業務痛點；增信能力，則通過增信背書，提升信任度，比如：通過個人用戶身份職業認證、機構用戶官方認證來認證生產者的身份職業社會位置，通過興趣愛好者認證來認證生產者提供內容的領域專業性。

二、業務架構全景

百度信譽認證是以人工智能、企業大數據等技術能力爲基礎，搭建的面向企業、機構以及個人等主體的核驗系統化服務平臺，旨在爲不同行業和業務領域提供身份識別、反欺詐、信息覈驗等系列產品能力及一體化解決方案。通過對生產者客觀身份，所在領域，生產能力，影響力等維度判斷，輸出認證結果，爲業務提供准入篩選等風控作用。除此之外，通過認證信息的對外披露，爲內容和服務的提供者提升可信度，輔助用戶的選擇和決策。它的總體架構如下圖（2）所示：

**（1）接入層：**通過統一認證標識，實現屏蔽業務方的多帳戶體系對系統的影響；提供統一的系統鑑權能力，最大粒度減少業務方在接入層的實現成本；

**（2）認證方案：**爲滿足業務方的不同認證訴求，我們提供了多種類的認證方案供業務方選擇，如資質類、行業類、網站類等；如果已有的認證方案不能滿足業務方訴求，則可以通過更小粒度的認證能力進行重新組合，組合成新的認證方案來服務於業務方；

**（3）能力地圖：**認證中臺歷經多年，沉澱了很多認證能力，這些能力既可以獨立爲企業或個人提供認證服務，也可以通過流程引擎的配置來組成爲某種複雜的認證方案來提供服務。隨着網絡科技和信息的不斷變化，認證中臺的能力地圖也一直在不斷豐富；

**（4）共享技術：**在能力地圖不斷豐富的同時，認證中臺在技術上也在持續沉澱出各種技術組件，這些技術組件的複用可以使認證中臺在接入業務時的開發效率大大提升；

（5）最下層是百度的大數據和各種基礎架構（如 BOS、BDRP 等）是認證中臺搭建的基石。

百度信譽認證產品詳解如下圖（3）所示：

風控能力，細分爲資質認證、實名認證、實地認證等，認證方式豐富多樣，可以滿足業務方業務准入需求；

增信能力，則涵蓋身份職業認證、官方認證、興趣領域認證、V 認證等，認證通過後將進行認證結果展示。

三、認證中臺技術架構

爲了滿足業務上持續、快速的發展需求，提升各業務方的接入效率，研發團隊將認證平臺的技術架構全面中臺化，在 2019 年完成了認證中臺一期的搭建，沉澱了越來越豐富的認證能力和認證方案。總體技術架構如圖（4）所示：

**（1）能力管理：**目標是基於現有業務、以及未來可能的業務進行服務抽象和業務剝離，包含能力標準制定、能力的註冊和發現、能力的管控和度量等。目前已沉澱認證能力包括：對公認證、資質認證、身份職業認證等。
**（2）方案管理：**能力是基礎，認證方案纔是我們最終提供給前臺業務的載體。方案建設的思路是對認證的業務進行場景化方案的沉澱，在這一層實現能力的編排、方案的自動化自建等。目前已提供機構類的資質認證方案、電子營業執照認證方案等、個人類實名認證方案等；

**（3）共享數據：**實現認證數據和結果的互認互通，減少業務方和中臺方的重複開發，實現一次認證，多處複用；

**（4）可視化的中控平臺：**當前是由移動開發者中心來承接。作爲中颱能力的門戶，承載方案介紹、能力視圖等功能，也是業務接入入口，業務方需在此申請具體的服務接口、配置 QPS 等；

（5）中臺能夠對服務進行分流、限流甚至是降級，避免不同級別的業務間互相造成影響；流量監控可以實時的知道各種的流量情況，比如消息流量，接口調用流量等；服務的調用，很可能因爲網絡或宕機之類的原因造成數據不一致，通過業務一致性平臺，可以提供運營工具來配置想要監控或定位哪個業務的哪些數據的一致性，這些手段的目標都是要確保中臺的穩定性達到標準或更高。

四、核心認證能力介紹

4.1 統一認證

2020 年，跟隨公司戰略腳步，MEG 所有內容生產者要實現帳號打通，內容進入統一數據流分發， B 端統一百家號品牌。包括號體系統一（百家號）、暱稱統一、認證統一、主頁統一及數據流統一。

百度信譽爲所有 B 端內容生產者提供統一認證服務，一期爲各業務提供通用認證服務，包括實名認證、身份職業認證、官方認證、興趣領域認證、加 V 認證。

在此背景下，認證中臺研發團隊考慮，可以爲所有的 B 端業務方提供一套統一的認證解決方案，目標是儘量減少各業務方的接入成本、各研發團隊間的聯調成本，實現快速上線。最終，統一認證架構如下圖（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）所示：

**（1）數據抽象與流程抽象：**我們把認證數據抽象爲最小粒度，比如：營業執照是一個完整的認證項，這個認證項包括三個字段：編號、照片、有效期；每一個字段對應某一種數據類型，比如編號是文本類型；同時可以爲每一個字段在該類型上設置屬性，比如文本類型的編號有最小和最長的長度限制。

**（2）數據複用與自動渲染：**當某一用戶在某一個業務裏已經提交過某個認證項的數據時，當另外一個業務有相同認證項時，無需重複定義認證項、重複提交，既節省開發時間，也提升用戶體驗。自動渲染是指在（1）中我們將認證項定義好字段、類型、屬性後，前端會根據約定自動生成一個對應的提交模板，無需再定製化進行前端的開發；

**（3）平臺化與自助管理：**所有的認證項的定義、組合、設置，完全可以由產品經理同學在平臺上自主完成，自主設置上下線，全程無需研發同學參與。

在此思路的指導下，我們實現了通用資質認證平臺。平臺分爲三個部分，如下圖（7）所示：

**（1）認證項的配置管理模塊：**實現認證數據統一管理，配置化完成，資質提交頁模板自動生成

**（2）產品認證邏輯引擎模塊：**通過服務分發，將不同的認證邏輯分發到不同的服務處理。在服務處理過程中，針對通用邏輯，直接走通用的認證流程，對於通用認證不能處理的邏輯，通過實現統一的服務接口，實現少量的代碼，即可將個性邏輯融入到整個系統中。在認證服務執行的前後，還設置了不同的監聽接口，對於一些複雜的認證邏輯，通過實現監聽接口實現。比如，對於對公賬戶驗證這樣的認證，用戶提交對公信息可以通過通用的數據提交檢索邏輯完成，但是信息提交完成後還需要跟百付寶交互，讓百付寶打款，打款的邏輯就可以在後置監聽中實現。總之，通過接口，實現整體框架的統一性；

**（3）通用服務模塊：**抽取了共用邏輯，實現數據接口模板化，減少重複開發

認證內容的自動化生成，本質上是一個面向抽象過程的系統的設計；由以往的面向需求開發，變成面向角色開發。系統的 Usercase 從面向用戶擴展爲：產品設計師，UI 交互設計師，數據模版設計者，審覈模版設計者，觸發器規則設計者，巡查項規則設計者，最後才面向用戶。這些角色在資質中心通過組合的腳手架，可以快速建立起一個資質認證產品。

4.3 流程引擎

有了這些腳手架搭建出來的各種解決方案。並不能直接換成可運行的系統。對於研發人員來說，需要在知識儲備中，保存大量有關業務流程的內容，在很多項目中，流程問題往往佔據軟件問題的多數。如何把中臺開發者從業務理解的知識海洋中解脫出來。於是我們設計了這樣一套工作流引擎，來實現認證能力的編排。引擎的核心構成是決策節點和路由器，流程配置中心以及插件容器。

對於流程設計者的建模方式爲：1. 梳理 ->2. 設計建模→3. 模擬。引擎運行在 ODP 擴展上，面向 phper 開發者更加友好，基於 zk 做配置服務，可以在運行時做流程升級和下發；節點預留同步 + 異步觸發器，實現多實例協同執行。

流程引擎的設計思路如下圖（8）所示：

（1）每一個服務都是一個獨立組件，可單獨開發和部署。

（2）支持普通節點、決策節點、聚合節點等多種節點類型，以滿足業務的各種需求；

（2）通過引擎的自動流轉來實現一個完整的認證解決方案，減少過多業務邏輯代碼的耦合。

4.4 智能化認證

從 2017 年開始，隨着內容生態的客戶規模爆發式增長，我們意識到現行的認證方案必將成爲制約業務發展的瓶頸；我們開始嘗試通過 AI 的手段來創新認證方案；當時用 paddlepaddle 上跑分類模型，做 OCR 識別文字內容。當時正值熊掌號品牌快速建設期，我們將拋出來的分別識別模型，應用在熊掌號的機審之上，一定程度上提高了審覈的效率，降低了審覈的工作量。

對於用戶來說，申請方式仍然沒有發生質的變化，以上是提交資質，等待人工審覈結果。同時，資質類別支持的太少，泛化能力有限。

研發團隊進一步分析，認證的本質是什麼？簡單來說認證就是對經營資質，經營人員，經營場所的信息進行收集，鑑別真僞。在之前，我們爲此開發了大量 mis 系統。這些認證過程，在本質上是有明確的規則可循，可以作爲 AI 的應用方向。爲了實現多樣複雜的認證信息的採集，我們需要認證端具備手機 APP 一樣的原生能力，並且需要具備較好的遷移能力。在我廠小程序還在內測階段我們便開發出第一版基於小程序的智能認證解決方案。

由於印刷、光線、遮擋等實際原因；最開始我們自己的識別模型廠內 IDL 資質模版識別，以及對比廠外的識別模型，在生產環境下最常見的資質整體召回率都不足 80%, 無法達到落地推廣能力要求。在分析無法召回的 badcase 時，發現人可以準確的推斷出來 不清晰的字是什麼，是因爲知識儲備 + 推理；雖然我們無法讓機器具備人所具備的知識體系，但是我們可以利用企業信用大數據，通過在數據上的能力，去補齊在識別度上的短板。

由此，我們進一步推出了資質智能認證服務，如圖（10）所示：

資質智能認證是認證中臺提供一種基於企業信用大數據，圖像識別技術等提供的常見資質的的認證解決方案；從資質識別，分類，官方數據驗證。在交互上，可提供面向後臺的機審服務 API，面向用戶 / 客戶的智能認證小程序。

把全量企業信息在 ES 中建立索引，將識別的內容進行相似度檢索，對相似數據再做二次認證，官方比對。整體資質準確率：98%；證照類的認證效率大幅提升，現已經在多個產品線裏廣泛使用。

五、發展與思考

未來，在業務上，我們將持續深耕內容認證，探索服務認證，讓用戶在百度獲取的內容和服務更加準確可信。在技術上，認證中臺研發團隊會通過細分認證節點等方式來提升認證的效率，進一步加大智能機審的能力，減少人工認證成本；在標籤覆蓋上會由被動等待用戶申請，變爲主動挖掘潛力用戶，從而推進這些用戶進一步成爲優質內容生產者，進而爲百度貢獻更多更好的優質內容，服務於網民。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Jm7oPN0azIlWNJB_CrvC_A