学习笔记详述 RAG 系统中向量数据库的核心原理、ANN 索引算法、主流数据库对比以及工程实践目录为什么需要向量数据库Embedding 算法演进第一代静态词向量第二代上下文向量第三代句级对比学习最新趋势向量数据库核心概念什么是向量数据库与传统数据库的区别核心能力ANN 索引算法HNSW 算法IVF 算法IVF-PQ 算法索引算法对比向量量化压缩标量量化 SQ8乘积量化 PQ量化方法对比主流向量数据库对比MilvusQdrantChromaWeaviateFAISSpgvectorPinecone选型指南向量数据库工程实践Milvus 生产实践案例内存计算与优化性能瓶颈与解决方案参考资料为什么需要向量数据库RAG 系统中文档经过 Embedding 模型转化为高维向量后需要一个专门的存储和检索系统。向量数据库的核心能力是近似最近邻搜索ANN能在百万甚至亿级向量中快速找到最相似的结果。为什么不用传统数据库传统关系型数据库如 MySQL依赖B-tree 索引擅长一维有序数据的精确匹配。但高维向量的近似是多维度的整体判断B-tree 无法有效处理。暴力遍历计算所有向量的相似度在百万级数据上延迟不可接受。向量数据库通过专用索引结构如 HNSW、IVF将延迟降到毫秒级。Embedding 算法演进理解 Embedding 算法的演进有助于选择合适的模型。三代算法逐步解决了前一代的核心缺陷。第一代静态词向量Word2Vec / GloVe / FastText每个词映射为一个固定向量不随上下文变化。模型年份核心思想特点Word2Vec2013, GoogleCBOW / Skip-gramSkip-gram 更常用对稀有词效果好GloVeStanford全局共现矩阵分解利用全局统计信息效果与 Word2Vec 相当FastTextFacebook子词n-gram分解解决未登录词OOV问题经典特性国王 - 男人 女人 ≈ 女王致命缺陷每个词只有一个固定向量无法处理多义词。“苹果” 在 “我吃了苹果” 和 “苹果手机” 中向量完全相同。第二代上下文向量ELMo / BERT向量随上下文动态变化同一词在不同句子中产生不同向量。模型年份核心思想特点ELMo2018, Allen NLP双向 LSTM第一个实用的上下文 EmbeddingBERT2018, GoogleTransformer MLM全双向注意力[CLS]句向量检索场景的致命缺陷比较两个句子必须将它们拼接后输入 BERT。百万文档意味着百万次前向传播每次数十毫秒总计数小时——无法用于实时检索。第三代句级对比学习SBERT / SimCSE / BGE专为句子相似度和语义检索设计是 RAG 系统的标准选择。模型年份核心思想特点SBERT2019双编码器架构两句独立编码速度提升数个数量级SimCSE2021, Princeton对比学习 Dropout解决 BERT 向量各向异性问题BGEBAAI大规模双语对比学习中文 RAG 首选E5Microsoft指令微调英文高精度SBERT 的核心突破传统 BERT 检索Doc1 Query → BERT → 相似度 每次都要拼接慢 SBERT 检索 Doc1 → BERT → Vec1 预计算存起来 Query → BERT → VecQ 只算一次 VecQ × Vec1 → 相似度 毫秒级文档向量可预计算存储查询时只需编码查询文本实现毫秒级检索。最新趋势2025-2026趋势说明指令感知 Embedding如 Qwen3-Embedding同一文本在不同检索指令下产生不同向量Matryoshka 表示学习前 N 维保留语义支持灵活降维平衡精度与存储多模态 Embedding单模型编码文本和图像支持跨模态检索三代算法对比代次代表模型核心特性局限RAG 适用性第一代Word2Vec, GloVe词级静态向量无法处理多义词词级非句级不适用第二代ELMo, BERT上下文动态向量需拼接两句子才能比较极慢不适合实时检索第三代SBERT, BGE, E5句级双编码器 对比学习精度略低于交叉编码器标准选择向量数据库核心概念什么是向量数据库向量数据库是专为存储和检索高维向量而设计的数据库核心能力是近似最近邻搜索ANN。存储的向量是 Embedding 模型产生的浮点数数组如 768 或 1024 维每个向量代表源内容的语义信息——语义相似的内容向量距离更近。与传统数据库的区别方面MySQL 等关系型数据库向量数据库索引方式B-tree一维精确匹配HNSW/IVF多维近似匹配查询语义精确匹配,LIKE语义相似“最像什么”数据类型结构化字段高维浮点向量典型场景按 ID 查用户、按日期筛选按语义找相似文档核心能力1. 元数据过滤混合检索每个向量可携带元数据字段如部门、日期、来源。检索时先用过滤条件缩小范围再执行 ANN 搜索。先搜索再过滤会浪费检索槽位在不相关结果上。2. 实时更新主流向量数据库支持在线写入和增量索引构建——新数据到达后无需停止服务重建索引。3. 关键词搜索集成纯向量检索对精确术语如产品型号、专有名词效果差。部分数据库同时支持向量检索 BM25 关键词搜索实现混合召回。ANN 索引算法ANNApproximate Nearest Neighbor是向量数据库的核心搜索范式通过牺牲少量精度换取大幅检索速度提升。HNSW 算法Hierarchical Navigable Small World核心原理基于跳表Skip List 小世界图Small World Graph的多层图结构。关键参数参数说明推荐值M每个节点的最大连接数16-64ef_construction构建时的候选集大小100-200ef_search查询时的候选集大小50-200优势查询速度极快O(log N)召回率高95%支持增量插入。劣势内存占用大图结构需全部加载到内存构建时间较长。默认使用 HNSW 的数据库Qdrant、Milvus、Chroma、Weaviate。IVF 算法Inverted File Index倒排文件索引核心原理先用 K-Means 聚类将向量空间划分为若干个 Voronoi 单元查询时只在最近的几个聚类中搜索。关键参数参数说明推荐值nlist聚类中心数量通常 √Nnprobe查询时探查的聚类数越大召回率越高但速度越慢优势内存效率高可与 PQ 乘积量化结合压缩存储适合超大规模数据。劣势精度略低于 HNSW边界附近的向量可能被遗漏。使用 IVF 的场景Milvus 在超大规模数据场景下使用 IVF 系列索引。IVF-PQ 算法将 IVF 聚类与 PQ 乘积量化结合先用 IVF 聚类缩小搜索范围再对每个聚类内的向量用 PQ 压缩存储。流程原始向量 → IVF 聚类分桶 → 每个桶内向量用 PQ 压缩 → 查询时先定位桶再在桶内用 PQ 查表法计算近似距离。适用场景超大规模亿级、内存受限场景。索引算法对比算法查询复杂度内存需求召回率适用场景HNSWO(log N)高★★★★★高精度、实时查询IVFO(N/nlist·nprobe)中★★★★大规模数据、可调精度IVF-PQ低低★★★超大规模、内存受限ScaNN低中★★★★Google 提出各向异性优化DiskANNO(log N)低★★★★超大规模、SSD 存储主流数据库的索引支持数据库默认索引其他支持MilvusHNSWIVF_FLAT, IVF_PQ, DiskANNWeaviateHNSWFlatQdrantHNSW标量量化FAISSIVFHNSW, PQ, OPQ向量量化压缩向量量化是降低存储成本和提升检索效率的关键技术。核心思想是用更低精度的表示替代原始 float32 向量。标量量化 SQ8Scalar Quantization原理将每个维度的 float324 字节独立量化为 int81 字节。过程 1. 对每个维度找到 min 和 max 2. 线性映射 [min, max] → [0, 255] 3. 查询时逆映射还原近似值 压缩率float32 (32bit) → int8 (8bit)约 4 倍压缩类比相当于把小数精度从 7 位降到 2 位——大部分语义信息存在于高位比特中。效果召回率下降不到 1 个百分点是最具性价比的优化手段。乘积量化 PQProduct Quantization原理将高维向量切分为多个子空间每个子空间独立聚类量化。压缩率float32 (d×32bit) → m×8bit可达数十倍压缩。优势压缩率极高支持高效 ANN 搜索查表法。劣势精度损失较大需要训练码本聚类中心。量化方法对比方法压缩率精度实现复杂度适用场景SQ8~4×较高低精度要求较高中等规模PQ~32×中等较高大规模向量检索内存受限OPQ~32×较高优于 PQ高需要更高精度的大规模场景IVF-PQ高中等高超大规模 内存受限常见变体方法说明OPQ正交旋转优化的 PQ先做旋转再量化RQ残差量化逐级量化残差IVF-PQ先 IVF 聚类再对残差做 PQScaNNGoogle 提出的各向异性量化方法主流向量数据库对比Milvus属性说明开发语言Go / C部署方式单机 / 分布式扩展性★★★★★支持百亿级向量特色水平扩展、读写分离、GPU 加速、丰富索引类型核心概念Collection类似关系数据库的表Segment内部数据管理单元增量段 → 密封段触发索引构建Index支持 HNSW、IVF_FLAT、IVF_PQ、DiskANN 等适用场景企业级生产环境百万到亿级数据需要分布式部署。Qdrant属性说明开发语言Rust部署方式自托管 / 云服务分布式扩展性★★★★十亿级特色高性能、丰富过滤、gRPC REST API适用场景中大规模生产环境需要强过滤能力和高性能。Chroma属性说明开发语言Python部署方式嵌入式 / 客户端-服务器 / 云扩展性★★中小规模特色零配置、上手极快、与 LLM 生态集成好适用场景原型开发、小规模应用、LLM 应用快速集成。Weaviate属性说明开发语言Go部署方式自托管 / 云服务扩展性★★★★特色内置向量化模块、GraphQL API、混合搜索适用场景多模态搜索、需要内置向量化能力。FAISS属性说明开发语言C / Python类型库非完整数据库特色纯索引、GPU 加速、极高性能注意FAISS 是索引库不是数据库——没有持久化、服务器、过滤、CRUD 等功能。适用场景算法研究、高性能离线处理、嵌入式使用。pgvector属性说明类型PostgreSQL 扩展特色无需新组件、SQL JOIN 业务数据、全文搜索融合适用场景已有 PostgreSQL 的团队不想引入新基础设施。Pinecone属性说明类型全托管云服务特色零运维、开箱即用注意费用较高需关注数据驻留和合规问题。选型指南综合对比数据库扩展性易用性混合搜索过滤GPU最佳场景Milvus★★★★★★★★✓✓✓大规模生产Qdrant★★★★★★★★✓✓★✗均衡性能功能Chroma★★★★★★★✗✓✗原型/LLM 应用Weaviate★★★★★★★★✓✓✗多模态搜索FAISS★★★★✗✗✓研究/离线pgvector★★★★★★✓✓✗已有 PG典型迁移路径Chroma原型→ Qdrant生产→ Milvus大规模向量数据库工程实践Milvus 生产实践案例场景知识库检索系统约150 万条 chunk每条为1024 维向量BGE-large-zh 生成HNSW 索引M16, ef_construction128。选型理由数据量超过单机承载能力需要分布式部署知识库每日增量更新需要读写分离性能指标单机16 核32GB RAM千兆局域网HNSW 内存模式ef100指标数值P50 延迟~20msP99 延迟~60ms并发吞吐100 QPS 稳定内存计算与优化原始向量内存150 万 × 1024 维 × 4 字节float32≈6GB仅向量数据Milvus 实际占用约10-12GB额外 4-6GB 用于 HNSW 图结构、元数据、管理开销、OS 缓存SQ8 量化优化状态内存占用召回率变化float32 原始~10GB基准SQ8 量化后~3GB下降 1%额外优化Milvus 支持mmap将原始向量存储在磁盘只在内存中保留索引。原始向量仅在精排阶段读取对查询延迟影响很小。性能瓶颈与解决方案瓶颈 1内存压力导致查询延迟飙升项目说明现象P50 延迟从 20ms 飙升到 2 秒以上原因内存不足OS 频繁 swap 到磁盘解决SQ8 量化将内存从 10GB 降到 3GB消除 swap辅以 mmap 将原始向量存磁盘瓶颈 2批量写入触发 Segment 合并导致查询抖动项目说明现象每日增量更新时 P99 从 60ms 飙升到 300ms原因大量新记录触发后台 Segment 合并合并小段 构建索引CPU 和磁盘 I/O 密集解决 1低峰期调度将批量写入移到凌晨低峰期解决 2分批写入每批限制 500-1000 条间隔数秒将一次大冲击转为多次小冲击分批写入示例# ❌ 一次性写入 50 万条 → 触发大合并查询抖动collection.insert(all_data)# ✅ 分批写入每批 1000 条间隔 3 秒foriinrange(0,len(data),1000):batchdata[i:i1000]collection.insert(batch)time.sleep(3)参考资料HNSW 论文Efficient and Robust Approximate Nearest Neighbor Search using HNSW Graphshttps://arxiv.org/abs/1603.09320FAISS 文档Facebook AI Similarity Searchhttps://github.com/facebookresearch/faissMilvus 官方文档https://milvus.io/docsQdrant 文档https://qdrant.tech/documentation/Chroma 文档https://docs.trychroma.com/Weaviate 文档https://weaviate.io/developers/weaviateANN Benchmarks索引算法性能对比https://ann-benchmarks.com/Product Quantization for Nearest Neighbor Search经典论文https://hal.inria.fr/inria-00514462v2/document
RAG 04：向量数据库与索引算法
学习笔记详述 RAG 系统中向量数据库的核心原理、ANN 索引算法、主流数据库对比以及工程实践目录为什么需要向量数据库Embedding 算法演进第一代静态词向量第二代上下文向量第三代句级对比学习最新趋势向量数据库核心概念什么是向量数据库与传统数据库的区别核心能力ANN 索引算法HNSW 算法IVF 算法IVF-PQ 算法索引算法对比向量量化压缩标量量化 SQ8乘积量化 PQ量化方法对比主流向量数据库对比MilvusQdrantChromaWeaviateFAISSpgvectorPinecone选型指南向量数据库工程实践Milvus 生产实践案例内存计算与优化性能瓶颈与解决方案参考资料为什么需要向量数据库RAG 系统中文档经过 Embedding 模型转化为高维向量后需要一个专门的存储和检索系统。向量数据库的核心能力是近似最近邻搜索ANN能在百万甚至亿级向量中快速找到最相似的结果。为什么不用传统数据库传统关系型数据库如 MySQL依赖B-tree 索引擅长一维有序数据的精确匹配。但高维向量的近似是多维度的整体判断B-tree 无法有效处理。暴力遍历计算所有向量的相似度在百万级数据上延迟不可接受。向量数据库通过专用索引结构如 HNSW、IVF将延迟降到毫秒级。Embedding 算法演进理解 Embedding 算法的演进有助于选择合适的模型。三代算法逐步解决了前一代的核心缺陷。第一代静态词向量Word2Vec / GloVe / FastText每个词映射为一个固定向量不随上下文变化。模型年份核心思想特点Word2Vec2013, GoogleCBOW / Skip-gramSkip-gram 更常用对稀有词效果好GloVeStanford全局共现矩阵分解利用全局统计信息效果与 Word2Vec 相当FastTextFacebook子词n-gram分解解决未登录词OOV问题经典特性国王 - 男人 女人 ≈ 女王致命缺陷每个词只有一个固定向量无法处理多义词。“苹果” 在 “我吃了苹果” 和 “苹果手机” 中向量完全相同。第二代上下文向量ELMo / BERT向量随上下文动态变化同一词在不同句子中产生不同向量。模型年份核心思想特点ELMo2018, Allen NLP双向 LSTM第一个实用的上下文 EmbeddingBERT2018, GoogleTransformer MLM全双向注意力[CLS]句向量检索场景的致命缺陷比较两个句子必须将它们拼接后输入 BERT。百万文档意味着百万次前向传播每次数十毫秒总计数小时——无法用于实时检索。第三代句级对比学习SBERT / SimCSE / BGE专为句子相似度和语义检索设计是 RAG 系统的标准选择。模型年份核心思想特点SBERT2019双编码器架构两句独立编码速度提升数个数量级SimCSE2021, Princeton对比学习 Dropout解决 BERT 向量各向异性问题BGEBAAI大规模双语对比学习中文 RAG 首选E5Microsoft指令微调英文高精度SBERT 的核心突破传统 BERT 检索Doc1 Query → BERT → 相似度 每次都要拼接慢 SBERT 检索 Doc1 → BERT → Vec1 预计算存起来 Query → BERT → VecQ 只算一次 VecQ × Vec1 → 相似度 毫秒级文档向量可预计算存储查询时只需编码查询文本实现毫秒级检索。最新趋势2025-2026趋势说明指令感知 Embedding如 Qwen3-Embedding同一文本在不同检索指令下产生不同向量Matryoshka 表示学习前 N 维保留语义支持灵活降维平衡精度与存储多模态 Embedding单模型编码文本和图像支持跨模态检索三代算法对比代次代表模型核心特性局限RAG 适用性第一代Word2Vec, GloVe词级静态向量无法处理多义词词级非句级不适用第二代ELMo, BERT上下文动态向量需拼接两句子才能比较极慢不适合实时检索第三代SBERT, BGE, E5句级双编码器 对比学习精度略低于交叉编码器标准选择向量数据库核心概念什么是向量数据库向量数据库是专为存储和检索高维向量而设计的数据库核心能力是近似最近邻搜索ANN。存储的向量是 Embedding 模型产生的浮点数数组如 768 或 1024 维每个向量代表源内容的语义信息——语义相似的内容向量距离更近。与传统数据库的区别方面MySQL 等关系型数据库向量数据库索引方式B-tree一维精确匹配HNSW/IVF多维近似匹配查询语义精确匹配,LIKE语义相似“最像什么”数据类型结构化字段高维浮点向量典型场景按 ID 查用户、按日期筛选按语义找相似文档核心能力1. 元数据过滤混合检索每个向量可携带元数据字段如部门、日期、来源。检索时先用过滤条件缩小范围再执行 ANN 搜索。先搜索再过滤会浪费检索槽位在不相关结果上。2. 实时更新主流向量数据库支持在线写入和增量索引构建——新数据到达后无需停止服务重建索引。3. 关键词搜索集成纯向量检索对精确术语如产品型号、专有名词效果差。部分数据库同时支持向量检索 BM25 关键词搜索实现混合召回。ANN 索引算法ANNApproximate Nearest Neighbor是向量数据库的核心搜索范式通过牺牲少量精度换取大幅检索速度提升。HNSW 算法Hierarchical Navigable Small World核心原理基于跳表Skip List 小世界图Small World Graph的多层图结构。关键参数参数说明推荐值M每个节点的最大连接数16-64ef_construction构建时的候选集大小100-200ef_search查询时的候选集大小50-200优势查询速度极快O(log N)召回率高95%支持增量插入。劣势内存占用大图结构需全部加载到内存构建时间较长。默认使用 HNSW 的数据库Qdrant、Milvus、Chroma、Weaviate。IVF 算法Inverted File Index倒排文件索引核心原理先用 K-Means 聚类将向量空间划分为若干个 Voronoi 单元查询时只在最近的几个聚类中搜索。关键参数参数说明推荐值nlist聚类中心数量通常 √Nnprobe查询时探查的聚类数越大召回率越高但速度越慢优势内存效率高可与 PQ 乘积量化结合压缩存储适合超大规模数据。劣势精度略低于 HNSW边界附近的向量可能被遗漏。使用 IVF 的场景Milvus 在超大规模数据场景下使用 IVF 系列索引。IVF-PQ 算法将 IVF 聚类与 PQ 乘积量化结合先用 IVF 聚类缩小搜索范围再对每个聚类内的向量用 PQ 压缩存储。流程原始向量 → IVF 聚类分桶 → 每个桶内向量用 PQ 压缩 → 查询时先定位桶再在桶内用 PQ 查表法计算近似距离。适用场景超大规模亿级、内存受限场景。索引算法对比算法查询复杂度内存需求召回率适用场景HNSWO(log N)高★★★★★高精度、实时查询IVFO(N/nlist·nprobe)中★★★★大规模数据、可调精度IVF-PQ低低★★★超大规模、内存受限ScaNN低中★★★★Google 提出各向异性优化DiskANNO(log N)低★★★★超大规模、SSD 存储主流数据库的索引支持数据库默认索引其他支持MilvusHNSWIVF_FLAT, IVF_PQ, DiskANNWeaviateHNSWFlatQdrantHNSW标量量化FAISSIVFHNSW, PQ, OPQ向量量化压缩向量量化是降低存储成本和提升检索效率的关键技术。核心思想是用更低精度的表示替代原始 float32 向量。标量量化 SQ8Scalar Quantization原理将每个维度的 float324 字节独立量化为 int81 字节。过程 1. 对每个维度找到 min 和 max 2. 线性映射 [min, max] → [0, 255] 3. 查询时逆映射还原近似值 压缩率float32 (32bit) → int8 (8bit)约 4 倍压缩类比相当于把小数精度从 7 位降到 2 位——大部分语义信息存在于高位比特中。效果召回率下降不到 1 个百分点是最具性价比的优化手段。乘积量化 PQProduct Quantization原理将高维向量切分为多个子空间每个子空间独立聚类量化。压缩率float32 (d×32bit) → m×8bit可达数十倍压缩。优势压缩率极高支持高效 ANN 搜索查表法。劣势精度损失较大需要训练码本聚类中心。量化方法对比方法压缩率精度实现复杂度适用场景SQ8~4×较高低精度要求较高中等规模PQ~32×中等较高大规模向量检索内存受限OPQ~32×较高优于 PQ高需要更高精度的大规模场景IVF-PQ高中等高超大规模 内存受限常见变体方法说明OPQ正交旋转优化的 PQ先做旋转再量化RQ残差量化逐级量化残差IVF-PQ先 IVF 聚类再对残差做 PQScaNNGoogle 提出的各向异性量化方法主流向量数据库对比Milvus属性说明开发语言Go / C部署方式单机 / 分布式扩展性★★★★★支持百亿级向量特色水平扩展、读写分离、GPU 加速、丰富索引类型核心概念Collection类似关系数据库的表Segment内部数据管理单元增量段 → 密封段触发索引构建Index支持 HNSW、IVF_FLAT、IVF_PQ、DiskANN 等适用场景企业级生产环境百万到亿级数据需要分布式部署。Qdrant属性说明开发语言Rust部署方式自托管 / 云服务分布式扩展性★★★★十亿级特色高性能、丰富过滤、gRPC REST API适用场景中大规模生产环境需要强过滤能力和高性能。Chroma属性说明开发语言Python部署方式嵌入式 / 客户端-服务器 / 云扩展性★★中小规模特色零配置、上手极快、与 LLM 生态集成好适用场景原型开发、小规模应用、LLM 应用快速集成。Weaviate属性说明开发语言Go部署方式自托管 / 云服务扩展性★★★★特色内置向量化模块、GraphQL API、混合搜索适用场景多模态搜索、需要内置向量化能力。FAISS属性说明开发语言C / Python类型库非完整数据库特色纯索引、GPU 加速、极高性能注意FAISS 是索引库不是数据库——没有持久化、服务器、过滤、CRUD 等功能。适用场景算法研究、高性能离线处理、嵌入式使用。pgvector属性说明类型PostgreSQL 扩展特色无需新组件、SQL JOIN 业务数据、全文搜索融合适用场景已有 PostgreSQL 的团队不想引入新基础设施。Pinecone属性说明类型全托管云服务特色零运维、开箱即用注意费用较高需关注数据驻留和合规问题。选型指南综合对比数据库扩展性易用性混合搜索过滤GPU最佳场景Milvus★★★★★★★★✓✓✓大规模生产Qdrant★★★★★★★★✓✓★✗均衡性能功能Chroma★★★★★★★✗✓✗原型/LLM 应用Weaviate★★★★★★★★✓✓✗多模态搜索FAISS★★★★✗✗✓研究/离线pgvector★★★★★★✓✓✗已有 PG典型迁移路径Chroma原型→ Qdrant生产→ Milvus大规模向量数据库工程实践Milvus 生产实践案例场景知识库检索系统约150 万条 chunk每条为1024 维向量BGE-large-zh 生成HNSW 索引M16, ef_construction128。选型理由数据量超过单机承载能力需要分布式部署知识库每日增量更新需要读写分离性能指标单机16 核32GB RAM千兆局域网HNSW 内存模式ef100指标数值P50 延迟~20msP99 延迟~60ms并发吞吐100 QPS 稳定内存计算与优化原始向量内存150 万 × 1024 维 × 4 字节float32≈6GB仅向量数据Milvus 实际占用约10-12GB额外 4-6GB 用于 HNSW 图结构、元数据、管理开销、OS 缓存SQ8 量化优化状态内存占用召回率变化float32 原始~10GB基准SQ8 量化后~3GB下降 1%额外优化Milvus 支持mmap将原始向量存储在磁盘只在内存中保留索引。原始向量仅在精排阶段读取对查询延迟影响很小。性能瓶颈与解决方案瓶颈 1内存压力导致查询延迟飙升项目说明现象P50 延迟从 20ms 飙升到 2 秒以上原因内存不足OS 频繁 swap 到磁盘解决SQ8 量化将内存从 10GB 降到 3GB消除 swap辅以 mmap 将原始向量存磁盘瓶颈 2批量写入触发 Segment 合并导致查询抖动项目说明现象每日增量更新时 P99 从 60ms 飙升到 300ms原因大量新记录触发后台 Segment 合并合并小段 构建索引CPU 和磁盘 I/O 密集解决 1低峰期调度将批量写入移到凌晨低峰期解决 2分批写入每批限制 500-1000 条间隔数秒将一次大冲击转为多次小冲击分批写入示例# ❌ 一次性写入 50 万条 → 触发大合并查询抖动collection.insert(all_data)# ✅ 分批写入每批 1000 条间隔 3 秒foriinrange(0,len(data),1000):batchdata[i:i1000]collection.insert(batch)time.sleep(3)参考资料HNSW 论文Efficient and Robust Approximate Nearest Neighbor Search using HNSW Graphshttps://arxiv.org/abs/1603.09320FAISS 文档Facebook AI Similarity Searchhttps://github.com/facebookresearch/faissMilvus 官方文档https://milvus.io/docsQdrant 文档https://qdrant.tech/documentation/Chroma 文档https://docs.trychroma.com/Weaviate 文档https://weaviate.io/developers/weaviateANN Benchmarks索引算法性能对比https://ann-benchmarks.com/Product Quantization for Nearest Neighbor Search经典论文https://hal.inria.fr/inria-00514462v2/document
