Qdrant 评测：开源向量数据库的生产力与边界

Qdrant 解决的是“生成 embedding 之后怎么处理”的问题。应用先用模型把文本、图片或用户行为变成高维向量，然后需要把这些向量存储起来，并找到与某个查询向量最接近的邻居。实际业务往往还要带条件过滤，比如“在某个分类下、价格低于 50 美元的商品里找最相似的 10 个”。传统数据库很难高效完成这类 nearest neighbor 搜索，因为这不是普通 SQL 能优化好的。Qdrant 把向量检索和 payload 过滤放在同一个引擎中，并提供 REST 和 gRPC API，让团队不必在原型验证之后重建系统。

当 AI 应用从演示走向生产时，团队最需要的是能把 embedding 向量存下来、查得快的基础设施。Qdrant 是少数明确把自己定位为“生产就绪”的向量数据库，而且源码在 GitHub 上公开，采用宽松的 Apache 2.0 许可。这意味着团队可以在不依赖单一云厂商的前提下，自建一套可控的向量检索服务。对很多企业来说，这一点比所谓“顶尖的向量检索性能”更有实际价值。

Qdrant 使用 Apache License 2.0，通常适合商业产品、内部系统和托管服务场景。需要保留许可证与版权声明，并按实际版本复核依赖。README 提到 Qdrant Cloud，但托管云不是使用开源版本的前提。真正容易被忽略的是部署责任：自托管意味着团队要自己处理认证、网络隔离、备份、监控和升级。

非技术人员可以把 Qdrant 理解成一个专门为 AI 生成的“内容指纹”设计的检索引擎。它不找完全相同的文本或图片，而是找“相似”的东西。比如电商网站给每张商品图生成一个向量指纹，用户上传照片时，系统就能在 Qdrant 中找到最相似的商品。你不需要懂向量数学，但必须记住一个关键点：Qdrant 本身不生成指纹。它只负责存和查。真正把内容变成向量的是另外的机器学习模型。所以在做技术选型时，非技术决策者最需要问的是：团队有没有能力运维自己的数据库服务器，还是应该直接用托管云服务。

想快速跑通 Qdrant，最直接的方式是 Docker。项目文档中推荐的一条命令是 `docker run -p 6333:6333 qdrant/qdrant`，启动后就有了一个本地 REST API 和 Web UI。你不需要 GPU，也不需要下载任何模型。下一步是安装官方客户端库，Python、Go、Rust、JavaScript、.NET、Java 等都提供了 SDK。在代码中创建 collection 时，vector size 必须和你的 embedding 模型输出维度一致。然后把向量连同 payload（如商品 ID、分类）一起写入。查询时发送一个 query vector，Qdrant 会返回最近的邻居。生产环境推荐增加反向代理和 TLS，启用认证，并配置持久化存储。数据量很大时，要在初期就规划好 sharding 和 replication，而不是等出问题再迁移。另外，因为 Qdrant 不生成 embedding，你需要单独搭建编码服务，并把整个数据流设计清楚。

Qdrant 的能力边界不是“性能天花板”，而是“范围天花板”。它不做模型训练，也不生成 embedding；它不理解文本或图像的语义，只比较数字向量。因此，凡是需要端到端 AI 推理的场景，Qdrant 都无法独自完成。在性能侧，Qdrant 设计上支持横向扩展、分片和复制，也提供向量量化、磁盘存储和 GPU 加速索引。实际能达到什么样的延迟和吞吐，取决于距离度量、HNSW 参数、内存容量和 payload 过滤的复杂度。如果应用需要关键词搜索与向量搜索结合，Qdrant 支持稀疏向量和混合搜索，但它仍然不是一个通用文档数据库。你大概率需要把它和另一个数据存储配合使用。

### Qdrant 本质上是什么

Qdrant 是一个向量数据库，不是模型框架。应用先用 embedding 模型把文本、图片或用户行为转成向量，Qdrant 负责存储这些向量、附带业务 payload，并在查询时找出相似项。它真正有用的地方不是“向量搜索”四个字，而是把相似性搜索、结构化过滤、持久化和服务 API 放在同一个产品里。

### 证据边界

本文依据仓库 README、许可证和 GitHub 元数据做判断，不引用独立性能数字。README 展示了 REST/gRPC、Web UI、客户端库、GPU 索引、分片、复制、量化、磁盘存储和托管云等能力，这些说明它面向生产服务，而不是单机实验库。但具体延迟、吞吐和成本仍取决于你的向量维度、距离度量、HNSW 参数、过滤条件和硬件。

### 采用前需要做的事

第一，确定 embedding 模型，因为 Qdrant 不负责生成向量。第二，创建 collection 前确定向量维度，后续更换模型通常意味着重新索引。第三，用真实查询测试 payload 过滤，比如分类、价格、地理位置和权限字段。第四，生产环境启用认证、TLS、持久化、备份和监控。第五，提前决定自建还是托管云，不要等数据量上来后才补运维设计。

### 谁不适合用 Qdrant

如果团队只是想在应用内做很小的本地相似搜索，嵌入式库或 pgvector 可能更简单。如果团队已经把所有数据都放在 PostgreSQL，并且向量规模不大，pgvector 能减少系统数量。如果你需要完整的文档数据库、搜索引擎或模型训练平台，Qdrant 也不是替代品。它应该作为 AI 数据栈的一环，而不是“一套工具解决所有问题”。

### 同类项目怎么选

Milvus 更偏大规模分布式向量数据库，适合数据量和集群复杂度更高的团队；Weaviate 把对象存储、schema、向量检索和模块生态放在一起，适合想要更完整数据层的团队；Chroma 对原型和本地 RAG 很友好，但生产治理能力需要谨慎评估；pgvector 适合 PostgreSQL 用户，优点是少引入一个数据库，限制是大规模专用向量检索能力不如独立系统。

### 可执行的采用清单

1. 选择 embedding 模型并记录向量维度。 2. 用 Docker 或托管云创建测试实例。 3. 写入真实业务样本，而不是只用玩具数据。 4. 同时测试相似搜索和 payload 过滤。 5. 对比 Qdrant、Milvus、Weaviate、Chroma、pgvector 的部署和维护成本。 6. 上线前配置认证、TLS、备份、监控和容量告警。

### 结论

Qdrant 适合需要自建语义检索服务、又不想把向量检索绑死在单一云厂商上的团队。它的强项是工程化边界清楚：存向量、查相似、带过滤、可扩展。它的弱点也清楚：不生成 embedding，不训练模型，也不会替你完成数据治理。用它之前，先确认团队是否愿意承担数据库运维责任。