Pinecone 刚刚几乎等于亲口宣布：RAG 时代结束了。
作为向量数据库赛道的开创者，Pinecone 当年亲手把 RAG 定义成了大语言模型 grounding 的标准范式。过去几年里，大约 80 万开发者、9000 家付费客户，都在 Pinecone 的基础设施上学习如何切 chunk、做 embedding、跑 retrieval。而随着本周一发布面向 Agent 的知识引擎 Nexus，Pinecone 现在却开始告诉这些开发者：他们过去学会的那套模式，如今反而成了瓶颈。
如果仔细看 Pinecone 对 Nexus 的描述，会发现它几乎是在重新定义整个 retrieval 模式。它把 retrieval-at-inference（推理检索）形容成“Agent 检索的十条蓝色链接时代（the ten blue links era of agentic retrieval）”。
这里的“十条蓝色链接”，其实是在借用早年搜索引擎的经典意象：搜索引擎只负责甩给你一堆链接，用户自己点进去、自己阅读、自己拼信息。Pinecone 的意思是，现在很多 Agent 的 retrieval，本质上也还停留在这种“AI 版搜索引擎”阶段——不停 retrieve、read、再 retrieve。
它给出的数据是：
陷在 retrieve-read-retrieve 循环里的 Agent，任务完成率通常只有 50% 到 60%；而且 Agent 85% 的精力，其实都消耗在“找上下文”这件事上。
Pinecone 的核心观点是：把一堆原始 chunk 直接丢给前沿模型，然后期待模型自己理解、自己推理，这套方式既脆弱、又慢，还非常昂贵。
而这套描述，其实就是换了个名字的 RAG。过去四年里，Pinecone 一直在推动的正是这套模式：教程、培训内容、开发者关系体系，几乎全都围绕它展开。只是现在，向量数据库已经不再是面向开发者的“产品表层”，而变成了更底层的基础设施。真正的产品层，又往上移动了一层。
这种级别的“自我揭短”其实很少见。大多数基础设施厂商，即便已经意识到旧模式在衰退，也会继续卖旧东西，等市场自己慢慢察觉。但 Pinecone 成了第一个主动把这件事说出来的厂商，他们表示：“Agent 时代需要一些不同的东西。”
Pinecone 现在的新关键词叫“Knowledge Compilation（知识编译）”。核心变化，其实是把“推理”提前了。
他们表示今天的 Agent，其实还无法真正表达“自己需要什么”。这不是功能缺失，而是更底层的结构性缺口。
现在几乎每一个做 Agent 应用的团队，都在重复造同样的 retrieval 轮子：自定义工具定义、在 Agent 框架和数据源之间写一堆胶水代码、做各种一次性的集成，而这些东西只要底层稍微变化一下就会崩掉。整个行业至今都没有一套统一的“知识请求语言”，让 Agent 能清楚表达自己究竟想从知识系统里得到什么。
这其实不是第一次发生类似的事。在 SQL 出现之前，每个应用也都得自己实现一套数据访问层。后来 SQL 给关系型数据库提供了一个通用接口，整个应用生态才真正建立起来。真正改变行业的，不只是数据库本身，而是那个统一接口。
现在 Agent 也走到了类似的结构性时刻。而且，有些东西，它们今天甚至根本“说不出来”。
“直接把答案给我，而不是二十段 chunk。”
现在没有统一的输出结构约定，Agent 拿到的往往还是原始文本，每次调用之后都得重新解析，token 消耗也随之暴涨。
“告诉我答案来自哪个来源，以及它的可信度。”
今天大多数系统都缺乏字段级别的 grounding，Agent 没法区分哪些是事实、哪些只是模型猜测，于是输出天然不稳定，也缺乏治理能力。
“把推理深度控制在标准范围内，并在 500 毫秒内返回。”
现在没有统一的 budget envelope（预算边界）。每次调用可能无限下钻、无限延长，最终结果就是不可预测、缓慢而浪费。
KnowQL 想解决的，就是 Agent 缺失的这套“表达能力”。
过去的模式里，Agent 会在查询时临时抓取二十段 chunk，再疯狂消耗 token 去理解这些内容到底是什么意思；而 Nexus 的做法，是提前把源数据预编译成带类型、可引用、面向具体任务的知识产物（artifacts）。Agent 查询的不再是原始语料库，而是这些已经整理好的 artifacts。
KnowQL 则给 Agent 提供了一套完成这件事的“语言”。它把 intent（意图）、filter（过滤）、provenance（来源）、output shape（输出格式）、confidence（置信度）以及 latency budget（延迟预算）这六个 primitive，封装进一次声明式调用里，最终直接返回一个带引用、结构化的结果。
Pinecone 声称，这种方式能把任务完成率提高到 90% 以上，同时把 token 开销降低 90%。这些数字当然还需要生产环境验证，暂时别太早全信。但就算不看具体数字，方向其实已经很明确了：“编译一次，多次复用（compile once, read many times）”，本来就更适合 Agent 工作负载。
而且，往这个方向走的，也不只有 Pinecone 一家。更大的趋势，其实是：整个 AI 世界都在把“推理”往上游移动。
Anthropic 推出的 Skills，本质上就是预编译、可复用的上下文包；Cursor 的 Rules，在编辑器层做的是同一件事；Claude Code 的 subagents，会为不同任务提前打包上下文和工具；而 LangChain 的 Harrison Chase 这几个月一直在强调的“context engineering”，也是同一个方向。现在，Pinecone 只是把这种思路推进到了 retrieval 层。
这个模式本身并不新鲜。真正新鲜的是：第一个公开宣布它的人，居然是 Pinecone 自己。当然，也有人会提出合理质疑。KnowQL 能不能像 SQL 那样成为真正的标准，还有很长的路要走。毕竟，标准不是某一家厂商一句话就能定义出来的。向量检索本身也不会消失，很多 Agent 工作负载依然需要廉价、快速的文本相似度搜索。真正变化的，是价值所在的位置。
如果未来 12 个月的发展，真的像 Pinecone 押注的那样，那么向量搜索会慢慢变成“水电煤”一样的基础设施；Knowledge Compilation 才会成为真正的产品层；而“RAG pipeline”这个词，最后可能会像今天的“LAMP stack”一样，变成一种带着敬意的历史名词。
最可能判断错的，其实也是“时间点”。因为一个技术范式的衰退，往往都会比厂商宣告它“结束”时来得更慢。但大的方向已经很明显了。而最先把这个方向说出来的，偏偏正是当年亲手把 RAG 做成主流的那家公司。
那个曾经教你怎么做 RAG 的厂商，现在开始告诉你：别再这么干了。
参考链接：
https://www.pinecone.io/blog/knowledge-infrastructure-for-agents/
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。