你的 AI 助手写好了代码,谁来检查那些默认配置?

让编码助手写一个随机森林，再看看它给出的那四行代码：导入正确，估计器完成了拟合，预测结果的形状也符合预期。现在看看那些没人指定的参数吧——因为这四行代码悄悄替你决定了比你的提示词更多的事情。

每棵树应该考虑多少个特征？模型应该施加多少正则化？验证折应该如何反映你的数据结构？这就是默认配置的作用：它们让一个描述不清的请求变成一段可执行的程序。

语言模型通过“下一个 token 预测”来学习代码的模式，这使得那些我们熟悉的写法天然成为生成的起点。当一段实现省略了某个参数时，库会替它补上取值，于是统计意义上的选择便在从未进入对话的情况下，悄悄进入了你的流水线。

助手在受到提示时可以审查这些选择，但拿到能运行的代码并不意味着这些选择已经被审查过。这种省略之所以容易被忽略，恰恰是因为没有任何东西会因此报错。

下面这五个默认配置，是我在自己的生产工作和同事的项目中都遇到过的——它们之所以引发调试噩梦，是因为我们都忽视了代码到底在做什么。每一条都值得问同一个问题：省略这个参数，到底替我决定了什么？

1. RandomForestRegressor(max_features=1.0)

如果你学随机森林时记住的是“对行做自助采样、对特征做子采样、再对树做平均”，那么默认的回归器会给你一个意外：RandomForestClassifier 用的是 max_features="sqrt"，而 RandomForestRegressor 用的是 max_features=1.0，意味着每次分裂时所有特征都可用！

这个差异关闭了“特征子采样”——正是这一步把常见的随机森林配方与普通装袋法（bagging）区分开来。自助采样依然存在，所以各棵树因为拿到的行不同仍然具有随机性，但第二层随机性（刻意限制每次分裂可以考虑哪些特征）却消失了。

为什么这很重要？想象一个数据集里有一个特别强的预测变量，比如销售模型中的价格或折扣。即便每棵树拿到的是不同的自助样本，价格仍可能持续赢得早期的分裂，因为它的预测信号在训练行发生变化时依然保留。因此这些树可能发展出相似的结构，并对训练数据的波动做出相似的反应，从而限制了“平均”能在多大程度上降低它们共同的方差。

特征子采样会偶尔把主导性预测变量排除在考虑之外，从而打断这种重复，迫使各棵树去探索其他的分裂方式。我在 TDS 文章《Why Random Forest Needs to Be This Random》中拆解了其中的数学原理并做了一个受控实验，其核心结论是：增加更多的树，无法消除与树之间的相关性相关的那部分方差。

在 max_features=1.0 下，你让那套额外的去相关机制闲置着，尽管这个估计器的名字可能让你以为它已经在起作用了。例如，设置 max_features=0.33，可以让每次分裂时大约三分之一的特征可用，从而恢复随机森林配方的这一部分。

该向你的助手提的问题是简单的：如果我们选择随机森林，部分原因就是为了特征层面的随机性，那我们又为什么让这层随机性处于关闭状态？

2. LogisticRegression(C=1.0)

如果你要一个逻辑回归，你大概期待得到一个能找到“最好解释观测结果的系数”的模型。但 LogisticRegression() 实际拟合的是一个正则化版本：它带有一个惩罚大系数的 L2 惩罚项，以及一个默认 C=1.0 来决定这个惩罚项与拟合数据之间的竞争强度。

正则化通常是有用的，尤其是当数据有噪声或预测变量相互重叠时；但数字 1.0 对你的具体问题一无所知。较小的 C 施加更强的正则化，较大的 C 则给系数更多自由，而省略这个参数，就等于不假思索地接受了某一个特定设置。

除了这一点，还有一个更微妙的问题：“大系数”取决于你如何度量这个特征。假设收入以欧元记录，其系数是 0.0001。用“千欧元”表示同样的收入，那么系数必须变成 0.1，才能对预测保持完全一致的惩罚贡献：

50,000 × 0.0001 = 50 × 0.1 = 5

信息没有变，但系数现在变大了 1000 倍，因此它对 L2 惩罚项（对系数平方）的贡献就大了 100 万倍。当你用同样的 C 重新拟合模型时，优化器面对的实际上是一个不同的权衡，而原因仅仅是你改了单位。

一个务实的起点是在 Pipeline 内部对连续特征做标准化，这样预处理会在每个训练折内拟合，然后再用合适的验证去调优 C。否则，你选择“欧元”还是“千欧元”，就会在不知不觉中帮你决定了每个特征接受多少正则化。

3. cross_val_score(model, X, y, cv=5)

五折交叉验证听起来像是一种令人安心的彻底检查：用数据的四部分训练，在第五部分上评估，然后重复，直到每个观测都被留出过一次。但 cv=5 只指定了折数，同时悄悄地把另一个决定留给了 scikit-learn：这些折是怎么构造的。

对于回归，它使用 shuffle=False 的 KFold，意味着验证折是现有顺序中连续的行块。如果你的 dataframe 是按日期、客户或地区排序的，那么这种顺序就成了你评估设计的一部分——无论你是否本意如此。

考虑 100 周按时间顺序排列的销售数据。第一折在训练了第 21–100 周后，评估第 1–20 周，于是模型是用更晚的观测来预测更早的观测。代码运行得完美无缺，但这个实验并不代表预测（forecasting）——在预测中，预测未来时只有过去是可用的。

简单地加上 shuffle=True 仍然会把过去和未来在训练集和验证集之间混在一起，这正是为什么正确的切分器取决于“未见数据”对你的具体问题意味着什么。对于行顺序无关紧要的独立观测，打乱的 KFold 是一个合理的选择；对于预测任务，应使用基于时间的切分方案，在更早的观测上训练、在更晚的观测上评估；对于关于新客户的预测，应使用分组切分器，让每个客户完全留在训练—验证边界的同一侧。

对于普通的二分类或多分类问题，scikit-learn 改用 StratifiedKFold，大致保持各类别比例，但默认仍然不做打乱，也不会自动尊重客户分组或时间。

通过传入 cv=5，你选择了要把模型评估多少次，却把评估的结构留成了隐式的。你的助手可以给出一个合法的交叉验证调用，但你仍然需要定义模型应该能泛化到什么。

4. KMeans(n_init="auto")

单词 "auto" 听起来令人安心，尤其对于一个控制算法“尝试寻找好解的次数”的参数而言。你大可以置之不理，假定库会替你做这个决定；但在默认的 init="k-means++" 下，n_init="auto" 精确意味着只完整运行一次。

要理解为什么这重要，请回想 KMeans 的工作原理：它从一组初始簇中心开始，把每个观测分配给最近的簇中心，然后不断迭代更新这些中心直到收敛。中心从哪里起步，会影响它们最终停在哪里，因为算法可能陷入一个局部最优，而进一步的迭代也无法跳出。

多次初始化通过从不同起点重复整个流程来应对这个问题。在 n_init=10 下，KMeans 执行 10 次运行，并保留惯性（inertia，即观测与其所属簇中心之间距离平方和）最小的那一次。

默认的 k-means++ 初始化比简单随机选择更谨慎地挑选起始中心，这使得单次运行成为一个更合理的计算捷径，但它并不保证另一种初始化不会产生更好的解。"auto" 设置遵循一条基于初始化方法的固定规则；它不会检查你的结果、然后不断重启直到结果看起来稳定。

增加 max_iter 无法补回那些缺失的重启，因为它只是在每次运行内部允许更多次更新。类似地，设置 random_state=42 让初始化可复现，于是你可以稳定地回到同一个解——却无从获知另一个起点是否会带来改进。

如果你想要多次尝试，请显式地用诸如 n_init=10 这样的取值来请求，并承担由此带来的额外计算。否则，你继承的这个“自动选择”，就是接受一次初始化的结果，而不把它与其他起点做比较。

5. SimpleImputer(keep_empty_features=False)

你把 SimpleImputer() 加进流水线，期望它去填补缺失值，但它的默认值也允许它删除整列。在默认的均值策略下，任何在拟合期间“只包含缺失值”的特征都无法计算均值，于是这个 imputer 会把它从转换后的输出中剔除。

想象一个含 20 个特征的训练数据集，其中包括一个在所有训练观测中都从未被记录过的测量值。imputer 删掉那一列，下游模型就在剩下的 19 个特征上训练，尽管你可能仍然把你的流水线当成“20 个特征”的模型来想。

现在新数据到了，那列之前为空的列里出现了真实取值。拟合好的 imputer 仍然会删掉它，因为这个决定是在训练阶段确立的；新的测量值永远不会到达模型。

你大概预期会看到一个特征数量错误，但一个一致的流水线不会产生任何错误：模型在训练时接收了 19 个特征，在预测时也接收同样的 19 个。一切正常运行，这就使得这个变化很容易被忽略——如果你只在预处理之前检查数据的话。

这种情况也可能发生在交叉验证内部：某个稀疏填充的列，可能在某一个训练折中完全缺失，尽管它在数据集的其他地方含有取值。

设置 keep_empty_features=True 会保留这些列，并在默认均值策略下用零来填补它们的缺失值。这保留了特征结构，但它无法教会模型一个在训练数据中并不存在的关系，所以保留这一列并不会自动让它未来的取值变得有用。

关键在于，去审视你的预处理实际向下游传递了什么，包括输出的特征名和形状。一个为了填补缺失项而引入的步骤，同样可以决定哪些特征得以留存，而一次成功的 .predict() 调用并不会告诉你某个特征消失了。

核心要点

这些都不是 bug，而且这些默认配置的存在都有充分的理由，从计算效率到让常见工作流更易运行。麻烦始于我们在没有注意到它们所做的选择时就接受了它们——尤其是当代码干净利落地执行、输出看起来完全合理的时候。

这些都是我在生产工作中亲身遇到的行为，无论是在我自己的流水线里，还是在同事的项目里，而且它们造成的调试麻烦，远超其在代码中那小小的存在感所暗示的程度。当你在排查数据、模型以及任何其他能解释意外结果的因素时，一个被省略的参数很容易被忽略。

编码助手让这些省略更容易被一路带下去，因为一个熟悉的写法可以在我们就其背后的假设展开讨论之前，就已经完整地呈现在我们面前。助手可以帮忙审查这些假设，但一句“写段代码”的请求，并不能保证会有一场关于行顺序、初始化、或哪些东西能挺过预处理的对话。

这正是经验仍然重要的地方：识别出哪些看似常规的选择值得再看一眼，并在拿到实现的同时，要求对默认配置做出解释。有时正确的结果就是保留默认，但要清楚地理解它为什么合适。

这项工作从来不只是敲出那四行代码；它在于知道那四行代码留下了哪些尚未回答的问题。