Hi 讀者，
相信大家都很關心 OpenAI 第一次的 DevDay 內容和各種技術細節，除了直接看影片和文件，我們也很推薦大家可以從別的角度來分析這次的發表會，例如 Ben Thompson 寫的〈The OpenAI Keynote〉，除了商業策略，其中兩個很特別的切角是「Keynote」這件事本身，另一個則是從消費者的角度去分析。
另一件想跟大家分享的事也剛發生，知名的電子報《The Pragmatic Engineer》作者 Gergely Orosz 出版了新書《The Software Engineer’s Guidebook》，內容聚焦在如何駕馭科技、新創公司裡的資深技術職位。目前紙本書已經開賣，電子書會比較晚才上市。
Titan
[optin-monster-inline slug=”hlq7r8kikxf7imrv22xq”]
[中] 李昀璇／新光人壽揭資料治理關鍵，讓業務部門擔任資料擁有者，來管理資料品質
原文連結｜閱讀時間：5-10 分鐘
過去我們有跟大家分享建立數據文化與資料治理的議題，最近新光金控資訊長林國彬在一場研討會中分享新光人壽的資料治理工程的階段性成果，內容包含他們是怎麽分析問題、建立對應的架構，以及執行面的實際作法。「資料絕對是 AI 發展的基石。」林國彬以此點出資料治理的重要性，也不忘分享推動資料治理的手法。
新光人壽自 2015 年起推動數位轉型，隨著資料使用程度大幅提升，相關的資料問題也隨之浮現。他們先建立資料品質管理流程與制度，做法是先設計資料治理架構，確立權責，並且讓業務部門也參與資料管理；至於資料本身，新光人壽先將原本超過一千項的原始資料，收斂到 60 項以內的「關鍵欄位」優先處理，再藉由資料品質儀表板以不同維度追蹤。目前他們的資料治理工程進行到第二階段，有興趣的讀者不妨閱讀原文並且持續追蹤。
[英] Netflix 工程團隊／我們打造了一個影片搜尋功能，讓創意團隊快速找到所需的素材
原文連結｜閱讀時間：5-10 分鐘
我們知道 Netflix 影像創意團隊會製作大量的影像素材，例如發表在 X 或 IG 上的短影音或 GIF，還有預告片等等。那麼該怎麼樣才能快速找到所需的片段呢？如果每一次都要捲動整部影片去找合適的鏡頭，是不是很沒效率？更何況有時需要來自不同電影的同類型鏡頭（例如飛車追逐畫面），這就好比要從乾草堆中找出一根針，卻是創意團隊工作流程中的關鍵和痛點。
最近 Netflix 工程部落格發表了一篇文章，分享他們如何打造出一種可使用文字快速搜尋影片素材的內部系統。文章可分成方法和工程面兩部分。這套系統利用對比學習（contrastive learning）技術來訓練影像和文字的聯合嵌入空間（joint embedding spaces），使得模型能同時學習物件、場景、情緒、行動等元素。而且以圖-文配對的訓練模型作為起點，再用內部的資料集（影片片段和相應的文字描述）去訓練影片-文字配對（畢竟影片就是一連串的影像），提升用文字檢索影片的表現，而且後來還能進一步找出特定屬性（例如特寫鏡頭）的影片，甚至做到「以影片找影片」。
有了文字和影片的解碼器之後，團隊就可以在鏡頭的層級去運算影片嵌入（video embeddings），放進他們的媒體特徵庫，再複製一份到 elastic search 叢集去做即時的最鄰近查詢（nearest neighbor query），接著解釋了他們怎麼在雲端環境有效運用 GPU、建構整個流程。文內提供更多他們如何善用內部資料的相關文章連結，感興趣的讀者不要錯過了。
[英] Stephan Schmidt／明明一開始用 Scrum，怎麼又走回瀑布式開發？
原文連結｜閱讀時間：5-10 分鐘
不知道各位讀者有沒有這種經驗：不管團隊用什麼模式來開發，最後還是因為某些原因變得比較像是傳統的瀑布式（waterfall）開發。本文作者 Stephan Schmidt 是工程師，也曾經創業過，職涯很長的時間都擔任 CTO，後來開始擔任 CTO 教練。這篇短文是他分享一位學員的困擾，進而思考為何即便是跑 Scrum，還是有可能變成「Scrumfall」，他認為並不是流程有問題，問題出在流程以外的驅動力。
Schmidt 先回顧了一下軟體開發工作是怎麼導入原本工業和工程的做法，然後隨著網路的出現、市場競爭加劇而改變，瀑布式開發不再適用，然後有了敏捷（Agile）和各種實踐敏捷開發的框架，例如 Scrum 和看板（Kanban）等。那為何人們往往會從 Scrum 退回 Scrumfall 呢？Schmidt 指出問題之一出在產品負責人（product owner, PO）只是在管理外部利益相關人士的需求，並不是真正的負責人，他說這就好比身為一輛車的主人，卻無法決定車子要往哪裡開。Schmidt 在文中繪製了一張圖表，解釋為何最終「瀑布又殺死了敏捷」，他說那些利益相關人就像迪士尼樂園的排隊人潮，渴望知道「大約要排 60 分鐘」——他們只關心跟自己有關的東西何時會交付，就是這點在驅動瀑布式開發。
[中] Yuren／筆記歸類：建構自己的偵探證據牆
原文連結｜閱讀時間：5-10 分鐘
使用圖表向來是視覺化溝通的重要工具，過去幾年除了 Miro、FigJam 等協作軟體大受歡迎，新一波的筆記軟體（或說知識管理工具）如 Obsidian 和 Logseq 等也陸續加入畫布（canvas）功能，更不用說原本就注重視覺化的 Heptabase。而本文作者、工程師 Yuren 要跟大家分享過去半年來他怎麼運用 Obsidian 畫布功能解決他使用筆記軟體時的困擾：找出筆記間的關聯性。
Yuren 平時就會在筆記加上「See Also」段落，但他發現自從筆記變多後（例如超過一、兩百篇），要找到相關筆記變得很困難，更不用說已經累積到破千之後的筆記量，而他試過標籤或分類等方法也不盡理想。他將所有的筆記都放到同一個畫布，並且將相關的筆記放在一起，這樣做有兩個好處：1. 一瞥式的閱覽；2. 視覺距離的關聯取代分類。至於分類與標籤相較之下效果就顯得較差。
閱讀更多內容，請看《RISE-UP 科技人才升級週報》各期目錄。
