HalvingGridSearchCV：比GridSearchCV快数倍的省算力网格搜索

去年调一个线上模型的超参数，我用 GridSearchCV 摆了一张很大的参数网格，结果一次交叉验证跑了大半夜，第二天看 log 才发现才跑了一半。从那以后我养成了先算账的习惯：参数组合数 × 折数 × 单次拟合耗时，稍微乘一下就心凉。

回到开头那句话的语境——如果你也是用 Python 做机器学习调参，正在被参数空间网格搜索的算力成本折磨，那我强烈建议你试试 sklearn 自带的 HalvingGridSearchCV。它是网格搜索的一种"省算力"进阶玩法，能在保证最终结果接近穷举搜索的前提下，把耗时压缩到原来的几分之一甚至几十分之一。这篇文章我会从原理到代码、再到坑点逐一拆解它，新手能直接照着抄，老手也能在资源分配和参数选择上收获一些可复用的经验。

1. GridSearchCV 的痛点和 HalvingGridSearchCV 的解题思路

1.1 穷举网格搜索的算力账

GridSearchCV 的本质很简单：把你圈定的参数网格里每一组超参数组合都跑一遍交叉验证，然后按平均分选出最优。朴素的思路往往最烧钱，因为组合数量是按笛卡尔积增长的。比如随机森林，n_estimators 取 4 个值，max_depth 取 4 个值，min_samples_split 取 3 个值，min_samples_leaf 取 3 个值，那组合数就是 4 × 4 × 3 × 3 = 144 个。如果交叉验证折数是 5，就是 720 次完整的模型拟合。每次拟合又包含建树、分裂、评估，样本量上万时，单次可能就是几十毫秒到几秒，乘起来就是一场漫长的等待。

更扎心的是，这 720 次拟合里，绝大多数算力都用在了"一眼就不行"的组合上。超参数空间里通常只有一小片区域是优的，其余大部分组合表现平庸，但 GridSearchCV 对好组合和坏组合一视同仁，每个候选都分配同样多的数据、同样的训练轮数。这就像评委让 100 个歌手每人完整唱 3 分钟，才决定淘汰谁。如果第一轮只让他们各唱 15 秒，先把明显跑调的筛掉，再让剩下的人完整展示，是不是能省很多时间？这就是 HalvingGridSearchCV 的核心直觉。

1.2 方案选型：随机搜索、贝叶斯优化还是逐次减半

GridSearchCV 太慢时，常见的替代方案有三条路。第一条是用 RandomizedSearchCV 在参数空间里随机撒点，跑固定次数就收手，简单但带有运气成分，可能在重要区域没采到点。第二条是上贝叶斯优化库，比如 Optuna、Hyperopt，用历史评估结果拟合一个代理模型来引导下一步搜索方向，效果上限高，但是要接额外依赖、要熟悉它的 Trial 与 Sampler 机制，学习成本和工程改造成本都不低。

第三条就是 sklearn 从 1.0 版本开始内置的 HalvingGridSearchCV（以及它的随机版 HalvingRandomSearchCV）。它保留网格搜索"所有候选都参与比赛"的确定性，不用额外装包，只用标准接口就能跑。对于参数网格中等规模、模型单次拟合有一定成本的场景，它基本是性价比最高的起步方案。我个人的选型经验是：如果参数组合数少于 30，直接 GridSearchCV；组合数在 30 到几百，优先 HalvingGridSearchCV；组合数上千且对调参结果要求极致、团队也愿意维护 Optuna 那套流程，再上贝叶斯优化。

2. HalvingGridSearchCV 核心原理：逐次减半是怎么运行的

2.1 逐次减半背后的"海选"逻辑

HalvingGridSearchCV 的算法名称来自 Successive Halving，每一轮都按比例砍掉一部分候选者。它有一个核心设定叫"资源"，默认资源就是训练样本量。整个流程可以这样理解：第一轮，让所有候选参数组合都在一个比较小的数据子集上训练并打分，比如 100 条样本；按分数排序，只保留成绩最好的 1/factor 部分，剩下的直接淘汰；第二轮，把资源放大 factor 倍，用 300 条样本继续评估幸存者，再淘汰一批；如此反复，直到某一轮资源接近全量数据，此时留下的候选极少，再做最终 PK。

这么做的好处是，把总预算从"平均分配给所有组合"改成了"前期小额广撒，后期重仓幸存者"。想象一下招聘流程：第一轮看简历，成本最低，筛掉明显不匹配的；第二轮电话面试；第三轮现场技术面；最后才是谈薪。如果一上来就让每个候选人都做完整的项目展示，时间和成本都不可控。机器学习里的"简历筛选"阶段就是小样本训练，虽然评估不一定精准，但足够区分特别差和特别好的候选，这就够了。

2.2 六个关键参数逐个讲透

用之前一定要把参数含义吃透，否则改了等于没改。我按重要程度一个个说。

• factor：每一轮幸存者的比例分母，默认是 3，表示每轮只保留约 1/3 的候选者，同时资源放大 3 倍。factor 越大淘汰越狠、速度越快，但误杀风险也越高，建议从默认的 3 开始，需要更精细的搜索再调到 2。
• resource：资源类型，默认 'n_samples'，也就是数据子集大小。如果你的模型支持迭代训练，比如 SGDClassifier、MLPClassifier 这类带 max_iter 的模型，可以把 resource 设为 'n_iterations'，这时候逐次减半的就是训练轮数而非样本量，某些场景下更直观。
• max_resources：单轮可用的最大资源，默认 'auto'。当资源类型是样本量时，auto 就是全部样本数；当资源类型是迭代轮数时，auto 就是估计器里的 max_iter 值。
• min_resources：第一轮使用的资源量，默认 'smallest'，系统会按交叉验证折数自动估算一个最小可用值，大致等于样本量除以折数。这个参数对总耗时影响非常大，后面实操部分我会专门讲怎么定。
• aggressive_elimination：默认 False。当候选者很多、按 factor 等比砍到后期仍然不止一个幸存者时，打开它可以强制继续淘汰，保证最后只剩 1 个候选。代价是有几轮可能在同一资源档位上重复烧算力。
• cv、scoring、n_jobs、refit、random_state：这些和 GridSearchCV 里的含义基本一致。唯一要提醒的是 random_state 在 HalvingGridSearchCV 里不是摆设，因为它每一轮只跑一次小样本评估，随机性比穷举搜索大得多，固定随机种子能让你复现结果。

2.3 迭代轮数与候选数变化怎么估算

要理解总耗时，得会算迭代轮数。公式是：n_iterations = floor(log_factor(max_resources / min_resources)) + 1。举个例子，样本量 2000，min_resources 设为 50，factor 取 2，那么 2000 / 50 = 40，log₂40 约 5.32，取整加 1 就是 6 轮迭代。每一轮资源依次是 50、100、200、400、800、1600，最后一轮虽然略小于 2000，但已经足够接近全量。

候选数则是每轮除以 factor 向下取整。初始 144 个组合，按 factor=2 依次变成 72、36、18、9、4，最后 4 个在最大资源上做最终对比。这里有个很漂亮的规律：每轮消耗的算力大约是"当时候选数 × 当轮资源"，而候选数按 factor 缩小、资源按 factor 放大，两者相乘基本不变，也就是说每一轮淘汰赛的算力成本大致持平。总成本约等于 迭代轮数 × 初始候选数 × min_resources。用这个公式估算，144 个组合、min_resources=50、6 轮，再乘 5 折交叉验证，大约是 21.6 万份"样本×拟合"的工作量；而穷举网格搜索是 144 × 2000 × 5，约 144 万份，差了 6 倍以上。如果把 factor 调到 3，省得更多，这就是它能提速的核心原因。

3. 实操：用 HalvingGridSearchCV 调优随机森林全流程

3.1 数据与参数网格准备

理论讲完直接上代码。为了演示方便，我用 make_classification 生成一个 2000 样本、20 特征的二分类数据集，模型选随机森林，因为它有多个超参数、且单次拟合有一定成本，很适合展示逐次减半的加速效果。

python复制import time
import pandas as pd

from sklearn.datasets import make_classification
from sklearn.ensemble import RandomForestClassifier
from sklearn.model_selection import HalvingGridSearchCV

# 生成演示数据
X, y = make_classification(
    n_samples=2000,
    n_features=20,
    n_informative=15,
    n_redundant=5,
    random_state=42,
)

param_grid = {
    'n_estimators': [50, 100, 200, 300],
    'max_depth': [None, 10, 20, 30],
    'min_samples_split': [2, 5, 10],
    'min_samples_leaf': [1, 2, 4],
}

组合数就是 4 × 4 × 3 × 3 = 144。如果你的数据是真实项目里的表数据，我建议先把训练集和验证集切出来，拿验证集做最后的 sanity check，搜索过程只在训练集上做，避免把验证集的信息提前泄漏进参数选择里。

3.2 核心代码与配置说明

接下来是主角登场：

python复制hgs = HalvingGridSearchCV(
    estimator=RandomForestClassifier(random_state=42),
    param_grid=param_grid,
    factor=2,                # 每轮保留 1/2 候选者
    resource='n_samples',    # 资源维度：样本数
    max_resources='auto',    # 最大资源 = 全部样本
    min_resources=100,       # 第一轮只用 100 条样本
    cv=5,
    scoring='accuracy',
    n_jobs=-1,
    random_state=42,
    refit=True,              # 结束后在全量数据上重训最优模型
    verbose=1,
)

start = time.time()
hgs.fit(X, y)
print(f"耗时: {time.time() - start:.1f} 秒")

我特意把 min_resources 从默认值调成了 100，而不是用 'smallest'，这是有讲究的。默认 smallest 在 5 折交叉验证下约等于样本量除以折数，也就是 400，这样的话迭代轮数只有 3 轮，很多组合来不及被充分淘汰。把起点压到 100，就能跑出 5 到 6 轮淘汰赛，加速效果更明显。当然，也不能调太小，比如 10 条样本上去训练一棵随机森林，噪声会大到排序毫无意义，这个度需要在项目里试几次才能摸准。

另外注意 n_jobs=-1 会让所有轮次的候选并行计算，短时间内存和 CPU 会打满，本地环境要留意是不是在跟其他服务抢资源。我之前就在共享服务器上吃过亏，一跑调参任务，同事的接口响应全变慢，后来学乖了，并行任务少的时候设成 n_jobs=4 或 8。

3.3 从 cv_results_ 读取完整比赛记录

跑完之后，除了直接看 best_params_ 和 best_score_，我更建议把 cv_results_ 拉出来好好读一遍，它能告诉你整个淘汰赛的完整过程：

python复制print("最优参数:", hgs.best_params_)
print("最优分数:", hgs.best_score_)

results = pd.DataFrame(hgs.cv_results_)
summary = results[['iter', 'n_resources', 'n_candidates',
                   'mean_test_score', 'params']].sort_values('iter')
print(summary.head(20))

cv_results_ 里每一行代表一次"候选组合 × 某轮资源"的评估，其中的 iter 列标记轮次，n_resources 列标记该轮用了多少样本，n_candidates 列标记该轮还剩多少候选。读这张表能发现很多细节，比如某些参数组合在资源只有 100 时分数很低、但资源加到 400 后排名一路上升，这说明它有潜力，只是需要更多数据才能发挥；反过来，那些前期分数高、后期被反超的组合，往往是小样本上的过拟合。

还要提醒一点：不要跨轮次比较 mean_test_score。第 0 轮用 100 条样本的 0.86 分，和第 5 轮用 1600 条样本的 0.91 分，两者资源不同、评估精度不同，直接比较没有意义，只会得出错误结论。HalvingGridSearchCV 内部也是只看同轮排名，而不是跨轮比较分数绝对值。

4. 常见报错、避坑技巧与使用边界

4.1 新手最容易踩的坑

第一个坑是候选数不足。如果你的参数网格只有 8 个组合，factor 又设成了 4，系统会发现还没开始淘汰就快没人了，直接报错或警告，提示候选值太少。解决办法要么扩大参数网格，要么把 factor 调小，要么干脆回到 GridSearchCV。这个报错信息我第一次见时愣了半天，后来想明白了：逐次减半的本质是"从多到少"，起点都不够多，自然没法施展。

第二个坑是候选数太多导致淘汰不干净。144 个组合在几轮淘汰后最后仍剩下不止一个候选时，默认策略可能提前停止淘汰，导致最后一批候选在同一个资源档位上重复比较，失去"逐次减半"的意义。出现这种提示时，把 aggressive_elimination=True 打开，它会强制继续按 factor 淘汰，保证最后只留 1 个候选。

第三个坑跟随机性有关。HalvingGridSearchCV 前期用少量样本评估，随机种子不同，早期被淘汰的候选会不一样，最终结果也可能不一样。这不是 bug，而是小样本评估方差大的正常表现。我的习惯是固定 random_state，在关键项目里再跑两三个种子验证最优参数是否稳定；如果换个种子最优参数就变了，说明 min_resources 设得太低，数据太少扛不住信息量，需要调高起点资源。

4.2 什么时候别用它：使用边界

HalvingGridSearchCV 不是万能的，我见过不少同学把它当成银弹，结果反而耽误事。如果你的参数组合总数很少，比如十几个，GridSearchCV 全跑一遍也就几分钟，没必要引入多一轮淘汰的随机性；如果是小样本数据集，总共就几百条样本，min_resources 根本压不下来，迭代轮数很少，逐次减半的优势体现不出来；如果你的模型单次拟合极快，比如线性模型在中等数据上，那瓶颈根本不是算力，这个搜索器也帮不上忙。

另外，如果你需要的是"可解释、可复现"的完整搜索报告——比如写论文、做基线对比，审稿人或团队要求列出所有组合的交叉验证分数——GridSearchCV 那种全枚举的结果更直观。HalvingGridSearchCV 只评估了幸存路径上的组合，表格里缺了很多被早期淘汰的候选。这种情况下建议两者结合：先用 HalvingGridSearchCV 快速锁定一个小范围，再在这个小范围上用 GridSearchCV 做一次精细、可汇报的穷举验证。

4.3 提高搜索质量的实战技巧

最后分享几个我实际项目里沉淀下来的技巧。

第一，评分指标一定要贴近业务。分类问题不平衡时别用 accuracy，改成 'f1'、'roc_auc' 这类更稳的指标；回归问题根据自己的需求选 'neg_mean_squared_error' 还是 'r2'。HalvingGridSearchCV 每轮只按一个指标排序，指标没选对，淘汰赛从第一轮就歪了。

第二，把 min_resources 当成一个超参数来对待。我一般会用几百条样本作为起点来测一轮搜索耗时，如果一轮跑得太快或太慢，再调整 min_resources 和 factor。经验上，表格类任务 min_resources 放在 100 到 500 之间比较合理，图像、文本这类高维数据适当上调。

第三，搜索结束后，别直接把 best_score_ 当作最终模型的泛化性能。它的含义是"最后一轮在最大资源上的交叉验证分数"，不等于"最终模型在测试集上的表现"。正确流程是：用 best_params_ 重建模型，在独立的测试集上再评估一次；如果项目允许，还可以在全部训练数据上用最佳参数重新拟合一轮，得到生产模型。这一步很多人会漏，导致上线后发现线上分数跟调参时对不上。

我也遇到过一种很有意思的场景：最优参数组合下，模型在小样本轮次分数一般，但到大资源轮次稳定排第一。这说明这个组合是"越喂数据越强"的类型，恰恰是真实业务里最值得用的模型；反过来，如果某个组合全靠小样本阶段的高分一路保送，到了大样本阶段却排名下滑，多半是过拟合信号，我会警惕它，即使它是最终幸存者也会多看一眼验证集表现。这些判断，都是 cv_results_ 那张表格教给我的，希望你也能从中读出自己模型的故事。