Qdrant 基础

Qdrant 这类向量库解决的，不是“把所有数据都存进去”，而是“怎样按语义把合适片段召回出来”。它在 RAG 里很重要，但它不是数据库总管，更不是业务真相来源。

理解 Qdrant，重点不是背概念，而是知道它为什么只该负责语义检索这一层。

先记住三个核心对象

多数时候，你只要先分清这三样：

• Collection：一组向量数据的集合。
• Point：一条带有向量和元数据的记录。
• Payload：让结果能过滤、能展示、能追溯的附加字段。

真正决定“能不能上线”的，往往不是向量本身，而是 payload 存得全不全。

为什么 payload 这么关键

如果没有 payload，向量库只知道“像不像”；有了 payload，系统才知道“这条结果能不能用”。常见字段通常包括：

• 文档或切片 ID
• 标题路径
• 来源链接
• 权限范围
• 版本状态

没有这些字段，后面引用展示、权限过滤和排查都会很痛苦。

它和 PostgreSQL 的边界

Qdrant 在这里更像检索基础设施，不该替代 PostgreSQL 这类业务数据库。简单说：

• PostgreSQL 负责业务主数据和事务事实。
• Qdrant 负责相似度召回和过滤查询。

把这两个角色混在一起，后面通常两边都做不好。

一句话先记住

Qdrant 的价值，不在于“存向量”，而在于让语义召回结果真正可过滤、可引用、可落地。

继续阅读

• 04-rag/006-vector-database.md
• 05-retrieval/007-rag-retrieval-stack-selection.md