
简介这份《深度学习调参指南中文版》源自Google研究团队Varun Godbole等人撰写的经典调优手册面向具备机器学习基础、希望系统提升模型性能的工程师与研究人员。文档从基础理论延伸到高级技巧涵盖损失函数选择、优化器比较、超参数调整策略、正则化应用以及Batch Size确定、增量调整策略、探索与利用权衡等实战环节并涉及工作流实施与监督、自监督学习等场景帮助读者减少调参中的猜测与试错成本。资源包为单个PDF文件压缩包约3.09MB内容结构清晰按开始新项目、选择模型架构、选择优化器等章节组织注重可操作的实战指导。目前已有902人学习下载适合需要系统化梳理调参流程、对照手册查漏补缺的中高级深度学习从业者参考。1. 调参不是玄学一份把超参数搜索讲透的中文手册如果你跑过深度学习项目大概率经历过这种场景模型结构照搬论文数据预处理反复检查训练脚本跑了一轮又一轮验证集指标就是卡在某个位置不动。你开始怀疑是学习率不对于是手动试了 1e-3、5e-4、1e-4结果发现换一个随机种子结论又变了。这不是你一个人的问题。深度学习调参长期以来缺乏系统性资料论文只呈现最终结果博客只给零散技巧商业项目里的工程师又没时间复盘。这份《深度学习调优指南中文版》正是冲着这个缺口来的——它由 Google 的研究人员和工程师撰写2022 年 4 月发布 1.0 版中文版由 Jay Ning、血小板自动机、r-asou 翻译内容覆盖从项目启动、架构选择、优化器配置、Batch Size 确定到训练步数决策、训练管道优化、常见问题排查的完整链路。它不教你反向传播怎么推导而是告诉你面对一个具体任务先做什么、后做什么、哪些参数必须一起调、哪些坑几乎每个人都会踩。适合已经能跑通训练脚本、但想让模型性能再上一个台阶的工程师和研究人员。2. 从零启动一个项目架构、优化器和初始配置怎么定2.1 为什么第一版模型应该“抄”而不是“创”手册开篇就给了一个反直觉的建议开始新项目时尽量重用有效的模型架构不要一上来就构建自定义结构。原因很实际——模型架构本身带有大量超参数层数、层宽度、激活函数类型等选择架构实际上是在选择一个庞大的模型家族。如果你同时还要探索架构创新调参空间会大到无法有效搜索。常见做法是找一篇和你手头问题尽可能接近的论文把它的模型作为起点。比如做图像分类ResNet 或 EfficientNet 是经过大量验证的起点做序列建模Transformer 系列是默认选项。先让模型跑起来、出一个“合理”的结果再考虑替换组件。手册里特别强调即使你最终要构建自定义模型也应该在基线模型工作正常之后再动手。这个策略背后的逻辑是调参的本质是在配置空间中搜索而搜索效率取决于空间的大小和结构。一个成熟的架构已经把大量无效区域排除掉了你只需要在它周围调整超参数。如果从零设计架构你不仅要搜索超参数还要搜索架构本身两者叠加会让实验周期长到无法接受。2.2 优化器选择从简单到复杂别一上来就 Adam 全参数调手册对优化器的建议很明确坚持使用成熟、流行的优化器尤其是在项目初期。它列出的常用优化器包括 SGD with momentumNesterov 变体、Adam 和 NAdam。注意这里的关键词是“成熟”——不是最新而是经过大量实践验证、行为可预测的。一个容易被忽视的点是优化器本身的超参数数量直接影响调参工作量。Adam 有 4 个可调超参数学习率、β1、β2、ε而且手册明确指出“它们都很重要”。相比之下固定动量的 SGD 只有学习率和动量两个主要参数。在项目初期当你还在探索架构和其他超参数时把优化器超参数视为冗余参数、先用简单配置跑通是更高效的做法。我一般会这样操作第一轮实验用 Adam学习率设 1e-3β10.9β20.999ε1e-8这些是绝大多数框架的默认值。如果模型能正常收敛且验证集指标合理再考虑切换到 SGD with momentum 做精细调优。如果第一轮就发散先检查数据管道和损失函数而不是急着换优化器。# PyTorch 中 Adam 的默认配置项目初期直接用这套 optimizer torch.optim.Adam( model.parameters(), lr1e-3, # 学习率最需要关注的参数 betas(0.9, 0.999), # β1 和 β2控制一阶和二阶矩估计的衰减率 eps1e-8 # 数值稳定项防止除零 ) # 如果切换到 SGD with momentum optimizer torch.optim.SGD( model.parameters(), lr1e-2, # SGD 的学习率通常比 Adam 大一个数量级 momentum0.9, # 动量加速收敛并抑制震荡 nesterovTrue # Nesterov 动量通常比标准动量略好 )参数说明Adam 的lr是最关键的betas在大多数任务上不需要改eps几乎不用动。SGD 的lr需要重新搜索momentum一般设 0.9nesterovTrue是常见做法。注意从 Adam 切到 SGD 时学习率不能直接沿用通常要放大 5 到 10 倍再重新搜索。2.3 Batch Size 的确定先测吞吐量再选最大值Batch Size 是手册里着墨最多的超参数之一因为它同时影响训练速度、资源消耗和最终性能。手册的核心结论是Batch Size 不应该被直接用来调验证集性能它的主要作用是决定训练速度。只要所有超参数尤其是学习率和正则化参数都针对该 Batch Size 重新调好并且训练步数足够理论上任意 Batch Size 都能达到相同的最终性能。实际操作分两步。第一步是确定硬件能支持的最大 Batch Size。方法很简单用 2 的幂次如 32、64、128、256跑少量训练实验直到某个值触发内存不足。但要注意不能只看能不能跑还要看训练吞吐量是否随 Batch Size 增加而线性增长。# 估算训练吞吐量的简单方法 import time def measure_throughput(model, dataloader, batch_size, device): model.train() model.to(device) # 预热避免首次运行的开销影响测量 for _ in range(3): batch next(iter(dataloader)) batch {k: v.to(device) for k, v in batch.items()} outputs model(**batch) loss outputs.loss loss.backward() # 正式测量 start time.time() num_batches 20 for i, batch in enumerate(dataloader): if i num_batches: break batch {k: v.to(device) for k, v in batch.items()} outputs model(**batch) loss outputs.loss loss.backward() elapsed time.time() - start samples num_batches * batch_size throughput samples / elapsed return throughput # 对每个候选 batch_size 调用观察吞吐量变化 for bs in [32, 64, 128, 256]: # 需要重新构建 dataloader 以匹配 batch_size throughput measure_throughput(model, dataloader, bs, device) print(fBatch Size {bs}: {throughput:.1f} samples/sec)逻辑说明如果 Batch Size 从 64 翻倍到 128吞吐量也接近翻倍说明硬件还没饱和可以继续增大。如果吞吐量不再增长说明遇到了瓶颈可能是 I/O、CPU 预处理或通信同步此时更大的 Batch Size 不会带来训练加速应该停在当前值。手册特别提醒梯度积累虽然能模拟大 Batch Size但不提供任何吞吐量优势应用工作中通常应避免。第二步是选择最小化训练时间的 Batch Size。在吞吐量随 Batch Size 线性增长的范围内更大的 Batch Size 通常意味着更少的训练步数。手册引用的研究表明Batch Size 翻倍可能使训练步数减半这被称为“完美缩放”。但完美缩放只在临界 Batch Size 之前成立超过临界值后步数减少的效果会下降。所以最小化训练时间的 Batch Size 通常是硬件支持的最大值前提是它还在完美缩放范围内。2.4 初始配置的“简单、快速、合理”原则手册对初始配置的指导原则是三个词简单、快速、合理。“简单”意味着避免花哨的东西——先用恒定学习率不要一上来就加上余弦退火、warmup、标签平滑等技巧。“快速”意味着用较小的模型和较少的训练步数让每次实验尽快出结果。“合理”意味着模型在验证集上的表现至少明显好于随机猜测。选择训练步数时需要平衡步数越多性能越好调参越容易但步数越多每次实验越慢调参效率越低。手册建议先用一个较小的步数跑通流程确认模型能正常学习后再逐步增加。如果一开始就设了一个很大的步数后续调整学习率时会被这个步数绑定很难改。3. 增量调参策略把实验设计成可积累的过程3.1 探索优先于利用为什么理解问题比刷指标更重要手册第二章提出了一个核心观点大多数时候调参的目标应该是更深入地理解问题而不是直接提升验证集指标。它把调参活动分为“探索”和“利用”两类并明确指出大部分时间应该花在探索上。这个观点初看反直觉但仔细想很合理。如果你只盯着验证集指标可能会反复尝试一些碰巧有效的配置但这些配置为什么有效、在什么条件下有效、和其他超参数如何交互你并不清楚。一旦问题稍作变化数据分布偏移、模型规模调整之前的“最佳配置”可能完全失效。而如果你理解了哪些超参数对性能影响最大、哪些超参数之间存在强交互、哪些方向已经被证明无效后续的调参会越来越高效。具体到操作上每轮实验应该有一个明确的目标并且范围要足够小。手册举了几个目标示例尝试对训练流程进行改进如新的正则化器、了解特定模型超参数的影响、最大化验证集指标。注意这三个目标的层次不同——前两个是探索性的第三个是利用性的。手册建议在项目早期多做前两类实验等到对问题结构有了足够理解再集中精力刷指标。3.2 目标超参数、冗余超参数和固定超参数的分类方法设计实验时手册要求把所有超参数分为三类目标超参数、冗余超参数和固定超参数。目标超参数是你想测量其影响的参数冗余超参数是必须优化才能公平比较目标超参数值的参数固定超参数是在当前轮次中取固定值的参数。举个例子假设你的实验目标是“确定更深的模型是否会减少验证集错误”。那么模型层数是目标超参数。学习率是冗余超参数——因为不同深度的模型最优学习率不同你必须分别调整学习率才能公平比较不同深度的模型。激活函数是固定超参数——你可以根据过去的经验固定为 ReLU或者接受实验结论仅在 ReLU 下有效。这个分类的关键在于一个超参数属于哪一类取决于实验目标。同一个超参数在不同实验中可能扮演不同角色。手册强调如果有无限计算资源应该把所有非目标超参数都保留为冗余超参数这样结论不会受固定超参数的限制。但现实中计算资源有限所以需要在“调优冗余超参数的成本”和“固定超参数带来的结论限制”之间做权衡。我一般会这样操作对于每个实验目标先列出所有可能影响结果的超参数然后问自己——如果这个参数不调我会不会得出错误结论如果会它就是冗余超参数如果不会就固定它。冗余超参数的数量控制在 2 到 3 个以内否则每轮实验的计算量会爆炸。3.3 从实验结果中提取信息的四个动作手册列出了从实验结果中获取经验的具体方法我把它归纳为四个动作。第一个动作是检查搜索空间边界。如果你在搜索空间的最优点总是落在边界上比如学习率搜索范围是 [1e-4, 1e-2]最优点总是 1e-4说明真实的最优值可能在搜索空间之外。这时候需要扩大搜索范围而不是在现有范围内继续细化。第二个动作是检查采样点是否足够。手册指出如果搜索空间中有多个区域表现都不错但你只采样了少数几个点可能错过更好的区域。准随机搜索Quasi-Random Search比网格搜索更高效因为它能更均匀地覆盖空间。手册建议至少跑 10 到 20 个试验点才能对搜索空间的结构有初步判断。第三个动作是检查训练曲线。不要只看最终验证集指标要看整个训练过程中的损失曲线和指标曲线。如果训练损失持续下降但验证损失开始上升说明过拟合了需要加正则化。如果训练损失震荡剧烈可能是学习率太大或 Batch Size 太小。如果训练损失下降太慢可能是学习率太小或初始化有问题。第四个动作是使用隔离图isolation plot检测更改是否有用。隔离图的做法是在相同条件下只改变一个超参数观察性能变化。如果改变该超参数后性能显著提升说明这个方向值得继续探索如果性能不变或变差说明这个方向可以暂时搁置。# 一个简单的隔离图实验框架 import itertools import pandas as pd def run_isolation_experiment(base_config, param_name, param_values): base_config: 基础配置字典 param_name: 要隔离的超参数名 param_values: 该超参数的候选值列表 results [] for value in param_values: config base_config.copy() config[param_name] value # 这里调用你的训练函数 metrics train_and_evaluate(config) results.append({ param: param_name, value: value, val_loss: metrics[val_loss], val_acc: metrics[val_acc] }) return pd.DataFrame(results) # 示例隔离学习率的影响 base {batch_size: 128, optimizer: adam, epochs: 50} df run_isolation_experiment(base, lr, [1e-4, 5e-4, 1e-3, 5e-3, 1e-2]) print(df)逻辑说明这个框架的核心是“只变一个参数”。每次实验只改一个超参数其他保持固定这样性能变化可以明确归因到该参数。参数说明base_config是当前认为最优的配置param_values应该覆盖一个合理的范围通常跨越两个数量级train_and_evaluate是你的训练评估函数返回验证集指标。3.4 什么时候该上线新的最佳配置手册对“上线”的定义是更新当前的最佳配置。它强调每次上线必须有据可循不能仅仅因为某次实验碰巧得到了更好的结果就上线。判断依据包括改进是否在多个随机种子下稳定复现、改进是否在隔离实验中明确归因到某个变更、改进是否与现有配置的其他部分兼容。如果改进只在特定随机种子下出现很可能是噪声。如果改进无法归因到具体变更可能是多个因素共同作用的结果难以复现。如果改进与现有配置冲突比如新学习率导致之前调好的正则化参数失效需要重新调整相关参数。手册还提醒上线新配置后之前的实验结论可能不再适用。比如你之前发现某个正则化器无效但那是在旧学习率下测试的换了学习率后可能有效。所以每次上线后应该重新审视之前搁置的方向。4. 训练步数与训练管道那些容易翻车的细节4.1 训练步数怎么定计算受限与不受限两种场景手册第三章专门讨论训练步数的确定把它分为两种场景训练不受计算限制和训练受计算限制。不受计算限制时你可以训练足够多的步数直到模型完全收敛。手册建议使用学习率搜索算法来确定max_train_steps的初始值。具体做法是先设一个较大的步数用学习率扫描找到使验证集指标最好的学习率然后观察在这个学习率下验证集指标在第多少步达到最优。这个步数就是max_train_steps的合理初始值。受计算限制时你必须在固定时间内完成训练。手册建议分两轮第一轮用较少的步数快速筛选出有希望的配置第二轮用较多的步数精细调优。第一轮的步数可以设为最终目标步数的 1/10 到 1/5这样能在短时间内排除明显不好的方向。我一般会这样操作先跑一个 1000 步的小实验确认模型能正常学习。然后逐步增加到 5000、10000、20000 步观察验证集指标是否还在提升。如果指标在 10000 步后基本不变就把max_train_steps设在 10000 到 15000 之间。如果指标持续提升就继续增加步数直到计算预算用完。4.2 输入管道优化别让数据加载成为瓶颈手册第四章提到训练管道中的输入管道数据加载、预处理、增强经常成为隐藏瓶颈。当 GPU 利用率低于 80% 时通常意味着输入管道跟不上。常见做法是使用tf.data或 PyTorch 的DataLoader配合多进程加载。关键参数是num_workers它决定并行加载数据的进程数。设置原则是num_workers等于 CPU 核心数但不要超过 Batch Size。如果num_workers太大进程间切换的开销会抵消并行加载的收益。from torch.utils.data import DataLoader # 输入管道配置示例 dataloader DataLoader( dataset, batch_size128, shuffleTrue, num_workers8, # 根据 CPU 核心数调整 pin_memoryTrue, # 如果使用 GPU开启内存钉住加速传输 prefetch_factor2, # 每个 worker 预取的数据批次数 persistent_workersTrue # 保持 worker 进程存活避免每轮重新创建 )参数说明num_workers8适用于 8 核 CPU如果 CPU 核心更多可以适当增加。pin_memoryTrue在 GPU 训练时几乎总是有益的它把数据放在锁页内存中加速 CPU 到 GPU 的传输。prefetch_factor2表示每个 worker 提前准备 2 个批次的数据增加这个值可以平滑数据加载的波动但会占用更多内存。persistent_workersTrue避免每个 epoch 结束后重新创建 worker 进程对训练时间有可见的改善。4.3 评估设置与检查点选择别被最终检查点骗了手册强调评估设置必须尽可能代表部署环境。如果你在生产中关心的是 Top-5 准确率就不要只看 Top-1。如果你在生产中面对的是类别不平衡的数据评估集也应该反映这种不平衡。定期评估的频率需要权衡评估太频繁会拖慢训练评估太少可能错过最佳检查点。手册建议根据训练总步数来定通常每 100 到 500 步评估一次。对于短训练几千步可以每 100 步评估对于长训练几十万步可以每 1000 步评估。检查点选择是另一个容易翻车的点。手册明确指出最终检查点不一定是最佳检查点。由于过拟合或训练不稳定的存在验证集指标可能在训练中途达到峰值然后下降。所以必须保存定期检查点并在训练结束后回溯选择最佳检查点。# 检查点保存与回溯选择 best_val_loss float(inf) best_checkpoint None for step, batch in enumerate(dataloader): # 训练步骤... if step % eval_interval 0: val_loss evaluate(model, val_dataloader) if val_loss best_val_loss: best_val_loss val_loss best_checkpoint copy.deepcopy(model.state_dict()) # 保存到磁盘 torch.save(best_checkpoint, fcheckpoint_step_{step}.pt)逻辑说明每次评估后如果验证损失创新低就保存当前模型状态。训练结束后加载验证损失最低的检查点而不是最后一个检查点。参数说明eval_interval是评估间隔根据训练总步数调整copy.deepcopy确保保存的是当前状态的副本而不是引用。4.4 BatchNorm 的实现细节训练和评估模式的区别手册专门用一节讨论 BatchNorm 的实现细节因为它是训练管道中最容易出错的组件之一。核心问题是BatchNorm 在训练时使用当前批次的统计量在评估时使用训练过程中累积的移动平均统计量。如果忘记切换模式评估结果会完全错误。# 正确的 BatchNorm 使用方式 model.train() # 训练模式BatchNorm 使用当前批次统计量 for batch in train_dataloader: # 训练步骤... model.eval() # 评估模式BatchNorm 使用累积的移动平均统计量 with torch.no_grad(): for batch in val_dataloader: # 评估步骤...另一个细节是 BatchNorm 的momentum参数它控制移动平均的更新速度。默认值 0.1 在大多数情况下工作良好但如果 Batch Size 很小可能需要减小 momentum 以增加统计量的稳定性。手册还提到 Ghost Batch Norm 的做法使用与计算梯度不同的 Batch Size 来计算统计量这在超大 Batch Size 训练中有时有用。5. 避坑与排查那些手册里没明说但实际会遇到的坑5.1 学习率预热没做对模型直接发散现象训练开始后损失迅速上升到 NaN或者损失剧烈震荡完全不收敛。原因学习率相对于当前模型状态太大。在训练初期模型参数是随机初始化的梯度方向可能很不稳定。如果直接用目标学习率可能一步就把参数更新到无效区域。解决加入学习率预热warmup。在训练的前 N 步学习率从 0 线性增加到目标值。N 通常设为总步数的 1% 到 5%。手册在 5.8.2.1 节专门讨论了预热建议在训练不稳定时优先尝试。# 线性预热 余弦退火的学习率调度 from torch.optim.lr_scheduler import LambdaLR import math def get_scheduler(optimizer, warmup_steps, total_steps): def lr_lambda(step): if step warmup_steps: return step / warmup_steps progress (step - warmup_steps) / (total_steps - warmup_steps) return 0.5 * (1 math.cos(math.pi * progress)) return LambdaLR(optimizer, lr_lambda) scheduler get_scheduler(optimizer, warmup_steps500, total_steps10000)参数说明warmup_steps是预热步数通常设为总步数的 1% 到 5%total_steps是总训练步数。预热阶段学习率线性增加之后余弦退火到 0。5.2 梯度截断没设对梯度爆炸反复出现现象训练过程中损失突然飙升或者梯度范数持续增大。原因某些批次的梯度异常大导致参数更新幅度过大。这在 RNN、Transformer 和深层网络中尤其常见。解决加入梯度截断gradient clipping。手册在 5.8.2.2 节建议当训练不稳定时先尝试梯度截断。常见做法是截断梯度范数到某个阈值如 1.0 或 5.0。# 梯度截断 torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0) # 然后在 optimizer.step() 之前调用 optimizer.step()参数说明max_norm1.0是截断阈值如果梯度范数超过这个值就按比例缩放。阈值太小会减慢训练太大则起不到防止爆炸的作用。我一般从 1.0 开始试如果训练太慢就调到 5.0。5.3 验证集指标震荡选错检查点现象验证集指标在训练过程中上下波动最终检查点的指标不是最好的。原因验证集太小或评估频率太低导致指标噪声大。或者模型在训练后期过拟合验证集指标下降。解决增加验证集大小如果可能提高评估频率保存定期检查点并回溯选择最佳。手册在 4.3 节明确建议保存检查点并追溯选择最佳检查点而不是直接用最终检查点。5.4 多主机训练时 BatchNorm 统计量不同步现象单机训练正常多机训练时验证集指标明显变差。原因多主机训练时每台机器上的 BatchNorm 只使用本机批次的数据计算统计量导致各机器的统计量不一致。解决使用同步 BatchNormSyncBatchNorm它在所有机器上同步计算统计量。PyTorch 提供了torch.nn.SyncBatchNorm可以通过convert_sync_batchnorm转换现有模型。# 将 BatchNorm 转换为 SyncBatchNorm model torch.nn.SyncBatchNorm.convert_sync_batchnorm(model)注意SyncBatchNorm 需要进程组通信会引入额外开销。如果 Batch Size 已经很大收益可能不明显。5.5 学习率衰减方案选错后期训练无效现象训练后期损失不再下降验证集指标停滞。原因学习率没有及时衰减模型在最优值附近震荡而不是收敛。解决手册在 5.1 和 5.2 节讨论了学习率衰减方案。默认推荐余弦退火或线性衰减。如果训练步数已知余弦退火通常表现良好如果训练步数可能变化线性衰减更灵活。手册特别提醒复杂的衰减方案如分段常数、指数衰减在大多数情况下并不比简单的余弦退火更好除非有明确证据表明需要。6. 进阶技巧用准随机搜索替代网格搜索手册在 5.5 到 5.7 节专门讨论了准随机搜索Quasi-Random Search这是我认为整份文档中最实用的进阶技巧之一。网格搜索的问题是当超参数维度增加时需要的试验点数量指数增长。而随机搜索在相同试验点数量下能更均匀地覆盖搜索空间。准随机搜索则更进一步它使用低差异序列如 Sobol 序列来生成试验点比纯随机搜索覆盖更均匀。手册建议在探索阶段使用准随机搜索而不是更复杂的黑盒优化算法如贝叶斯优化。原因是在项目早期搜索空间的结构还不清楚贝叶斯优化依赖对搜索空间的先验假设可能误导探索方向。准随机搜索不假设任何结构能更客观地揭示搜索空间的形状。# 使用 scipy 的 Sobol 序列生成准随机搜索点 from scipy.stats import qmc import numpy as np def generate_quasi_random_points(n_points, param_ranges): n_points: 试验点数量 param_ranges: 字典键为参数名值为 (min, max) 元组 sampler qmc.Sobol(dlen(param_ranges), scrambleTrue) points sampler.random(nn_points) # 将 [0,1] 区间的点映射到实际参数范围 param_names list(param_ranges.keys()) result {} for i, name in enumerate(param_names): low, high param_ranges[name] # 对数均匀分布适用于学习率等跨数量级的参数 if name in [lr, weight_decay]: result[name] np.exp(np.log(low) points[:, i] * (np.log(high) - np.log(low))) else: result[name] low points[:, i] * (high - low) return result # 示例为学习率和权重衰减生成 20 个搜索点 ranges { lr: (1e-5, 1e-2), weight_decay: (1e-6, 1e-2), dropout: (0.0, 0.5) } points generate_quasi_random_points(20, ranges) for i in range(20): print(fTrial {i}: lr{points[lr][i]:.2e}, wd{points[weight_decay][i]:.2e}, dropout{points[dropout][i]:.2f})逻辑说明Sobol 序列生成的是 [0,1] 区间内的低差异点需要映射到实际参数范围。对于学习率和权重衰减这类跨数量级的参数使用对数均匀分布对于 dropout 这类有界参数使用线性均匀分布。参数说明n_points是试验点数量手册建议至少 10 到 20 个scrambleTrue打乱序列避免不同维度之间的相关性。手册在 5.7 节回答了“需要多少次试验”的问题对于低维搜索空间2 到 3 个参数10 到 20 个试验点通常足够对于高维空间5 个以上参数需要 50 到 100 个试验点。但手册也提醒试验点数量不是越多越好关键是要根据实验结果动态调整搜索空间。我自己的习惯是第一轮用 20 个准随机点覆盖整个搜索空间观察哪些区域表现好。然后围绕表现好的区域缩小搜索范围再用 10 到 15 个点做第二轮。这样两轮下来通常能找到比手动调参好得多的配置。从那以后我每次启动新项目都会先用准随机搜索跑一轮基线而不是凭经验设一组参数就开跑。希望帮到你。本文还有配套的精品资源点击获取