Milvus 3.0开源解读：从Entity到Element，StructArray如何重构多向量检索

在向量数据库的发展历程中，早期的设计哲学倾向于简洁高效：一个实体（Entity）对应一条向量（Embedding）。这种抽象在文档搜索、推荐召回和初代RAG应用中表现出色，因为对于结构相对简单的数据，一条高维向量确实能够在统计意义上代表其语义特征。然而，当我们面对更复杂的数据类型——一段视频、一份长篇技术文档、一个包含数十张商品图片的展示页面——将所有内容强行压缩成单一向量时，局部细节就会被严重稀释。真正决定相关性的关键信息，往往藏匿于这些被平均化的细节之中。

StructArray：重新定义Entity与Element的关系

面对这一挑战，一个直观的解决方案是将数据"暴力拆分"：将视频分割为多个片段，每个片段作为独立实体存储自己的embedding、时间戳、描述文本等信息。这种做法虽然让局部搜索变得简单直接，却也引入了新的问题——同一条视频的多个片段可能同时出现在搜索结果的前列，父级元数据需要在多条记录中重复存储，数据库层面失去了对数据内在关联的认知，应用层不得不承担起分组、去重和重排序的额外工作。这里浮现出一个典型的粒度矛盾：业务消费的是整体，而检索命中的却是局部。

三种检索语义：MATCH、EmbeddingList与Element-level

Milvus 3.0引入的StructArray，正是为了解决这一粒度失衡问题。它允许在一个Entity内部保存一组彼此对齐的Elements，每个Element可以包含受支持的标量元数据和向量子字段，同时仍然归属于同一个父实体。这种设计让数据库能够明确理解哪些数据在共同描述同一个对象，并在entity级别、element级别或两种粒度之间灵活选择搜索策略。以视频检索场景为例，一个video entity可以包含多个clips，每个clip拥有自己的向量、时间戳、描述文本和场景标签等属性，而这些属性在数据库层面被显式关联，确保了数据的一致性和可追溯性。

索引策略与混合搜索

StructArray的核心价值在于它提供了三种互补的检索语义。首先是MATCH系列操作符，用于在element层面执行条件判断后再决定entity是否命中——例如检查是否存在同一个clip同时满足"厨房场景"且"置信度高于0.8"这两个条件。这种语义确保了多个过滤条件作用于同一个element，而非在父实体的不同elements间分散判断。其次是EmbeddingList搜索，适用于query本身也是多向量集合的场景（如视频到视频、多图到商品的匹配），Milvus使用MaxSim类指标比较查询与存储的向量列表，返回最相似的父实体。最后是Element-level搜索，让每个element的向量独立参与ANN检索，结果携带offset信息，直接告诉应用命中的是父实体内部的第几个element。

适用场景与设计思考

在索引层面，EmbeddingList模式需要精确计算大量向量间的相似度以保证质量，但全量遍历成本较高。Milvus采用两阶段搜索模型：先用近似方法召回候选父实体，再在候选集上重新计算MaxSim得到最终排序。对于需要同时支持两种搜索模式的场景，建议使用两个独立的向量子字段——一个服务于EmbeddingList+MAX_SIM，另一个服务于element-level的常规向量度量。混合搜索场景下，当所有子搜索都来自同一父StructArray时，结果可保持element-level；当涉及普通向量字段或不同父struct时，element-level结果需要collapse回entity-level，选择最佳element score、求和、平均或只聚合top-k element作为最终排序依据。

如有侵权，请联系删除。