意見領袖丨高聲談

　　輾轉了政務、醫療等多個行業后，多數隱私計算公司最終還是選擇將金融業作為優先落地的行業，理由很簡單：作為國內數據化程度最高的行業之一，金融業有著最為成熟的技術基礎、最強烈的數據場景需求以及雄厚的購買實力。

　　金融業也不負眾望，去年下半年以來先后落地了數十個隱私計算項目，反向印證了上述觀點。但是繁華背后存隱患：我們看到，上述落地案例中實驗、探索項目居多，至今還沒有真正上生產環境的案例出現。

　　其中原因有很多，從供給側看，隱私行業的打法、產品性能與質量等方面存在這不小問題，筆者在《隱私計算公司開拓金融業的意見與建議》、《隱私計算的破局之道》等文章中有過深入分析，不再贅述。此次我們重點從需求側分析銀行等金融機構的疑慮和擔心——對既有風控技術框架的調整與改在成本。

　　銀行傳統風控技術框架

　　通常來講，金融機構風控技術架構的設計思路見下圖：“數據服務平臺”是外部數據調用平臺，承載與外部數據的統一報送與采集功能。為了方便風控建模，銀行一般會單獨設立針對性的風控集市用于模型訓練和預測，不同目的的模型其風控集市差異較大，比如小微企業貸款與個人消費貸款的集市維度連主鍵信息都不一樣，甚至更細致的，個人消費貸款的貸前信用評分卡模型和貸后風險表現模型也會分別建立集市進行支持。

　　我們知道，風控模型分為模型訓練和模型預測（模型運行）兩個階段。

　　模型訓練階段是事前、非實時的，一般是先從數據集市中的存量數據按照一定規則提煉樣本，按照主鍵信息從數據源接口批量查得結果后，結合數據集市中銀行已有的數據特征值一同建模，模型訓練成型后部署在決策引擎之中，準備上生產。

　　在模型預測（模型運行）時，從進件前端或是核心系統傳輸來的進件申請將客戶主鍵信息推動至決策引擎，引擎實時掉起數據集市和數據服務平臺中入模數據的API接口查得數據，一同進入模型中生成模型結果。然后，決策引擎根據核心系統需要展示的決策結果，將各類模型結果打包形成決策包后，統一推送至核心系統及進件前端進行展示。這便是最簡單的模型訓練、預測的全流程。

　　隱私計算重構了風控技術框架

　　我們首先分析隱私計算承載著何種職能。

　　由于部分設計個人隱私的數據的價值必須通過隱私產品交互獲得，且這些數據無法移出隱私產品，必須在隱私產品內進行模型訓練和預測，因此隱私計算產品替代了決策引擎的計算模塊和部分數據服務平臺職能。

　　模型訓練階段還是事前、非實時的，與之前不同的是，銀行需將從數據集市中提煉的樣本（包含主鍵信息和銀行端存量特征值）一同灌入隱私計算產品之中，在隱私產品中與不同數據源的節點互動迭代生成模型。需要強調的是，此時的成型模型不能移出，只能存放在隱私產品之中。

　　隱私行業所說的建模速度損耗就是指的該階段，受算力和網絡傳輸的影響，當前的隱私計算建模效率至少是明文狀態的百倍。這還不包括從數據集市到隱私計算產品之間的傳輸環節。

　　模型預測（運行）時，由于銀行接入了央行征信、百行征信等很多其它合規數據源（而這些數據源是明文差得的），因此還是不能繞開決策引擎和原有的數據服務平臺。合意的做法是：還是將進件申請獲得的客戶主鍵信息推動至決策引擎，先由決策引擎通過數據服務平臺，從央行征信等系統查得明文數據，從風控集市中查得銀行存量數據標簽后，與主鍵信息一起灌入隱私計算產品之中，在隱私產品中實現與三方隱私數據節點的交互，并一同導入成型模型中計算出結果。

　　由于隱私產品很難結合核心系統和進件前段系統進行個性化改造，因此將多個模型結果打包生成決策包的工作還需決策引擎承擔。隱私計算平臺要將計算得出的模型預測（模型運行）結果推給決策引擎，形成指令集后由決策引擎推送至核心系統及進件前端進行展示。

　　因此，調整后的風控技術架構見下圖。與之前相比，合意的設計框架多了隱私計算平臺這一支路。

　　隱私計算適合從簡單、獨立場景做切入

　　很多銀行等金融機構采用的是統一風控平臺架構，多年沉淀形成的風控信息技術架構遠比上圖刻畫的復雜，對接的系統、個性化的接口包裝復雜多樣，牽一發而動全身，一旦改動，成本巨大。對于這些金融機構，統一風控平臺已經納入公司IT基礎設施之中，對于引入隱私平臺從而涉及的風控平臺調整屬于公司重大基礎設施調整，這就要求隱私產品必須經過多年實踐驗證，足夠安全與穩定后，通過統一招投標納入金融機構集采名單，方能予以使用。從這一點講，隱私計算進入銀行等金融機構核心系統或基礎設施還有很長的一段路要走。

　　比較現實的操作是：在小型業務場景中先行先試隱私計算，單獨搭建整套風控框架和數據庫，做到與統一風控平臺基礎設施的平行運行。為該業務場景建立單獨的數據庫，該數據庫與銀行數據中臺或既有風控數據庫聯通，用于存放并向隱私產品提供提前抽取好的業務相關客戶和特征標簽，同時存儲新生成的業務數據，及時同步至公司數據中臺。

　　交鑰匙隱私計算一體機的出廠配置

　　筆者歷史文章曾經提及，隱私計算一體機的獨有CPU或集成的GPU、FPGA會極大緩解隱私計算算力瓶頸，加之種種其它原因決定了一體機是隱私計算的必然發展方向之一。如果僅是如此，隱私計算一體機距離盡量減少銀行開發調整的“交鑰匙”工程還有不小差距。

　　前文提到，由于單獨存放于數據庫中的風控集市需要與決策引擎、隱私計算產品進行反復查詢和讀寫，因此數據庫對隱私計算產品的支持效率同樣會影響建模效率，因此在一體機中集成進“可以大幅提升反復查詢讀寫的內存式數據庫”或“適應大吞吐量數據查詢讀寫的分布式數據庫”是必須要考慮的問題。

　　隱私計算一體機最好也要有決策引擎的集成方案。由于決策引擎涉及到對業務系統和進件前端的個性化改造與支持，這將是一個或有選擇。決策引擎對核心系統和進件前端系統的個性化適配是在所難免的，要么，集成在一體機之中的隱私產品和數據庫與銀行業務已有的風控決策引擎做連接耦合，要么將決策引擎也集成在一體機之中，針對銀行業務在核心系統及進件前端的個性化展示，將隱私產品的計算結果進行轉換，并生成針對性決策包推送給核心系統。

　　綜上，未來真正具備交鑰匙能力的“隱私計算一體機”，不僅要承載隱私計算產品，還應該同時集成內存式/分布式數據庫，用于存放單獨支撐該業務的風控集市；同時，最好集成能夠滿足銀行業務需求的決策引擎，能夠直接對接業務核心系統以及進件前端系統，當然工程實施時少不了定制化開發耦合。

　　以上是針對銀行新興業務的“隱私計算一體機”交鑰匙版本配置，筆者認為，只有當隱私廠商多做一點，真正做到不改變銀行既有軟硬件適配與架構調整，該隱私產品才真正具備“交鑰匙”能力，如此距離大規模商用化發展之路也就不遠了。

　　(本文作者介紹：保險信貸人，就職于國有大型保險公司，長期關注信用保證保險、線上信貸、數據經濟和隱私計算。)