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