Pgvector

选型先看规模，别先看流行度 向量库这两年铺天盖地，但绝大多数团队的真实数据量撑死在几十万到几百万条 chunk——这个量级，杀鸡用牛刀的代价是运维复杂度暴涨。Milvus 这类分布式系统要部署 etcd、MinIO、集群节点，一个人维护都吃力；而你的检索延迟可能只需要 50ms 以内，单机方案完全够。选型第一问永远是：我的向量条数大概多少？QPS 多少？要不要过滤？ 四类方案对号入座 方案 适合规模 优点 代价 Chroma 十万级内、原型验证 pip install 即用，纯嵌入式 不适合高并发生产 pgvector 百万级、已有 PostgreSQL 复用现有库，SQL 联合查询 百万以上 HNSW 调参吃紧 Qdrant 百万到千万、生产混合检索 原生过滤、稀疏向量、Rust 性能 多一个独立服务要运维 Milvus 亿级、大规模分布式 水平扩展成熟 部署重，组件多 一个常被忽略的点：pgvector 的隐性优势是和业务表同库。你的 chunk 带着文档 ID、权限、来源元数据，用 SQL JOIN 直接过滤（比如「只检索当前部门有权看的文档」），比在向量库里单独维护一套 ACL 简单一个数量级。中小团队如果本来就用 PostgreSQL，加个 pgvector 扩展往往是最优解，CREATE EXTENSION vector; 一行搞定。 三个踩坑提醒 第一，HNSW 参数别用默认：ef_construct 和 ef_search 直接决定召回率和延迟的 trade-off，Qdrant、pgvector 都要根据数据量实测，默认值往往偏保守。第二，维度别盲目追高：OpenAI text-embedding-3-small 是 1536 维，bge-m3 是 1024 维，维度越高索引越大、检索越慢，够用就行。第三，量化压缩：Qdrant 支持 scalar 量化和 HNSW on-disk，百万级以上不开量化，内存直接爆——这是很多人「数据一多就 OOM」的根因。 ...