文 | Jazon
編 | 小軼

大家好，我是 Jazon。作為 AI 科研工作者，我們的目光不該只聚焦在開發新技術、刷榜打 SoTA 上。學界如職場，還有很多技術之外的軟實力需要培養。這篇文章里，我想以我個人的經歷作為切入點，聊一聊與此有關的兩個話題：

• 實驗室文化；

• 團隊合作下的代碼質量。

背景介紹

在我之前的文章里提到，筆者現在在 Stanford 攻讀計算機碩士項目；和中國的研究生不同，美國很多 CS 碩士項目（包括我們項目）中，做科研不是畢業的必須要求，也不需要有固定的導師。一個學期里，可以在 lab 打工，也可以純上課；如果在 lab 待得不喜歡，或者項目做完了，下學期可以選擇換導師。

作為碩士生，尋找科研機會有很多途徑，比如直接聯系老師或PhD，或者有的lab有專門的申請表格。另外，有些 project 的招人廣告，會在系里以郵件的形式廣播給所有同學。

2020年11月，我便通過這樣一則招人廣告，經過面試、測驗，申進了 Stanford 商學院的 Social Impact Lab，之后直到研一結束（2021年6月），我在這里作為 RA（research assistant），做一個推薦系統方面的科研項目。Lab 的導師 Susan Athey 是經濟學出身，美國科學院院士，24歲就博士畢業，維基百科上她的詞條有13種語言，非常厲害。

關于我這次科研項目的技術細節，有興趣的朋友可以訪問我的個人網站查看（請參見文末“閱讀原文”的鏈接）；本文主要是想吐槽一下技術以外的方面。

周報制度

剛入 lab，第一件讓我頭疼的事是lab的周報制度。在這里，我每周必須上報一個 Progress Report，里面主要分為幾個模塊：

目標；

職業發展：

本周總結；

下周計劃。

其中，“目標”模塊需要列出所有進行的 project，它們對應的 deadline，以及現在完成的進度。

“本周總結”要列出本周在每項工作上花了幾個小時。

而“下周計劃”要列出計劃的任務，以及各自預計需要的小時數；每項 task 不能超過4小時，否則需要將其拆分成更小的 tasks。

剛入 lab 時，我對手頭的任務還一頭霧水，要我列出這么詳細的計劃，這讓我很頭疼。隨著時間的流逝，我對項目漸漸熟悉，但寫周報仍然是件很心累的事。

在我看來，科研和其他工作不同，探索的方向有很大不確定性，需要自由的思考空間來獲取靈感。拿我的項目來說，我們有個大體的目標：提升某個平臺上推薦系統的表現，細分下來有“用怎樣的評分標準”、“冷啟動怎么解決”等問題。但是更加細分的課題，不少都是在實驗、閱讀過程中自然出現的，無法提前預知。

另外，嘗試量化每項任務的耗時，我覺得也不合理。寫代碼的工作本來就很難預測用時，更何況在科研的情境下，失敗是家常便飯，經常會試了各種方法發現行不通后放棄，完成任務需要的時間就更不可控制。

每次的周報，我都得花大概1小時完成；如果沒有按照規定的格式寫，就會被 lab 的 HR 發郵件要求改正。半年下來我一共被四五次“建議修改”，都是些我覺得并沒有必要的格式性問題，我也只是象征性地改一改應付一下，比如加一些實際上意義不大的“任務 deadline”。

▲Stanford GSB

我們 lab 的領域之一是經濟管理，理應深得領導力之道，但 lab 里這種“時間管理導向”的文化，讓不喜歡刻意管理時間的我，很難適應。有一次我甚至吐槽，寫這種周報是“血汗工廠”行為……

其實這個周報制度，是有不少好處的，有助于自己梳理工作進度、總結工作效率。另外周報里第2部分“職業發展”，要求列出近期的職業目標（計劃去哪實習，或者何時開始求職），鼓勵大家思考當下的工作對自己短期、長期職業規劃是否有利，也很有意義。

只是我個人對周報的感受，更多還是負面的。這也反映了在某種程度上，我和 lab 的文化不太搭吧……

代碼質量

在不少互聯網公司，都有對代碼質量嚴格把關的機制。比如變量命名要遵循一定的標準，每個方法超過幾十行要拆開；再比如有完善的 version control 系統，一段代碼需要跑通測試、經過多人審核通過，才能部署使用。

但在很多實驗室，大家寫碼普遍比較隨性（如果你看過或用過 AI 方面論文對應的 GitHub 代碼庫，可能對此會有同感）。如果是自己一時用，那沒有問題；一旦是需要反復跑的，或者是需要別人合作的代碼，隨意寫碼的習慣就會帶來問題。

4月的時候，我的 mentor 要求我在他寫好的 pipeline 里加幾個模塊，跑一系列新實驗。然而，在這個代碼框架下，我連加一個 baseline 都非常困難。大致來說：

• 各個方法之間的關系錯綜復雜，如果出了問題很難 debug；

• 一個方法的輸入，有時應是 pandas DataFrame，有時應是 PyTorch tensor，如果是 DataFrame，可能還需要含有特定名字的 column。這些都沒有任何文檔或者注釋說明，加上由于是 python 寫的，無法直接知道每個變量是什么樣的數據結構；

• 一部分變量名寫得不清楚，甚至可能有誤導性，比如有個叫 “input_file” 的變量，實際代表的是 output 文件。

我和mentor反映了這套代碼使用起來比較困難，他卻好像不理解我的處境，覺得改這套代碼是很簡單的事。

推薦系統小組里只有我們2個搞技術的，我自己說不動他，也找不到其他人可以幫忙；在產出實驗數據的壓力下，我只能違反他的意愿，自己從頭寫了一套跑實驗的 pipeline，從處理數據，到搭建模型，再到 train 和 test，最后可視化結果。

這樣的好處是，我對代碼的邏輯有完全的掌控，一來出了 bug 更容易 debug，二來如果要修改代碼實現新功能，也能更快上手，靈活了很多。

當然，寫自己的風險就是：我的代碼相比原來別人寫過的，可能有我注意不到的問題，或者代碼的行為會有細微的、難以預測的差異，解決不好的話一樣會卡進度。

果然，我的代碼也出了問題。我犯了個低級錯誤，把 test set 當成 validation set 用；但這還是件小事，要命的是，我的 mentor 說，相比他花了很久搭好的 pipeline，我的跑實驗代碼“正確性尚未驗證”，他就無法完全信服我跑出來的數據。這一點，后來直到我離職都沒完全解決。

歸根結底，軟件架構這東西是需要一個牛人來搭建的，合作者去使用或加入模塊應該是一件輕松的事情，不用管 pipeline 里其他的部分。但我在 lab 里的體驗，就是處于與此相反的境地，于是引出了一些麻煩。

結語

這篇文章吐槽了很多，并不是說這次科研 project 的體驗不好。實際上這是一次很充實的經歷——探索未知課題的過程有很多樂趣，我的 mentor 和導師也很關心我，在技術上給了我很多指導，我非常感謝這次難得的鍛煉機會。但我希望能總結一下感受不那么好的地方，希望自己，以及處在 AI 行業的讀者你，可以從中學到一些道理~

萌屋作者：Jazon

來自南京，斯坦福MSCS（計算機碩士）在讀最年輕的中國人，預計2022年畢業。愛安靜地探索宇宙的奧秘，也愛和朋友桌游、運動。夢想養貓，花花與三貓的視頻平均每個看過20+遍。相信AI雖然有趣，但短期內在美國職場生存，還是要靠豐富的開發技能。

作品推薦

人在斯坦福，剛上CS224n

謝撩，人在斯坦福打SoTA

后臺回復關鍵詞【入群】

加入賣萌屋NLP/IR/Rec與求職討論群

后臺回復關鍵詞【頂會】

獲取ACL、CIKM等各大頂會論文集！

總結

以上是生活随笔為你收集整理的我在斯坦福做科研的碎碎念的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。