← 返回概念解读

Concept Fable精修版

pgvector

pgvector · PostgreSQL vector extension

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

老账房在旧总账上接了一根新算筹

百年票号有一套传了几代的总账。客户、交易、契约、担保和权限都在同一套账柜里,账房们熟悉每条查账路径。新掌柜想给柜台多一项本事:客人一来,能找出过往最相似的几位客人,看他们适合哪些票据。

有人提议另买一座相似柜。那柜子算得快,却要把总账里的资料定期抄过去。第一次,新客户等了两个时辰才进相似柜;第二次,抄写时漏了银钱小数;第三次,守柜规矩和总账规矩不一致,伙计能在相似柜里看到本不该看的记录。

老账房说,另起一柜看着新,其实多了一条抄账河。河上每一座桥都会漏、会慢、会忘记权限。他建议在旧总账里加一副相似算筹:每位客人、每份契约旁多放一串特征珠,查账时仍在总账柜内完成,只是多了一种按相近程度排序的拿法。

第一次试用并不顺。算筹太少时,相似的人找不准;算筹太多时,旧账柜抽屉变沉,伙计翻账变慢。老账房没有拆掉新算筹,而是给常查的账目建木架,给冷门账目慢查,把权限牌仍挂在原柜上。

新算筹接入后,柜台能在同一套账规下问:与这位客人最相近的五位是谁,他们买过什么,是否同属某类风险,哪些记录当前伙计有权查看。账不必搬走,权限也不必另写一遍。

当然,旧总账不是万能。珠串太多会占柜,排序太频繁会拖慢账房,索引木架也要维护。若全城巨量资料都压进来,总账未必扛得住。

掌柜最后明白,新能力长在旧账骨架上,价值不只是省一座柜,更是保住已有的资料、权限和查询习惯。能在熟悉的总账里增加一种相似查找,才是这门改造真正省心的地方。

后来票号接待熟客时,伙计仍能用旧账规查身份、额度和权限,只是在同一柜里多问一句相似的人是谁。新本事没有把老体系撕开,反而借老体系获得了信任。掌柜知道,这种改造适合已有总账深、又不想另开一套规矩的地方。

揭示

这个故事讲的是:pgvector

pgvector 是一个 PostgreSQL 扩展,在关系数据库中直接增加向量存储和相似度搜索能力。它支持多种索引类型(HNSW、IVFFlat)、多种距离度量(L2、内积、余弦距离)和精确/近似搜索。在企业场景中,pgvector 的最大价值是把向量检索和现有业务数据放在同一套事务、权限和查询体系里——你可以用一条 SQL 同时做 JOIN、WHERE 过滤和向量相似度排序,而不需要在专用向量库和业务数据库之间维护同步。适合数据量在百万级以内、团队已经深度使用 PostgreSQL、且需要强一致性和低延迟向量查询的场景。当向量量级超过千万、需要分布式或纯向量工作负载时,应考虑专用向量数据库。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 百年总账:企业已有的 PostgreSQL 数据库,包含交易、权限和报表逻辑
  • 新搜索柜:专用向量数据库,功能强但独立于业务数据库
  • 定时同步桥接:ETL / CDC 同步,引入延迟、一致性和权限问题
  • 丢失小数位:同步中的数据错误,在金融等强一致性场景中不可接受
  • 旧总账里装新算筹:pgvector 作为 PostgreSQL 扩展,向量搜索原生嵌入
  • ORDER BY embedding <-> query_vector:SQL 原生向量相似度排序
  • 行级安全策略:利用 PostgreSQL 已有的 RLS 做向量数据的权限控制
  • 代价是扩展上限:pgvector 受限于 PG 单机扩展模型,适合百万级向量

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

PostgreSQLvector searchSQLembeddingsHNSWIVFFlat