我最早听说“PostgreSQL AI”这个组合时，心里想的是：一个关系型数据库怎么跟 AI 搭上边？后来在几个项目里把向量检索、嵌入存储、RAG 工作流跑通，才慢慢明白，数据库在 AI 时代不是配角。它承担记忆、过滤、事务和实时反馈，模型负责推理和生成。这个分工让 PostgreSQL AI 变成一条很实际的落地路线。
从团队协作角度看，AI 应用要求数据层同时处理结构化条件、语义相似度和权限控制。过去做推荐系统，我可能先上专用向量库，再补一个 MySQL 存业务数据。两套系统之间的同步、一致性、运维成本，折腾得人够呛。PostgreSQL AI 的吸引力就在这里：一套数据库，多种能力。
1.1 AI 时代对数据库能力的新需求
我参与过一个企业知识库项目。文档上传后要切分、生成嵌入、存元数据、做权限过滤、支持语义搜索。早期架构里，向量放进专用库，原文和权限放进 PostgreSQL。查询时需要两边请求，再合并结果。延迟高，数据更新也容易不同步。那时我就想，如果数据库能直接处理向量和关系数据，该省多少事。
另一个角度来自运维同事。他关心的是备份、监控、高可用、扩容。每多一种数据库，就多一套备份策略和告警规则。AI 时代的数据需求变得更快、更杂、更实时。数据库需要支持向量类型、相似度计算、索引加速、事务写入、SQL 查询、权限体系。单独拼装组件能跑通 Demo，生产环境却会被一致性和运维复杂度拖住。
业务方看到的又是另一层。他们希望搜索能理解语义，推荐能结合用户画像，问答能引用最新文档。数据库得在毫秒级返回候选集，还得保证数据新鲜。PostgreSQL AI 的价值不是取代模型，而是让数据层足够灵活，接得住这些需求。
1.2 PostgreSQL 支持 AI 的核心优势：扩展、SQL、事务与生态
我最初用 PostgreSQL，看中的是它的扩展机制。CREATE EXTENSION 像给数据库装插件，pgvector、PostGIS、pg_trgm 都能加进来。做 AI 应用时，这一点很关键。向量检索可以做成扩展，全文检索可以组合使用，结构化过滤继续用 SQL。不同能力在一个查询里协作，减少数据搬运。
SQL 也是我舍不得放下的东西。写 RAG 时，我需要按租户、时间、标签、权限过滤，再按向量距离排序。用 SQL 表达这些条件很自然。CTE、窗口函数、JSONB、全文检索、向量操作符可以混在一起。开发同学不用学一套新的查询语言，DBA 也能用 EXPLAIN 分析计划。PostgreSQL AI 的落地门槛因此低了不少。
事务和生态是我后来才真正重视的。嵌入向量和业务数据写在同一个事务里，更新文档时不会出现原文已改、向量未更新的情况。PostgreSQL 的生态里有云托管、监控工具、ORM、迁移框架、备份方案。这些东西让 AI 功能不是一个孤岛，而是长在成熟的数据平台上。
1.3 PostgreSQL AI 相关扩展与工具版图
我梳理过一圈 PostgreSQL AI 扩展。pgvector 是最常被提到的，它提供 vector 类型、距离操作符和 HNSW、IVFFlat 索引。pg_trgm 做模糊匹配，tsvector 做全文检索，PostGIS 处理地理空间。做多模态检索时，还可以把图像嵌入和文本嵌入放在同一张表里。这些扩展拼起来，能覆盖不少 AI 场景。
工具层面，LangChain、LlamaIndex、Dify、Spring AI 这些框架都支持 PostgreSQL 作为向量存储。Python 生态里有 psycopg、SQLAlchemy、asyncpg。Node.js、Go、Java 也有对应驱动。我试过在 FastAPI 里用 asyncpg 查 pgvector，延迟表现不错。云厂商的托管 PostgreSQL 也在逐步支持 pgvector 和 AI 相关扩展。PostgreSQL AI 的工具版图已经不只是数据库圈的事，它跟应用框架、模型服务、数据管道连在一起。
从选型角度看，工具多不一定是好事。我的经验是：先确定查询模式，再看扩展组合。需要语义搜索就上 pgvector，需要关键词召回就加 tsvector，需要模糊匹配就加 pg_trgm。工具版图是地图，不是清单。按场景选，才不会把系统堆复杂。
1.4 从专用向量数据库到 PostgreSQL 一体化架构
我经历过专用向量数据库的阶段。它的向量索引性能好，API 也简单。项目初期，数据量不大，查询模式单一，用起来很顺手。业务长起来后，问题出现了。权限过滤、事务更新、混合查询、多租户隔离，这些都要在应用层补。专用向量库擅长向量召回，不擅长关系型事务和复杂过滤。
后来我把部分场景迁到 PostgreSQL。向量字段和业务字段放在同一张表，查询时用 SQL 组合条件。召回率没有明显下降，架构却简单了。备份、监控、权限、迁移沿用原有体系。团队不用维护两套数据库。PostgreSQL AI 一体化架构的好处，在中小规模和中等复杂度场景里尤其明显。
专用向量数据库并没有消失。超大规模、极致低延迟、纯向量检索场景，它仍有位置。我的看法是：先问数据关系和查询模式。如果业务数据、权限、事务、过滤条件都很重，PostgreSQL 一体化更省心。如果只是海量向量近邻搜索，专用库可能更合适。PostgreSQL AI 不是唯一答案，它是一条平衡路线。
我在项目里第一次把嵌入向量塞进 PostgreSQL 时，心里挺没底。关系型数据库存高维浮点数组，听起来就不像它的本职工作。pgvector 把这个想法变成了现实。它给 PostgreSQL 加了一个 vector 类型，配套距离操作符和索引。装完之后，向量检索和业务 SQL 能在同一个事务、同一条查询里完成。这部分我想聊聊实际用下来的细节，从安装到调优，再到能落地的几个场景。
2.1 pgvector 安装、向量类型与基本操作
装 pgvector 有两条路。图省事就用官方 Docker 镜像，pgvector/pgvector:pg16 拉下来直接跑。生产环境我更喜欢源码编译，make && make install 之后进数据库执行 CREATE EXTENSION vector;。云托管的话，AWS RDS、阿里云、Supabase 都提供这个扩展，开之前确认一下实例规格和版本。团队里 DBA 同事提过一次，扩展版本要和 PostgreSQL 主版本对齐，升级时容易漏掉这一步。
建表时用 vector(1536) 声明维度，维度必须固定。插入长度不对会直接报错。这个约束一开始让我有点烦，后来反倒觉得是好事。它逼着你在建表前想清楚嵌入模型。我们做过一次模型切换，从 1536 维换到 768 维，整张表的数据得重新生成、重新写入。所以现在我会按模型分表，或者预留一个 embedding_model 字段做版本标记。
基本操作很直白。插入可以用字符串 '[0.1, 0.2, 0.3]'，也可以从数组转换。查询就是 ORDER BY embedding <=> '[...]' LIMIT 5。pgvector 还提供 halfvec、bit、sparsevec 几种类型。halfvec 省一半存储，精度损失可接受。bit 类型做图片去重特别省空间，二值嵌入几 KB 就能搞定一张图。sparsevec 适合 BM25 那种稀疏权重向量。我一般先用 vector，遇到存储或性能瓶颈再换类型。
2.2 向量相似度计算与距离度量选择
距离度量有三个常用操作符。<=> 是余弦距离，文本嵌入场景里我用得最多。<#> 返回负内积，数值越大越相似。<-> 是欧氏距离，图像特征匹配时偶尔用。选择哪个，跟嵌入模型的训练方式直接相关。OpenAI 的 text-embedding 系列、多数中文嵌入模型，都按余弦相似度设计。Cohere 有些模型明确要求内积。
一个很容易被忽略的点是归一化。嵌入模型如果输出了单位向量，余弦和内积的结果几乎一样。向量没归一化就上内积，排序会偏。我们早期做商品推荐时吃过这个亏，召回结果里混进了明显不相关的商品。排查半天才发现是向量没归一化，用 <#> 排序时长度大的向量占了便宜。改成 <1 - (a <=> b)> 之后正常了。现在我会在建表时统一做一次归一化，或者干脆在嵌入服务里处理掉。
度量选择和索引是绑死的。建索引时要指定操作符类，vector_cosine_ops 只加速 <=>，vector_l2_ops 只加速 <->，vector_ip_ops 只加速 <#>。查询里写错操作符，索引直接失效，走全表扫描。我见过同事建了余弦索引，查询却用 <->，EXPLAIN 出来是 Seq Scan，还以为是索引没建好。这个坑记住一句话就行：建什么索引，查什么操作符。
2.3 HNSW、IVFFlat 索引与向量查询优化
pgvector 提供两种索引，HNSW 和 IVFFlat，性格完全不同。IVFFlat 把向量聚成若干簇，查询时只扫部分簇。它构建快、占内存少。代价是召回率受 lists 和 probes 影响大。有个使用顺序很关键：先把数据灌进去，再建 IVFFlat 索引。数据为空时建索引，簇心是随机初始化的，后面插入的数据分布对不上，召回会很难看。lists 参数的经验值，百万行以内用 rows/1000，超过百万用 sqrt(rows)。
HNSW 是图索引，查询快、召回高，代价是构建慢、吃内存。默认 m=16、ef_construction=64，多数场景够用。追求更高召回可以把 m 调到 32，内存会跟着涨。查询时用 SET hnsw.ef_search = 100; 控制搜索范围。我的习惯是拿一批真实查询跑测试，把 ef_search 从 40 逐步往上调，观察召回率和延迟的拐点。100 左右经常是个不错的平衡点，具体还得看数据分布。
批量导入的场景有个优化技巧。先删掉向量索引，灌完数据再重建，比边插边维护索引快好几倍。重建时用 CREATE INDEX CONCURRENTLY 避免锁表。线上服务还可以配合 maintenance_work_mem 和并行 worker 加速构建。写完索引记得跑 ANALYZE。查询侧用 EXPLAIN (ANALYZE, BUFFERS) 确认走的是 Index Scan。如果发现计划里出现 Sort 加 Seq Scan，八成是操作符和索引不匹配，或者过滤条件把优化器带偏了。
2.4 pgvector 向量数据库 AI 应用：语义搜索、推荐与聚类
语义搜索是最直接的应用。把用户查询嵌入成向量，ORDER BY embedding <=> $1 LIMIT 10，再拼上租户、时间、权限这些过滤条件。实际写 SQL 时，过滤和向量排序的先后顺序会影响性能。数据量大、过滤选择性高的时候，PostgreSQL 可能先过滤再排序，这时普通 B-tree 索引能帮上忙。选择性低的时候，先做向量近邻再过滤更划算。我的做法是把两种计划都测一遍，用真实数据看执行时间。分区表在按租户或时间切分的场景里效果明显，每个分区独立建向量索引，查询只扫相关分区。
推荐场景的玩法和语义搜索接近。用户向量和商品向量放在同一个嵌入空间，直接做近邻查询就能拿到候选。麻烦的地方是结果太同质化。你搜一个跑鞋，返回十条都是跑鞋。我会在 SQL 层做一点处理：按类目分桶，每桶取前几条，再合并。或者用 DISTINCT ON 加距离阈值，把过于相似的项去掉。业务方对这个多样性参数很敏感，调高调低直接影响点击率。我们后来把它做成了可配置项，按场景调。
聚类我更多放在数据库外面做。pgvector 本身提供 kmeans 函数，小数据量能用。数据一多，HDBSCAN、UMAP 这类算法在 Python 生态里更成熟。我的流程是把嵌入读出来，跑完聚类，把簇标签写回 PostgreSQL，再用 SQL 做分析和展示。这样数据库负责存储和查询，Python 负责计算密集的部分。两边各干各擅长的事，比硬塞进数据库里跑要省心。整个链路跑通之后，语义搜索、推荐、聚类共享同一份向量数据，维护成本降了不少。
上一章聊的是向量本身怎么存、怎么查。这一章我想把视角拉高一点，说说整个 RAG 系统里 PostgreSQL 到底站在哪个位置。我做过三四个 RAG 项目，有从零搭的，也有往老系统里加检索能力的。踩过的坑集中在两块：一是数据怎么进库，二是答案怎么出来。中间那段检索逻辑，反而相对稳定。下面按数据流的方向拆开讲。
3.1 RAG 系统架构与 PostgreSQL 的定位
很多人一听 RAG，第一反应是"向量数据库 + 大模型"。我早期也这么想，后来发现这个描述漏掉了最要紧的部分：数据治理。企业里的文档不是一次导入就完事，有权限、有版本、有软删除、有增量更新。这些需求专用向量库做起来别扭，关系型数据库做起来顺手。PostgreSQL 在 RAG 里的角色，我理解是"带向量能力的数据中枢"，不只是一个存嵌入的桶。
具体说说一次真实改造。原系统用某云向量库做语义检索，业务元数据放在 MySQL。每次查询要跨两个系统，权限过滤得在应用层做，代码里散落着一堆补丁。搬到 PostgreSQL 之后，向量、文档元数据、租户信息、权限表全在一个库。检索 SQL 里直接 JOIN 权限表，过滤条件写进 WHERE 子句。事务保证写入一致。这一下省掉了两套数据同步的逻辑，出错面小了很多。
架构上我现在倾向于三层。底层是 PostgreSQL，管文档、切块、向量、元数据、对话历史。中间是检索服务，负责嵌入调用、混合召回、重排。上层是编排层，组装 prompt、调 LLM、处理流式输出。有团队把中间层也塞进数据库，用 PL/Python 直接调嵌入 API。小规模能跑，规模化之后调试很痛苦。我更愿意让 PostgreSQL 做它擅长的事：存、查、保证一致。
3.2 文档切分、嵌入生成与元数据存储
切分这一步看起来简单，实际最影响最终效果。固定长度切分（比如 512 token）实现容易，语义边界经常被切碎。我更喜欢按结构切：Markdown 按标题层级，PDF 按段落和表格，代码按函数和类。结构切完之后再做二次合并，把过短的块粘到相邻块上。有个经验值，块长控制在 300 到 600 token 之间，重叠 50 到 100 token。太短上下文不够，太长嵌入会稀释主题。
切完块，接下来是嵌入。这里有个容易忽略的细节：嵌入要基于什么文本。只嵌入正文，检索时用户问"这份合同什么时候到期"，可能召不回来，因为日期写在元数据里。我的做法是把标题、小节路径、关键元数据拼在前缀里一起嵌入。比如 [产品手册 > 支付模块 > 退款] 退款申请需在订单完成后 7 天内提交...。检索效果提升明显。嵌入批量调用时注意并发控制，OpenAI 有速率限制，本地模型则受显存限制。我一般用队列加退避重试。
存的时候，表结构设计要提前想好。一张 documents 存原始文档、来源、版本、权限标签。一张 chunks 存切块文本、嵌入向量、在原文中的位置、所属文档 ID。还留一张 embedding_meta 记录每条向量用的模型名、维度、生成时间。模型换代的时候，这张表帮大忙。我吃过一次苦头：升级嵌入模型之后，新旧向量混在一张表里，检索结果时好时坏。后来加了 embedding_model 字段，查询时强制带上，问题才消失。索引建在 chunks.embedding 上，用 HNSW，理由是 RAG 场景查询频繁、写入相对少。批量导入的时候先把索引删掉，灌完重建。
3.3 向量召回、关键词检索与混合重排
纯向量召回有个老毛病：语义相近但关键词不匹配的内容会被漏掉。用户问某个产品型号 "XR-2000 的保修期"，向量模型可能把 "XR-2000" 当作噪声，召回一堆讲保修但不讲这个型号的文档。反过来纯关键词检索，遇到同义改写就抓瞎。我的做法是两路并行召回，再做融合。向量路走 ORDER BY embedding <=> $1 LIMIT 30，关键词路用 PostgreSQL 的全文检索 tsvector @@ tsquery，也取 30 条。两路各有所长。
融合算法我用过 RRF（Reciprocal Rank Fusion），实现简单效果稳。核心就是 score = sum(1 / (k + rank))，k 取 60。两路结果的排名取倒数相加，排名靠前的自然分数高。它不需要归一化分数，避免了向量距离和 BM25 分数尺度不一致的问题。写完发现某条文档在两路里都排前面，融合后分数就特别高，这类"双路命中"的内容往往确实是用户想要的。
融合之后再加一层重排。我一般用交叉编码器，把查询和候选块拼在一起送进模型，输出相关性分数。这一步比向量召回慢很多，所以候选集控制在小范围，20 到 30 条。重排完取前 5 到 8 条送进 prompt。重排模型可以本地部署，也可以调 API。小语种项目里，我发现多语言交叉编码器的效果比英文模型好很多。整个链路跑下来，从查询到最终候选，延迟控制在几百毫秒以内是可以做到的，前提是索引调好、批量处理得当。
3.4 上下文注入、LLM 调用与答案生成编排
候选块拿到之后，怎么塞进 prompt 也有讲究。简单堆砌会浪费 token、干扰模型。我的做法是给每块编号，附上来源信息。比如 [1] 来源：产品手册 v2.3，退款章节。然后在系统提示里要求模型标注引用，请基于以下资料回答，引用时用 [编号] 标注。这样输出可追溯，用户知道答案从哪来。有客户特别看重这一点，合规部门要求每条事实都能溯源。
上下文长度是个约束。候选块总 token 超过模型窗口就得截断。我按重排分数从高到低填，填到接近上限为止。有时排序最高的块很短，我会再塞几个次优块补足。这个策略比按固定数量取块更稳。还有个技巧是把最关键的信息放在开头或结尾。做过测试，模型对 prompt 首尾信息的注意力明显高于中段。所以我会保证排名第一的块放在最前面。
调用 LLM 这一步，工程上要处理的事不少。流式输出让用户感知延迟小。失败重试、超时降级、token 计费监控，每一样都要照顾到。我们内部做了个编排层，把"检索 → 组装 → 调用 → 后处理"串成管道，每一步可插拔。对话历史存在 PostgreSQL 里，多轮场景下把最近几轮对话一起送进去。长会话的话，历史也要做摘要压缩，否则窗口很快撑满。整套系统上线后，用户反馈里最常提的一句是"回答有出处，敢信"。这句话比任何技术指标都让我踏实。 SELECT c.id, c.content, c.embedding <=> $1 AS distance FROM chunks c JOIN documents d ON c.document_id = d.id WHERE d.tenant_id = $2 AND d.category = 'contract' AND d.status = 'active' AND c.embedding <=> $1 < 0.35 ORDER BY c.embedding <=> $1 LIMIT 20;
SELECT p.id, p.title, p.embedding <=> $1 AS distance FROM products p WHERE p.price BETWEEN $2 AND $3 AND p.stock > 0 AND p.category = $4 ORDER BY p.embedding <=> $1 LIMIT 50;
前面聊的都是怎么把 AI 能力塞进 PostgreSQL 里跑起来。真正上线之后，麻烦事才刚开始。部署方式选哪种、权限怎么卡、监控看什么指标、成本怎么压下来，这些琐碎问题比调索引更磨人。我把自己踩过的坑和这几年观察到的趋势整理一下，希望能帮你少走点弯路。
6.1 云托管、自建集群与边缘部署模式
我最早做 AI 应用时，图省事直接用了云托管的 PostgreSQL。AWS RDS、Azure Database、GCP Cloud SQL 都支持 pgvector，开箱即用，备份、监控、扩容点点鼠标就行。那会儿项目紧，没时间折腾运维，托管方案确实帮了大忙。后来数据量涨到几千万向量，托管实例的内存和 IO 开始吃紧，HNSW 索引构建动不动就超时。升级实例规格能缓解，账单也跟着涨。我算过一笔账，同样配置的自建集群，成本能省下四成左右。自建意味着自己装 pgvector，自己配流复制，自己搞备份脚本。好处是能针对向量负载调参，比如把 maintenance_work_mem 拉大，shared_buffers 按索引大小重新分配。坏处是半夜出问题得自己爬起来。我现在的选择是：核心业务用托管，边缘分析和实验环境用自建，混合着来。
边缘部署是最近两年冒出来的需求。有个做工业质检的客户，工厂在郊区，网络不稳定，质检图片不能传出厂区。我们在产线旁放了一台小服务器，跑 PostgreSQL 加 pgvector，本地存图片向量，本地做缺陷匹配。边缘节点只把异常结果和少量元数据同步到云端，原始图片和向量留在本地。这种模式对延迟和数据主权都友好，麻烦的是边缘设备的运维。我们写了一套 Ansible 脚本，自动安装、升级、收集日志。边缘节点的 PostgreSQL 配置也做了精简，关掉不必要的扩展，只留 pgvector 和几个监控插件。内存有限，HNSW 的 m 参数设得比较小，召回率靠调整 ef_search 补回来。我自己的感受是，边缘场景下 PostgreSQL 的轻量优势很明显，一台 8G 内存的机器就能跑几十万向量的检索。
6.2 权限控制、数据脱敏与隐私合规
权限这块我在知识库项目里吃过亏。早期应用层过滤权限，结果向量检索先返回了所有部门的文档片段，再在代码里筛掉无权限的。日志里能看到员工查询时，系统短暂加载过机密文档的向量。后来全部改成 PostgreSQL 的行级安全策略。chunks 表启用 RLS，策略里写清楚：当前用户只能看到所属部门且密级不高于其权限的行。向量检索的 SQL 里不用额外加 WHERE，数据库自动套上策略。HNSW 索引在 RLS 下可能效率下降，我的做法是按部门分区，每个分区单独建索引，策略里带上分区键，优化器能剪掉无关分区。列级权限也用过，比如 embedding 列只允许特定角色读取，普通分析师只能看文本和元数据。这种细粒度控制在 AI 场景里特别重要，向量本身可能反推出原文，不能随便暴露。
数据脱敏要在嵌入生成之前做。我见过团队直接把用户聊天记录扔给 embedding 模型，里面带着手机号、身份证号。向量存进数据库后，这些信息虽然不可读，但通过相似度检索能关联到具体个人。我的流程是：先过一遍脱敏管道，用正则或 NER 模型把 PII 替换成占位符，再生成嵌入。查询时如果必须用原始数据，走另一套加密通道，向量和原文分开存储。合规方面，GDPR 的“被遗忘权”对向量库是个挑战。用户要求删除数据时，不光要删原文，还得删对应的向量和索引条目。pgvector 的 HNSW 索引不支持单条删除，我们只能标记删除，定期重建索引。重建期间用 IVFFlat 索引顶着，保证查询不中断。审计用 pgAudit，所有向量查询和 LLM 调用都记录在案，出了事能追溯。
6.3 监控、备份、扩容与成本优化
监控向量数据库跟监控普通 OLTP 库不太一样。我主要看几个指标：HNSW 索引的构建时间、查询时的 ef_search 实际生效值、向量检索的 P99 延迟、以及 pg_stat_statements 里向量查询的调用频率。Prometheus 抓取 pg_stat_database 和自定义的 pgvector 指标，Grafana 上做面板。有次线上查询突然变慢，看监控发现是某个批处理任务在重建索引，把 IO 打满了。后来我们把索引构建挪到只读副本上，主库只负责查询和增量写入。备份策略也调整了。向量数据体积大，全量备份耗时。我的做法是：原文和元数据每天全备，向量列单独处理。嵌入可以从原文重新生成，备份时跳过向量列，恢复后再跑一遍嵌入流水线。这样备份窗口从 4 小时压到 40 分钟。代价是恢复后要等嵌入重新算完才能提供检索服务，我们把这个过程做成异步任务，先恢复结构化查询，向量检索逐步上线。
扩容和成本是绑在一起的。垂直扩容简单，加内存加 CPU，但单机有上限。水平扩容我试过 Citus 分片，按用户 ID 或文档 ID 哈希，每个分片独立建 HNSW 索引。查询时 Citus 并行下发，汇总结果。分片键选不好会导致热点，比如按部门分片，大部门的分片压力特别大。后来改成按文档 ID 哈希，均匀多了。成本优化上，向量占的存储空间是大头。1536 维的 float32 向量，一千万条就是 60GB 左右。我们试过半精度存储，vector(1536) 换成 halfvec(1536)，存储减半，召回率掉了一个百分点。量化到 int8 更省，但精度损失需要评估。LLM 调用成本也得盯着。高频问题走缓存，缓存命中率做到 60% 之后，每月 API 账单降了七成。缓存 key 用问题嵌入的哈希，存在 PostgreSQL 的 cache 表里，设 TTL。
6.4 数据库内 AI、Agent 应用与实时智能趋势
数据库内 AI 是我最近特别关注的方向。PostgresML、MADlib 这些扩展能把模型训练和推理直接放在数据库里跑。我做过一个实时风控的 demo：交易数据写入 PostgreSQL，触发器调用 pgml 的预测函数，毫秒级返回风险分。数据不用出库，延迟低，架构也简单。缺点是模型选择有限，复杂深度模型还是得抽到外部。我的判断是，数据库内 AI 适合特征工程简单、延迟敏感的场景，比如实时推荐、异常检测。复杂模型训练仍然在外部做，推理结果写回数据库。这种混合架构在可预见的未来会一直是主流。
Agent 应用是另一个让我兴奋的点。我最近在折腾一个客服 Agent，用 PostgreSQL 存对话历史、工具调用记录和长期记忆。记忆用向量存，每次对话前检索相关历史，拼进 prompt。Agent 的状态机也放在数据库里，用 SKIP LOCKED 做任务队列，多个 Agent 实例并发处理。LangChain 和 LlamaIndex 都支持 PostgreSQL 作为向量存储和记忆后端。我自己的体会是，PostgreSQL 在 Agent 场景里扮演的是“中枢神经”角色：短期记忆、长期记忆、工具执行日志、权限控制，全在一个事务里管。比东拼西凑一堆存储服务靠谱得多。实时智能的趋势也很明显，Debezium 捕获 PostgreSQL 的变更，实时推给流处理引擎更新向量，推荐结果秒级刷新。我服务的一个新闻 App 就这么干，新文章发布后 3 秒内就能被语义检索到。未来几年，PostgreSQL 大概率会从“支持 AI 的数据库”变成“AI 应用的数据中枢”，向量、关系、全文、JSON、图，都在一个引擎里闭环。
