Milvus(@milvusio)

We built HNSW directly on the embedding lists, with no encoding step in between. 𝗧𝗵𝗲 ...

8.5内容质量
We built HNSW directly on the embedding lists, with no encoding step in between. 𝗧𝗵𝗲 ...

TL;DR · AI 摘要

Milvus 直接在嵌入列表上构建 HNSW 索引，无需编码步骤，质量几乎无损失，且优于现有近似策略。

核心要点

  • 直接在嵌入列表上构建 HNSW 索引，质量接近 BruteForce 方法。
  • 现有近似策略（如 TokenANN、MUVERA、LEMUR）在减少步骤中损失了质量。
  • 构建成本和列表长度是限制该方法投入生产的主要因素。

结构提纲

按章节快速跳转。

  1. §引言

    Milvus 直接在嵌入列表上构建 HNSW 索引，无需编码步骤，质量几乎无损失。

  2. ·方法概述

    每个文档的完整嵌入列表作为一个 HNSW 节点，使用 MeanMaxSim 计算节点间距离。

  3. ·质量评估

    该方法在 nDCG@10 指标上表现优于现有近似策略，接近 BruteForce 方法。

  4. ·性能与成本

    构建成本和列表长度是限制该方法投入生产的主要因素。

  5. ·结论与未来方向

    未来工作将集中在优化减少步骤，以实现接近 BruteForce 的质量。

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）
  • HNSW 直接构建于嵌入列表
    • 方法
      • 每个文档的完整嵌入列表作为一个 HNSW 节点
      • 使用 MeanMaxSim 计算节点间距离
    • 质量评估
      • nDCG@10 指标接近 BruteForce 方法
      • 优于现有近似策略
    • 限制因素
      • 构建成本高
      • 列表长度限制

金句 / Highlights

值得收藏与分享的关键句。

#HNSW#向量搜索#Milvus#嵌入列表
打开原文

Milvus on X: "我们在嵌入列表上直接构建了HNSW，中间没有编码步骤。 𝗧𝗵𝗲 𝗾𝘂𝗮𝗹𝗶𝘁𝘆 𝗰𝗮𝗺𝗲 𝗼𝘂𝘁 𝗮𝗹𝗺𝗼𝘀𝘁 𝗹𝗼𝘀𝘀𝗹𝗲𝘀𝘀, 𝗯𝘂𝘁 𝘁𝗵𝗲 𝗳𝗶𝗻𝗱𝗶𝗻𝗴 𝗶𝘀 𝘄𝗵𝗮𝘁'𝘀 𝗺𝗼𝘀𝘁 𝘃𝗮𝗹𝘂𝗮𝗯𝗹𝗲: 𝘁𝗼𝗱𝗮𝘆'𝘀 𝗮𝗽𝗽𝗿𝗼𝘅𝗶𝗺𝗮𝘁𝗲 𝘀𝘁𝗿𝗮𝘁𝗲𝗴𝗶𝗲𝘀 https://t.co/dWAOWlW9un" / X

Milvus

@milvusio

我们在嵌入列表上直接构建了HNSW，中间没有编码步骤。 𝗧𝗵𝗲 𝗾𝘂𝗮𝗹𝗶𝘁𝘆 𝗰𝗮𝗺𝗲 𝗼𝘂𝘁 𝗮𝗹𝗺𝗼𝘀𝘁 𝗹𝗼𝘀𝘀𝗹𝗲𝘀𝘀, 𝗯𝘂𝘁 𝘁𝗵𝗲 𝗳𝗶𝗻𝗱𝗶𝗻𝗴 𝗶𝘀 𝘄𝗵𝗮𝘁'𝘀 𝗺𝗼𝘀𝘁 𝘃𝗮𝗹𝘂𝗮𝗯𝗹𝗲: 𝘁𝗼𝗱𝗮𝘆'𝘀 𝗮𝗽𝗽𝗿𝗼𝘅𝗶𝗺𝗮𝘁𝗲 𝘀𝘁𝗿𝗮𝘁𝗲𝗴𝗶𝗲𝘀 𝗹𝗼𝘀𝗲 𝗺𝗼𝘀𝘁 𝗾𝘂𝗮𝗹𝗶𝘁𝘆 𝗶𝗻 𝘁𝗵𝗲 𝗿𝗲𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝘀𝘁𝗲𝗽, 𝗻𝗼𝘁 𝘁𝗵𝗲 𝗶𝗻𝗱𝗲𝘅. TokenANN, MUVERA, 和 LEMUR 都将文档的令牌向量减少为单向量的ANN，只是从相反的两端进行：MUVERA 和 LEMUR 将每个文档压缩为一个向量，TokenANN 则分别对每个令牌进行索引并重新组装。不管怎样，这都是对 MaxSim 的近似，而质量的损失就发生在这里。因此，跳过减少步骤：将整个列表作为索引单元，一个文档，一个向量列表。我们尝试了这种方法，效果很好 —— 质量几乎与精确匹配相当。

它是如何设置的：

  • 每个文档的完整嵌入列表是一个 HNSW 节点
  • 两个节点之间的距离是双向的 MeanMaxSim：MeanMaxSim(A,B) + MeanMaxSim(B,A)
  • 双向，因为 HNSW 需要对称的距离，而 MaxSim 不对称
  • 平均，因为原始 MaxSim 随着向量数量的增加而增长，所以将其除掉可以保持不同长度文档的可比性
  • 在查询时，使用标准的单向 MaxSim(query, doc)；查询较短，因此反向方向主要是噪声

它取得的成绩：

  • 数学 nDCG@10（与精确 BruteForce 排名的一致性）：高于 0.98，而三种近似策略中最好的只有 0.87–0.89
  • 端到端：在 TREC-COVID 上与 BruteForce 平局（0.516），在 MS MARCO 上接近匹配（0.957 vs 0.966）

这个差距正是重点所在。所有四种方法都运行在 HNSW 上，只有先减少列表的三种方法失去了精度 —— 大约损失了 10 个点。图搜索在所有地方都是一样的；损失追踪减少步骤。获得这种接近无损的端到端质量，几乎接近精确的上限。

两个因素让它无法投入生产，都与成本有关：

  • 构建成本：每个距离是两个列表之间每对令牌的内积 —— O(avg_len² × dim)。节点数量从 N × avg_len 降低到 N，但总体成本仍然随着 avg_len 增加。测量结果：在 avg_len 为 87（MS MARCO）时，成本是单向量 HNSW 的 6 倍；在 avg_len 为 236（TREC-COVID）时，成本是 18 倍。
  • 列表长度：当文档携带数千个向量（如 ColQwen2：每页 5,143 个补丁）时，距离成本会增加，直到构建和搜索延迟变得无法接受。这排除了多模态和长复杂查询文档 —— 正是多向量方法最能发挥优势的地方。

在完整列表上直接构建 HNSW，没有减少步骤，几乎与 BruteForce 完全匹配。 这告诉我们，MUVERA、LEMUR 和 TokenANN 丢失的质量来自于它们如何减少嵌入列表，而不是它们共享的 HNSW 索引。 因此，下一步的工作将聚焦于此：优化减少步骤，一个可部署的方法可能达到 BruteForce 级别的质量。

3:00 PM · Jun 23, 2026

216

Views

1