可以平替,而且是更"工程化"的做法,但取决于你要不要这几个能力:
- 你现在(内存索引)优点:实现简单、依赖少、延迟低;缺点是重启就丢、多进程/多实例各算各的。
- pgvector 优点:向量可持久化、多实例共享、可做权限/审计/备份、可用索引(HNSW/IVFFlat)提升检索速度;缺点是多一个数据库依赖、写入/迁移要做、延迟通常略高。
内存方案是最小成本最佳起步;但如果你后面要扩展到很多图表、很多服务实例、或希望重启不重算 embedding,pgvector 很合适。
pgvector 的典型落地形态(怎么替换)
- 表结构(示例):
chart_embeddings(chart_id text primary key, chart_json jsonb, embedding vector(d), updated_at timestamptz) - 写入:启动或检测到
dns.json更新时,重新向量化并upsert - 查询:用户问题 embedding 后,用余弦/内积距离做 TopK
- 常见:
ORDER BY embedding <=> :query_vec LIMIT 3(具体算子随你选择的距离类型)
- 常见:
- 索引:数据量上来后再加 HNSW/IVFFlat(小数据可以先不加)
如果你要我做"pgvector 版",需要确认两点:
- 是否接受"不再是纯内存"(会持久化到 PostgreSQL)
- 你们 PostgreSQL 是否允许装扩展
pgvector(通常需要 DBA 执行CREATE EXTENSION vector;)