LlamaIndex 与 Milvus 实战：从 CRUD 到智能检索的完整路线

做RAG检索增强生成这一年多我最大的感受是一个问答系统好不好用决定上限的不是大模型的聪明程度而是检索层能不能把对的内容捞出来。之前我用本地文件加一个简单的向量索引做原型几万条文档就卡得不行元数据过滤更是想都别想。后来换成 LlamaIndex 配 Milvus 向量数据库从最基础的增删改查CRUD到能支撑业务的智能检索整个路径踩了不少坑也总结出一些能直接用的经验。这篇文章就是把这条完整路线梳理一遍为什么选 Milvus、Collection 怎么设计、增删改查怎么写、LlamaIndex 怎么接进来实现带过滤条件的语义检索。不管你是刚接触向量数据库的新手还是已经在做 RAG 项目但被检索性能折磨过的开发者这篇文章都能给你一条可以直接照着做的路线也会把我踩过的坑原原本本摆出来。1. 为什么是 Milvus向量数据库选型背后的考量1.1 从精确匹配到语义检索的思维切换传统数据库擅长的是精确匹配查订单表WHERE status PAID查用户的年龄WHERE age 30。这种查询的前提是数据本身具备结构化特征条件是明确指定的。但到了搜索“跟某段话意思相近的文档”这个需求时传统 SQL 就完全使不上劲了——你不能用等值匹配去查“相似”也没法用索引去加速“意思相近”。这里的核心转变是把文本变成向量——一串几百维的浮点数让语义相近的文本在向量空间里距离更近。检索就变成了“算距离”给定一个查询向量找出向量空间里最接近的那一批。这就是向量检索的基本逻辑也是 RAG 应用里最常见的技术底座。向量检索说到底就是 K 近邻搜索的工程化落地。数据量小的时候你可以暴力把每一条都算一遍距离几万条也能接受。但一旦到几十万、上千万条每次查询都把全场扫一遍延迟和资源消耗都扛不住。这时候就需要专门的索引结构来做近似最近邻搜索ANN用精度换速度在“差不多的结果”和“毫秒级延迟”之间取一个工程上可接受的平衡点。1.2 Milvus 与其他方案的对比市面上向量检索方案很多从轻量的 FAISS、HNSW 库到成熟的向量数据库 Milvus、Qdrant、Weaviate 等。我最初直接用 FAISS用起来确实简单但有两个硬伤一是所有数据都在内存里几百万条向量轻松吃掉几十 GB 内存二是数据持久化要靠自己管理程序重启还要重新加载索引写文档、删文档这些操作都没有现成接口。Milvus 这类真正的向量数据库则把这些问题都解决了。它的对比优势可以简单列一下能力FAISS 等嵌入式方案Milvus数据持久化自行管理重启需重新加载内置持久化重启即用增删改查不支持需自行实现完整支持 CRUD标量字段过滤不支持支持表达式过滤可与向量检索组合动态扩容困难分布式架构天然支持生态集成手动写胶水代码LlamaIndex 等框架有官方集成这个表透露出一个关键信息如果你的项目停留在原型验证阶段数据量不大、没有复杂的过滤需求FAISS 足够但一旦要上生产、积累数据、多人使用Milvus 的工程完备性是嵌入方案没法比的。选用 Milvus 还有一个重要原因它跟 LlamaIndex 有官方集成。这意味着我可以不用自己写向量插入、索引构建、相似度查询的底层代码直接用框架封装好的接口做业务逻辑开发效率高很多。2. Milvus 环境搭建与 Collection 设计2.1 用 Docker Compose 快速启动一个 MilvusMilvus 的 standalone 模式是单体部署适合开发环境。我用 Docker Compose 拉起三个组件etcd元数据存储、minio对象存储存向量数据文件、milvus主服务。这个组合是官方推荐的开发启动方式。下面的docker-compose.yml是实测可用的version: 3.5 services: etcd: container_name: milvus-etcd image: quay.io/coreos/etcd:v3.5.5 environment: - ETCD_AUTO_COMPACTION_MODErevision - ETCD_AUTO_COMPACTION_RETENTION1000 - ETCD_QUOTA_BACKEND_BYTES4294967296 - ETCD_SNAPSHOT_COUNT50000 volumes: - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/etcd:/etcd command: etcd -advertise-client-urlshttp://127.0.0.1:2379 -listen-client-urls http://0.0.0.0:2379 --data-dir /etcd healthcheck: test: [CMD, etcdctl, endpoint, health] interval: 30s timeout: 20s retries: 3 minio: container_name: milvus-minio image: minio/minio:RELEASE.2023-03-20T20-16-18Z environment: MINIO_ACCESS_KEY: minioadmin MINIO_SECRET_KEY: minioadmin volumes: - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/minio:/minio_data command: minio server /minio_data --console-address :9001 healthcheck: test: [CMD, curl, -f, http://localhost:9000/minio/health/live] interval: 30s timeout: 20s retries: 3 milvus: container_name: milvus-standalone image: milvusdb/milvus:v2.4.1 command: [milvus, run, standalone] security_opt: - seccomp:unconfined environment: ETCD_ENDPOINTS: etcd:2379 MINIO_ADDRESS: minio:9000 volumes: - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/milvus:/var/lib/milvus ports: - 19530:19530 - 9091:9091 depends_on: - etcd - minio启动命令很直白docker compose up -d启动后可以检查一下容器状态三个容器都健康了再继续。测试连接最直接的方式是用 pymilvus 连一下 19530 端口from pymilvus import connections connections.connect(aliasdefault, hostlocalhost, port19530) print(connections.get_connection_addr(default))能打印出连接地址就说明 Milvus 已经就绪。我见过很多人第一步就卡在这镜像拉取慢、端口冲突、内存不够Milvus standalone 至少需要 8GB 内存才跑得比较顺小机器硬跑容易出现组件被操作系统杀掉的情况表现就是连接时不时断开。2.2 Collection Schema先把“表结构”想清楚再动手用过关系型数据库的人对“先设计表再写入”这件事很熟练但到了向量数据库反而容易忽略因为一开始兴冲冲就是想赶紧把数据塞进去。其实 Collection 的设计直接决定了后续检索的效果和灵活性。Collection 相当于关系数据库里的表里面可以包含两类字段标量字段和向量字段。向量字段嵌入模型直接决定维度比如常用的文本向量模型输出通常是 1024 维或 1536 维文本内容本身可以单独存一个字段后续要展示原文时直接取出。此外建议额外加业务字段比如文档分类、时间戳、来源标识这样后续可以组合检索条件只搜某个分类下的相似内容这是纯向量检索做不到的。我设计了一个典型的论文资料库 Collection字段结构如下from pymilvus import ( CollectionSchema, FieldSchema, DataType, Collection, utility, ) fields [ # 主键用自增整型注意 Milvus 2.x 的主键不支持字符串自增 FieldSchema(namepk, dtypeDataType.INT64, is_primaryTrue, auto_idTrue), # 原文内容 FieldSchema(nametext, dtypeDataType.VARCHAR, max_length8192), # 向量字段dim 由 embedding 模型决定 FieldSchema(nameembeddings, dtypeDataType.FLOAT_VECTOR, dim1024), # 业务标量字段分类、时间用于过滤 FieldSchema(namecategory, dtypeDataType.VARCHAR, max_length64), FieldSchema(namecreated_at, dtypeDataType.INT64), ] schema CollectionSchema( fieldsfields, description文档向量集合, enable_dynamic_fieldFalse, ) collection_name documents # 如果已存在先删掉再建方便重复实验 if utility.has_collection(collection_name): Collection(collection_name).drop() collection Collection(collection_name, schemaschema)代码里有个容易被忽略的细节auto_idTrue之后插入数据时不需要传主键。这是大概率会用到的设置因为业务系统里很少需要手动指定一个全局唯一 ID与其自己生成再维护一份 ID 映射不如交给数据库自动管理。不过也要做取舍如果后续需要把 Milvus 里的记录和业务数据库里的记录做关联那主键由你自己控制更好把业务 ID 传进去。两种方案我都试过经验是纯 RAG 场景自动 ID 足够省心涉及业务关联就用自己的 ID。Collection 设计没有绝对正确答案预判好数据怎么生长、怎么检索比抄模板更重要。2.3 索引与距离度量方式的选择建完 Collection 后要做两件事创建向量索引和加载到内存。Milvus 的设计里查询发生在内存中所以每个 Collection 要先执行load才能查。不加载直接查会抛异常这也是新手最常见的问题之一。索引参数直接决定了检索速度和召回质量。我习惯对中等数据规模使用 HNSW 索引index_params { index_type: HNSW, metric_type: IP, # IP / COSINE / L2三选一 params: { M: 16, efConstruction: 200, }, } collection.create_index( field_nameembeddings, index_paramsindex_params, ) collection.load()选索引类型和参数的逻辑值得展开讲。M表示每个节点在构图时连接的最大边数值越大图越稠密检索效果通常越好但内存占用和建图时间都会上升16到32是相对平衡的范围。efConstruction控制建索引时的动态列表长度值越大索引质量越好但建索引更慢数据量不大几百万内建议设为200。metric_type的选择要结合 embedding 模型来定。如果 embedding 模型本身做了向量归一化那么 L2 距离、余弦相似度、内积IP的结果排序是一致或者等价的。如果模型没归一化一般直接选 COSINE 更符合“语义相似度”的直觉。内积适合那些可以用点积直接衡量相关性的场景。我测试的向量模型做的是归一化输出用 IP 和 COSINE 排序结果没有明显差别这里为了和 LlamaIndex 默认配置对齐选用了 IP。这里有一个特别提醒Collection 创建后字段结构、索引参数基本不可修改。想改只能删掉重建、重新导入数据。所以新建项目时向量维度、索引类型、度量方式这些关键参数要一次定对否则后面就是返工。我的做法是在 demo 阶段用不同参数各建一个 Collection 实测对比之后再定正式结构这批测试数据都走同一个脚本生成保证对比公平。3. CRUD 实战从插入、查询到删除的闭环3.1 数据插入的两种正确姿势Collection 创建好之后接下来就是写入数据。这一步我踩过最大的坑是数据类型不匹配——VARCHAR字段传了 Python 的str没问题但整数时间戳传成字符串就会直接报错而且错误信息不大明显。插入代码本身不复杂把字段按顺序组成列表传入即可from pymilvus import Collection collection Collection(documents) texts [ Milvus is a vector database built for similarity search., LlamaIndex provides a framework for connecting data to LLMs., Retrieval augmented generation combines retrieval and generation., ] categories [tech, ai, rag] timestamps [1710000000, 1710000100, 1710000200] # 这里故意不传主键因为 auto_idTrue 会自动生成 data [texts, # text 字段 None, # embeddings 字段留给占位下面替换 categories, timestamps] # 正确做法先构建随机向量或真实模型生成的向量 import random random.seed(42) embeddings [[random.random() for _ in range(1024)] for _ in range(len(texts))] data[1] embeddings result collection.insert(data) print(f插入数量: {result.insert_count})这样写虽然能跑通但有三个值得优化的点第一数据插入按字段分列插入而不是按行插入理解这个结构后写批量插入不容易乱。第二我只用了随机向量做演示真实项目里这里要替换成 embedding 模型的输出。第三插入后别忘了做一个 flush确保数据落盘Milvus 默认是异步持久化直接查询可能查不到刚插入的数据collection.flush()对于大量数据批量导入还有另一个更推荐的做法用pymilvus的数据导入工具bulk_writerbulk_import或官方提供的数据管理工具先把数据写成 Parquet 文件传到对象存储再触发导入任务。这种方式适合几百万条以上的初始化数据速度比逐条插入快一个量级。不过项目规模的 CRUD 场景直接用 API 插入就足够了。3.2 查询相似度检索与标量过滤组合CRUD 中间的 RRead在向量数据库里分两种形态一种是精确读取按主键查询另一种就是核心的相似度检索。两种形态对应不同 API。精确查询用的是querycollection.query( exprpk in [1, 2, 3], output_fields[text, category] )大多数场景下真正关心的还是向量相似度检索也就是search。一个简单的基于查询文本的相似度检索需要把查询文本转成向量再传进去from pymilvus import Collection collection Collection(documents) # 假设 query_vector 是某向量模型生成的查询向量 result collection.search( data[query_vector], # 注意是二维列表支持一次多向量查询 anns_fieldembeddings, # 指定检索的向量字段 param{metric_type: IP, params: {ef: 64}}, limit5, # 返回 Top 5 output_fields[text, category, created_at] ) for hits in result: for hit in hits: print(fID: {hit.id}, 距离: {hit.distance}, 文本: {hit.entity.get(text)})这里ef是查询时候的搜索范围可以动态调整值越大召回越准但越慢这个参数和建索引时的efConstruction不是一回事别弄混。组合标量过滤的场景更常见。比如要查“2024 年之后属于 ai 分类的文档”可以这样写filter_expr category ai and created_at 1710000000 result collection.search( data[query_vector], anns_fieldembeddings, param{metric_type: IP, params: {ef: 64}}, limit5, exprfilter_expr, # 标量过滤条件 output_fields[text, category, created_at] )过滤条件的语法与标准 SQL 有所差异但很接近比较操作符、逻辑组合、in操作符都好用。我第一次用的时候把写成了直接报语法错误后来就长记性了。3.3 更新与删除upsert 和 delete 的正确用法向量数据的更新和删除与关系型数据库有个显著不同向量字段更新会涉及索引重建代价比纯标量字段高很多所以设计时要尽量不让向量值高频变动。如果确实需要更新Milvus 提供了upsert接口# upsert 需要显式传入主键 from pymilvus import Collection collection Collection(documents) # 假设主键存在同时更新文本和向量 result collection.upsert( data[ [1001], # pk [新的文本内容], # text [[0.01, 0.02, ...]], # embeddings [ai], # category [1711000000], # created_at ] ) print(result.upsert_count)需要重点强调的是upsert的语义是“存在则更新不存在则插入”但你不要指望它像关系数据库一样有一层事务保护。Milvus 的 upsert 实际上是先按主键删除旧数据再插入新数据这个操作在并发场景下可能出现一个小时间窗查询时暂时看不到该条数据。对要求严格一致性的项目建议自行管理主键和状态先删后插也行。删除操作相对简单collection.delete(pk in [1001, 1002]) # 按条件批量删除 collection.delete(category temp and created_at 1700000000)有一个容易忽略的点内存中的索引不能做到即时反映删除。执行delete后数据会在后台 compaction 中被真正清理如果在同一时刻执行查询这条被删的数据可能仍然被检索到。实践中业务上能接受的场景可以等一两秒要求严格同步的业务需要自己做缓存层或者软删除标记。CRUD 这一层做完后我对 Milvus 的一个整体判断是它的设计兼具了传统数据库的熟悉感和向量检索的专用能力。但不要拿它去当普通业务数据库用——标量字段的复杂事务、审计日志这些还是交给关系型数据库Milvus 管好“向量 过滤”这层就够了。4. 用 LlamaIndex 串联 Milvus从底层操作到智能检索4.1 为什么要用 LlamaIndex 去接 Milvus直接用 pymilvus 写 CRUD 和查询没问题但距离一个完整的“读文档 → 切分 → 向量化 → 检索增强问答”流程还有不少距离。LlamaIndex 的价值就是把文档加载、文本切分、向量生成、索引管理、检索问答这整条链路统一编排。你在 LlamaIndex 里操作一个高阶对象比如VectorStoreIndex底层会自动完成叫 Milvus 去建 Collection、插向量、构建索引这些事。带着 CRUD 的基础去理解 LlamaIndex 的集成会顺手很多。因为你需要知道 LlamaIndex 在幕后做了什么、什么时候做了什么。比如第一次运行一段代码时它自动创建了哪个 Collection字段结构是什么样的这直接关系到你后续能不能手动去操作这批数据。4.2 最小可跑的集成代码先看一段从文档构建检索问答系统的最小代码from llama_index.core import ( SimpleDirectoryReader, StorageContext, VectorStoreIndex, ) from llama_index.vector_stores.milvus import MilvusVectorStore # 1. 读取本地文档 documents SimpleDirectoryReader(data).load_data() # 2. 配置 Milvus 存储 vector_store MilvusVectorStore( urihttp://localhost:19530, collection_namellamaindex_docs, dim1024, overwriteTrue, ) # 3. 构建索引自动完成切分、向量化、写入 Milvus storage_context StorageContext.from_defaults(vector_storevector_store) index VectorStoreIndex.from_documents( documents, storage_contextstorage_context, ) # 4. 创建检索引擎直接做问答 query_engine index.as_query_engine(similarity_top_k5) resp query_engine.query(Milvus 和 FAISS 有什么区别) print(resp)这段代码看起来简单但理解它在内部做了哪些事非常重要SimpleDirectoryReader读取文件夹下的文件变成文档对象。MilvusVectorStore连接 Milvus指定了 Collection 名称和向量维度。overwriteTrue表示如果 Collection 已存在就直接删掉重建开发时方便生产环境慎用。VectorStoreIndex.from_documents内部会自动做文档切分默认按固定 chunk size 切、调用默认的 embedding 模型生成向量、把向量写入 Milvus 指定 Collection。如果你已经提前创建好了 Collection更高效的做法是不用from_documents重新嵌入一遍而是用from_vector_store直接连接已有数据vector_store MilvusVectorStore( urihttp://localhost:19530, collection_namedocuments, dim1024, ) index VectorStoreIndex.from_vector_store(vector_store) query_engine index.as_query_engine(similarity_top_k3) resp query_engine.query(这个集合里有哪些和向量索引相关的内容)我自己实际项目里用的是这个方式数据管道用独立的脚本写入 Milvus问答服务启动时只做连接、不重复嵌入启动速度快处理新数据时也不需要重启服务。LlamaIndex 的集成把底层操作桥接得比较好但你不必被它绑住。4.3 元数据过滤器让检索更精准的关键参数LlamaIndex 的MilvusVectorStore其实把之前提到的标量过滤包装成了 metadata 过滤。你可以通过MetadataFilters指定过滤条件然后交给检索器执行。比如只搜索某个分类下的内容from llama_index.core.vector_stores import MetadataFilters, ExactMatchFilter filters MetadataFilters( filters[ ExactMatchFilter(keycategory, valuerag), ] ) query_engine index.as_query_engine( similarity_top_k5, filtersfilters, ) resp query_engine.query(RAG 技术的主要步骤是什么)这里要提醒一下LlamaIndex 的ExactMatchFilter默认对应的是标量字段的等值匹配。如果你的 Milvus Collection 是 LlamaIndex 自动创建的它会在 schema 里预留一个metadata字段存放文档的附加元数据过滤器本质上就是在那个字段上做表达式过滤。如果你像第 2 节那样手动建了 Collection并且自定义了category字段记得检查过滤器字段名与 Collection 里实际字段名是否一致不一致会导致检索结果为空。另外由于底层有过滤条件与向量相似度检索的组合执行过滤不会额外拖慢太多速度——Milvus 处理 ANN 加标量过滤这套组合检索的效率还是不错的。但如果过滤条件本身选择率很低比如筛出 0 条最终 Top K 的结果可能不够需要在应用层做兜底逻辑判断。4.4 查询改写与对话式检索智能检索的进阶形态as_query_engine已经解决了基础 RAG但它有个明显短板用户的提问往往是口语化的、省略上下文的。比如先问“Milvus 的索引有哪些类型”再追问“哪个最快”第二次提问里没有出现 Milvus 这个词。如果直接拿这句去检索召回效果很差。这个场景就需要拓展查询改写和对话记忆。LlamaIndex 里可以用CondenseQuestionChatEngine或者带上下文压缩的检索器来处理。核心思路是把历史对话交给大模型让大模型结合上下文把当前问题改写成一个完整的独立查询然后再去 Milvus 里做检索。我这里用一个简化的实现展示思路from llama_index.core.query_engine import CustomQueryEngine from llama_index.core.llms import LLM class CondenseQueryEngine(CustomQueryEngine): 改写问题后再走向量检索的查询引擎。 query_engine: CustomQueryEngine llm: LLM def custom_query(self, query_str: str): # 用大模型把问题改写为完整表述实际需结合历史 rewritten self.llm.complete( f把下面的问题改写为意思不变但包含完整上下文的独立问句{query_str} ) return self.query_engine.query(str(rewritten))这只是示意实际业务上我通常配合memory组件存在把历史对话存储下来改写时把最近几轮拼进 prompt。效果方面对话式检索对用户体感的提升比调检索参数来得更明显值得花时间做。5. 性能优化与常见问题排查实录5.1 检索变慢从索引、数据量和资源三方面定位一套接好的检索系统用一段时间后最容易出现的问题是查询延迟升高。我经历过的真实案例里原因无外乎三类第一类是索引类型和数据量不匹配。数据量上了千万级还一直用 HNSW 默认参数查询性能会下降。此时考虑换用 IVF_PQ 或 IVF_SQ8 这类量化索引用一定精度损失换内存占用和查询速度的优化。不过要注意量化索引在过滤条件下的表现先压测再切换。第二类是内存资源不足。Milvus 的查询依赖内存索引如果机器内存紧张会和对象存储之间频繁换入换出表现就是延迟忽高忽低。这个问题要靠监控指标观察查看 Milvus 的监控面板确认内存使用率和索引加载耗时资源不够加节点是最直接的解法。第三类是查询参数设置不合理。ef值设得太高单次查询会扫描更多图节点Top K 的limit值设得太大网络传输和后续处理也会变慢。我的经验是普通问答场景ef控制在 64 到 128limit5 返回 5 条足够数据稀疏或对召回要求极高的场景才需要更大。5.2 维度不一致最常出现的集成错误开发中遇到最高频的报错就是维度不匹配。可能产生的链路有两条embedding 模型输出 1024 维但 Collection 建表时写成了 1536 维或者 LlamaIndex 连接已有 Collection 时指定dim参数与真实情况不符。这类错误的典型表现pymilvus 直接插入时报错提示维度不匹配。LlamaIndex 首次自动建 Collection 成功后第二个流程里更换了 embedding 模型新向量维度不一致插入失败。规避方法是在项目里把 embedding 模型和维度作为统一配置常量启动时自检如果模型变了就核对 Collection 的 schema 再运行。标签化测试环境里最好带一套独立的 Milvus 实例避免模型切换污染正式数据。5.3 删除数据后查询仍然命中理解内部执行机制前面提到过删除操作的后台异步清理机制这个细节在生产环境影响很大。如果业务要求删除立即生效——比如用户在系统里删了一篇文档再问相关问题时就必须是这个文档不再出现的——只依赖 Milvus 的 delete 是满足不了的。我的解决办法是在应用层增加一层软删除标记文档库里保留记录的is_deleted状态写入 Milvus 时同步写入一个标量字段status。查询时过滤器强制加status active这样删除从应用语义上即刻生效后台清理不再影响业务体验。这是典型的“应用层兜底存储层尽力”的设计思路。5.4 文档类常见问题速查表把这一年积累的常见问题收拾成一张表方便直接对照排查现象可能原因解决方案连接 localhost:19530 超时Docker 容器未启动或端口映射错误检查docker compose ps确认三个容器都正常查询报 “collection not loaded”忘记调用collection.load()建索引后先 load 再 search插入报 “dimension not match”向量维度与 schema 定义不一致核对模型输出维度修改插入向量或重建 CollectionLlamaIndex 创建 Collection 失败同名 Collection 已存在且结构不同设置overwriteTrue或用from_vector_store连接现有集合过滤条件查询返回空过滤器字段名与 Collection 字段名不一致打印 schema 字段列表逐项对比延迟缓慢HNSW 参数设置不当或内存不足优化 ef 值、考虑量化索引、增加资源插入后立刻查询无结果Milvus 异步持久化机制插入后执行flush()再查询upsert 后数据短暂消失upsert 内部为先删后插避免高频 upsert必要时应用层加缓存5.5 优化检索效果的三点实践心得技术链路全通之后真正的分水岭在检索质量调优。分享我最看重的三点第一embedding 模型决定检索效果上限。向量数据库只是把模型输出的向量管理好模型本身的语义理解能力才是底层天花板。对比测试过几种主流模型之后具体项目里我最终选定的模型比当初的默认模型在专业领域文档召回率提升了约三成。选模型这件事值得花时间别急着接下游。第二文档切分粒度需要与内容特点匹配。LlamaIndex 默认按固定 token 数切分遇到结构化技术文档时切得七零八落检索出来经常是残缺片段。我现在对长文档采用层级切分思路标题作为结构化标记内容按语义段落分块块与父章节保持引用关系。效果上比默认切分明显更符合问答场景。第三混合检索比单纯向量检索更稳。向量检索擅长语义相近但精确匹配关键词时反而容易跑偏比如用户问“什么是 HNSW”数据库里明明有这个术语向量检索可能召回一些“图索引”“网络结构”的文档。对这种高频术语类查询加上 BM25 关键词检索再做结果融合RRF 排序比单纯堆一个模型更可靠。LlamaIndex 也有对应的混合检索模式可以先从简单接入开始实验。6. 个人实操笔记这套组合现在还能怎么扩展结合最近一段时间的实践我想补充几个容易被忽略但实际价值很高的扩展点。第一个是数据更新管道的自动化。我现在的做法是数据源侧接入消息队列新增或修改的文档触发一个定时任务任务里完成文本预处理、向量生成、upsert 写入 Milvus。这里有一个经验点不要每次全量重建索引而是给文档维护增量版本号Milvus 的 upsert 配合主键更新能把增量维护成本压得很低。第二个是查询前的问题改写和意图识别。问题改写这部分刚才提过往深做可以结合一个轻量的意图分类器判断用户是提问、找文档还是闲聊然后分流到不同检索路径。这个在上线较复杂的业务场景后几乎成为必选项因为直接把口语化问题拿去做向量检索效果好不到哪去。第三个是监控与质量评估。检索效果不能靠感觉我现在的做法是对运营数据进行离线评估构造一批标准问答对定期跑评估记录召回率、命中率、端到端回答质量评分数值下降就触发告警。这套体系搭好之后至少能确保改动不会引入劣化。第四个值得投入的方向是多模态向量检索。Milvus 不止能存文本向量图像向量、音频向量同样支持。我目前的一个实验项目正在把图表、文档截图也向量化后存入同一个 Collection通过一个对象 ID 统一关联文本块和图片块这样做出的问答系统可以直接输出带图文的答案。Milvus 的向量字段支持不同类型这套扩展路径不需要改架构。从我个人的实操体会来看LlamaIndex 和 Milvus 的组合是一条越用越顺的路。最初觉得是“多引入一个组件增加复杂度”但等数据量涨上来、业务开始要求过滤和性能才发现这层复杂度是必要的。现在遇到新项目我的默认起点就是 LlamaIndex 管理流程、Milvus 承担存储检索两者各司其职。最后再分享一个小技巧开发调试阶段可以在 LlamaIndex 里加一个回调打印每次检索实际命中的文档片段这也是我排查检索质量问题的首选手段。看似不起眼却能帮你在问题变得复杂之前就把它揪出来。这一套链路从 CRUD 到智能检索走下来核心还是那句话检索不是把代码接起来就完事每一个参数的取舍、每一个字段的设计最终都会变成用户体验的一部分。愿你少踩坑多出活。