引言：

本次竞赛吸引了创纪录数量的参与者。
社区非常活跃。讨论富有成效，创造了一个促进学习和分数快速提升的协作环境。金牌/银牌笔记本和讨论的数量本身就说明了这一点。

这对我来说不是一段轻松的旅程。我花了近5个月的时间来完善表格竞赛的解决方案流程。有几次我曾位列公共排行榜第一，但未能经受住排名波动。还有几次我选择了错误的提交。这些经历让我吸取了教训，也让我明白："如果方法扎实，你就不需要一天提交5次。"

解决方案：

背景：

从竞赛一开始，我就发现模型的性能会受到一个非常重要的特征的限制。我在这里发布了讨论，展示了从原始数据集合成产生了多少方差。无论集成模型多么优秀，都无法提供我获得的获胜优势。

早期发现：

在模型验证的早期阶段，我发现模型在某些明显的预测上表现不佳。
最常见的错误是yield == 1945.53061。您可以在附件作品中看到这一点。
我注意到，对于train和origin都相同的fruitset和fruitmass值0.335339 0.233554，无论什么模型，其预测值始终是1945.53061。所以我将这些预测值指定为1945.53061，并观察OOF（袋外验证）的表现。正如您所想，效果非常好。

后来我又发现了几个类似的例子，您会在笔记本的第一阶段校正中看到它们。

自动化过程：

我意识到手动搜索不可扩展，因此编写了一个完整的脚本，用于遍历train和test中常见的fruitset和fruitmass值。测试集共有2073个样本。
但应该分配什么值呢？很简单，我迭代遍历了所有唯一的776个yield值，观察哪个效果更好。虽然这改善了OOF表现，但在排行榜上表现不佳，所以我最终采用了原始数据集中的值，这效果就像一颗核弹（我将在后续继续用这个类比）。

策略：

我决定采取缓慢推进的策略。第二阶段的后处理包括按风险程度排列的不同提交版本瀑布流。
我根据国际核事件分级表对它们进行命名，其中anomaly（异常）仅指1945.53061的修正。
然后您可以使用这些代码行进行更深入的修正：

if len(dsp_train) > 2 and len(dsp_test) > 1:
	if not dsp_origin.empty:
		orig_value = dsp_origin['yield'].values[0]
		tr_idx = train.loc[train.fruitset.eq(txt[0]) & train.fruitmass.eq(txt[1]), 'pred'].index.tolist()
		te_idx = test.loc[test.fruitset.eq(txt[0]) & test.fruitmass.eq(txt[1]), 'pred'].index.tolist()

len(dsp_train) > 2 and len(dsp_test) > 1：意味着在train中至少要有两个以上的共同记录，在test中至少有一个，在origin中也至少有一个。

Serious Incident（严重事件） : > 4 > 3
Zone With consequences（后果区）: > 3 > 2
Dangerous Zone（危险区）: > 2 > 1
Ground Zero（零点区）: > 1 > 0 (未提交)

在私人排行榜上失败的风险很大，这就是为什么您稍后在提交截图中会看到_private_600后缀的原因。