1. 從哪下手?jǐn)?shù)智金融框架的真實出發(fā)點去年我去某股份行做技術(shù)交流對方數(shù)字化轉(zhuǎn)型部門的負(fù)責(zé)人一開口就說“我們現(xiàn)在不缺技術(shù)缺的是一個能跑的框架。”這句話我印象特別深。市面上關(guān)于數(shù)據(jù)中臺、智能風(fēng)控、實時計算的概念鋪天蓋地但真正落到“數(shù)智金融框架搭建”這個動作上很多人第一反應(yīng)是選型用哪家的大數(shù)據(jù)平臺、買哪款機(jī)器學(xué)習(xí)引擎、上哪個實時計算組件。我后來發(fā)現(xiàn)這個順序恰恰反了。數(shù)智金融框架說到底不是一套軟件組合而是把金融機(jī)構(gòu)最核心的三樣?xùn)|西——數(shù)據(jù)、決策、業(yè)務(wù)——串成一條可運行、可迭代的流水線。數(shù)據(jù)是原料決策是加工邏輯業(yè)務(wù)是交付出口?？蚣艿膬r值在于它定義了原料怎么進(jìn)、加工怎么排、出口怎么送并把這條流水線的運行狀態(tài)透明化讓你能持續(xù)改進(jìn)。所以搭建數(shù)智金融框架第一步不是買服務(wù)器而是想清楚一個問題你的金融機(jī)構(gòu)或者一個金融服務(wù)團(tuán)隊日常最依賴哪些決策這些決策需要哪些數(shù)據(jù)輸入產(chǎn)出之后給誰用、怎么觸發(fā)業(yè)務(wù)動作。這里我給出一個粗粒度的分工方便不同背景的讀者定位自己如果你是技術(shù)負(fù)責(zé)人框架的重點是數(shù)據(jù)鏈路、計算引擎、服務(wù)接口、灰度發(fā)布、可觀測性。如果你是業(yè)務(wù)架構(gòu)師框架的重點是業(yè)務(wù)對象、流程節(jié)點、指標(biāo)口徑、風(fēng)險偏好、產(chǎn)品策略。如果你是團(tuán)隊Leader框架的重點是迭代節(jié)奏、團(tuán)隊協(xié)作方式、評估體系、知識沉淀。這三條線缺一不可。只做技術(shù)最后會造出一個精致的廢墟只做業(yè)務(wù)技術(shù)實現(xiàn)會失控只帶團(tuán)隊沒有工程底座一切都會變成口頭管理。我在實際項目里最喜歡用一個類比數(shù)智金融框架就像一棟樓的水電系統(tǒng)住戶不需要知道管道怎么走的但必須擰開水龍頭就有水、按下開關(guān)燈就亮。水壓不穩(wěn)、電路跳閘才是這棟樓真正要解決的問題。業(yè)務(wù)部門對金融系統(tǒng)的感知就是這樣的——他們不關(guān)心你用的是實時數(shù)倉還是離線批處理他們只關(guān)心今天的數(shù)據(jù)準(zhǔn)不準(zhǔn)、模型跑出來的名單能不能直接用、審批流轉(zhuǎn)要不要等上一整天。所以數(shù)智金融框架搭建項目本質(zhì)上是為金融機(jī)構(gòu)打造一套“水電系統(tǒng)”。評估它的唯一標(biāo)準(zhǔn)就是業(yè)務(wù)使用方能不能像用自來水一樣、按需獲取數(shù)智能力而不被底層的復(fù)雜管道干擾。2. 框架的四層結(jié)構(gòu)與設(shè)計取舍數(shù)智金融框架搭建我在多個項目里沉淀下來一個相對固定的分層結(jié)構(gòu)不一定完全通用但作為起步參考很實用。整個框架分為四層基礎(chǔ)數(shù)據(jù)層、智能加工層、決策服務(wù)層、業(yè)務(wù)交互層。每層之間通過標(biāo)準(zhǔn)化的接口銜接避免“層層滲透”導(dǎo)致系統(tǒng)耦合過深。2.1 基礎(chǔ)數(shù)據(jù)層用一張統(tǒng)一事實底座兜住全局基礎(chǔ)數(shù)據(jù)層是數(shù)智金融框架的底座核心任務(wù)是把分散在各個業(yè)務(wù)系統(tǒng)中的數(shù)據(jù)匯集起來形成一套口徑一致、可追溯的數(shù)據(jù)資產(chǎn)。這里最忌諱的是直接把源系統(tǒng)的表映射過來用而是要做主題域拆分和事實建模。做過金融數(shù)據(jù)的人都有感觸最痛苦的事情不是數(shù)據(jù)量大而是同一業(yè)務(wù)指標(biāo)在不同的部門、不同的歷史時期有完全不同的定義。比如“客戶資產(chǎn)”零售部可能只算存款財富部會加上理財和基金如果差異不可控上層智能模型就是建在沙地上的。我習(xí)慣的做法是建立兩層模型第一層是“核心域模型”覆蓋客戶、產(chǎn)品、協(xié)議、渠道、機(jī)構(gòu)、公共主題第二層是“分析模型”按業(yè)務(wù)條線和場景進(jìn)一步加工。數(shù)據(jù)出口必須統(tǒng)一。2.2 智能加工層規(guī)則與模型的分工協(xié)作智能加工層解決的是“決策依據(jù)怎么產(chǎn)生”的問題。很多金融機(jī)構(gòu)在這里容易陷入一個誤區(qū)——一上來就搞深度學(xué)習(xí)覺得越復(fù)雜的模型越高級。實際上金融業(yè)務(wù)的決策鏈條中規(guī)則系統(tǒng)承擔(dān)著基準(zhǔn)和兜底的作用模型在規(guī)則之上做優(yōu)化和增強(qiáng)。以信貸審批場景為例反欺詐階段的硬性黑名單、多頭借貸紅線就是規(guī)則絕不能交給模型去“學(xué)習(xí)判斷”貸前風(fēng)險評分則適合用機(jī)器學(xué)習(xí)模型捕捉變量間的復(fù)雜關(guān)系。在框架層面我把規(guī)則引擎和模型推理引擎做成兩個獨立模塊統(tǒng)一了輸入和輸出格式。規(guī)則引擎管“硬約束”模型引擎管“軟評估”最后進(jìn)入決策融合層做綜合裁定。這種設(shè)計的核心好處是改規(guī)則不用重新訓(xùn)練模型升模型不影響規(guī)則二者能獨立發(fā)布和回滾。2.3 決策服務(wù)層讓決策成為可編排的“服務(wù)編排圖”決策服務(wù)層的目標(biāo)是把復(fù)雜的智能加工能力封裝成輕量服務(wù)供上層業(yè)務(wù)靈活調(diào)用。參考微服務(wù)的思路將決策邏輯拆分為一系列決策單元如額度計算單元、利率定價單元、風(fēng)險攔截單元、產(chǎn)品推薦單元。設(shè)計時以小步快跑模式推動每個決策單元獨立迭代。在框架實現(xiàn)上我用一個可視化配置的家庭主婦戴維、類似拉條的“決策編排”工具把不同的決策單元編排成完整的業(yè)務(wù)流程——比如營銷場景的“識別-觸達(dá)-轉(zhuǎn)化”編排風(fēng)控場景的“核查-評估-決策-解釋”編排。這樣一個新的業(yè)務(wù)場景上線時不需要從零開發(fā)只需把已有決策單元重新排列。2.4 業(yè)務(wù)交互層把復(fù)雜留給自己把簡單交給用戶業(yè)務(wù)交互層是業(yè)務(wù)方直接使用的出口它的設(shè)計哲學(xué)是“極簡”。不要試圖向業(yè)務(wù)展示你的技術(shù)能力而是直接幫助業(yè)務(wù)人員解決問題。我在框架里只保留三類交互入口實時決策查詢、批量名單推送、指標(biāo)儀表盤。比如客戶經(jīng)理在信貸進(jìn)件時只需輸入客戶信息和申請要素系統(tǒng)返回結(jié)構(gòu)化結(jié)果同時提供是否拒絕、拒絕原因、額度建議、定價建議、風(fēng)險提示。全部以JSON協(xié)議返回不做額外包裝。這三類交互入口已經(jīng)覆蓋約90%的業(yè)務(wù)場景更重要的是它不考驗業(yè)務(wù)團(tuán)隊的“技術(shù)能力”業(yè)務(wù)人員幾乎不需要培訓(xùn)。3. 實操過程從零到一的落地順序與步驟框架總不能停留在PPT上下面這部分是我在真實項目中反復(fù)驗證過的實操路徑。我把它按順序展開按順序執(zhí)行會讓整個過程順利得多。3.1 調(diào)研與現(xiàn)狀盤點沒有最真實的現(xiàn)狀一切都是空談啟動數(shù)智金融框架項目第一步一定是盤家底。這一步關(guān)系到整個項目的邊界需要投入一到兩周時間你甚至可以把期間的大部分時間花在“和人聊天”上。我通常用四張表完成盤點系統(tǒng)清單表有哪些業(yè)務(wù)系統(tǒng)數(shù)據(jù)在哪里由誰維護(hù)數(shù)據(jù)質(zhì)量如何。決策場景表核心業(yè)務(wù)有哪些決策動作當(dāng)前決定方式是人工經(jīng)驗、規(guī)則還是老舊的單點模型。數(shù)據(jù)鏈路表從源系統(tǒng)到當(dāng)前報表、當(dāng)前應(yīng)用數(shù)據(jù)經(jīng)歷了哪些流轉(zhuǎn)加工是否有斷點和重復(fù)開發(fā)。技術(shù)資產(chǎn)表現(xiàn)有技術(shù)平臺包括計算引擎、中間件、模型平臺哪些可以復(fù)用而不是推翻重來。然后和每個業(yè)務(wù)部門做一輪“痛點訪談”。別問“你需要什么數(shù)智能力”而是要問“你現(xiàn)在做這個決策最慢、最煩、最容易出錯的是哪一步”。很多時候業(yè)務(wù)部門說出來的痛點跟技術(shù)想象完全不同只有聽了原話你才能知道框架優(yōu)先級怎么排。3.2 主題域劃分與指標(biāo)口徑的建設(shè)工程盤點完成后最關(guān)鍵的落地動作是設(shè)計主題域。很多團(tuán)隊在這里會陷入“大而全”的失重狀態(tài)把零售、對公、同業(yè)、風(fēng)控全都納入第一版結(jié)果團(tuán)隊忙亂成一個項目交付卻不斷延期。正確做法是第一版只做一到兩個主題域。我遵循的高優(yōu)先級判斷準(zhǔn)則是業(yè)務(wù)痛點最強(qiáng)烈、數(shù)據(jù)基礎(chǔ)相對較好、價值見效最快。優(yōu)先做客戶域和風(fēng)險域?？蛻粲蛑魏罄m(xù)所有以客戶為中心的分析和營銷風(fēng)險域是金融機(jī)構(gòu)數(shù)智化最容易出價值的場景風(fēng)向模型一旦上線收益直接可用不良率、審批時效、欺詐攔截量來度量。主題域確定后要立刻鎖定指標(biāo)口徑。指標(biāo)體系建設(shè)至少要有三層原子指標(biāo)可以從事實層直接計算的、復(fù)合指標(biāo)多個原子指標(biāo)的運算結(jié)果、派生指標(biāo)加上業(yè)務(wù)限定條件的?？趶揭诤诵牟块T之間評審?fù)ㄟ^形成一份指標(biāo)字典。沒有這個字典后面模型做得再好也會前功盡棄。3.3 框架代碼骨架與數(shù)據(jù)開發(fā)流水線的搭建技術(shù)骨架的搭建可以分四步走創(chuàng)建統(tǒng)一的數(shù)據(jù)接入層將不同源系統(tǒng)的數(shù)據(jù)通過CDC或批量抽取機(jī)制入湖以原始分區(qū)方式保存并保留時間戳版本。加工統(tǒng)一的事實表和維度表采用ETL腳本與數(shù)據(jù)質(zhì)量校驗規(guī)則并行開發(fā)質(zhì)量規(guī)則先于數(shù)據(jù)發(fā)布上線。開發(fā)指標(biāo)計算層將口徑固化到配置化的指標(biāo)引擎中不再需要為每個單個指標(biāo)單獨開發(fā)代碼。封裝決策API服務(wù)把規(guī)則引擎、模型引擎、指標(biāo)服務(wù)編排成標(biāo)準(zhǔn)接口統(tǒng)一放上網(wǎng)關(guān)。這里有一個實操上的重要建議第一版本先不要追求純實時。很多團(tuán)隊盲目上Flink、上實時數(shù)倉導(dǎo)致項目周期拉得很長。按我的經(jīng)驗先用T1跑通全部鏈路把數(shù)據(jù)模型的準(zhǔn)確性做扎實再針對少數(shù)高價值場景如實時反欺詐、實時營銷引入實時計算。階段更穩(wěn)妥、風(fēng)險更可控。3.4 治理體系與運維機(jī)制的同步建設(shè)框架上線只是起點“常用常新”才是真正的目標(biāo)。任何一個數(shù)智框架如果等到上線才開始考慮治理就已經(jīng)來不及了。數(shù)據(jù)字典、指標(biāo)口徑、模型版本、規(guī)則變更這些都需要從一開始就建立生命周期管理機(jī)制。具體做法是建立數(shù)據(jù)Owner機(jī)制每個主題域必須有一個明確的數(shù)據(jù)Owner對數(shù)據(jù)口徑、數(shù)據(jù)質(zhì)量、數(shù)據(jù)安全負(fù)責(zé)。這不是技術(shù)負(fù)責(zé)人而是業(yè)務(wù)和技術(shù)雙線共同負(fù)責(zé)。所有的指標(biāo)和模型注冊到元數(shù)據(jù)中心字段命名、負(fù)責(zé)人、血緣關(guān)系、版本歷史一目了然。這一條對于后續(xù)排查問題和人員更替非常重要。建立每周的數(shù)據(jù)質(zhì)量播報抽取核心指標(biāo)進(jìn)行一致性核對發(fā)現(xiàn)問題先報警再定責(zé)。把質(zhì)量問題暴露在過程而不是等年終總結(jié)。3.5 團(tuán)隊配置與交付節(jié)奏的磨合數(shù)智金融框架這類項目如果按傳統(tǒng)瀑布式推進(jìn)大概率會失控。業(yè)務(wù)需求在變數(shù)據(jù)在變技術(shù)的可選方案也在變唯一不變的就是變化本身。我在項目中更傾向于“極簡四角色”的小團(tuán)隊結(jié)構(gòu)數(shù)據(jù)工程師一人負(fù)責(zé)鏈路開發(fā)數(shù)據(jù)分析師一人負(fù)責(zé)口徑和模型特征算法工程師一人負(fù)責(zé)模型訓(xùn)練與評估決策架構(gòu)師一人負(fù)責(zé)整體規(guī)則、模型策略融合和業(yè)務(wù)銜接。四到六人即可跑通全部過程。如果人員多于這個規(guī)模協(xié)調(diào)成本反而會蓋過產(chǎn)出效率。節(jié)奏上按兩周一個迭代第一周開發(fā)與驗證第二周業(yè)務(wù)驗收與復(fù)盤。每次迭代結(jié)束時產(chǎn)出一個業(yè)務(wù)可看到的增量這樣業(yè)務(wù)團(tuán)隊才會持續(xù)給出有效反饋框架才能進(jìn)入正循環(huán)。4. 常見問題與避坑記錄這里分享幾個我在實際項目中反復(fù)遇到的典型問題每一個都帶著真實的代價值得數(shù)智金融框架的搭建者提前了解。4.1 數(shù)據(jù)口徑的“語言之爭”某一次做客戶資產(chǎn)統(tǒng)一視圖零售部認(rèn)為“客戶總資產(chǎn) 存款 理財”財富部認(rèn)為“客戶總資產(chǎn) 存款 理財 基金 保險”。兩個部門各有道理但在統(tǒng)一口徑階段互不相讓。如果技術(shù)團(tuán)隊自己拍板項目就會“粉身碎骨”。我的解決方法是分析層的統(tǒng)一口徑采用“全口徑”即所有產(chǎn)品線資產(chǎn)的總和重點滿足風(fēng)險管理需求同時保留部門級字段作為擴(kuò)展屬性讓業(yè)務(wù)方自己按需過濾。在口徑評審會上直接展示“同一客戶在不同口徑下的資產(chǎn)差異幅度”對比讓業(yè)務(wù)方自己理解差異所在。核心原則是客戶總體風(fēng)險判斷必須用全口徑部門日常經(jīng)營分析可以自行選口徑避免技術(shù)棧綁架業(yè)務(wù)邏輯。4.2 規(guī)則與模型發(fā)布的協(xié)調(diào)問題初期我把規(guī)則引擎和模型引擎分開部署但發(fā)布時機(jī)沒有對齊。有一次模型升級后沒有同步調(diào)整規(guī)則參數(shù)導(dǎo)致線上出現(xiàn)了“規(guī)則拒絕但模型給高分”的矛盾結(jié)果。業(yè)務(wù)電話接踵而至。后來的解法是建立“共同決策回放”機(jī)制每次規(guī)則變更或模型更新都取線上最近7天的歷史樣本做回放比對量化影響面后再實施。并確保新模型和舊規(guī)則進(jìn)行聯(lián)合驗證后方可進(jìn)入生產(chǎn)從流程上杜絕“各管各”造成的隱性沖突。4.3 “實時”執(zhí)念帶來的成本失控退化有個項目一開始就上全鏈路實時計算每個指標(biāo)都要求實時刷新導(dǎo)致開發(fā)周期拉長三倍運維復(fù)雜度急劇上升。復(fù)盤后發(fā)現(xiàn)真正需要實時的只有“反欺詐攔截”和“大額交易監(jiān)控”兩個場景其余完全可以用T1滿足。我自己的經(jīng)驗法則是實時性帶來的業(yè)務(wù)價值必須可量化至少要滿足“時延降低X分鐘可減少Y損失或增加Z收益”否則一律默認(rèn)離線。金融場景不缺炫技的機(jī)會但組織資源有限每一分投入都應(yīng)當(dāng)直接關(guān)聯(lián)業(yè)務(wù)結(jié)果。5. 一些可復(fù)制的配置參考為了讓這份分享更有可參照性我把在常用技術(shù)選型上的參考配置整理成一張表前提是你們團(tuán)隊以Java和Python為主要技術(shù)棧并且允許引入開源組件。模塊選型偏好理由備注數(shù)據(jù)接入Kafka CDC工具成熟度高社區(qū)活躍延遲可控版本選型注意兼容離線計算Spark on Yarn生態(tài)齊全離線處理能力強(qiáng)配置文件與提交參數(shù)標(biāo)準(zhǔn)化實時計算Flink需要實時場景時引入初期可暫不啟用數(shù)據(jù)倉庫ClickHouse Hive多樣混合Hive離線明細(xì)ClickHouse服務(wù)即席查詢和結(jié)果存儲避免單一引擎考慮存儲成本指標(biāo)服務(wù)配置化指標(biāo)中間層支持口徑管理和統(tǒng)一接入邏輯自研為主不依賴閉源產(chǎn)品規(guī)則引擎輕量規(guī)則流引擎用Drools類或自研配置規(guī)則關(guān)鍵是可視化配置和版本管理模型推理Python服務(wù)容器化部署算法團(tuán)隊友好與Java服務(wù)之間用標(biāo)準(zhǔn)接口通信前端交互低代碼配置平臺減少重復(fù)開發(fā)分析師可自主搭建儀表盤這里特別提醒一點選型不是越新越好。業(yè)界被淘汰的框架反而不是最影響成敗的因素最影響的是團(tuán)隊是否真正掌握并持續(xù)守護(hù)它。如果團(tuán)隊里沒人深度用過某個明星組件寧可先用自己熟練的技術(shù)棧。在參數(shù)配置方面最容易被忽略的是數(shù)據(jù)分區(qū)的粒度。在搭建初期建議所有事實表以“業(yè)務(wù)日期更新時間戳”分區(qū)不要只按業(yè)務(wù)日期分區(qū)以便數(shù)據(jù)回溯和重跑場景中對歷史狀態(tài)進(jìn)行追溯。關(guān)于調(diào)度和告警我推薦“十分熟原則”——調(diào)度任務(wù)要設(shè)置超時、重試、失敗告警三個級別的控制每類任務(wù)都要有明確的SLA。數(shù)智框架一旦成為關(guān)鍵路徑數(shù)據(jù)延遲就是業(yè)務(wù)事故必須像對待生產(chǎn)系統(tǒng)一樣對待數(shù)據(jù)任務(wù)。6. 從框架搭建到數(shù)智運營的最后一公里框架搭建項目到這一步基礎(chǔ)設(shè)施已經(jīng)相當(dāng)完備了。但我在多個項目中最深刻的體會是框架真正產(chǎn)生價值往往是在它“不再被特別提及”之后。當(dāng)業(yè)務(wù)方不再關(guān)心數(shù)據(jù)的鏈條、風(fēng)險模型的參數(shù)而是精準(zhǔn)地說“我需要一個針對高價值客戶流失預(yù)警的實時名單”——這時數(shù)智金融框架才算真正完成了從技術(shù)底座到業(yè)務(wù)價值交付的跨越。要做到這一步還有兩個工作必不可少。第一件事是建立反饋閉環(huán)。數(shù)智化能力上線后不等于結(jié)束。模型輸出的推薦名單是否產(chǎn)生了轉(zhuǎn)化、審批決策是否降低了不良率這些結(jié)果數(shù)據(jù)必須自動回流進(jìn)入下一輪的模型迭代和規(guī)則調(diào)優(yōu)?？蚣艿淖罱K形態(tài)是一個不斷在自我進(jìn)化的系統(tǒng)。我見過很多金融機(jī)構(gòu)花了很大的力氣把框架搭起來卻從來沒建立結(jié)果回流機(jī)制能力和業(yè)務(wù)效果越走越遠(yuǎn)——這是最可惜的。第二件事是在組織內(nèi)部建立“體驗文化”。數(shù)智金融框架的服務(wù)對象雖然是業(yè)務(wù)方和客戶但對系統(tǒng)內(nèi)部的每一個使用者而言它的“體驗”同樣重要——這里的體驗指數(shù)據(jù)要可查、指標(biāo)要可解釋、報錯要能定位。如果一個數(shù)據(jù)產(chǎn)品線的分析師發(fā)現(xiàn)自己拿到數(shù)據(jù)還需要跑一堆自定義任務(wù)那反映的其實是框架的數(shù)據(jù)服務(wù)能力沒有做透。我自己在收尾一個數(shù)智金融框架項目時最常做的一件事就是隨機(jī)攔住一位業(yè)務(wù)同事請他現(xiàn)場完成一個日常決策動作然后觀察他需要通過多少步、多少系統(tǒng)查詢才能得到答案。如果步驟越來越接近“一步到位”框架就真正到位了。這個簡單的測試方法比任何技術(shù)指標(biāo)評審都有說服力。最后一點個人建議數(shù)智金融框架的搭建本質(zhì)上是一場持續(xù)演進(jìn)的行為不要追求一次性完成。找到第一個高價值的場景用一兩周的時間上線一版的能力把它交給業(yè)務(wù)使用然后根據(jù)反饋快速迭代這比我見過任何宏大而漫長的“整體規(guī)劃”都要有效。數(shù)智化的本質(zhì)不是做一個空前龐大的系統(tǒng)而是讓組織里的每一個人都能在一杯水燒開的功夫里拿到自己想要的決策答案。