最近我让一个本地部署的开源推理大模型把我手头那堆 PostgreSQL 资料从头到尾梳理了一遍重点让它总结“PG 的 AI 生态到底长成什么样了”。结果比预想有用得多——它不光把向量检索、混合检索、数据库内推理这几件事串成了一条线还帮我指出了不少日常运维中容易忽略的细节。所以这篇稿子不打算复述模型输出而是把梳理结论和我的实际落地经验揉在一起重新组织一回。写这篇文章的目标读者是后端开发者、数据工程师以及正在纠结“AI 应用的数据层到底该选专用向量数据库还是继续用 PG”的架构师。我会先从“为什么 PG 能长成 AI 基础设施”讲起再展开生态里的几个核心模块接着给一套可复现的文档问答库搭建流程最后把踩过的坑和排查思路整理成速查表。内容偏实操原理部分尽量用大白话讲透。1. 为什么“AI PG”会成为数据层的新基线1.1 传统关系型数据库在 AI 应用面前的短板想理解 PG 为什么在 AI 应用里重新火起来先得看传统关系型数据库在 AI 需求面前有多尴尬。过去我们写 SQL处理的是精确匹配和聚合统计查一张订单号、算某个月的销售额、联表找出某个用户的所有地址这些都是布尔逻辑能表达的。但 AI 应用的长尾问题根本不长这样。举一个最典型的场景智能问答系统里用户问“哪些文档和‘分布式事务的隔离级别’这句话语义最相关”。这个需求用传统的等值匹配做不到LIKE %隔离级别% 扫全表的效率在千万级数据上根本没法看。更重要的是这里的核心动词不是“包含”而是“相关”——相关本身是一个语义距离问题不是字符串问题它需要把文本映射成向量再去做相似度计算。于是前几年市面上冒出一批专用向量数据库专门解决“Embedding 存储 相似度检索”。方案本身没问题但用起来有一个极其现实的代价业务系统里多了一套独立存储数据要双写双写后又牵扯一致性备份要单独做监控要单独配权限体系各管各的。站在一个运维或者后端负责人的角度这几乎是不可接受的复杂度增长。1.2 PG 的“积木式”扩展机制是杀手锏PostgreSQL 能后来居上的原因说到底是它的扩展机制。它不像某些闭源数据库那样把功能锁死在内核里而是定义了一套足够稳定的扩展 API第三方团队可以把新功能编译成扩展然后用一条 CREATE EXTENSION 命令把能力加载进数据库。这意味着向量索引、全文检索、机器学习推理这些能力都可以像装插件一样长在同一个数据库进程里。对使用者来说最大的好处不是“少装了一套软件”而是事务、权限、备份、恢复这些数据库基本功被直接复用了。在向量表里写入的数据和普通业务表一样进入预写日志WAL一样能按时间点做恢复一样能通过标准的 pg_dump 做逻辑备份。这一点在正经业务场景里权重极高。我自己的体会是除了技术上的复用团队认知层面的复用同样重要。新人上手时不需要理解一套全新的存储系统只需要知道“PG 里有一张表存了 vector 类型”这句话的信息量比“这是向量库你要重新学一套 API”小得多曲线立刻平缓了。1.3 AI 应用对数据层提出的四个实际需求大模型帮我梳理的时候把 AI 应用对数据层的需求归纳成了四类这个框架我觉得很清楚向量存储与相似度检索把文本、图片、音视频等数据编码成向量支持按余弦相似度、内积或欧氏距离做召回。混合检索很多业务场景里语义匹配和字面匹配必须同时生效。比如“iPhone 15 价格”这种 query顾客就是要字面关键词你不能只靠语义。数据库内轻量推理把训练好的模型直接放进数据库执行避免数据在应用和模型之间来回搬运。与业务数据的联合查询这是最容易被忽略的一点。向量检索结果往往需要和用户维度、订单维度、标签维度等结构化数据做过滤和聚合如果不在同一个存储里这一步会变成噩梦。这四个需求缺一不可。只做向量检索你可以选专用库但四个同时要而且还要保证一致性PG 这套“一体化”路线就变得非常有吸引力了。2. 大模型梳理出的生态全景四个核心模块2.1 向量检索从“外挂专用库”到“内置扩展”先讲向量检索这个模块。它的原理其实不神秘每个文本或图片被模型编码成一串浮点数比如 1536 维的数组查询时计算出查询向量的浮点数组然后去库里面找“距离最近”的那些向量。朴素的暴力计算方法在大数据量下不可行因为 100 万条 1536 维向量做全量扫描每次查询都要计算 100 万次内积或余弦。所以业界的主流做法是使用近似最近邻ANN索引算法牺牲一点点召回精度换取数量级的速度提升。目前 PG 生态里最常见的两种索引算法HNSW分层可导航小世界图把向量组织成一张多层图检索时从高层粗筛往底层细筛走。它的特点是查询速度快、召回率稳定在百万级数据下表现很好缺点是索引构建需要的内存较大因为图结构本身要驻留内存才能发挥性能。IVFFlat倒排文件索引先把向量聚类分成若干个桶查询时只扫描离 query 最近的几个桶。构建速度快、内存占用低但召回率受分桶数量影响比较大且数据发生大量更新后索引会退化需要定期重建。还有一个经常被忽略的点是向量压缩。原始浮点向量是 4 字节存储100 万条 1536 维向量光数据就接近 6GB索引开销另算。为了降低内存压力生态里普遍支持乘积量化PQ和标量量化。标量量化的思路比较直觉把每个浮点数从 32 位压缩到 8 位甚至更少换来 3-4 倍的内存下降代价是召回略微受损。实操中我会建议先用全精度浮点跑通流程等数据量涨上来了再考虑量化不要一上来就压缩。2.2 混合检索语义和字面两手都要抓纯向量检索有个经典翻车现场用户搜“Python 3.12 升级指南”系统只按语义召回结果把“Python 3.11 迁移注意事项”也排上来了因为语义上确实接近。但对用户来说版本号 3.12 是硬条件字面匹配必须优先。混合检索就是为解决这类问题出现的。PG 生态的标准姿势是向量字段负责语义召回自带的全文检索tsvector 和倒排索引负责字面召回两者在查询结束后用 RANK 融合算法合并排序。常见的融合策略是加权求和最终得分 α × 向量相似度得分 β × 全文检索得分。α 和 β 不是拍脑袋定的而是需要根据业务场景调。比如 SEO 类场景中关键词的权重就一定要拉高而开放式的社区问答场景则可以让语义权重占主导。2.3 数据库内推理在 SQL 里直接跑模型第三个模块是数据库内推理。这个方向在 PG 生态里一直在稳步推进核心思路是把训练好的模型导出为轻量推理格式放进数据库扩展里然后在 SQL 里像调用普通函数一样调用它。听起来是不是觉得有点黑科技原理上其实不难理解。数据库扩展通过 C 语言绑定加载了推理运行时SQL 执行到特定函数时把输入数据交给运行时拿到输出后再返回给查询。因为推理过程发生在数据库进程内部省去了应用层到模型服务的网络往返延迟能低一个量级。这个能力最实用的场景是“在线预测”。比如风控系统里打分模型直接部署在数据库里写一条 UPDATE 就能给一批订单重新打分。另一个很常见的是直接在库里做 Embedding 生成省掉外部调用接口的网络开销。2.4 周边生态Serverless、迁移与监控大模型梳理时还特意提了一嘴周边生态这点我很认同。再好的内核功能如果没有配套的运维工具在真实环境里都跑不起来。目前 PG 生态里已经有 Serverless 形态的托管服务出现按需扩缩容对 AI 应用这种“日常流量不大、但每次查询可能都很重”的负载非常友好。迁移工具链也在快速成熟从传统数据库迁到 PG以及从专用向量库把存量向量数据迁回来都有工具支撑。监控方面各种 PG 监控插件已经能覆盖到索引膨胀率、锁等待、慢查询等关键指标。这些周边能力单独看不算惊艳但它们补齐了“数据库替代”的最后一块拼图——让团队能够在一个统一平台上完成建表、写入、检索、推理、备份、监控全流程。3. 实操四步搭出一套“文档问答”数据库3.1 规格选型先算清楚数据量和内存搭建之前先把账算清楚。最核心的两个指标是数据规模和向量维度。以文档问答为场景举个例子文档总量100 万条Embedding 维度1536 维这是目前很多常用 Embedding 模型的输出规格单条向量存储大小1536 × 4 字节 6144 字节 ≈ 6KB总数据大小100 万 × 6KB ≈ 6GB这 6GB 只是向量数据本身。如果使用 HNSW 索引索引结构通常还要额外占 1.2 到 1.5 倍的数据内存。也就是说一台 16GB 内存的机器跑这套场景会比较紧张建议起步配置放到 32GB或者先缩向量维度到 768 维或者干脆开启标量量化把内存压到可控范围。这个计算过程不是学术推导我实际碰到过好几次“测试库 5 万条数据跑得飞快一上生产 100 万条直接卡死”的情况根因就是没人提前做内存估算。3.2 建表与写入流程规格定了就可以建表。一个适合文档问答的典型表结构大致长这样CREATE TABLE document_chunks ( id BIGSERIAL PRIMARY KEY, doc_title TEXT NOT NULL, chunk_index INT NOT NULL, chunk_content TEXT NOT NULL, chunk_embedding VECTOR(1536), chunk_tsv TSVECTOR GENERATED ALWAYS AS (to_tsvector(simple, chunk_content)) STORED ); CREATE INDEX idx_document_chunks_embedding ON document_chunks USING hnsw (chunk_embedding vector_cosine_ops); CREATE INDEX idx_document_chunks_tsv ON document_chunks USING GIN (chunk_tsv);几条关键设计说明chunk_content 是切分后的原文块切分策略可以按固定长度切也可以按段落边界切。固定长度建议 512 到 1024 个字符之间太短会丢失上下文太长召回会不精准。chunk_tsv 我用的是 generated column插入文档时由数据库自动生成全文检索向量省了一层应用代码。向量索引我用的是余弦距离算子因为文本语义相似度场景里余弦是大多数 Embedding 模型默认优化过的度量方式。写入时建议用批量插入一次事务插 500 到 1000 条PG 的顺序写性能能发挥得很好。3.3 混合检索的 SQL 写法表建好、数据写进去之后核心就是查询。一个比较完整的混合检索 SQL 长这样WITH semantic AS ( SELECT id, chunk_content, 1 - (chunk_embedding :query_embedding) AS semantic_score FROM document_chunks ORDER BY chunk_embedding :query_embedding LIMIT 50 ), keyword AS ( SELECT id, chunk_content, ts_rank(chunk_tsv, plainto_tsquery(simple, :query_text)) AS keyword_score FROM document_chunks WHERE chunk_tsv plainto_tsquery(simple, :query_text) LIMIT 50 ) SELECT COALESCE(s.id, k.id) AS id, COALESCE(s.chunk_content, k.chunk_content) AS chunk_content, COALESCE(s.semantic_score, 0) * 0.7 COALESCE(k.keyword_score, 0) * 0.3 AS final_score FROM semantic s FULL OUTER JOIN keyword k ON s.id k.id ORDER BY final_score DESC LIMIT 10;这段逻辑拆开看并不复杂先用向量语义召回 50 条再用全文检索召回 50 条然后两个结果集做全外联加权合并排序。权重这里我给了 0.7 和 0.3实际业务里建议用一组手工标注的 query 集做回归测试来定。还有个小技巧如果两个分支都没有命中最终得分会是 0说明这个 query 确实超出了知识库覆盖范围可以直接提示用户“未找到相关内容”体验反而更干净。3.4 调优并行度、内存参数与查询规划器搭建完成之后不要马上宣称“搞定了”必须做两轮调优。第一轮调的是 PG 内存和并行参数。对于向量检索这种计算密集的查询我通常会把 work_mem 从默认的 4MB 提到 64MB 甚至更高否则排序和索引运算很容易落盘。maintenance_work_mem 也要跟着提建索引时它决定排序阶段能吃掉多少内存。第二轮调的是并行度。向量检索的索引查询本身很难并行但混合检索的结构里语义分支和关键词分支天然可以并行。实测下来把 max_parallel_workers_per_gather 从 2 提高到 4混合查询整体延迟能快 30% 左右。具体能提多少取决于 CPU 核数和数据分布不能无脑照抄。最后还要看一眼执行计划确认查询规划器真的走了向量索引和 GIN 索引而不是退化成了顺序扫描。如果发现顺序扫描大概率是 LIMIT 数量太大或者索引统计信息过期跑一次 ANALYZE 通常能解决。4. 排查实录我在落地时踩过的坑4.1 索引碎片化和“假性能”第一次做向量索引时我犯过一个典型的错测试数据是连续插入的线上却是边删边插一段时间后 HNSW 索引膨胀率到了 65%查询延迟翻了几倍。因为 HNSW 图结构里删除的节点会留“墓碑”查询时仍然要遍历这些无效节点。排查过程其实不复杂通过查看索引大小和表大小的比例就能发现异常。解决办法是定期重建向量索引或者在业务允许的时间窗口里做一次 VACUUM FULL。更长效的方案是控制删除频率把物理删除改成逻辑删除用状态位过滤查询性能稳定得多。4.2 维度与距离函数选错另一个非常隐蔽的问题是距离函数和 Embedding 模型的匹配。有些 Embedding 模型输出的向量默认优化的是内积有些优化的是余弦如果你在查询时用了不匹配的距离算子召回质量会整体下降但不会报错。在我的项目里出现过一次诡异的“部分 query 召回很好、部分完全驴唇不对马嘴”的情况排查到最后才发现是建索引时指定了 L2 距离而实际业务语义用的是余弦语义。这个坑光看执行计划看不出问题建议在切换 Embedding 模型后用一组固定 query 做回归测试横向对比不同距离算子下的召回结果。4.3 双写一致性隐患如果你是从专用向量库迁移过来的最大的坑其实是双写期的一致性问题。迁移过程中新数据写入应用会同时写 PG 和旧向量库一旦两边写入顺序不一致就会产生“PG 里有、旧库没有”或者相反的缝隙。我的建议是不要搞双写迁移直接停机一次导出向量文件用批量导入的方式灌进 PG然后在应用层切换数据源。PG 支持事务性导入导入失败可以完整回滚这个特性让迁移窗口比想象中短很多。4.4 常见问题速查表现象可能原因排查思路解决办法查询全部走顺序扫描统计信息过期 / LIMIT 太大执行 EXPLAIN ANALYZE执行 ANALYZE调低 LIMIT索引膨胀严重、查询变慢频繁删除/更新查索引大小与表大小比例定期重建索引或改用逻辑删除同一条 query 结果忽好忽坏临时表数据分布不均对比多次执行计划校准聚类参数或重建索引写入速度极慢每行都生成一次 Embedding查看写入链路耗时分布批量生成向量后再批量入库向量检索结果相似但语义不相关距离算子与模型不匹配用固定 query 回归测试切换为匹配的距离算子5. 生态趋势与选型建议5.1 从“外挂向量库”到“一体化数据平台”大模型把这套生态的演进总结成一句话“外挂专用组件”只是过渡阶段最终形态是数据库本身成为 AI 应用的数据底座。我理解这句话的内涵是数据不要因为 AI 而被迫拆到多个存储里数据在哪里推理和检索就应该在哪里发生。这种趋势带来的连锁反应是架构设计思路的转变。以前做 RAG检索增强生成应用至少要拆成文档存储、向量库、缓存、应用编排四个组件现在在 PG 生态里一张表、一个索引、几条 SQL 就能覆盖前两个环节。架构变简单了出问题的点自然也变少了。5.2 什么时候该选 PG 生态什么时候不该虽然 PG 生态很强但也不是万能的。我自己的判断标准是这样建议选 PG 生态数据量在千万级以内、业务已经重度使用 Postgres、需要 ACID 事务保证、希望把结构化查询和向量检索合并成一站式方案。慎重选 PG 生态纯向量检索场景数据量达到亿级以上、请求模式极其单一、召回排序要求极端苛刻。这类场景下专用向量库的专门优化依然有优势。还有一个折中思路值得提如果你预判未来向量规模可能暴涨可以先在 PG 里跑通业务同时在数据出口做一层抽象一旦规模突破阈值可以只把向量相关查询迁移到专用库业务代码改动最小。这种“先统一、后分流”的路线是我目前见过最稳妥的演进方式。整理到最后我自己的体会是PostgreSQL 这轮 AI 生态的崛起靠的不是某一个杀手级特性而是“扩展机制 事务能力 生态成熟度”三者的乘积。以前我会跟别人说“向量检索还是用专用库吧”现在我反而会先问一句“你的 PG 起来了吗扩展装了吗”如果答案是否定的那也许你错过的不是一个插件而是一整条更省心的数据路线。 
长河君 · 2026/10/19 11:55:06 · 阅读 1.2k PostgreSQL AI生态全景：从向量检索到数据库内推理的落地实践
最近我让一个本地部署的开源推理大模型把我手头那堆 PostgreSQL 资料从头到尾梳理了一遍重点让它总结“PG 的 AI 生态到底长成什么样了”。结果比预想有用得多——它不光把向量检索、混合检索、数据库内推理这几件事串成了一条线还帮我指出了不少日常运维中容易忽略的细节。所以这篇稿子不打算复述模型输出而是把梳理结论和我的实际落地经验揉在一起重新组织一回。写这篇文章的目标读者是后端开发者、数据工程师以及正在纠结“AI 应用的数据层到底该选专用向量数据库还是继续用 PG”的架构师。我会先从“为什么 PG 能长成 AI 基础设施”讲起再展开生态里的几个核心模块接着给一套可复现的文档问答库搭建流程最后把踩过的坑和排查思路整理成速查表。内容偏实操原理部分尽量用大白话讲透。1. 为什么“AI PG”会成为数据层的新基线1.1 传统关系型数据库在 AI 应用面前的短板想理解 PG 为什么在 AI 应用里重新火起来先得看传统关系型数据库在 AI 需求面前有多尴尬。过去我们写 SQL处理的是精确匹配和聚合统计查一张订单号、算某个月的销售额、联表找出某个用户的所有地址这些都是布尔逻辑能表达的。但 AI 应用的长尾问题根本不长这样。举一个最典型的场景智能问答系统里用户问“哪些文档和‘分布式事务的隔离级别’这句话语义最相关”。这个需求用传统的等值匹配做不到LIKE %隔离级别% 扫全表的效率在千万级数据上根本没法看。更重要的是这里的核心动词不是“包含”而是“相关”——相关本身是一个语义距离问题不是字符串问题它需要把文本映射成向量再去做相似度计算。于是前几年市面上冒出一批专用向量数据库专门解决“Embedding 存储 相似度检索”。方案本身没问题但用起来有一个极其现实的代价业务系统里多了一套独立存储数据要双写双写后又牵扯一致性备份要单独做监控要单独配权限体系各管各的。站在一个运维或者后端负责人的角度这几乎是不可接受的复杂度增长。1.2 PG 的“积木式”扩展机制是杀手锏PostgreSQL 能后来居上的原因说到底是它的扩展机制。它不像某些闭源数据库那样把功能锁死在内核里而是定义了一套足够稳定的扩展 API第三方团队可以把新功能编译成扩展然后用一条 CREATE EXTENSION 命令把能力加载进数据库。这意味着向量索引、全文检索、机器学习推理这些能力都可以像装插件一样长在同一个数据库进程里。对使用者来说最大的好处不是“少装了一套软件”而是事务、权限、备份、恢复这些数据库基本功被直接复用了。在向量表里写入的数据和普通业务表一样进入预写日志WAL一样能按时间点做恢复一样能通过标准的 pg_dump 做逻辑备份。这一点在正经业务场景里权重极高。我自己的体会是除了技术上的复用团队认知层面的复用同样重要。新人上手时不需要理解一套全新的存储系统只需要知道“PG 里有一张表存了 vector 类型”这句话的信息量比“这是向量库你要重新学一套 API”小得多曲线立刻平缓了。1.3 AI 应用对数据层提出的四个实际需求大模型帮我梳理的时候把 AI 应用对数据层的需求归纳成了四类这个框架我觉得很清楚向量存储与相似度检索把文本、图片、音视频等数据编码成向量支持按余弦相似度、内积或欧氏距离做召回。混合检索很多业务场景里语义匹配和字面匹配必须同时生效。比如“iPhone 15 价格”这种 query顾客就是要字面关键词你不能只靠语义。数据库内轻量推理把训练好的模型直接放进数据库执行避免数据在应用和模型之间来回搬运。与业务数据的联合查询这是最容易被忽略的一点。向量检索结果往往需要和用户维度、订单维度、标签维度等结构化数据做过滤和聚合如果不在同一个存储里这一步会变成噩梦。这四个需求缺一不可。只做向量检索你可以选专用库但四个同时要而且还要保证一致性PG 这套“一体化”路线就变得非常有吸引力了。2. 大模型梳理出的生态全景四个核心模块2.1 向量检索从“外挂专用库”到“内置扩展”先讲向量检索这个模块。它的原理其实不神秘每个文本或图片被模型编码成一串浮点数比如 1536 维的数组查询时计算出查询向量的浮点数组然后去库里面找“距离最近”的那些向量。朴素的暴力计算方法在大数据量下不可行因为 100 万条 1536 维向量做全量扫描每次查询都要计算 100 万次内积或余弦。所以业界的主流做法是使用近似最近邻ANN索引算法牺牲一点点召回精度换取数量级的速度提升。目前 PG 生态里最常见的两种索引算法HNSW分层可导航小世界图把向量组织成一张多层图检索时从高层粗筛往底层细筛走。它的特点是查询速度快、召回率稳定在百万级数据下表现很好缺点是索引构建需要的内存较大因为图结构本身要驻留内存才能发挥性能。IVFFlat倒排文件索引先把向量聚类分成若干个桶查询时只扫描离 query 最近的几个桶。构建速度快、内存占用低但召回率受分桶数量影响比较大且数据发生大量更新后索引会退化需要定期重建。还有一个经常被忽略的点是向量压缩。原始浮点向量是 4 字节存储100 万条 1536 维向量光数据就接近 6GB索引开销另算。为了降低内存压力生态里普遍支持乘积量化PQ和标量量化。标量量化的思路比较直觉把每个浮点数从 32 位压缩到 8 位甚至更少换来 3-4 倍的内存下降代价是召回略微受损。实操中我会建议先用全精度浮点跑通流程等数据量涨上来了再考虑量化不要一上来就压缩。2.2 混合检索语义和字面两手都要抓纯向量检索有个经典翻车现场用户搜“Python 3.12 升级指南”系统只按语义召回结果把“Python 3.11 迁移注意事项”也排上来了因为语义上确实接近。但对用户来说版本号 3.12 是硬条件字面匹配必须优先。混合检索就是为解决这类问题出现的。PG 生态的标准姿势是向量字段负责语义召回自带的全文检索tsvector 和倒排索引负责字面召回两者在查询结束后用 RANK 融合算法合并排序。常见的融合策略是加权求和最终得分 α × 向量相似度得分 β × 全文检索得分。α 和 β 不是拍脑袋定的而是需要根据业务场景调。比如 SEO 类场景中关键词的权重就一定要拉高而开放式的社区问答场景则可以让语义权重占主导。2.3 数据库内推理在 SQL 里直接跑模型第三个模块是数据库内推理。这个方向在 PG 生态里一直在稳步推进核心思路是把训练好的模型导出为轻量推理格式放进数据库扩展里然后在 SQL 里像调用普通函数一样调用它。听起来是不是觉得有点黑科技原理上其实不难理解。数据库扩展通过 C 语言绑定加载了推理运行时SQL 执行到特定函数时把输入数据交给运行时拿到输出后再返回给查询。因为推理过程发生在数据库进程内部省去了应用层到模型服务的网络往返延迟能低一个量级。这个能力最实用的场景是“在线预测”。比如风控系统里打分模型直接部署在数据库里写一条 UPDATE 就能给一批订单重新打分。另一个很常见的是直接在库里做 Embedding 生成省掉外部调用接口的网络开销。2.4 周边生态Serverless、迁移与监控大模型梳理时还特意提了一嘴周边生态这点我很认同。再好的内核功能如果没有配套的运维工具在真实环境里都跑不起来。目前 PG 生态里已经有 Serverless 形态的托管服务出现按需扩缩容对 AI 应用这种“日常流量不大、但每次查询可能都很重”的负载非常友好。迁移工具链也在快速成熟从传统数据库迁到 PG以及从专用向量库把存量向量数据迁回来都有工具支撑。监控方面各种 PG 监控插件已经能覆盖到索引膨胀率、锁等待、慢查询等关键指标。这些周边能力单独看不算惊艳但它们补齐了“数据库替代”的最后一块拼图——让团队能够在一个统一平台上完成建表、写入、检索、推理、备份、监控全流程。3. 实操四步搭出一套“文档问答”数据库3.1 规格选型先算清楚数据量和内存搭建之前先把账算清楚。最核心的两个指标是数据规模和向量维度。以文档问答为场景举个例子文档总量100 万条Embedding 维度1536 维这是目前很多常用 Embedding 模型的输出规格单条向量存储大小1536 × 4 字节 6144 字节 ≈ 6KB总数据大小100 万 × 6KB ≈ 6GB这 6GB 只是向量数据本身。如果使用 HNSW 索引索引结构通常还要额外占 1.2 到 1.5 倍的数据内存。也就是说一台 16GB 内存的机器跑这套场景会比较紧张建议起步配置放到 32GB或者先缩向量维度到 768 维或者干脆开启标量量化把内存压到可控范围。这个计算过程不是学术推导我实际碰到过好几次“测试库 5 万条数据跑得飞快一上生产 100 万条直接卡死”的情况根因就是没人提前做内存估算。3.2 建表与写入流程规格定了就可以建表。一个适合文档问答的典型表结构大致长这样CREATE TABLE document_chunks ( id BIGSERIAL PRIMARY KEY, doc_title TEXT NOT NULL, chunk_index INT NOT NULL, chunk_content TEXT NOT NULL, chunk_embedding VECTOR(1536), chunk_tsv TSVECTOR GENERATED ALWAYS AS (to_tsvector(simple, chunk_content)) STORED ); CREATE INDEX idx_document_chunks_embedding ON document_chunks USING hnsw (chunk_embedding vector_cosine_ops); CREATE INDEX idx_document_chunks_tsv ON document_chunks USING GIN (chunk_tsv);几条关键设计说明chunk_content 是切分后的原文块切分策略可以按固定长度切也可以按段落边界切。固定长度建议 512 到 1024 个字符之间太短会丢失上下文太长召回会不精准。chunk_tsv 我用的是 generated column插入文档时由数据库自动生成全文检索向量省了一层应用代码。向量索引我用的是余弦距离算子因为文本语义相似度场景里余弦是大多数 Embedding 模型默认优化过的度量方式。写入时建议用批量插入一次事务插 500 到 1000 条PG 的顺序写性能能发挥得很好。3.3 混合检索的 SQL 写法表建好、数据写进去之后核心就是查询。一个比较完整的混合检索 SQL 长这样WITH semantic AS ( SELECT id, chunk_content, 1 - (chunk_embedding :query_embedding) AS semantic_score FROM document_chunks ORDER BY chunk_embedding :query_embedding LIMIT 50 ), keyword AS ( SELECT id, chunk_content, ts_rank(chunk_tsv, plainto_tsquery(simple, :query_text)) AS keyword_score FROM document_chunks WHERE chunk_tsv plainto_tsquery(simple, :query_text) LIMIT 50 ) SELECT COALESCE(s.id, k.id) AS id, COALESCE(s.chunk_content, k.chunk_content) AS chunk_content, COALESCE(s.semantic_score, 0) * 0.7 COALESCE(k.keyword_score, 0) * 0.3 AS final_score FROM semantic s FULL OUTER JOIN keyword k ON s.id k.id ORDER BY final_score DESC LIMIT 10;这段逻辑拆开看并不复杂先用向量语义召回 50 条再用全文检索召回 50 条然后两个结果集做全外联加权合并排序。权重这里我给了 0.7 和 0.3实际业务里建议用一组手工标注的 query 集做回归测试来定。还有个小技巧如果两个分支都没有命中最终得分会是 0说明这个 query 确实超出了知识库覆盖范围可以直接提示用户“未找到相关内容”体验反而更干净。3.4 调优并行度、内存参数与查询规划器搭建完成之后不要马上宣称“搞定了”必须做两轮调优。第一轮调的是 PG 内存和并行参数。对于向量检索这种计算密集的查询我通常会把 work_mem 从默认的 4MB 提到 64MB 甚至更高否则排序和索引运算很容易落盘。maintenance_work_mem 也要跟着提建索引时它决定排序阶段能吃掉多少内存。第二轮调的是并行度。向量检索的索引查询本身很难并行但混合检索的结构里语义分支和关键词分支天然可以并行。实测下来把 max_parallel_workers_per_gather 从 2 提高到 4混合查询整体延迟能快 30% 左右。具体能提多少取决于 CPU 核数和数据分布不能无脑照抄。最后还要看一眼执行计划确认查询规划器真的走了向量索引和 GIN 索引而不是退化成了顺序扫描。如果发现顺序扫描大概率是 LIMIT 数量太大或者索引统计信息过期跑一次 ANALYZE 通常能解决。4. 排查实录我在落地时踩过的坑4.1 索引碎片化和“假性能”第一次做向量索引时我犯过一个典型的错测试数据是连续插入的线上却是边删边插一段时间后 HNSW 索引膨胀率到了 65%查询延迟翻了几倍。因为 HNSW 图结构里删除的节点会留“墓碑”查询时仍然要遍历这些无效节点。排查过程其实不复杂通过查看索引大小和表大小的比例就能发现异常。解决办法是定期重建向量索引或者在业务允许的时间窗口里做一次 VACUUM FULL。更长效的方案是控制删除频率把物理删除改成逻辑删除用状态位过滤查询性能稳定得多。4.2 维度与距离函数选错另一个非常隐蔽的问题是距离函数和 Embedding 模型的匹配。有些 Embedding 模型输出的向量默认优化的是内积有些优化的是余弦如果你在查询时用了不匹配的距离算子召回质量会整体下降但不会报错。在我的项目里出现过一次诡异的“部分 query 召回很好、部分完全驴唇不对马嘴”的情况排查到最后才发现是建索引时指定了 L2 距离而实际业务语义用的是余弦语义。这个坑光看执行计划看不出问题建议在切换 Embedding 模型后用一组固定 query 做回归测试横向对比不同距离算子下的召回结果。4.3 双写一致性隐患如果你是从专用向量库迁移过来的最大的坑其实是双写期的一致性问题。迁移过程中新数据写入应用会同时写 PG 和旧向量库一旦两边写入顺序不一致就会产生“PG 里有、旧库没有”或者相反的缝隙。我的建议是不要搞双写迁移直接停机一次导出向量文件用批量导入的方式灌进 PG然后在应用层切换数据源。PG 支持事务性导入导入失败可以完整回滚这个特性让迁移窗口比想象中短很多。4.4 常见问题速查表现象可能原因排查思路解决办法查询全部走顺序扫描统计信息过期 / LIMIT 太大执行 EXPLAIN ANALYZE执行 ANALYZE调低 LIMIT索引膨胀严重、查询变慢频繁删除/更新查索引大小与表大小比例定期重建索引或改用逻辑删除同一条 query 结果忽好忽坏临时表数据分布不均对比多次执行计划校准聚类参数或重建索引写入速度极慢每行都生成一次 Embedding查看写入链路耗时分布批量生成向量后再批量入库向量检索结果相似但语义不相关距离算子与模型不匹配用固定 query 回归测试切换为匹配的距离算子5. 生态趋势与选型建议5.1 从“外挂向量库”到“一体化数据平台”大模型把这套生态的演进总结成一句话“外挂专用组件”只是过渡阶段最终形态是数据库本身成为 AI 应用的数据底座。我理解这句话的内涵是数据不要因为 AI 而被迫拆到多个存储里数据在哪里推理和检索就应该在哪里发生。这种趋势带来的连锁反应是架构设计思路的转变。以前做 RAG检索增强生成应用至少要拆成文档存储、向量库、缓存、应用编排四个组件现在在 PG 生态里一张表、一个索引、几条 SQL 就能覆盖前两个环节。架构变简单了出问题的点自然也变少了。5.2 什么时候该选 PG 生态什么时候不该虽然 PG 生态很强但也不是万能的。我自己的判断标准是这样建议选 PG 生态数据量在千万级以内、业务已经重度使用 Postgres、需要 ACID 事务保证、希望把结构化查询和向量检索合并成一站式方案。慎重选 PG 生态纯向量检索场景数据量达到亿级以上、请求模式极其单一、召回排序要求极端苛刻。这类场景下专用向量库的专门优化依然有优势。还有一个折中思路值得提如果你预判未来向量规模可能暴涨可以先在 PG 里跑通业务同时在数据出口做一层抽象一旦规模突破阈值可以只把向量相关查询迁移到专用库业务代码改动最小。这种“先统一、后分流”的路线是我目前见过最稳妥的演进方式。整理到最后我自己的体会是PostgreSQL 这轮 AI 生态的崛起靠的不是某一个杀手级特性而是“扩展机制 事务能力 生态成熟度”三者的乘积。以前我会跟别人说“向量检索还是用专用库吧”现在我反而会先问一句“你的 PG 起来了吗扩展装了吗”如果答案是否定的那也许你错过的不是一个插件而是一整条更省心的数据路线。