pgvector/pgvector¶
这个项目在系统里负责哪一层¶
pgvector 负责的是 RAG 的数据底座。它解决的不是“世界上最强的向量检索”，而是“如果团队本来就在用 Postgres，能不能把向量检索和业务元数据放进同一套数据库里管理”。
这对大量第一版知识库系统非常重要。第一版最缺的通常不是极限性能，而是低复杂度、可维护性，以及权限、版本和引用能不能走在同一条链上。
先抓整体结构¶
读 pgvector 时，先抓四件事：
- 向量类型和距离算子：解决“怎么存、怎么比”。
- 索引策略：解决“速度、召回和资源怎么取平衡”。
- 业务过滤：解决“只在当前用户有权看的范围内检索”。
- 数据生命周期：解决“更新、重建和失效怎么处理”。
真正成熟的 RAG 系统，不会把这四件事分开想。它们一起决定了检索是不是可用。
一条典型执行链¶
如果你用 Postgres + pgvector 做企业知识库，一条链通常这样跑：
- 文档入库，保留文档 ID、版本、租户、权限、标题等元数据。
- 文档切块并生成 embedding。
- chunk 文本、embedding 和元数据一起写进表。
- 查询时先带上租户、版本、权限、文档类型等过滤条件。
- 在过滤后的范围内做向量检索，必要时再结合全文检索或关键词检索。
- 召回结果再交给 rerank、引用装配和最终生成。
这条链最值钱的地方是：过滤条件、版本有效性和相似度排序可以放进同一套 SQL 思路里。对企业场景来说，这比单独追求向量检索跑分重要得多。
值得学的设计¶
pgvector 最值得学的，是它把“向量检索”和“业务过滤”放回了同一个数据系统。很多人一学向量库就容易进入纯算法视角，仿佛只要相似度算得准，系统就会好。企业场景里不是这样。租户、版本、权限、文档类型、时间范围，这些条件和相似度一样重要。
这也是为什么 HNSW、IVFFlat、exact search 不能孤立背。它们不是单独的名词，而是不同的工程取舍。exact search 简单但可能慢，适合规模小或强过滤场景；HNSW 适合追求更稳的近似召回，但索引和资源成本更高；IVFFlat 更依赖参数和数据分布，调优空间更大，也更容易因为数据更新和过滤条件出现波动。
适合借回自己项目的点¶
- 第一版系统优先把文档、chunk、租户、版本、权限和 embedding 放在一套数据模型里。
- 先把数据生命周期设计清楚，再调索引参数。
- 把“过滤条件 + 相似度 + 版本有效性”一起当成检索主链。
- 需要精确术语时，尽早考虑 hybrid search，而不是只押宝纯向量。
不要照抄的地方¶
- 不要一上来就追复杂索引，数据模型和过滤边界没立住时，索引调优收益很有限。
- 不要只会写相似度 SQL，却不会解释版本、权限和生命周期。
- 不要把它讲成“向量魔法”。它首先还是数据库工程和数据建模问题。