RAG 没死，但也快了
内容提要
RAG仍然存在，但传统的“切片—向量化—Top-K”流水线不应再作为默认方案。Claude Code等转向Agentic Search，通过目录和grep按需查找，效果更佳。在长上下文时代，小知识库可直接放入上下文；向量检索应回归普通工具定位，与全文检索、元数据和权限控制配合使用。PostgreSQL可统一存储与检索，避免跨系统一致性问题。核心是根据语料、成本和延迟进行选型，而非盲目依赖向量检索。
延伸解读
传统 RAG 流水线的局限
文章指出，切片、向量化、Top-K 的流水线存在固有缺陷：切片会拆散上下文，导致前提与结论分离；Top-K 返回的是最相似而非最相关的片段，可能遗漏关键信息；相似不等于相关，否定、数字、错误码等细节尤其容易出错。这些限制意味着，单纯依赖向量检索难以保证回答质量，需要更复杂的检索系统设计。
Agentic Search 的替代优势
Claude Code 等转向 Agentic Search，通过目录和 grep 按需查找，效果更佳。Agent 可以边找边改主意，先读目录再读正文，发现错误可换词重搜，还能继续翻前后文。对于代码库、文档站等有结构的资料，利用现有目录和全文搜索往往比预先切片向量化更高效，且避免了索引陈旧问题。
长上下文与小知识库的简化方案
随着上下文窗口扩大，小知识库可直接放入上下文，无需搭建检索管线。文章建议先数 token，若完整内容在预算内，就不必切碎。对于有结构的资料，优先利用目录、文件树和全文搜索，交给 Agent 按需查找。这能省去维护分块、embedding 和索引同步的额外工程。
PostgreSQL 的统一存储与检索价值
文章认为，向量检索应回归普通工具，与全文检索、元数据、权限控制配合。PostgreSQL 可统一存储原始内容、向量和元数据，在同一事务中维护，避免跨系统一致性问题。专用向量数据库在补全高可用、备份、事务等功能时，反而进入通用数据库地盘。选型应基于语料、成本和延迟，而非盲目依赖向量检索。
Q&A
传统的RAG流水线具体指什么？为什么现在不建议作为默认方案？
传统RAG流水线指“文档切片→embedding→存向量库→问题转向量→相似度检索→捞Top-K→塞进prompt”这一套流程。不建议作为默认方案，是因为它诞生于小上下文窗口时代，当时不得不挑几段塞进模型；现在长上下文窗口出现，小知识库可直接放入上下文，且纯向量召回存在切片拆散上下文、Top-K只给最相似而非足以回答的片段、相似不等于相关等问题。
Claude Code为什么选择agentic search而不是向量检索？
Claude Code作者Boris Cherny在播客中表示，他们早期试过RAG和几种搜索方案，最后选择agentic search，因为效果更好。早期版本确实用了本地向量库，但让Agent自己搜索更简单，也省掉了索引陈旧等麻烦。Anthropic后来的方法论也是这条路：CLAUDE.md预先放入上下文，其余靠glob、grep按需查找，先给目录让Agent自己翻。
长上下文窗口的出现如何影响RAG的必要性？
长上下文窗口出现后，原来塞不进去的资料现在可能放得下了。对小知识库来说，动手搭管线之前应先数一遍token：如果完整内容就在可接受的预算里，就没必要先切碎。但长上下文不是免费的，成本、延迟、信息遗漏依然存在，所以仍需根据语料、成本和延迟进行选型。
纯向量召回有哪些常见问题？
纯向量召回有几个老问题：切片会拆散上下文，导致结论捞回来但前提丢失；Top-K给的是库里最像的几条，不是足以回答问题的几条，库里没答案也能排名；相似不等于相关，否定、数字、错误码、产品型号等细节尤其不能只靠大意相近。阈值、reranker、拒答机制能补，但补到最后已是一套需要认真设计的检索系统。
在RAG架构中，PostgreSQL可以扮演什么角色？
PostgreSQL可以存原始内容，做全文和向量检索，管理权限，也可以保存Agent的任务、对话和执行状态。把上下文窗口理解成工作内存，Agent还需要一个可靠的地方保存长期状态，PG在这里的价值比“放向量的柜子”大得多。向量和原文放在同一个PG里，可以在同一事务中维护，一起提交、删除、回滚，减少跨系统一致性问题。
专用向量数据库面临哪些挑战？
专用向量数据库的挑战在于位置：它们早就不只做Top-K，混合检索、元数据过滤、多租户、备份都在补，但补着补着就走进了通用数据库的地盘。业务上生产后，高可用、备份恢复、事务、权限、监控、驱动迟早都得有人负责。pgvector可以直接使用PostgreSQL已有的这些能力。更实际的问题是一致性：主数据在PG，向量在另一套系统，就得负责同步，用户删了一行数据，向量库里那份还没删，检索就可能翻出本不该存在的记录。
如何根据语料类型选择检索架构？
先看资料长什么样。资料不多，就先试直接放进上下文。代码库、文档站、Wiki、API手册，优先用它们已有的结构，如目录、文件树、交叉引用、全文搜索，交给Agent按需查找。十万份合同、几年邮件、杂乱群聊和扫描件，则需要建索引，但也不该只留一路向量召回：全文检索负责关键词、型号、错误码；向量补充同义词、跨语言和口语化问法；元数据缩小范围，权限决定可见内容。找到文档后，再读相关章节，必要时继续检索。
