为知识库智能体选向量数据库时，先看团队现有数据在哪里，以及是否需要把租户、版本、地区等过滤条件与向量相似度一起使用。pgvector 是 PostgreSQL 扩展；Qdrant 是独立的向量搜索服务。两者都能用于 RAG 检索，但接入、更新和运维路径不同。以下比较基于两项目在 2026 年 10 月 1 日可读取的官方文档，未对你的数据集跑性能测试。
比较同一个场景
假设一套内部手册有 tenant_id、version、chunk_text 和向量字段。员工提问时，必须只检索本人租户的现行版本。过滤是归属边界，不能等相似度搜索结束后才随意删结果；应用层仍需从已认证身份生成租户条件，不能直接信任用户输入的租户 ID。
| 维度 | pgvector | Qdrant |
|---|---|---|
| 接入方式 | 在已有 PostgreSQL 中启用 vector 扩展，向量与业务列放在表里；团队能继续用 SQL、事务与既有备份流程。 |
建立独立 collection，将向量和可过滤的 payload 放入 point；应用要管理独立服务、连接及备份。 |
| 过滤 | SQL 的 WHERE tenant_id = ... AND version = ...与向量排序共同构成查询，需检查执行计划和索引。 |
搜索请求可附 payload 条件；官方过滤文档说明可以按 payload 和 point ID 设条件。 |
| 更新 | 可用普通 UPDATE、DELETE或 upsert 更改记录；pgvector 官方项目文档给出这些 SQL 示例。 |
通过 point ID upsert 或更新 payload、向量；Qdrant points 文档提醒：上传已存在 ID 的完整 point 会替换该 point，未提供的向量可能被清空，局部更新应选相应更新操作。 |
怎么做一个可比较的试点
- 用相同的 20 个已脱敏文档片段、相同嵌入模型和相同问题集各建一份索引；把每个片段的租户、版本和原文 ID 一并存入。
- 固定“只查租户 A 当前版”的过滤条件，检查返回片段中是否有租户 B 或旧版；任何越权结果直接判失败。
- 更新一条政策，再删除旧版；比较两边何时返回新内容，以及应用是否能从结果定位到原文。记录部署、备份、监控和恢复步骤，不能只比一条查询的耗时。
已有 PostgreSQL 且检索规模与延迟满足实测要求时，先试 pgvector 能减少新服务；若团队需要专门的向量服务能力并愿意承担独立运维，可试 Qdrant。没有你的数据量、过滤选择性、索引配置和硬件结果，不能断言某一方一定更快或更省钱。上述 20 条只是试点样例数量，不是性能结论；正式选型要用真实规模和权限负例复测。
Ai菜鸟网。发布者：AI小管家，转载请注明出处：https://www.alyyhw.com/29881.html
