使用Tidymodels调优XGBoost运行超12小时未结束，如何解决？

核心原因 #

• 预处理与工作流不匹配，引入高基数特征
  你已完成预处理配方定义，但构建工作流时未使用add_recipe(hts_recipe)，反而通过add_formula(hts_test_result ~ .)直接传入原始训练集。这会导致两个问题：一是独热编码、SMOTE过采样、标准化等预处理步骤会在20组参数×默认10折交叉验证的200次训练中重复执行；二是原始训练集中patient_id是24422个水平的高基数因子，公式默认对其做独热编码生成两万余列稀疏特征，计算量呈指数级增长。
• 并行逻辑冲突导致资源争抢
  XGBoost本身自带多线程训练能力，你注册的doParallel会为每个交叉验证任务分配独立进程，两层并行逻辑会造成CPU资源抢占、进程阻塞，大幅降低运行效率。
• 训练与存储开销冗余
  默认10折交叉验证搭配20组超参数、每轮训练500棵树，总计需要训练200个XGBoost模型，同时开启的save_pred = TRUE会存储每一轮的全量预测结果，额外增加内存与IO开销。
• 超参数搜索范围未收敛
  拉丁超立方抽样生成的20组参数覆盖范围极广，可能包含树深过大、学习率极小的参数组合，这类组合的单模型训练耗时是常规参数的数倍。

优化方案 #

• 修正工作流逻辑，将xgb_wf中的add_formula(hts_test_result ~ .)替换为add_recipe(hts_recipe)，确保预处理逻辑生效，同时过滤ID类高基数特征。
• 调整并行策略：取消doParallel::registerDoParallel()，在XGBoost引擎中直接指定线程数set_engine("xgboost", nthread = 14)，预留2核给系统调度，避免并行冲突。
• 降低初始运行开销：调参阶段关闭save_pred = TRUE，可先将交叉验证折数降至5折、树的数量降至200、学习率下限设为0.01，验证流程跑通后再回调参数。
• 调整过采样比例：阳性样本占比90%的场景下，可先将SMOTE的over_ratio降至0.5减少训练样本量，流程验证完成后再调整至目标值。

内容的提问来源于stack exchange，提问作者anubhuti mishra