RAG 没死，但也快了

PG 三十周年系列直播，第七期聊 PG + AI。主持人的手卡上有这么一问：

RAG 火了两年了，就是让大模型查你的私有资料再回答。PG 在这套架构里到底扮演什么角色？只存向量，还是连元数据、权限、对话记忆都兜住？

老冯看了半天，觉得该先问另一个问题：这套架构本身，还值得照着搭吗？

RAG 这个词当然还活着。但大家熟悉的那套“切片、向量化、Top-K”流水线，已经不该是默认答案了。向量检索正在退回一个普通工具的位置，越来越多的工作，被目录、全文检索和会自己翻资料的 Agent 接了过去。

向量检索有用，但这不妨碍我认为，这几年大家把它捧得太高了。

发明者为什么要辟谣？

2020 年那篇 RAG 论文的共同作者之一 Douwe Kiela，后来创办了 Contextual AI。2025 年，他写了一篇《RAG is dead, long live RAG![8]》，反驳“长上下文让 RAG 过时”的说法，公司还为此买了个域名。

后来接受 The New Stack 采访时，他又解释：大家只是把 RAG 重新包装成了 context engineering。通过 MCP 去检索资料，也可以算 RAG。报道还提到，RAG 仍在公司的技术栈里，只是首页上已经不再突出这个词。

发明者没放弃，老冯不能替他宣布死亡。不过，一个技术名词需要专门辟谣，还得不断扩充定义来证明自己依然重要，处境如何大家心里有数。

按字面理解，“检索增强生成”确实很难死。模型回答前去外面找了点东西，都能算。但多数人在 2023 年学会、2024 年上线、今天还在维护的 RAG，是一条具体得多的流水线：

文档切片 → embedding → 存向量库 → 问题转向量 → 相似度检索 → 捞 Top-K → 塞进 prompt。

老冯要说的就是这套东西。

Claude Code 最后选了 grep

Claude Code 作者 Boris Cherny 在 2025 年的 Latent Space 播客里讲过：他们早期试过 RAG，也试过几种搜索方案，最后选择了 agentic search，因为效果更好。后来他又补充，早期版本确实用了本地向量库，但让 Agent 自己搜索更简单，也省掉了索引陈旧等麻烦。

Anthropic 后来的方法论也是这条路。CLAUDE.md 这类文件预先放进上下文，其余内容靠 glob、grep 按需查找。读到一个文件，发现它引用了另一个文件，就继续往下读。Agent Skills 也是先给简短描述，用到了再加载正文，需要细节再翻附件。

说白了，就是先给目录，让它自己翻。老冯给 Pigsty 做 Skill 时，走的也是这个路子。没切块，没算向量，只是把文档站的目录写进 AGENTS.md / CLAUDE.md：装 PG 去哪一页，配高可用去哪一页，某个参数在哪一节。Agent 看目录找入口，不够就顺着链接继续读，简单粗暴，效果很好。

实际用下来，已经足够解决我的问题。一个副作用是，Pigsty 文档站的流量被 Agent 拉到了每月上亿 PV。至于向量检索，我已经很久没碰过了——不是不会，是在自己的场景里用不上。

这和固定的向量流水线有个很大的区别：Agent 可以边找边改主意。

一次 Top-K 检索，是提前猜好哪几段可能相关，交给模型作答。Agent 则可以先读目录，再看正文；发现找错了，换个词；发现条件不全，继续翻前后文。

当然，代码库和文档站本来就有结构，函数名、参数名、章节标题都适合搜索。这不能证明 grep 在所有场景里都赢。但它至少说明：有现成的结构可用时，先把内容切碎再算向量，未必是最聪明的做法。

你把这种按需查资料的方式也叫 RAG，当然可以。只是它已经不是当初那条流水线了。

小窗口时代的办法，不该一直照搬

RAG 诞生于 2020 年，并不是专门为 ChatGPT 的 4K 窗口发明的。但它在 2023 年爆火，和当时捉襟见肘的上下文窗口脱不开关系。

你有一本三百页的产品手册，模型却只能吃下几页。怎么办？只能挑一点塞进去。

挑选的方法很多，倒排索引、BM25 都能用。但 embedding 加相似度检索最容易演示，教程最多，一个下午就能跑通。于是，切片、向量库、Top-K 成了标准答案。

后来，几十万乃至百万 token 的上下文窗口出现了。原来塞不进去的资料，现在可能放得下了。

长上下文当然不是免费的，也不保证模型看过就能用好。成本、延迟、信息遗漏，一个都没消失。但对小知识库来说，动手搭管线之前，至少应该先数一遍 token：完整内容就在可接受的预算里，为什么非要先切碎？

即便不谈窗口，纯向量召回也有几个老问题。

切片首先会拆散上下文。“以下项目不予报销”和后面的清单被切开了，结论捞回来了，前提没捞回来。块小，容易匹配到具体内容，却容易丢背景；块大，背景多了，匹配又可能不够准确。Late Chunking、Contextual Retrieval 都在缓解这个问题，但不能指望随手切一刀，语义就刚好落在边界里。

其次，Top-K 给你的是库里最像的几条，不是足以回答问题的几条。库里根本没有答案，它照样能排出一个名次。相似段落被塞进 prompt，模型又倾向于接着往下说，错误就这么出来了。

阈值、reranker、拒答机制都能补。只是补到最后，你搭的已经是一套需要认真设计的检索系统，不再是教程里那次轻巧的余弦计算。

还有最根本的一条：相似不等于相关。

问“哪些项目不能报销”，捞回来一篇“报销流程说明”，语义上确实很近，问题却未必答得上。否定、数字、错误码、产品型号，这些地方尤其不能只靠“大意相近”。而企业知识库里，用户经常问的恰恰就是这些细节。

grep 也不是灵丹妙药。用户说“数据库连不上”，文档写的是 connection refused，搜一次照样可能不中。Agent 的好处是能换词再搜、读原文核对，而不是把第一次结果当成最终证据。

向量检索同样可以放进这个循环。没必要把它和 Agent 对立起来，该放弃的是“一次相似度排序就足够回答问题”的侥幸。

先看资料，再选架构

老冯现在会先看资料长什么样。资料不多，就先试直接放进上下文。能用简单办法解决，没必要为了架构完整，额外养一套检索系统。当然，每次调用的成本和延迟还是要算。

代码库、文档站、Wiki、API 手册，优先用它们已有的结构。目录、文件树、交叉引用、全文搜索，本来就是人找资料的工具，也可以交给 Agent。几千页的手册不需要一次读完，每次找到相关的几页就够了。

这里真正值得花功夫的是目录质量、页面组织和搜索能力。目录也会过期，但如果它能随文档构建自动生成，通常比额外维护一套分块、embedding 和索引同步流程省事。

十万份合同、几年的邮件、杂乱的群聊和扫描件，就没这么轻松了。这里确实需要建索引，但也不该只留一路向量召回。

全文检索负责关键词、型号、错误码；向量补充同义词、跨语言和口语化问法；元数据用来缩小范围，权限决定哪些内容能被看到。找到文档后，再读相关章节，必要时继续检索。

Agent 多翻几轮也有代价：调用更多，延迟更高。对响应时间和成本要求严格的服务，一套经过评测的固定检索管线，仍然可能是更好的选择。

所以别把“用不用 RAG”当成一道信仰题。语料、权限、成本、延迟，才是选型依据。

向量还是有用，只是没那么神

向量检索的老本行，是找相似对象。

在大模型知识库火起来之前，图像搜索、推荐、去重、聚类就已经在用它。文本向量也不是 2023 年才有的，只是那一年，embedding API 和大模型问答把它推到了所有开发者面前。

问题出在，“找相似内容”被包装成了“找到正确答案”。

找相似图片、相似工单，做推荐、聚类，向量当然好用。文本问答里的同义词、跨语言表达，也值得留一路向量召回。但要找某条报销规定的适用条件，最终还得看原文，不能拿余弦相似度代替证据。

这就是 2023 年的那句话：。

到处都用，每个数据库都值得支持。但支持一种数据类型、提供一种检索能力，不意味着用户就该为它单独养一个数据库。

专用向量数据库，问题出在位置上

老冯 2023 年写 时，判断很简单：向量存储和检索是真实需求，会随 AI 一起增长；但专用向量数据库未必能分到多少。

今天我还是这个看法。

Databricks 收购 Neon，Snowflake 收购 Crunchy Data，至少说明一件事：通用数据库没有因为 AI 的到来失去价值。PG 不必先改名叫“AI 原生数据库”，照样是值钱的资产。

专用向量库也早就不只做 Top-K 了。混合检索、元数据过滤、多租户、备份，大家都在补。它们面临的麻烦，是这些东西补着补着，就走进了通用数据库的地盘。

业务上了生产，用户要的不会只有检索速度。高可用、备份恢复、事务、权限、监控、驱动，迟早都得有人负责。pgvector 可以直接使用 PostgreSQL 已有的这些能力。一个扩展背后站着整套数据库，这是 PG 不讲武德的地方。

更实际的问题是一致性。

主数据在 PG，向量在另一套系统，你就得负责同步。用户删了一行数据，向量库里那份还没删，检索就可能翻出一条本不该存在的记录。CDC、outbox、重试、对账都能解决，但每一样都是额外工程。

向量和原文放在同一个 PG 里，就可以在同一事务中维护，一起提交、删除、回滚。它不会自动替你生成新 embedding，却能少掉一个跨系统一致性问题。这个价值，通常不会出现在向量检索的 benchmark 表格里。

再看实际需要的检索：全文、向量、元数据过滤、权限，还有业务表关联。PG 配上合适的扩展，往往就能放在一起做。为了向量单独拆出一套系统，再把这些东西同步过去，得有足够大的收益才划算。

这不等于 pgvector 没有短板。索引构建、写入、内存占用、大规模部署，都该拿真实负载测。HNSW 自身有成本，PG 的实现也有取舍，不能把所有问题都推给其中一方。VectorChord 等扩展在尝试不同的索引和量化路线，也需要按场景评估。

规模大到值得拆一个专门的检索系统，那就拆。只是别在还没有数据、没有负载的时候，先把分布式数据同步的债背上。

至于向量要不要进 PG 内核，老冯觉得没必要着急。检索方案还在变化，扩展可以各走各的路。用户需要的是好用的能力，不是一张“已进入内核”的奖状。

结语

回到直播手卡上的问题：PG 在 RAG 架构里扮演什么角色？

不用拿 RAG 把它框住。PG 可以存原始内容，做全文和向量检索，甚至存储检索图数据，地理空间数据，可以处理管理权限，也可以保存 Agent 的任务、对话和执行状态。查资料只是其中一部分，持久化、事务、回滚和审计，同样重要。

把上下文窗口理解成工作内存，那么 Agent 还需要一个可靠的地方保存长期状态。PG 在这里的价值，比一个 “放向量的柜子”大得多。

向量检索值得保留，但是围着向量检索搭建一切的习惯，可以退场了。有些系统还在为小窗口时代的限制付账，有些则只是照着教程，给自己添了一堆本来不需要的零件。十年前问要不要上 NoSQL，五年前问要不要上云原生数据库，两年前问要不要上向量数据库，今天又问要不要上 AI 原生数据库。

老冯的建议还是那句：

先把 Postgres 用明白吧。

参考资料

•冯若航，《专用向量数据库凉了吗？[10]》，2023 年 11 月。•Lewis et al.，《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks[11]》，2020 年。•Douwe Kiela，《RAG is dead, long live RAG![12]》，Contextual AI Blog，2025 年；Richard MacManus，《RAG isn’t dead, but context engineering is the new hotness[13]》，The New Stack，2026 年 1 月。•Latent Space，《Claude Code: Anthropic’s Agent in Your Terminal[14]》，2025 年 5 月；Boris Cherny 在 X 上的补充说明[15]，2026 年 2 月。•Anthropic，《Effective context engineering for AI agents[16]》，2025 年 9 月；《Introducing Contextual Retrieval[17]》，2024 年 9 月；Agent Skills 发布说明[18]，2025 年 10 月。•Databricks 收购 Neon 公告[19]，2025 年 5 月；TechCrunch 关于 Snowflake 收购 Crunchy Data 的报道[20]，2025 年 6 月。