第36名方案（以及“本可以是”第22名的方案）
作者: Moiz Saifee (Master) | 团队: String Matchers | 排名: 36th
祝贺所有的奖牌获得者以及所有在这次比赛中学到新东西的人。感谢组织者和Kaggle举办这次比赛。
我们选定的方案让我们获得了第36名，但我们有一个提交方案，如果当时选了它，我们本可以获得第22名（没有遗憾，这都是游戏的一部分）。以下是关于我们方案的高层级概览和一些细节。
概览
- NER模型： 使用Roberta作为骨干网络，利用新旧比赛数据进行训练：约 0.5x / 0.3x。我们做的一个改进是——我们在训练NER时采用了双重目标：除了预测NER标签（开始/中间/结束）外，还预测句子中包含数据集的概率。与仅使用单一NER目标相比，这似乎有所帮助。
- 集成模型： 使用类似流程但不同骨干网络（如Scibert, Conll, Biobert）的集成：约0.56 / ~0.414（这是我们没选的那个方案）。
- 集成 + 后处理： 在本地和Public LB（公开排行榜）上有效但在Private LB（私有排行榜）上无效的后处理：约0.56x / 0.368（我们选定的方案 - 1/2）。
- 集成 + 后处理 + 字符串匹配： 使用数据集列表进行字符串匹配：0.640 / 0.363（我们选定的方案 - 2/2）。
详细细节
- 训练和评分是在句子级别进行的，使用Spacy Sentencizer提取句子。
- 在测试出版物中，仅对通过正则表达式提取出的约10%的句子进行了评分，以便在笔记本分配的时间内运行4个模型的集成。这导致验证集和LB上的准确性没有显著下降。（感谢我的队友 @soloway）
- 有一些数据集在新旧训练数据中有大量的出版物，这导致本地CV（交叉验证）不稳定。为了解决这个问题，每个数据集仅使用5-10篇出版物进行训练/验证。
- 字符串匹配似乎在Public LB上有效，但在Private LB上稍微拖了我们的后腿。我们知道这个风险，所以我们要么选定的2个方案中只有1个包含了字符串匹配。