快速 vs. 准确：衡量量化向量搜索的召回率

作者来自 Elastic Jeff Vestal解释如何在最少设置的情况下测量 Elasticsearch 中向量搜索的召回率。从向量搜索到强大的 REST APIElasticsearch 为开发者提供了最全面的搜索工具集。深入了解 Elasticsearch Labs 仓库中的示例 notebooks尝试一些新内容。你也可以立即开始免费试用或在本地运行 Elasticsearch。每个人都希望向量搜索是即时的。但高维向量是 “沉重” 的。一个 1,024 维的 float-32 向量会占用相当多的内存并且将其与数百万个向量进行比较在计算上代价高昂。为了解决这个问题像 Elasticsearch 这样的搜索引擎使用两种主要优化策略近似搜索分层可导航小世界 [HNSW]不是扫描每个文档而是构建一个导航图以快速跳转到答案可能所在的邻域。量化我们压缩向量例如从 32 位浮点数压缩到 8 位整数甚至 1 位二进制值以减少内存使用并加快计算速度。但优化通常伴随着代价准确性。这种担忧是合理的“如果我压缩数据并在搜索过程中走捷径会不会错过最佳结果”“这种优化是否会降低搜索引擎的相关性”为了证明 Elastic 的量化不会降低结果质量我们使用 DBPedia-14 数据集构建了一个可重复的测试框架用于精确计算在 Elasticsearch 中使用默认优化时为了速度所牺牲的准确性具体来说是召回率。总结实际影响可能远小于你的想象。查看 notebook 并亲自尝试。定义面向非专家在查看代码之前我们先统一一些术语。相关性 vs 召回率相关性是主观的我是否找到了好的结果。召回率是数学上的。如果数据库中有 10 个与查询完全匹配的文档而搜索引擎找到了其中 9 个那么你的召回率是 90%或 0.9。精确搜索flat有时称为 “暴力” 方法。搜索引擎扫描索引中的每一个文档并计算距离。优点100% 完美召回率。缺点计算成本高在大规模下速度慢。近似搜索HNSW一种“捷径”方法。搜索引擎构建一个 HNSW 图并在图中遍历以找到最近邻。优点速度极快且可扩展。缺点如果图遍历过早停止可能会错过某些邻居。实验精确 vs 近似为了测试召回率我们使用了DBPedia-14数据集这是一个包含 14 个本体类别的标题和摘要的大型数据集常用于训练和评估文本分类模型。具体来说我们将重点关注 Film 类别。我们的目标是将优化后的生产设置与数学上完美的基准进行比较。在本实验中我们使用 jina-embeddings-v5-text-small 模型这是一个最先进的多语言模型在文本表示方面领先行业基准。我们选择该模型是因为它代表了当前高性能 embedding 的标准。通过将 Jina v5 的高精度与 Elasticsearch 的原生量化相结合我们可以展示一种既计算高效又不牺牲检索质量的搜索架构。我们设置了一个具有双映射的索引。我们将相同的文本同时写入两个不同的字段content.raw类型为 flat。这会强制 Elasticsearch 对完整的 Float32 向量执行暴力扫描。该方式返回精确匹配结果并将作为我们的基准。content类型为 semantic_text。默认使用 HNSW Better Binary QuantizationBBQ。这是近似匹配的标准优化生产设置。Recall10 测试我们的指标使用 Recall10。我们随机选择了 50 部电影并在两个字段上运行相同的查询。如果精确flat搜索认为前 10 个邻居的 ID 是 [1, 2, 3... 10]。而近似HNSW搜索返回的 ID 是 [1, 2, 3... 9, 99]。那么我们正确找到了前 10 个中的 9 个得分为 0.9。这是我们使用的映射# The Control Group: Forces exact brute-force scan raw: { type: semantic_text, inference_id: .jina-embeddings-v5-text-small, index_options: { dense_vector: { type: flat } } }结果“平直线”的成功我们进行了一个规模测试重新加载完整数据集并针对 1,000 到 40,000 文档的索引规模进行测试。以下是召回率得分的变化文档数Recall10 得分1,0001.000100%5,0000.998100%10,0000.99299.4%20,0000.99999.0%40,0000.99298.8%结果非常稳定。即使在规模扩大时近似搜索在超过 99%的情况下与暴力精确搜索结果一致。为什么效果这么好你可能会认为将向量压缩为二进制值会比实际影响的准确性更大。原因在于 Elasticsearch 如何处理检索。如今大多数 embedding 模型输出 Float32 向量这些向量很大。为了提高搜索效率Elasticsearch 对高维向量使用量化。具体来说自 9.2 版本起它默认使用 BBQ。BBQ 使用重评分机制遍历Traversal搜索引擎使用压缩量化向量快速遍历 HNSW 图。由于向量较小它可以高效地过采样收集更多候选文档例如前 100 个大致相似的文档而不会带来性能损耗。重评分Rescore一旦获取到候选文档它只检索这些少数文档的全精度值以计算最终的精确排序。这让你两全其美量化带来的速度处理大量数据以及浮点数带来的最终排序精度。还能做得更好吗值得注意的是我们这里看到的结果使用的是默认设置和随机采样数据。可以把它看作一个高性能的起点。虽然 Jina v5 非常强大但这些召回率并不是针对每个数据集的 “一刀切” 保证。每个数据集合都有自己的特点虽然你可以进一步调优以获取更高性能但你应始终针对自己的具体数据进行基准测试以确定实际上限。结论这是一个非常小规模的测试。但这项练习的重点不是专门测量 embedding 模型或 BBQ而是展示如何在最少设置下轻松测量你数据集的召回率。如果你想在自己的数据上运行此测试可以查看这里的 notebook 并亲自尝试。原文https://www.elastic.co/search-labs/blog/recall-vector-search-quantization