在实际项目中基于 Milvus 构建 RAG 知识库已经不是新鲜事但真正把它从 Demo 推到“企业级可用”需要跨越的问题并不少文档怎么切分、向量字段怎么设计、检索结果怎么排序、Milvus 集群出现抖动时如何定位、Attu 连不上本地实例应该查哪几项。这篇文章会用一条主线把这些问题串起来用 Milvus 作为向量存储搭建一套可运行的 RAG 知识库并覆盖从架构设计、环境准备、核心代码、运行验证到生产落地的完整链路。文章面向已经了解 RAG 基本概念、但还没有系统实践过的开发者。如果你熟悉docker compose和 Python能更快进入状态如果你只写过调用 LLM 接口的脚本按本文顺序操作也能跑通一套最小知识库。建议不要在开始前纠结“Milvus 3.0 和 2.x 到底差在哪”先把版本选型和运行方式确认清楚后面所有步骤才有稳定的基准。1. 先理解 RAG 知识库为什么要依赖向量检索RAGRetrieval-Augmented Generation的目标很直接让大模型在回答问题时能先从一个外部知识源里找到相关内容再把这段内容作为上下文交给大模型生成答案。这样做能缓解模型自身的知识截止时间问题也能让回答严格限定在企业文档、内部规范或私有数据范围内。在这个流程里向量检索承担的是“找得准”的责任。文档会被切分成若干片段每个片段通过嵌入模型转成一个向量写入向量数据库。用户提问时同样把问题转成向量然后在向量数据库里执行相似度检索找出语义上最接近的若干条文档片段。1.1 为什么选 Milvus 而不是其他存储Milvus 是开源的向量数据库最核心的价值在于它把“向量存储 相似度检索 标量过滤”做成了独立的基础设施。相比直接用sklearn或numpy在内存里算距离Milvus 提供了分布式扩展能力、持久化存储和成熟的索引类型。在常见 RAG 项目里Milvus 的优势主要体现在三点支持多种索引类型例如 IVF_FLAT、HNSW、DISKANN可以根据数据量和查询性能要求选型。支持标量字段过滤检索向量时可以同时按来源、时间、业务线过滤这是企业文档检索的刚需。社区和生态成熟很多 RAG 框架、低代码平台都原生支持 Milvus接 LangChain 或 LlamaIndex 的成本较低。1.2 一套企业级 RAG 知识库的核心组成不要以为“Milvus 大模型”就是知识库的全部。一个能应对生产需求的知识库至少包含以下模块文档接入层负责从本地文件、数据库、对象存储或内部系统中拉取文档。文档解析层处理 PDF、Word、Markdown 等格式提取正文和元数据。切片策略层决定文档分成多大一块块与块之间是否重叠。嵌入模型层把切片和查询问题转成向量。这部分可以用开源模型也可以走商业 API。向量存储层Milvus 负责存储向量和标量字段并提供检索能力。排序与重排层第一次检索出候选文档后可以用 Rerank 模型对候选文档重新排序提高准确率。生成层把排序后的文档拼进 Prompt交给大模型生成答案。本文会实现其中最小可运行闭环文档解析、切片、向量化、写入 Milvus、检索、生成答案。排序与重排会放在扩展部分说明。2. 架构设计和版本选型先决定再动手很多项目失败不是因为代码写不出来而是前期选型不明确。Milvus、Attu、嵌入模型、RAG 框架这四类组件如果版本不匹配后面每一个报错都会浪费时间。2.1 Milvus 部署形态的取舍Milvus 有两种常见部署形态Standalone 和 Cluster。学习环境和中小项目优先使用 Standalone生产高可用场景再考虑 Cluster。部署形态依赖组件适用场景运维复杂度Milvus Standaloneetcd、MinIO单机学习、Demo、百万级向量验证低docker compose 可一键启动Milvus Clusteretcd、MinIO、多个 QueryNode / DataNode生产环境、数据量大、需要水平扩展高需要规划节点和监控注意Milvus 依赖 etcd 做元数据存储依赖 MinIO 或对象存储保存二进制数据。所以网上搜到 “milvus etcd” 这类关键词通常是在排查元数据存储相关的问题不是选择题而是安装依赖。2.2 Attu 与 Milvus 的版本匹配Attu 是 Milvus 的图形化管理工具用于查看 Collection、分区、索引和查询结果。很多初学者在“Attu 支持哪个 Milvus 版本”上踩坑安装时直接拉取最新版 Attu却连接不上旧版 Milvus。推荐做法是先在 Milvus 官方文档中确认当前使用的 Milvus 版本再选择同一时间段的 Attu Release 版本。如果 Milvus 是 2.4.x优先找明确支持 2.4 的 Attu 版本如果 Milvus 升级到 2.5 或更高同样要检查 Attu 的兼容说明。避免直接使用最新版 Attu 连接旧 Milvus 实例。2.3 RAG 框架选型LangChain、LlamaIndex 还是自研RAG 框架解决的问题是“把流程串起来”不会替你解决全部性能问题。LangChain生态丰富文档多适合快速原型验证。LlamaIndex在文档索引和检索方面更细致适合文档密集型知识库。自研流程当业务对 Prompt、切片、元数据过滤有强定制需求时直接用pymilvus写一条流程往往更可控。本文核心示例使用pymilvus直连 Milvus不依赖重量级框架。这样可以清楚看到每个环节发生了什么后面要替换成 LangChain 或 LangChain4j 时也不会被框架黑盒阻隔。Java 项目可以参考 LangChain4j 的 Milvus 集成模块思路一致。3. 环境准备从安装 Milvus 到启动可视化工具开始写代码前先准备一套可复现的本地环境。如果你在 Windows 上使用 Docker Desktop记得确认 WSL2 和内存配额足够如果在 Linux 服务器上部署建议至少分配 4 核 8GB 给 Milvus 相关容器。3.1 使用 Docker Compose 启动 Milvus StandaloneMilvus 官方仓库提供了 Standalone 模式的docker-compose.yml。安装前确认 Docker 和 Docker Compose 已安装docker --version docker compose version建议创建一个独立目录把 Milvus 的 Compose 文件下载到本目录mkdir -p /opt/milvus/standalone cd /opt/milvus/standalone wget https://github.com/milvus-io/milvus/releases/download/v2.4.x/milvus-standalone-docker-compose.yml -O docker-compose.yml docker compose up -d启动后执行docker compose ps正常情况下会看到etcd、minio、standalone三个容器处于运行状态。注意具体版本号要以你选择的 Milvus 版本为准不要照抄示例中的v2.4.x。如果原始材料没有明确版本先去官方 Release 页面确认兼容版本再安装。3.2 验证 Milvus 服务是否可用Milvus 默认暴露端口为19530。可以用 Python 客户端验证连通性。先创建虚拟环境并安装pymilvuspython -m venv venv source venv/bin/activate # Windows 使用 venv\Scripts\activate pip install pymilvus然后写一段最简连接代码from pymilvus import connections connections.connect(aliasdefault, hostlocalhost, port19530) print(Milvus connected)如果输出Milvus connected说明 Server 端正常。如果连接超时或报错优先检查容器状态和端口映射docker compose logs standalone | tail -20 lsof -i :195303.3 启动 Attu 并连接本地 MilvusAttu 本身是独立服务通过 Web 页面连接 Milvus。先用 Docker 启动一个 Attu 容器docker run -d -p 8000:3000 \ -e MILVUS_URLhost.docker.internal:19530 \ --name attu \ zilliz/attu:latest然后打开浏览器访问http://localhost:8000在连接页面填写Host如果 Attu 跑在 Docker 里连接宿主机 Milvus使用host.docker.internalPort19530名称自定义例如local-milvus常见坑如果 Attu 也跑在 Docker 里MILVUS_URL直接写localhost:19530会指向容器自身连接失败。应该写成host.docker.internal:19530。如果在宿主机直接启动 Attu 二进制文件则使用localhost:19530。3.4 嵌入模型的选择RAG 流程里向量质量直接来自嵌入模型。常见选择有三类类型示例说明开源本地模型BGE、M3E、GTE数据不出内网适合私有化部署商业 API 模型OpenAI 系列、国内大模型平台使用简单但需要调用外部服务并注意数据合规云厂商向量模型各家云厂商提供的 Embedding API与云环境集成好但依赖外部服务本文示例使用兼容 OpenAI 接口的 Embedding API方便替换成其他模型。真实项目中如果文档内容以中文为主建议优先验证开源中文嵌入模型的效果而不是默认使用英文模型。4. 从零实现最小 RAG 知识库这一节会把流程拆成四个阶段准备测试文档、设计 Collection 结构、执行“解析 - 切片 - 向量化 - 入库”管道、完成检索问答。四个阶段跑通后你就拥有一个可以继续扩展的知识库骨架。4.1 准备测试文档和项目结构先在项目目录下创建如下结构rag_demo/ ├── docs/ │ └── company_policy.md ├── ingest.py ├── query.py ├── requirements.txt └── utils.pydocs/company_policy.md放一段企业制度文本内容包含多个主题例如请假流程、报销规则、加班申请方便后面验证检索效果。requirements.txt内容如下pymilvus openai python-dotenv安装依赖pip install -r requirements.txt4.2 设计 Collection字段、向量维度和索引类型在 Milvus 中Collection 类似关系数据库中的表。一个 Collection 包含多个字段其中至少要有一个向量字段也可以包含主键、标量字段和动态字段。一个常见的设计如下字段名字段类型说明idINT64 或 VARCHAR主键建议使用文档块的哈希值或 UUIDtextVARCHAR原始文档片段用于返回给 LLMsourceVARCHAR来源文件路径用于过滤和追溯embeddingFLOAT_VECTOR向量字段维度与嵌入模型一致示例中嵌入模型输出维度为 1024当然不同模型维度不同。创建 Collection 时维度必须和模型输出维度一致否则插入数据会报错或者查询时返回空结果。在ingest.py中实现创建 Collection 的逻辑from pymilvus import connections, Collection, CollectionSchema, FieldSchema, DataType, utility connections.connect(aliasdefault, hostlocalhost, port19530) COLLECTION_NAME knowledge_base if utility.has_collection(COLLECTION_NAME): collection Collection(COLLECTION_NAME) else: id_field FieldSchema(nameid, dtypeDataType.VARCHAR, is_primaryTrue, max_length64) text_field FieldSchema(nametext, dtypeDataType.VARCHAR, max_length65535) source_field FieldSchema(namesource, dtypeDataType.VARCHAR, max_length512) embedding_field FieldSchema(nameembedding, dtypeDataType.FLOAT_VECTOR, dim1024) schema CollectionSchema( fields[id_field, text_field, source_field, embedding_field], descriptionRAG knowledge base collection, enable_dynamic_fieldTrue, ) collection Collection(nameCOLLECTION_NAME, schemaschema) index_params { index_type: HNSW, metric_type: COSINE, params: {M: 16, efConstruction: 200}, } collection.create_index(field_nameembedding, index_paramsindex_params) print(fCollection {COLLECTION_NAME} created with index {index_params})这里选择 COSINE 距离而不是 L2是因为文本嵌入模型经过归一化后余弦相似度更容易直观理解值接近 1 表示语义相近接近 0 或负值表示不相关。HNSW 是图索引适合中小数据量和低延迟场景。M控制图节点的连接数越大召回率越高但内存占用越大efConstruction控制建索引时的搜索深度越大索引质量越好但耗时更长。4.3 实现文档解析与切片文档解析的目标是把 PDF、Word、Markdown 中的纯文本提取出来。示例中先处理 Markdown 文件def load_markdown(path: str) - str: with open(path, r, encodingutf-8) as f: return f.read()切片是影响检索质量的关键环节。切片过大单段文本主题混杂检索结果不精确切片过小会丢失上下文且向量表征不稳定。常见切分策略有三种策略优点缺点固定长度切片简单可控速度最快可能在句子中途切断按结构切片按标题、段落切分语义完整需要文档结构较规范递归切分按分隔符逐级切分兼顾完整性和长度实现复杂度略高推荐先用递归切分。这里直接实现一个简化版本def recursive_split(text: str, chunk_size: int 500, overlap: int 50) - list[str]: chunks [] start 0 while start len(text): end start chunk_size # 尽量在换行符位置截断 if end len(text): newline_pos text.rfind(\n, start, end) if newline_pos ! -1 and newline_pos start chunk_size // 2: end newline_pos chunk text[start:end].strip() if chunk: chunks.append(chunk) start max(end - overlap, start 1) return chunkschunk_size和overlap都是超参数。overlap的作用是让相邻切片共享一小段文本避免关键句刚好落在切片边界而被切断。注意不要追求一套切片参数适配所有文档。企业知识库通常包含制度、技术文档、问答记录等不同内容类型建议按内容类型配置不同参数并通过检索效果评测反向调整。4.4 调用 Embedding 接口生成向量示例使用 OpenAI 兼容的 Embedding 接口。先把 API Key 写入.env文件OPENAI_API_KEYyour_api_key OPENAI_API_BASEhttps://your-endpoint EMBEDDING_MODELyour-embedding-model然后封装一个获取向量的函数import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_API_BASE), ) def get_embedding(text: str) - list[float]: resp client.embeddings.create( modelos.getenv(EMBEDDING_MODEL), inputtext, ) return resp.data[0].embedding生成向量后应该立即检查维度是否和 Collection 中dim1024一致test_vec get_embedding(测试文本) print(len(test_vec))如果维度不一致后面的insert一定会失败属于最常见错误之一。4.5 写入 Milvus批量插入和索引构建使用批量接口插入数据避免逐条插入造成网络往返开销from pymilvus import Collection import hashlib import uuid collection Collection(knowledge_base) def ingest_document(file_path: str): text load_markdown(file_path) chunks recursive_split(text) ids [] texts [] sources [] embeddings [] for i, chunk in enumerate(chunks): chunk_hash hashlib.md5(f{file_path}:{i}.encode()).hexdigest() ids.append(chunk_hash) texts.append(chunk) sources.append(file_path) embeddings.append(get_embedding(chunk)) collection.insert([ids, texts, sources, embeddings]) print(fInserted {len(chunks)} chunks from {file_path}) ingest_document(docs/company_policy.md)插入后还需要构建索引。虽然前面创建 Collection 时已经定义了index_params但索引真正生效要等数据写入后再创建或调用load前确认。collection.flush() collection.create_index( field_nameembedding, index_params{index_type: HNSW, metric_type: COSINE, params: {M: 16, efConstruction: 200}}, ) collection.load()flush会把内存中的数据落盘load会加载索引到内存或内存映射文件中查询前必须执行。4.6 实现检索相似度查询和标量过滤查询流程如下对用户问题生成向量。指定输出字段和 TopK。可选地加入expr条件过滤来源或业务线。在返回结果中取出text字段拼入 Prompt。query.py的核心代码from pymilvus import Collection, connections from utils import get_embedding connections.connect(aliasdefault, hostlocalhost, port19530) collection Collection(knowledge_base) collection.load() def search_related_docs(question: str, top_k: int 5, source_filter: str | None None): question_vec get_embedding(question) search_params { metric_type: COSINE, params: {ef: 128}, } expr None if source_filter: expr fsource {source_filter} results collection.search( data[question_vec], anns_fieldembedding, paramsearch_params, limittop_k, exprexpr, output_fields[text, source], ) docs [] for hits in results: for hit in hits: docs.append({ text: hit.entity.get(text), source: hit.entity.get(source), score: hit.score, }) return docssearch_params中的ef是查询时的动态搜索宽度只在 HNSW 索引下有效。ef越大召回质量越高但查询延迟越高。调优时可以在准确率和延迟之间取平衡。4.7 拼接 Prompt 并调用大模型生成答案检索到text片段后不能直接把全部片段塞进 Prompt。需要控制上下文长度并且明确告诉大模型只能基于给定资料回答。def generate_answer(question: str, top_k: int 5): docs search_related_docs(question, top_ktop_k) context \n\n---\n\n.join([f[来源: {doc[source]}]\n{doc[text]} for doc in docs]) prompt f请基于以下资料回答问题。 资料 {context} 问题{question} 要求 1. 如果资料中没有相关信息直接回答“资料中未找到相关信息”。 2. 不要编造资料中不存在的内容。 3. 回答末尾列出参考资料来源。 resp client.chat.completions.create( modelos.getenv(CHAT_MODEL), messages[{role: user, content: prompt}], temperature0.3, ) return resp.choices[0].message.content, docstemperature0.3是为了降低生成内容的随机性。知识库问答属于事实性任务不建议使用过高温度。4.8 完整跑通流程后你会看到什么运行入库脚本python ingest.py预期输出Collection knowledge_base created with index {index_type: HNSW, metric_type: COSINE, params: {M: 16, efConstruction: 200}} Inserted 12 chunks from docs/company_policy.md运行问答脚本python query.py这里需要在query.py中固定一个问题或者通过命令行参数传入。建议先准备三个不同类型的问题验证效果能在文档中找到答案的问题、需要跨多个切片整合信息的问题、文档中完全没有答案的问题。第三个问题尤其重要。它检验的不是模型能力而是你的 RAG 系统是否会让模型在找不到资料时“硬答”。如果模型开始编造内容说明 Prompt 和切片策略还需要调整。5. 运行验证不要只验证“能启动”很多 RAG 项目停在了“能跑”阶段但对一个企业级知识库来说“能跑”远不等于“可用”。本节给出一个可操作的验证方法以及一个简化的 RAG 评测方案。5.1 用三个问题检查基础链路建议先把验证集做得足够小但覆盖多种类型问题类型示例预期单一切片可回答“年假申请需要提前几天提交”回答命中知识库具体条款并给出来源跨切片整合“申请报销车票需要准备哪些材料流程是什么”回答能综合多个切片的信息文档外问题“公司是否有境外保险福利”回答明确说明未找到相关信息如果第二类问题答不好优先看切片是否太小、TopK 是否足够、是否需要重排模型。如果第三类问题答错优先调整 Prompt 要求必要时先做一轮关键词过滤检索不到相关内容就直接拒绝回答。5.2 检查 Milvus 中的数据形态在 Attu 中进入knowledge_baseCollection可以看到三个层面的信息实体列表确认text字段内容是否完整切片是否过长或过短。索引状态确认 HNSW 索引已经构建成功。查询测试直接在 Attu 中嵌入一个向量进行检索对比 TopK 结果是否合理。如果查询返回的分数都很低例如 COSINE 相似度只有 0.4 左右通常说明嵌入模型与文档领域不匹配或切片中存在大量噪声内容。5.3 建立最小评测集而不是靠感觉调参RAG 上线前至少需要一个可重复的评测步骤。最简做法是准备 20 到 50 组“问题 - 期望答案片段”标注对然后计算两个指标RecallK正确答案是否出现在 TopK 检索结果中。人工评分或 LLM 评分生成答案是否正确、完整、可引用。指标计算方式作用RecallK正确答案出现在 TopK 的比例检验检索模块是否找得到答案正确率正确答案与期望答案匹配比例检验生成模块是否答得对引用准确率回答内容是否有相应文档支持检验是否“硬答”或编造这一步不需要一开始做得很重。先把评测集建起来之后调整切片长度、嵌入模型、TopK、是否加重排时才知道改动到底是让系统变好还是变差。没有评测集的调参只能叫碰运气。6. 常见问题排查从现象定位根因这一节总结 RAG 知识库项目中高频出现的几类问题。排查顺序一般是从环境到代码再从数据到模型不要一上来就怀疑 Milvus。6.1 Attu 连接不上本地 Milvus现象打开 Attu 页面后连接报错提示 timeout 或 connect refused。检查链路确认 Milvus Standalone 容器在运行docker compose ps。确认 19530 端口被监听lsof -i :19530或ss -lnt | grep 19530。确认 Attu 中填写的 Host 不是容器内部地址。Docker 中的 Attu 连宿主机 Milvus 要使用host.docker.internal。确认 Milvus 与 Attu 的版本兼容性。问题现象常见原因检查方式连接超时网络不通或容器未启动docker compose ps加 19530 端口检查连接 refused端口映射错误或 Milvus 未监听查看docker compose logs standalone版本不兼容Attu 与 Milvus 版本跨度过大查询官方版本兼容表6.2 插入向量时报维度错误现象insert时报invalid dimension或field dimension mismatch。处理步骤打印嵌入向量的len()和 Collection 中dim参数对比。如果换过嵌入模型必须重新检查维度。不同模型输出维度差异很大常见有 384、512、768、1024、1536 等。修改维度后建议删除旧 Collection 重建而不是在旧 Collection 上强行插入。6.3 查询返回空结果或分数异常现象查询返回 0 条或分数低到没有参考价值。可能原因和排查顺序Collection 是否执行了load()。Milvus 查询前必须加载数据未加载会报错或返回空。索引是否创建成功。如果数据量很小且没建索引部分查询也能跑但生产场景必须建立索引。嵌入模型是否和建库时一致。如果入库用 A 模型查询用 B 模型即使向量维度相同语义空间也不一致结果必然不准。查询参数中metric_type是否与索引一致。比如索引用 COSINE查询却写成 L2结果排序会不符合预期。6.4 升级或修改知识库时报 Internal Server Error这个现象在 Dify、Attu 等平台搭配 Milvus 时经常出现典型场景是升级后无法保存知识库或修改知识库时报internal server error。排查重点看 Milvus 端日志确认是不是 Collection 状态异常。看平台日志确认错误是出在 Milvus 客户端调用还是平台自身处理逻辑。当etcd中元数据与 MinIO 中实际数据不一致时常见的原因是升级过程中组件版本不一致导致数据节点或查询节点启动失败。处理建议排查升级路径是否跨过太多版本。Milvus 升级通常需要沿版本链逐级升级直接跳到最新版本可能无法自动迁移。知识库数据可重建时优先考虑重建 Collection而不是花大量时间修复异常元数据。数据库、对象存储和向量数据库在任何变更前先做备份和快照。6.5 检索结果不准是模型问题还是切片问题先确认检索召回是否准确再判断生成质量。如果召回的text本身与问题无关回答肯定不可靠。此时按以下顺序排查检查切片长度是否超过嵌入模型的最大输入长度超长会被截断语义可能被破坏。检查切片是否把多个主题混在一起。一个切片里同时讨论年假和报销检索时只能体现一段主题另一个主题会被遗漏。检查嵌入模型与文档领域是否匹配。通用模型在垂直领域上的表现可能明显变差。检查 TopK 是否过小。如果问题依赖多个片段top_k2很可能不够。7. 生产环境落地从 Demo 到可维护系统的距离本地跑通 Demo 只是起点。进入生产后仅仅多几台机器远远不够必须把配置、权限、监控、数据治理补齐。7.1 环境差异对照维度学习环境生产环境Milvus 部署Standalone Docker ComposeCluster 或托管服务规划资源嵌入模型外部 API 或本地小模型私有化部署或经过数据合规评估的模型鉴权无开启 TLS、配置认证和访问控制数据备份无对象存储快照、Milvus 数据备份、etcd 备份监控手动看日志Prometheus Grafana、Milvus 监控指标发布变更直接改代码灰度发布、索引切换、Collection 版本管理评测手工验证几个问题自动化评测集纳入 CI7.2 参数和生产经验建议嵌入模型选型如果文档以中文为主优先测试中文语料最优的开源模型不能只看榜单分数。如果对数据安全有强要求放弃外部 API本地部署嵌入模型并做好 GPU 资源规划。Collection 设计不同业务知识建议拆成不同 Collection或者在同一 Collection 中用业务字段过滤不要让一个 Collection 承担所有类型。主键建议使用VARCHAR类型的哈希值方便后续幂等写入。索引参数参数推荐范围说明index_typeHNSW数据量千万级以下普遍适用metric_typeCOSINE文本向量推荐语义可比性强M16 ~ 32越大内存开销越高efConstruction200 ~ 500建索引时间与质量权衡ef查询128 ~ 512按查询延迟动态调整7.3 完整清单上线前检查以下清单可以复制到你们的发布文档中[ ] Milvus 版本与 RAG 框架版本兼容。[ ] Attu 版本与 Milvus 版本匹配。[ ] Collection 维度与嵌入模型输出维度一致。[ ] 切片参数已经通过评测集验证。[ ] 索引类型、距离度量和查询参数一致。[ ] 查询前已执行load()生产环境确认索引加载策略。[ ] 业务数据通过标量字段区分避免跨业务串数据。[ ] 开启鉴权和网络访问控制向量数据库不直接暴露公网。[ ] 配置监控告警Milvus 节点状态、查询延迟、磁盘使用率。[ ] 配置数据备份Milvus 数据、etcd 元数据、对象存储。[ ] 建立评测集记录每次调参前后的 RecallK 和答案正确率。[ ] 对“未检索到答案”的情况定义兜底回答防止模型编造。7.4 下一阶段可以扩展的方向迷你知识库跑通后根据业务需要选择扩展方向Rerank 重排检索出 Top50再用重排模型选出 Top5配合 Milvus 的粗排能力。Graph RAG当文档强调实体关系时可结合图结构保存关系提升多跳问答能力。Agentic RAG当问题需要多步查询或工具调用时把 RAG 流程交给 Agent 编排而不是固定“检索一次、生成一次”。多模态知识库在 Milvus 中同时管理文本向量和图像向量。Java 服务化使用 LangChain4j 集成 Milvus把知识库能力封装成内部 API供业务系统调用。在整个扩展过程中最重要的一点始终没有变任何检索策略和模型调整都要先有评测集再谈优化。没有评测基准的知识库无法判断改动是改进还是回退。8. 常见误区与最终建议第一次搭建 RAG 知识库的人通常会在几个地方反复踩坑。如果你时间有限先记住这四条经验不要直接信任“默认参数”。chunk_size500不是通用答案它只在特定文档结构下表现尚可。你的切片参数需要基于自己的知识库内容去调整。不要混用嵌入模型。入库和查询必须使用同一个模型否则检索效果会大幅退化。换模型时必须重建 Collection。不要把搜索参数写死。ef、top_k、distance metric这些参数最好外置成配置项方便在不同环境切换。不要跳过生产安全。Milvus 默认配置面向学习环境生产环境至少要开启认证、限制端口访问并配置备份。最后给刚开始学习的开发者一个练习建议先用自己的 50 篇文档搭出最小系统记录当前参数下的评测结果再每次只改动一个变量。例如只调整切片重叠大小或者只更换嵌入模型观察指标变化。经过几轮这样的实验你对 RAG 的理解会远远超过只会调用框架接口的人。