在本地或内网搭建RAG检索服务时，向量数据库的选型与部署往往是第一个卡点。本文从工程落地角度，对比Milvus、Qdrant、Chroma三种常见方案，并给出从文本切分到相似度检索的完整链路实现思路。

说明：本文涉及的具体组件、端口与索引参数以对应版本官方文档为准，以下内容为通用工程实践参考，并非版本确定事实。

一、选型对比：部署复杂度、资源占用与接口

Milvus 定位分布式向量数据库，支持多种索引类型（IVF、HNSW、DiskANN等），适合数据量较大、需要水平扩展的场景。本地部署通常依赖etcd、MinIO、Pulsar等组件，容器化编排复杂度较高，资源占用也相对可观。若只是单机验证，可使用Milvus Lite或Standalone模式降低依赖。

Qdrant 以Rust实现，单二进制即可运行，官方提供Docker镜像，部署门槛低。它原生支持payload过滤与混合检索，REST与gRPC接口并存，适合中小规模、需要元数据过滤的RAG场景。资源占用介于Milvus与Chroma之间。

Chroma 主打轻量与嵌入式，可作为Python库直接运行，也支持客户端-服务端模式。适合原型验证和小规模数据，持久化依赖本地文件或SQLite。当数据量增长到百万级向量时，检索性能与并发能力会成为瓶颈。

选型建议：原型阶段用Chroma快速验证；内网中小规模生产用Qdrant；数据量大且需要分布式扩展时再考虑Milvus。

二、容器化部署要点

以Qdrant为例，Docker启动命令通常为映射6333（REST）与6334（gRPC）端口，并挂载存储卷以持久化数据。Milvus Standalone可通过官方docker-compose文件一键拉起，需注意etcd与MinIO的端口冲突。Chroma服务端模式同样支持Docker，但生产环境建议显式配置持久化路径，避免容器重启后数据丢失。

部署后应验证健康检查接口，确认集合创建、写入与检索的基本通路。

三、RAG检索链路工程流程

1. 文本切分
按语义或固定长度切分文档，控制chunk大小与重叠窗口。切分粒度过大导致检索噪声，过小则丢失上下文。

2. 嵌入生成
选择嵌入模型后，必须记录其输出维度。例如某模型输出768维（此处仅为示例，实际以所选嵌入模型输出维度为准），则向量库集合的维度必须一致。维度不匹配是写入失败的最常见原因。

3. 批量写入
将chunk文本、向量、元数据（来源、页码等）一并写入。批量大小需权衡内存与吞吐，过大易触发超时。

4. 相似度检索
查询时先用同一嵌入模型生成查询向量，再执行top-k检索。可结合元数据过滤缩小范围，提升相关度。

四、常见配置问题与排查

  • 嵌入模型与向量维度不匹配：创建集合时指定的维度必须与嵌入输出一致，否则写入报错。
  • 索引构建失败：检查索引类型与参数是否匹配数据规模，HNSW的M、efConstruction等参数需按内存与召回率权衡。
  • 检索结果相关度差：排查切分策略、嵌入模型是否适合中文、是否归一化向量、距离度量（余弦/内积/L2）是否与模型训练目标一致。

五、工程取舍

本地搭建时，优先保证链路可跑通，再逐步调优索引与参数。不要过早引入分布式组件；元数据过滤需求强时优先选Qdrant；若团队已有Milvus运维经验，可沿用其生态。检索质量最终取决于切分、嵌入与检索参数的联合调优，而非单一数据库选型。