现在给系统加向量检索，默认选项已经从「上个专用向量库」变回「先看看 PostgreSQL 加 pgvector 够不够」。这个转变值得认真对待。
pgvector 能覆盖的范围比想象中大
向量和原始数据在同一个库、同一行里，意味着过滤条件就是普通 SQL——按租户 ID、按时间范围、按状态字段筛选，都是原生能力，不需要额外的元数据同步。
运维层面更关键：pgvector 使用 WAL，所以复制、时间点恢复、备份、连接池、监控全都沿用现有体系，不需要新学一套。
对多数中小规模的检索增强生成场景，这个组合完全够用，而且省掉一整套数据同步的复杂度。
什么时候该换独立引擎
明确的三条判断标准：
第一，向量加索引的规模超过了你能负担的最大主库内存。HNSW 索引希望工作集常驻内存，而且每个副本都要复制一份。
第二，检索和重建索引的负载开始跟在线交易抢资源。同一个缓冲池、同一组 CPU，互相拖累。
第三，需要多字段重度过滤。近似索引上的后过滤要小心处理，专用引擎提供的是过滤感知的图搜索和 payload 索引。
三条都不满足，就先用 pgvector 并持续测量。六百万向量的迁移在后期只是一个批处理作业，前提是应用层只依赖一个足够小的检索接口。
接口隔离是提前埋的伏笔
把检索封装成一个函数或微服务，内部用什么引擎对上层透明。这样今天用 pgvector，明天换 Qdrant 或 Milvus，改动范围可控。
近似检索的几个参数
HNSW 有三个旋钮值得知道：m 是每个节点的连接数，越大召回越好但内存越多，pgvector 和 Qdrant 默认 16；ef_construction 影响建图质量；ef_search 影响查询时的召回与延迟权衡。
调它们的顺序是：先固定一个可接受的召回率目标，再反向找最小的参数组合，而不是一味往上加。
当前版本参考
截至近期，Milvus 2.6.25、Weaviate 1.40.0、Qdrant 持续迭代、Chroma 1.5.9、LanceDB 0.40.0。Weaviate 从 1.40.0 起，命名空间和去重备份需要许可密钥——选商用引擎时把许可变化一起算进成本。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。