这绝对是我们想要的功能。 问题是：实现它的最佳方式是什么（就 API 而言）？
在 adaboost pr:#522 中有一些类似的东西。 这实现了使用估计器的子集进行预测，这也非常有帮助。

您认为用户想要fit_extend的场景/代码是什么样的？ 它可能在交互式环境中最有用，对吧？

SGD 中有一个稍微相关的函数partial_fit 。 不过，这实际上是针对在线学习的，因此它会获得不同的数据。

我想通过添加尽可能少的 API 名称来获得此功能；）

顺便说一句，我不会散列X和y 。 我认为没有理由强迫用户提供相同的输入数据。

我想一次训练少量的子估计器（并等待相对较短的时间）。 然后在我的交叉验证集上测试它，如果我的 cv 分数仍然下降，我可以继续训练。 而不是训练大量的子估计器并等待很长时间（对我来说是几个小时）。 那是我的动力。

我可以理解对添加另一个实例方法犹豫不决。 我认为向 fit() 添加另一个可选参数可能是值得的，但我在贡献页面上看到了这个引用。

拟合参数应限制为直接数据因变量

所以我不确定这是否是个好主意。 将

def fit(self, X, y, n_estimators=self.n_estimators)

可以接受吗？ 然后如果n_estimators > self.n_estimators ，我们将训练更多的估计器。

我同意在预测方法中添加 n_estimators 参数很好，但我想你会同意它解决了一个不同的问题。 对于我的问题，在 n_estimators 上执行网格搜索并不是一个真正的选择，因为它需要很长时间。

在我们就合适的界面达成一致之前，您可以使用以下 hack：

# Train a forest of 10 trees
clf1 = RandomForestClassifier(n_estimators=10)
clf1.fit(X, y)

# Train a second forest of 10 trees
clf2 = RandomForestClassifier(n_estimators=10)
clf2.fit(X, y)

# Extend clf1 with clf2
clf1.estimators_.extend(clf2.estimators_)
clf1.n_estimators += clf2.n_estimators

# clf1 now counts 20 trees

请注意，这只适用于 RandomForest 和 ExtraTrees。 Gradient Boosting 不能使用相同的技巧。

参见#1626。 提前停止对您来说是一个可以接受的解决方案吗？

@amueller我在这里与@glouppe有着相同的观点https://github.com/scikit-learn/scikit-learn/issues/1626#issuecomment -12785168。 我喜欢提前停止，但我认为这并不能解决这个问题。

好的。 然后我们应该寻找一种解决方案，允许提前停止并添加额外的估计器。

再想一想，我认为partial_fit方法将是正确的接口。 在 SGD 中，您可以使用相同的数据或新数据调用partial_fit ，它会不断学习。 不同之处在于，在 SGD 中，如果您手动迭代批次，则会得到原始算法。 对于合奏来说，这是不正确的。 您需要在每次调用partial_fit时使用全部数据。

再想一想，我认为 partial_fit 方法是正确的
界面。

我喜欢这个建议。 其他人怎么想？

只是为了澄清一下，在合奏的情况下， partial_fit究竟会发生什么？ 这会增加n_estimators更多的估计器，其中n_estimators是来自构造函数的参数值吗？ （或者我们可以改变这个值吗？）

好问题。 我也想过 ;) 实际上，你会想要改变它，对吧？ 之后你可以通过set_params更改它，但这感觉很尴尬：-/

很抱歉这么晚才加入讨论。

我同意我们需要这样的功能，但是，我不确定fit_extends是否是@jwkvam描述的问题的最佳解决方案。 为了提前停止，用户必须编写一些基本上重复调用fit_extends的代码，然后检查 CV 错误。

我宁愿提出我们过去讨论过的monitor拟合参数： est.fit(X, y, monitor=some_callable)其中some_callable将在每次迭代后被调用，并传递估计器的完整状态。 可调用对象也可以返回一个值，不管训练是否应该继续。

使用这样的 api 不仅可以实现提前停止，还可以实现自定义报告（例如交互式绘制训练与测试分数）和快照（所有 X 迭代转储估计器对象并将其复制到某个位置；如果您正在运行，这很棒在 EC2 现场实例或其他一些不可靠的硬件上；-)

然而，即使有这样一个monitor API，我认为一旦模型被拟合（即fit_extends ），就需要一个 API 来拟合更多的估计器——通常训练一个模型并且做了一些内省，发现运行更多迭代可能更好 - 现有的估计器使用warm_start参数来实现这样的功能（例如，参见linear_model.ElasticNet ） - 这是参数的文档字符串： ：

warm_start : bool, optional
When set to True, reuse the solution of the previous call to fit as initialization, otherwise, just erase the previous solution.

就个人而言，我更喜欢fit_extends （或fit_more ）而不是warm_start - 热启动非常隐含 - 你必须::

est = GradientBoostingRegressor(n_estimators=1000)
est.fit(X, y)

# now we want to fit more estimators to ``est`` 
# if you forget warm_start=True you nuke your previous estimators - quite implicit
est.fit(X, y, n_estimators=2000, warm_start=True)

# alternatively - more explicit
est.fit_more(X, y, n_estimators=1000)

或者 - 更明确

est.fit_more(X, y, n_estimators=1000)

对我来说， fit_more 确实对应于我们在
其他估计器。

@pprett我认为应该有一种简单的方法来做简单的事情。 监视器 API 非常灵活，但实际上您希望每次使用估算器时都提前停止，对吗？ 所以应该没有必要写一个回调来做到这一点。 此外，它必须与 GridSearchCV 兼容。

对我来说， fit_more 确实对应于我们在
其他估计器。

我不这么认为。 在partial_fit中，“partial”代表对数据的部分访问：您希望数据不能立即放入内存中，因此您一次只能放入一个块，并在扫描数据时逐步更新模型.

在这种情况下，我们希望更改子估计器的数量，但可能希望在每次调用时重用完全相同的数据。

出于类似的原因，ElasticNet 具有warm_start构造函数参数而不是partial_fit方法，并且 SGDClassifier 都具有warm_start参数和partial_fit方法：它们的服务不同目的。

我同意监视器 API 通常非常有用（用于处理快照、提前停止等），但不会解决以交互方式增加子估计器数量的问题。

我们还可以：

est.fit(X, y, n_additional_estimators=1, warm_start=True)

甚至增长 110%（估计数增加 10%）：

est.fit(X, y, additional_estimators=0.1, warm_start=True)

嗯，我没有过多关注我们目前拥有的热启动 API。 没有中央文件，对吧？
我们真的应该考虑文档的组织。 我们在调查中得到了相当多的评论：-/

@ogrisel我必须查看 SGD 实现以查看详细信息，但是热启动和 partial_fit 之间实际发生的情况有什么区别？ 我认为我们同意相同/更改数据的观点。
warm_start做几个 epoch 而partial_fit不做吗？ 这对我来说很有意义，然后我们可能应该将它们分开。
如果我们已经有了热启动 api，我们绝对应该“只是”为集成估计器实现它。

warm_start只是防止拟合忘记先前的状态（假设模型的内部状态可能会使其更快地收敛到具有新超参数的新调用的解决方案）。

2013/1/30 安德烈亚斯·穆勒[email protected]

@ogrisel https://github.com/ogrisel我得看看 SGD
实施以查看详细信息，但有什么区别
实际上发生在热启动和partial_fit之间？ 我想我们同意
相同/更改数据的点。
warm_start 会做几个 epoch 而 partial_fit 不会？ 那会
对我来说很有意义，然后我们可能应该将它们分开。
如果我们已经有了热启动 api，我们绝对应该“只是”
为集成估计器实现这一点。

我认为主要区别在于_语义_：背后的主要思想
warm_start是更快地收敛 - 但不管是什么值
warm_start你有没有得到同样的解决方案！
另一方面，部分拟合改变了基础模型。 考虑
以下示例：

# this is the intended use-case for warm_start is faster convergence

clf = SGDClassifier(n_epochs=10)
clf.fit(X, y)

clf2 = clone(clf)
clf3 = SGDClassifier(n_epochs=10)

clf2.fit(X, y, warm_start=True)
clf3.fit(X, y)

# clf2 and clf3 should converge to the same solution - but since clf3

可以重用来自 clf 的拟合权重，它可能会更快地收敛
# 在后台SGDClassifier.fit重置“训练”状态模式
估计器（sgd 的自适应学习率）

# now partial fit
clf = SGDClassifier(n_epochs=10)
clf.partial_fit(X, y, classes)
# training has not completed yet "training" state (adaptive learning rate) is stored.

clf.partial_fit(X, y)  # resume with previous learning rate

免责声明：这个例子可能是迂腐的，因为术语的不同
学习的权重是最小的 - 但从概念上讲，它们完全是恕我直言
不同的东西...

—
直接回复此邮件或在 Gi tHub上查看 https://github.com/scikit-learn/scikit-learn/issues/1585#issuecomment -12883146。

彼得·普雷滕霍夫

warm_start API 最初是为了在使用正则化器alpha的路径时允许更快地计算一系列相同的线性模型而引入的。 这有点类似于在增强集成模型中迭代地增加子估计器的数量，因此我们可以决定重用warm_start来处理该用例，但如果这个 API 显示增强模型很麻烦，它可能会更好现在重新考虑一下，因为我们有一个额外的用例。

我同意@pprett的分析。

我不知道如何处理@pprett分析。

在线性模型的情况下，估计器将收敛到相同的结果，即使热启动得到的数据与原始拟合不同。 如果我们“热启动”合奏/树木，情况就不会如此。
我们可以尝试确保热启动时提供的数据与原始数据相同。

目前，“热启动”是指一种优化过程，在基于树的方法中没有。
而partial fit保留了估计器的所有状态并继续拟合。

另一方面，随后对批次的部分拟合调用会导致与对整个数据进行训练的模型相同。

同样，这与树/集成案例不同。 我觉得这可以追溯到我的论点，即这更像是一种路径算法，而不是其他任何东西；）

所以我看到了两种可能的解决方案：确保始终使用相同的数据调用热启动，然后添加估算器将是热启动。
如果没有，我们需要第三种方法来重新拟合给定的模型。
顺便说一句，目前的文档在哪里；）

确保始终使用相同的数据调用热启动。

为什么这样？ 让用户决定他/她想如何使用warm_start 。

顺便说一句，目前的文档在哪里；）

http://scikit-learn.org/dev/modules/generated/sklearn.linear_model.ElasticNet.html

warm_start : bool, optional
When set to True, reuse the solution of the previous call to fit as initialization, otherwise, just erase the previous solution.

我同意给予动力会有所帮助，例如在这种情况下：

“这对于有效计算 ElasticNet 模型的正则化路径非常有用，如 :func: enet_path函数所做的那样”。

我认为争论是关于语义的。 我认为语义是通过给用户一定会发生什么的保证来定义的。 这样用户就不需要知道算法的所有细节。
我认为warm_start的保证是“warm_start 不会改变结果”，而partial_fit的保证是“迭代批次不会改变结果”。

如果没有保证，那么我看不出如何有共同的语义。

我们向用户保证，如果他再次使用 warm_start=true 提供相同的数据，他将获得相同的结果（只是更快）。 但是我们不应该阻止用户使用不同的数据，如果他做出明智的猜测，对新数据的热启动将帮助他解决他的问题（例如，如果他假设新数据是合理分布的，则更快地解决新数据类似于第一个数据，因此从前一个位置启动优化器应该会加快速度）。

对于线性估计器是可以的。 但是如果你想在 ensemles 上使用warm_start ，它会突然之间有一个非常不同的语义。

事实上，在不断变化的数据上建立一个增强的集成是很奇怪的并且可能是无用的（除非它是一种为某些元元集成估计器注入一些随机化的方法，它可能对增强模型进行装袋？）。 我认为我们不应该尝试强制数据不会在调用之间发生变化。 让我们在文档字符串中记录该选项的预期使用场景。

好的。 所以基本上文档字符串应该说“除非你确切地知道你在做什么，否则对相同的数据使用warm_start”。
我都可以。 有人反对使用warm_start吗？

不过，我仍然需要看看在 SGD 和 ENet 中是如何处理的……

确实，不断增长的数据变化合奏很奇怪，而且可能毫无用处

不，不是没用：这是一种特定的子抽样策略。 实用的
与在线方法的不同之处在于您希望批量很大。

在 2013 年 1 月 30 日上午 11:42，Peter Prettenhofer 写道：

我认为主要区别在于_语义_：背后的主要思想
warm_start是更快地收敛 - 但不管是什么值
warm_start你有没有得到同样的解决方案！
仔细想想，这是不对的。
在 SGDClassifier 中，如果你用warm_start拟合两次，你肯定会
得到不同的解决方案。 根据您之前所做的，您可能会得到
更好或更差的解决方案，但训练时间将完全相同。

所以SGDClassifier中的warm_start不能用于模型选择。
另一方面， partial_fit可以用来找到最好的
max_iter 。

我想得越多，它就越让我感到困惑：-/

顺便说一句，有什么理由warm_start是一个初始化参数
partial_fit是一个函数吗？
如果partial_fit也是一个 init 参数会不会更容易？

顺便说一句，有什么理由warm_start是一个初始化参数
partial_fit是一个函数吗？

因为partial_fit是一种特定的策略，可能不同于
fit中使用的策略。

如果partial_fit也是一个 init 参数不是更容易吗？

我认为这会令人困惑。 partial_fit的目标是成为
可在核外框架中使用的构建块。 为此使用fit
目的可能导致相当灾难性的结果。

我不明白你的论点。 fit所做的基本上是“忘记模型，调用partial_fit ”。

嗯，也许你的意思是fit可能需要做的工作比partial_fit少，因为partial_fit需要存储先前数据的“足够的统计数据”，而 fit 不需要需要这样做吗？

我不明白你的论点。 fit 所做的基本上是“忘记模型，
调用 partial_fit”。

它可以做得更多。 通常它会在调用部分数据之前对数据进行洗牌
合身。 它还可以将其分成用户可选择大小的小批量。

嗯，也许你的意思是 fit 可能需要做的工作比 partial_fit 少
因为 partial_fit 需要存储前一个的“足够的统计量”
data 和 fit 不需要这样做吗？

可能是这样。 也可能是fit需要做额外的
努力将大批量数据集转换为一组小批量数据集。

嗯，好吧，也许这现在不是那么重要。

我想尽量减少我们在 sklearn 中的机制数量，我们肯定需要一个（更多？）来进行有效的模型选择。 在坐标体面算法中，正是为此目的引入了warm_start选项。 我不确定它是否足以真正做到这一点（如果有多个参数怎么办？）并且它在 SGDClassifier 中不再满足这一要求。

（刚刚删除了很多之前的评论，因为我在重复自己）。

我想尽量减少我们在 sklearn 中的机制数量，我们肯定需要一个（更多？）来进行有效的模型选择。 在坐标体面算法中，正是为此目的引入了 warm_start 选项。 我不确定它是否足以真正做到这一点（如果有多个参数怎么办？）并且它在 SGDClassifier 中不再满足这一要求。

我不明白最后这句话。 warm_start 对 SGDClassifier 完全有效（除了partial_fit ）：现在 SGDClassifier 没有收敛检查/提前停止。 但是一旦有了，warm_starting 就可以更快地计算正则化路径，就像 ElasticNet 一样。

SGDClassifier 执行n_iter次更新，然后停止。 n_iter步骤之后它在哪里结束很大程度上取决于你从哪里开始。
即使您执行“提前停止”，这也将是在验证集上提前停止，而不是提前停止优化。 SGDClassfier 没有将目标完全优化到最后的目标。 所以你最终会在哪里取决于初始化。
特别是，对于提前停止（在验证集上！），最好减少迭代次数，从而降低偏差。

特别是，我认为“alpha 的正则化路径”在 SGD 设置中没有意义。 “路径”是一个最优序列。 SGD 永远不会找到最佳值，因此您最终的位置可能与实际正则化一样取决于学习率的缩放。

特别是，我认为“alpha 的正则化路径”在 SGD 设置中没有意义。 “路径”是一个最优序列。 SGD 永远不会找到最佳值，

对于线性模型，问题是凸的。 如果 n_iter 足够大，具有良好学习计划的 SGD 将收敛到最优（如果在收敛之前不停止）。 接近最优时的收敛速度不如坐标下降，但这是一个不同的问题。

所以我们同意：除非 n_iter 足够大并且时间表恰到好处，否则模型会有所不同——这在实践中不太可能。

此外，“如果其他设置经过适当调整，结果将是相同的”形式的保证听起来并不像保证。

Olivier Grisel [email protected] schrieb：

特别是，我认为“alpha 的正则化路径”不会使
在 SGD 设置中的意义。 “路径”是一个最优序列。 新元将
永远找不到最合适的，

对于线性模型，问题是凸的。 如果 n_iter 足够大，SGD
具有良好的学习计划将收敛到最佳状态（如果您
在收敛之前不要停止）。 得到时的收敛速度
更接近最优值只是不如坐标下降，但是
这是一个不同的问题。

---

直接回复此邮件或在 GitHub 上查看：
https://github.com/scikit-learn/scikit-learn/issues/1585#issuecomment -12958852

Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet。

那么怎么样

clf = RandomForestClassifier(n_estimators=10)
clf.fit(X, y)
print(clf.score(X, y))
clf.set_params(warm_start=true, n_estimators=20)
clf.fit(X, y)

这是可接受的使用模式吗？

还是您希望这些作为fit的参数？ 根据文档，在 SGD 中， warm_start是__init__参数。

让我们重新讨论。 在 #1044 @GaelVaroquaux说他仍然更喜欢partial_fit 。
目前，我认为warm_start的方向更正确，但我没有强烈的意见。 @ogrisel @pprett @glouppe @larsmans你对我上面发布的使用模式有什么看法？ 或者您想拥有另一个使用warm_start或partial_fit的界面？

目前，我认为 warm_start 是更正确的方向，但我没有
强烈的意见。

我不喜欢使用“warm_start”的是目前
与 scikit-learn 估算器的合同是您可以调用“fit”并获得
无论对象的历史如何，一个有效/有用的答案。 它可能会去
更快或更慢，但这有点傻。 如果你通过不同的
数据到集成估计器，并使用“warm_start”来适应更多
估计，你会得到废话。 我担心不得不写
'防御性' 代码来避免此类问题。

partial_fit在我们的设置中如何工作 - 这是正确的::

est = GradientBoostingRegressor(n_estimators=1000)
est.fit(X, y)
...
est.fit_partial(X, y, n_estimators=1000)  # train another 1000

所以它需要任意fit_params或只是n_estimators ？

就个人而言，我赞成使用fit_more ，因为我们当前的partial_fit服务的用例完全不同，而且fit_more更明确。

在合奏的情况下，我对partial_fit这个名字也不是很满意。 从我的角度来看，该名称表明它将根据构造函数中请求的总数构建一些估算器，但不会更多。

如果我们选择warm_start那么规范是什么？ 您在构造函数中设置n_estimators并调用fit追加n_estimators更多估计器？ 就像@amueller上面所做的那样？ 好吧，我并不反对这种模式，但这对我来说似乎不是很直观。

从非常实用的角度来看，我喜欢fit_more 。 这是明确的。 无需解释。 但是，它为我们的 API 添加了另一个功能......

（我还没有强烈的意见，这些言论只是反映了我此刻的想法）

我并不完全反对添加一个功能，但我不希望它特定于合奏。
我确实看到了与路径算法的联系，所以我认为共享一个界面会很好。

考虑以下假设情况（可能不太现实）：
您安装了一个整体，但现在您看到您欠拟合并希望让您的树更深（假设我们实现了它）。 这将是类似路径行为的另一个示例。 你也会通过fit_more做到这一点吗？ 或者添加一个fit_deeper函数？

我想在普遍性和明确性之间存在权衡。

@GaelVaroquaux与partial_fit的合同恕我直言，如果您批量迭代数据，您将得到相同的结果。 如果在这里使用绝对不会是这种情况。 所以按设计我们会违约？！

再想一想，也许我们可以使用一种新方法来实现#1626。
我不介意称它为fit_more ，但在do some more fitting along the parameter path的意义上不是fit additional estimators in the ensemble的意义上。

所以恕我直言，我们应该要么做warm_start （可能是防御性编程），要么添加另一种我们通常可以用来适应参数路径的方法。

那么fit_more会不会是防御性的？ ;)

-1 防守。 我宁愿把它记录好，让用户决定什么
对自己有好处。

2013 年 2 月 11 日 22:14，Andreas Mueller [email protected]写道：

那么 fit_more 会是防守还是不防守？ ;)

—
直接回复此邮件或在 Gi tHub上查看 https://github.com/scikit-learn/scikit-learn/issues/1585#issuecomment -13403244。

我也反对防守。 我只是想知道添加该功能是否真的解决了问题，或者我们是否只是添加了另一种方式来进行热启动。 两者都有相同的防守/非防守问题，对吧？

如果我只是重复已经说过的话，我很抱歉。 但似乎您可以将估计器分为两类：那些一旦拟合就冻结参数（集成，DT），以及那些不适合（线性模型）的估计器。 我的意思是，使用warm_start，您不会重新调整集成的前n 个子估计器或决策树中的现有拆分。 无法使用warm_start 到达集合和DT 的参数空间中的任何位置，这让我认为实例方法更合适。

如果选择了实例方法，是否需要像@amueller指出的那样更通用？ 如果在某个时候有人想要增加子估计器的 max_depth 的能力，那也可以用fit_more()来处理？

对于它的价值，我也会反对防守。 正如@GaelVaroquaux 之前指出的那样，它提供了一种子采样策略，例如，如果您的训练数据不适合主内存。

经过一番思考，我认为我们应该在这里看到更大的图景。 在不久的将来，我想实现可以将任何类型的估计器组合在一起的通用元集合。 我宁愿看到的是一种“组合”机制，它将一个（拟合的）估计器列表作为输入，并产生一个将它们全部组合起来的元估计器。

在实践中，我认为我们可以在不向 API 添加任何新功能的情况下实现这一目标。 例如，可以简单地将这样一个拟合估计器列表传递给元集合的构造函数。

就 API 而言，可以（大致）通过以下方式实现这样的集成：

a) 装袋：

• 构造函数： base_estimator （可选）， n_estimators （>=0），拟合估计器的列表L （可选）。
• fit: 扩展L与n_estimators新的base_estimators实例拟合（引导副本）训练样本。 如果没有给出基本估计量，则相当于组合L中的估计量。

b) 堆叠：

• 构造函数： base_estimator （可选）、 n_estimators （>=0）、拟合估计器的列表L （可选）。
• 拟合：扩展L与n_estimators新实例base_estimators拟合引导样本，然后在估计器的预测上重新拟合模型。

c) 森林：

• 构造函数： base_estimator （可选）、 n_estimators （>=0）、拟合估计器的列表L或森林（可选）。
• fit: 扩展L与n_estimators新的base_estimators实例拟合训练样本。 在这里，我们还可以检查L中的估计量是森林还是决策树。 森林将被夷为平地，以便将所有树木放在同一水平面上。

此外，在这样的框架中，集成的计算可以很容易地分布在多台机器上：构建您的估算器； 腌制它们； 然后将它们重新组合成一个单一的元估计器。 甚至可以将该接口封装到 MapReduce 集群中，而无需深入研究我们的实现！

你怎么看？ 我知道这仅与某种合奏有关。 例如，GBRT 和 AdaBoost（在我看来）更适合warm_restart或partial_fit 。

为了清楚起见，要扩展森林，可以执行以下操作：

forest = RandomForestClassifier(n_estimators=100)
forest.fit()
forest_extended = RandomForestClassifier(n_estimators=100, L=forest)
forest_extended.fit() # now counts 200 trees

该界面的动机是什么？ 我完全支持你支持更多的集成方法。 我只是觉得为 GBRT 和随机森林设置不同的界面是很尴尬的。 我真的看不出这样做的动机。

如果主要动机是分发令人尴尬的并行作业，那么我认为我们应该通过实现更强大的并行化来解决这个问题。 按照您描述的方式进行操作似乎非常手动和hacky。

基本上我觉得你的建议只是解决了一个非常特殊的情况，而大多数情况都没有解决。

好吧...我只是觉得扩展类似增强的合奏和类似平均的合奏是完全不同的事情。

除了并行化之外，您的接口的用例是什么？ 或者更好：在哪些用例中，您需要不同的界面来增强集成和装袋？

用例是当您想将多个估算器组合在一起时。 这对于类似平均的合奏很自然，但在增强的合奏中没有意义。 从这个角度来看，我将“扩展估计器”视为将其与更多基本估计器“结合”。

所以设置是你已经训练了一些 bagging 估计器并且想要将它们组合在一起，对吗？
除了并行化之外，您希望在哪个设置中执行此操作？ 这对我来说不是很清楚，但也许我忽略了一些明显的东西。

在 Stacking 的情况下，估计器可能完全不同（比如你想将森林与 svm 合并）。

（间接地，这也可用于实施二次抽样策略或监控拟合过程。）

我不确定我是否得到堆叠示例。 我会想象，如果我们有一个堆叠接口，您可以指定一个估计器作为基础估计器，另一个作为顶部估计器。

在我看来，堆叠的目的是结合不同性质的估计器的预测。 它们越多样化，通常就越好。

好的，所以基本估计量会有所不同。 但是我们也可以将其构建到堆叠界面中，对吗？

已解决 #2570

@jwkvam我们最近在 #2570 中同意使用warm_start参数来实现此功能。 它现在在 GBRT 中实现。 我将尝试在发布之前使用相同的机制更新森林。

@glouppe你说得对，我忘了我是为任何合奏写的。 但实际上我只是想要 GBRT :) 所以我匆忙决定这个问题已经解决了。 如果你喜欢你可以重新打开它并在完成后关闭它，这对我来说并不重要。