一句话定义
在"重分布式 Milvus"与"关系库 pgvector"之间，Qdrant、Weaviate、Chroma 代表三条中间路线：Qdrant 以过滤与量化见长的 Rust 单二进制、Weaviate 以模块化混合检索见长的 Go 平台、Chroma 以开发者体验见长的 Python 原生嵌入式——三者覆盖了中小规模向量库的大部分选择空间。
为什么重要
真实项目最常落在"百万~千万级、单机到小集群"区间，恰是这三家的主场。它们的设计取舍（语言、部署形态、过滤实现、混合检索定位）是理解"向量库产品差异化"的最佳样本：同样是 HNSW，包装出的产品性格完全不同。
前置知识
kp-018（谱系地图）、kp-008（HNSW 共同内核）、kp-014（过滤策略——Qdrant 的招牌差异点）。
核心概念
- Qdrant：Rust 实现，单二进制部署；filterable HNSW（过滤感知遍历 + 基数估算选执行策略）、标量/乘积/二进制量化全套、原生分布式（raft 元数据 + 分片副本）。
- Weaviate：Go 实现，平台化定位；module 体系（向量器、reranker 可插拔）、GraphQL API、原生混合检索（BM25 + 向量 + alpha 加权）、cross-reference 对象引用。
- Chroma：Python 优先，嵌入式起步（
pip install即用，持久化目录即库），后增 client-server 模式；定位是"开发者 10 分钟上手"的原型与中小规模生产。 - collection / class：三家的数据组织单位（Qdrant collection、Weaviate class、Chroma collection），都支持多租户/命名空间化。
原理与机制
三者共享 HNSW 内核，差异在"向量检索之外"的每一层：
| 维度 | Qdrant | Weaviate | Chroma |
|---|---|---|---|
| 语言/形态 | Rust/单二进制+分布式 | Go/服务端+模块 | Python/嵌入式+服务端 |
| 招牌能力 | 过滤性能、量化全套 | 混合检索、模块生态 | 极低上手成本 |
| 过滤 | filterable HNSW+基数估算 | where 过滤+倒排 | metadata 过滤（较基础） |
| 混合检索 | 稀疏向量+融合 API | 原生 BM25+向量 alpha | 依赖外接或新版本功能 |
| 量化 | SQ/PQ/二进制+rescoring | 有限（压缩选项演进中） | 无（依赖外部） |
| 分布式 | 原生分片副本 | 原生（企业版能力分层） | 单机/轻量服务端为主 |
| 典型规模 | 千万~亿级 | 千万~亿级 | 十万~百万级 |
选型心法：按主导 workload 反推——过滤复杂/低选择率高 → Qdrant（filterable HNSW 是实打实的工程差异，见 kp-014/017）；需要一站式混合检索与 rerank 编排、模型可插拔 → Weaviate；原型验证、Notebook 工作流、小团队无运维 → Chroma。三者都可先单机后扩容，但分布式成熟度与多租户能力上 Qdrant/Weaviate 更接近 Milvus 形态。
公式或模型
本节不适用：产品对比篇；性能数字一律以自建评测（kp-025）为准，本文不引用第三方跑分。
图示
轻 ◄──────────────────────────► 重 (运维复杂度)
Chroma ──────► pgvector ──────► Qdrant/Weaviate ──────► Milvus 分布式
(嵌入式) (关系库) (专用单机→小集群) (云原生全家桶)
│ │ │ │
原型/Notebook 已有PG/事务 中大规模独立部署 十亿级/多租户/强扩展实例或案例
法律文书检索（500 万段、权限过滤苛刻、专名多）：选 Qdrant——低选择率的 org+权限 过滤走 filterable HNSW（kp-017 陷阱 2 的标准出口），BM25 腿用其稀疏向量或外接 ES 后 RRF（kp-016）。
多模态素材平台（图片+文本，想内嵌 CLIP 向量化与 rerank）：选 Weaviate 的 module 生态，少写一整套向量化服务。
高校课程项目/内部小工具（5 万条 FAQ）：Chroma 三行代码起步，一天出 demo；上生产前按 kp-027 决策树复核规模与可用性要求。
直观类比
Qdrant 是"精密瑞士军刀"——单件工具做到极致（过滤/量化），需要自己组装刀架（生态要外接）；Weaviate 是"集成灶"——向量器、rerank、混合检索预装联动，厨房（检索管线）一站式；Chroma 是"便携电煮锅"——宿舍（Notebook）里最快开饭，宴席（大规模生产）另请后厨。
常见误区
- "三家随便选，反正都是 HNSW"——过滤、量化、混合检索的实现深度差异会转化为 3~10 倍的性能/质量差（尤其过滤场景），必须按主导 workload 选。
- "Chroma 不能上生产"——准确说法是"适合中小规模与轻可用性要求的生产"；需要分布式、强过滤时它不是对的工具，而非它"不能"。
- "用厂商跑分做决策"——数据分布、维度、过滤模式不同，跑分不可迁移；唯一有效数字出自 kp-025 的自建评测。
自测题
- 低选择率过滤场景为何优先 Qdrant？
- Weaviate 的 module 体系解决了什么痛点？
- 从 Chroma 原型迁移到生产前，必须补测的三件事？
答：其 filterable HNSW 做了过滤感知遍历与基数估算（按选择率自动选执行策略），正是 kp-017 陷阱 1/2 的系统性解法。
答：把向量化（embedding 调用）、rerank 等环节以可插拔模块内置，省去自建"模型服务+检索编排"的胶水层，混合检索一个 API 完成。
答：目标规模下的 p99/QPS（含并发爬坡）、过滤选择率分桶的召回、备份与高可用方案——对应 kp-025 评测与 kp-029 容量设计。
与其他知识点的关系
kp-018 把三者放回谱系；kp-020 是同区间的关系库对照；本篇结论最终汇入 kp-027 的选型决策树。
延伸阅读
Qdrant / Weaviate / Chroma 官方文档（开源项目）——过滤实现、量化选项与部署形态以官方最新文档为准；本文只固定其设计定位与取舍逻辑。