做机器学习项目这些年，我见过太多团队把时间耗在“调参”上。选模型、调学习率、改网络层数、试不同预处理方式……每一步单看不难，叠在一起就是无底洞。而这个章节要聊的AutoML（自动化机器学习）和神经架构搜索（NAS），核心目标就一句话：把“人工选择”变成“自动搜索”，把机器学习工程师从重复劳动里解放出来，让他们有精力去处理真正需要判断力的事情。
这个系列走到第17章，前面的内容已经覆盖了传统机器学习、深度学习、正则化、训练技巧等基础。现在我们把视角从“如何手动训练好一个模型”切换到“如何让机器自己找到好模型”。如果你已经对机器学习基本流程有把握，正在被调参折磨，或者想在项目中引入更高效的模型选型方法，那这一章就是你需要的。
1. 调参这件事，为什么越来越像一个“优化问题”
先别急着看工具。想理解AutoML，得先理解它要解决的问题到底是什么。
1.1 组合爆炸：模型选择不是一个点，而是一个空间
传统机器学习里，我们面对的不是“一个模型”，而是一整条流水线。拿表格数据举例：数据要清洗、缺失值要填充、类别变量要编码、连续特征可能要标准化或归一化、要不要做特征选择、选什么模型（逻辑回归、随机森林、梯度提升树还是SVM）、模型的超参数怎么设……每一步都有多种选择。
假如每个环节平均有5种可选方案，流水线上有8个环节，那组合数就是5的8次方，约39万种组合。这还没算每个模型的连续超参数，比如学习率可以是0.01、0.001、0.0001……连续值一进来，搜索空间直接变成无限大。
这还不是最让人头疼的。到了深度学习时代，问题更严重：网络有几层、每层多少神经元、卷积核大小、激活函数选哪个、dropout比例、优化器用什么、批大小多少、学习率调度策略怎么选——这些超参数之间是强烈耦合的。手动调整时，你调好了学习率，可能又要重新调层数；调好了层数，可能发现dropout又不对了。人脑根本没法在高维空间里做有效搜索。
1.2 从网格搜索到AutoML：历史在帮我们找出路
早期的解决方案很朴素：网格搜索。你把每个参数列几个候选值，然后穷举所有组合。听着很稳妥，但维度一高根本跑不动，10个参数每个取5个值，就是976万次训练。后来有人用随机搜索，虽然听起来不高级，但在高维空间里随机采样往往比网格更有效，因为网格搜索的“均匀覆盖”在高维下很容易漏掉真正的好区域，而随机采样可以碰运气碰上更多的有效组合。
但这些方法都有一个共同问题：它们只是在盲目尝试，没有从历史尝试中学习。真正让AutoML站上舞台的，是两个改变思路的技术：贝叶斯优化（从参数历史里学习概率模型，预测哪些参数更可能出好结果）和神经架构搜索（把神经网络的结构也当作搜索对象）。从2018年前后开始，AutoML相关工具在各类数据竞赛里的成绩越来越好，逐渐从实验室走进工程实践。
1.3 AutoML不是“AI取代算法工程师”
这一点必须说清楚，因为误解太多了。AutoML的本质不是造一个万能的AI来取代你，而是把“模型选择、超参数调优、特征工程选择”这类可枚举、可量化、可被优化器处理的环节，交给自动化程序搜索。它替代的是“手工试参数”的机械劳动，而不是“理解业务、设计评估指标、做特征洞察、权衡成本与效果”这种需要领域知识和判断力的工作。
理解了这层关系，再看AutoML的工具和算法，思路就清晰了：它们不是黑盒魔法，而是一套成熟的优化方法论被应用到了模型开发流程中。
2. AutoML管道拆解：数据、特征、模型、超参数各自在“自动”什么
一个完整的AutoML系统，远比“自动调参”复杂。它覆盖了从原始数据到最终模型的整条流水线。
2.1 五个自动化环节
我习惯把AutoML拆成五个层次来看：
- 数据与预处理自动化：自动检测缺失值、异常值、数据分布偏移，自动选择填充策略（均值/中位数/模型预测），自动判断类别变量和数值变量并选择编码方式。
- 特征工程自动化：自动生成新特征（比如多项式组合、时间特征拆分）、自动做特征选择（基于统计检验或模型重要性）、自动做降维（PCA、SVD等）。
- 模型选择自动化：在候选模型集合（逻辑回归、SVM、随机森林、XGBoost、LightGBM等）中自动挑选最适合当前数据的模型。老牌的auto-sklearn就是干这个的。
- 超参数优化自动化：对选定模型的关键超参数做优化，比如树的深度、叶子节点数、学习率、正则化强度。
- 神经架构搜索（NAS）：当候选池里包含深度学习模型时，自动设计网络结构——层数、通道数、连接方式、激活函数、注意力机制怎么排布。
这套流程做出来后，用户给一个DataFrame，系统自己跑完上面所有环节，交出一个能部署的模型。但这背后的搜索问题，一个比一个难。
2.2 核心抽象：配置空间
AutoML一切动作的基础，是一个叫做“配置空间”的概念。你可以把它理解成一张“决策清单”：每个环节有哪些可选操作，每个操作有哪些可调参数，参数是连续值、离散值还是条件依赖的。
举个例子，一个配置空间可能是这样的：
- 数据填充：枚举值{均值, 中位数, 常数}，如果是常数又要填c=0还是c=-1。
- 特征选择方法：枚举值{方差阈值, 卡方检验, 递归特征消除}。
- 模型类型：枚举值{随机森林, XGBoost, 线性回归}。
- 模型的n_estimators：整数范围50到500。
- 模型的学习率：连续值范围0.001到0.1。
注意这里的“条件依赖”：只有模型选XGBoost时，学习率才存在；选随机森林时，n_estimators存在但学习率不存在。AutoML优化器必须能处理这种结构化的、带条件约束的搜索空间。很多新手自己写调参脚本时最容易踩的坑就在这——拿一个扁平的参数网格去套，结果模型换了，参数对不上了。
2.3 为什么不能全盘自动化？
也许有人会问：既然如此，把所有的环节都自动了，是不是就万事大吉了？答案是不够。
原因很实际：自动化搜索的每一步，都需要计算资源来评估。一个完整的AutoML跑下来，可能需要几百次甚至上千次模型训练。如果数据量大有几十万条，每次训练要几分钟甚至几十分钟，那一次全自动搜索可能要跑几天甚至几周。所以工业上通常的做法是：把“确定性高、试错成本低”的环节（比如数据填充规则）先定死，把“影响大、难手动调”的环节（比如模型选择、关键超参数）留给AutoML，而且设置明确的搜索预算（时间上限、迭代次数上限）。
3. 超参数优化：贝叶斯与多保真度是真正的主力
超参数优化是AutoML里最成熟的部分，也是你在实际项目中最容易用到的一部分。这一节我们深入讲。
3.1 为什么不能只用网格和随机搜索
网格搜索的问题我们前面说过，维度灾难。随机搜索比网格好，但它仍然只是“均匀撒点”，不会从已经跑过的点里总结规律。
举个例子：你搜索学习率，发现0.001和0.003效果都不错，0.01很差。一个聪明的算法应该意识到：“0.002附近可能也不错，值得再试一试；0.05附近大概率没戏，不用再浪费资源了。”随机搜索不会这么做，它下一轮还是会均匀地抽0.05。这一步浪费，不算大；但几百个参数组合的浪费叠加起来，时间成本就失控了。
3.2 贝叶斯优化的核心思想
贝叶斯优化解决的正是“如何用更少的尝试找到更好的结果”这个问题。它的思路分两步：
- 代理模型：用已有的历史评估结果（参数组合和对应的验证集分数）训练一个概率模型，用来预测任意一组新参数的“期望表现”和“不确定性”。
- 采集函数：根据代理模型的预测，决定下一组参数试什么。经典的采集函数是EI（Expected Improvement），它认为好的是“有潜力大幅超过当前最好成绩”的点，而不是“预测分数最高”的点。
为什么要用EI而不是直接取预测分数最高的点？关键在“不确定性”，这也是贝叶斯优化最精彩的地方。假设有两个区域：A区域预测准确率0.88，但模型很确定，波动很小；B区域预测准确率0.86，但样本很少，不确定性极大，可能实际能到0.92。纯贪心会选A，但反复选A只会原地踏步；EI算法会适度探索B，因为它的“潜力期望”更高。这本质上是一种“开发与探索的平衡”，和强化学习里探索-利用困境是同一个道理。
3.3 TPE和高斯过程：两大主流代理模型
超参数优化领域用得最多的两种代理模型是：
- 高斯过程（GP）：数学上漂亮，能直接给出后验分布，但计算复杂度随数据点数量立方级增长，迭代两百次以上会明显变慢，更适合参数维度不高的场景（比如少于20个参数）。
- TPE（Tree-structured Parzen Estimator）：不直接建模“参数到分数的函数”，而是分别建模“表现好的参数分布”和“表现一般的参数分布”，用两者的比值来指导采样。它对条件依赖空间支持得很好，计算开销小，目前很多主流调参库（比如Optuna）的默认策略就是基于TPE的。
3.4 多保真度优化：Hyperband与ASHA
这条值得单独拎出来讲。超参数优化的一个致命痛点是：每次评估都需要完整训练一个模型，太贵了。
多保真度优化的思路是：用更便宜的方式预测哪些参数值得投入完整训练。比如先用少量训练轮数跑一轮，效果好的参数再继续加大投入。Hyperband就是这类算法的代表。它通过多轮的“探索-淘汰”策略，在资源预算内以较高概率找到好的配置。
它的进阶版ASHA（Asynchronous Successive Halving Algorithm）支持异步并行，你可以同时开多台机器跑不同配置，随时淘汰表现差的，腾出资源给新的候选。在分布式环境里，这套机制能把调参效率提升好几个量级。
3.5 实操示例：用Optuna跑一个XGBoost调参
说这么多，给个能直接跑起来的例子。Optuna是目前我用下来最顺手的调参库，上手快，而且支持动态配置空间和剪枝。
import optuna import xgboost as xgb from sklearn.datasets import load_breast_cancer from sklearn.model_selection import cross_val_score from sklearn.model_selection import train_test_split data = load_breast_cancer() X_train, X_val, y_train, y_val = train_test_split( data.data, data.target, test_size=0.2, random_state=42 ) def objective(trial): params = { "n_estimators": trial.suggest_int("n_estimators", 50, 500), "max_depth": trial.suggest_int("max_depth", 3, 10), "learning_rate": trial.suggest_float("learning_rate", 0.005, 0.2, log=True), "subsample": trial.suggest_float("subsample", 0.5, 1.0), "colsample_bytree": trial.suggest_float("colsample_bytree", 0.5, 1.0), "reg_alpha": trial.suggest_float("reg_alpha", 1e-8, 10.0, log=True), "reg_lambda": trial.suggest_float("reg_lambda", 1e-8, 10.0, log=True), } model = xgb.XGBClassifier(**params, use_label_encoder=False, eval_metric="logloss") score = cross_val_score(model, X_train, y_train, cv=3, scoring="roc_auc").mean() return score study = optuna.create_study(direction="maximize", sampler=optuna.samplers.TPESampler()) study.optimize(objective, n_trials=100) best = study.best_params print(best)跑完之后，再拿验证集测一次最优参数组合，防止搜索过程中对验证集过拟合。这是用AutoML最容易忽略的一个问题，后面我们专门讲。
4. NAS的三种范式与计算代价的博弈
如果说超参数优化解决的是“给定网络结构调参数”，那神经架构搜索（NAS）解决的就是“连网络结构都帮你设计”。它能跑出很多人类想不到的连接方式，但代价也是惊人的。我们先看它的三要素。
4.1 NAS的三个核心维度
任何NAS算法都绕不开这三个问题：
- 搜索空间：允许搜索的网络长什么样？可能包含哪些层、哪些连接方式、哪些操作（卷积、池化、跳跃连接、注意力模块）？
- 搜索策略：怎么在空间里探索？是随机采样、强化学习、进化算法，还是梯度下降？
- 评估策略：搜出来的候选网络怎么打分？完整训练一次？还是只用少量轮数估个大概？
这三个维度决定了NAS的“贵”与“便宜”。
4.2 第一条路线：以强化学习为代表
早期最有名的NAS是使用强化学习：把一个RNN控制器当成“网络生成器”，每输出一组动作就生成一个网络结构，然后训练这个网络，把验证集上的准确率作为奖励回传给控制器，控制器再慢慢学会生成更好的结构。
思路很直接，效果也很惊艳，很多搜索出的结构直接刷新了当时的图像分类榜单。但问题显而易见：每生成一个候选网络都要从零训练，动辄上千GPU天。普通团队根本没有这个资源，这也是它后来被淘汰出主流实践的根本原因。
4.3 第二条路线：进化算法
进化算法的思路是：维护一个种群，每代做变异和交叉，然后评估适应度，优胜劣汰。这个路线在搜索空间的自由度上比强化学习更灵活，可以做层级搜索、模块复用。
它的好处是对长链条的依赖关系不敏感，适合非常复杂的大空间；坏处是评估代价依然高昂，而且进化过程本身需要精细调参（种群规模、变异概率、代际数量），能把人逼疯。AmoebaNet这类后期的进化NAS把效率提升了不少，但依然离不开大量计算资源。
4.4 第三条路线：One-Shot与权重共享，让NAS真正落地
前面两条路线本质上是“离散搜索”，昂贵无比。后来研究者发现：不如把整个搜索空间变成一个大网络，共享权重。这就是One-Shot NAS的核心思想。它先训练一个“超网络”（包含所有候选操作），不同结构只是从超网络里采一条不同的子路径，推理时用已经训练好的权重来评估，基本不用重新训练。
这条路线的代表作，就是DARTS。它把离散的“选择哪一层操作”松弛成了连续权重，直接用梯度下降优化这些权重。搜索过程快了很多，计算量从几千GPU天降到了几个GPU天。
但DARTS不是没有代价的。我实际用下来发现它有稳定性问题：搜索完的连续权重转离散结构时，性能会明显下降；而且不同随机种子跑出来的结果方差很大。后面大家用不同的正则化手段去稳定搜索过程，但这也告诉我们一件事——NAS的搜索策略和评估策略是会互相影响的，搜索到的“最优”很可能只是搜索空间里的最优，换个空间结果可能完全不同。
4.5 普通人怎么用NAS
老实说，对于绝大多数项目而言，自己从零写NAS算法是不划算的。真正可落地的用法有两个：
- 用现成的NAS工具库（比如后面要介绍的AutoKeras、NNI）在合理的预算内搜索一个小型网络。
- 直接在预训练模型的基础上做微调，而不是搜索完整网络结构。现实中很多“NAS”最后落地到业务，反而是第二种，因为代价低、收益直接。
5. 工具选型：AutoKeras、AutoGluon、Optuna，别只挑贵的
市面上AutoML工具不少，但特点差异很大。我按自己的使用经验把它们分成几类，你可以直接对应场景选。
5.1 工具对比
| 工具 | 定位 | 适合场景 | 上手成本 | 限制 |
|---|---|---|---|---|
| Optuna | 超参数优化框架 | 已有模型、只想高效调参 | 低 | 不做特征工程和模型选择 |
| Auto-sklearn | 传统表格AutoML | 中小规模表格数据 | 中 | 基于sklearn，深度学习支持弱 |
| AutoKeras | Keras之上的NAS工具 | 需要神经网络结构搜索 | 中 | 深度模型训练成本仍高 |
| AutoGluon | 全流程AutoML | 表格数据竞赛、快速建模 | 低 | 对内存占用较大 |
| TPOT | 基于遗传编程的管道搜索 | 探索特征工程组合 | 中 | 搜索速度慢，需要代码耐心 |
| NNI | 微软开源的全家桶 | 团队需要统一管理调参+NAS+分布式 | 高 | 配置体系庞大，学习曲线陡 |
5.2 AutoKeras的最小实战示例
如果你有一个图像分类需求，又不想手写网络结构，AutoKeras是最快的路：
import autokeras as ak clf = ak.ImageClassifier( max_trials=10, # 最多尝试10个不同的网络结构 overwrite=True, ) clf.fit(x_train, y_train, epochs=30) model = clf.export_model() model.save("auto_model.keras")就这么几行，它会在内部跑结构搜索。但你要清楚：max_trials=10意味着至少训练10个网络，如果数据集大，几分钟到几小时都正常。务务必先在小数据子集上验证可行，再放大规模。
5.3 AutoGluon和多保真度的组合
处理表格数据的场景，AutoGluon是我现在最推荐的。它的理念和传统AutoML不太一样：不会纠结于选哪个模型，而是把多个强模型加在一起做堆叠集成。实测下来，在结构化数据的基准上，它经常能直接追上甚至超过人类专家调出来的单模型。
from autogluon.tabular import TabularPredictor predictor = TabularPredictor(label="target", eval_metric="roc_auc").fit( train_data, time_limit=600, # 给10分钟预算 presets="best_quality", )time_limit这个参数特别适合实际项目——你可以告诉它资源边界，它自己决定跑多少候补和多少层集成。这个“预算意识”是我认为AutoGluon做得最贴心的地方。
5.4 选型建议：不按“价格”按“问题”
我的原则很简单：
- 如果是深度学习模型训练，主要用Optuna做超参数优化，有必要时再用AutoKeras或轻量NAS。
- 如果是表格数据、快速出基线，直接AutoGluon，几个模型对比那一步都省了。
- 如果有经验丰富的工程师，且团队有分布式集群，才考虑NNI这类全家桶方案，因为它灵活，但学习成本也确实高。
6. 自动化不等于免维护：三个被反复踩的坑
工具跑起来了，最危险的时刻才刚刚开始。以下是三年里我反复遇到的三大坑，每一个都是血泪教训。
6.1 数据泄漏：AutoML流水线也会放大它
自动化工具会替你做预处理、特征选择、模型训练，但它不知道你的业务约束。最常见的错误是把一些应该是“预测目标”或“未来信息”的列当作普通特征喂进去。
举个例子：预测客户流失场景，数据里如果有一列“最近是否提交过投诉工单”，看起来合理，但如果这个工单是在流失之后才生成的，模型哪怕故意“作弊”也能拿到满分——因为它看到了未来。AutoML不会提醒你这件事，它只会欣喜地发现这个特征特别重要。这种泄漏在人工建模时还有可能靠专业敏感度发现，但自动化时会因为“跑得又快又好”而让你放松警惕。
6.2 在搜索过程中反复使用验证集：变相过拟合
很多人用AutoML时，会盯着中间输出，看到某几个参数效果好就手动“微调”再跑；或者反复修改数据重新搜索。这就产生了一个隐蔽问题——你实际上是在用验证集反馈来指导自己的下一步操作。
这和搜索算法本身在验证集上优化没有本质区别。数据经不起反复看，验证集的结果看多了，你的模型对验证集的过拟合是必然的，最后在线上的表现一定会低于你在本地看到的数字。
我的做法是：搜完结束后，把最终选定的模型在预留的、从未碰过的测试集上跑一次，以那个分数作为真实基准；并且绝不回头调整参数来追高测试集分数。
6.3 “AutoML跑出来的模型可以直接上线”是危险的
AutoML生成的是一个模型，不是一个系统的完整解决方案，它不在乎延迟、内存占用、可解释性、上下游依赖兼容性。
我见过一个实际例子：AutoML搜索出一个精度提升几个点的集成模型，但单次推理时间多了50倍，上线根本扛不住；还有的模型依赖了工具内部才有的处理函数，部署时压根没法复现那份预处理逻辑。这些问题都需要人在上线前介入处理。自动化搜索得到的应该是个更好的起点，而不是终点。
7. 一点个人经验
AutoML这门手艺，本质上教我们的是两件事：把调参问题形式化为搜索问题，以及学会用计算预算换取模型质量。这种思路本身，比任何一个具体工具都值钱。
在实际项目里，我现在的流程是：先用AutoGluon跑一个快速基线，拿到一个分数；再用Optuna对重点模型做二次优化；最后用少量手动调整处理AutoML顾不到的工程细节。这么一套组合拳下来，建模部分的时间压缩了至少一半，而且省出来的时间都投在了更重要的地方——数据分析、特征设计、上线监控。
希望这一章节对你有用。如果你在使用的过程中碰到了有意思的坑或者意外的收获，欢迎交流，说不定下一篇就是这个系列的下一个主题了。
