AIDE ML：把「寫 ML 程式」變成樹狀搜尋的參考實作
AIDE: an LLM agent for machine learning engineering - the research Weco grew out of. Referenced in OpenAI MLE-bench.
秒懂
- 它是什麼？
- WecoAI 的 aideml 把 AIDE 演算法做成可安裝的 Python 套件：LLM 產生候選腳本、執行、用指標剪枝，最後留下 best_solution.py。它適合想改搜尋策略的研究者，不是拿來取代 AutoML 的平台。
- 適合誰用？
- 如果你的工作是改進代理搜尋策略、評估器或 LLM 後端，aideml 的 MIT 授權與精簡結構讓它值得直接讀原始碼；若你只是想要一個能上線、可排程、能追蹤實驗的 ML 平台，這個 repo 明確把自己定位成參考實作，README 也把產品層指向 weco.ai，你應該先確認自身需求再決定。動手前請先驗證三件事：agent.code.model 預設值是否仍符合你的預算、agent.steps 與 agent.search.num_drafts 的組合會產生多少 LLM 呼叫、以及 logs/<id>/best_solution.py 是否真的能在你的環境重跑而不依賴執行期殘留的檔案。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 12 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是「誰來寫第一版 pipeline」這個問題
拿到一份資料集，真正的成本通常不在模型，而在把資料讀進來、處理缺失值、切分訓練與驗證、定義指標、跑出一版可比較的基準。這個流程重複、瑣碎，而且每一步都要人工判斷。aideml 的目標就是把這段工作交給 LLM：你給一個目錄、一句目標描述、一個評估指標，代理自己產生 Python 腳本、執行、看指標、再改。README 把適用對象寫得很直白，一類是代理架構研究者，可以替換搜尋啟發式、評估器或 LLM 後端；另一類是 ML 實作者，想快速生出一個高效能 pipeline。值得注意的是它並不是在既有的 sklearn Pipeline 物件上做超參數搜尋，搜尋的單位是完整的 Python 腳本，這讓它能改動的特徵空間大得多，也讓結果的可重現性更依賴執行環境。
樹狀搜尋的實際資料流：節點是腳本，剪枝靠指標
README 與論文摘要描述的機制是這樣：每個 Python 腳本成為解答樹上的一個節點，LLM 產生的修補（patch）長出子節點，指標回饋決定哪些分支被剪掉、哪些被繼續探索。這是一個在「程式碼空間」而非「超參數空間」上的搜尋，因此節點之間的差異可能是換模型、換特徵工程、換資料前處理，而不只是某個參數的數值。repo 附帶的 HTML 視覺化工具能把整棵樹與每個節點對應的程式碼攤開來看，這對研究用途很關鍵，因為你要判斷的不是最終分數，而是代理走過哪些彎路。README 引用 OpenAI 的 MLE-bench（75 個 Kaggle 競賽）指出，AIDE 的樹狀搜尋拿到的獎牌數是最佳線性代理 OpenHands 的四倍。這個數字出自該 benchmark 的報告，不是本站在本機跑出來的結果，請當成外部引用看待。
安裝與最小可跑範例
安裝只有一行：pip install -U aideml。接著設定 LLM 金鑰，README 的範例用 export OPENAI_API_KEY=<your-key>。然後就是核心指令，aide data_dir="example_tasks/house_prices" goal="Predict the sales price for each house" eval="RMSE between log-prices"。跑完之後，輸出落在 logs/<id>/best_solution.py 與 logs/<id>/tree_plot.html，前者是最佳程式碼，後者用瀏覽器打開就能檢視解答樹。若要在 Python 裡呼叫，README 給的介面是 aide.Experiment(data_dir=..., goal=..., eval=...) 取得物件後呼叫 exp.run(steps=2)，回傳值帶有 valid_metric 與 code 兩個屬性。這種「資料目錄加自然語言目標」的介面是它相對輕量的地方，不需要先寫 YAML 網格或包一層 wrapper。
要調的旋鈕其實只有三個，但每個都直接燒錢
進階用法透過覆寫設定鍵完成，例如 aide agent.code.model="claude-4-sonnet" agent.steps=50 data_dir=… goal=… eval=…。README 列出的常用旗標有三個：agent.code.model 決定寫程式的 LLM，預設 gpt-4-turbo；agent.steps 是改進迭代次數，預設 20；agent.search.num_drafts 是每步產生的草稿數，預設 5。把這三個乘起來就是呼叫量級：20 步乘以每步 5 份草稿，代表至少上百次 LLM 請求，而且每次請求都附帶當前的程式碼與指標上下文。README 提到模型中立，支援 OpenAI、Anthropic、Gemini，以及任何講 OpenAI API 的本地模型，這對想把成本壓在自架推論上的團隊是實際的選項。反過來說，這個設計也意味著執行時間與費用對 agent.steps 幾乎是線性敏感，調高之前最好先確認預設值在你的資料集上是否已經收斂。
什麼情況下它會讓你失望
第一個限制寫在專案自己的定位裡：這是「參考實作」，README 的表格把 AIDE 演算法、AIDE ML repo 與 Weco 產品分成三層，並註明產品層才提供實驗追蹤與更強的使用者控制。也就是說這個 repo 沒有內建實驗管理、沒有排程、沒有多使用者隔離，產出是一棵樹與一個 best_solution.py。第二，評估指標是你給的一句話，代理會自己決定怎麼算，如果指標描述有歧義，例如只寫 RMSE 卻沒說要對 log 價格取誤差，搜尋會朝一個與你預期不同的方向最佳化，而這個偏差在最終程式碼裡不一定看得出來。第三，它最佳化的對象是驗證指標，資料洩漏、時序資料的未來資訊滲透這類問題不會被自動擋下，時間序列任務尤其需要你事後檢查切分邏輯。若你的場景需要嚴格的實驗治理或法規可追溯性，這個 repo 不是那個工具。
與 AutoML 的差別：搜尋的是程式碼，不是參數
拿 auto-sklearn 或 FLAML 這類 AutoML 框架相比，差異在搜尋空間的定義。AutoML 通常在固定的 pipeline 模板上挑模型與超參數，搜尋空間有界、可枚舉、結果容易重現；aideml 讓 LLM 直接寫腳本，空間幾乎不受限，能做的事情更多，但每一步的正確性取決於生成的程式碼能否執行，失敗的節點就是浪費掉的呼叫。反過來說，AutoML 沒辦法替你發明新的特徵工程寫法，aideml 可以。如果你的問題是表格資料加上標準指標，AutoML 的確定性通常更划算；如果你的問題需要探索非典型的建模路徑，或你的研究主題本身就是代理架構，aideml 的程式碼空間搜尋才是對的抽象層次。兩者不是替代關係，aideml 產出的 best_solution.py 完全可以再丟進 AutoML 做細部調參。
授權、維護與升級成本
授權是 MIT，這代表你可以修改、商用、再散布，只要保留著作權聲明；本文不構成法律意見，實際條款請自行閱讀 repo 內的 LICENSE。維護頻率可以從發布紀錄看出端倪：v0.1.4 在 2024 年 4 月，v0.2.0 在 2025 年 1 月，v0.2.2 在 2025 年 11 月，節奏不快，屬於研究型專案的典型樣貌。這對採用決策的含義是：不要期待它跟著上游 LLM API 的變動即時更新，模型名稱如 claude-4-sonnet 這類字串是設定值，一旦供應商改名或下架，你得自己改設定。升級成本主要來自兩處，一是 agent.code.model 的可用性，二是生成的程式碼所依賴的套件版本，後者不在這個 repo 的控制範圍內，best_solution.py 能不能在你鎖定的環境重跑，得自己驗證。
編輯結論
如果你的工作是改進代理搜尋策略、評估器或 LLM 後端，aideml 的 MIT 授權與精簡結構讓它值得直接讀原始碼；若你只是想要一個能上線、可排程、能追蹤實驗的 ML 平台，這個 repo 明確把自己定位成參考實作，README 也把產品層指向 weco.ai，你應該先確認自身需求再決定。動手前請先驗證三件事：agent.code.model 預設值是否仍符合你的預算、agent.steps 與 agent.search.num_drafts 的組合會產生多少 LLM 呼叫、以及 logs/<id>/best_solution.py 是否真的能在你的環境重跑而不依賴執行期殘留的檔案。
社群筆記