當(dāng)前金融、醫(yī)療、零售這幾個(gè)行業(yè)數(shù)據(jù)是最值錢的資產(chǎn)也是最不敢動(dòng)的資產(chǎn)。我過去兩年一直在做跨行業(yè)聯(lián)邦學(xué)習(xí)平臺(tái)的搭建說白了就是解決一個(gè)非常現(xiàn)實(shí)的問題數(shù)據(jù)不出域模型還能一起練大家還能分到好處。這個(gè)題目聽起來很性感但真正落地的時(shí)候坑比想象中多得多。這篇文章我打算把整套方案的骨架、核心細(xì)節(jié)、實(shí)操過程、還有那些文檔里根本不會(huì)寫的坑一次性講清楚。如果你正準(zhǔn)備在自己的公司里推動(dòng)多方數(shù)據(jù)協(xié)作或者接到了“建一個(gè)聯(lián)邦學(xué)習(xí)平臺(tái)”這種任務(wù)又不想只是搭個(gè)demo交差那這篇內(nèi)容應(yīng)該能幫你省下不少走彎路的時(shí)間。我不講概念層面的花活全是實(shí)際能落地的思路和步驟。1. 項(xiàng)目整體定位聯(lián)邦學(xué)習(xí)到底在解決什么問題1.1 跨行業(yè)數(shù)據(jù)協(xié)作的現(xiàn)實(shí)阻力先聊一個(gè)我在項(xiàng)目啟動(dòng)會(huì)上經(jīng)常舉的例子。某銀行想聯(lián)合幾家保險(xiǎn)公司做反欺詐模型邏輯上非常順——銀行有交易流水和信貸記錄保險(xiǎn)有理賠記錄和核保數(shù)據(jù)兩邊特征互補(bǔ)性極強(qiáng)理論上模型效果能提升一大截。但真到了談數(shù)據(jù)合作的時(shí)候問題就全冒出來了。銀行說我們的客戶明細(xì)是核心監(jiān)管數(shù)據(jù)不可能給你保險(xiǎn)公司說我們的理賠記錄涉及個(gè)人醫(yī)療隱私法務(wù)那關(guān)就過不去。兩家公司的數(shù)據(jù)根本不在一個(gè)池子里連搬到一個(gè)中間服務(wù)器都做不到。就算有公司愿意做那個(gè)“中間方”數(shù)據(jù)的合規(guī)成本、安全責(zé)任、泄露風(fēng)險(xiǎn)全都是一筆算不清的賬。1.2 聯(lián)邦學(xué)習(xí)的核心價(jià)值讓數(shù)據(jù)不動(dòng)模型動(dòng)聯(lián)邦學(xué)習(xí)的技術(shù)思路其實(shí)很樸素——數(shù)據(jù)不用離開各自的公司每一方在自己的本地環(huán)境里訓(xùn)練模型然后把模型參數(shù)或者梯度加密之后傳到中央服務(wù)器去聚合聚合完再把更新后的參數(shù)發(fā)回來如此反復(fù)迭代。這套機(jī)制解決的是“所有權(quán)”和“使用權(quán)”分離的問題。數(shù)據(jù)的所有權(quán)始終在本地方手里任何人拿不到原始數(shù)據(jù)但數(shù)據(jù)的使用權(quán)通過模型參數(shù)的形式被“間接”利用了。用大白話說就是我不把你的賬本拿走我只借鑒你看賬本的思路。正是這種特性讓聯(lián)邦學(xué)習(xí)成了跨機(jī)構(gòu)數(shù)據(jù)協(xié)作里少有的合規(guī)可行性方案。因?yàn)閿?shù)據(jù)不出域大大降低了隱私合規(guī)層面的壓力這也是我推薦跨行業(yè)協(xié)作優(yōu)先考慮這個(gè)技術(shù)路線的原因。1.3 誰最需要這個(gè)東西據(jù)我觀察目前最適合上聯(lián)邦學(xué)習(xí)的場景主要有三類同行業(yè)但不同機(jī)構(gòu)之間的數(shù)據(jù)互補(bǔ)比如多家醫(yī)院聯(lián)合訓(xùn)練醫(yī)療影像模型各家都不想讓影像數(shù)據(jù)出院?？缧袠I(yè)但客戶群重疊度高的場景比如金融機(jī)構(gòu)、電商平臺(tái)、運(yùn)營商三方聯(lián)合做風(fēng)控。集團(tuán)公司內(nèi)部不同子公司之間的數(shù)據(jù)打通業(yè)務(wù)上需要協(xié)作但管理上各有邊界。如果你所在的公司正好有這種“想用別人的數(shù)據(jù)但拿不到”的困境那聯(lián)邦學(xué)習(xí)平臺(tái)就值得認(rèn)真評(píng)估一下了。2. 平臺(tái)架構(gòu)設(shè)計(jì)與方案選型不能上來就寫代碼2.1 先搞清楚的三個(gè)關(guān)鍵問題我在搭建平臺(tái)之前通常會(huì)先問自己和團(tuán)隊(duì)三個(gè)問題。第一個(gè)問題我們的數(shù)據(jù)場景是橫向聯(lián)邦還是縱向聯(lián)邦橫向聯(lián)邦是多個(gè)參與方的樣本不同、特征空間相同比如三家銀行各自有100萬客戶特征都是交易流水縱向聯(lián)邦是參與方的樣本重疊度較高、但特征互補(bǔ)比如銀行有交易特征電商有消費(fèi)習(xí)慣運(yùn)營商有位置軌跡。這兩個(gè)方向的架構(gòu)差異非常大。第二個(gè)問題各方數(shù)據(jù)量級(jí)差異大不大如果一家有1000萬樣本另一家只有1萬樣本那聚合的時(shí)候如果不做特殊處理小數(shù)據(jù)方很快就會(huì)被“淹沒”模型基本等于用大那家的數(shù)據(jù)訓(xùn)練出來的小數(shù)據(jù)方就失去了參與意義。第三個(gè)問題通信和算力條件怎么樣聯(lián)邦學(xué)習(xí)模型每訓(xùn)練一輪就要把參數(shù)傳一輪如果參與方之間網(wǎng)絡(luò)延遲高或者GPU資源緊張訓(xùn)練效率會(huì)非常不理想。這些問題看起來基礎(chǔ)但極大影響后面的技術(shù)選型。哪怕只在一開始答錯(cuò)一個(gè)問題后面返工的成本都?jí)蚰惆哑脚_(tái)重寫一遍。2.2 整體架構(gòu)四層模型我們最終落地的平臺(tái)遵循了一個(gè)比較標(biāo)準(zhǔn)的四層架構(gòu)這也是很多工業(yè)界聯(lián)邦學(xué)習(xí)平臺(tái)的主流分法數(shù)據(jù)接入層負(fù)責(zé)對接各參與方的數(shù)據(jù)源做數(shù)據(jù)格式統(tǒng)一、樣本ID對齊等前置處理。這層最容易被低估實(shí)際工作量巨大。算法層封裝橫向聯(lián)邦、縱向聯(lián)邦、聯(lián)邦遷移學(xué)習(xí)等常用算法邏輯讓業(yè)務(wù)方不感知底層通信細(xì)節(jié)。聚合調(diào)度層負(fù)責(zé)中央服務(wù)器的模型聚合策略、訓(xùn)練任務(wù)調(diào)度、節(jié)點(diǎn)狀態(tài)管理。這一層是平臺(tái)的大腦。安全合規(guī)層提供加密通信、安全聚合、差分隱私等組件確保參數(shù)傳遞過程中的數(shù)據(jù)安全。很多團(tuán)隊(duì)會(huì)把安全合規(guī)層并入聚合調(diào)度層但我個(gè)人強(qiáng)烈建議獨(dú)立出來。因?yàn)橐坏I(yè)務(wù)審計(jì)要求提供安全保障說明獨(dú)立分層的平臺(tái)在合規(guī)解釋上會(huì)輕松非常多。2.3 基建選型自研還是開源框架這個(gè)問題幾乎每個(gè)客戶都會(huì)問到。我自己的做法是如果團(tuán)隊(duì)沒有核心算法團(tuán)隊(duì)優(yōu)先基于開源框架做二次開發(fā)而不是從零自研。市面上的開源聯(lián)邦學(xué)習(xí)框架各有偏向像FATE在金融場景落地案例多文檔和社區(qū)相對成熟FedML在算法研究和快速驗(yàn)證上更靈活Flower則輕量適合快速試驗(yàn)和小團(tuán)隊(duì)。選型的時(shí)候不要只看Star數(shù)量更要看你的核心場景和它擅長的方向是否匹配。如果場景里有比較強(qiáng)的定制化需求比如結(jié)合某種特殊的隱私保護(hù)算法那可以在開源框架的基礎(chǔ)層上做二次開發(fā)。直接自研整個(gè)平臺(tái)說實(shí)話從通信協(xié)議到安全機(jī)制到算法庫沒個(gè)十幾人的核心團(tuán)隊(duì)很難支撐起來。3. 核心細(xì)節(jié)解析聚合策略與安全機(jī)制是靈魂3.1 聚合策略不只是FedAvg很多人一聽聯(lián)邦學(xué)習(xí)就想到FedAvg以為把各方參數(shù)平均一下就行。但真實(shí)落地場景里聚合策略直接決定模型效果的上限。最基礎(chǔ)的是FedAvg按各方的數(shù)據(jù)量占比做加權(quán)平均。它的前提是各方數(shù)據(jù)獨(dú)立同分布但真實(shí)跨行業(yè)場景里這個(gè)前提往往不成立。比如銀行的欺詐樣本率可能只有0.1%而保險(xiǎn)公司的欺詐樣本率有5%模型極易被數(shù)據(jù)分布偏斜的一方帶偏。我們當(dāng)時(shí)做了兩個(gè)優(yōu)化第一個(gè)是把各方本地的訓(xùn)練輪數(shù)E和本地批次大小B解耦開通過控制本地迭代次數(shù)來緩解數(shù)據(jù)分布不均帶來的影響第二個(gè)是引入了基于驗(yàn)證集損失的動(dòng)態(tài)權(quán)重調(diào)整——每次聚合前讓各方在公共驗(yàn)證集上跑一遍根據(jù)表現(xiàn)好壞決定本輪的貢獻(xiàn)權(quán)重。這兩個(gè)調(diào)整做下來在客戶真實(shí)場景里模型AUC平均提升了3到5個(gè)百分點(diǎn)。3.2 參數(shù)加密和安全聚合怎么選聯(lián)邦學(xué)習(xí)雖然數(shù)據(jù)不出域但參數(shù)傳遞過程還是有泄露風(fēng)險(xiǎn)的。因?yàn)槟Ｐ蛥?shù)可能反推原始數(shù)據(jù)這在學(xué)術(shù)界已經(jīng)有攻擊方法論證過。安全聚合協(xié)議是目前比較成熟的選擇它的核心機(jī)制是對每個(gè)參與方的參數(shù)做隨機(jī)掩碼加密然后在服務(wù)器端聚合的時(shí)候?qū)⑦@些掩碼相互抵消。這樣中央服務(wù)器全程只能看到聚合后的結(jié)果看不到任何一方的原始參數(shù)。這個(gè)協(xié)議在實(shí)際部署中最大的問題是通信開銷翻倍。除此之外差分隱私是另一種常見思路就是在參數(shù)中加入一定量級(jí)的噪聲。實(shí)現(xiàn)上簡單但噪聲越大模型精度損失就越大。我們平臺(tái)的默認(rèn)配置是“安全聚合輕量差分隱私”的組合——通過安全聚合屏蔽參數(shù)級(jí)別的泄露風(fēng)險(xiǎn)再疊加一個(gè)極小的噪聲兜底。注意這里噪聲的scale參數(shù)一定不能拍腦袋定需要根據(jù)梯度范數(shù)的統(tǒng)計(jì)值來動(dòng)態(tài)調(diào)整否則精度損失會(huì)非常明顯。3.3 通信機(jī)制同步、異步還是半同步多方協(xié)作訓(xùn)練時(shí)的通信機(jī)制選擇也是我反復(fù)被問到的問題。同步聯(lián)邦學(xué)習(xí)最簡單等所有的參與方都訓(xùn)練完一輪再聚合。但真實(shí)網(wǎng)絡(luò)環(huán)境下總有一個(gè)節(jié)點(diǎn)慢半拍整個(gè)訓(xùn)練就只能等它這就是所謂的straggler問題。異步聯(lián)邦學(xué)習(xí)雖然可以解決等待問題但模型收斂性很難保證很多算法層面的性質(zhì)會(huì)丟失。我們最終的方案是折中策略設(shè)置一個(gè)超時(shí)窗口比如60秒內(nèi)沒報(bào)到的節(jié)點(diǎn)服務(wù)器先聚合已到的參與方遲到的節(jié)點(diǎn)在下一輪并用上一輪的全局模型做同步校準(zhǔn)。這個(gè)方式在參與方算力不平衡的時(shí)候非常管用實(shí)測訓(xùn)練時(shí)間能縮短差不多一半同時(shí)模型精度損失控制在可接受范圍內(nèi)。4. 實(shí)操過程實(shí)錄從0到1搭起一個(gè)跨行業(yè)聯(lián)邦學(xué)習(xí)demo4.1 場景設(shè)定與數(shù)據(jù)準(zhǔn)備為了讓整個(gè)過程更容易理解我這里用一個(gè)真實(shí)的模擬場景來做演示。假設(shè)平臺(tái)要對接三方參與方某銀行、某電商平臺(tái)、某運(yùn)營商聯(lián)合訓(xùn)練一個(gè)客戶信用評(píng)估模型。這三方的數(shù)據(jù)特征完全是異構(gòu)的銀行有客戶的工資流水和貸款記錄電商有消費(fèi)金額和頻次運(yùn)營商有通話時(shí)長和流量使用習(xí)慣。其中銀行側(cè)有部分樣本帶有標(biāo)簽是否逾期電商和運(yùn)營商兩側(cè)都沒有標(biāo)簽。這是一個(gè)非常經(jīng)典的縱向聯(lián)邦場景。數(shù)據(jù)準(zhǔn)備階段我們遇到的第一個(gè)問題就是樣本ID對齊。三方數(shù)據(jù)里有重疊的客戶ID大約60%剩下的40%是各方獨(dú)有的。如果不做對齊聯(lián)合訓(xùn)練的效果會(huì)大打折扣如果只保留三方重疊的樣本樣本量又不夠。解決方案是用隱私求交PSI技術(shù)——在不暴露各自全量客戶ID的前提下計(jì)算出三方的重疊客戶集合。這里我用了一段非常簡潔的Python實(shí)現(xiàn)來演示核心思路import hashlib def hash_id(raw_id: str, salt: str) - str: # 實(shí)際PSI會(huì)使用更復(fù)雜的盲簽名機(jī)制 # 這里用加鹽哈希模擬ID的隱私保護(hù)映射 return hashlib.sha256((salt raw_id).encode()).hexdigest() bank_ids [客戶A, 客戶B, 客戶C, 客戶D] ecom_ids [客戶B, 客戶D, 客戶E] # 假設(shè)每個(gè)參與方都有各自的鹽值 bank_salt, ecom_salt salt_123, salt_678 bank_hashed {hash_id(uid, bank_salt) for uid in bank_ids} ecom_hashed {hash_id(uid, ecom_salt) for uid in ecom_ids} # 簡化邏輯實(shí)際是多方間通過盲化交換的方式求交而不是直接對哈希值求交集 # 這里的哈希結(jié)果不能直接跨方對比僅用于本地組織數(shù)據(jù) print(f銀行哈希數(shù): {len(bank_hashed)}) print(f電商哈希數(shù): {len(ecom_hashed)})真實(shí)的PSI過程會(huì)比這段代碼復(fù)雜得多涉及到盲化因子、混淆電路等密碼學(xué)協(xié)議但核心目標(biāo)是一致的——各方只知道自己和別人重疊了哪些ID不知道對方全量ID。我們當(dāng)時(shí)用的是基于RSA盲簽名的PSI方案300萬級(jí)別的ID集合跑完整個(gè)求交過程大概需要幾分鐘屬于可以接受的范圍。數(shù)據(jù)對齊之后還有一個(gè)非常容易被忽略的工作就是特征工程的對齊。不同來源的原始字段五花八門比如銀行的“月均流水”在電商側(cè)可能對應(yīng)的是“月均消費(fèi)”在運(yùn)營商側(cè)是“月均ARPU值”。我們用了統(tǒng)一的特征標(biāo)準(zhǔn)化流程讓三方提交的特征經(jīng)過相同的分箱和歸一化處理這樣在后續(xù)模型訓(xùn)練時(shí)才能在同一個(gè)尺度上做計(jì)算。4.2 模型初始化與本地計(jì)算流程在縱向聯(lián)邦場景里因?yàn)閿?shù)據(jù)特征分散在不同參與方我們使用的是拆分學(xué)習(xí)的思路各方持有特征的一方各自維護(hù)一個(gè)底層網(wǎng)絡(luò)bottom model銀行持有標(biāo)簽的一方額外維護(hù)一個(gè)頂層網(wǎng)絡(luò)top model。整個(gè)模型的前向傳播需要走完三方的底層網(wǎng)絡(luò)然后在標(biāo)簽方完成最后一步計(jì)算。這里給出了核心的聯(lián)邦訓(xùn)練調(diào)度偽代碼幫助大家理解整個(gè)協(xié)作流程是怎么組織的# 偽代碼縱向聯(lián)邦學(xué)習(xí)訓(xùn)練流程 def vertical_fed_train(bank_model, ecom_model, telco_model, top_model, data, max_rounds30): # 1. 初始化各方底層模型參數(shù) interactive_features {} losses [] for round_idx in range(max_rounds): # 2. 各參與方本地計(jì)算底層特征 bank_out bank_model.forward(data.bank_features) ecom_out ecom_model.forward(data.ecom_features) telco_out telco_model.forward(data.telco_features) # 3. 聚合中間結(jié)果傳到標(biāo)簽方銀行 concat_features torch.cat([bank_out, ecom_out, telco_out], dim1) logits top_model.forward(concat_features) loss binary_cross_entropy(logits, data.labels) # 4. 反向傳播時(shí)各參與方只更新自己的模型 top_model.backward(loss) bank_grad top_model.get_grad_wrt(bank_out) ecom_grad top_model.get_grad_wrt(ecom_out) telco_grad top_model.get_grad_wrt(telco_out) bank_model.update(bank_grad) ecom_model.update(ecom_grad) telco_model.update(telco_grad) losses.append(loss.item()) print(fRound {round_idx}: loss{loss.item():.4f}) return losses這套流程跑通了整個(gè)平臺(tái)的技術(shù)骨架基本就搭建起來了。注意上面的代碼在實(shí)際部署時(shí)看起來輕巧但真正的難點(diǎn)在于工程化各方模型在不同機(jī)器上前向傳播時(shí)需要跨機(jī)通信反向傳播時(shí)梯度要原路送回各參與方整個(gè)過程還要被安全聚合協(xié)議保護(hù)每一步通信都不能明文傳輸。4.3 平臺(tái)部署環(huán)境與參數(shù)配置部署方面我們用了四臺(tái)云服務(wù)器其中一臺(tái)做協(xié)調(diào)方和聚合服務(wù)器其余三臺(tái)分配給銀行、電商、運(yùn)營商。每臺(tái)服務(wù)器配置了相當(dāng)充裕的資源——8核CPU、32G內(nèi)存、一張普通級(jí)別的GPU卡。訓(xùn)練用的模型是一個(gè)三層的MLP參數(shù)量不大單輪訓(xùn)練時(shí)間大約在十幾秒級(jí)別。通信方面因?yàn)槿_(tái)參與方的服務(wù)器分布在不同的機(jī)房網(wǎng)絡(luò)延遲在10到30毫秒之間整體的訓(xùn)練速度還算理想。為了避免內(nèi)網(wǎng)通信占用過高帶寬我們在參數(shù)傳遞時(shí)壓縮了浮點(diǎn)數(shù)的精度從32位降到16位傳輸體積直接縮小一半同時(shí)model效果損失控制在極小的范圍。聚合策略上我們使用了帶驗(yàn)證集權(quán)重的FedAvg變種。協(xié)調(diào)方保留了一部分銀行側(cè)的測試數(shù)據(jù)作為公共驗(yàn)證集每次聚合前讓三方模型分別跑一遍驗(yàn)證集用AUC作為權(quán)重計(jì)算依據(jù)。實(shí)測下來這個(gè)策略比純FedAvg在冷啟動(dòng)階段收斂速度快了不少。4.4 效果評(píng)估多方協(xié)作的收益到底有多大既然花了這么大力氣做跨行業(yè)協(xié)作總要回答一個(gè)問題效果收益在哪里我們對比了三種方案僅用銀行自有數(shù)據(jù)訓(xùn)練的本地模型、用三方可直接共享的非敏感字段拼出來的聯(lián)合模型、以及聯(lián)邦學(xué)習(xí)平臺(tái)訓(xùn)練的隱私保護(hù)聯(lián)合模型。結(jié)果很有說服力本地銀行模型的AUC是0.742只用了銀行自身的數(shù)據(jù)特征維度非常有限傳統(tǒng)聯(lián)合模型AUC是0.771用了部分可共享的特征但是很多敏感特征根本無法納入聯(lián)邦模型的AUC達(dá)到了0.803不僅特征維度更豐富而且無需任何原始數(shù)據(jù)出域。0.03到0.06的AUC提升對于風(fēng)控場景來說意味著在相同的通過率下壞賬率能降低十幾個(gè)百分點(diǎn)。這個(gè)數(shù)字不是在實(shí)驗(yàn)室里卷出來的是在真實(shí)業(yè)務(wù)場景里跑出來的。我見過太多項(xiàng)目止步于“聯(lián)邦學(xué)習(xí)能做”但其實(shí)真正能證明它“值得做”的就是這組效果對比數(shù)據(jù)。5. 常見問題與排查技巧實(shí)錄5.1 參與方中途掉線怎么辦多方訓(xùn)練的常態(tài)就是不穩(wěn)定。我們在實(shí)際跑訓(xùn)練任務(wù)的時(shí)候銀行側(cè)服務(wù)器經(jīng)常因?yàn)闃I(yè)務(wù)高峰CPU被占滿導(dǎo)致訓(xùn)練進(jìn)程響應(yīng)超時(shí)。最開始我們的調(diào)度器只要發(fā)現(xiàn)某個(gè)節(jié)點(diǎn)失聯(lián)整個(gè)訓(xùn)練任務(wù)就掛起等待結(jié)果一等就是兩個(gè)小時(shí)。后來我們加了兩層機(jī)制第一層是參與方本地的自動(dòng)重試和斷點(diǎn)續(xù)訓(xùn)訓(xùn)練過程中定期保存本地模型的checkpoint第二層是調(diào)度器層面的超時(shí)降級(jí)等待時(shí)間超過預(yù)設(shè)值后自動(dòng)剔除該節(jié)點(diǎn)繼續(xù)本輪聚合并在下一輪開始前嘗試恢復(fù)連接。這個(gè)處理機(jī)制上線之后訓(xùn)練任務(wù)的完成率從70%左右提升到了95%以上。做跨行業(yè)協(xié)作項(xiàng)目一定不要把“參與方網(wǎng)絡(luò)永穩(wěn)定”當(dāng)作前提假設(shè)。5.2 模型不收斂查看Loss是否震蕩聯(lián)邦學(xué)習(xí)的模型不收斂90%的情況不是算法問題而是數(shù)據(jù)分布和超參設(shè)置的問題。在我們的模擬場景里剛開始訓(xùn)練時(shí)Loss下降非常慢而且每個(gè)round之后Loss震蕩得很厲害。排查之后發(fā)現(xiàn)是本地學(xué)習(xí)率設(shè)置得太高了每個(gè)參與方在自己的本地?cái)?shù)據(jù)上跑了3個(gè)epoch學(xué)習(xí)率用的是0.01整體算下來相當(dāng)于每一輪全局更新時(shí)模型參數(shù)在參數(shù)空間里邁了一大步自然容易越過最優(yōu)點(diǎn)。解決方案非常簡單粗暴把學(xué)習(xí)率降到0.003同時(shí)把本地epoch降到1收斂效果立刻變得穩(wěn)定。這里有個(gè)經(jīng)驗(yàn)值可以參考聯(lián)邦學(xué)習(xí)的全局學(xué)習(xí)率一般要比單機(jī)訓(xùn)練小3到5倍因?yàn)槎噍啽镜馗聲?huì)產(chǎn)生累積效應(yīng)。5.3 安全聚合通信開銷太大安全聚合協(xié)議雖然安全性好但通信量幾乎是明文傳輸?shù)娜兑陨?。在跨機(jī)房場景下這個(gè)開銷非常感人。我們做過一個(gè)粗略的測試模型參數(shù)量100萬單次明文傳輸大約是4MB16位浮點(diǎn)安全聚合流程里光是掩碼交換和密鑰協(xié)商就要額外產(chǎn)生接近10MB的通信量。為了在這個(gè)約束下保障訓(xùn)練效率我們做了兩件事。第一是梯度稀疏化只上傳絕對值排名前1%的梯度。這個(gè)操作在保持模型效果的同時(shí)通信量直接降了一個(gè)數(shù)量級(jí)。第二是梯度量化把32位浮點(diǎn)梯度量化到8位整數(shù)配合誤差補(bǔ)償機(jī)制來減少精度損失。兩者疊加單輪通信耗時(shí)從百毫秒級(jí)別降到了幾十毫秒級(jí)別模型精度損失不到0.5%。5.4 參與方數(shù)據(jù)分布極度不均衡之前參與過一個(gè)項(xiàng)目一方有800萬樣本另一方只有5萬樣本。如果按FedAvg的默認(rèn)邏輯聚合模型幾乎完全被大數(shù)據(jù)方掌控小數(shù)據(jù)方的數(shù)據(jù)價(jià)值完全體現(xiàn)不出來。這種情況下我們做的是“分層聚合”——先將參與方按數(shù)據(jù)量級(jí)分成大、中、小三檔檔內(nèi)采用加權(quán)平均檔間采用平均聚合。這樣做的好處是小數(shù)據(jù)方的模型參數(shù)在最終結(jié)果中至少能保持與中等數(shù)據(jù)方相近的貢獻(xiàn)度而不是被直接淹沒。6. 平臺(tái)后續(xù)擴(kuò)展方向與個(gè)人實(shí)踐經(jīng)驗(yàn)6.1 從橫向聯(lián)邦到縱向聯(lián)邦的擴(kuò)展很多團(tuán)隊(duì)一開始接觸聯(lián)邦學(xué)習(xí)都是從橫向聯(lián)邦入門的因?yàn)閷?shí)現(xiàn)簡單通信邏輯直白。但實(shí)際業(yè)務(wù)里更有價(jià)值、落地難度也更大的其實(shí)是縱向聯(lián)邦因?yàn)檎嬲缧袠I(yè)的數(shù)據(jù)互補(bǔ)幾乎都是特征互補(bǔ)型的。我們的平臺(tái)架構(gòu)在初期就預(yù)留了對縱向聯(lián)邦的支持接口數(shù)據(jù)接入層單獨(dú)抽象了特征對齊模塊算法層預(yù)留了拆分學(xué)習(xí)引擎。如果讓我重來一次我依然會(huì)堅(jiān)持這個(gè)決策。一開始多花點(diǎn)時(shí)間做擴(kuò)展性設(shè)計(jì)后面接入新場景時(shí)能省非常多的時(shí)間。6.2 性能調(diào)優(yōu)方面的實(shí)戰(zhàn)心得有幾個(gè)小的調(diào)優(yōu)點(diǎn)雖然不是決定性的但積累起來對整體體驗(yàn)影響不小。第一個(gè)是把Python層面的數(shù)據(jù)預(yù)處理盡量下沉到C或者用向量化操作因?yàn)榭缧袠I(yè)的原始數(shù)據(jù)非常臟清洗邏輯復(fù)雜純Python處理慢得讓人崩潰。第二個(gè)是給參與方的本地訓(xùn)練進(jìn)程設(shè)置合理的CPU綁核策略避免和其他業(yè)務(wù)進(jìn)程搶資源導(dǎo)致訓(xùn)練抖動(dòng)。第三個(gè)是提前想好日志方案聯(lián)邦學(xué)習(xí)的日志分散在各參與方節(jié)點(diǎn)排查問題的時(shí)候如果沒有統(tǒng)一的日志采集體系光找日志就能把人逼瘋。6.3 這個(gè)平臺(tái)還能做什么平臺(tái)穩(wěn)定運(yùn)行之后可以擴(kuò)展的方向很多。比如引入更豐富的隱私保護(hù)算法庫讓業(yè)務(wù)方在不同合規(guī)要求下選擇合適的保護(hù)級(jí)別又比如增加自動(dòng)化模型壓縮工具降低參與方本地的部署算力要求還可以建立一套模型效果貢獻(xiàn)度評(píng)估機(jī)制根據(jù)各方參數(shù)對最終模型的貢獻(xiàn)反推數(shù)據(jù)方應(yīng)該獲得的收益分配比例。尤其最后一點(diǎn)在跨行業(yè)場景里特別重要。多方合作不能只靠情懷必須有清晰的利益分配機(jī)制聯(lián)邦學(xué)習(xí)的特性天然為這種機(jī)制提供了技術(shù)依據(jù)。用誰的參數(shù)多、效果提升大誰就該分到更多收益這個(gè)邏輯在業(yè)務(wù)談判時(shí)非常有說服力。就我個(gè)人經(jīng)驗(yàn)來說跨行業(yè)聯(lián)邦學(xué)習(xí)平臺(tái)這個(gè)方向最難的從來不是算法本身而是把算法工程化、系統(tǒng)化并且讓所有參與方都相信這個(gè)系統(tǒng)是公平且安全的。技術(shù)只是必要條件信任和治理機(jī)制才是決定項(xiàng)目能不能長期跑下去的關(guān)鍵。如果你正準(zhǔn)備啟動(dòng)類似的項(xiàng)目我建議你在設(shè)計(jì)架構(gòu)的同時(shí)盡早把參與方的溝通機(jī)制和利益分配機(jī)制納入規(guī)劃里。