Hierarchical BM25: Lexical Search at Billion-Document Scale
分层 BM25 通过使用一个小型、常驻的粗粒度索引来选择相关的文档组，从而取代了内存密集型的扁平索引，通过实现固定的内存和延迟边界，同时保留检索子集的精确评分，实现了交互式的十亿级规模词法搜索。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你正试图在一座拥有十亿本书的图书馆中寻找一个特定的事实。在计算机科学领域，这就是“词法搜索”（lexical search）所面临的挑战——即基于精确的单词匹配来查找文档，例如搜索“hierarchical BM25”这个短语，而不是仅仅搜索它的泛指概念。几十年来，计算机在这方面一直在进步，但有一个难点：为了瞬间搜索十亿本书，你通常需要将每一本书中每一个单词的庞大索引图谱都保存在计算机的主内存（RAM）中。这个图谱如此巨大——大约 400 GB——就像是试图在跑步时把整座图书馆都装进你的背包里一样。如果你没有那么多内存，你就必须为了每一个问题在书架（硬盘）之间来回奔波，这需要数秒钟的时间。在一个我们期望瞬间得到答案的世界里，等待四到十二秒简直就像是在看油漆变干；这会破坏用户体验。这篇论文正是针对这一问题展开研究的：我们如何在不需要超级计算机内存的情况下，瞬间搜索十亿份文档？
作者提出了一种名为 Hierarchical BM25 的巧妙新搜索方法。他们并没有尝试一次性记住整个图书馆，而是建议采用一种模仿人类图书管理员协助你的两步策略。首先，他们根据主题将十亿份文档组织成大约 1,000 个不同的“走廊”或组。他们为这些“走廊”构建了一个微小的、超快速的索引，且该索引能轻松放入内存中（约 4.4 GB）。当你提出问题时，计算机不会扫描每一本书；它首先检查这个小型的索引，以确定哪 40 个“走廊”最有可能包含答案。然后，它仅深入到这些特定的“走廊”中去寻找精确的文档。
这里的魔力在于一种权衡。作者承认，通过跳过其他 960 个“走廊”，他们偶尔可能会错过那个绝对完美的答案。他们称之为放弃了“排名安全性”（rank safety）——即每次都能获得完全一致的前 10 个结果的保证。然而，他们认为在现代搜索系统中，得到第 10 好的结果而不是第 11 好的结果其实并不重要，因为第二台计算机（“重排序器”）稍后会对它们进行排序。真正重要的是速度。通过这种权衡，他们实现了一个此前无法实现的目标：他们可以在使用极少量内存的情况下，在约 300 毫秒（不到三分之一秒）内搜索十亿份文档。
在测试中，这种新方法比旧的标准搜索方式快了 4.7 到 5.6 倍，即使在旧方法使用了多个处理器协同工作的情况下也是如此。当旧方法难以处理每秒超过 3 个问题时，这个新系统在“走廊”预热就绪后，可以处理多达 32 个问题。作者还发现了一个关于不同书籍组之间如何相互评分的微妙错误，并修复了它，从而确保在进行搜索时，数学计算是完全准确的。
然而，作者非常谨慎，并未称其为完美的解决方案。他们明确指出，这种方法是一种近似值，而非保证。他们通过对 50 万份文档的小规模测试来衡量其效果，发现通过仅检查 5% 到 10% 的组，他们可以恢复约 83% 到 92% 的“质量”。他们认为这在十亿文档规模下也可能成立，但尚未在自然、杂乱的真实世界数据集上得到证实。他们还注意到，该方法最适用于长而复杂的查询（16 到 32 个单词），这在现代 AI 系统中很常见，而旧方法则是为短小、简单的网络搜索设计的。
简而言之，这篇论文表明，如果你愿意接受极小的错过绝对最佳答案的可能性，你就可以构建一个针对十亿份文档的搜索引擎，它既快速又廉价，并且能装进标准计算机的内存中。这是一个实用的工程胜利，它优先考虑速度和效率，而非数学上的完美，并承认在现实世界中，一个快速的“足够好”的答案往往比一个缓慢的“完美”答案更有效。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。