KerasTuner是TensorFlow官方推荐的轻量级超参搜索库，原生兼容tf.keras，支持贝叶斯优化、Hyperband和随机搜索，能自动处理早停、分布式训练与显存管理，避免手写循环导致的边界遗漏、复现困难和过拟合问题。
用 KerasTuner 跑超参搜索比手写循环靠谱得多
直接上结论：别自己写 for 循环遍历 learning_rate、batch_size、units —— 容易漏边界、难复现、不支持早停和分布式。KerasTuner 是 TensorFlow 官方推荐的轻量级超参搜索库，原生兼容 tf.keras.Model，且能无缝对接 tf.data.Dataset。
常见错误是把模型定义写死在 build_model() 外面，导致每次 trial 无法独立初始化权重；或者忘记在 tuner.search() 里传 validation_data，结果搜索全程只看训练 loss，选出的超参过拟合严重。
- 必须把模型构建逻辑封装进一个带
hp参数的函数，例如def build_model(hp): -
hp.Float('learning_rate', 1e-4, 1e-2, sampling='log')比线性采样更合理，因为学习率变化通常跨数量级 - 用
tuner = RandomSearch快速验证流程；真调参时换BayesianOptimization，但注意它要求max_trials >= 10才开始建模 - 务必设置
project_name和directory，否则每次运行都丢掉历史 trials
避免 tuner.search() 卡住或报错的关键配置
最常卡在 search() 第一轮：不是代码错，而是数据管道或回调没对齐。KerasTuner 默认每轮只跑 1 epoch，但如果你的 Dataset 没设 repeat() 或 batch() 大小不匹配，就会提前耗尽迭代器，抛出 OutOfRangeError。
另一个隐形坑是 GPU 显存——每个 trial 独立加载模型，但默认不释放显存。连续跑几十个 trial 后可能 OOM，尤其用了大 batch_size 或 Conv2D 层。
立即学习“Python免费学习笔记（深入）”；
- 在
build_model()结尾加model.compile(..., run_eagerly=False)，避免 eager mode 下调试信息干扰搜索 - 用
tf.data.Dataset.cache().prefetch(tf.data.AUTOTUNE)加速数据加载，否则 I/O 成瓶颈 - 显式传
epochs=50给search()，并配callbacks=[tf.keras.callbacks.EarlyStopping(patience=5)]，不然搜完所有 trials 才停 - 如果用
Hyperband，必须设hyperband_iterations=2（最小值），否则报ValueError: max_epochs must be at least 2
从 tuner.get_best_models() 提取可用模型要绕开两个陷阱
tuner.get_best_models(num_models=1)[0] 返回的是已训练好的 tf.keras.Model，但很多人直接拿去 predict，结果发现输出 shape 不对或 softmax 缺失——因为 build_model() 里可能没固定最后一层激活，或者用了 hp.Choice('loss', ['sparse_categorical_crossentropy', 'categorical_crossentropy'])，但没同步改 label 预处理逻辑。
更隐蔽的问题是：best model 的权重虽然训好了，但它的 input_shape 可能和你线上部署时的输入不一致。比如搜索时用 hp.Int('img_size', 224, 384, step=32)，但最佳值是 352，而你生产环境只支持 256×256。
- 调用
get_best_models()后，立刻用model.evaluate(test_dataset)验证，别只信 tuner 报的 validation accuracy - 检查
model.input_shape和model.output_shape，尤其当用了hp.Choice('num_classes', [3, 5, 10])时，输出层维度会变 - 保存模型用
model.save('best_model.h5')或model.save('best_model', save_format='tf')，别用tf.keras.models.load_model()直接读 tuner 的 checkpoint 目录
自定义搜索空间时，hp.Int/hp.Float/hp.Choice 的行为差异直接影响结果
hp.Int('units', 32, 128) 默认步长为 1，但神经元数没必要试 33、34……实际应设 step=16；而 hp.Float('dropout', 0.1, 0.5) 若不指定 sampling='linear'（默认），会在 0.1–0.5 之间均匀采样，但 dropout 值越小越敏感，更适合对数采样？其实不是——dropout 是概率值，线性更合理。
真正容易被忽略的是条件搜索（conditional space）：比如只有当 hp.Choice('optimizer', ['adam', 'sgd']) == 'sgd' 时，才暴露 hp.Float('momentum', 0.5, 0.99)。不用 hp.Boolean() 或嵌套 if，KerasTuner 会静默跳过该维度，导致搜索空间缩水。
- 用
hp.Choice('activation', ['relu', 'swish'])比字符串拼接安全，避免 typo 导致 build_model 报NameError - 对 batch size，优先用
hp.Choice('batch_size', [16, 32, 64, 128])，而不是hp.Int，因为显存占用是非线性的 - 如果搜索 learning rate 和 weight decay 的组合，别分开定义——用
hp.Float('lr_wd_ratio', 1e-3, 1e2, sampling='log')再推导wd = lr / lr_wd_ratio，更稳定
build_model，而在于让每个 trial 真正独立、可复现、内存可控，并且搜索出来的模型能直接进生产 pipeline。很多团队卡在“搜到了指标高的模型，一上线就崩”，往往是因为搜索时的数据预处理逻辑和线上不一致，或者忽略了 tf.function 编译带来的 shape 推断差异。 
