Qdrant 是开源向量数据库与向量检索引擎，支持向量搜索、payload 过滤、混合检索、分布式部署、托管云、混合云和企业支持，适合构建 RAG、语义搜索、推荐系统和 AI agent 记忆检索层。

Qdrant 工具文档

核心参数与统计

Qdrant 是一款开源向量数据库和向量相似度搜索引擎，主要用于语义搜索、RAG、推荐系统和 AI agent 记忆检索。它的核心价值不是“能存向量”，而是把向量索引、payload 过滤、混合检索、分布式运行和企业部署路线组合成可上线的检索基础设施。

项目	信息
产品名称	Qdrant
官方入口	https://qdrant.tech/
开源仓库	https://github.com/qdrant/qdrant
最新版本	v1.18.2，2026-06-04
主要形态	OSS、自托管、Managed Cloud、Hybrid Cloud、Enterprise
核心场景	RAG、语义搜索、推荐系统、AI agents、图片/多模态检索
公司所在地	Germany / Berlin

对做 AI 检索的团队来说，Qdrant 往往承担召回层角色：上游负责 chunking、embedding 和数据清洗，下游负责 rerank、prompt 组织和回答生成，Qdrant 负责在可过滤、可扩展的索引里快速找回候选内容。

用户与市场认可

Qdrant 的市场认知来自两个方向：一是开源向量数据库的开发者采用，二是面向生产系统的 Cloud、Hybrid Cloud 和 Enterprise 产品线。官网把它放在 vector database、RAG、recommendation systems、advanced search 和 AI agents 等入口下，说明它的定位非常明确。

维度	公开信号	判断
开源采用	GitHub release 活跃，Docker/自托管路径明确	适合开发者和平台团队验证
企业路线	Cloud、Hybrid Cloud、Enterprise	适合合规和网络边界要求更高的组织
场景表达	RAG、推荐、语义搜索、AI agents	聚焦 AI 检索层
品牌资源	官方 brand resources 页面	资产来源明确，便于目录展示

它的用户并不局限于 AI 应用开发者。平台工程团队会关心部署、扩缩容和快照恢复；企业架构团队会关心身份、网络和支持；业务产品团队则关心检索质量能否支撑真实问答和推荐体验。

成本与边界

Qdrant 的成本结构分为开源自托管和云服务两条线。自托管能降低软件采购成本，但需要团队承担运维、升级、备份、监控和网络治理；Cloud/Hybrid Cloud 则把更多运行成本转为服务订阅和资源计费。

层级	费用特征	适合场景
OSS	开源免费	评估、自托管、内部平台集成
Free Tier	官方云服务免费层	原型、测试、轻量数据集
Standard Tier	Usage-based pricing	生产工作负载、弹性扩展
Premium Tier	Minimum spend required	更高安全、合规和支持要求
Enterprise / Hybrid	联系销售	私有网络、混合云、组织级治理

采购时不要只看“每月价格”，还要看集群规模、内存、磁盘、备份、恢复、SLA、网络连接和团队运维能力。向量数据库进入生产后，稳定性和恢复能力往往比初始账单更重要。

主要功能

Qdrant 的核心功能围绕检索质量和生产稳定性展开。

• 向量相似度搜索：用于 embedding 驱动的语义召回。
• Payload 过滤：在检索时结合结构化字段，支持权限、时间、标签和业务条件过滤。
• 混合检索：将语义检索与关键词/稀疏信号组合，提高专有名词和精确条件场景的召回质量。
• 分布式与快照：支持生产环境常见的扩展、迁移和恢复需求。
• Cloud 与 Hybrid Cloud：降低运维负担，同时保留企业需要的部署控制能力。
• 多语言客户端：适合接入不同技术栈的后端服务。

这些能力让 Qdrant 更像一个检索后端，而不是一个孤立数据库。真实业务通常会把它和 embedding 模型、reranker、数据同步器和 LLM 应用框架一起使用。

模型与版本演进

Qdrant 的版本节奏偏工程化。v1.18 系列公开节点集中在 2026 年 5 月到 6 月，重点不是 UI 变化，而是数据库和检索引擎在生产环境中需要的稳定性修复。

版本	日期	变化重点
v1.18.0	2026-05-11	1.18 系列公开发布基线
v1.18.1	2026-05-22	多向量、WAL、resharding、snapshot 相关修复
v1.18.2	2026-06-04	WAL 恢复、payload index、REST auth、snapshot transfer 等修复

对数据库类工具来说，这种版本演进是正向信号。生产用户更关心恢复、索引一致性、快照和认证安全，而不是频繁出现的概念性新功能。

技术优势

Qdrant 的技术优势首先是检索层组合度高。向量搜索与 payload 过滤结合，可以减少应用层二次过滤带来的延迟和召回偏差。对 RAG 来说，这意味着系统可以同时满足“语义相近”和“业务条件正确”。

第二是部署路径清晰。团队可以先用 OSS 和 Docker/Kubernetes 自托管验证，再根据运维能力选择 Cloud 或 Hybrid Cloud。这个路线对成长型团队很友好，因为它不要求一开始就做重采购。

第三是生产边界明确。快照、恢复、分布式、权限、云服务和企业支持都被放在产品路线里，说明 Qdrant 面向的是长期运行的检索基础设施，而不是只跑 notebook demo。

如何使用

典型使用流程是：准备数据，切分文档，生成 embedding，将向量和 payload 写入 Qdrant，再在查询时结合语义向量和过滤条件召回候选内容。

步骤	说明
数据准备	清洗文档、拆分 chunk、设计 metadata
向量化	使用 embedding 模型生成向量
写入集合	创建 collection，写入 vector 和 payload
查询召回	用向量搜索、过滤条件和混合检索找回候选
下游处理	rerank、组装 prompt、交给 LLM 或推荐系统

落地时最容易出问题的不是 Qdrant API，而是 metadata 设计、chunk 粒度和权限过滤。建议在上线前建立检索评测集，持续检查召回质量。

产品定价

Qdrant 的定价采用开源加云服务并行模式。OSS 免费，自托管成本由团队自己的基础设施承担；Cloud 提供 Free、Standard 和 Premium 等层级；企业和混合云通常需要联系销售。

方案	适合对象	关注点
OSS	有运维能力的开发者和平台团队	成本低，维护责任自担
Free Cloud	原型和轻量测试	快速体验，不适合重负载
Standard Cloud	生产检索服务	资源、备份、扩展和 SLA
Premium / Enterprise	高安全和合规组织	私网、支持、组织治理

如果团队已经有成熟的 Kubernetes 和数据库运维能力，自托管可能更省；如果检索层是关键业务而团队运维资源有限，托管云更容易降低长期风险。

应用场景

Qdrant 的典型应用场景都围绕“高质量召回”展开。

• 企业知识库 RAG：为内部文档、工单、规范和产品知识提供语义召回。
• 语义搜索：为站内搜索、文档搜索和研究资料搜索提供向量检索能力。
• 推荐系统：基于内容、用户画像或行为向量召回候选项。
• AI agent 记忆：存储长期记忆、工具结果和任务上下文。
• 多模态检索：通过 embedding 支持图片、文本和其他向量化对象的相似搜索。

如果任务只是少量静态文档查询，也许简单托管检索服务足够；当检索质量、权限过滤和扩展性变重要时，Qdrant 的价值会更明显。

适用人群

Qdrant 适合 AI 应用开发者、后端工程师、数据平台团队、MLOps/LLMOps 团队和企业架构团队。开发者关心 API 简洁和检索质量，平台团队关心部署和恢复，企业团队关心网络、权限和支持边界。

不适合的场景是：没有向量检索需求、数据规模极小、也不打算维护任何检索评测。那时引入向量数据库反而会增加系统复杂度。

总结与展望

Qdrant 的核心竞争力，是把开源向量数据库和生产级云/混合云路线结合起来。它既能让开发者快速验证，也能让企业逐步走向可治理的检索基础设施。

下一阶段值得观察的是混合检索能力、云服务企业化能力、v1.18 后续版本稳定性，以及它在 RAG 与 agent memory 场景中的生态集成深度。

版本信息

• Qdrant v1.18.2 ：官方 GitHub release 最新公开版本，重点修复 WAL 恢复日志、缓存、payload index、REST auth 与 snapshot transfer 等稳定性和安全相关问题。 （2026-06-04）
• Qdrant v1.18.1 ：1.18 系列修复版本，聚焦多向量打分、WAL 校验、resharding 和 snapshot 稳定性。 （2026-05-22）
• Qdrant v1.18.0 ：1.18 系列公开发布基线，为后续 1.18.x 稳定性修复奠定版本基础。 （2026-05-11）