Milvus向量数据库实战：从部署到RAG集成与C#动态列读取

2026 年了大模型面试里 RAG 相关问题的出场率越来越高而不管是 LangChain、LlamaIndex 还是 Dify底层接得最多的开源向量数据库之一就是 Milvus。这次我们专门把 Milvus 拆开讲2026 最新版有哪些值得关注的新特性本地怎么从零部署怎么跟 Embedding 模型和 RAG 框架串起来以及面试官真正会问的考点到底在哪。这篇文章不是官方文档的翻译而是一套可以直接跟着做完的流程先判断这个工具适不适合你再准备环境、启动服务、建集合、写数据、做检索然后接 LangChain / LlamaIndex / Dify最后用面试题复盘一遍。整个过程用到的命令、代码和排查清单都会贴出来你可以直接复制到自己的测试环境里跑。涉及 Milvus 部署、RAG 项目集成、C# SDK 动态列读取、向量数据库选型这些热搜问题也会一并覆盖。1. 核心能力速览先给一张速览表把你最关心的能力项一次性说清楚。这里不纠结某个具体小版本号重点看当前版本的核心能力。能力项说明项目类型开源分布式向量数据库面向海量向量数据的存储、索引与相似度检索开源情况Milvus 是由 Zilliz 发起并维护的开源项目自 2023 年起已加入 LF AI Data 基金会属于业界应用最广的开源向量数据库之一主要功能向量相似度检索、标量字段过滤、混合查询、分区管理、动态 Schema、多租户、增量数据写入支持的部署模式单机 Standalone、分布式 Cluster、Milvus Lite 本地轻量版推荐硬件普通服务器即可跑通 Standalone生产环境建议内存充足磁盘尽量用 SSD显存占用不强制需要 GPU如果使用 CAGRA 等 GPU 索引则需要 NVIDIA GPU 和对应驱动实际显存占用需按索引大小和参数测试支持平台Linux / macOS / WindowsWindows 建议用 Docker 或 WSL2启动方式Docker Compose、HelmKubernetes、Milvus Litepip 安装、二进制包是否支持 API支持 gRPC、RESTful API并提供 Python、Java、Go、Node.js、C# 等 SDK是否支持批量任务支持批量写入、批量检索RESTful 接口和 SDK 都可以循环调用配合任务队列做批处理适合场景RAG 知识库、大模型应用、以图搜图、商品推荐、去重、多模态检索从上面的表格可以看出Milvus 并不是一个“内存玩具库”它从设计之初就面向分布式和海量数据。如果你的项目只是本地几千条向量Chroma、FAISS 甚至 SQLite 的向量扩展就够了但如果数据量到百万、千万甚至亿级并且对可用性、动态 Schema、混合过滤有要求Milvus 就是更稳的选择。2. 适用场景与使用边界面试的时候最容易踩的坑是把“向量数据库”当成“万能数据库”。Milvus 适用什么、不适用什么要先有边界。2.1 适合解决什么问题第一个典型场景是 RAG。大模型无法覆盖私有知识先把文档切块、做 Embedding 生成向量再写入 Milvus用户提问时把问题向量化在 Milvus 里做近似最近邻搜索把 TopK 结果拼到 Prompt 里让大模型回答。这是目前大模型应用落地最主流的方式Milvus 在这条链路里承担的是“检索底座”。第二个场景是相似度检索。以图搜图、以音搜音、相似文本检测、推荐系统召回阶段都可以把图片、音频、文本映射成向量再交给 Milvus 做召回。第三个场景是元数据过滤与混合查询。只做纯向量检索很多数据库也能做但业务场景往往要求“在某个类别下找最相似的 Top10”这就需要在向量检索的同时叠加标量过滤。Milvus 支持在查询时指定布尔表达式过滤字段比如category news这是它比不少轻量向量库更符合生产需求的原因。2.2 不适合什么场景Milvus 不适合做传统事务型业务。它的核心是向量索引和检索不是行级事务处理。如果你要维护订单、账户、库存这种强一致、强事务的数据应该用关系型数据库。Milvus 也不适合特别小的临时项目。一个几千条向量的 Demo用 Milvus 需要启动 Etcd、MinIO、Milvus 三个组件成本偏高Milvus Lite 可以降低这个门槛但生产级别仍然建议走完整服务。另外向量检索本质上还是“相似度搜索”不是“精确匹配”。如果业务对精确率要求极高比如人脸识别、金融风控中的精确匹配需要在上层再叠加阈值过滤和校验逻辑。2.3 合规与安全边界使用 Milvus 做 RAG 或者多模态检索时Embedding 的源数据往往来自文档、图片、录音等。如果这些数据包含个人信息、商业机密或版权内容必须确认数据来源合法、已获得授权并按企业数据安全规范做脱敏。尤其在 Dify、LlamaIndex 这类框架里接入大模型接口时数据会被发送到模型服务端需要提前确认是否允许敏感数据出域。本地部署 Milvus 不等于数据绝对安全访问控制、网络隔离和日志审计都要跟上。3. 本地部署环境准备Milvus 的新版本安装步骤已经比早期平滑很多但环境上仍然有几个前置点需要先确认。3.1 安装方式选型先确认你想用哪种部署方式方式适用场景依赖Milvus Lite本地开发调试、Demo 验证Python 3.8pip 安装Docker Compose Standalone单机生产或测试环境Docker、Docker ComposeHelm Cluster生产集群、水平扩展Kubernetes 集群二进制包 / 源码编译特殊环境定制编译工具链从社区反馈看绝大多数测试环境和中小型生产环境用 Docker Compose 启动 Standalone 就够了。CentOS 7 上部署也是走 Docker 方式最省事因为 Milvus 依赖 Etcd、MinIO本地二进制方式需要手动管理这些依赖比较容易踩坑。3.2 硬件和系统检查清单如果使用 Docker Compose 启动 Standalone建议先确认以下条件操作系统Linux 最常见CentOS 7、Ubuntu 20.04 以上都有社区案例macOS 可以跑 Docker DesktopWindows 建议 WSL2。内存Standalone 模式至少给 8GB 左右实际取决于数据量和索引类型。磁盘SSD 优先向量索引和原始数据都需要磁盘空间预留数据量的 2 到 3 倍空间比较稳妥。Docker 版本建议使用 Docker 20.10 以上Docker Compose v2。端口Milvus gRPC 默认 19530Etcd 默认 2379MinIO 默认 9000/9001。本机端口被占用时需要先处理冲突。这里先不把端口写死因为新版可能有弹性配置。你可以直接去官方文档拉最新的 docker-compose 文件再根据本机端口情况调整映射。3.3 Python 环境检查后面要做 SDK 测试和 RAG 集成建议准备 Python 3.10 以上环境并用虚拟环境隔离依赖。python3 -m venv venv source venv/bin/activate pip install --upgrade pip4. 安装部署与启动方式下面给出一套通用的 Standalone 部署流程。实际路径、版本号和端口以官方文档为准这里提供的是可复制的操作模板。4.1 拉取 docker-compose 文件Milvus 官方通常会在 GitHub 仓库提供 standalone 和 cluster 两种 compose 文件。部署时先到官方仓库对应分支下载wget https://raw.githubusercontent.com/milvus-io/milvus/master/deployments/docker-compose/standalone/docker-compose.yml如果下载失败可以手动创建一份 docker-compose.yml。通用结构包含三个服务etcd、minio、milvus。注意image标签要写成官方仓库的镜像名和版本不要使用不存在的镜像。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 volumes: - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/etcd:/etcd command: etcd -advertise-client-urlshttp://etcd:2379 -listen-client-urls http://0.0.0.0:2379 --data-dir /etcd 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 milvus: container_name: milvus-standalone image: milvusdb/milvus:latest command: [milvus, run, standalone] ports: - 19530:19530 - 9091:9091 environment: ETCD_ENDPOINTS: etcd:2379 MINIO_ADDRESS: minio:9000这里给出的是通用模板镜像 tag 需要按官方最新版本替换。MinIO 控制台端口 9001 不是必选项生产环境应关闭外部访问。4.2 启动服务在 docker-compose.yml 所在目录执行docker compose up -d启动后检查容器状态docker compose ps如果三个服务都是 Up说明 Milvus Standalone 已经起来了。接下来检查端口是否能通curl -X GET http://127.0.0.1:9091/healthz正常情况会返回健康状态信息。如果返回连接失败先看 docker 日志docker logs milvus-standalone --tail 200从排查经验看最常见的启动失败原因是端口冲突、MinIO 或 Etcd 没有先就绪以及 Docker 版本不兼容。这时候不要反复重启整个堆栈先锁定具体服务日志。4.3 Milvus Lite 快速验证方式如果你不想折腾 Docker只是想先跑通 SDK 逻辑可以用 Milvus Lite。Milvus Lite 是面向本地开发的轻量版本安装后可以直接在 Python 里创建 Collectionpip install pymilvus milvus-lite注意 Milvus Lite 的启动方式在不同版本中有差异建议直接查阅当前官方文档的 Quickstart 章节。它的定位是本地调试不是替代 Standalone 服务。5. 功能测试与效果验证服务启动后下一步就是用 SDK 完成一次完整的“建集合—插数据—建索引—检索”流程。这里以 Python SDK 为例实际操作时请先确认pymilvus版本与 Milvus 服务端匹配。5.1 连接 Milvus 服务from pymilvus import connections, utility connections.connect( aliasdefault, host127.0.0.1, port19530 ) print(Milvus collections:, utility.list_collections())如果输出为空列表说明连接正常还没有创建任何集合。5.2 创建 Collection 并写入数据向量数据库里的 Collection 可以理解为关系型数据库中的表。先定义一个 Schema指定主键字段、向量字段和标量字段。from pymilvus import ( CollectionSchema, FieldSchema, DataType, Collection ) fields [ FieldSchema(nameid, dtypeDataType.INT64, is_primaryTrue, auto_idFalse), FieldSchema(namecategory, dtypeDataType.VARCHAR, max_length100), FieldSchema(namecontent, dtypeDataType.VARCHAR, max_length1000), FieldSchema(nameembedding, dtypeDataType.FLOAT_VECTOR, dim768) ] schema CollectionSchema(fields, descriptionrag_demo_collection) collection Collection(namerag_demo, schemaschema) import random data [ [i for i in range(100)], [random.choice([news, blog, paper]) for _ in range(100)], [fdoc content {i} for i in range(100)], [[random.random() for _ in range(768)] for _ in range(100)] ] collection.insert(data) print(inserted row count:, collection.num_entities)这一步如果成功说明集合创建和写入链路没问题。写入后马上查询num_entities数据不会立即可见需要根据一致性级别等待。这个问题也是面试高频点。5.3 创建向量索引检索前必须创建索引。不同索引类型适合不同场景索引类型特点适用场景IVF_FLAT基于倒排思想精度高内存占用适中千万级以下数据IVF_SQ8对向量做量化压缩内存占用低精度略降数据量大、内存有限HNSW基于图的算法检索速度快但内存占用高对延迟敏感的在线检索DISKANN基于磁盘的索引适合超大数据量亿级向量成本优化SCANN基于压缩的最近邻搜索精度和性能较均衡大规模高维向量CAGRAGPU 加速索引有 NVIDIA GPU 且需要极低延迟索引参数不能凭空给出需要根据实际向量维度、数据量和召回要求做测试。下面是一个 HNSW 索引创建模板from pymilvus import Index index_params { index_type: HNSW, metric_type: COSINE, params: { M: 16, efConstruction: 200 } } collection.create_index( field_nameembedding, index_paramsindex_params )创建成功后加载集合到内存或显存collection.load()注意检索前需要先执行load()这是 Milvus 里很容易忽略的步骤。5.4 向量检索与混合过滤向量检索用search方法。如果业务只需要查询向量相似度不关心标签直接传 query 向量即可如果要求带过滤条件可以在expr中写标量表达式。import random query_vector [[random.random() for _ in range(768)]] results collection.search( dataquery_vector, anns_fieldembedding, param{metric_type: COSINE, params: {ef: 64}}, limit10, exprcategory news, output_fields[id, category, content] ) for hit in results[0]: print(hit.id, hit.score, hit.entity.get(category), hit.entity.get(content))判断检索成功的标准返回结果数等于设置的limit每个结果带有相似度分数expr过滤条件生效返回的 category 都是 news输出字段能正常读取。如果分数异常或者过滤不生效优先检查数据是否已经加载、索引度量方式和 Embedding 模型是否对齐。5.5 C# SDK 获取 $meta 动态列值有的项目用 C# 后端面试题里也有“Milvus C# SDK 如何获取 $meta 动态列的值”这种偏实操的问题。动态字段是 Milvus 2.x 的常见特性允许在 Schema 不预定义的情况下写入额外字段查询时通过$meta读取。C# SDK 不同版本的 API 略有差异先给一个通用处理思路// 以 var result 表示 SearchResult 对象 // 读取动态字段时先判断 Field 是否存在 var metaField result.Fields.FirstOrDefault(f f.FieldName $meta); if (metaField ! null) { var meta metaField.GetValuestring(); Console.WriteLine(meta); }具体类名和方法签名需要匹配你当前使用的 Milvus C# SDK 版本。核心思路是动态字段名保留为$meta返回结果里通过字段名索引来取不要直接强转成预定义类型。6. 大模型 RAG 集成与批量任务Milvus 单独用价值有限接进 RAG 链路才是 2026 年面试和工程项目的重点。这里的集成方式主要有三种LangChain、LlamaIndex、Dify。6.1 Embedding Milvus LlamaIndex 项目实战LlamaIndex 是目前 RAG 项目里很常用的框架它内置了 MilvusVectorStore。pip install llama-index llama-index-vector-stores-milvus pymilvus一个最小可运行的 RAG 检索流程如下from llama_index.core import Document, StorageContext, VectorStoreIndex from llama_index.vector_stores.milvus import MilvusVectorStore vector_store MilvusVectorStore( urihttp://127.0.0.1:19530, collection_namellamaindex_demo, dim768, overwriteTrue ) documents [ Document(textMilvus 是开源向量数据库适合 RAG 场景。), Document(textLlamaIndex 是 RAG 数据框架。) ] storage_context StorageContext.from_defaults(vector_storevector_store) index VectorStoreIndex.from_documents( documents, storage_contextstorage_context ) query_engine index.as_query_engine() response query_engine.query(Milvus 最适合什么场景) print(response)这里有两个坑dim必须和你使用的 Embedding 模型输出维度一致overwriteTrue会重建同名 Collection生产环境不要随意开启。不同 Embedding 模型的维度差异很大常见的有 384、512、768、1024、1536 等选型时要和 Milvus Schema 对齐。6.2 LangChain 集成方式LangChain 的集成也是类似思路通过Milvus类把向量库和检索器串起来。核心流程是加载文档 → 切块 → Embedding → 存入 Milvus → 构建 Retriever。from langchain_community.vectorstores import Milvus from langchain_openai import OpenAIEmbeddings embeddings OpenAIEmbeddings() vector_store Milvus.from_documents( docsdocuments, embeddingembeddings, collection_namelangchain_demo, connection_args{host: 127.0.0.1, port: 19530} ) retriever vector_store.as_retriever(search_kwargs{k: 5})如果你不希望调用在线 Embedding API也可以换成本地 Embedding 模型比如BAAI/bge-base-zh-v1.5这类模型。本地模型的好处是避免数据出域但需要先下载模型文件并确认模型授权范围。6.3 Dify 与批量任务Dify 这类低代码平台通常内置了 Milvus 作为向量数据库选项。在 Dify 里配置 Milvus 时只需要填 Milvus 服务地址、端口、用户名密码如果启用了认证、Collection 名称即可。批量任务方面可以做两层设计写入侧文档切片后分批调用 Embedding 模型再把向量分批写入 Milvus。建议每批 100 到 500 条根据 Embedding 服务吞吐调整。检索侧离线批量生成 query 向量循环调用 Milvus search把结果统一落盘。批量任务最关键的是日志和失败重试。批量写入时如果中间某批失败不要直接重跑全部数据要按批次记录状态只重试失败批次。批量检索时同样要记录每个 query 的耗时和返回条数方便排查超时问题。7. 资源占用与性能观察性能问题在面试里几乎必问实际工程里也是上线前最需要关注的部分。7.1 如何观察资源占用Docker Compose 部署时直接看容器资源docker stats重点关注 milvus-standalone 容器的内存和 CPU。随着 Collection 执行load()内存占用会上升这是把索引加载到内存的正常现象。如果内存持续上涨并且没有回调说明索引段数量过多或者数据分布不均匀。7.2 影响性能的关键因素向量维度维度越高内存占用和计算量越大。768 维和 1536 维的差距非常明显。索引类型HNSW 内存占用高但检索快IVF 类需要调nlist参数DISKANN 适合超大但磁盘 IO 敏感。一致性级别Strong 一致性开销最大Bounded 和 Eventually 性能更好。离线检索引擎可以放宽一致性在线交易场景要谨慎。批量写入大小一次插入太少会导致小段文件过多给后续索引合并带来压力。标量过滤复杂度expr中的过滤字段如果没有合理设计可能让查询性能明显退化。7.3 如何降低资源占用内存不够时先考虑这几条小数据集用 IVF_SQ8 替代 HNSW用精度换内存。控制 Segment 数量减少碎片化。只加载查询需要的字段不要把所有字段都留在内存。用分区和过滤缩小检索范围。对历史数据使用 DiskANN 或冷热分离。实际占用需以本机测试为准不同版本、不同索引参数和不同数据量差异很大。8. 常见问题与排查方法把社区和日常实践里最常碰到的问题整理成一张排查表。问题现象可能原因排查方式解决方案docker compose up 后 Milvus 容器一直重启Etcd 或 MinIO 未就绪看 etcd、minio 日志看 milvus 容器日志等待依赖组件就绪后重启 milvus 服务连接 19530 端口失败服务未启动或端口映射错误docker compose ps、检查端口监听调整端口映射并重启容器Python SDK 连接超时网络不通或连接参数错误Ping 测试、telnet 端口检查 host、port、alias插入数据后搜不到结果数据未落盘或索引未构建完成查看 num_entities、索引状态调用collection.flush()后再查询检索报错“Index not found”没有创建索引或字段名错误查看 Collection 索引列表先执行 create_index 和 load动态字段 $meta 读取为空C# SDK 版本接口不匹配检查返回字段名是否为大写或带斜杠按当前 SDK 版本调整字段索引方式大批量写入很慢单批条数太小或者刷盘太频繁统计写入耗时、查看段数量调大 batch_size减少 flush 调用CPU 内存占用过高索引类型不合适或数据未分区查看索引配置、段分布换低内存索引增加分区策略CentOS 7 上 Docker 启动报错内核版本和 Docker 版本不兼容检查 Docker 和服务日志升级 Docker 版本或检查内核模块8.1 依赖安装失败如果pip install pymilvus失败先确认 Python 版本和 pip 源。国内环境可以临时换镜像源pip install pymilvus -i https://pypi.tuna.tsinghua.edu.cn/simple8.2 数据一致性带来的“刚写入查不到”Milvus 默认的一致性级别可能不是 Strong写入后立即查询不一定能看到最新数据。对在线场景可以在 search 时指定一致性级别或者调用 flush 强制持久化。面试考点解释 Strong、Bounded、Eventually 三种级别的区别以及为什么默认不用 Strong。8.3 向量检索结果质量差结果质量差先检查 Embedding 模型是不是同一个检索时的度量方式是否和索引构建时一致。比如建索引用 COSINE查询时传 EUCLIDEAN结果必然异常。另一个常见原因是文本切片粒度不合理切片太大导致信息混杂切片太小导致上下文缺失。这个属于 RAG 的经典坑。9. 最佳实践与使用建议工程落地时建议把下面这套实践固化成团队规范。第一第一次跑通时不要直接上大数据。先用 100 条数据和最小参数验证链路确认 Schema、索引、检索、过滤、动态字段全部符合预期后再逐步扩大数据量。第二保留一套最小可运行配置。把 docker-compose.yml、初始化脚本、Embedding 模型配置、检索参数模板都放进同一个目录方便新同学复现。第三目录和命名要规范。向量数据、原始文档、Embedding 缓存、检索结果分开存放Collection 命名建议包含业务域和版本信息比如news_embedding_v2。第四批量任务必须加日志和重试。每批写入记录成功条数、失败条数和耗时失败超过阈值要告警不要盲目重试。第五接口服务要限制访问范围。如果 Milvus 对外开放 19530 端口任何能访问该端口的人都可以删 Collection。生产环境建议放到内网或者启用认证并开启 TLS。第六涉及人脸、声音、版权内容时必须确认授权。向量库本身不含语义但存入的向量可以还原出用户的原始内容特征数据脱敏和权限隔离不能省。第七发布前要做效果复核。不要只看 TopK 返回了结果要抽样检查返回内容是否贴合业务问题分数阈值是否合理。10. 面试考点复盘面试题不会直接考“你会不会启动 Milvus”而会考你对底层机制的理解。下面这几个问题几乎覆盖了主流面试方向。10.1 基础概念类为什么需要向量数据库而不是直接用关系型数据库答案核心是关系型数据库的 B 树索引对高维向量相似度搜索支持有限无法高效处理“查找与某个高维向量最接近的 TopK 向量”这种问题。向量数据库通过 ANN 索引HNSW、IVF、DiskANN 等在召回率和检索速度之间做权衡。Collection、Partition、Segment、Shard 分别是什么Collection 对应表Partition 是逻辑分区适合按业务维度隔离数据Segment 是物理存储单元写入数据会生成多个段Shard 是数据分片是分布式扩展的基础。10.2 索引选型类面试官如果问“1 亿条 1024 维向量你会怎么选索引和资源”不要直接说某个索引最好。要按场景拆如果内存充足并且对延迟敏感HNSW 或者 CAGRA有 GPU优先如果内存有限IVF_SQ8 或者 DiskANN 更现实。同时要说明 nlist、efConstruction、ef 这些参数的作用。10.3 与 RAG 结合类RAG 为什么用向量数据库因为大模型不知道私有知识需要先检索相关信息再生成。向量数据库的价值在于把文档切块并向量化后查询时能快速找出语义上最接近的候选片段。为什么需要混合检索纯向量检索对关键词和专有名词容易丢精度。实际项目里经常是“向量召回 关键词召回 重排序”的组合方案。Milvus 支持布尔过滤可以在向量召回前先缩小范围减少不必要的计算。10.4 踩坑类“刚写入的数据为什么搜不到”答案是索引构建和一致性级别的问题。写入后数据先到 Segment索引构建需要时间同时默认一致性可能不是 Strong需要确认具体的可见性级别。“为什么换了 Embedding 模型之后同一个 query 搜索结果差别很大”因为不同模型的向量空间不一致如果 Collection 里有旧模型生成的数据再混入新模型的数据检索质量必然下降。这也是面试官很喜欢追问的点。10.5 选型对比类如果被问 Milvus 和 Chroma、FAISS、Qdrant、pgvector 怎么选可以这样答Chroma 更轻量适合原型验证FAISS 是库不是服务没有内建的分布式和鉴权pgvector 适合想复用 PostgreSQL 基础设施的场景Qdrant 在过滤性能和易用性上做得不错Milvus 适合数据量大、需要分布式、混合过滤和生态集成的场景。没有绝对的“最强”只有“当前业务最合适”。11. 总结与下一步Milvus 最值得尝试的一点是它把一个完整生产级向量检索系统的底座用 Docker Compose 就能拉起来并且有 Python、Java、Go、Node.js、C# 多语言 SDK和 LangChain、LlamaIndex、Dify 的集成案例都很多。2026 年这个节点你不需要在“要不要用向量数据库”上纠结真正要练的是把它接进 RAG 链路并调优的能力。建议你按这个顺序操作先用 Milvus Lite 或 Docker Compose 跑通连接与建集合再用公开的 Embedding 模型把一批文档写进去接着用 LlamaIndex 或 LangChain 实现一个最简单的问答流程最后用 C# 或 Python 验证动态字段和批量检索是否满足你的业务场景。最容易踩的坑集中在版本不匹配、索引类型选错、Embedding 维度不一致这三个地方提前确认这三点能省下大量排查时间。后续可以考虑的方向把 Milvus 的备份恢复、监控告警、多租户隔离、GPU 索引加速和生产级鉴权补上再针对具体场景做召回准确率和检索耗时的对比实验形成一套自己的调参记录。这样无论是做项目还是应对大模型方向的技术面试你手里都有一份能直接讲清楚的数据。