年Milvus搭配Ollama搭建RAG知识库终极指南

1、RAG介绍

RAG（Retrieval-Augmented Generation，检索增强生成），说白了，就是把信息检索和文本生成结合起来搞。它的核心思路很简单：让大模型在回答问题之前，先去外部知识库查查资料，然后基于查到的信息来生成更准确、有根有据的回答。这样一来，大模型经常犯的“知识过时”和“瞎编乱造”的毛病，就能得到有效缓解。

1.1、RAG基本原理

RAG的工作流程大致可以分成三步：准备数据 → 检索信息 → 生成答案，形成一个“先查后答”的闭环。

• 数据准备（也就是索引阶段）：把企业文档、网页、PDF这些非结构化的数据，给加载进来，然后切成一块一块的小段（这个过程叫chunking），一般每段300到800个字符。接着用嵌入模型（比如text-embedding-3-small）把这些文本块转换成向量，存到向量数据库里，方便后面做语义检索。
• 检索阶段（Retrieval）：用户提问题的时候，系统先把问题也转成向量。然后在向量数据库里，通过计算相似度（比如余弦相似度），把最相关的那几个文本片段找出来。有时候还会把关键词检索（BM25）和语义检索（DPR）结合起来搞“多路召回”，这样能提升召回率和精准度。
• 生成阶段（Generation）：把找到的那些相关片段，跟原始问题拼到一起，组成一个提示词（Prompt），喂给大语言模型。模型就根据这些“参考资料”来生成回答，确保说出来的是有依据的，减少胡编乱造的风险。

这里有个关键点：RAG的准确率瓶颈，说白了就是“检索上下文的质量”到位不到位。如果检索出去的信息就是错的，那再牛的生成模型也白搭。

1.2、RAG应用场景

正因为RAG又灵活又准确，它在很多领域都已经落地应用了，特别适合那些对专业性、实时性、可解释性要求高的场景。

• 企业知识库问答：员工可以像聊天一样，问内部制度、产品手册、项目文档。系统自动检索并给出摘要，不用再麻烦着人工整理，信息获取效率一下就上来了。
• 智能客服与售后服务：客户咨询产品功能、退换货政策时，RAG能实时去查最新的服务条款，不会因为信息滞后而答错。还能结合用户的历史订单，给出个性化的建议。
• 医疗与法律辅助决策：医生输入患者症状，系统就能去查最新的诊疗指南或临床研究，辅助诊断。律师查合同条款，RAG能从历史案例或法规库里找到相关的判例，让合规性更有保障。
• 学术研究与文献综述：研究者提个研究问题，RAG就能快速检索大量论文摘要，并给出一份初步的综述框架。省去了大量查资料的时间，科研效率自然就高了。
• 动态内容生成与新闻撰写：结合实时数据（比如股市行情、体育比赛结果），RAG能生成带最新信息的报告或新闻稿。这对财经、体育、舆情监控这些对时效性要求高的领域来说，非常实用。

1.3、RAG核心技术

RAG这套东西，主要由下面几个关键部分组成：

• 信息检索模块（Retrieval Module）：负责从庞大的文档库里，把跟用户查询最相关的那些片段给捞出来。通常会用向量数据库（比如Faiss、Pinecone、Milvus）来存文档的向量表示，通过计算查询向量和文档向量的相似度来实现快速检索。检索算法可以是基于关键词的（如BM25），也可以是基于语义的（如DPR、Sentence-BERT）。
• 嵌入模型（Embedding Model）：用来把文本（不管是文档还是查询）转换成固定长度的向量，这样就能做语义相似度计算了。常用的嵌入模型包括：Sentence-BERT（SBERT）、OpenAI的text-embedding模型、通义千问的QwenEmbedding等等。嵌入模型的质量，直接影响着检索效果。
• 生成模型（Generation Model）：通常就是我们常说的大语言模型（LLM），比如GPT系列、通义千问、Llama这些。它接收检索到的相关文档片段和原始查询，然后生成最终的回答。生成模型得有良好的上下文理解和语言生成能力。
• 检索-生成融合机制（Retrieval-Generation Fusion）：把检索到的文档片段跟原始查询组合成一个提示（Prompt），喂给生成模型。这个过程可以是简单的拼接，也可以是更复杂的融合策略，比如加个注意力机制。
• 向量数据库（Vector Database）：专门用来高效存储和检索高维向量数据。支持快速的近似最近邻（ANN）搜索，是实现大规模文档检索的关键。常见的向量数据库有：Faiss、Pinecone、Milvus、Wea viate等等。
• 数据预处理与后处理：数据预处理包括文档清洗、分块、去掉无关内容等等，目的是提高检索效率和质量。后处理可能包括答案过滤、格式化输出、引用标注等，让最终的回答更好读、更可信。这些组件一起协同工作，让RAG既能发挥大语言模型的强大生成能力，又能通过外部知识库提供更准确、更可靠的问答结果。

本文的选型方案是：“Milvus（向量数据库）、Qwen（生成模型）、Qwen-embedding（嵌入模型）以及SpringAI”，下面我们就围绕这套组合来展开。

2、向量数据库

向量数据库是一种专门用来存储、管理和高效检索高维向量数据的数据库系统。它能通过AI模型，把文本、图像、音频这些非结构化数据，转化成蕴含语义特征的向量序列，然后基于向量之间的相似度实现“语义级检索”。这解决了传统数据库在处理非结构化数据时的局限性，为RAG智能问答、多模态搜索、智能推荐等AI应用提供了底层支撑。

2.1、核心工作步骤

• 数据向量化：生成“特征指纹”。这是向量数据库的前置核心环节，需要借助Embedding模型把原始非结构化数据转化成高维向量。同时要平衡好向量的维度：维度越高，特征表达越精细，检索精度也越高，但存储和计算成本会指数级增长；维度越低，效率越高，但可能丢失关键特征导致精度下降。工业级的常规选择，文本一般是768-1536维，图像是512-2048维。

  • 文本数据：可以选OpenAI的text-embedding-ada-002（通用场景下最优，1536维）、国产开源的BGE（性价比之选，768维）、或者微调后的BERT（细分领域的首选）等模型。
  • 图像数据：CLIP（支持文本搜图的多模态适配模型）、ResNet（纯图像特征提取模型）都是常用工具。
  • 音频数据：Wa v2Vec2（语音转向量）、VGGish（音频场景特征提取）可以满足需求。
• 存储与索引构建：加速相似性计算。向量数据库会把生成的高维向量存起来，然后构建特殊的索引结构来提升检索效率。常见的索引算法有IVF（倒排文件）、HNSW（分层可导航小世界图）等，它们能大幅降低相似性计算的时间。

• 相似性检索：找“最近邻”。用户发起查询时，系统先把查询内容转为向量，然后在数据库里找跟它“距离最近”的Top-K个向量。常用的距离度量方式有三种：

  • 余弦相似度：最常用，只关注向量的方向，忽略长度，适合做语义级对比，比如文本检索。计算结果范围是[-1,1]，越接近1相似度越高。
  • 欧氏距离：计算两个向量的直线距离，同时考虑方向和长度，适合关注绝对特征差异的场景，比如图像检索。值越小相似度越高，需要提前对向量进行归一化处理。
  • 点积相似度：计算速度最快，但受向量长度影响大。对向量做L2归一化后，结果就等价于余弦相似度，适合高并发低延迟的场景，比如实时推荐。

3、Milvus介绍

Milvus是一款为高维向量数据设计的云原生向量数据库，广泛应用于人工智能、机器学习和相似性搜索等场景。它采用存储与计算分离的架构，具备高可用性、高性能和弹性扩展能力。

3.1、核心架构层次

Milvus的系统架构分为四个主要层次：

• 接入层（Access Layer）：作为系统的入口，由一组无状态的Proxy组件构成，负责请求路由和负载均衡。
• 协调服务（Coordinator Service）：负责管理元数据、任务调度和状态同步，包括Root Coordinator、Data Coordinator和Index Coordinator等。
• 执行节点（Worker Node）：负责处理实际的数据插入、查询和索引构建等操作，包含Query Node、Index Node和Data Node。
• 存储层（Storage Layer）：负责持久化存储，使用对象存储（如S3、MinIO）来保存向量数据和索引文件，同时通过etcd和Pulsar/Kafka来管理元数据和日志。

3.2、数据模型与存储机制

3.3、术语映射关系

4、Milvus本地部署

4.1、Docker Compose 部署

Milvus提供了Docker Compose配置文件，拉下来启动就行：

wget https://github.com/milvus-io/milvus/releases/download/v2.6.11/milvus-standalone-docker-compose.yml -O docker-compose.yml

sudo docker compose up -d

Creating milvus-etcd  ... done
Creating milvus-minio ... done
Creating milvus-standalone ... done

启动完成后，访问Milvus WebUI地址（http://127.0.0.1:9091/webui/）就能查看Milvus实例的更多信息。

4.2、Attu（可视化工具）安装

Attu是Milvus官方推出的图形化管理工具，提供了一个直观的可视化界面，方便用户查看和管理向量数据库。通过Attu，数据库架构设计、数据操作、向量搜索这些复杂任务都能轻松搞定，大大降低了Milvus的使用门槛。

docker run -d --name milvus-attu 
  -p 8000:3000 
  -e MILVUS_URL=localhost:19530 
  zilliz/attu:v2.6

Attu启动完成后，访问（http://localhost:8000），就能以图形化的方式查看和管理Milvus实例了。

5、模型本地安装

RAG系统依赖两类模型：Embedding和Generation。

• 嵌入模型（Embedding Model）：用来把文本（文档和查询）转成固定长度的向量，方便做语义相似度计算。常用的有Sentence-BERT（SBERT）、OpenAI的text-embedding模型、通义千问的QwenEmbedding等。嵌入模型的质量直接影响检索效果。
• 生成模型（Generation Model）：通常就是大语言模型（LLM），比如GPT系列、通义千问、Llama等。它接收检索到的相关文档片段和原始查询，生成最终回答。生成模型得有良好的上下文理解和语言生成能力。

本文选了“qwen3-embedding”做嵌入模型，“qwen3.5”做生成模型，用Ollama本地安装：

admin@Mac-miniM4 milvus % ollama list
NAME                                ID              SIZE      MODIFIED    
qwen3.5:2b                          324d162be6ca    2.7 GB    3 hours ago    
qwen3-embedding:0.6b                ac6da0dfba84    639 MB    4 hours ago    

6、RAG系统设计

RAG知识库的核心价值在于“结构化检索（关系型）+ 语义检索（向量）”的融合。实体模型设计得同时兼顾关系型数据的结构化关联能力和向量数据的语义匹配能力，既要保证实体间的逻辑关联清晰，又要实现基于语义的精准检索。下面聚焦“关系型 + 向量数据融合”的实体模型设计，包含核心实体定义、数据存储分工、关联逻辑、落地实现四大模块。

6.1、核心设计原则（融合版）

• 分工明确：关系型数据库（MySQL）存储“实体元数据、关联关系、检索过滤条件”，向量数据库（Milvus）存储“文本语义向量”，避免单库承受所有压力。
• 双向关联：关系型数据与向量数据通过唯一ID（chunk_id）绑定，支持“从关系型维度筛选→向量语义检索”，也支持“从向量检索结果→回溯关系型元数据”。
• 轻量化融合：向量数据只存储核心检索单元（Chunk）的向量，不冗余存储文档或实体的全量向量。关系型数据补充向量无法表达的结构化信息（如实体类型、文档来源）。

6.2、核心实体模型（关系型 + 向量融合）

实体分工总览：

关系型实体表设计（核心元数据 + 关联）：

• Knowledge（知识库实体，关系型）：存储知识库定义元数据，维护知识库的Embedding模型和向量数据库设置信息。
• Document（文档实体，关系型）：存储文档级结构化元数据，是所有子实体的根节点，不存完整内容和向量。
• Chunk（文本块实体，关系型）：存储Chunk的元数据，只保留向量ID（与向量库绑定），不存原始向量，是关系型与向量数据的核心桥梁。
• 向量数据模型设计（语义检索核心）：在Milvus中创建“knowledge_vector_collection”集合，与关系型Chunk表的vector_id一一对应。

7、RAG关键代码

7.1、Ma ven依赖引入

用SpringAI来集成模型和向量数据库，需要添加下面的依赖：

    io.milvus
    milvus-sdk-ja va


    org.springframework.ai
    spring-ai-starter-model-ollama

7.2、知识数据向量化入库

核心流程就是“文档分块 → 向量化 → Milvus入库”：

// 1、初始化Embedding模型
EmbeddingModel embeddingModel = OllamaEmbeddingModel
                .builder()
                .defaultOptions(OllamaEmbeddingOptions
                        .builder()
                        .model(EMBEDDING_MODEL_NAME)
                        .dimensions(VECTOR_DIMENSION)
                        .build())
                .ollamaApi(ollamaApi)
                .build();

// 2、知识文档正文分块
List chunks = splitDocument(doc.getContent());

// 3、Chunk文档向量化处理
List vectors = embeddingModel.embed(texts);

// 4、知识数据向量化入库
List vectorData = process(vectors);
UpsertResp upsertResp = client.upsert(UpsertReq.builder()
                .collectionName(collectionName)
                .data(vectorData)
                .build());

7.3、知识相似度检索

核心流程是“问题向量化 → Milvus检索”：

// 1、问题向量化
float[] keywordVector = embed(List.of(keyword)).get(0);

// 2、向量 检索
SearchReq searchReq = SearchReq.builder()
                    .collectionName(buildCollectionName(kbId))                                  
                    .data(Collections.singletonList(new FloatVec(keywordVector)))  
                    .annsField("contentVector")                                                     
                    .outputFields(Arrays.asList("id", "chunkId", "contentVector"))     
                    .limit(TOP_K_COUNT)
                    .searchParams(Map.of("radius", SIMILARITY_THRESHOLD))   // 相似度阈值
                    .build();
SearchResp searchResp = client.search(searchReq);

7.4、知识库系统交互

知识库系统交互的流程，支持对文档进行新建、管理、向量化（Embedding）、相似度检索等操作。部分截图如下：

• 知识库管理：
  
• 知识相似度检索：