概念介绍：Milvus 到底解决什么问题

概念介绍：Milvus 到底解决什么问题

Milvus 是一个开源的向量数据库，专门用来存储和检索由 embedding 模型生成的高维向量。传统数据库靠精确匹配找数据，比如 WHERE title = 'Milvus 教程'；而向量数据库靠相似度找数据——把一段文字、一张图片、一段音频交给 embedding 模型变成一串浮点数，再让数据库找出「和这串数最接近的另外几串数」。这件事的学名叫近似最近邻检索（ANN，Approximate Nearest Neighbor）。

为什么需要「近似」？因为精确检索要把查询向量和库里每一条向量都算一遍距离，数据量上到百万、千万级时延迟无法接受。Milvus 的思路是提前为向量建索引，把向量空间划分成若干区域或组织成图结构，检索时只探查一小部分候选，用极小的精度损失换取数量级的延迟下降。这个「精度换速度」的旋钮，是后面所有索引参数（nlist、nprobe、ef 等）在调的东西。

在 RAG（检索增强生成）架构里，Milvus 承担的是召回层：用户提问先被 embedding 成向量，去 Milvus 里召回最相关的若干段文档，这些段落拼进 prompt 再交给大模型生成答案。召回层的质量直接决定最终答案的上限——召回错了，模型再强也答不对。所以选型时要关心的不是「数据库跑得多快」，而是「给定延迟预算，recall 能做到多少」。

另外要分清一件事：Milvus 只负责存向量、算距离、返回结果，它不做 embedding。生成向量的模型（比如各种文本 embedding、CLIP 之类的多模态模型）是独立的一环，必须在写入和查询两侧使用同一个模型、同一个版本、同一个维度，否则向量空间对不上，检索结果会完全错乱。

与 pgvector / Qdrant / Elasticsearch 向量检索的区别

这四者常被放在一起比较，但它们的定位差别很大，取舍主要看数据规模、团队技术栈和运维能力。

一个常见的落地路径是：先用 pgvector 或 Milvus Lite 快速验证效果，确认召回的 recall 达标、业务价值成立之后，再迁移到 Milvus Standalone 或 Distributed 扛量。迁移成本主要在 schema 与索引参数的重建，向量本身是通用的 float 数组，搬起来不难。

核心术语表

Milvus 的数据模型和关系型数据库有不少同名但含义不同的概念，先把这张表看懂，后面看官方文档和 API 会顺很多。