文 | Severus
編 | 小軼
寫在前面：本文完全基于我個人的工作經(jīng)驗，沒有經(jīng)過任何形式的行業(yè)調(diào)研，所以我的理解也有相當濃厚的個人印記，可以認作一家之言。如果能對讀者朋友們起到任何幫助，都是我的榮幸。如果不贊同我的看法，則還請一笑了之。
大家好，我是Severus，一個在某廠做中文文本理解的程序員。
今天我想要分享的是，在算法崗工作6年之后，我心中對“算法崗”的理解，以及我在這個職業(yè)中，是如何生存的。
我時常提到，“AI算法工程師”分為兩個部分，“AI算法”和“工程師”。二者的關(guān)系是：算法工程師，首先得是個工程師。有了 idea，還得有能力高效、優(yōu)美、完整地實現(xiàn)出來，還要去解決一系列工程上的問題。
同時，除了有產(chǎn)生想法的能力，還要有及時放棄想法的能力。因為我做出來的東西，要面對的從來不是那幾個數(shù)據(jù)集，幾個指標，而是實打?qū)嵉挠脩?/strong>。我向來認為，指標可以控制，gold 集合只能定性，最終的作用才是最重要的。所以，在工業(yè)中做算法，又必須要嚴謹，那么除了扎實的背景知識，還需要分析能力，以及下這些笨功夫的耐心。
我認為合格的算法工程師，應當具備相當?shù)?strong>分析能力。遇到問題的時候，能一步一步地找到問題的根源，并提出扎實的方法去解決它。扎實的方法指的是，每一步都是在切實地解決問題，有可靠的邏輯、理論支撐。而不是一拍腦門，就覺得某一個方法可以用，唯 SOTA 論，看了論文就覺得這個方法肯定 work。這種分析能力和提出扎實方法的能力，其實就是一個算法工程師的方法論。
例如，我一直說，模型預測時的表現(xiàn)通常反映了訓練樣本中的現(xiàn)象。所以，通常我們解決 case 的流程為：
所謂做算法，尤其是想要落地或者推廣，大多數(shù)時候的確更像是做數(shù)據(jù)，下這些笨功夫。相對來講，很多“靈光一現(xiàn)”，或者僅僅以指標為基準，看到的論文中的方法，多數(shù)在腦暴會議中就會被 fail 掉。那些方法要么在理論上不靠譜，要么徒增算法的復雜度，卻僅僅解決了一小部分問題。
畢竟，部分學術(shù)打榜任務，更像是先有了指標，后有了任務或數(shù)據(jù)，而不是以實際需求為基準，去定義相關(guān)的任務及數(shù)據(jù)。例如，充斥著大量遠監(jiān)督數(shù)據(jù)的各路關(guān)系抽取數(shù)據(jù)集（不僅僅是在 train 中，也在 test 中），但又僅僅給出了文本數(shù)據(jù)；中文需要自然語言推斷任務，則機翻了一個數(shù)據(jù)集，得到了某中文推斷數(shù)據(jù)集；中文需要自己的理解榜單，就有了高 bias 的某文本相似判定數(shù)據(jù)集；有著大量不可推斷關(guān)系的某知識圖譜補全數(shù)據(jù)集（知識圖譜補全本身也是個指標大于需求的任務）等等。
例如，ACL2021 某方法在某數(shù)據(jù)集上的實驗結(jié)果中，隨機初始化參數(shù)的模型和 BERT 模型對比，召回相差10個點左右，而在 tuning 好的模型上，將頭尾實體 span 替換成對應的 type （如 China 替換成 country），抹去三元組本身可能過擬合的信息后，召回下降40個點有余。case 分析發(fā)現(xiàn)，替換后的正確召回的確是通過文本理解得到的，而遠監(jiān)督得來的三元組，的確大多被判定成了 unrelated。使用先驗知識的增益可能僅僅是10個點（所有方法用 BERT 和不用 BERT 的區(qū)別都是10個點左右），那么其余的30多個點，大概就是三元組名字過擬合了吧。
這些任務，以及發(fā)論文唯指標論的風氣，也就造成了算法相關(guān)工作從學生到工作最大的 gap。
我在工作中見到的刷分團隊，其成果很多都是兩只腳皆踩在虛空之上。他們在試圖將自己研發(fā)的所謂“算法”落地時，做的事情往往就是：管應用方要一份數(shù)據(jù)集，把分數(shù)刷上去，超過某些方法，就算是交付了，卻完全不分析問題。刷分的手段包括但不限于搜參數(shù)（提幾百個任務爆搜，連訓幾個 epoch 都要搜），堆大模型，搞集成。不會優(yōu)先考慮工程上是否能接受，是否具備應對其他情況的泛化能力，或者這個“算法”是否還有未來成長空間。于是就會導致——一波又一波地趕著熱點，或許能發(fā)不少 paper，但很難做出來一個能夠落地應用的算法。
說了這么多，看上去我描述了一種極端——就是算法工程師就是在悶悶地做分析，做工程優(yōu)化等，似乎與前沿研究毫不相關(guān)。不是的，算法工程師也要花費相當?shù)臅r間去刷論文，了解相關(guān)的前沿領(lǐng)域發(fā)生了什么。只不過，擁有了這些分析能力及經(jīng)驗后，在遇到前沿論文時，就會具備能力去拆解一篇論文提出的方法中的每一個組件，吸收其中有價值的 idea 用到自己的項目當中（而非一定要全盤復用論文，或者糾結(jié)論文中方法之外的細枝末節(jié)）；或者受到論文中某一個 idea 的啟發(fā)，提出適用于自己的方案。畢竟，AI 領(lǐng)域，大家的方法都是明牌，數(shù)據(jù)也是海量。真正理解了“為什么”，才能讓它們發(fā)揮作用。
舉個例子。在過去一年的工作中，我根據(jù) Cross-Thought 的論文，提出了一種簡化版的優(yōu)化方案，應用到了我的預訓練語言模型中，在序列標注任務上取得了一定的成績，用一種相對樸素的方法就能得到十分有效的句子的表示。
再比如，我們還將 prompt 方法直接應用到了細粒度分類任務中，并根據(jù)模型測試時的一些表現(xiàn)，得出了用 prompt 去清洗訓練數(shù)據(jù)，優(yōu)化其他模型的方法。這個方法已經(jīng)在我們的一個落地項目，以及某一個學術(shù)任務上有了初步成效。同時也孵化了一個文本挖掘框架，今年完成了開源，填補了某一個空白，在相關(guān)領(lǐng)域的開發(fā)者中頗受好評。小弟不才，在接下來的 WAVE SUMMIT 峰會上，會上場介紹我們最新的成果。
列位可能要問了：有些 idea 可能就是靈光一現(xiàn)，完全憑借靈感和直覺想到的，而非基于繁瑣的數(shù)據(jù)/任務分析。以我說的這種工作風格，這類想法就應該直接放棄？那不就相當于只能做些細枝末節(jié)的改進工作了么？
不，扎實的工作風格不代表會錯過變革。近些年的經(jīng)典論文，如 Transformer 、BERT、RoBERTa 等工作，都有相當?shù)睦碚撘罁?jù)做支撐，其核心思想的立足點，都是相當扎實的，它們自然他們也就成為了經(jīng)典。而我們看后面涌現(xiàn)了很多不知所謂的改進，哪怕不斷地刷新SOTA，卻往往又掀不起什么其他的浪花（更有一些直接被其他研究者用理論去推翻或證明某種改進是有相當?shù)南拗频?，或過于繁瑣的）。
這里我也分享一下我在看待一篇工作時常用的視角。
我在觀察一個模型的時候，觀察的重點一般是這模型計算某一答案時，利用的信息是什么。
例如，我曾看到一篇用圖神經(jīng)網(wǎng)絡建模依存關(guān)系樹的工作，任務是關(guān)系抽取。作者的假設是：語法依存關(guān)系是對關(guān)系抽取能起到作用的。
當我看到這一模型后，心路歷程是：首先，一些依存關(guān)系的確可以直接表明實體間關(guān)系。使用部分依存關(guān)系去強化文本 token 之間的關(guān)系看上去也是合理的。但是，做過關(guān)系抽取的也都知道，并不是所有的依存關(guān)系都可以去抽取實體間關(guān)系的。有些關(guān)系引入了、強調(diào)了，則是在引入噪音。所以我當時的第一個疑慮就是：在建模的時候是否對邊的關(guān)系有所區(qū)分（比如用門控結(jié)構(gòu)去控制強調(diào)，或者用不同的矩陣往不同的空間上投影）。另外，依存關(guān)系的不可傳遞性與統(tǒng)計模型的連續(xù)空間上存在的一種天然沖突，是否會造成問題。
援引我最近讀的一本書中看到的一句話：搞深度學習的人，都應該學習一下計算理論。
工作以來，我越來越感受到，自己得以將各類方法拆解改造、化為己用，這份能力主要都仰賴于我接受過的數(shù)據(jù)結(jié)構(gòu)與算法訓練。
上面提到，與其是做算法，更多時間則是在做數(shù)據(jù)。而在工業(yè)界，我們最不缺的就是數(shù)據(jù)——與其說是“做數(shù)據(jù)”，不如說是“選數(shù)據(jù)”。從海量的數(shù)據(jù)獲取合適的訓練樣本，則需要繁瑣的策略、高效的方法作為支撐。用對了方法，運行效率可能就是幾百倍的差異，迭代模型的周期亦是天壤之別。
除數(shù)據(jù)結(jié)構(gòu)和基礎算法外，頂層設計能力同樣重要。無論是單兵作戰(zhàn)，還是團隊協(xié)同，扎實、漂亮的工程設計都會讓我們在效率（甚至心情）上有質(zhì)的變化。
具體的實施細則在大學 CS 課程中已經(jīng)多有強調(diào)。不過，光關(guān)注那些說教型的細則還是遠遠不夠，更多的其實還是多寫，多想，多看。看一看別人的代碼中，有什么設計或編碼技巧可以吸收借鑒的。想一想自己在某個工程中寫出來的基礎模塊，之后在其他工程里還是否愿意復用？在團隊協(xié)同的時候，別人調(diào)用你開發(fā)的模塊是否會遇到困難？
除此之外，工程能力還有一個重要方面，就是工程方案的選擇。
工作過程中，總是不可避免會應用其他人開發(fā)的東西。而當我們擁有選擇權(quán)時，就要能清楚哪個方案更加適合自己的任務。
基于個人的工作經(jīng)驗，我也總結(jié)出了一些原則：
明確的，而非黑盒的。比如，有個分布式工具，它可能“看上去方便”——用簡單的幾行指令即可完成較為復雜的需求。但沒有任何文檔說明它中間如何生成各種復雜邏輯，也不提供任何代碼可供研究。相比之下，我還是寧愿選擇自己下一些笨功夫。
簡潔的，而非復雜的。還是以分布式工具為例。如果原本三兩個節(jié)點就可以解決的問題，它卻生成數(shù)倍的節(jié)點。當然，也就造成了數(shù)倍的調(diào)度和I/O，以及數(shù)倍的資源占用。即使它其他方面做得再好，我還是會盡量棄之不用。
可控的，而非限制的。也舉個例子。如果一個模型訓練套件，定死了輸入樣本和輸出的格式，或者測試步數(shù)、保存邏輯也定死了（不寫文檔四舍五入也差不多算定死了）。再有甚者，可能連給出的模型也是加密的。相比之下，我肯定愿意選擇更可控的方案，或者干脆完全自己寫。
魯棒的，而非漏洞的。例如，框架版本選擇，一定選擇有人維護且完善的版本，而非久遠的舊版本。部署中臺，也一定選擇 log 明確，錯誤好查，容易定位，部署過程穩(wěn)定的，而非每一個步驟都有崩潰的風險，更換一個開發(fā)版本直接 bomb 的。
（上面列舉出的都是一些虛構(gòu)的極端例子...如有雷同，純屬巧合。）
寫這篇文章，是因為看到了知乎上關(guān)于算法工程師的“職業(yè)護城河”的一些討論，也有感于工作過程中見過的一些事情。希望上面的內(nèi)容能幫助一些小伙伴剛在入行的時候迅速跨過心理落差，更好地投入業(yè)界。
正如開篇所說，這些經(jīng)驗和想法，帶有非常濃厚的個人印記。全都是一家之言。如果不贊同，還請一笑了之。
