RAG从入门到精通(九)——Milvus数据库操作介绍及索引类型介绍
FLAT的“Flat”指向量平铺存储,无分层、分区等优化,本质是“原始向量存储+全量遍历比对”,是向量检索的“基准方案”。
RAG基本处理流程
整个流程的优化方向是 “高准确率、快速度、低内存消耗”,利用 Milvus 的向量存储与检索能力,实现游戏数据的高效语义查询。

1. Milvus 核心概念与基础用法详解
Milvus 是开源分布式向量数据库,以下是其核心概念及创建数据库、集合、字段的基础操作:
一、核心概念
-
数据库(Database)
Milvus 中的独立数据空间,用于隔离不同业务的集合(类似 MySQL 的数据库),支持多租户场景。 -
集合(Collection)
Milvus 中存储数据的容器(类似 MySQL 的表),需定义 Schema(数据结构),包含字段、索引等配置。 -
Schema
集合的数据结构定义,包含字段列表、字段类型、主键规则等。 -
字段架构(Field)
集合的基本数据单元(类似 MySQL 的列),支持多种类型:- 主键字段:唯一标识实体,支持
INT64类型,可手动指定或 Auto ID 自动生成; - 向量字段:存储向量数据,类型为
FLOAT_VECTOR(稠密向量)或BINARY_VECTOR(二进制向量),需指定维度(如 128、256); - 标量字段:存储结构化数据(如
VARCHAR、INT32、FLOAT),用于条件过滤。
- 主键字段:唯一标识实体,支持
-
主键和 Auto ID
- 主键:字段需标记
is_primary=True,保证实体唯一性; - Auto ID:主键字段设置
auto_id=True时,Milvus 自动生成主键值,无需手动传入。
- 主键:字段需标记
-
索引(Index)
加速向量检索的算法结构,支持 HNSW、IVF_FLAT、IVF_PQ 等类型,需在插入数据前创建。 -
实体(Entity)
集合中的一条数据(类似 MySQL 的行),由字段值组成(如id=1, content="游戏攻略", vector=[0.1, 0.2...])。 -
Upsert
插入或更新实体:若实体主键已存在,则更新该实体;若不存在,则插入新实体。 -
分区(Partition)
集合的子集,共享父集合的 Schema,用于按业务规则分组实体(如按“游戏类型”分区分组)。检索时可指定分区,减少扫描范围,提升效率。 -
分片(Shard)
集合的水平切片,对应独立的数据输入通道,用于提升写入吞吐量。集合默认 1 个分片,可在创建时指定分片数(需根据数据量/吞吐量调整)。 -
别名(Alias)
集合的“别名”,一个集合可绑定多个别名,但别名不能共享。用于简化集合名称管理(如切换线上/测试集合)。 -
函数(Function)
创建集合时配置的自定义函数,用于导出字段(如从VARCHAR字段导出稀疏向量,支持全文+向量混合检索)。 -
一致性级别(Consistency Level)
定义分布式场景下数据的一致性,支持 4 种级别:Strong:强一致性(读操作需等待所有写操作完成);Bounded Staleness:有限陈旧(读操作等待指定版本的写操作完成);Session:会话一致性(同一客户端的读写操作保持一致);Eventually:最终一致性(读操作可能返回旧数据,最终会一致)。
二、基础用法(以 Python SDK 为例)
1. 连接 Milvus
from pymilvus import MilvusClient
# 连接本地 Milvus 服务
client = MilvusClient(uri="http://localhost:19530")
2. 创建数据库
在 Milvus 中,数据库是组织和管理数据的逻辑单元。
- 多租户创建多个数据库,为不同的应用程序或租户从逻辑上隔离数据。例如,创建一个数据库用于存储用户 A 的数据,另一个数据库用于存储用户 B 的数据
# 创建名为 "game_db" 的数据库
client.create_database(database_name="game_db")
# 切换到该数据库(后续操作默认在这个库中)
client.using_database(database_name="game_db")
3. 创建集合(含 Schema、字段、分片)
-
可以创建多个 Collections 来管理数据,并将数据作为实体插入到 Collections 中。
Collections 和实体类似于关系数据库中的表和记录。
Collection 是一个二维表,具有固定的列和变化的行。每列代表一个字段,每行代表一个实体。 -
Schema 定义了 Collections 的数据结构。创建 Collections 时,需要根据自己的要求设计模式。
-
集合架构包含一个主键、最多四个向量字段以及多个标量字段。
与关系数据库中的主字段类似,Collection 也有一个主字段,用于将实体与其他实体区分开来。主键字段中的每个值都是全局唯一的,并与一个特定实体相对应。
名为id的字段是主字段。主字段只接受整数或字符串。
• 插入实体时,默认情况下应包含主字段值。
• 如果在创建 Collections 时启用了AutoId,Milvus 将在插入数据时生成这些值。此时,从要插入的实体中排除主字段值
# 定义 Schema(字段列表)
schema = MilvusClient.create_schema(
auto_id=False, # 关闭 Auto ID,手动指定主键
enable_dynamic_field=True # 允许动态字段(可选)
)
# 添加主键字段
schema.add_field(
field_name="id",
datatype="INT64",
is_primary=True
)
# 添加向量字段(128维稠密向量)
schema.add_field(
field_name="game_vector",
datatype="FLOAT_VECTOR",
dim=128
)
# 添加标量字段(游戏名称)
schema.add_field(
field_name="game_name",
datatype="VARCHAR",
max_length=100
)
# 添加标量字段(游戏类型)
schema.add_field(
field_name="game_type",
datatype="VARCHAR",
max_length=50
)
# 创建集合(指定分片数为2,一致性级别为Session)
client.create_collection(
collection_name="game_collection",
schema=schema,
shards_num=2, # 分片数
consistency_level="Session" # 一致性级别
)
4. 创建索引
为特定字段创建索引可提高搜索效率 ,向量字段的索引是强制性的。
建议为所有有用字段创建索引。
向量字段需要同时设置索引类型和度量类型,标量字段只需设置索引类型。
创建了包含索引参数的集合,Milvus 会在创建时自动加载该集合。在这种情况下,索引参数中提到的所有字段都会被索引。
# 为向量字段创建 HNSW 索引
client.create_index(
collection_name="game_collection",
field_name="game_vector",
index_params={
"index_type": "HNSW",
"metric_type": "COSINE", # 相似度度量方式(余弦)
"params": {"M": 8, "efConstruction": 64} # HNSW 参数
}
)
5. 插入/ Upsert 实体

-
insert 操作:主键冲突会报错当插入的实体主键已存在于集合中时,insert 会触发 PrimaryKeyDuplicateException,无法插入新数据,原有数据也不会被修改。
-
upsert 操作:主键相同则覆盖upsert 是 “插入(insert)+ 更新(update)” 的组合逻辑:
若主键不存在:执行插入,新增实体;
若主键已存在:执行更新,用新数据覆盖原有实体的所有字段(包括向量、标量字段)。
# 准备实体数据
entities = [
{
"id": 1,
"game_vector": [0.1]*128,
"game_name": "原神",
"game_type": "开放世界"
},
{
"id": 2,
"game_vector": [0.2]*128,
"game_name": "王者荣耀",
"game_type": "MOBA"
}
]
# 插入实体
client.insert(
collection_name="game_collection",
data=entities
)
# Upsert 实体(更新 id=1 的实体)
upsert_entities = [
{
"id": 1,
"game_vector": [0.15]*128,
"game_name": "原神(3.0版本)",
"game_type": "开放世界"
}
]
client.upsert(
collection_name="game_collection",
data=upsert_entities
)
6. 创建分区
在 Milvus 中,Entity是指Collection中共享同一个Schema的数据记录,一行中每个字段的数据构成
一个 Entity。因此,同一个 Collection 内的 Entity 具有相同的属性(例如字段名、数据类型和其他
约束)。
将实体插入集合 (Collection) 时,只有包含 Schema 中定义的所有字段,插入的实体才能成功添加。
插入的实体将按插入顺序进入名为_default的分区 (Partition )。如果存在某个分区 (Partition),您
也可以通过在插入请求中指定分区名称,将实体插入到该分区 (Partition) 中。
# 创建分区(按游戏类型分区分组)
client.create_partition(
collection_name="game_collection",
partition_name="open_world_part" # 开放世界游戏分区
)
# 向分区插入实体
partition_entities = [
{
"id": 3,
"game_vector": [0.3]*128,
"game_name": "塞尔达传说",
"game_type": "开放世界"
}
]
client.insert(
collection_name="game_collection",
data=partition_entities,
partition_name="open_world_part"
)
7. 创建别名
您可以为集合创建别名。一个集合可以有多个别名,但集合之间不能共享一个别名。收到
针对某个集合的请求后,Milvus 会根据提供的名称查找该集合。
# 为集合绑定别名
client.create_alias(
collection_name="game_collection",
alias="game_coll_alias"
)
8. 其他概念及一致性
Partition- 分区是集合的子集,与其父集合共享相同的字段集,每个分区包含一个实体子集。通过将实体分配到不同的分区,您可以创建实体组。您可以在特定分区内进行搜索和查询,让Milvus 忽略其他分区中的实体,从而提高搜索效率。Shard- 分片是集合的水平切片。每个分片对应一个数据输入通道。
每个集合默认都有一个分片。您可以根据预期吞吐量和要插入到集合中的数据量,在创建集合时设置适当的分片数量。。Alias- 您可以为集合创建别名。一个集合可以有多个别名,但集合之间不能共享一个别名。收到针对某个集合的请求后,Milvus 会根据提供的名称查找该集合。Function- 您可以在 Milvus 创建集合时设置函数来导出字段。例如,全文搜索功能使用用户自定义函数从特定的 varchar 字段导出稀疏向量字段。Consistency Level- 分布式数据库系统通常使用一致性级别来定义跨数据节点和副本的数据相同性。可以在创建集合或在集合内进行相似性搜索时设置单独的一致性级别。适用的一致性级别包括Strong, Bounded Staleness, Session, Eventually。

2. 索引类型
2.1 FLAT 索引 – 全量扫描
FLAT(Flat Index)是向量数据库的基础索引类型,核心是无结构全量暴力扫描——检索时将查询向量与所有向量逐一计算相似度,无优化结构,以“速度换精度”。
一、核心定义
FLAT的“Flat”指向量平铺存储,无分层、分区等优化,本质是“原始向量存储+全量遍历比对”,是向量检索的“基准方案”。
二、工作流程
- 存储:向量按写入顺序平铺存储,无预处理;
- 检索:查询向量与所有存储向量逐一计算相似度;
- 输出:按相似度排序,返回Top K结果。
三、关键特性
- 精度:100%无近似误差,是检索精度的“黄金基准”;
- 速度:时间复杂度O(N×D)(N为向量数,D为维度),仅适合小数据量(≤10万条);
- 易用性:零参数调优,仅需指定向量字段和相似度计算方式(如L2、余弦)。
四、适用场景
✅ 小数据集(≤10万条)、高精度需求(如科研验证)、高频写入场景;
❌ 海量数据、高并发、低延迟场景。
五、实操代码(Milvus)
# 配置FLAT索引
index_params = client.prepare_index_params().add_index(
field_name="vector", # 向量字段名
index_type="FLAT", # 四级标题对应功能:FLAT全量扫描
metric_type="Cosine" # 相似度计算方式
)
2.2 IVF_FLAT - 倒排文件

IVF_FLAT(Inverted File Flat)是基于聚类分区+倒排索引的向量索引,核心是“先缩小搜索范围,再全量比对”——通过K-means算法将向量聚成多个簇,检索时仅在与查询向量相近的簇内做全量扫描,平衡了FLAT的精度和检索速度,是中小规模数据(10万~1000万条)的常用方案。
一、核心原理:聚类+倒排
IVF_FLAT的“倒排”指“簇中心→簇内向量”的映射关系(类似“关键词→文档”的倒排索引),工作分为离线聚类和在线检索两步:
- 离线聚类(索引构建):
- 用K-means算法将所有向量聚成
nlist个簇(nlist是配置参数,代表簇的数量); - 每个簇选一个“簇中心(centroid)”,并建立“簇中心→该簇内所有向量”的倒排映射表。
- 用K-means算法将所有向量聚成
- 在线检索(查询匹配):
- 计算查询向量与所有簇中心的相似度,找到最相近的
nprobe个簇(nprobe是配置参数,代表要搜索的簇数量); - 仅在这
nprobe个簇内,对所有向量做全量相似度计算(同FLAT的暴力比对); - 按相似度排序,返回Top K结果。
- 计算查询向量与所有簇中心的相似度,找到最相近的
二、关键参数(平衡精度与速度)
IVF_FLAT的性能由nlist和nprobe共同决定:
- nlist(簇数量):
- 越大→簇内向量越少,簇间区分度越高,但聚类开销越大;
- 建议值:数据量的
1/1000~1/100(如100万条向量,nlist=1000)。
- nprobe(搜索簇数量):
- 越大→覆盖的簇越多,检索精度越接近FLAT,但速度越慢;
- 建议值:
nlist的1%~5%(如nlist=1000,nprobe=10~50)。
三、核心特性
| 维度 | 特性描述 |
|---|---|
| 检索速度 | 远快于FLAT(仅扫描部分簇),数据量越大优势越明显 |
| 检索精度 | 接近FLAT(nprobe越大,精度越高,最高≈98%) |
| 存储开销 | 额外存储簇中心和倒排映射表,开销略高于FLAT |
| 适用数据量 | 10万~1000万条向量(中小规模场景) |
四、适用场景
✅ 中小规模向量库(10万~1000万条)、需要平衡“速度与精度”的场景(如企业知识库、中等流量推荐系统);
❌ 超大规模数据(>1000万条,建议用HNSW)、极端高精度需求(需用FLAT)。
五、实操代码(Milvus)
# 配置IVF_FLAT索引
index_params = client.prepare_index_params().add_index(
field_name="vector",
index_type="IVF_FLAT", # 索引类型:IVF_FLAT
metric_type="Cosine",
params={
"nlist": 1000, # 簇数量
"nprobe": 20 # 搜索簇数量(检索时可动态调整)
}
)
2.3 IVF_PQ:倒排文件与乘积量化
IVF_PQ(Inverted File + Product Quantization)是在IVF_FLAT基础上结合**乘积量化(PQ)**的向量索引,核心是“聚类缩小范围+向量压缩”——既通过IVF的簇分区减少检索空间,又用PQ将高维向量压缩为低维编码,大幅降低存储开销与计算成本,适配百万~亿级大规模向量库。
一、核心原理:IVF聚类 + 乘积量化
IVF_PQ的工作分为离线编码和在线检索两步,核心是“向量分块压缩+倒排索引”:
- 离线编码(索引构建):
- 步骤1:IVF聚类:用K-means将向量聚成
nlist个簇,建立“簇中心→簇内向量”的倒排映射(同IVF_FLAT); - 步骤2:乘积量化(PQ):
- 将每个高维向量分块:把D维向量拆分为m个连续的子向量(如768维拆为12个64维子向量);
- 子向量聚类:对每个子向量维度,用K-means聚成k个“子簇中心”(称为“码本,codebook”);
- 向量编码:每个子向量用“距离最近的子簇中心的索引”表示(如用1个字节存储索引),最终整个向量被压缩为m个索引组成的“PQ编码”(存储开销仅为原向量的1/m)。
- 步骤1:IVF聚类:用K-means将向量聚成
- 在线检索(查询匹配):
- 计算查询向量与簇中心的相似度,选择
nprobe个目标簇; - 将查询向量也拆分为m个子向量,计算每个子向量与对应码本子簇中心的距离,得到“距离表”;
- 用“距离表”快速计算查询向量与目标簇内所有向量的PQ编码的近似距离,排序后返回Top K结果。
- 计算查询向量与簇中心的相似度,选择
二、关键参数(平衡存储、速度、精度)
| 参数 | 含义 | 调优建议 |
|---|---|---|
nlist |
IVF的簇数量 | 同IVF_FLAT(数据量的1/1000~1/100) |
nprobe |
检索时选择的簇数量 | 同IVF_FLAT(nlist的1%~5%) |
m |
向量分块数(PQ的子向量数量) | 常用12/24(分块越多,压缩率越高,精度略降) |
k |
每个子向量的码本大小(子簇数量) | 常用256(即每个子向量用1字节编码) |
三、核心特性
- 存储开销极低:高维向量被压缩为PQ编码(如768维向量→12字节编码,压缩率64:1);
- 检索速度快:IVF缩小范围+PQ编码的近似距离计算,比IVF_FLAT快1~2个数量级;
- 精度可控:通过
nprobe和m调优(nprobe越大、m越小,精度越高),最高接近IVF_FLAT; - 适用数据量:百万~亿级向量库(大规模场景的主流选择)。
四、适用场景
✅ 亿级大规模向量库(如推荐系统、大规模知识库)、存储资源有限的场景、高并发低延迟需求;
❌ 极端高精度场景(需用FLAT/IVF_FLAT)、小数据量场景(压缩收益不明显)。
2.4 HNSW:分层可导航小世界
HNSW(Hierarchical Navigable Small World)是基于分层图结构的向量索引,核心是“模拟小世界网络的分层导航”——通过构建多层连接的图结构,检索时从顶层快速定位大致范围,再逐层向下精细搜索,兼顾了检索速度与精度,是当前大规模向量库(亿级+)的主流选择之一。
一、核心原理:分层小世界图
HNSW的“小世界”指图中节点(向量)间存在“短路径连接”,分层结构则让检索能“先粗后细”,工作分为离线建图和在线检索两步:
- 离线建图(分层图构建):
- 为每个向量随机分配一个“层数”(顶层向量少,底层向量多);
- 从顶层开始,为每个向量在同层/高层中选择
M个“近邻节点”建立连接(M是每个节点的最大连接数); - 逐层向下构建,最终形成“顶层稀疏、底层稠密”的分层图结构。
- 在线检索(分层导航):
- 从顶层任意节点(入口点)开始,搜索当前层的近邻节点,找到与查询向量最相似的节点,作为下一层的入口;
- 逐层下探至底层,在底层以
ef为搜索广度(ef是底层搜索的候选节点数),遍历近邻节点,最终找到Top K最相似向量。
二、关键参数(平衡速度与精度)
| 参数 | 含义 | 调优建议 |
|---|---|---|
M |
每个节点的最大连接数 | 常用16~64(M越大,精度越高、速度越慢) |
ef_construction |
建图时的搜索广度 | 建议为M×2(如M=16时,ef_construction=32) |
ef |
检索时的底层搜索广度 | 常用100~200(ef越大,精度越高、延迟越高) |
三、核心特性
- 检索速度极快:分层导航避免全量扫描,亿级数据也能毫秒级响应;
- 精度高:近似精度可达95%~99%(接近IVF_FLAT);
- 可扩展性强:支持亿级以上大规模向量库;
- 存储开销中等:需额外存储节点连接关系,开销略高于IVF_PQ。
四、适用场景
✅ 亿级大规模向量库(如电商推荐、短视频检索)、高并发低延迟场景、对精度要求较高的大规模检索;
❌ 小数据量场景(建图开销大于收益)、极端存储受限场景(优先选IVF_PQ)。
2.5 DISKANN(磁盘版图索引)
DISKANN(Disk - based Approximate Nearest Neighbor)是专为超大规模向量检索设计的磁盘优化图索引,核心亮点是突破内存限制,将海量向量数据与图索引主体存储在SSD,仅通过内存缓存轻量信息,结合优化的Vamana图结构减少磁盘IO开销,实现了亿级到百亿级数据下高召回率与低成本的平衡,是大规模向量检索中兼顾性价比和稳定性的优选方案。
一、核心原理:Vamana图与磁盘协同架构
DISKANN的核心是基于Vamana图结构,并通过磁盘 - 内存协同策略解决大规模数据的存储与检索效率问题,整体流程分为离线建索引和在线检索两部分:
- 离线建索引(分块构图+磁盘存储)
- 数据分簇分片:先通过全局Kmeans将海量向量分成若干个簇,每个向量会分配到1 - 2个相近簇中,以此拆分超大规模数据集,适配内存有限的建图需求;
- 构建Vamana子图:为每个簇单独构建Vamana图索引,该图通过两轮裁边策略优化——首轮用较严格的裁边条件精简边数,第二轮放松裁边参数增加长边,最终形成直径小、搜索跳数少的高效图结构,其搜索性能不逊色于HNSW等主流图索引;
- 索引合并落盘:将所有簇的Vamana子图合并为全局索引,同时把原始向量数据、图的邻接关系等核心数据存储到SSD,仅将压缩后的PQ码、热点节点等轻量信息预留缓存空间,大幅降低内存占用。
- 在线检索(缓存加速+批量IO)
- 缓存优先查询:检索时优先从内存缓存中读取热点节点和压缩向量,快速完成粗粒度筛选,减少磁盘访问频次;
- 批量磁盘读取:当需要访问非缓存节点时,利用beam search策略批量加载多个节点的邻接信息和向量数据。由于磁盘单次少量随机访问与单扇区访问耗时接近,批量操作可显著减少IO轮次;
- 精确距离重排:粗筛阶段用内存中的压缩向量计算距离,确定候选集后,再读取磁盘中对应的原始向量计算精确距离,最终返回Top - K最相似结果,兼顾效率与精度。
二、关键参数(适配磁盘与性能平衡)
DISKANN的参数调优聚焦于控制索引规模、磁盘IO和召回率,在Milvus等向量数据库中的核心参数如下:
| 参数 | 含义 | 调优建议 |
|---|---|---|
MaxDegree |
Vamana图中节点的最大连接数 | 默认值56,取值范围1 - 512。数值越大召回率越高,但会增加索引体积和建图时间,百亿级数据可适当调至80 - 128 |
search_list |
检索时的候选列表大小 | 默认值16,需大于查询的Top - K值。增大该值可提升召回率,但会增加检索时延 |
SearchListSize |
建索引时的候选列表大小 | 默认值100,建议设置为小于MaxDegree的值,若无需缩短建图时间,保持默认即可保障召回率 |
BeamWidthRatio |
每次迭代的最大IO请求数与CPU数量的比值 | 默认值4.0,取值需匹配磁盘IO能力,过高易造成带宽浪费,过低则无法发挥多路读取优势 |
PQCodeBugetGBRatio |
PQ量化代码的内存占用比例 | 默认值0.125,范围0.0 - 0.25,增大可提升检索速度,但会增加内存开销 |
三、核心特性
- 极致内存节省:仅缓存轻量数据,原始向量和索引常驻SSD,相比HNSW可节省95%以上的内存资源,1台64G内存机器即可支撑十亿级向量检索;
- 高召回且低时延:依托Vamana图的高效结构,召回率可达95%以上,配合批量IO优化,单查询平均时延可控制在毫秒级,十亿级数据集QPS能达到5000;
- 可扩展性极强:从千万级到百亿级数据规模,查询性能波动小,且支持与RaBitQ等量化算法结合,进一步降低内存占用或提升性能;
- 灵活适配场景:支持磁盘模式(低成本大规模存储)和性能模式(全量加载内存追求极致速度)两种部署方式。
四、适用场景
✅ 百亿级大规模向量存储场景,如大模型RAG知识库、百亿级商品推荐、短视频检索;
✅ 内存成本敏感场景,需在控制硬件开销的同时保障高召回率;
❌ 极致低时延的内存优先场景(优先选HNSW);
❌ 小数据量场景(建图和分块开销大于收益,FLAT或IVF_FLAT更高效)。
五、与其他主流索引的对比
| 索引类型 | 速度 | 精度 | 适用数据量 | 内存开销 |
|---|---|---|---|---|
| FLAT | 极慢 | 100% | ≤10万条 | 极高 |
| IVF_FLAT | 中等 | ≈98% | 10万 - 1000万条 | 高 |
| IVF_PQ | 极快 | ≈90% | 1000万 - 10亿条 | 极低 |
| HNSW | 极快 | ≈98% | ≥1亿条 | 中等 |
| DISKANN | 快 | ≈95% | ≥10亿条 | 极低 |
2.6 各种索引类型

2.7 选型快速预览

2.8 Milvus中索引的工作机制
Milvus 向量索引的核心是 “数据结构粗过滤→量化加速计算→精炼器重排修正” 的三层协同架构,通过“先粗筛、再加速、最后精准修正”的流程,实现“大规模数据下效率与精度的平衡”。
一、三层架构的具体分工
Milvus 索引的每个模块承担不同职责,环环相扣保障检索效果:
-
数据结构(粗过滤:缩小检索范围)
- 作用:从全量向量中快速筛选出与查询向量“可能相关”的候选子集,避免全量扫描;
- 实现方式:
- 如 IVF 类索引:通过 K-means 聚类将向量划分为多个“桶”,仅扫描与查询向量最接近的若干桶;
- 如 HNSW 类索引:通过分层图结构,从顶层快速定位到底层的近邻区域,仅遍历局部节点;
- 核心目标:将检索范围从“全量”缩小到“小部分候选集”,是提升速度的基础。
-
量化(加速计算:降低资源开销)
- 作用:对粗过滤后的候选向量做“有损压缩”,用低精度编码(如 8 位整数)替代 32 位浮点向量,减少内存占用与距离计算耗时;
- 实现方式:
- 如 SQ8:将向量归一化后压缩为 8 位整数;
- 如 PQ:将向量分块后用“码本索引”表示;
- 核心目标:以轻微精度损失为代价,大幅提升候选集的距离计算速度。
-
精炼器(精准重排:修正精度)
- 作用:弥补量化的精度损失,对量化后的候选集(通常取
topK×扩展率个结果,如top10×2=20个候选),用原始 32 位浮点向量重新计算精确距离,再排序得到最终topK结果; - 核心目标:在“加速计算”的基础上,把精度拉回接近原始向量比对的水平,保障最终结果的高质量。
- 作用:弥补量化的精度损失,对量化后的候选集(通常取
二、完整检索流程(以 HNSW+PQ+精炼器为例)
以“用户查询‘2025 新能源政策’”为例,Milvus 索引的工作流程为:
- SearchReq 发起:用户请求检索向量字段,指定返回
top10结果; - 数据结构粗筛:HNSW 分层图快速定位到查询向量的近邻区域,筛选出 100 个候选向量;
- 量化加速计算:用 PQ 编码快速计算这 100 个候选与查询向量的近似距离,初步排序后取
top20(top10×2); - 精炼器重排:加载这 20 个候选的原始 32 位浮点向量,计算精确距离,重新排序后取
top10返回给用户。
三、核心优势
- 效率与精度的平衡:粗过滤解决“全量扫描慢”的问题,量化解决“计算开销大”的问题,精炼器解决“精度损失”的问题,三者结合实现“快且准”;
- 模块可灵活组合:数据结构(如 HNSW/IVF)、量化算法(如 PQ/SQ8)可按需搭配(例如 IVF+PQ、HNSW+SQ8),适配不同场景的速度/精度需求;
- 适配大规模数据:三层架构的分工让 Milvus 能支撑亿级甚至百亿级向量的低延迟检索。
2.9 内存估算

3. 检索(搜索)、度量类型 和 条件过滤
3.1 ANN搜索
Milvus的ANN搜索是一种高效的向量相似度搜索方法,它通过预构建的索引文件来加速搜索过程。与kNN搜索相比,ANN搜索不需要遍历所有向量,而是通过索引快速定位可能包含最相似向量的子集,从而大大提高了搜索效率。
主要特点包括:
- 支持单向量和批量向量搜索
- 可以在特定分区内进行搜索
- 支持多种相似度度量方式(L2、IP、COSINE等)
- 可以通过过滤条件、范围搜索等方式增强搜索效果
- 支持分页查询和输出字段控制

3.2 距离度量
- L2(欧氏距离)
• 适用于连续数值型特征,如图像像素或声纹特征;
• 常见于需要精确度量“几何距离”的场景,例如视觉检索、点云匹配等。 - IP(内积)
• 在向量长度(范数)有意义时使用,比如评估未归一化嵌入向量的匹配强度;
• 若向量已归一化,等价于余弦相似度,可用于文本或推荐系统中的评分计算。 - COSINE(余弦相似度)
• 最常用于文本、自然语言嵌入之间的语义相似性计算;
• 不受向量长度影响,关注方向一致性,适合主题或意图匹配。 - JACCARD(交并比距离)
• 用于集合或二值特征的相似度评估,如标签集合、关键词重叠;
• 在文本片段重叠、推荐系统中基于兴趣标签的匹配场景常见。 - HAMMING(海明距离)
• 专用于二进制向量(如感知哈希、二值化特征)的相似度度量;
• 常见于图像指纹检索、人脸二值编码或者简易哈希匹配场景。 - BM25(全文检索评分)
• 专为稀疏向量上的全文搜索设计,结合 TF、IDF 和文档长度归一化;
• 适用于文档检索、问答系统的倒排索引搜索场景。
3.2.1 字段支持的度量类型

3.2.2 各种度量类型的取值范围

3.3 过滤搜索
标准过滤会先过滤再搜索,迭代过滤会边搜索边过滤,这在处理复杂过滤条件时可能会更高效。
3.4 范围搜索
- 范围搜索是在 ANN 搜索结果的基础上,进一步按相似度(或距离)
阈值进行筛选,将符合条件的向量返回。 - 通过两个参数 radius(外圈半径)和 range_filter(内圈半径)构成一
对同心圆,返回落在这两个圆之间(或内外圈定义区间内)的所有向量。
3.5 分组搜索
目的:在基于向量的相似度搜索结果中,按某个标量字段(如 docId、category)分组,以提高结果多样性,避免同一组内多个相似片段抢占 Top-K。
场景举例:对拆分成多个段落的文档做检索,希望最终返回最相关的文档列表,而不是返回同一文档中多个相似段落。
流程:
1.ANN 检索 对整个集合执行近似最近邻搜索,得到若干最相似实体(chunk)。
2.按字段分组 将检索结果按 group_by_field 指定的字段值(如 docId)分桶。
3.选取每组 TopN 默认从每个组中取最相似的 1条; 如需更多,可通过 group_size(每组返回条数)和 strict_group_size(是否严格保证每组条数)进行控制。
4.整体汇总 最终按组级 TopK(limit)选出若干组,并返回各组内按相似度排序的实体。
3.6 混合搜索
同时对同一实体中的多种向量字段(如稠密向量 dense 与稀疏向量 sparse)
分别执行 ANN 搜索,将各自返回的 Top-K 结果按得分或排名策略重新融合
(rerank),最后输出一个统一的结果集。
目的:融合多模态或多视角特征,提高检索的准确性和鲁棒性。

- Embedding 生成
• 稠密向量(dense):用 BERT、CLIP、其他深度模型生成。
• 稀疏向量(sparse):用 BM25、SPLADE、BGE-M3 等算法或 Milvus Function 生成。 - 创建集合并定义多向量字段
• 在建表时同时包括 FLOAT_VECTOR(稠密)
• 和 SPARSE_FLOAT_VECTOR(稀疏)字段, 并分别建立索引。 - 插入数据
• 同一条记录同时插入两种向量。
• 发起多次基础 ANN 搜索
• 针对每个向量字段构造一个AnnSearchRequest - 选择重排序(Reranking)策略
• WeightedRanker:可为每个向量字段分配权重,强化某些字段的重要性
• RRFRanker(Reciprocal Rank Fusion):平衡融合,默认参数 k 可调 - 执行 Hybrid Search
• limit 决定最终输出的 Top-K 条融合结果。
3.7 BM25 全文关键字检索
通过 BM25 对原始文本进行关键词匹配排序,弥补语义向量检索可能忽略精确词条匹配的不足.
优势:
• 接受原始文本输入,无需手动生成向量;
• 自动将文本分词、映射为稀疏向量(PARSE_FLOAT_VECTOR);
• 适合需精确命中关键术语的场景,如法律、医药、配置文档等;
• 与稠密向量检索结合,可在 RAG 中实现“语义 + 关键词”双保险。

3.8 Text Match: 精确文本匹配
- 精确匹配:基于倒排索引查找包含指定词条的文档,不计算相关度分数,仅返回命中实体。
- 底层引擎:集成 Tantivy ,针对每个 VARCHAR 字段建立倒排索引,按词条快速定位
– 包含 machine 或 deep
TEXT_MATCH(text, ‘machine deep’)
– 包含 machine 且包含 deep
TEXT_MATCH(text, ‘machine’) AND TEXT_MATCH(text, ‘deep’)
– 包含 machine、learning,但不包含 deep
TEXT_MATCH(text, ‘machine’)
AND TEXT_MATCH(text, ‘learning’)
AND NOT TEXT_MATCH(text, ‘deep’)
3.9 搜索和查询
搜索是根据度量标准找到相似(距离相近)的向量;
查询是根据元数据直接定位实体;

4. 多模态检索方案


火山引擎开发者社区是火山引擎打造的AI技术生态平台,聚焦Agent与大模型开发,提供豆包系列模型(图像/视频/视觉)、智能分析与会话工具,并配套评测集、动手实验室及行业案例库。社区通过技术沙龙、挑战赛等活动促进开发者成长,新用户可领50万Tokens权益,助力构建智能应用。
更多推荐
所有评论(0)