1. 從“DS和華為”這個標(biāo)題說起我到底想聊什么“DS和華為”這個標(biāo)題第一次看到的時候我腦子里蹦出來的不是某個具體產(chǎn)品而是一組關(guān)系一個是以算法和模型能力見長的技術(shù)流派一個是以硬件工程和系統(tǒng)整合能力見長的科技企業(yè)。這兩者放在一起天然就帶著一種“軟硬結(jié)合”的張力。我之所以想認(rèn)真聊聊這個話題是因為過去一年多里我身邊不少做技術(shù)、做產(chǎn)品、做行業(yè)解決方案的朋友都在反復(fù)討論同一個問題當(dāng)算法能力越來越像水電一樣可獲取的時候真正拉開差距的到底是什么先把這個標(biāo)題拆開來看?！癉S”在我的理解里可以泛指一類以數(shù)據(jù)科學(xué)、深度學(xué)習(xí)、決策系統(tǒng)為核心的技術(shù)能力集合它代表的是一種“用模型和數(shù)據(jù)去解決問題”的思路。而“華為”在這里更像是一個符號代表著極致的工程化能力、對底層硬件的掌控力以及把技術(shù)推向大規(guī)模商用的執(zhí)行力。這兩者單獨(dú)拿出來都很強(qiáng)但真正有意思的地方在于它們相遇之后產(chǎn)生的化學(xué)反應(yīng)。我寫這篇東西不是要做什么宏觀分析也不是要預(yù)測什么行業(yè)趨勢。我更想從一個一線從業(yè)者的角度把“算法能力”和“工程能力”這兩條線怎么在實際項目里擰成一股繩掰開揉碎了講清楚。如果你正在做AI應(yīng)用落地、在做行業(yè)解決方案、或者在思考技術(shù)選型和團(tuán)隊配置那這篇內(nèi)容應(yīng)該能給你一些可以直接參考的東西。我會盡量少講空話多講我踩過的坑、試過的方案、以及那些文檔里不會寫的細(xì)節(jié)。2. 為什么“算法工程”這個組合值得反復(fù)琢磨2.1 單點(diǎn)算法能力強(qiáng)不等于項目能跑起來我見過太多團(tuán)隊模型指標(biāo)刷得很漂亮論文也發(fā)了不少但一到真實場景就歇菜。原因很簡單實驗室環(huán)境和生產(chǎn)環(huán)境是兩碼事。實驗室里你可以用干凈的標(biāo)注數(shù)據(jù)、充足的算力、無限次的調(diào)參機(jī)會但到了生產(chǎn)環(huán)境數(shù)據(jù)是臟的、算力是有限的、延遲要求是毫秒級的、硬件可能是五花八門的。這時候光有算法能力是不夠的。你需要有人能把模型壓縮到能在邊緣設(shè)備上跑需要有人能設(shè)計出合理的推理流水線需要有人能搞定數(shù)據(jù)采集和預(yù)處理的工程鏈路。這些事恰恰是工程能力強(qiáng)的團(tuán)隊更擅長的。我自己的體會是一個項目能不能成算法決定了上限工程決定了下限。下限守不住上限再高也沒用。2.2 工程能力再強(qiáng)沒有算法突破也只是重復(fù)勞動反過來也一樣。我見過一些工程能力非常扎實的團(tuán)隊代碼寫得漂亮系統(tǒng)穩(wěn)定性極高但做出來的東西就是“不好用”。為什么因為核心的算法能力沒有突破只能做一些規(guī)則堆砌的工作。比如做推薦系統(tǒng)如果只會用簡單的協(xié)同過濾不去研究更先進(jìn)的召回和排序模型那效果的天花板就擺在那里。工程能力可以讓你把60分的東西做到80分的穩(wěn)定性但沒法讓你從60分跳到90分的效果。那30分的差距必須靠算法創(chuàng)新來補(bǔ)。所以這兩者不是誰替代誰的關(guān)系而是互相成就的關(guān)系。算法負(fù)責(zé)打開可能性工程負(fù)責(zé)把可能性變成可靠性。2.3 真正的難點(diǎn)在于“接口”而不是“單點(diǎn)”我后來想明白一件事算法和工程結(jié)合最難的不是各自做到極致而是找到那個“接口”。這個接口包括數(shù)據(jù)接口、性能接口、迭代接口。數(shù)據(jù)接口決定了算法團(tuán)隊能不能拿到高質(zhì)量的數(shù)據(jù)性能接口決定了模型能不能在工程約束下跑起來迭代接口決定了算法更新能不能快速部署到生產(chǎn)環(huán)境。這三個接口每一個都是坑。我見過算法團(tuán)隊抱怨數(shù)據(jù)質(zhì)量差工程團(tuán)隊抱怨模型太復(fù)雜跑不動兩邊互相甩鍋。也見過模型更新一次要兩周等上線的時候業(yè)務(wù)需求已經(jīng)變了。這些問題都不是單點(diǎn)技術(shù)能解決的需要從系統(tǒng)設(shè)計層面去考慮。3. 核心細(xì)節(jié)拆解算法與工程結(jié)合的幾個關(guān)鍵環(huán)節(jié)3.1 數(shù)據(jù)閉環(huán)從“有什么用什么”到“缺什么補(bǔ)什么”數(shù)據(jù)是算法和工程結(jié)合的第一個交匯點(diǎn)。很多團(tuán)隊的做法是“有什么數(shù)據(jù)就用什么數(shù)據(jù)”這是被動的。更好的做法是建立數(shù)據(jù)閉環(huán)算法團(tuán)隊告訴工程團(tuán)隊需要什么樣的數(shù)據(jù)工程團(tuán)隊去設(shè)計采集和標(biāo)注流程然后反饋給算法團(tuán)隊。這里有個關(guān)鍵細(xì)節(jié)數(shù)據(jù)采集的粒度要和模型需求匹配。我做過一個項目算法團(tuán)隊需要用戶的行為序列數(shù)據(jù)但工程團(tuán)隊采集的是聚合后的統(tǒng)計值。結(jié)果算法團(tuán)隊拿到數(shù)據(jù)后發(fā)現(xiàn)根本沒法用因為序列信息丟失了。后來我們重新設(shè)計了埋點(diǎn)方案把原始行為事件按時間戳記錄下來算法效果立刻上了一個臺階。注意數(shù)據(jù)閉環(huán)不是一次性工作而是一個持續(xù)運(yùn)轉(zhuǎn)的機(jī)制。建議在項目初期就建立數(shù)據(jù)質(zhì)量監(jiān)控看板把數(shù)據(jù)覆蓋率、標(biāo)注準(zhǔn)確率、特征分布漂移這些指標(biāo)可視化讓兩邊團(tuán)隊都能看到同一份數(shù)據(jù)。3.2 模型壓縮與加速讓算法在工程約束下跳舞算法團(tuán)隊訓(xùn)練出來的模型往往參數(shù)量大、計算量大直接部署到生產(chǎn)環(huán)境會有性能問題。這時候就需要做模型壓縮和加速。常見的手段包括剪枝、量化、知識蒸餾等。我自己的經(jīng)驗是量化是最容易見效的手段。把FP32的模型量化到INT8推理速度通常能提升2到4倍精度損失一般在1%以內(nèi)。但量化也有坑不是所有層都適合量化有些對精度敏感的層需要保留高精度。我一般會先用工具做敏感度分析找出哪些層可以量化哪些層必須保留。剪枝則要更小心一些。結(jié)構(gòu)化剪枝對硬件更友好但可能會影響模型表達(dá)能力非結(jié)構(gòu)化剪枝壓縮率高但需要專門的硬件支持。我試過在一個圖像分類項目里做非結(jié)構(gòu)化剪枝壓縮率到了80%但在通用CPU上推理速度反而變慢了因為稀疏計算沒有被硬件加速。后來改成結(jié)構(gòu)化剪枝壓縮率降到50%但推理速度提升了1.8倍。3.3 推理流水線把多個模型串成一條高效產(chǎn)線真實場景里往往不是單個模型在戰(zhàn)斗而是多個模型協(xié)同工作。比如一個內(nèi)容審核系統(tǒng)可能先用人臉檢測模型定位人臉再用屬性識別模型判斷年齡性別最后用分類模型判斷是否違規(guī)。這些模型怎么串起來直接影響整體延遲和吞吐。我設(shè)計推理流水線時會重點(diǎn)考慮三件事第一哪些模型可以并行跑哪些必須串行第二模型之間的數(shù)據(jù)傳遞能不能做到零拷貝第三有沒有必要做模型融合把多個小模型合并成一個大模型。并行化是最容易想到的優(yōu)化手段。比如人臉檢測和場景分類可以并行因為它們互不依賴。但并行也會帶來資源競爭問題需要合理分配計算資源。零拷貝則需要在工程層面做設(shè)計比如讓上游模型的輸出直接作為下游模型的輸入避免在內(nèi)存里來回拷貝。模型融合適合那些輸入輸出高度相關(guān)的模型融合后可以減少中間數(shù)據(jù)的讀寫開銷。3.4 硬件選型不是越貴越好而是越匹配越好硬件選型是工程側(cè)的重要決策但很多團(tuán)隊容易走極端要么全用最貴的GPU要么全用最便宜的CPU。我的經(jīng)驗是要根據(jù)模型的計算特性和業(yè)務(wù)場景來選。訓(xùn)練階段GPU幾乎是必須的因為需要大量矩陣運(yùn)算。但推理階段就不一定了。如果模型是計算密集型的比如大語言模型那GPU或?qū)Ｓ眉铀傩酒线m如果模型是訪存密集型的比如推薦模型那高內(nèi)存帶寬的CPU可能更劃算。我還發(fā)現(xiàn)一個現(xiàn)象很多團(tuán)隊在硬件選型時只看峰值算力忽略了實際利用率。一塊峰值算力很高的芯片如果因為內(nèi)存帶寬不足或者調(diào)度不合理實際利用率可能只有30%。這時候不如選一塊峰值算力稍低但利用率能到70%的芯片。我一般會建議做一個小規(guī)模的基準(zhǔn)測試用真實模型和真實數(shù)據(jù)跑一遍看實際吞吐和延遲而不是只看規(guī)格書。4. 實操過程一個完整的算法工程化落地案例4.1 場景定義與約束梳理假設(shè)我們要做一個工業(yè)質(zhì)檢系統(tǒng)用攝像頭拍攝產(chǎn)品表面自動識別缺陷。這個場景的約束很明確產(chǎn)線速度是每分鐘60件也就是說每件產(chǎn)品的處理時間不能超過1秒工廠環(huán)境沒有穩(wěn)定的網(wǎng)絡(luò)所以推理必須在本地完成設(shè)備預(yù)算有限不能上太高端的GPU。這些約束直接決定了技術(shù)方案的選擇。1秒的處理時間意味著模型不能太大否則推理時間超標(biāo)本地推理意味著不能用云端API預(yù)算有限意味著硬件選型要精打細(xì)算。我先把這些約束列成表格方便后續(xù)做技術(shù)決策。約束項具體要求影響的技術(shù)決策處理速度每件不超過1秒模型大小、推理框架、硬件選型部署環(huán)境本地離線不能依賴云端服務(wù)硬件預(yù)算單臺設(shè)備不超過一定成本邊緣計算設(shè)備選型缺陷類型多種缺陷樣本不均衡數(shù)據(jù)增強(qiáng)、損失函數(shù)設(shè)計準(zhǔn)確率要求召回率不低于95%模型結(jié)構(gòu)、閾值調(diào)優(yōu)4.2 數(shù)據(jù)采集與標(biāo)注的工程化處理工業(yè)質(zhì)檢的數(shù)據(jù)采集有個特點(diǎn)正常樣本遠(yuǎn)遠(yuǎn)多于缺陷樣本。我做過統(tǒng)計正常樣本和缺陷樣本的比例可能達(dá)到1000比1。這種極端不均衡的數(shù)據(jù)直接訓(xùn)練模型效果會很差。我的做法是分三步走。第一步先用正常樣本訓(xùn)練一個自編碼器讓它學(xué)習(xí)正常樣本的分布。第二步用這個自編碼器去檢測異常把重構(gòu)誤差大的樣本挑出來作為候選缺陷樣本。第三步對候選樣本進(jìn)行人工復(fù)核和標(biāo)注補(bǔ)充到訓(xùn)練集里。這樣可以在不增加太多標(biāo)注成本的情況下快速擴(kuò)充缺陷樣本。標(biāo)注環(huán)節(jié)也有講究。工業(yè)缺陷往往很小標(biāo)注時容易漏標(biāo)或錯標(biāo)。我一般會要求標(biāo)注人員用放大鏡看并且對每個標(biāo)注結(jié)果做交叉驗證。另外我會把標(biāo)注工具和產(chǎn)線數(shù)據(jù)打通標(biāo)注完直接入庫避免人工導(dǎo)出導(dǎo)入的繁瑣和出錯。4.3 模型訓(xùn)練與調(diào)優(yōu)的實操記錄模型選型上我一開始試了ResNet和EfficientNet效果都不錯但推理速度不達(dá)標(biāo)。后來換成了MobileNetV3精度略降但速度提升明顯。具體數(shù)據(jù)是ResNet50在邊緣設(shè)備上單張推理要800毫秒MobileNetV3只要200毫秒精度從98%降到96%?？紤]到產(chǎn)線速度要求我選了MobileNetV3。訓(xùn)練過程中我用了幾個技巧。一是數(shù)據(jù)增強(qiáng)除了常規(guī)的翻轉(zhuǎn)、旋轉(zhuǎn)還加了隨機(jī)遮擋和亮度擾動模擬產(chǎn)線上的光照變化。二是損失函數(shù)用了Focal Loss來處理樣本不均衡讓模型更關(guān)注難分類的缺陷樣本。三是學(xué)習(xí)率調(diào)度用了余弦退火訓(xùn)練后期學(xué)習(xí)率降到很小幫助模型收斂到更優(yōu)的解。調(diào)參這塊我踩過一個坑一開始把batch size設(shè)得很大想著能加快訓(xùn)練。結(jié)果發(fā)現(xiàn)小缺陷樣本在大的batch里被淹沒了模型對它們的梯度貢獻(xiàn)很小。后來把batch size調(diào)小并且用了梯度累積效果反而更好。所以batch size不是越大越好要根據(jù)數(shù)據(jù)分布來定。4.4 模型部署與推理優(yōu)化的現(xiàn)場記錄部署環(huán)節(jié)我選了一個支持INT8量化的推理框架。量化過程分兩步先用校準(zhǔn)數(shù)據(jù)集統(tǒng)計各層的激活值分布確定量化參數(shù)然后對模型做量化轉(zhuǎn)換。量化后模型大小從20MB降到5MB推理速度從200毫秒降到80毫秒精度損失不到0.5%。推理流水線設(shè)計上我把圖像預(yù)處理和后處理都放到了CPU上模型推理放在NPU上這樣能充分利用異構(gòu)計算資源。預(yù)處理包括縮放、歸一化、通道轉(zhuǎn)換后處理包括非極大值抑制和閾值過濾。這些操作雖然簡單但很耗時放到CPU上可以和NPU的推理并行執(zhí)行。還有一個細(xì)節(jié)產(chǎn)線上的圖像是連續(xù)采集的如果每張圖都單獨(dú)處理會有很多重復(fù)計算。我設(shè)計了一個滑動窗口機(jī)制把相鄰幾幀圖像緩存起來只在檢測到物體進(jìn)入視野時才觸發(fā)推理。這樣既減少了計算量又避免了漏檢。5. 常見問題與排查技巧實錄5.1 模型精度不達(dá)標(biāo)怎么一步步排查精度問題是最常見的。我一般會按這個順序排查先看訓(xùn)練集上的精度如果訓(xùn)練集精度就低說明模型欠擬合需要增加模型復(fù)雜度或訓(xùn)練輪數(shù)如果訓(xùn)練集精度高但驗證集精度低說明過擬合需要加正則化或數(shù)據(jù)增強(qiáng)如果驗證集精度高但測試集精度低說明數(shù)據(jù)分布不一致需要檢查數(shù)據(jù)采集和標(biāo)注流程。還有一個容易被忽略的點(diǎn)評估指標(biāo)是否合理。我見過一個項目用準(zhǔn)確率作為指標(biāo)但數(shù)據(jù)極度不均衡模型只要全預(yù)測為正常樣本就能達(dá)到99%的準(zhǔn)確率。后來換成F1分?jǐn)?shù)和AUC才暴露出模型其實很差。所以指標(biāo)選擇要和業(yè)務(wù)目標(biāo)對齊不能只看一個數(shù)。5.2 推理速度慢瓶頸到底在哪里推理速度慢可能的原因有很多。我一般會用性能分析工具把推理過程拆成預(yù)處理、模型推理、后處理三段分別計時。如果預(yù)處理慢可能是圖像解碼或縮放耗時如果模型推理慢可能是模型太大或硬件利用率低如果后處理慢可能是非極大值抑制的閾值設(shè)得太低導(dǎo)致候選框太多。硬件利用率低是常見問題。我遇到過一種情況模型在GPU上跑但GPU利用率只有20%。查下來發(fā)現(xiàn)是數(shù)據(jù)加載成了瓶頸CPU預(yù)處理速度跟不上GPU推理速度。后來用了多線程數(shù)據(jù)加載和GPU預(yù)處理利用率提到了70%整體速度提升了一倍多。5.3 模型更新后效果反而變差怎么回滾和對比模型更新后效果變差原因可能是新數(shù)據(jù)有噪聲、訓(xùn)練參數(shù)不對、或者新模型和舊模型的行為差異太大。我一般會保留最近幾個版本的模型并且記錄每個版本的訓(xùn)練數(shù)據(jù)、參數(shù)和評估結(jié)果。一旦新版本效果變差可以快速回滾到舊版本。對比新舊模型時我不僅看整體指標(biāo)還會看細(xì)分指標(biāo)。比如整體準(zhǔn)確率差不多但某個類別的召回率下降了那可能是新數(shù)據(jù)里這個類別的樣本太少。這時候需要針對性地補(bǔ)充數(shù)據(jù)而不是簡單回滾。5.4 常見問題速查表問題現(xiàn)象可能原因排查方法解決思路訓(xùn)練集精度低模型欠擬合檢查模型復(fù)雜度和訓(xùn)練輪數(shù)增加層數(shù)或訓(xùn)練輪數(shù)驗證集精度低過擬合對比訓(xùn)練集和驗證集損失加正則化或數(shù)據(jù)增強(qiáng)推理速度慢預(yù)處理耗時分段計時優(yōu)化預(yù)處理或并行化推理速度慢硬件利用率低查看硬件監(jiān)控優(yōu)化數(shù)據(jù)加載或調(diào)度模型更新后變差數(shù)據(jù)噪聲檢查新數(shù)據(jù)質(zhì)量清洗數(shù)據(jù)或回滾模型更新后變差參數(shù)不匹配對比新舊參數(shù)重新調(diào)參提示排查問題時一定要有基線。沒有基線你連“變差了”都判斷不了。我一般會在項目初期就建立一個簡單的基線模型后續(xù)所有改進(jìn)都跟它對比。6. 一些踩坑之后的個人體會6.1 算法團(tuán)隊和工程團(tuán)隊要“混在一起”我經(jīng)歷過兩種團(tuán)隊組織方式。一種是算法團(tuán)隊和工程團(tuán)隊分開各做各的定期同步。這種方式的問題是溝通成本高信息傳遞容易失真。另一種是混編算法和工程的人坐在一起隨時溝通。后者的效率明顯更高?；炀幍暮锰幨撬惴ǖ娜四芗皶r了解工程約束不會設(shè)計出根本跑不動的模型工程的人能理解算法的需求不會在數(shù)據(jù)采集和預(yù)處理上偷工減料。我印象很深的一次算法同事在訓(xùn)練時發(fā)現(xiàn)某個特征很重要但工程同事說這個特征在生產(chǎn)環(huán)境拿不到。如果兩邊分開這個問題可能要到部署時才會暴露。混編之后當(dāng)場就調(diào)整了特征方案。6.2 不要追求“一步到位”的完美方案我年輕的時候總想設(shè)計一個完美的系統(tǒng)把所有可能的情況都考慮到。后來發(fā)現(xiàn)這種思路在真實項目里行不通。因為需求會變、數(shù)據(jù)會變、硬件會變你不可能一開始就設(shè)計出完美的方案。更務(wù)實的做法是快速迭代。先做一個能跑通的最小可行系統(tǒng)然后根據(jù)反饋不斷優(yōu)化。我現(xiàn)在的習(xí)慣是第一個版本只求能跑通不追求性能第二個版本優(yōu)化性能第三個版本再考慮擴(kuò)展性和可維護(hù)性。這樣每一步都有明確的目標(biāo)不會陷入過度設(shè)計的陷阱。6.3 文檔和工具鏈的投入不能省我見過很多團(tuán)隊技術(shù)能力很強(qiáng)但文檔和工具鏈一塌糊涂。結(jié)果就是一個人離職他負(fù)責(zé)的模塊就沒人能接手一個模型上線沒人知道怎么復(fù)現(xiàn)訓(xùn)練過程。這種隱性成本非常高。我的建議是從項目第一天起就重視文檔和工具鏈。文檔不一定要多正式但至少要記錄清楚數(shù)據(jù)從哪里來、模型怎么訓(xùn)練、參數(shù)怎么配置、部署怎么操作。工具鏈方面版本管理、實驗跟蹤、模型注冊這些基礎(chǔ)工具要盡早搭建。這些投入短期看是負(fù)擔(dān)長期看是保險。6.4 最后分享一個小技巧如果你也在做算法和工程結(jié)合的項目我建議你每周花半小時把算法和工程兩邊的人拉到一起做一個簡單的“對齊會”。每個人說說這周做了什么、遇到了什么問題、下周打算做什么。不需要很正式站著開就行。這個習(xí)慣我堅持了兩年幫我避免了很多因為信息不對稱導(dǎo)致的返工。這個會還有一個好處能讓兩邊的人看到對方的貢獻(xiàn)。算法的人知道工程的人為了優(yōu)化推理速度做了多少工作工程的人知道算法的人為了提升精度調(diào)了多少參數(shù)?；ハ嗬斫庵蠛献鲿槙澈芏?。