向量数据库到底是什么从原理、索引到 RAG 实战选型在 RAGRetrieval-Augmented Generation检索增强生成项目中经常会看到这样的技术链路用户问题 ↓ Embedding ↓ 向量 ↓ 向量数据库 ↓ 相似度检索 ↓ 相关文档 ↓ LLM ↓ 最终答案很多刚开始接触 RAG 的人知道要使用 Chroma、Milvus、Qdrant 等向量数据库但并不清楚向量数据库和 MySQL 到底有什么区别为什么不能直接用 MySQL 存向量HNSW 和 IVF 到底是什么向量数据库除了“查相似向量”还能做什么Chroma、Qdrant、Milvus、pgvector 到底该怎么选这篇文章从底层原理到实际项目选型把这些问题一次讲清楚。一、向量数据库到底是什么向量数据库简单来说就是专门用于存储、索引和检索向量数据的数据库。这里的“向量”一般来自 Embedding 模型。例如小猫正在吃鱼 ↓ Embedding 模型 ↓ [0.12, -0.87, 0.34, 0.56, ...]这可能是一个 768 维或者 1024 维的向量。Embedding 模型的目标是让语义相近的内容在向量空间中距离更近。例如小猫正在吃鱼 猫咪正在进食鱼肉 汽车正在高速公路上行驶前两句话语义比较接近因此对应的向量通常也比较接近。而第三句话和前两句话没有太大关系向量距离自然会比较远。所以向量数据库最核心的任务就是输入一个 Query 向量 ↓ 在数据库中找到最相似的 K 个向量 ↓ 返回这些向量对应的原始数据这个过程叫做ANNApproximate Nearest Neighbor近似最近邻搜索它也是 RAG 中“检索”环节的底层技术之一。二、为什么不用 MySQL非要使用向量数据库这是很多人刚开始做 RAG 时都会产生的问题。实际上MySQL、PostgreSQL 和向量数据库解决的问题并不一样。例如 MySQL 擅长SELECT*FROMuserWHEREid10001;这种查询的特点是我要找一个确定的数据。而向量检索是给我一个 Query 向量 ↓ 找出数据库中与它最相似的 10 个向量它不是寻找“相等”而是在寻找谁和我最接近这两个问题完全不同。1. 暴力搜索为什么不行假设数据库里面有 100 万个向量每个向量 1024 维。最简单的方法是Query ↓ 和第1个向量计算相似度 ↓ 和第2个向量计算相似度 ↓ 和第3个向量计算相似度 ↓ …… ↓ 和第100万个向量计算相似度也就是把所有向量都算一遍。数据量小时没有太大问题但是当向量数量达到100万 1000万 1亿这种全量遍历显然无法满足实际应用的延迟要求。2. 为什么 B-Tree 解决不了MySQL 常见的 B-Tree 索引本质上是利用数据的有序性进行快速查找。例如id 10001 age 30 price BETWEEN 100 AND 200这些数据可以按照某个维度建立排序关系。但是一个 1024 维向量是[x1, x2, x3, ..., x1024]两个向量之间的“距离”是由多个维度共同决定的。不存在简单的按照第1维排序就能快速找到整体最相似向量的方法。因此向量数据库需要专门设计适合高维空间的索引算法。这也是向量数据库存在的核心原因。三、向量数据库是怎么做到快速检索的向量数据库最重要的技术之一就是ANNApproximate Nearest Neighbor近似最近邻搜索。这里的“近似”非常关键。如果要求 100% 找到绝对最近的向量就需要进行大量计算。而实际工程中通常采用少量精度损失 ↓ 换取大量性能提升目前比较常见的 ANN 索引主要有HNSWIVF1. HNSW通过图结构快速寻找近邻HNSWHierarchical Navigable Small World可以理解成一种多层图结构。它不是把所有向量全部放在一起搜索而是建立类似这样的结构第3层 A -------- B \ C 第2层 A ---- D ---- B \ | C --- E 第1层 A-B-C-D-E-F-G-H-I-J-K...查询的时候不会从所有节点开始搜索而是从高层开始 ↓ 快速找到大致区域 ↓ 进入下一层 ↓ 进一步缩小范围 ↓ 最终找到最相似的向量可以类比成找一家餐厅。你不会把全国所有餐厅全部查一遍而是全国 ↓ 省 ↓ 城市 ↓ 区域 ↓ 街道 ↓ 具体餐厅HNSW 的特点优点查询速度快召回效果通常比较好非常适合实时检索目前很多向量数据库都支持缺点建立索引需要更多内存数据量特别大时内存成本比较明显所以 HNSW 非常适合中小规模 中等规模 实时检索 对召回率要求比较高四、IVF先聚类再缩小搜索范围IVFInverted File Index的思路不一样。它会先对向量进行聚类。例如所有向量 ↓ 聚类 ↓ ┌──────┬──────┬──────┬──────┐ │ Cluster A │ Cluster B │ Cluster C │ Cluster D │ └──────┴──────┴──────┴──────┘假设用户 Query 进来之后判断它最接近Cluster B Cluster C那么就只搜索这几个 Cluster而不是搜索全部数据。可以把它理解成在图书馆找一本书。你不会把整个图书馆所有书都翻一遍而是图书馆 ↓ 计算机类 ↓ Python ↓ 机器学习 ↓ 目标书籍IVF 的特点优点可以减少实际参与搜索的向量数量对大规模数据比较友好内存压力相对更容易控制缺点聚类质量会影响召回率参数需要调节精度和速度之间需要进行权衡所以在超大规模向量数据场景下IVF 仍然有很强的价值。HNSW 和 IVF 怎么理解可以简单记索引核心思想优点缺点HNSW图结构导航快、召回率高内存占用较高IVF聚类后缩小搜索范围更适合大规模数据需要调参可能损失召回率并不是HNSW 比 IVF 高级所以所有项目都用 HNSW。真正的选择需要结合数据规模 内存 查询延迟 召回率要求五、真正的生产环境不只是“查向量”如果向量数据库只有存向量 查相似向量其实还远远不够。真正的 RAG 项目还需要处理文档来源文档类型部门时间权限版本标签关键词所以向量数据库还需要提供 Metadata 等能力。1. Metadata 过滤假设知识库里面有2023年技术部文档 2024年技术部文档 2025年技术部文档 2024年市场部文档 2025年市场部文档用户现在要求只查询 2024 年技术部的资料。这时候不能简单地先向量搜索 ↓ 得到 Top 100 ↓ 再过滤更合理的是Query ↓ Metadata Filter ↓ 只保留符合条件的数据 ↓ Vector Search ↓ Top-K例如department 技术部 year 2024先把搜索范围限制下来再进行向量检索。这种能力在企业知识库中非常重要因为企业数据通常存在部门隔离 用户权限 时间范围 文档类型 知识库分类六、为什么向量数据库还需要 BM25Embedding 擅长解决意思相近但文字不同的问题。但是对于下面这种内容E03 RTX-4090 ABC-1001 HTTP 500 Python 3.12关键词往往比语义更加重要。例如用户查询设备 E03 故障怎么处理如果文档里面明确写错误代码E03那么 BM25 很容易直接命中。所以生产环境经常采用Query ↓ ┌──────┴──────┐ ↓ ↓ 向量检索 BM25 ↓ ↓ └──────┬──────┘ ↓ 混合召回 ↓ Rerank ↓ LLM也就是语义检索 关键词检索这就是常说的 Hybrid Search / Hybrid Recall。它通常比单独使用向量检索更加稳定。七、向量数据库还需要支持实时更新RAG 知识库不是静态数据。例如公司每天都会新增文档 修改文档 删除旧文档 更新产品说明书 增加新的 FAQ如果每次修改一个文档都需要删除整个索引 ↓ 重新导入全部文档 ↓ 重新建立索引显然无法用于生产环境。所以实际向量数据库通常需要支持新增 修改 删除 增量写入也就是说新文档 ↓ Chunk ↓ Embedding ↓ 写入向量数据库 ↓ 增量更新索引不需要因为新增一份 PDF 就把整个知识库重新构建一遍。八、常见向量数据库怎么选目前开发 RAG 时比较常见的方案包括ChromaQdrantMilvusPineconepgvector它们并不存在一个绝对的“最好”。真正应该根据项目规模 部署方式 运维能力 成本 是否需要混合检索进行选择。1. Chroma适合学习和快速原型Chroma 的特点就是简单。基本不需要复杂配置就可以快速搭建一个向量检索系统。比较适合个人学习 RAG Demo LangChain 实验 小型知识库 原型验证优点上手简单部署方便Python 生态友好RAG 学习阶段非常方便缺点超大规模生产环境并不是它最擅长的场景如果你刚开始学习 RAGChroma 是一个很合适的起点。2. Qdrant中大型项目常见选择Qdrant 使用 Rust 开发性能比较好同时 API 设计相对简单。比较适合中型知识库 生产 RAG 需要较好性能 希望自己部署特点高性能支持 Metadata Filter支持 Hybrid Search支持分布式能力API 比较容易使用如果项目已经从 Demo 开始走向生产环境Qdrant 是一个值得考虑的方案。3. Milvus大规模向量检索Milvus 更偏向专业的向量数据库和大规模数据场景。适合百万级 千万级 亿级 更大规模它的优势是分布式架构水平扩展能力强ANN 索引丰富面向大规模向量数据设计缺点也很明显部署和运维复杂度更高。如果只是做一个几万条数据的课程 RAG直接上 Milvus 往往没有必要。4. Pinecone不想自己维护基础设施Pinecone 属于云托管方案。开发者不需要自己维护服务器 索引 集群 扩容 故障恢复适合希望快速上线、并且接受云服务成本的团队。缺点主要是云服务成本对网络环境有要求企业数据需要考虑合规和数据传输问题因此国内企业项目在选择时需要结合具体业务要求考虑。5. pgvector其实很多项目根本不需要单独的向量数据库pgvector 是 PostgreSQL 的向量扩展。它最大的优势是不需要额外引入一套数据库。假设你的项目本身已经使用 PostgreSQL用户数据 订单数据 业务数据 知识库数据 向量数据都可以放在 PostgreSQL 中。这样可以直接利用 SQL 进行关联查询。例如用户 ↓ 权限 ↓ 知识库 ↓ 文档 ↓ 向量这种情况下pgvector 的工程价值非常高。它不一定拥有专业向量数据库在超大规模向量检索方面的性能但对于很多中小型 RAG 项目来说已经完全够用。九、几个常见方案怎么选可以先按照下面这个思路判断方案适合场景优点缺点Chroma学习、Demo、小型项目简单、上手快超大规模场景不合适Qdrant中大型 RAG性能好、API 简单大规模集群需要调优Milvus大规模、亿级向量分布式、扩展能力强部署维护复杂Pinecone云端生产项目托管、无需维护成本、网络和合规问题pgvector已经使用 PostgreSQL 的项目不需要额外数据库、SQL 方便超大规模性能不如专用方案十、实际项目到底应该怎么选如果是学习 RAGChroma先把文档 ↓ Chunk ↓ Embedding ↓ Vector DB ↓ Similarity Search ↓ LLM整个流程跑通。如果准备做一个真正的中小型生产项目Qdrant或者项目本身已经大量使用 PostgreSQLpgvector如果数据量非常大已经达到千万、亿级甚至更高Milvus如果团队明确希望完全使用云服务不想自己维护向量数据库Pinecone所以并不是Milvus Qdrant Chroma而应该是项目需求 ↓ 数据规模 ↓ 部署环境 ↓ 性能要求 ↓ 运维能力 ↓ 选择合适的数据库十一、把整个 RAG 检索流程串起来到这里再回头看 RAG就比较容易理解向量数据库到底处于什么位置。完整流程实际上是【离线阶段】 PDF / Word / Markdown ↓ 文档解析 ↓ Chunk ↓ Embedding ↓ ┌─────────────────────┐ │ Vector Database │ │ │ │ Vector Metadata │ └─────────────────────┘ 【在线阶段】 用户 Query ↓ Query Embedding ↓ ┌─────────────────────┐ │ Vector Search │ │ │ │ BM25 Keyword Search │ └─────────────────────┘ ↓ 混合召回 ↓ Rerank ↓ Top-K 文档 ↓ LLM ↓ 最终回答可以看到向量数据库并不是 RAG 的全部。它主要负责的是高效保存向量并根据 Query 快速找到相关数据。而一个完整的生产级 RAG还需要解决文档解析 Chunk 切分 Embedding 向量存储 Metadata 向量检索 关键词检索 Rerank Prompt LLM 权限控制 数据更新总结理解向量数据库可以抓住几个核心概念第一向量数据库解决的是“相似度搜索”问题。MySQL 擅长id 100 name 张三而向量数据库擅长找和这个 Query 语义最接近的 Top-K 数据第二ANN 索引是向量数据库能够快速检索的关键。其中HNSW → 图结构搜索速度快、召回率高 IVF → 聚类缩小搜索范围更适合大规模数据第三生产环境不能只考虑向量搜索。真正好用的 RAG 通常还需要Metadata Filter BM25 Vector Search Rerank第四数据库选型没有绝对答案。可以简单记成学习 / Demo → Chroma 中小型生产 RAG → Qdrant / pgvector 大规模向量数据 → Milvus 云托管 → Pinecone最后需要注意一个非常重要的点向量数据库不是为了“存向量”而存在而是为了让系统能够在海量向量中快速、准确地找到与当前 Query 最相关的数据。对于 RAG 来说真正重要的也不是“用了什么向量数据库”而是最终能不能做到用户问什么 ↓ 正确理解 Query ↓ 找到正确 Chunk ↓ 交给 LLM ↓ 生成正确答案数据库只是其中的一环但它决定了 RAG 检索阶段能不能稳定运行。