Dcard Machine Learning team 在做什麼？一次公開團隊合作分工和挑戰！

很開心有這個機會可以和大家分享 Dcard 的 Machine Learning team，事不宜遲，就開始就介紹團隊在做什麼吧。

介紹 Dcard Machine Learning Team

在聊聊 Machine Learning 團隊之前，先來聊聊 Dcard 的資料團隊的組成！

Dcard 的資料團隊主要分為三塊：Machine Learning / Business Intelligence / Data Infrastructure，分別執掌的是面向使用者的產品 / 輔助公司夥伴決策及分析支持 / 建立良好的資料工程基礎，讓其他團隊可以很好且很快地運用資料產生價值。

而 Machine Learning 團隊專注於應用 Machine Learning 技術到產品上，在 App 或網頁供使用者使用，如文章推薦、廣告推薦等。在開發的過程中，團隊漸漸發現有良好的基礎建設的支援越來越重要，因此在近期和 Data Infrastructure 團隊做整合，去發展更加堅強的基礎建設來幫助其他團隊去發揮資料的最大價值，同時也加速讓算法上線所需要的時間以及提高穩定程度。

而整個 Machine Learning 團隊的工作性質主要較偏於工程導向而非研究導向，團隊專注於利用算法解決產品遇到的問題，舉例來說：團隊關注怎麼設計演算法問題 / 模型以及探索 feature 去提升在意的指標或是目前的做法跟產品想要的目標有沒有在一致的。因此 Machine Learning Team 做的東西基本上都可以對產品可以立即產生影響力，在上線之後就可以快速觀察到使用者的反應。

在日常生活中，Machine Learning Team 工作的範疇大概有：模型設計、模型上線、實驗設計、模型所需的資料工程及 MLOps，並探討模型與產品的關係。

Machine Learning Team 怎麼合作

目前團隊依據開發的專案而拆分為不同團隊，像目前 ML team 就分成 4 個專案團隊，負責算法的 Machine Learning Engineer 分別跟 Infra 和 BI 都有密切合作，開發出實際應用在產品上的專案，如前者提到的廣告、推薦系統。

分成不同專案是因為觀察到隨著產品的功能與需求增加，不同產品所需要的 domain knowledge 以及遇到的挑戰都會不一樣，所以把專案劃分出來持續迭代，對整體產品會有好的影響。這時在不同專案團隊間，溝通就會是重要的課題。

在每個專案團隊裡，在專案運行的時候，我們借重 Scrum 隨時掌握彼此情況的精神，每天透過 Daily Sync 快速了解團隊成員的進度以及遇到的困難，並快速討論出 action item 之後實作。除此之外，團隊對開發流程的順暢程度有著高敏感性，Machine Learning 團隊也會有自己的 CI/CD 與 code review 流程，而近期為了讓過程更順暢，團隊也決定要改善 unit test 的環節。

其實在團隊內待久了就會發現，開發跟會議佔比大概在 7:3，雖然我們花更多時間在打程式，團隊仍不會忘記溝通的重要性。平時在辦公室裡，辦公室的位子非常開放，彼此的辦公桌間也都沒有隔板，只要你遇到問題想找人討論，轉個頭就能找到人跟你討論交流了！

除了專案的運行之外，對於算法相關的推進，團隊定期也會有討論，主要會專注於下列幾點：

• 思考算法與產品之間的關係
• 目前算法還有哪些可以發展的空間及機會
• 看其他公司 or Top Conferences 公開的 paper / 分享（如 RecSys)

在做重要決策時，我們多採討論方式，也透過這樣的方式讓成員們都清楚最終要達到的目標為何 (why)、要做的事情是什麼 (what)。並藉由制定 OKR 的目標 (Objectives) 來確認 KR (Key Results)，了解具體細節該如何達成 (how)。透過充分的討論團隊與個人目標後，發展出自己的行動方案，對於長期產品開發流程才更能達到比較健康的生態。

我們遇到的挑戰

算法面的挑戰

在處理算法面的問題時，我們遇到的挑戰會有下列幾個點：

• 目前的模型設計是不是跟產品想要的目標是接近的？如果不是，可以怎麼調整（例如調整 Objective）
• 選用的 offline metrics 跟線上想觀測的目標的接近程度？ Offline evaluation 是某足夠具有代表性去幫助我們快速選擇模型？
• Online A/B testing 應該要怎麼設計，在統計上才足夠公平？
• 如何在開發時程上做掌握，例如說嘗試某個方向的時候，如果不如預期的話，什麼時候該是個停損點？

工程面的挑戰

我們的挑戰不只來自於建構模型，還需要把模型整合上線、控制上線的穩定度跟解釋性。對我們而言，流量控制就是一大考量，當流量大，QPS (Queries Per Second，每秒查詢率) 就會高，因此我們需要：

• 研究如何把模型上線以及控管模型的穩定度（即最近蠻多人提到的 MLOps）
• 監測並管控流量
• 保證回應速度可以維持在一定水準之上
• 同時考慮模型速度以及精確性怎麼取得平衡

在資料量大的情況下，資料需要清理跟驗證，而資料的品質跟模型穩定度、解釋性有關，資料越乾淨，就越能保證預測結果的品質。

Dcard Machine Learning team 特別的地方…

1. Data Driven — 在團隊內任何的分析與決策都是圍繞著重要指標運作，擬定產品開發目標時，都是依據 OKR 的設定來衡量是否有價值，藉此確保夥伴們都在同個軌道並朝著相同目標前進。比起仰賴感覺來判斷，我們更重視依靠數據來思考。
2. 快速前進 — 能夠跟一群很厲害的人一起工作，不論在技術或合作能力都會有顯著成長。且團隊步調很快，我們期待產品能夠快速前進，相對的每天也會遇到許多挑戰，像是如何把廣告系統架起來承受高流量，或是如何維持資料更新即時又快速等。
3. 流程優化 — 團隊很在意流程是否順暢，所以會持續思考如何合作會更有效率。我們會捲起袖子，直接去改變困擾我們的事物，優化整個開發跟生活的體驗。
4. 持續成長 — 除了例行性的讀書會，我們會透過團隊內的 Developer Session ，了解不同 domain 的夥伴做過哪些專案；也會邀請團隊外部成員向我們分享其他團隊成功案例或開發過程。
5. 團隊支持 — 對於 ML 的開發跟專案的推進，CEO 常常會提供我們一些建議。此外，他同時也相當 open-minded ，對各種的想法都很樂於接受，尊重每個人的意見，讓團隊能夠在討論過程中找到最合適的方法。

未來發展

隨著產品的走向越趨多樣與複雜，團隊接下去的分工也會更細緻。除了繼續以開發專案進行分工，我們也嘗試開始慢慢分出 Machine Learning Engineer （算法）跟 Machine Learning Backend Engineer / Data Infrastructure Engineer （工程）的角色，因此團隊內的溝通會變得更加重要。讓我們持續保持專案的透明度，更能了解 (1) 彼此在做什麼 (2) 為什麼做這個決定，達成團隊內外掌握對等的資訊。

另一方面，我們也持續調整團隊的合作模式與開發流程，固定每一季會開 retro 的會議。成員們一起檢視整體產能與效率，討論是否有更好的發揮空間，讓 Machine Learning team 在下個季度能更有效率地開發新功能或新產品。

對了，若是你投入在 Machine Learning 領域，同時也對 Dcard 有興趣的朋友們，歡迎隨時來和我們聊聊！

Machine Learning Engineer — https://dcard.link/p5boNm

Machine Learning Engineer (Ads) — https://dcard.link/EdslG2

ML Infrastructure Engineer — https://dcard.link/C1xTlU