上周公司组织了一场 AI 应用实践分享会，十几个团队轮番上台。做智能客服的讲了 prompt 调优，做知识库的讲了文档切分策略，做代码助手的讲了 rerank 模型的选型，做合同审查的讲了自己搭的多轮对话链路……

**"RAG" 这个词，在三个小时的分享里出现了不下四十次。**

但有一件事很奇怪：**从头到尾，没有一个人提到向量数据库。**

不是没人用，每个做 RAG 的团队都在用。只是它被默认成了一行不起眼的初始化代码：

```python
vectorstore = Chroma(persist_directory="./db", embedding_function=embeddings)
```

写完这行，它就消失了。台上的人聊切片、聊召回、聊大模型幻觉，台下的人记笔记、点头、拍照。**所有人都盯着屋顶的瓦片，没人问地基是钢筋混凝土还是泡沫砖。**
这件事让我后背发凉。因为在真实的工程里，你踩的绝大多数坑，恰恰不出在"上层建筑"，而出在这层被忽略的地基上：
- 知识库刚上线时召回挺准，数据从 3 万条涨到 300 万条，检索开始要等两秒，用户体验直接崩盘；
- 演示环境跑得好好的，一上生产，多两个人并发提问，服务直接 OOM；
- 业务方要求"只搜 2024 年之后的合同、且仅限华东区"，你才发现默认的元数据过滤撑不住复杂条件；
- 安全审计问你要权限日志和操作留痕，你翻遍文档才发现，开源版根本没这功能。

**RAG 的上层是魔术，下层是工程。魔术负责让人惊艳，工程负责让人不翻车。**

所以这篇文章想聊点"不性感但致命"的东西：当你真的要为一个 RAG 系统挑选向量数据库时，Chroma 和 Milvus 到底该怎么选。
![image.png](https://developer.qcloudimg.com/http-save/yehe-2356176/73d3a2791ee033e862809ad9a75a8e6d.png)

## 一、先说结论：这不是"谁更好"，是"你在哪一段路上"

一上来就比参数是最没效率的。两款数据库的根本差异不在性能表里，而在**设计哲学**上

| 维度       | Chroma                  | Milvus                    |
| ---------- | ----------------------- | ------------------------- |
| 一句话定位 | AI 时代的 **SQLite**    | AI 时代的 **分布式数仓**  |
| 核心承诺   | 让开发者 30 秒内跑起来  | 让企业扛住十亿级数据不崩  |
| 架构       | 嵌入式单机              | 云原生分布式微服务        |
| 典型规模   | 10 万级以内             | 千万级 ~ 百亿级           |
| 上手成本   | `pip install`，开箱即用 | 需要 Docker/K8s，要懂运维 |
| 许可证     | Apache 2.0              | Apache 2.0                |

**一句话概括：Chroma 优化的是"第一次运行的爽感"，Milvus 优化的是"第一万次运行的稳定性"。**

这两件事在工程上天然冲突。所有让你快速上手的设计（进程内嵌、本地文件、单节点、默认参数），到规模化时都会变成负债。理解了这一点，后面所有的参数对比你都能自己推出来。

## 二、架构：一个是背包，一个是物流网络

这是最该看懂、也最容易被跳过的一节。

### 2.1 Chroma：把数据库塞进你的进程里

Chroma 的架构极简：底层用 SQLite 做持久化，数据和计算都在单个节点上完成，**没有服务器进程，没有分布式 ，没有网络调用**。

它的好处是革命性的，作为第一个能靠 `pip install` 装好的数据库，它把向量检索从"运维任务"降维成了"一行 import"。你写个脚本、跑个 notebook、做个 demo，全程不需要知道什么叫索引构建、什么叫分片。

但代价同样直接：**所有美好的简化，都在暗中标注了天花板。**

- 无法分布式部署 → 计算能力锁死在单机硬件上；
- 数据与进程同生共死 → 内存占用会挤压你的应用本身；
- 数据量过百万 → 性能断崖式下跌，且**没有平滑升级路径，只能换库重来**。

![image.png](https://developer.qcloudimg.com/http-save/yehe-2356176/7072fa94303e567443e268c50fb4f8b4.png)

### 2.2 Milvus：把数据库拆成一堆各司其职的微服务

Milvus 走的是完全相反的路子。存算分离的云原生架构，整个系统被拆成四层：

- **协调层（大脑）**：Rootcoord 管元数据、Datacoord 管数据、Querycoord 管查询调度；
- **接入层（门面）**：一组无状态 Proxy，负责连接、校验和结果归并；
- **执行层（四肢）**：DataNode 管落盘、QueryNode 管查询、IndexNode 管索引构建；
- **存储层（骨骼）**：元数据存储 + 消息存储 + 对象存储，负责持久化。

这四层可以各自独立扩缩容。查询压力大？加 QueryNode。数据量涨了？加 DataNode 和存储。理论上可以从单机一路扩到数百节点。

代价是：**你需要一个懂它的人**。生产环境部署涉及协调服务、存储组件、计算节点的配置，学习曲线和运维成本都很实在。

> Milvus 自己也知道这个问题，所以提供了三档形态：Milvus Lite（本地开发）、Standalone（测试环境）、Distributed（生产环境）。这其实是一种"渐进式复杂度"的设计——你不需要一开始就为分布式买单。
> 
## 三、性能：差距不在"快不快"，在"崩不崩"

### 3.1 三条关键曲线

性能对比最容易写成数字堆砌。真正该关注的是**三条曲线随规模变化的形状**：

- **延迟曲线**：百万向量规模下，调优后的 Milvus 查询延迟可稳定在 10ms 以内；Chroma 在同等规模下可能超过 100ms。注意：**差距不是 10 倍那么简单，它是"可用"与"不可用"的分界线**。10ms 用户无感，100ms 已经能感知卡顿。
- **并发曲线**：这是最致命的一条。Milvus 在分布式环境下吞吐量近似线性扩展；Chroma 在高并发下是**断崖式下跌**，某一点之前岁月静好，某一点之后直接雪崩。
- **召回曲线**：Milvus 支持 HNSW、IVF、DiskANN、量化等多种索引，允许你在召回率、延迟、资源消耗之间做取舍；Chroma 默认 HNSW，索引选项有限，优化空间基本被锁死。

### 3.2 一个反直觉的点

**在 10 万条数据以内，Chroma 的响应速度往往不输 Milvus，甚至更快。**

因为没有网络开销、没有序列化、没有跨节点协调，进程内调用就是最快的。这也是为什么"我们测试的时候挺快的啊"这句话，会成为后期事故的墓志铭。

**小规模下的性能优势，是最危险的伪信号。**

![image.png](https://developer.qcloudimg.com/http-save/yehe-2356176/00771bb455676d67910aed66b2edb3e9.png)
## 四、功能与生态：企业级需求的照妖镜

当项目从"能用"走向"能交付"，你会撞上一堆之前根本不会考虑的需求。这张表建议收藏：

| 能力项      | Milvus                                     | Chroma                                |
| ----------- | ------------------------------------------ | ------------------------------------- |
| 索引类型    | HNSW / IVF / DiskANN / 量化 / 二进制，丰富 | 默认 HNSW，选项有限                   |
| 混合查询    | 向量 + 关键词 + 元数据 + 重排              | 向量 + 简单元数据过滤                 |
| 过滤复杂度  | 范围查询、布尔组合                         | 简单条件                              |
| 高频更新    | 支持频繁增删，无需重建索引                 | 大规模更新性能差                      |
| 安全合规    | RBAC、审计日志                             | 基础安全，缺企业级特性                |
| 容灾        | 主备集群，RPO=0、RTO<30s                   | 无分布式架构，能力有限                |
| 多语言 SDK  | Python / Java / Go / C++ / Node.js / Ruby  | 主要 Python + JS/TS                   |
| AI 框架集成 | PyTorch、TensorFlow 等                     | **与 LangChain、LlamaIndex 深度集成** |

生态侧，Milvus 有 46k+ Stars、4000+ 贡献者、完善的工具链（VectorDBBench 基准测试、Attu 管理工具、迁移工具）；Chroma 有 29k+ Stars，社区规模相对小，但文档简洁、与 AI 工具链的贴合度更高。

**这是 Chroma 真正的护城河**。如果你整个技术栈就是 LangChain + 本地脚本，Chroma 的集成体验确实更丝滑。生态的"适配度"有时比"丰富度"更重要。
## 五、选型：一个能直接用的决策路径
讲了这么多，落到实操，就五个问题。按顺序问自己：

**① 数据规模会超过 100 万向量吗？**  
是 → Milvus。否 → 继续。  
（这里问的是"会"，不是"现在有"。按 12 个月后的预期算。）

**② 需要企业级高可用保障吗？**  
需要 RPO=0、RTO<30s、审计日志、RBAC → Milvus 或 Zilliz Cloud。否 → 继续。

**③ 需要复杂的元数据过滤或混合查询吗？**  
要"时间范围 + 部门 + 权限标签"这类组合条件 → Milvus。否 → 继续。

**④ 团队有专业数据库运维能力吗？**  
有 → Milvus 可自建。没有 → Chroma，或者直接上 Zilliz Cloud 用全托管换掉运维负担。

**⑤ 是快速原型 / 深度用 LangChain 吗？**  
是 → Chroma。否 → 看看 Qdrant、PGVector、Weaviate。

![image.png](https://developer.qcloudimg.com/http-save/yehe-2356176/fdd7f082f33dcbff0166d4beae0e6138.png)

### 补充几条场景化建议

- **百万级以下** → Chroma，简单直接，别过度设计；
- **千万到亿级** → Milvus（资源紧张时先用 Milvus Lite 顶着）；
- **十亿级以上** → Milvus，没有第二个选项；
- **高并发实时查询**（电商推荐、实时视频分析）→ Milvus 必选；
- **向量 + 关系混合查询** → 考虑 PGVector，别硬上专用库；
- **强事务一致性**（ACID）→ 传统关系库的向量扩展，如金仓数据库。

## 六、两条被大多数人忽略的选型原则

### 原则一：用"混合策略"，而不是"一次押注"

这是我最推荐的做法：

> **早期用 Chroma 跑通业务闭环 → 数据规模和并发上来后，迁移到 Milvus / Zilliz Cloud。**

理由很实在：项目早期最大的风险是"做不出东西"，不是"撑不住流量"。为了一个还没验证的需求提前背上分布式运维的债，是典型的过度设计。

但**前提是你要从第一天就把数据访问层做抽象**。别让 `chroma_client.query()` 散落在业务代码的各个角落，否则迁移时的成本会让你放弃迁移，然后在某个深夜被流量打穿。

**抽象层，是你为未来的迁移提前买的一份保险。**

### 原则二：别信宣传，用真实数据跑一遍

无论选谁，上线前必须做四件事：

1. **真实业务数据测试**：用跟线上分布一致的数据集，别用随机生成的假向量；
2. **多维度评估**：不只看延迟，还要看召回率、吞吐量、带过滤条件的性能；
3. **扩展性验证**：模拟数据量 ×3、×10，看曲线是平缓还是陡峭；
4. **故障恢复测试**：手动杀掉一个节点，看系统多久恢复、丢不丢数据。

VectorDBBench 这类基准测试工具值得一用。**厂商的参数表会美化，你自己的压测数据不会撒谎。**
## 七、结语
在 AI 应用这条链路上，大模型最耀眼，prompt 最出活，切片策略最容易被讨论，而向量数据库最容易被"默认"。但恰恰是它，决定了你的系统在数据翻十倍、并发翻十倍之后，是优雅地扩展，还是狼狈地重构。**尤其是作为资深架构师等技术决策者，一定不要让“默认”迷了眼！**

**选型的本质，从来不是选最先进的技术，而是选"你当前阶段负担得起的复杂度"。**

Chroma 让你今天能跑起来，Milvus 让你明年还能跑得动。这两个价值都对，只是属于不同的时间点。所以下次你在分享 RAG 的时候，也花 30 秒，讲讲你脚底下那层地基吧。


上周公司组织了一场 AI 应用实践分享会，十几个团队轮番上台。做智能客服的讲了 prompt 调优，做知识库的讲了文档切分策略，做代码助手的讲了 rerank 模型的选型，做合同审查的讲了自己搭的多轮对话链路……

都在讲 RAG，没有一个人提它：你的 AI 应用，正站在一条看不见的地基上

分享会上，RAG 被提四十余次，向量数据库却无人问津，它早已默认成代码里最不起眼的一行。本文从这一盲区切入：Chroma 与 Milvus 的差异不在参数，前者是 AI 时代的 SQLite，优化"第一次运行的爽感"；后者是分布式数仓，优化"第一万次运行的稳定性"。沿架构取舍推演至五问决策路径，点破最危险的陷阱。

新能源数字化技术负责人

人工智能

AI应用实践中，RAG系统频繁被提及，但作为地基的向量数据库常被忽略。本文深入对比Chroma与Milvus的架构、性能及选型路径，揭示数据规模与并发场景下的关键差异，提供务实决策框架，助你避免从快速原型到生产环境的致命坑。

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

都在讲 RAG，没有一个人提它：你的 AI 应用，正站在一条看不见的地基上-腾讯云开发者社区-腾讯云

都在讲 RAG，没有一个人提它：你的 AI 应用，正站在一条看不见的地基上

都在讲 RAG，没有一个人提它：你的 AI 应用，正站在一条看不见的地基上

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐