1. 从手动调参到AutoML我为什么最终留下了TPOT先交代一下背景。我大部分时间在做表格类机器学习项目客户那边的数据基本在几万到几十万行量级变量几十到几百个。这类项目最花时间的不是写模型代码而是把数据预处理、特征选择、模型选择和超参调优这一整条pipeline试出来。以前我都是手动用for循环加GridSearchCV一套一套跑直到有个项目连续两周没调出理想结果才认真把AutoML工具捡起来。折腾过好几个主流库之后留到最后真正常用的是TPOT也就是Tree-based Pipeline Optimization Tool。这篇文章就把我对TPOT的理解和实战用法完整记录下来从工作机制到参数设置从demo跑通到生产部署包括后来踩过的几个坑希望对同样在做表格类项目的人有用。先说一个容易误解的点TPOT不是一个超参搜索工具而是一个pipeline自动构造工具。GridSearchCV帮你在给定模型的一堆超参里找最优组合但TPOT干的事更大——它会同时帮你决定要不要标准化、要不要做PCA、选几个特征、用什么模型、模型的超参设多少、要不要把几个模型堆叠起来。它搜的不是一个点而是一整条数据处理链路。1.1 手动调参的痛不止是超参数还有pipeline组合手动调参的痛点经历过的人都懂。假设你有三个预处理器StandardScaler、MinMaxScaler、RobustScaler两个特征选择器SelectPercentile、PCA三个模型LogisticRegression、RandomForestClassifier、GradientBoostingClassifier每个模型再各自带5到8个超参。光是组合数就远超能靠人肉试完的范围——而这还是没算上游特征工程和下游阈值选择的情况。更麻烦的是这些选择之间有耦合关系。比如RandomForest对特征缩放不敏感但KNN和LogisticRegression对缩放极其敏感PCA会把特征含义抹掉但决策树系模型反而无所谓PolynomialFeatures生成高维交互项之后正则化参数和特征选择器都得跟着变。手动调参时你很难系统地把这种耦合关系都试一遍通常是凭经验假设一组看起来合理的组合然后在附近微调。这其实是拿个人经验赌搜索空间赌对了是运气赌错了就是白加班。TPOT解决的就是这个问题把预处理特征工程模型超参当成一个整体去搜索而不是一段一段分别优化。1.2 TPOT的定位主流AutoML库横向对比先说结论TPOT不是万能的但它有非常独特的生态位。目前主流的AutoML方案我基本都试过列个表给你感受一下差异工具核心策略适合场景主要短板TPOT遗传编程搜索pipeline结构中小型表格数据、需要模型可解释、想拿到可直接改写的sklearn代码大数据量上速度慢不做自动特征编码Auto-sklearn贝叶斯优化元学习集成结构化数据、几千到几万行数据安装依赖重Windows下尤其麻烦AutoGluon多模型堆叠自动集成大规模表格、多模态数据依赖重模型栈复杂解释成本高H2O AutoML网格/随机搜索模型集成企业级场景、分布式大数据需要Java环境和sklearn生态衔接弱Optuna参数化搜索框架调超参、深度学习、自定义搜索空间不算完整AutoML不自动做pipeline结构搜索TPOT最大的特点是透明。它搜出来的结果不是黑盒而是一段标准sklearn pipeline代码你可以导出之后继续手工修改、加注释、删减组件完全融入现有工程链路。对于我这种需要跟业务方解释模型逻辑、需要代码走评审的项目来说这是刚需。另外它pip安装简单不依赖Java不要求Linux特定环境普通笔记本也能跑。2. TPOT的核心机制遗传编程如何进化出你的机器学习pipeline用之前我一直有个疑问TPOT凭什么能在这么大的组合空间里找到好pipeline后来翻源码、读论文才发现它用的不是暴力搜索而是遗传编程Genetic Programming。这块机制值得花点篇幅讲清楚因为理解了它你才会知道为什么参数要那样配为什么跑出来的结果长那样。2.1 一个关键转变把pipeline表达成程序树TPOT把一条机器学习pipeline表示成一棵程序树。树的叶子节点是具体算子比如StandardScaler、PCA、RandomForestClassifier树的内部节点代表数据流经的顺序。举个例子下面这条pipeline原始数据 → StandardScaler → PCA(n_components0.9) → RandomForestClassifier(n_estimators200)在TPOT内部会被编码成类似嵌套函数调用的树形结构RandomForestClassifier( n_estimators200, PCA( n_components0.9, StandardScaler() ) )你可以类比源代码的AST语法树。TPOT就是在树的空间里做搜索而不是在超参网格里做搜索。树的结构决定pipeline拓扑树叶上的参数决定具体行为。交叉、变异操作都作用在这棵树上所以它天然能表达先做特征变换再接模型这种结构也能表达两个模型输出堆叠这种复杂结构。TPOT默认的搜索空间覆盖了常见的sklearn预处理算子、特征选择算子、降维算子、分类器和回归器。如果你安装了xgboost和lightgbm这两类模型也会被纳入候选没装也不影响运行TPOT会自动跳过不可用的算子。2.2 种群迭代的三板斧锦标赛选择、交叉、变异遗传编程的迭代过程本质上就是达尔文那套选择、交叉、变异。TPOT用的是改进版的NSGA-II算法每一代流程大致如下初始化种群随机生成一堆pipeline树比如population_size100就是100棵不同的树。评估适应度每个个体在训练集上做交叉验证得到一个性能得分。这个得分不是最终目标而是进化的适应度。锦标赛选择从当前种群中随机抽一小批个体留下表现最好的那个作为父本。这样做的好处是既偏向优秀个体又给普通个体留了活路避免太早收敛到局部最优。交叉选两个父本交换它们各自的一部分子树生成新个体。举个例子A的PCA子段接到B的分类器子段前面拼出一条全新pipeline。变异随机改动某个个体的局部比如把LogisticRegression的C参数从1.0改成0.1或者把一棵子树整体替换成另一个算子。生成新一代父代和子代混在一起按得分高且复杂度低的双目标进行非支配排序选出下一代的种群。你可能会问为什么交叉率只有0.1变异率却有0.9这不是和常见遗传算法反着来吗答案在2.3讲这里先卖个关子。2.3 为什么不用网格搜索搜索空间爆炸的数学直觉假设你有10个预处理算子、5个特征选择算子、8个模型每个模型的超参平均有5个候选值。如果穷举所有pipeline组合数量级保守估计也是百万级。而每个组合都要在训练集上做一次交叉验证也就是要对模型做5次fit这在实际项目里根本跑不完。更重要的是pipeline组合空间不是普通网格而是结构空间。网格搜索无法表达先A预处理再接B模型再接C模型这种拓扑变化你只能固定一个结构然后微调超参。TPOT把结构也纳入变异和交叉的对象搜索效率完全不同。遗传编程在这样的大空间里不需要评估所有组合它靠保留优秀的子树片段来逐步逼近更优结构。一旦某个个体试出PCALogisticRegression效果不错这个子结构就会通过交叉扩散到整个种群后面几代在这个基础上继续微调这就是它比暴力搜索高效的核心原因。另外TPOT在进化过程中做了个很聪明的设计它同时优化两个目标——交叉验证得分和pipeline复杂度。复杂度用小树深度和算子数量衡量个体越简单越好。所以最终结果的pipeline往往不会故意给你堆一堆无用的变换步骤这在工程上非常省心也侧面提高了一点可解释性。3. 最小可用实践跑通一次TPOT搜索的完整链路理论讲再多不如直接跑一次。我用sklearn自带的乳腺癌数据集做演示这个数据集大小合适569个样本、30个特征二分类问题跑起来不慢适合先在本地把链路摸熟。3.1 环境准备安装很简单pip一行搞定pip install tpot如果你希望XGBoost、LightGBM也参与搜索顺手一起装pip install tpot xgboost lightgbm注意TPOT在运行时才检测三方库是否可用所以装完xgboost之后不用改任何代码搜索空间会自动包含它。另外提醒一句Windows下装xgboost如果遇到坑用conda装通常省事。我当前用下来TPOT的API一直挺稳定0.11和0.12版本之间接口基本一致这篇示例代码在新版上直接跑没问题。3.2 数据准备与切分TPOT对输入数据有一个硬性要求它只接受数值型特征而且不处理缺失值。类别特征需要你自己先做编码缺失值需要先做填充或删除。这个坑后面我会专门展开先按最简单的情况来。from sklearn.datasets import load_breast_cancer from sklearn.model_selection import train_test_split X, y load_breast_cancer(return_X_yTrue) X_train, X_test, y_train, y_test train_test_split( X, y, test_size0.2, random_state42, stratifyy ) print(X_train.shape, y_train.shape)注意训练集切分时用了stratifyy保持正负样本比例一致这是分类问题的基本素养。3.3 初始化TPOT实例并fit核心代码也就几行from tpot import TPOTClassifier tpot TPOTClassifier( generations5, population_size20, offspring_size20, cv5, scoringroc_auc, verbosity2, n_jobs-1, random_state42, max_time_mins10, ) tpot.fit(X_train, y_train)verbosity2会在终端打印每一代的进化日志你会看到类似这样的输出Generation 1 - Current best internal CV score: 0.971... Generation 2 - Current best internal CV score: 0.973... ...“internal CV score”是指当前种群中最优个体在交叉验证上的得分。因为是遗传算法这个分数不一定单调上升偶尔会倒退但只要整体趋势往上走就是正常的。fit结束后TPOT会在全部训练数据上用最优pipeline结构重新训练一次模型结果保存在tpot.fitted_pipeline_里。这是很多新手忽略的一点TPOT内部做交叉验证只是为了评估个体最终给你的是已经fit好了的模型不是只给你一套结构参数。3.4 查看结果最优pipeline与测试评估fit完之后先看看它选了什么结构print(tpot.fitted_pipeline_)一个可能的输出长这样Pipeline(memoryNone, steps[(featureagglomeration, FeatureAgglomeration(n_clusters10)), (logisticregression, LogisticRegression(C0.5, penaltyl2, solverliblinear))])我实际跑的结果比这个稍微复杂一点但思路一致TPOT找到了一个特征聚合后接逻辑回归的组合这个组合在AUC指标上超过了单独使用RandomForest的baseline。接下来评估测试集效果。这里有个小坑TPOTClassifier.score()方法内部调用的是最优pipeline自身的.score()也就是默认返回准确率即使你把scoring设成了roc_aucscore方法打印的仍然是accuracy。想拿AUC就得自己用predict_proba算from sklearn.metrics import roc_auc_score y_pred_proba tpot.predict_proba(X_test)[:, 1] auc roc_auc_score(y_test, y_pred_proba) print(fTest AUC: {auc:.4f})这一步很多人会看懵但原理很简单scoring参数控制的是进化过程中的适应度计算而score()方法是模型自带的评分函数两者不是一回事。所以你要严格按业务指标评估就自己写评估代码别偷懒。3.5 回归场景TPOTRegressor回归问题的用法几乎一模一样只需要换成TPOTRegressor然后注意scoring要选回归指标比如neg_mean_squared_error、neg_mean_absolute_error或r2。这里有个方向性的细节sklearn的scorer里MSE这类越小越好的指标会取负值变成越大越好所以你会看到neg_mean_squared_error别理解错了。4. 把TPOT调明白五个直接决定搜索质量的关键参数跑通demo之后就该认真琢磨参数了。TPOT暴露的参数不算多但每一个都对搜索过程和最终效果有直接影响。下面这几个是我在实际项目里反复调整过、最有心得的部分。4.1 时间预算max_time_mins和max_eval_time_mins怎么配TPOT默认是没有时间上限的。默认配置下generations100、population_size100也就是要评估10000条pipeline每条做5折交叉验证意味着要做5万次模型训练。小数据集可能几十分钟稍微上点规模的数据就是挂机几小时起步。所以真实项目里第一个要设置的参数是max_time_mins它控制整个搜索的总时长上限。第二个参数max_eval_time_mins更隐蔽但更重要它限制单条pipeline评估的最长时间。为什么要限制单个个体因为遗传编程会在种群中随机产生一些极端组合比如超大n_estimators的RandomForest配上高维PolynomialFeatures在数据量大的情况下可能要fit好几分钟。如果不加限制整个搜索会被少数几个怪物个体拖死。合理做法是先设个值试一次比如max_eval_time_mins3再根据日志里实际出现的超时情况调整。我自己的经验公式是max_time_mins给30到120分钟作为首次搜索预算max_eval_time_mins设置为总预算的1/20到1/50左右避免单点拖垮全局。这两个值没有标准答案跟数据量强相关先跑一次看日志再定。4.2 种群与代数population_size、generations、offspring_size的配合这三个参数共同决定了搜索覆盖的空间大小。默认值分别是100、100、NoneNone表示等于population_size。计算总评估次数有个粗略公式总评估数 ≈ population_size generations × offspring_size在每代都生成offspring_size个新个体、且父代不重复评估的前提下成立。假设population_size100、generations100、offspring_size100那就是10000条pipeline评估每条再乘上cv折数如5就是50000次模型训练。可想而知这个搜索空间是完全够用的但时间也够呛。我的建议是先用小配置验证数据链路再放大搜索规模。比如第一次跑generations5, population_size10确认数据没毛病、输出都正常再上generations50, population_size50这种正式配置。反过来一上来就默认值跑了两小时发现数据预处理有问题心态很容易崩。4.3 变异率和交叉率TPOT里有点反直觉的默认值通常说到遗传算法直觉是交叉率该高一点比如0.8变异率该低一点比如0.1。但TPOT的默认值正好反过来mutation_rate0.9crossover_rate0.1。我当时看到这个默认值也很疑惑后来想明白了一件事pipeline树和传统遗传算法里的定长染色体不一样树结构复杂随意的交叉很容易产生两个父本都不具备的语义断裂比如把PCA子段接到需要原始特征语义的模型下面结果可能并不好。而变异是单点操作改动可控更适合在树结构上做细粒度探索。所以我不建议轻易去改这两个值。如果真要调我试过mutation_rate0.8, crossover_rate0.2效果跟默认值差别不大还增加了不稳定性。对于普通场景信任默认值就好把精力花在搜索空间和时间预算上更划算。4.4 scoring与cv别让默认的accuracy坑了你scoring是决定进化方向的关键参数默认值是分类用accuracy、回归用r2。这两个默认值在类别均衡的数据上是合理的但只要出现类别不平衡accuracy就是个灾难性的指导指标。比如一个99%是负样本的欺诈检测数据集你什么都不干全预测成负样本accuracy就是0.99TPOT会认为这个什么都不干的pipeline是优秀的然后朝错误方向进化。对于不平衡分类我常用的scoring选择是场景推荐scoring二分类关注少数类识别f1、roc_auc多分类各类别样本不均balanced_accuracy业务更关注召回f1_macro、recall_macro回归关注大误差惩罚neg_mean_squared_error回归关注绝对值误差neg_mean_absolute_error回归关注解释能力r2cv默认是5表示交叉验证折数。折数越大适应度估计越稳定但评估次数也线性增加。我通常保持默认5数据量很小几千行时改成3节省时间数据量大且时间充足时改成10更稳妥。4.5 config_dict自定义搜索空间加速收敛默认搜索空间很大算子多、参数多好处是覆盖率广坏处是搜索慢。有些场景下你其实能提前排除一大批算子——比如你已经知道数据是稀疏高维的KNN这种基于距离的模型大概率没戏又比如你线上推理环境对延迟敏感堆叠模型、超大随机森林不能考虑。这时候用config_dict自定义搜索空间能把时间集中在真正有希望的候选上。config_dict是一个字典键是算子所在模块路径值是该算子的超参搜索范围。拿TPOT自带的配置做基础再裁剪就行from tpot.config.classifier import classifier_config_dict my_config { sklearn.ensemble.RandomForestClassifier: classifier_config_dict[sklearn.ensemble.RandomForestClassifier], sklearn.linear_model.LogisticRegression: classifier_config_dict[sklearn.linear_model.LogisticRegression], sklearn.preprocessing.StandardScaler: classifier_config_dict[sklearn.preprocessing.StandardScaler], sklearn.decomposition.PCA: classifier_config_dict[sklearn.decomposition.PCA], } tpot TPOTClassifier(config_dictmy_config, ...)注意config_dict传进去是整体替换默认配置不是叠加。所以你想保留哪些就得手动一一挑出来。这个操作把搜索空间从几十个算子压缩到三四个跑出来的速度会快一个数量级。等你有思路了再把其他算子一点点加回去。顺带提两个实用技巧warm_startTrue可以让TPOT在已有点种群基础上继续搜索适合搜到一半发现时间不够、想接着跑的场景periodic_checkpoint_folder会定期把进化中间状态存到磁盘程序中断后还能恢复长任务必备。5. 从Jupyter到生产导出pipeline之后的事很多教程讲到tpot.export(pipeline.py)就结束了但实际上导出只是第一步。工程化部署时你会发现TPOT导出的文件并不直接能上线跑需要二次加工。5.1 export导出的不是模型文件是模板代码tpot.export()导出的.py文件里包含的是最优pipeline的构造代码、一堆import语句以及一段用于演示训练的模板代码。它的典型结构长这样import numpy as np import pandas as pd from sklearn.linear_model import LogisticRegression # NOTE: Make sure that the outcome column is labeled target tpot_data pd.read_csv(PATH/TO/DATA.csv, sepCOLUMN_SEPARATOR, dtypenp.float64) features tpot_data.drop(target, axis1) training_features features.copy() training_target tpot_data[target].copy() exported_pipeline LogisticRegression(C0.5, penaltyl2, solverliblinear) if hasattr(exported_pipeline, fit): exported_pipeline.fit(training_features, training_target)你需要理解两点导出的是代码模板不是序列化模型对象。模型参数是定好的但模型还没在数据上fit。模板里的pd.read_csv和target列只是为了方便你在本地快速验证生产环境通常用不上。所以我从来不会直接把导出文件扔到线上而是把它当成一份模型结构说明书。5.2 把导出的代码接入训练与预测流程我的标准做法是把导出的estimator拿来作为Pipeline的最后一步外层再加上自己管理的数据清洗和特征工程。假设我前期做了缺失值填充和类别编码那么在预测时也要保证做同样处理所以干脆全部封进同一个Pipelinefrom sklearn.compose import ColumnTransformer from sklearn.impute import SimpleImputer from sklearn.pipeline import Pipeline # 1. 外部数据清洗和编码 preprocessor ColumnTransformer([ (num, SimpleImputer(strategymedian), numeric_cols), (cat, Pipeline([ (impute, SimpleImputer(strategymost_frequent)), (onehot, OneHotEncoder(handle_unknownignore)), ]), categorical_cols) ]) # 2. 中间层TPOT导出的模型结构 model_from_tpot LogisticRegression(C0.5, penaltyl2, solverliblinear) # 3. 组合成完整pipeline full_pipeline Pipeline([ (preprocess, preprocessor), (model, model_from_tpot), ])这样训练和预测走的都是同一套逻辑不会出现训练时清洗了线上忘了清洗的低级事故。TPOT导出文件里可能还包含它自己搜索到的预处理步骤比如前面例子里看到的FeatureAgglomeration这些已经在model_from_tpot内部了不用重复加。5.3 模型持久化、特征名管理与稳定性复查模型持久化直接用joblibimport joblib joblib.dump(full_pipeline, production_model.pkl)线上加载预测时要注意如果TPOT搜出来的pipeline里包含PCA一类会把特征投影到新空间的算子你没法用原始特征名直接解释结果也不用太纠结。但输入特征列的顺序必须和训练时一致否则预测结果会错得悄无声息。我踩过一次这类坑线上环境重跑特征工程时列顺序变了模型不报错AUC却直接崩了查了半天才发现是列顺序问题。建议训练完立刻把特征列顺序存成单独的文件with open(feature_order.json, w) as f: json.dump(list(X_train.columns), f)上线前再做一遍稳定性复查。我一般会做两件事一是用测试集做bootstrap重采样看AUC或F1的区间是否稳定二是画学习曲线看训练集和验证集的差距是不是过大。如果TPOT搜出来的模型在训练集上明显过拟合我会把它打进候选黑名单重新限制搜索空间再跑一次。5.4 关于重新训练机器学习模型上线后不是一劳永逸。我习惯把TPOT当成自动重训脚本的一部分每周或每月定时跑一次。做法很简单固定random_state、固定数据版本、固定config_dict跑完自动对比新老模型的线上表现只有新模型明显更好才切换。这里的关键是每次重训的数据口径要一致否则你很难分清性能变化是数据变了还是模型变了。6. 使用TPOT绕不开的坑我的踩坑排查记录工具用久了坑就慢慢现原形了。下面这几个问题是我和同事在真实项目里踩过、并且花了不少时间排查的写出来帮你省点时间。6.1 类别特征与缺失值TPOT不管你必须自己办TPOT的默认搜索空间里没有专门的类别编码器和缺失值填充器它的OneHotEncoder操作只对数值编码后的输入有效而SimpleImputer在默认配置里也不出现。所以你把带字符串类别列或空值的数据直接传给TPOT它要么直接报错要么在内部计算时悄悄出错。正确流程是先用sklearn的预处理模块把数据整干净再交给TPOT。我习惯在交给TPOT之前就把预处理做完from sklearn.impute import SimpleImputer from sklearn.preprocessing import OneHotEncoder from sklearn.compose import ColumnTransformer preprocessor ColumnTransformer([ (num, SimpleImputer(strategymedian), numeric_cols), (cat, OneHotEncoder(handle_unknownignore), categorical_cols), ]) X_processed preprocessor.fit_transform(X)然后再TPOTClassifier().fit(X_processed, y)。这样TPOT专注搜pipeline结构数据层面的脏活由外部代码负责。等导出模型时再把preprocessor和导出的model串成一个大Pipeline。说白了TPOT的职责是在干净数据上找到最优建模路径不是把脏数据洗干净。6.2 关于结果复现random_state、n_jobs和第三方库的随机性设置random_state42是复现的第一步但不保证每次都一样。原因有两个。第一当n_jobs大于1时TPOT用多进程并行评估种群不同进程的运行顺序和调度有随机性可能导致结果波动。第二搜索空间如果包含xgboost或lightgbm这两个库内部有独立于TPOT的随机种子TPOT的random_state不会自动传递到它们内部。我的建议分场景处理。如果只是快速探索random_state42, n_jobs-1没问题速度快结果略有波动可接受。但如果要出最终报告或严格复现我会专门跑一次random_state42, n_jobs1的确认实验并且pip freeze锁住所有依赖版本。在这个条件下结果基本是可复现的。6.3 关于n_jobs-1并行开满不一定是好事n_jobs-1表示用满所有CPU核心听上去很美但实际项目里至少两次让我差点把机器跑挂。TPOT的并行不是简单的重复跑每个worker都会复制数据在数据量大、pipeline里包含XGBoost这类内存大户时内存会成倍膨胀。而且交叉验证本身也会尝试并行多个层级叠加起来资源消耗远超预期。现在我的习惯是先看机器内存和数据量数据几千行、模型都偏轻量放心n_jobs-1数据几十万行、特征又多我会限制n_jobs4或8同时配上max_eval_time_mins作为兜底。另外TPOT打印日志时会显示每代进度如果发现某一代迟迟不动优先怀疑是有怪物个体在超时运行用max_eval_time_mins限制它就好。6.4 不平衡分类的scoring选择上面4.4提到过不平衡分类必须改scoring这里补充一个我在实践中的完整思路。假设我在做一个流失预测项目正样本比例只有5%我一开始用默认的accuracy跑TPOT给的pipeline清一色预测不流失AUC只有0.5但accuracy高达0.95看起来好像还行。后来把scoringroc_auc跑出来AUC到了0.8才算是真正找到有区分能力的模型。有一点要额外注意TPOT搜索空间里的分类器默认不带class_weight超参所以它不会自己通过调类别权重来处理不平衡。要处理类别不平衡要么先在外层做重采样比如SMOTE再把重采样后的数据传给TPOT要么事后把导出的pipeline里的模型换成带class_weight的版本。我一般倾向后者因为SMOTE之后再接TPOT导出的pipeline结构会带上重采样的外部依赖上线时多一层复杂度。7. 我在实践中的几条朴素经验写到这正文该讲的基本讲完了。最后分享几条不算技术、但真影响项目走向的经验。第一TPOT最适合当快速baseline生成器而不是最终模型迷信对象。我现在的标准工作流是先手动写一个业务上可解释的简单模型作底然后跑TPOT用它的结果看上限在哪。如果TPOT跑出来的复杂pipeline只比简单模型高1个点我会直接选简单模型因为它上线后更稳、更容易排查。如果差值超过5个点说明特征加工和模型组合确实有潜力再投入时间深挖。第二数据清洗永远是第一步。TPOT对脏数据的容忍度很低类别列、空值、异常值最好在你调用TPOT之前就处理完。别指望AutoML帮你搞定数据工程它只能帮你搞定建模搜索。第三搜索规模要循序渐进。我第一次用TPOT时一上来就默认参数跑大几万行的数据挂了四个小时只跑到第37代中间还因为内存不足崩了一次。后来改成先小配置跑通、再放大效率和心态都好了很多。建议初次接触时先用generations5, population_size10, max_time_mins10这种小配置跑通流程确认数据、代码、输出都没问题再上正式搜索规模。第四如果你做好了以上所有事TPOT还是会出一些让你哭笑不得的组合——比如给线性模型加PolynomialFeatures导致维度爆炸或者给树模型套一层无意义的StandardScaler。这时不用怀疑自己直接在config_dict里把不合适的算子砍掉再跑一次就行。遗传编程本来就是在乱中取胜你要做的是给它划定一个合理的边界。就这些。如果这篇对你有帮助或者你在用TPOT的时候遇到了我没提到的坑欢迎在评论区补充咱们一起把这份使用指南补完整。
