训练自由！不跑代码也能做AutoML？KAIST提出多智能体全流程自动化框架

对于这个图像分类任务，我建议尝试 ResNet-50（预估准确率 92%），Vision Transformer（预估 93%），EfficientNet（预估 91%）。：即使与需要真训练的 AutoML 方法相比，AutoML-Agent 通过伪执行找到的方案性能也很接近（差异小于 5%），但速度快了 100 倍以上。（不同计划的数据专家、模型专家可以同时工作），而且“伪执行”本身很快，因此

frank_hetest

376人浏览 · 2026-04-25 18:35:34

frank_hetest · 2026-04-25 18:35:34 发布

论文题目：AutoML-Agent: A Multi-Agent LLM Framework for Full-Pipeline AutoML
作者：韩国科学技术院（KAIST）的 Patara Trirat 等人
发表会议：ICML 2025（机器学习领域顶级会议）
开源代码：https://github.com/deepauto-ai/automl-agent

一、这篇论文想解决什么问题？

做机器学习（ML）项目，哪怕是一个简单的分类或预测任务，通常需要很多步骤：

找数据：从某个地方把数据集弄到手。
清洗与预处理：处理缺失值、归一化、编码分类变量等。
特征工程：构造有用的特征。
选模型：从几十种候选模型中挑一个合适的。
调超参数：调整学习率、层数等参数提升效果。
评估与验证：用测试集看模型效果。
部署：把模型打包成接口或服务，让别人能调用。

这就是所谓的 “机器学习全流程”。传统方式下，这需要数据科学家或工程师花很多时间手动完成。
自动机器学习（AutoML） 想把这个过程自动化。但现有的 AutoML 工具（比如 Auto-sklearn、H2O）往往只覆盖部分步骤，而且需要反复训练模型，非常耗费算力和时间。

最近有人尝试用大语言模型（LLM，比如 GPT-4） 来自动化部分步骤，例如让 ChatGPT 直接写代码完成数据预处理。但这些方法通常只解决流程中的某一个环节（比如只做特征工程，或只做模型选择），很少有人能把从数据到部署的整个链条串起来。

这篇论文的核心目标是：设计一个基于多个 LLM 智能体（Agent）协作的系统，能够：

覆盖从数据获取到模型部署的完整流程；
适用于不同类型的数据（图像、文本、表格、时间序列、图数据）；
不需要真的训练模型也能找到好方案，从而节省大量计算资源；
具有较强的可靠性，避免 LLM 经常出现的“幻觉”（胡说八道或生成不能用代码）。

二、整体思路：用一支 AI 团队完成工作

AutoML-Agent 不像传统方法那样只有一个 AI 助手，而是设计了一个多智能体系统，每个智能体负责不同角色，各司其职，由一名“项目经理”统一协调。

2.1 五个智能体（一个团队）

角色	英文名	职责
项目经理	Agent Manager (Amgr)	跟用户对接，理解需求，制定多套备选方案，协调其他智能体，最后验证结果
需求解析师	Prompt Agent (Ap)	将用户的自然语言描述转成结构化的 JSON 数据，方便机器理解
数据专家	Data Agent (Ad)	负责所有跟数据相关的事：找数据集、清洗、分析、特征工程等
模型专家	Model Agent (Am)	负责模型搜索、超参数调优、模型性能预估，并给候选模型排序
开发工程师	Operation Agent (Ao)	把最终确定的方案变成可以直接部署的代码（如 Python 脚本）

项目经理是核心，所有任务都会经过它分配。其他智能体只做自己领域内的事情，相互之间沟通也经由项目经理。

为什么要拆成多个智能体？

减少单个 LLM 需要处理的信息量，降低上下文过长的风险。
专业分工可以提高质量（比如数据专家不需要懂模型细节）。
多个计划可以并行执行，提升效率。

2.2 系统的工作流程图

用户提出需求（例如：“帮我用 Butterfly 数据集做一个图像分类模型，部署成 API。”）
项目经理先检查需求是否清晰（需求验证）。如果问题不清楚，它会反问用户补充信息。
需求解析师把需求转成系统内部 JSON 格式。
项目经理根据这个 JSON，调用外部搜索（比如搜 arXiv 论文或网页），从最新方法中获得灵感，生成 P 个不同的完整计划（比如计划 A 用 ResNet，计划 B 用 ViT，计划 C 用 EfficientNet）。
对于每个计划，项目经理把数据部分派给数据专家，模型部分派给模型专家。这两个专家采用 “伪执行”（假装执行）的方式，不实际运行代码，而是让 LLM 根据自己的知识“分析”数据并预测模型性能。
项目经理收集所有计划的“伪执行”结果，对比并选出最好的一个。
开发工程师根据获胜计划写出完整可运行的 Python 代码，并进行最终的部署验证。
系统返回给用户：训练好的模型 + 部署代码（或直接一个 API 端点）。

整个过程中，有三个验证关卡（需求验证、执行验证、实现验证），任何一个环节失败都会触发自动修订，直到成功或向用户求助。

三、关键技术细节

3.1 结构化需求解析 —— 让 LLM “听懂人话”

项目经理不能直接处理自然语言，所以需要一个需求解析师。这个解析师是经过指令调优的大模型：作者构建了一个训练集，里面包含很多“用户自然语言输入 → 结构化 JSON 输出”的样例。

举个例子：
用户说：“我想基于 Vision Transformer 做图像分类，数据集是 CIFAR-10。”
解析后输出：

json

{"user":{"intent":"build","expertise":"medium"},"problem":{"area":"computer vision","downstream_task":"image classification"},"dataset":[{"modality":["image"],"target_variables":["class_label"]}],"model":[{"name":"Vision Transformer","family":"transformers"}]}

这样项目经理就知道：任务类型、数据模态、期望的模型类型等。如果用户没说清楚，项目经理会要求补充。

3.2 检索增强规划（RAP）—— 让 AI 主动查资料

传统方法往往只生成一个执行计划，但可能不是最优的。AutoML-Agent 会在确认需求后，主动去外部知识库搜索：

调用 arXiv API，搜索最近发布的与当前任务相关的论文摘要。
调用 网络搜索引擎（例如 Google），查找最新的模型实现或技巧。

然后项目经理根据这些搜索结果，独立生成多套不同的端到端计划（比如 P=3 或 P=5）。这些计划在模型选择、预处理方法、调参策略上可以完全不同。

为什么要这样做？

避免只依赖 LLM 内部过时的知识（大模型的知识可能截止到训练时间）。
发现新方法，提高找到最优方案的概率。
多个计划并行执行，探索更充分。

3.3 “伪执行”—— 不跑代码，省时省力

这是 AutoML-Agent 最聪明的地方之一。
传统 AutoML 在评估一个方案时，需要实际运行代码：加载数据、训练模型、计算指标。这个过程可能非常慢（尤其是大模型）。

AutoML-Agent 的数据专家和模型专家被设计成：完全靠 LLM 的内部知识来模拟执行结果。

具体怎么做？

数据专家拿到数据集的基本信息（比如 metadata：有几行几列，列名是什么，数值/类别类型，有没有缺失等）。它并不真正读取每个数据点，而是基于这些统计信息和 LLM 对常见数据分布的“常识”，输出一份分析报告：
“我认为这个数据需要做归一化，因为数值范围很大；性别列需要独热编码；缺失值少于5%，可以用中位数填充。处理后特征数量将变成 128 维。”
模型专家拿到数据专家输出的报告后，根据任务类型（分类/回归）和当前流行模型，输出候选模型列表及预估性能：
“对于这个图像分类任务，我建议尝试 ResNet-50（预估准确率 92%），Vision Transformer（预估 93%），EfficientNet（预估 91%）。超参数建议：学习率 0.001，batch size 32，训练 50 个 epoch。”

整个过程没有一行代码真正执行，完全是大语言模型在“假装执行”。但实验表明，这种伪执行的排序和真实训练后的排序有很高的相关性（在常见数据集上）。

优点：几乎零计算成本，速度快到秒级，可以同时探索很多个方案。
风险：如果遇到 LLM 从来没见过的奇怪数据分布，预测可能不准。论文通过后面的验证环节来兜底。

3.4 三重验证机制 —— 避免 AI 骗你

LLM 有时候会产生“看起来对但实际错”的输出（幻觉）。AutoML-Agent 设计了三个检查点：

验证阶段	谁负责	检查什么	失败后怎么办
请求验证 (ReqVer)	项目经理	用户输入是否完整清晰？有没有歧义？	反问用户补充信息
执行验证 (ExecVer)	项目经理	数据专家和模型专家的“伪执行”结果是否符合逻辑？计划能否走通？	记录失败原因，修改计划重试
实现验证 (ImpVer)	项目经理	最后生成的代码能不能真正运行？能否部署？	反馈给开发工程师，重新生成代码

有了这三道防线，即使某个环节 LLM 出了错，系统也能自动修订或请求人工帮助，大大提高了成功率。

3.5 并行执行 —— 多个计划同时推进

由于每个计划的执行是独立的（不同计划的数据专家、模型专家可以同时工作），而且“伪执行”本身很快，因此 AutoML-Agent 可以同时跑多个计划。项目经理只需要最后汇总结果。

实验里，他们通常设置 P=3 或 P=5，总时间基本就是最慢的那个计划的时间（通常几秒到几十秒），而不是 P 倍。

四、实验设计及结果

为了证明 AutoML-Agent 比现有方法好，作者设计了比较全面的实验。

4.1 任务与数据集

选了 7 个不同的下游任务，涵盖 5 种数据模态，总共 14 个数据集。例如：

模态	任务举例	数据集举例
图像	图像分类	Butterfly Image, Shopee-IET
文本	文本分类、文本蕴含	Ecommerce Text, SNLI
表格数据	分类/回归/聚类	Banana Quality, Crab Age
时间序列	预测	几个公开时序数据集
图数据	节点分类	Cora, Citeseer

4.2 对比的方法（基线）

他们对比了 6 种现有的基于 LLM 的自动化框架，包括 AutoML-GPT、HuggingGPT、AgentHPO、Data Interpreter 等。为了公平，每个方法都在相同的数据集上运行。

4.3 评估指标

他们设计了一个综合分数（CS），兼顾代码成功率与模型性能：

CS = 0.5 × 成功率 + 0.5 × 归一化性能
归一化性能 = 1 / (1 + 损失值)
损失值越小，归一化性能越接近 1；损失越大越接近 0。

为什么要用归一化性能？因为不同任务的评价指标不一样（比如分类用准确率，回归用均方误差），归一化后可以统一比较。

4.4 主要结果

在 14 个数据集上，AutoML-Agent 的综合分数平均比第二名高出约 15%~20%（具体数值可查原文表 2，这里简述趋势）：

成功率：在约束感知（用户指定硬件/时间限制）和约束无关两种设定下，均显著高于其他方法。尤其对于复杂任务（如图数据），其他方法失败率较高，而 AutoML-Agent 成功率保持在 80% 以上。
模型性能：即使与需要真训练的 AutoML 方法相比，AutoML-Agent 通过伪执行找到的方案性能也很接近（差异小于 5%），但速度快了 100 倍以上。
多模态适应性：在所有 5 种模态上，AutoML-Agent 都表现稳定，证明它是任务无关的通用框架。

4.5 消融实验（验证每个组件是否必要）

他们做了一些“去掉某个组件”的实验：

去掉检索增强规划（RAP）：综合分数下降约 10%，说明上网查资料确实能带来更好的方案。
去掉伪执行，改成真训练：效果稍微好一点点（提升约 3%），但时间开销是原来的 50 倍以上。说明伪执行是一种很好的效率代价平衡。
去掉三重验证：代码生成的成功率大幅下降到 40% 左右，可见验证机制对防止 LLM 幻觉非常重要。

五、优点总结（论文声称的主要贡献）

第一个真正覆盖全流程（数据→部署）的多智能体 AutoML 系统。
第一次把“检索增强”引入 AutoML 规划阶段，让 AI 可以学习最新知识。
“伪执行”训练自由搜索，大幅降低计算成本，使得普通电脑也能运行全流程 AutoML。
三重验证 + 自动修订，保证高成功率和代码可用性。
任务无关，能处理图像、文本、表格、时序、图数据。
开源，方便复现和二次开发。

六、存在的不足与可以改进的地方

伪执行的局限性
如果任务的数据分布非常新颖（例如一个从未出现在 LLM 训练数据中的特殊传感器数据），LLM 很难凭空预测最佳预处理和模型性能。虽然最终有实现验证兜底，但可能会多几次失败重试。
检索开销
上网搜论文和网页需要几秒到十几秒，对于简单任务来说，这个开销可能比直接跑一个小模型还大。或许可以设计一个“快速模式”，跳过检索。
部署部分还不够深入
论文里的部署验证主要是检查代码能否运行并返回推理结果。真实生产环境的部署（如 Docker 镜像、负载均衡、模型版本管理）尚未覆盖。
大规模任务的处理能力
当数据集非常大（比如几十 GB）或模型非常大（比如 LLaMA-70B）时，项目经理的上下文窗口和智能体间的通信可能成为瓶颈。目前未测试极限情况。
对用户专业度的依赖
虽然系统会反问，但如果用户自己也不清楚任务细节（比如不知道要预测哪一列），仍然可能卡住。论文没有深入讨论完全零输入的情况。

七、个人感受与应用启发

“伪执行”这个思路很有启发：我们不一定每一步都要真实计算，可以让大模型充当“代理模型”快速筛选候选方案，最后只验证少数几个最优方案。这种做法可以推广到很多需要搜索的场景（如神经网络架构搜索、自动 prompt 优化）。
多智能体协作 + 外部知识检索：未来任何复杂的自动化任务（不仅仅是机器学习）或许都可以用类似架构：分解角色、并行探索、检索知识、验证闭环。
可靠性设计的价值：很多人用 LLM 一次生成代码就完事了，但 AutoML-Agent 通过三阶段验证把成功率提得很高。这对于实际落地非常关键。
如果想复现或使用：可以直接去 GitHub 拉代码，按 README 跑一下示例。他们提供了若干现成的数据集和任务配置，可以很快体验“从一句话到部署代码”的感觉。