Shopify 的「自動研究」重度使用者不是 ML 工程師，是 PM：Tangle/Tangent 怎麼把 AutoML 真的民主化

本文整理自 Latent Space 2026 年 4 月播出的單集，受訪者為 Shopify 技術長帕拉欣（Mikhail Parakhin）。他在加入 Shopify 前，是微軟（Microsoft）旗下含 Bing、Edge、Ads、Windows 在內事業群的執行長，更早之前在俄羅斯網路巨頭 Yandex 主導機器學習與 Alice 數位助理。原始單集約 110 分鐘。

{{< youtube RrkGoX3Cw7o >}}

---

Karpathy 的「auto-research」在 Shopify 不是概念，是已經 production 的東西

訪談一開頭，帕拉欣就帶著一點玩笑語氣提到，他幾天前在 X 上看到前 Tesla AI 總監 Andrej Karpathy 發了一則貼文，講組織 agent 來儲存與查詢資料的各種做法。帕拉欣半開玩笑地回了一條，說這些做法 Shopify 早就在用了，連他和 Toby Lütke（Shopify 創辦人兼執行長）都各有偏好：Toby 是 QMD 的死忠粉，他自己則更喜歡 SQLite。Swyx 順著這條線追問，發現帕拉欣是想藉這個小故事帶出後面更大的話題：很多 AI 圈當下熱議的概念，在 Shopify 內部其實已經跑了一段時間，而且跑得很大規模。

最具代表性的就是 Karpathy 近來在公開場合反覆推廣的「auto-research」（自動研究）。簡單來說，這是一種讓 agent 自己跑成百上千個實驗、改寫程式碼、依損失函數爬山找最佳解的工作模式。Karpathy 認為這個模式會徹底改寫機器學習研究的速度。帕拉欣同意這個判斷，但他想補一句更有殺傷力的：Shopify 不只在做 auto-research，還已經把它放進一個更大的內部資料管道平台，產生了實際的工程戰績。

那個更大的平台叫 Tangle，疊在它上面的自動研究系統叫 Tangent。在帕拉欣的描述裡，這兩件東西已經像野火一樣在 Shopify 內部傳開：每天都有人在 Slack 上貼出「我用 Tangent 又把某某流程的吞吐量推高了多少」、「某張表的儲存被去重掉一半」。不是 ML 部門特例，而是橫跨全公司各種職能的人都在用。能讓一個內部工具產生這種擴散速度，靠的不是漂亮的介面，而是背後那套架構讓 auto-research 的「觸發成本」低到可以隨手用。

Tangle：橫跨三家公司、三個世代的資料管道平台

要理解 Tangent 為什麼能擴散，得先理解 Tangle。帕拉欣形容 Tangle 是他職涯中第三代資料管道系統。他在微軟時主導過第一代叫 Ether 的東西，到 Yandex 之後又做了第二代叫 Nirvana 的版本，到 Shopify 後把前兩代踩過的坑全部累積出來，做出了現在這套 Tangle。它的目標是讓 ML 實驗、資料前處理、訓練、上線這條鏈在同一套工具裡可組合、可分享、可版控。

它的設計重點有四個。第一，跨語言可組合，每個元件都是 CLI 程式包一層 YAML，Python、Rust、Go、SQL 寫的元件可以無縫接在一起。第二，視覺化編排，整條 pipeline 看起來就像一張流程圖，每個節點點開就能看程式碼與輸入輸出。第三，全程版控，每次跑都可以重現。第四，一鍵從實驗模式切到 production，這條路徑在大多數公司是兩個工具、兩個團隊、兩套配置，Tangle 把它合在一起。

這四件事單獨看都不算革命性，但加在一起就把使用者體驗往上拉了一個量級。帕拉欣特別強調，Tangle 已經開源在 GitHub 上，他們也寫了一篇官方部落格詳述設計理念，外部公司也可以拿去用。對於正在為自家 ML 工程化投入的臺灣團隊，這份設計藍本本身就值得拆解。它不是一個雲端服務、不是一個 SaaS，而是一套「我們踩過的坑寫成的程式碼」，這種方式在開源社群裡更有共鳴。

隱形的組織級節省：當你跑過的步驟，自動幫整個公司省下重跑成本

但 Tangle 真正的殺手級功能，藏在一個很容易被低估的細節裡：內容雜湊快取（content-hash caching）。Swyx 在訪談中問到這個機制時，帕拉欣的反應是「這才是最大的省錢點，但很多人會講錯重點」。他解釋，多數人介紹 caching 都會說「下次同一個 pipeline 重跑會更快」，但這是 90 年代就會做的本地優化，不是真正的價值。

真正讓他興奮的，是 Tangle 把這個 cache 推到組織層級。每個資料處理步驟跑完，Tangle 會用內容雜湊產生一個指紋，把結果存在組織共享的儲存層。下次任何人、任何團隊、任何專案，跑出指紋一樣的步驟，Tangle 就直接把結果端出來，根本不需要再執行一次。換句話說，假設有十個工程師獨立寫了一段「把上週的訂單資料清洗成同樣格式」的程式碼，這個步驟在整個公司會被執行的次數是一次，不是十次。

帕拉欣特別點出，這種節省最大的一塊不是個人的重跑，而是「你不知道別人也在做」的那種跨團隊重複勞動。他說在 Shopify 大到一定規模之後，根本沒辦法手動知道哪些團隊在做類似的資料前處理。沒有 content-hash caching 之前，這些重複勞動是徹底隱形的，每個團隊各自燒運算費用，組織層面看不見。Tangle 把它們一次性消化掉之後，工程資源就被釋放出來投入更有價值的事情。

「節省其實不是來自於你重跑自己的工作，」帕拉欣說，「而是來自你做完之後就走人，然後某個你根本不知道存在的部門，半年後跑同一個任務在新版本上，他們其實連執行都沒執行過。」這個說法把 cross-team dedup 的價值講得淋漓盡致：傳統組織衡量不到的浪費，正是被一個架構動作消化掉的浪費。

Tangent：把 auto-research 推進每一個可量化的工程問題

有了 Tangle 這層基礎，Tangent 才能跑得起來。Tangent 是一個 agent 系統，它會讀取 Tangle 上的 pipeline，針對特定損失函數設計實驗、改寫程式碼、收集結果、做下一輪假設。這個動作對 ML 工程師來說不陌生，但 Tangent 把成本壓到可以「隨手起一個」的程度，而且可以對任何能量化的工程指標跑（不限於模型訓練），所以才會在 Shopify 內部擴散得那麼快。

帕拉欣說 Tangent 在兩個層次運作。第一層比較淺：它會在既有元件之間洗牌，例如把 XGBoost 換成 PyTorch 的某個模組、把某段 SQL 改寫成另一個寫法。這層只動接線，不創造新元件。第二層比較深：因為 Tangle 上的每個元件本質都是 CLI 程式包一層 YAML，Tangent 可以直接讀程式碼、改寫，甚至生成新的元件。這兩層可以互相組合，所以同一個 Tangent 任務可以同時在「找最佳組合」和「發明新組件」兩個維度上爬山。

Shopify 拿這套東西實際打出的戰績相當驚人。最具代表性的一個是搜尋系統的吞吐量優化：原本同一台機器在同樣品質之下能處理 800 QPS（每秒查詢數），Tangent 跑了一輪之後推高到 4,200 QPS，足足 5.25 倍。第二個是 gisting，也就是把長 prompt 壓縮成短 prompt 的技術，Tangent 不只把延遲壓下來，連品質都微幅提升，這在傳統工程上幾乎是矛盾目標。第三個是商家主題的 HTML/Liquid 模板化，這影響到 Shopify 上千萬家商店的網站效能。第四個有點荒謬：Tangent 在儲存層發現了一張被遺忘的巨大 cache 表，內容是「隨機 ID 對應到另一個隨機 ID」，跑了去重之後立刻釋放出可觀的儲存空間。

帕拉欣還分享了一個更個人的故事。他自己挑了一個過去多年都在親手優化、自認為無懈可擊的問題，丟給 Tangent 跑了好幾週，跑了大約 400 次實驗，只有 1 次成功改善了結果。乍看是很慘的命中率，但那 1 次的改善，是他自己花了多年都沒做出來的。他原本是抱著看好戲的心態啟動實驗，結束後變成 Tangent 的死忠支持者。這個 1/400 的數字，對所有準備押注 auto-research 的團隊都是一個重要校準：不要期待 50% 命中率，要期待「找到一個別人找不到的點」。

最大的驚喜：用得最兇的不是 ML 工程師，是 PM

但這次訪談最讓人印象深刻的洞察，藏在使用者組成的轉變裡。帕拉欣說 Tangent 一開始的設計目標讀者是 ML 與 AI 工程師，因為 auto-research 在概念上最接近 ML 研究的工作流。系統剛上線時，使用者也確實是這群人。但幾個月之後，他們發現使用 Tangent 最頻繁、最重度的人，居然不是 ML 工程師，而是產品經理（PM）。

而且不是泛泛地用，而是已經有 PM 變成全公司 Tangent 任務數第一名。帕拉欣笑說這個發現一開始讓 ML 部門有點挫敗，但仔細分析就會理解為什麼會這樣。PM 的工作天天在面對「這個指標如果改一下會怎樣」的假設性問題，他們有領域知識、有產品脈絡，過去的限制是缺一個能把這些假設轉成實驗的工具。Tangent 剛好補上了那個工具，於是 PM 等於是手裡多了一個會自動跑成千上萬次小實驗的黑盒，而他們本來就比 ML 工程師更知道該餵什麼問題進去。

這個轉變的意義，遠超出一個工具的使用統計。它代表 ML 工作流的瓶頸，正在從「會跑模型」變成「會問對的問題」。當會跑模型的部分被 LLM 自動化，那個瓶頸就從稀缺的 ML 工程師肩上，移到了領域專家手上。原本要等 ML 團隊排隊才有時間做的問題，現在 PM 自己丟給 Tangent 一晚上就有結果。對 ML 工程師而言，這代表他們的時間應該重新分配到更基礎的架構工作上；對 PM 而言，這代表那些原本沒空做的「小優化」現在隨手就能跑。

帕拉欣對這個轉變的判斷很清楚：在 Shopify 的某些問題上，PM 已經不需要 ML 工程師介入了。這聽起來像是工作消失，但實際情況是工作被重新分配，ML 工程師被釋放去做那些 PM 跑不動的硬問題。他特別補一句說，這個轉變代表 Patrice Smart 那一代 AutoML 研究者的願景，正在以一個他們沒預料到的路徑兌現。

為什麼 AutoML 在 LLM 時代才終於跑得起來

要理解為什麼這次 AutoML 跑得起來，得先理解前幾次為什麼跑不起來。帕拉欣回顧了 LLM 之前的 AutoML 歷史：早期工具是基於貝氏優化（Bayesian optimization）、超參數搜尋（hyperparameter optimization）這些演算法，數學很漂亮，但有一個天花板，那就是只能在「結構化、定義清楚」的問題上發揮，碰到任何需要解讀指標、調整方向、判斷實驗成敗的步驟，就卡住了。

Patrice Smart 這位研究者花了大半輩子在試圖把 AutoML 民主化，目標是讓非 ML 專家也能用上自動化機器學習。但每次嘗試都會卡在同樣的關卡：那些「需要人類判斷的中間步驟」沒辦法自動化。例如監控訓練曲線發現異常、看 confusion matrix 解讀模型偏差、根據結果決定要不要改架構，這些動作沒辦法被任何固定演算法捕捉。沒有這些步驟自動化，整個迴圈就需要 ML 工程師守在旁邊，AutoML 就民主化不起來。

LLM 出現之後這道牆突然倒了。LLM 不見得在每個步驟都做得比 ML 專家好，但它做得「夠好」，而且可以無縫接在迴圈的每一個地方。讀指標、寫摘要、根據觀察提下一輪假設、改寫程式碼，這些 LLM 都可以一手包辦。整個 AutoML 的結構沒變，只是把每一步原本需要人類判斷的環節，換成 LLM 來做，整個迴圈就跑起來了。

帕拉欣對這個現象有一個很精煉的形容：同一條 pipeline，每個節點上都多了一層智能，整體效能就跨了一個量級。這也解釋了為什麼 auto-research 不只是「ML 加速器」，而是任何可量化問題的通用優化框架。Shopify 用它優化搜尋、優化儲存、優化模板，這些跟傳統 ML 沒太大關係，但在 auto-research 的架構下都是同一類問題。

我的觀察：自動研究擅長與不擅長的事

Tangent 的 1/400 命中率，給所有準備推自動研究的團隊一個誠實的校準。它不是「丟下去馬上有答案」的東西，而是「願意讓它跑很久、接受高失敗率、只賭那幾個你自己想不出來的突破」的工具。帕拉欣的個人實驗是好幾週、400 次嘗試、只 1 次成功，但那 1 次的價值高到讓他改變立場。對臺灣的工程團隊，這個比例是個重要參考：不要期待 Tangent 變成日常 PR review 工具，那不是它擅長的事；要把它放在「這條路徑我已經人工優化到極限，但又不敢說沒空間」的問題上。

帕拉欣也很坦白地說 Tangent 不擅長什麼。對於需要好幾天、跨越多個分布的「真正開放性思考」，Tangent 還是無能為力。它擅長的是那些「我們其實知道該做、只是沒人有空」的明顯改善：你能列出損失函數、你能描述邊界、你只是缺一雙手把實驗跑完。這個邊界很重要，因為它告訴 PM 與 ML 主管什麼問題該丟、什麼問題該自己來。把開放性問題丟給 Tangent，會浪費好幾週運算費用後一無所獲。

第三個值得思考的是這個工具對組織分工的衝擊。當 PM 自己就能用 Tangent 跑掉很多原本要排 ML 工程師時程的問題，ML 工程師的價值會被重新定義。他們不再是「會做機器學習的執行者」，而是「會搭基礎設施、會解 Tangent 解不了的硬問題、會判斷哪些 PM 實驗該被擋下來」的角色。這對 ML 工程師來說不見得是壞事，但需要主動意識到工作重心要往上移，否則就會被 Tangent 吃掉一大塊原本的工作面。

最後值得記住的，是 Karpathy 那個簡單動作的力量：給東西取一個好名字。帕拉欣特別強調，「auto-research」這個名稱比任何技術細節都還重要，因為它讓內部所有人立刻理解這件事在做什麼、跟自己有什麼關係，於是擴散得起來。對所有正在做 AI 工具的臺灣團隊，這個提醒是免費的：技術做得再好，如果命名不對、員工不知道怎麼把它放進腦中的工作分類，就傳不開來。Tangent 在 Shopify 跑得起來，技術只是一半，命名與心智模型是另一半。