基础定义向量数据库专门用于存储和检索高维向量的数据库核心能力是语义相似性搜索。非结构化数据文本、图片、音频等→ 通过 Embedding 模型 → 高维向量如 768/1536 维检索时根据向量间的距离余弦相似度、欧氏距离等快速匹配语义最相关的内容而非关键词匹配。其他与传统数据库的区别传统数据库做精确匹配向量数据库做相似匹配传统数据库索引基于结构化字段向量数据库基于向量索引如 HNSW、IVF。典型场景RAG、推荐系统、图像检索、多模态搜索。大模型应用中的三大核心问题给大模型补上「长期记忆」原生问题大模型上下文窗口有限如 GPT-4 最多 128K token无法直接承载企业级海量文档。解决方式文档切片 → 生成向量 → 存入向量库用户提问时先检索 Top-K 最相关片段将片段作为上下文喂给大模型 → 生成答案RAG 核心链路补充切片策略按语义 / 段落 / 固定长度拆分避免语义断裂检索精度影响最终回答质量是 RAG 优化的关键环节突破知识时效性限制原生问题大模型知识截止到训练时间点无法获取实时 / 新增知识如最新新闻、政策、产品更新。解决方式向量数据库支持实时增量写入新数据可快速入库并被检索到无需重新训练大模型。补充可对接实时数据流如日志、新闻接口实现「动态知识库」配合大模型做到「训练数据不变外部知识实时更新」降低推理成本原生问题若将全部背景知识塞进 PromptToken 消耗极高推理速度慢、费用昂贵。解决方式仅检索最相关的少量片段通常 5-10 条大幅减少 Token 消耗推理成本可降低一个数量级。补充Token 节省10 万条文档全量塞入需数百万 Token检索后仅需约 2000 Token推理速度上下文变短大模型生成速度显著提升工作流程向量检索的底层原理传统数据库用B 树做索引支持精确匹配和范围查询。向量数据库用的是近似最近邻(KNN)算法因为在几百维的空间里做精确最近邻搜索计算量是 O (n×d)1000 万条 1536 维向量精确搜一遍要几分钟生产环境根本用不了。近似最近邻牺牲一点准确率换速度常见算法有三类HNSW 是目前最主流的算法构建一个多层跳表结构。最底层存所有向量往上每层随机抽取部分节点查询时从最顶层开始像走迷宫一样一层层往下找。1000 万向量的库查询只需要访问几百个节点延迟在 10ms 以内。Milvus、Pinecone、Weaviate 默认都用 HNSW。IVF 先用 K-Means 把向量聚成几千个簇查询时只在最相似的几个簇里搜索。建索引快但查询精度不如 HNSW。适合向量数据量特别大、对延迟要求没那么高的场景。PQ 把高维向量拆成多个子向量每个子向量用聚类中心的 ID 代替压缩存储空间。10 亿级向量的场景会用 IVFPQ 的组合内存占用能压到原来的 1/10。主流向量数据库embedding 模型的选择向量数据库只负责存储和检索向量本身是 embedding 模型生成的。模型选得不好检索效果再好也没用。OpenAI 的 text-embedding-3-large 是目前效果最好的通用模型1536 维或 3072 维可选。缺点是调 API 有成本100 万 token 大概 0.13 美元。开源模型推荐 BGE 系列智源发布的中英文效果都不错。bge-large-zh-v1.5 在中文场景下效果接近 OpenAI可以本地部署成本低很多。还有个容易踩的坑query 和 document 要用同一个模型生成向量不能混用。不同模型的向量空间不一样混着用检索效果会很差。实际项目中向量数据库很少单独使用通常和传统数据库配合。比如一个文档问答系统文档的元数据存在 PostgreSQL 里向量存在 Milvus 里。查询时先在向量库里检索语义相似的 chunk再根据 chunk ID 去关系库里捞完整的文档信息。有些向量数据库支持 metadata filtering可以在向量检索的同时加上结构化条件。比如 “只在 2024 年的文档里搜索”先按时间过滤再在过滤后的子集里做向量检索。Weaviate 和 Qdrant 这方面做得比较好。一些疑惑提问HNSW 和 IVF 具体怎么选什么场景用哪个回答主要看数据量和对召回率的要求。1000 万以内的向量HNSW 无脑选召回率高、延迟低。超过 1 亿的向量HNSW 的内存占用会很夸张每个向量除了本身的数据还要存一堆邻居指针1 亿条 1536 维向量光 HNSW 索引就要几百 GB 内存。这时候用 IVFPQ牺牲一点召回率内存能省一个数量级。还有个考量是更新频率HNSW 增量插入比较友好IVF 的聚类中心是建索引时固定的数据分布变化大了得重建索引。问检索出来的结果语义相关但答非所问怎么优化回答这个问题通常出在三个地方。一是 chunk 切分粒度不对切太细丢失上下文切太粗检索不精准一般 500-1000 字比较合适还可以加上滑动窗口重叠。二是 embedding 模型和业务场景不匹配通用模型对垂直领域术语理解不好可以换成领域微调过的 embedding 模型或者在 query 前面加上领域关键词做 query expansion。三是只靠向量相似度不够可以加上 BM25 关键词匹配做混合检索Weaviate 和 Elasticsearch 都支持 hybrid search。提问向量数据库的数据怎么保证一致性和持久化回答不同产品实现不一样。Milvus 用 etcd 存元数据用 MinIO 或 S3 存向量数据和索引写入时先落 WAL 再异步刷盘。Pinecone 是全托管的底层细节不公开但官方承诺 99.99% 的可用性。开源方案要自己做好备份和灾备。Milvus 支持跨集群复制也可以定期把数据 dump 出来存到对象存储。一致性方面大多数向量数据库是最终一致性写入后不能立刻检索到有几十毫秒到几秒的延迟强一致性场景不太适用。
【大模型应用】5.深入理解向量数据库
基础定义向量数据库专门用于存储和检索高维向量的数据库核心能力是语义相似性搜索。非结构化数据文本、图片、音频等→ 通过 Embedding 模型 → 高维向量如 768/1536 维检索时根据向量间的距离余弦相似度、欧氏距离等快速匹配语义最相关的内容而非关键词匹配。其他与传统数据库的区别传统数据库做精确匹配向量数据库做相似匹配传统数据库索引基于结构化字段向量数据库基于向量索引如 HNSW、IVF。典型场景RAG、推荐系统、图像检索、多模态搜索。大模型应用中的三大核心问题给大模型补上「长期记忆」原生问题大模型上下文窗口有限如 GPT-4 最多 128K token无法直接承载企业级海量文档。解决方式文档切片 → 生成向量 → 存入向量库用户提问时先检索 Top-K 最相关片段将片段作为上下文喂给大模型 → 生成答案RAG 核心链路补充切片策略按语义 / 段落 / 固定长度拆分避免语义断裂检索精度影响最终回答质量是 RAG 优化的关键环节突破知识时效性限制原生问题大模型知识截止到训练时间点无法获取实时 / 新增知识如最新新闻、政策、产品更新。解决方式向量数据库支持实时增量写入新数据可快速入库并被检索到无需重新训练大模型。补充可对接实时数据流如日志、新闻接口实现「动态知识库」配合大模型做到「训练数据不变外部知识实时更新」降低推理成本原生问题若将全部背景知识塞进 PromptToken 消耗极高推理速度慢、费用昂贵。解决方式仅检索最相关的少量片段通常 5-10 条大幅减少 Token 消耗推理成本可降低一个数量级。补充Token 节省10 万条文档全量塞入需数百万 Token检索后仅需约 2000 Token推理速度上下文变短大模型生成速度显著提升工作流程向量检索的底层原理传统数据库用B 树做索引支持精确匹配和范围查询。向量数据库用的是近似最近邻(KNN)算法因为在几百维的空间里做精确最近邻搜索计算量是 O (n×d)1000 万条 1536 维向量精确搜一遍要几分钟生产环境根本用不了。近似最近邻牺牲一点准确率换速度常见算法有三类HNSW 是目前最主流的算法构建一个多层跳表结构。最底层存所有向量往上每层随机抽取部分节点查询时从最顶层开始像走迷宫一样一层层往下找。1000 万向量的库查询只需要访问几百个节点延迟在 10ms 以内。Milvus、Pinecone、Weaviate 默认都用 HNSW。IVF 先用 K-Means 把向量聚成几千个簇查询时只在最相似的几个簇里搜索。建索引快但查询精度不如 HNSW。适合向量数据量特别大、对延迟要求没那么高的场景。PQ 把高维向量拆成多个子向量每个子向量用聚类中心的 ID 代替压缩存储空间。10 亿级向量的场景会用 IVFPQ 的组合内存占用能压到原来的 1/10。主流向量数据库embedding 模型的选择向量数据库只负责存储和检索向量本身是 embedding 模型生成的。模型选得不好检索效果再好也没用。OpenAI 的 text-embedding-3-large 是目前效果最好的通用模型1536 维或 3072 维可选。缺点是调 API 有成本100 万 token 大概 0.13 美元。开源模型推荐 BGE 系列智源发布的中英文效果都不错。bge-large-zh-v1.5 在中文场景下效果接近 OpenAI可以本地部署成本低很多。还有个容易踩的坑query 和 document 要用同一个模型生成向量不能混用。不同模型的向量空间不一样混着用检索效果会很差。实际项目中向量数据库很少单独使用通常和传统数据库配合。比如一个文档问答系统文档的元数据存在 PostgreSQL 里向量存在 Milvus 里。查询时先在向量库里检索语义相似的 chunk再根据 chunk ID 去关系库里捞完整的文档信息。有些向量数据库支持 metadata filtering可以在向量检索的同时加上结构化条件。比如 “只在 2024 年的文档里搜索”先按时间过滤再在过滤后的子集里做向量检索。Weaviate 和 Qdrant 这方面做得比较好。一些疑惑提问HNSW 和 IVF 具体怎么选什么场景用哪个回答主要看数据量和对召回率的要求。1000 万以内的向量HNSW 无脑选召回率高、延迟低。超过 1 亿的向量HNSW 的内存占用会很夸张每个向量除了本身的数据还要存一堆邻居指针1 亿条 1536 维向量光 HNSW 索引就要几百 GB 内存。这时候用 IVFPQ牺牲一点召回率内存能省一个数量级。还有个考量是更新频率HNSW 增量插入比较友好IVF 的聚类中心是建索引时固定的数据分布变化大了得重建索引。问检索出来的结果语义相关但答非所问怎么优化回答这个问题通常出在三个地方。一是 chunk 切分粒度不对切太细丢失上下文切太粗检索不精准一般 500-1000 字比较合适还可以加上滑动窗口重叠。二是 embedding 模型和业务场景不匹配通用模型对垂直领域术语理解不好可以换成领域微调过的 embedding 模型或者在 query 前面加上领域关键词做 query expansion。三是只靠向量相似度不够可以加上 BM25 关键词匹配做混合检索Weaviate 和 Elasticsearch 都支持 hybrid search。提问向量数据库的数据怎么保证一致性和持久化回答不同产品实现不一样。Milvus 用 etcd 存元数据用 MinIO 或 S3 存向量数据和索引写入时先落 WAL 再异步刷盘。Pinecone 是全托管的底层细节不公开但官方承诺 99.99% 的可用性。开源方案要自己做好备份和灾备。Milvus 支持跨集群复制也可以定期把数据 dump 出来存到对象存储。一致性方面大多数向量数据库是最终一致性写入后不能立刻检索到有几十毫秒到几秒的延迟强一致性场景不太适用。
