RAG入门，向量存储与Milvus企业级向量数据库，如何选？

本文是 refine-rag 系列教程的第八篇，我们来学习向量存储的核心技术和 Milvus 数据库的使用。 本文所有代码都在：https://github.com/zonezoen/refine-rag 往期系列文章 007：RAG 入门-向量嵌入与检索 006：RAG 入门-面试官问你，RAG 为什么要切块？ 005：RAG 入门-LangChain读取表格数据 目录 前言 为什么传统数据库搞不定向量搜索？ 向量数据库横向对比 为什么选择 Milvus？ 快速搭建 Milvus Milvus 核心概念 实战示例 学习路径 前言 前面我们学习了向量嵌入与检索，知道如何把文本转成向量、如何计算相似度。但有个问题：这些向量存在哪里？ 如果只有几千条数据，存在内存里就够了。但如果有几百万、几千万条数据呢？这时候就需要专业的向量数据库。 向量数据库就像是为向量量身定制的"仓库管理系统"，它不仅能存储海量向量，还能快速检索、高效管理。 为什么传统数据库搞不定向量搜索？ 上一篇文章提到，向量本质上是一个浮点数数组，是机器理解文本语义的方式。 你可能会想：既然向量就是数组，那我存进 MySQL 的 JSON 字段或者直接存在内存 List 里不行吗？ 答案是：小规模可以，大规模必死。 当你的知识库达到万级、百万级甚至亿级时，你会面临： 检索效率塌方（计算量过大）： 传统数据库查找数据是“相等判断”，而向量搜索需要计算空间距离。如果你有 100 万条数据，每搜一次都要全表扫一遍并计算相似度O(n) 复杂，查询一次可能要几秒甚至几分钟。向量数据库通过 ANN（近似最近邻）算法（如 HNSW），将搜索效率提升到了毫秒级O(log n) 复杂度。 维度灾难（内存压力）： 一个 1536 维的向量（OpenAI 标准）看起来不大，但几百万条叠在一起，会瞬间撑爆普通的服务器内存。向量数据库专门优化了数据的压缩与加载策略。 工程化缺失： 向量数据库不仅仅是“存数据”，它还提供了成熟的 CRUD、多租户隔离、数据备份和水平扩展（Scale-out）能力，这些是简单的内存库（如 FAISS）难以胜任的。 核心对比：传统数据库 vs 向量数据库 传统数据库查找的是精准的数据，而向量数据库则更适合模糊搜索。 传统数据库 (MySQL)： 你问：“有没有编号为 1024 的商品？”他秒回。 你问：“有没有长得像苹果的手机？”他直接罢工”。 向量数据库 (Milvus)： 他会把所有数据转化为空间坐标，告诉你：“虽然我没找到完全一样的，但有几个神似的数据。” 代码层面的直观感受 传统数据库（MySQL）：侧重“准” -- 精确查询：差一个字都搜不到 SELECT * FROM products WHERE category = '手机' AND brand = '苹果'; -- 范围查询：基于确定的数值边界 SELECT * FROM products WHERE price BETWEEN 5000 AND 8000; 特点：擅长精确匹配，基于 B-Tree 索引，查询条件极其明确（非黑即白）。 向量数据库（Milvus）：侧重“像” # 相似度查询：基于“语义距离” results = client.search( collection_name="products", data=[query_vector], # 搜索“长得像苹果的手机”对应的向量 limit=10 ) 特点：擅长模糊搜索，基于向量索引（HNSW、IVF），返回的是 Top-K 个“最相似”的候选者。