一、环境准备1. 基础环境Windows 11Docker Desktop开启 WSL22. GPU 环境可选nvidia-smiDocker GPU 测试dockerrun--rm--gpusall nvidia/cuda:12.3.1-base-ubuntu22.04 nvidia-smi输出如下-----------------------------------------------------------------------------------------|NVIDIA-SMI580.102.01 Driver Version:581.57CUDA Version:13.0|---------------------------------------------------------------------------------------|GPU Name Persistence-M|Bus-Id Disp.A|Volatile Uncorr. ECC||Fan Temp Perf Pwr:Usage/Cap|Memory-Usage|GPU-Util Compute M.||||MIG M.||||0NVIDIA GeForce RTX4060Ti On|00000000:01:00.0 On|N/A||0% 40C P3 14W / 160W|3712MiB / 8188MiB|26% Default||||N/A|--------------------------------------------------------------------------------------- -----------------------------------------------------------------------------------------|Processes:||GPU GI CI PID Type Process name GPU Memory||ID ID Usage||||0N/A N/A35G /Xwayland N/A|-----------------------------------------------------------------------------------------二、Milvus 2.6.2 部署1. 创建目录D:\environment\Docker\milvus2. docker-compose.yml在目录下创建docker-compose.ymlversion:3.5services:etcd:container_name:milvus-etcdimage:quay.io/coreos/etcd:v3.5.5environment:-ETCD_AUTO_COMPACTION_MODErevision-ETCD_AUTO_COMPACTION_RETENTION1000command:etcd-advertise-client-urlshttp://127.0.0.1:2379-listen-client-urlshttp://0.0.0.0:2379ports:-2379:2379minio:container_name:milvus-minioimage:minio/minio:RELEASE.2023-03-20T20-16-18Zenvironment:MINIO_ACCESS_KEY:minioadminMINIO_SECRET_KEY:minioadmincommand:server /dataports:-9000:9000milvus:container_name:milvus-standaloneimage:milvusdb/milvus:v2.6.2command:[milvus,run,standalone]environment:ETCD_ENDPOINTS:etcd:2379MINIO_ADDRESS:minio:9000ports:-19530:19530-9091:9091depends_on:-etcd-minio3. 启动 Milvusdocker-composeup-d4. 验证dockerps端口说明端口协议作用19530gRPC向Milvus插入向量、查询向量、管理集合等操作9091HTTP状态监控、Prometheus 采集指标、一些管理 UI 或 HTTP API三、Milvus 核心概念在使用 Milvus 之前需要先理解其核心数据结构这对于后续索引选择和查询优化非常重要。1. Collection集合Collection 可以理解为关系型数据库中的“表”。用于存储向量数据及其相关字段每个 Collection 都有固定的 Schema字段定义一般包含主键ID向量字段Vector业务字段如文本、来源等类比MySQL → TableElasticsearch → IndexMilvus → Collection2. Field字段Field 是 Collection 中的列定义常见类型包括INT64主键FLOAT_VECTOR向量字段核心VARCHAR文本字段其中最重要的是向量字段例如embedding: { type: FLOAT_VECTOR, dim: 1024 } 这里的dim表示向量维度必须和 embedding 模型一致。3. Segment数据分片Segment 是 Milvus 的底层存储单元。可以理解为Collection 并不是一个整体存储而是被拆分成多个 Segment特点数据写入时先进入 growing segment达到一定大小后转为 sealed segment查询时会在多个 segment 上并行执行索引是构建在 segment 级别而不是 collection 级别4. Index索引Milvus 的索引用于加速向量相似度搜索。本质上解决的问题是在海量向量中如何快速找到最相似的 TopK不同索引的核心区别在于精度Recall查询速度内存占用常见索引类型FLAT精确搜索IVF聚类加速HNSW图结构5.GUI官方GUI链接https://github.com/zilliztech/attu/releases四、向量索引类型详解在 Milvus 中不同索引决定了检索性能与精度的平衡。1. FLAT暴力检索原理对所有向量逐一计算距离全量扫描。特点✅ 召回率100%最准确❌ 速度慢数据量大时不可用适用场景数据量小精度要求极高评估/测试2. IVF倒排索引原理先对向量进行聚类KMeans查询时只搜索部分聚类。流程数据被划分为多个 clusternlist查询时只访问部分 clusternprobe核心参数nlist建索引时聚类数量越大 → 更精细 → 更慢构建nprobe查询时查询多少个 cluster越大 → 召回率更高但更慢IVF 的核心思想是用空间换时间通过减少搜索范围提升性能。3. HNSW图索引原理构建多层“近邻图”通过图遍历找到最相似向量。核心参数M每个节点连接的边数越大 → 精度高但内存大efConstruction构建图时的搜索深度ef查询参数查询时遍历深度越大 → 更准但更慢特点✅ 高召回率接近 FLAT✅ 查询速度快❌ 内存占用高对比索引类型召回率速度内存适用场景FLAT100%慢高小数据IVF中快中大规模HNSW高很快高高性能检索五、查询机制与核心参数Milvus 查询本质是给定一个向量找到最相似的 TopK 个向量1. TopK返回最相似的 K 条数据K 越大 → 查询时间越长2. 距离度量Metric Type常见三种L2欧式距离两个向量在空间中的“直线距离”IP内积本质是计算两个向量的“方向一致性 长度”COSINE余弦相似度必须和 embedding 模型匹配否则效果会很差3. IVF 查询参数nprobe控制搜索范围越大 → 召回率更高4. HNSW 查询参数ef控制搜索深度越大 → 更准查询参数nprobe / ef本质上是在控制“搜索范围”从而在性能 vs 召回率之间做权衡。六、如何提升召回率在实际项目特别是 RAG中召回率直接决定效果上限。1. 调整查询参数IVF → 提高nprobeHNSW → 提高ef 最直接有效的方法2. 选择合适索引高精度 → HNSW大规模 → IVF3. 提升向量质量最重要使用更强的 embedding 模型如 bge-m3优化文本切分chunk清洗数据4. 混合检索推荐 结合Elasticsearch关键词Milvus向量 提升召回覆盖率语义 精确匹配5. 重排Rerank流程先召回 TopKMilvus / ES使用 rerank 模型重新排序 常见方式Cross EncoderRRF融合排序
Milvus 从环境搭建到检索优化
一、环境准备1. 基础环境Windows 11Docker Desktop开启 WSL22. GPU 环境可选nvidia-smiDocker GPU 测试dockerrun--rm--gpusall nvidia/cuda:12.3.1-base-ubuntu22.04 nvidia-smi输出如下-----------------------------------------------------------------------------------------|NVIDIA-SMI580.102.01 Driver Version:581.57CUDA Version:13.0|---------------------------------------------------------------------------------------|GPU Name Persistence-M|Bus-Id Disp.A|Volatile Uncorr. ECC||Fan Temp Perf Pwr:Usage/Cap|Memory-Usage|GPU-Util Compute M.||||MIG M.||||0NVIDIA GeForce RTX4060Ti On|00000000:01:00.0 On|N/A||0% 40C P3 14W / 160W|3712MiB / 8188MiB|26% Default||||N/A|--------------------------------------------------------------------------------------- -----------------------------------------------------------------------------------------|Processes:||GPU GI CI PID Type Process name GPU Memory||ID ID Usage||||0N/A N/A35G /Xwayland N/A|-----------------------------------------------------------------------------------------二、Milvus 2.6.2 部署1. 创建目录D:\environment\Docker\milvus2. docker-compose.yml在目录下创建docker-compose.ymlversion:3.5services:etcd:container_name:milvus-etcdimage:quay.io/coreos/etcd:v3.5.5environment:-ETCD_AUTO_COMPACTION_MODErevision-ETCD_AUTO_COMPACTION_RETENTION1000command:etcd-advertise-client-urlshttp://127.0.0.1:2379-listen-client-urlshttp://0.0.0.0:2379ports:-2379:2379minio:container_name:milvus-minioimage:minio/minio:RELEASE.2023-03-20T20-16-18Zenvironment:MINIO_ACCESS_KEY:minioadminMINIO_SECRET_KEY:minioadmincommand:server /dataports:-9000:9000milvus:container_name:milvus-standaloneimage:milvusdb/milvus:v2.6.2command:[milvus,run,standalone]environment:ETCD_ENDPOINTS:etcd:2379MINIO_ADDRESS:minio:9000ports:-19530:19530-9091:9091depends_on:-etcd-minio3. 启动 Milvusdocker-composeup-d4. 验证dockerps端口说明端口协议作用19530gRPC向Milvus插入向量、查询向量、管理集合等操作9091HTTP状态监控、Prometheus 采集指标、一些管理 UI 或 HTTP API三、Milvus 核心概念在使用 Milvus 之前需要先理解其核心数据结构这对于后续索引选择和查询优化非常重要。1. Collection集合Collection 可以理解为关系型数据库中的“表”。用于存储向量数据及其相关字段每个 Collection 都有固定的 Schema字段定义一般包含主键ID向量字段Vector业务字段如文本、来源等类比MySQL → TableElasticsearch → IndexMilvus → Collection2. Field字段Field 是 Collection 中的列定义常见类型包括INT64主键FLOAT_VECTOR向量字段核心VARCHAR文本字段其中最重要的是向量字段例如embedding: { type: FLOAT_VECTOR, dim: 1024 } 这里的dim表示向量维度必须和 embedding 模型一致。3. Segment数据分片Segment 是 Milvus 的底层存储单元。可以理解为Collection 并不是一个整体存储而是被拆分成多个 Segment特点数据写入时先进入 growing segment达到一定大小后转为 sealed segment查询时会在多个 segment 上并行执行索引是构建在 segment 级别而不是 collection 级别4. Index索引Milvus 的索引用于加速向量相似度搜索。本质上解决的问题是在海量向量中如何快速找到最相似的 TopK不同索引的核心区别在于精度Recall查询速度内存占用常见索引类型FLAT精确搜索IVF聚类加速HNSW图结构5.GUI官方GUI链接https://github.com/zilliztech/attu/releases四、向量索引类型详解在 Milvus 中不同索引决定了检索性能与精度的平衡。1. FLAT暴力检索原理对所有向量逐一计算距离全量扫描。特点✅ 召回率100%最准确❌ 速度慢数据量大时不可用适用场景数据量小精度要求极高评估/测试2. IVF倒排索引原理先对向量进行聚类KMeans查询时只搜索部分聚类。流程数据被划分为多个 clusternlist查询时只访问部分 clusternprobe核心参数nlist建索引时聚类数量越大 → 更精细 → 更慢构建nprobe查询时查询多少个 cluster越大 → 召回率更高但更慢IVF 的核心思想是用空间换时间通过减少搜索范围提升性能。3. HNSW图索引原理构建多层“近邻图”通过图遍历找到最相似向量。核心参数M每个节点连接的边数越大 → 精度高但内存大efConstruction构建图时的搜索深度ef查询参数查询时遍历深度越大 → 更准但更慢特点✅ 高召回率接近 FLAT✅ 查询速度快❌ 内存占用高对比索引类型召回率速度内存适用场景FLAT100%慢高小数据IVF中快中大规模HNSW高很快高高性能检索五、查询机制与核心参数Milvus 查询本质是给定一个向量找到最相似的 TopK 个向量1. TopK返回最相似的 K 条数据K 越大 → 查询时间越长2. 距离度量Metric Type常见三种L2欧式距离两个向量在空间中的“直线距离”IP内积本质是计算两个向量的“方向一致性 长度”COSINE余弦相似度必须和 embedding 模型匹配否则效果会很差3. IVF 查询参数nprobe控制搜索范围越大 → 召回率更高4. HNSW 查询参数ef控制搜索深度越大 → 更准查询参数nprobe / ef本质上是在控制“搜索范围”从而在性能 vs 召回率之间做权衡。六、如何提升召回率在实际项目特别是 RAG中召回率直接决定效果上限。1. 调整查询参数IVF → 提高nprobeHNSW → 提高ef 最直接有效的方法2. 选择合适索引高精度 → HNSW大规模 → IVF3. 提升向量质量最重要使用更强的 embedding 模型如 bge-m3优化文本切分chunk清洗数据4. 混合检索推荐 结合Elasticsearch关键词Milvus向量 提升召回覆盖率语义 精确匹配5. 重排Rerank流程先召回 TopKMilvus / ES使用 rerank 模型重新排序 常见方式Cross EncoderRRF融合排序
