第四名解决方案

首先，祝贺获奖团队。

非常不幸的是，关于查询构建存在一些“魔法”。我在 10 天前才意识到它们，此后花费了大量时间考虑如何使用它们。

我将解释使用“魔法”的解决方案（LB 0.98）和不使用“魔法”的解决方案（LB 0.91）。

使用“魔法”的解决方案 (LB 0.98)

你可以通过以下方式构建查询来节省 AND 令牌。下面示例中的令牌数量为"1"。

ti:"token1"detd:"token2""token3"ti:"token4"'

这等同于：

ti:token1 AND detd:token2 AND token3 AND ti:token4

在我的解决方案中，我将目标专利分为 25 对，并按出现次数递减的顺序通过 AND 令牌连接多达 25 个公共令牌。最终查询形式如下：

("token1"ti:"token2"...detd:"token25") OR ("token26"ti:"token27"...detd:"token50") OR …

为了确定匹配哪些对，我使用了令牌出现概率的乘积。匹配后，每个部分查询都针对 test-index（包含 test.csv 中的所有专利）运行，如果命中了两个目标以外的内容，则不用于最终查询。接下来，使用额外令牌逐个命中每个未使用的目标。（如同配对的情况一样，我只贪婪地组合出现频率较低的令牌。）最后，只要可能，我就添加公共令牌，以确保查询长度不超过 10,000 的上限。

不使用“魔法”的解决方案 (LB 0.91)

对以下格式的查询进行模拟退火：

cpc:CPC1(token1 OR token2 OR …) OR cpc:CPC2(…) … OR (token1 OR … OR tokenN)

SA 中的评估函数是 mAP 的期望值。这不是精确的期望值，但它的速度足够快且足够准确。请稍后查看发布的 state.py 以了解详细信息。（此处）

此解决方案的预处理在我的环境中需要大约几周时间。做出了一些各种加速和磁盘空间相关的提示，例如：

• 预文件化令牌化文本数据
• 将文件压缩为 .bz2
• 使用名为 leveldb 的键值存储
  • 直接处理 .bz2 更快且更容易并行化，但当文件数量太多时，上传到 Kaggle 数据集非常麻烦。
• 当使用 leveldb 时，数据本身合并为单个文本文件，DB 存储要读取的范围
  • 即，key → (leveldb) → range → (.txt.bz2) → data
  • 直接将数据存储在 DB 中会降低 DB 构建和访问速度
• 使用哈希分割 DB
  • 上传到 kaggle notebook 时，如果 DB 大于 20GB，将其分割为几个 DB。
  • 在这种情况下，使用哈希函数确定键属于哪个 DB。这消除了对额外 dict 或 DB 的需求。
• 对于大型预处理，保存标志以避免重复已完成的过程
  • 过程可能会因 OOM 或意外角落案例导致的错误而中断。
  • 恢复时，标记为已完成的过程将被跳过。
• 等等…

结论

再次，非常悲伤的是，这样的“魔法”在比赛结束时被发现，因为这是一个非常有趣的任务。除了这个之外，我还发现了其他几个“魔法”。（例如，一种在单个令牌中表达多个令牌精确匹配的方法）据我所知，在过去的比赛中，由于泄露或其他缺陷，截止日期后没有重新计算 LB 的先例，所以 LB 可能会就这样最终确定。然而，幸运的是，就我从 LB 上看到的情况而言，大多数顶级参与者直到比赛截止日期前至少 2 周都没有使用这些“魔法”。我期待阅读他们不使用“魔法”的解决方案。

代码