跳转至

pgvector: 关系型现实里的语义检索

pgvector 不是要把 PostgreSQL 变成一个“纯向量数据库”，它是要解决如何在不引入额外系统复杂度的前提下，实现带业务约束的语义检索。

1. 工程判断：为什么第一版首选它？

很多团队在项目初期就急于引入独立的向量数据库（如 Milvus, Pinecone），但这往往会陷入数据孤岛与一致性泥潭。

  • 元数据共生：租户 ID、文档权限、版本状态、Chunks 文本与 Embedding 向量存在同一张表里。工程直觉：最稳的过滤不是“先检索再过滤”，而是让数据库 Planner 在同一个查询计划里完成 WHERE tenant_id = 'acme' 与向量余弦相似度计算。
  • 事务一致性：文档更新时，业务记录与向量索引在同一个事务内同步变更。不存在“数据库改了，向量库还没同步”的中间态。

2. 索引机制：HNSW 与 IVFFlat 的取舍

在 pgvector 中，索引不是魔法，是性能与成本的博弈。

  • HNSW (Hierarchical Navigable Small World)：
    • 优势：检索精度高，查询速度快。
    • 代价：内存占用极大，索引构建慢。适合对时延敏感、内存预算充足的场景。
  • IVFFlat (Inverted File Flat)：
    • 优势：内存占用小，索引构建快。
    • 代价：需要先进行聚类（Lists），查询时需扫描多个分片，精度随数据量增长可能下降。

3. 查询计划：让 SQL 认识向量

SELECT doc_id, content
FROM chunks
WHERE tenant_id = 'acme'  -- 强业务约束
ORDER BY embedding <=> $1 -- 向量余弦距离
LIMIT 10;

这段 SQL 的价值在于：向量距离算子（<=>）被拉平到了 SQL 表达式层面。这意味着你可以利用 PostgreSQL 成熟的索引选择、连接（Join）与聚合能力，直接在语义检索之上叠加复杂的业务逻辑。

4. 失效模式与性能陷阱

  • Filter Pushdown 失败：如果业务过滤条件（如 tenant_id）选择性极高，但 Planner 却选择了扫描全量向量索引，性能会发生断崖式下跌。
  • 内存溢出：在大规模数据下，如果 HNSW 索引的大小超过了 shared_buffers，高频回表（Random IO）会拖慢检索。
  • 索引漂移：IVFFlat 索引未能在数据分布发生剧烈变化时重新训练（Re-cluster），导致召回率下降。

5. 排查顺序：从计划到召回

  1. EXPLAIN ANALYZE：看查询计划。是走了 Index Scan 还是 Seq Scan？过滤条件是否在索引前置位？
  2. 核对距离算子：是否使用了正确的算子（L2 距离 <->, 内积 <#>, 余弦距离 <=>）？
  3. 检查索引参数：HNSW 的 m 和 ef_construction 是否设置得当？IVFFlat 的 lists 数量是否合理？
  4. 监测内存指标：索引是否能完全装入内存？磁盘 IOPS 是否因为检索请求而暴涨？

结论： pgvector 是对工程复杂度的极限压缩。它让开发者能以最低的认知成本，将语义检索无缝集成进现有的关系型业务链路中。