发布说明
了解 Milvus 新功能！本页面汇总了每个版本中的新功能、改进、已知问题和错误修复。建议您定期访问此页面，了解最新更新。
v3.0.0
发布日期：2026 年 7 月 29 日
| Milvus 版本 | Python SDK 版本 | Node.js SDK 版本 | Java SDK 版本 | Go SDK 版本 |
|---|---|---|---|---|
| 3.0.0 | 3.0.1 | 3.0.3 | 3.0.5 | 3.0.0 |
Milvus 3.0.0 正式发布！基于 3.0-beta 引入的 Lake-native 架构，此版本完成了 beta 阶段启动的能力建设：External Collection 覆盖更多 Lakehouse 工作流；Schema 支持在线 add / backfill / drop；Sparse Index 围绕 SINDI 重构；StructArray 和 faceted search 完善检索引擎；FAISS passthrough 和 TEXT 扩展 Index 与模态选择；Woodpecker 以独立服务运行。
观看下方视频，深入了解 Milvus 3.0 并参与核心维护者的 AMA 问答：
如果你是第一次接触 3.0 系列，下方的 Core 3.0 features recall 部分概述了 3.0-beta 引入的能力；完整介绍请参阅 3.0-beta release notes。
3.0.0 新增功能（自 3.0-beta 起）
External Collection：更完整的 Lakehouse 工作流
3.0-beta 引入了 External Collection：可原地引用数据湖文件、构建索引并执行搜索，无需将数据复制到 Milvus。本次发布将其扩展为更完整的 Lakehouse 检索工作流。外部字段现在可作为 Function 输出字段的数据来源，例如 BM25 sparse vectors、MinHash signatures 和 text Embedding，因此文本和模型派生的检索字段可在 Milvus 内构建，无需复制源表。Refresh 也支持追加式 Schema 演进：当外部表新增列时，Milvus 会修补受影响的 Segment，而不是重建 Collection。
本次发布还新增了 milvus-table 外部格式，可将 Milvus Snapshot 元数据和 Storage V3 manifests 作为外部数据源，因此 Collection Snapshot 本身也可以作为外部表提供服务，让批处理系统和在线服务系统基于同一份 manifest-backed 数据视图进行协作。
如需了解更多信息，请参阅 创建 External Collection 和 Snapshots。
Flexible schema：在线添加、回填和删除列
生产环境中的 Schema 不会一成不变：Embedding 模型会被替换，特性会持续迭代，字段也会被废弃。过去，这些变更通常意味着需要停机重建整个 Collection，或进行双写。3.0.0 补齐了这一能力闭环：在服务持续运行的同时，你可以添加、填充和删除列。
Backfill 支持两个方向。External backfill 用于处理在 Milvus 外部计算得到的值：添加一列，将 Collection 以 Snapshot 作为一致的起点，离线运行任务，再将结果写回；Milvus 会对新列进行增量索引。这样，面向数亿行数据的 Embedding 模型升级也可以无需停机地在线完成。Inner backfill 用于处理内核派生的值：将 BM25 或 MinHash function 挂载到现有 Collection 后，其输出字段会自动基于已有数据计算生成。
有关更多信息，请参阅 向现有 Collection 添加字段。
Sparse index overhaul：SINDI、Block-Max WAND 和 Block-Max MaxScore
Milvus 3.0 全面升级了 sparse vector index。它引入了新的搜索算法：SINDI、Block-Max WAND 和 Block-Max MaxScore，同时支持倒排列表压缩、可配置量化，以及按 workload 选择搜索算法。mmap loading、序列化和 BM25 scoring 也得到了优化，可降低大规模 sparse vector 和 Full Text Search 场景下的 index 存储与加载开销。在内部基准测试中，在召回率相当的情况下，压缩后的 BM25 index 体积约为 2.6 sparse index 的三分之一；在 learned sparse Embedding 上，SINDI 的 QPS 最高可达到 MaxScore 的约 10 倍。启用新版 index 后（请参阅 Compatibility and behavior notes），SINDI 将成为 sparse IP search 的默认算法，MaxScore 将成为 BM25 的默认算法。
StructArray coverage
StructArray 现在支持 NULL 值、bitmap indexes、对 live Collection 动态添加字段，以及通过 upsert 对 struct fields 进行部分更新，并在 REST 和 bulk-import 路径中提供相应覆盖。
元素级搜索新增了跨 vector sub-fields 的 Hybrid Search，支持可配置的按 Entity collapse（max / sum / avg / top-k 变体），并在其中支持 Range Search 和 group-by。嵌套过滤覆盖 element_filter 谓词、MATCH_ANY / MATCH_ALL / MATCH_LEAST / MATCH_MOST / MATCH_EXACT 量词、如 tags[0][name] 这样的 positional sub-field access，以及 struct column 上的 array_length()。
有关更多信息，请参阅 StructArray 和 StructArray Operators。
Search Aggregation 与 faceted search
Beta 版中的 Query Aggregation 可以基于过滤后的数据计算精确统计信息；3.0.0 在搜索路径上新增了 faceting 能力。你可以在搜索时指定 facet field，Milvus 会返回排名靠前的 facet 值；每个 facet 值都由其在 ANN 排名中最匹配的成员表示，并附带 COUNT、AVG 等聚合结果。这样，faceted-search 侧边栏（品牌、价格区间、属性）可以通过一次请求完成，而无需过量拉取数据并在客户端计数。
Function Chain reranking
现在，Reranking 可通过 Function Chain API 进行组合。Function Chain API 会在单次搜索请求中执行一个有序且具备类型约束的 Pipeline。一个 Chain 可以将 QueryNode 上的早期 L0 rescoring 与 Proxy 上的 L2 post-reduction reranking 结合起来，支持分数转换与组合、基于模型的 reranking、排序以及候选结果裁剪，而无需在客户端进行编排。本版本还新增了原生 XGBoost scoring，可使用注册为 FileResources 的 UBJ 模型进行 L0 reranking，并引入 Hugging Face Inference Providers，用于由服务端管理的文本 Embedding 和句子相似度 reranking。
TEXT long-text fields
TEXT 字段让长文本成为一等字段，并移除了存储侧的长度限制：它们支持 text_match、phrase_match 和 BM25。小于 64 KB 的值保持 inline；更大的值会以 Vortex 格式写入 Partition 级 LOB 文件，列中仅存储 (file_id, offset) 引用。LOB 文件在多个 Segment 之间共享，因此 Compaction 只移动引用，而不会重写文本。对于 RAG，这意味着可以通过一次 IO 从同一存储中同时取回向量和源文本，无需运维外部 blob store。
FAISS index passthrough
新的 FAISS index type 通过 faiss_index_name 参数接受任意 Faiss index-factory 字符串，例如 IVF64,Flat、HNSW16,Flat、OPQ16,IVF64,PQ16x4。搜索参数也会透传，因此 Faiss recipes 可以直接在 Milvus 中复现。
Vortex and Lance format support
存储层新增两种开放列式格式：Vortex 作为下一代内部格式，支持自适应编码（dictionary、RLE、bit-packing、float-specific compression）、零拷贝解压，并针对向量与标量混合 workload 进行了优化；Lance 则与 Parquet 并列，用于开放生态中的数据交换。Vortex 将成为默认内部格式，filter pushdown 和本地变体已纳入 roadmap。
Woodpecker standalone deployment
Woodpecker 是 streaming write path 核心的 WAL，现在可以作为独立服务部署，而不再嵌入其他节点中。这样一来，它可以像其他微服务一样独立扩缩容、隔离故障并提供可观测性。对于大型集群和高写入工作负载，这一点尤为重要。
Core 3.0 features recall
以下功能已在 3.0-beta 中引入，并属于 3.0.0 的一部分；完整说明请参阅 beta notes。
- External Collection — 原地查询 lakehouse 数据（Parquet、Lance、Iceberg、Vortex）：零拷贝、只读，并通过增量刷新保持同步。
- Snapshot — 基于 Segment 引用的按时间点只读 Collection 视图，边际存储开销接近于零。
- Storage V3 (Loon) — 基于 manifest 的 Object Storage 列式存储；是 Snapshot 和 External Collection 的基础。
- Query / Search ORDER BY — 服务端多字段排序，支持为每个字段设置 ASC / DESC。
- Query Aggregation — COUNT / SUM / AVG / MIN / MAX 及 group-by，由服务端计算。
- EmbList + DiskANN — 面向 StructArray embedding list 的磁盘多向量索引，并提供 Muvera、Lemur 等加速路径。
- MinHash function (doc-in, doc-out) — 服务端 MinHash 签名以及用于近似重复检测的
MINHASH_LSH。 - Nullable vectors — 六种向量类型均支持 NULL；搜索会跳过 NULL 行，AddField 也扩展支持向量字段。
- Entity TTL — 基于 TIMESTAMPTZ 字段驱动的行级过期。
- FileResource — 集群管理的字典、同义词列表和停用词列表，用于 analyzer、BM25 和 Text Match。
- Force Merge — 由 operator 触发的 Segment Compaction，支持同步或异步模式。
Compatibility and behavior notes
- Storage V3 (Loon) 默认禁用。 依赖它的功能（例如 Snapshot 和 TEXT fields）需要通过
common.storage.useLoonFFI手动启用。Storage V3 将在后续版本中默认启用。 - 保证 2.6 → 3.0 兼容性和回滚能力：3.0 部署可以回滚到 2.6。但是，一旦启用或使用会改变序列化数据格式的功能（例如 Storage V3），就无法再回滚。
- 新版 index 当前需要手动启用。 新引入的 index 算法需要先手动提升目标 index 版本（将
dataCoord.targetVecIndexVersion提升到 10，将dataCoord.targetScalarIndexVersion提升到 4）后才会生效；后续版本将默认启用这些版本。 - GPU 镜像迁移到 CUDA 12.9，并且不再保留 Ubuntu 20.04 GPU 兼容性。
v3.0-beta
发布日期：2026 年 5 月 9 日
| Milvus 版本 | Python SDK 版本 | Node.js SDK 版本 |
|---|---|---|
| 3.0-beta | 3.0.0 | 3.0.0 |
Milvus 3.0-beta 通过与 Open Lake 生态系统的全新集成扩展了 Milvus 向量数据库：External Collection 使 Milvus 能够零拷贝查询外部 Lake 表，而 Spark 可以通过 Snapshot 直接读取 Milvus Collection。此版本还带来了更丰富的检索功能、更具表现力的 Schema、更深入的文本搜索定制、更精细的数据和模型生命周期控制，以及更多运维侧控制能力。Milvus 3.0 是 Zilliz Lakebase 的核心内核，为其统一的服务、发现和批处理提供支持。
主要功能
External Collection
在典型的 AI 数据管道中，数 TB 的 Embedding 和元数据通常已作为 Parquet、Lance 或 Iceberg 表存储在 Object Storage 中。将这些数据复制到 Milvus 会使存储成本翻倍，增加必须保持同步的 ETL 管道，并导致数据治理权脱离客户掌控。
外部 Collection 消除了复制需求。Milvus Collection 可直接引用数据原生存储位置，Milvus 仅负责管理 Schema、索引和查询执行。 增量刷新机制确保 Collection 与底层文件保持同步。对于数据无法离开数据湖的客户（如金融和医疗团队），可在数据原地运行向量检索。单个驻留数据湖的数据集也可由多个 Milvus 实例同时提供服务。
如需了解更多信息，请参阅 创建外部 Collection。
Snapshot
服务和批量发现通常需要同时访问同一个 Collection。A/B 模型评估、大规模去重、回填验证以及版本回滚，在写入仍在进行时，都需要 Collection 的稳定视图。
Snapshot（快照）通过引用现有 Segment 而非复制数据，为 Collection 创建特定时间点的只读视图，因此边际存储成本接近于零。在 MVCC 风格的隔离机制下，批处理任务可从 Snapshot 中读取数据，而实时 Collection 继续接受写入。
有关更多信息，请参阅 Snapshot、管理 Snapshot 和 Snapshot 用例。
查询 / 搜索 Order By
搜索和查询现支持多字段排序，排序操作已下推至 Milvus 内核，且可针对每个字段设置 ASC /DESC 参数。这解决了生产环境中的常见痛点：当最相似的项并非最便宜、最新或最受欢迎时，仅基于距离的 Top-K 排序往往无法满足业务需求。
应用程序不再需要过度检索结果并在客户端进行 rerank 来实现复合排名。
有关更多信息，请参阅 按标量字段排序搜索结果 和 排序查询结果。
查询聚合
过去，要从 Milvus Collection 中生成租户分布统计、字段完整性计数或版本发布进度，需要将匹配的实体拉回客户端并在那里进行聚合。 Milvus 3.0 将 SQL 风格的标量聚合推入内核。查询调用接受 group_by_fields 以及 output_fields 中的聚合表达式，包括 count(*)、count(<field>)、sum(<field>)、avg(<field>)、min(<field>) 和 max(<field>)。聚合在过滤后在服务器端进行评估。
有关更多信息，请参阅 聚合查询结果。
空向量
Embedding 通常是异步生成的，因此实体可能在其向量到达之前就已到达。 多模态数据本身也存在天然缺失，例如没有字幕的视频或没有图片的产品。早期版本对此没有好的解决方案：应用程序要么延迟写入直到向量准备就绪，要么填充一个占位符向量，这两种选择都会损害检索质量。
Milvus 3.0 支持所有六种向量类型的向量字段中的 NULL 值。搜索会自动跳过 NULL 向量，检索质量不受影响，且 NULL 向量实际上不占用存储空间。AddField 也扩展到了此变更下的向量字段：通过 nullable=True，现有 Collection 可以在不重建的情况下在线扩展新的向量字段。
有关更多信息，请参阅 可为空字段。
自定义词典与同义词词典
开箱即用的分词器并不总能满足生产环境的搜索质量要求。中文、医学、法律和化学等垂直领域，以及多语言语料库，均可从自定义词典和同义词表中获益匪浅。此前，这些资源主要以应用程序侧的查询重写形式存在。
Milvus 3.0 引入了 FileResource 机制，用于注册自定义分词器词典、同义词表、停用词表以及拆分规则。 资源注册后，可在任何分词器或过滤器中引用，并适用于 BM25、分析器和文本匹配功能。词典和同义词现可进行版本控制并集中管理，不再分散在应用程序代码中。
有关更多信息，请参阅 管理文件资源。
Entity TTL
对于许多生命周期和合规性场景而言，Collection 级和 Partition 级的 TTL 过于粗略。同一 Collection 内的不同租户通常具有不同的保留规则，且个别实体可能需要按照与 Collection 其余部分不一致的计划过期。
Milvus 3.0 支持按实体设置 TTL。在 Schema 中声明一个 TIMESTAMPTZ 字段，通过 Collection 属性将其标记为 TTL 字段，Milvus 便会自动回收已过期的实体。这涵盖了“被遗忘权”请求、过期的会话数据以及有限的对话历史记录，且无需应用程序端进行清理。
更多信息，请参阅 设置 Entity 级 TTL。
MinHash DIDO（文档输入、文档输出）
Milvus 2.6 引入了用于基于 Collection 的近似重复检测的 MINHASH_LSH 索引，但应用程序在将数据写入 Milvus 之前仍需计算 MinHash 签名。
Milvus 3.0 引入了服务器端的 MinHash Function。在 Schema 中声明一个 VARCHAR 输入字段和一个 BINARY_VECTOR 输出字段，并关联一个 FunctionType.MINHASH 函数，Milvus 便会在插入、批量插入和搜索过程中计算签名。结合 MINHASH_LSH，这支持 Milvus 内部针对大型数据集的去重工作流、指纹识别以及抄袭检测。
更多信息，请参阅 MinHash Function。
EmbList + DISKANN
“一个实体 = 一个向量”的假设已不再适用于现代检索。长文档会被拆分为多个片段，ColBERT 等晚期交互模型会为每个令牌生成一个向量，而多模态实体可能包含多种视图。
EmbList 为每个实体存储一个可变长度的向量列表，并以 DISKANN 作为磁盘索引。当语料库超过内存预算时，磁盘路径可有效控制 RAM 使用量。EmbList +DISKANN 是本次 RC 版本中更广泛的 StructList 家族的首个变体。 该家族的其余部分，包括 StructList 过滤以及 Muvera / Lemur 多向量加速功能，计划在正式的 3.0 版本中发布。
更多信息请参阅 使用 Embedding 列表进行搜索。
强制合并
生产工作负载会随着时间的推移积累分段碎片，从而导致查询延迟波动和存储膨胀。
Milvus 3.0 增加了在非高峰时段显式触发 Segment Compaction 的功能，支持同步和异步两种模式。
有关更多信息，请参阅 Force Merge Compaction。
Storage V3
Milvus 3.0 引入了 Storage V3，这是一个基于清单的列式存储引擎，其中数据和元数据存储在兼容 S3 的 Object Storage 中。每个数据集版本都被捕获为一个不可变的清单快照，这是一个 Avro 编码的文件，记录了构成该数据集的列组、增量日志和统计信息。
清单是紧凑的 Avro 文件，增量日志记录实体级别的删除操作，而无需重写数据文件。这使得随着数据集的增长，元数据开销得以保持在较低水平。此外，清单将元数据追踪与查询路径解耦，使 Collection 能够管理更多分段，同时不会降低查询性能。
由于状态存储在 Object Storage 中，数据集具有自描述性：任何能够访问存储路径的读取者均可发现并解析数据集，无需依赖中央目录。这一特性为外部 Collection、快照以及未来的湖存储集成提供了基础。