使用 Milvus 快速搭建 RAG 服务

总结一下我使用 Milvus 做 RAG 时踩过的坑，如果你在正在给老师做项目，然后项目里又要求有知识检索（RAG）的功能，然后又愁不知道怎么做，可以看看我的总结。

一、云端 or 本地

Milvus提供了本地部署的方式，也就是用 docker 去部署一个 Milvus 数据库，然后把你的数据存进去就可以实现检索。但是用 docker 部署太重了，你需要写很多代码去实现更新数据，插入数据，查询数据等操作，然后最后向外提供 api 接口。这个流程就要花费不少时间。

我们的首要目的是尽快搭建一个原型，RAG 的细节根本就不用去管，只有先做出来我们才会去考虑其他事情。因此，云端的免费的 Milvus 数据库就是我们的首要选择。

二、创建数据库

进入 zilliz 云，先完成基本的注册：https://cloud.zilliz.com/。注册成功后，按照里面的指引来，点击 create 创建一个 free 数据库。

设置一下名字，然后参数保持默认就行了，然后点击 create

然后稍等片刻，初始化需要一点时间。

三、创建 Collection

点击 Create Collection，创建一个 collection。

collection 你可以认为就是一张二维表，具有固定的列和变化的行。每列代表一个字段，每行代表一个实体。

四、添加字段

填写好 collection 名称后，我们首先要添加字段。

首先，我举一个例子，假如你是要做一个教材知识库，你拥有所有的高中地理教材，你对教材数据进行清理后，得到了如下的结构。

其中，id 是必须的，每个实体必须要有一个唯一的 id，book_name 是知识点对应的教材名，chapter，subsection 的意思分别是章和小节，source_type 和 source_name 不用管，这只是我这边项目的需求，然后 text 指的是对应的原文。

这个结构清晰的展示了每个知识点在教材库里的具体位置。

你做 RAG 的需求是：1. 我可以对 text 进行检索，比如搜索“人口分布的特点”，能够找到对应的原文片段。2. 我可以对 subsection_name 进行检索，这样我就能方便的找到小节的名称。

因此，你就必须要有两个字段，text_embedding 和 subsection_embedding，用于存储 text 和 subsection_name 向量化后的结果。

然后就是正式的添加字段了，Milvus 对于不同类型的字段的数据类型有要求，如果是 embedding 字段的话，就必须要用向量类型（Vector Fields），我们选择 FLOAT_VECTOR 就行了。

然后向量字段的 2048 指的是向量的维度，这个是根据实际情况来的，比如我用的是 Qwen 的 text-embedding-v4 作为 embedder，向量维度只能填下面的几个。

五、设置索引

我们必须要对 embedding 字段设置索引，加快检索速度。设置界面其实已经默认给你设置好了，用的是 AUTOINDEX，意思就是会根据你的实际情况，自动选择合适的索引类型。

其他保持默认，最后点击 create，成功创建

六、插入数据

插入数据有两种方法，一是直接在界面选择导入数据，我是导入 json 格式的，这种方法必须保证一下几点要求：

一是必须是一个实体一个实体的格式，例如我下面这种

二是字段名称必须和数据库里的名称一一对应，不能错，不能多也不能少。

三是 embedding 字段必须是已经生成好了的。这个需要单独先去处理，写一个脚本，调用阿里云百炼的 Embedding 模型或者其他模型，生成好实际的 embedding 向量

然后就能插入成功

第二种方法是写脚本，发送 post 请求，方法其实在里面就已经有介绍了，我就不多说了。

其实最简单的方法就是直接上传数据，因为如果你用第二种方法，就已经能够生成第一种方法需要的 json 数据了，没必要多此一举去发送 post 请求了。

七、查询数据

查询数据需要发送 post 请求过去，其中需要配置 token 和 endpoint。其他的请求参数可以去文档里面看，里面介绍的详细。

export TOKEN="db_admin:xxxxxxxxxxxxx"

curl --request POST \
--url "${CLUSTER_ENDPOINT}/v2/vectordb/entities/search" \
--header "Authorization: Bearer ${TOKEN}" \
--header "Content-Type: application/json" \
-d '{
    "collectionName": "quick_setup",
    "data": [
        [
            0.3580376395471989,
            -0.6023495712049978,
            0.18414012509913835,
            -0.26286205330961354,
            0.9029438446296592
        ]
    ],
    "annsField": "vector",
    "limit": 3,
    "outputFields": [
        "color"
    ]
}'

结语

其实在做 RAG 这个功能之前，不妨多想想，你的项目真的需要做知识检索吗？大模型对于你项目里的知识库，真的有偏见吗？

就比如我这个，做的是地理教材知识库，大模型对于地理概念真的有偏见吗？难道大模型训练的时候没有去使用到教材吗？我觉得是没有偏见的，大模型肯定知道地理教材的一些基本概念，根本没必要实现一个 RAG 服务。与其做 RAG，还不如在 Agent 上面多花点功夫。

那么什么情况下适合使用 RAG 了，我觉得有两点：一、严肃的场合而非娱乐场合。比如医疗大模型，必须要用 RAG，因为药品的合适用量不是开玩笑的，否则会出事故的。二、大模型绝对的无知领域。比如公司业务大模型，任何 AI 肯定不知道你公司的具体事情，比如财务日报啊，员工信息啊，客户信息啊，这些东西大模型是绝对不知道的，才适合用 RAG。