實驗：Karpathy Autoresearch 的人類版本 (Experiments The Human Version of Karpathy’s Autoresearch)

原始來源與檔名：2026-05-19T092643+0800-Experiments The Human Version of Karpathy’s Autoresearch.md

NAPKIN | 餐巾纸

餐巾紙公式

系統進化 = 資料集 (Dataset) + 變數控制 (Variables) + 基準對比 (Baseline vs Output) + 評估器 (Evaluator)

一句話

在將 AI 開發交給全自動代理 (Agentic Autoresearch) 之前，人類必須先學會如何手動控制變數、比較結果並定義什麼才是「更好」。

餐巾紙草圖

[Dataset] --+--> [Baseline System] ----> [Output A] --+
            |                                         |--> [Compare / Evaluator] --> [Actionable Insight]
            +--> [Changed Condition] --> [Output B] --+

ROUND 1: SKELETON | 骨架掃描

• 核心問題: AI 團隊如何系統化地優化 AI 應用，避免盲目修改導致「加速失敗」？
• 核心答案: 實踐 AI 工程迴圈 (AI Engineering Loop)，透過控制單一變數（如模型、提示詞、上下文），在真實數據集上進行 A/B 實驗與結果對比。
• 論證結構: 步驟型與歸納型

章節骨架

1. 什麼是實驗: 實驗是分離因果關係的唯一方法，包含四要素（數據、基準、變數、對比）。
2. 常見變數: 模型 (Model)、提示詞 (Prompt)、上下文 (Context)、工具存取 (Tool access)、代理架構 (Agent architecture)。
3. 實驗場景: 新模型測試、提示詞改進、新架構對比。
4. 實踐路徑: 從手動開始 (20-30 筆真實數據) -> 肉眼對比 -> 引入評估器 -> 整合 CI/CD。

ROUND 2: DISSECTION | 血肉解剖

• 隱形假設: 系統的優化方向必須清晰可見，且存在具代表性的生產級數據集可以作為測試基準。
• 邊界條件: 若評估指標錯誤或數據集不能代表真實場景，那麼高速的自動化實驗只會帶來「更快的失敗 (faster failure)」。

ROUND 3: SOUL | 靈魂提取

• 知識連結: 與傳統軟體工程中的 A/B 測試、CI/CD 迴歸測試以及機器學習模型評估高度相關。
• 深層洞見: Karpathy 的 Autoresearch 之所以成功，是因為他擁有 20 年的經驗直覺來定義「什麼是好」。自動化只是加速，無法取代對問題本質的理解。
• 行動呼籲: 不要一開始就建立龐大的基礎設施或盲信自動化評估器。先手動閱讀 20-30 個真實的 Trace 對比，建立對系統行為的直覺，再進行擴展與自動化。

實驗：Karpathy Autoresearch 的人類版本 (Architectural Deep Dive)

前言/背景

隨著 Karpathy 的 Autoresearch (自動化代理在一夜之間進行 700 次實驗並優化模型訓練) 引起熱議，許多團隊渴望將 AI 優化流程全自動化。然而，本文指出：在交由 Agent 自動化之前，人類工程師必須先掌握「手動」實驗的科學方法，透過控制變數並在真實數據上對比結果，才能避免系統朝向錯誤的方向盲目狂奔。

章節詳細總結

實驗在 AI 工程迴圈中的定位 (How experiments fit into the loop)

要系統化地理解並改進 AI 系統，必須具備分離因果關係的能力。這正是實驗的價值所在。 每次實驗包含四個核心元素：

1. 數據集 (Dataset)
2. 基準配置 (Baseline configuration)
3. 變更變數 (Changed variable)
4. 輸出比對方式 (Way to compare outputs) 架構師原則：每次盡量只改變一個變數。唯一的例外是變數高度耦合時，例如換了新模型通常需要配上新的提示詞才能發揮其真實效能。

AI 系統的五大實驗變數 (Variables)

1. 模型 (Model)：在推理能力、速度與成本之間進行權衡。
2. 提示詞 (Prompt)：最常用的槓桿。在改 Prompt 前，必須區分這是「規格問題 (specification problem，指令模糊)」還是「泛化問題 (generalization problem，模型無法一致地執行清晰指令)」。前者直接修改，後者才值得設計實驗測量。
3. 上下文 (Context)：輸入給模型的資訊，如檢索文件 (RAG)、對話歷史或使用者中繼資料。
4. 工具存取 (Tool access)：新增/移除工具，或修改工具的描述語以提高其被模型發現的機率。
5. 代理架構 (Agent architecture)：單代理對抗多代理、選擇哪種 Agent harness、框架，以及如何拆解任務。這會極大影響系統的延遲與成本。

實驗的實踐路徑與 CI/CD 整合 (Where to start & CI/CD)

• 拒絕過早自動化：不要一開始就建立龐大的基礎設施或直接導入自動評估器 (Evaluator)。
• 「20-30」手動驗證法則：從生產環境的 Trace 中提取 20-30 個真實案例（如退款請求）。將這 20 個案例分別用舊配置與新配置跑一次，並將結果並排放置，用肉眼閱讀。
• 建立直覺再自動化：透過手動比對，工程師能理解什麼是「更好」，這時再將這個直覺編碼為 Evaluator。
• CI/CD 整合：一旦 Evaluator 穩定，即可將實驗整合進 CI/CD 流水線，在每次部署前確保新配置在基準測試中的得分不會退化。

總結與結論

• 品質、成本與速度的拉扯：這三個指標在 AI 應用中極少能同時提升。唯有透過實驗，才能在具體的數據上看到這三者如何互相拉扯，而非停留在抽象理論。
• 自動化無法取代問題定義：自動化的實驗迴圈 (如 Autoresearch) 就像推進器，如果方向錯誤，只會讓你「失敗得更快」。人類理解「什麼是成功」的這一步是無法被外包的。
• 數據品質決定實驗上限：測試用的數據集必須覆蓋生產環境中 Agent 實際處理的邊緣案例，而不僅僅是那些「容易處理」的標準案例。