Nexus：RAG 时代终结？编译器 AI 知识层来了

最近 Pinecone 发布了一个新东西**Nexus。**最早我是在抖音上看到的说实话这种标题挺吓人的低劣但有效我都忍不住要点进去RAG 时代终结了。向量数据库不够用了。Agent 需要 Knowledge Engine。因为过去两年很多企业刚刚理解什么是 RAG刚刚知道知识库不是把 PDF 丢给大模型刚刚开始研究向量数据库、Embedding、Chunk、TopK、Rerank结果现在突然有人告诉你RAG 时代终结那不是完了吗大家千万不要小看这种短视频因为他真的会影响老板的心智他会导致一个问题那企业到底还做不做 AI 知识库大家不要笑这是真实在发生的事情技术负责人要花很大的功夫去解释这一切毕竟老板们多半只看标题不看内容…当然也会有一些“心志不坚”对 AI 体系不了解的产研负责人会疑惑甚至焦虑刚学会走路就被通知走路这件事已经落后了我觉得这里需要冷静一点RAG 没有消失消失的是低配 RAG毕竟低配 RAG 本来也没解决什么问题所谓低配 RAG就是传统三件套上传文档 ↓切成 chunk ↓向量化 ↓用户提问时召回 TopK ↓塞给大模型 ↓生成答案如果问题简单比如客服 FAQ、产品说明、内部制度查询这套东西也能使用。但如果你要让 AI 真正进入企业流程帮你做合同审查、项目复盘、医疗辅助决策这套朴素 RAG 就会开始暴露问题召回不稳定证据不完整表格读不准上下文拼不全引用对不上多文档比较困难权限不好控制答案经常看起来对其实依据很弱综上我深入研究 Nexus 后我觉得他要表达的也不是 RAG 没了而是在倡导新的范式AI 知识库的重点正在从检索片段走向编译知识。关于这里的知识我们在前两天讨论 NoteBookLM 的时候已经做了讨论今天继续围绕 Nexus 做下简单扩展Nexus 是什么Pinecone 原来是典型的向量数据库公司。按理说它最应该继续强化一个叙事向量数据库是 AI 应用的核心基础设施。只不过随着模型的发展和我们在 AI 知识库的实践大家都慢慢意识到貌似向量库不是必须他跟 AI 知识库并不是绑定关系。出于生存考虑很多向量数据库公司都不得不贴着 AI 知识库讲新的故事Nexus 就是这个场景下的产物。因为既然向量库是“过时”的产物所以 Pinecone 对 Nexus 的定位就肯定不是一个更强的向量库而是Knowledge Engine for Agents也就是面向 Agent 的知识引擎Pinecone 官方介绍里Nexus 主要有两个核心组件Context Compiler 和 Composable Retriever。前者负责围绕企业业务结构组织知识后者负责按照不同 Agent 的任务需求把知识以合适格式返回给 Agent。这句话听起来非常抽象翻译一下就是以前 RAG 是用户提问以后系统临时去文档里找片段。Nexus 想做的是在 Agent 使用之前先把企业数据提前整理、结构化、编译成任务可用的知识资产前两天我们聊 NotebookLM 的时候其实已经讲过类似的趋势。NotebookLM 给用户的体验是你把资料上传进去它可以围绕资料做问答。并且从表面上看NotebookLM 好像完全没有 RAG 的痕迹看不到 chunk看不到向量库看不到 TopK看不到 rerank看不到 score 阈值但这不代表它没有 RAG而是 Google 把 RAG 的工程链路产品化、黑盒化了。综上Nexus 和 NotebookLM 虽然不是一个产品类型但背后的方向是一致的低配 RAG检索 chunk → 拼上下文 → 临时回答NotebookLM资料理解 → 检索排序 → 上下文组织 → 可信知识产品Nexus企业数据 → Context Compiler → Knowledge Artifact → Agent 查询使用再往前看Karpathy 提出的 LLM Wiki 也是这个方向。LLM Wiki 的核心观点是传统 RAG 最大的问题是每次回答都在临时拼答案知识没有被持续沉淀。更好的方式是让 LLM 持续读取资料、维护一个结构化 Wiki里面有实体页、主题页、交叉引用、矛盾点和综合结论。至此大家应该对 Nexus 有了初步印象这里再补一句NotebookLM 是一个面向用户的 AI 知识库产品LLM Wiki 是一种知识组织架构/方法论Nexus 是 Pinecone 面向企业 Agent 应用推出的“知识基础设施层”。Nexus 的野心是有点大的他试图把企业数据提前编译成任务可用的知识资产再通过统一查询接口交给 Agent 使用这里大家可能不太理解Nexus 目标并不是更好的 RAG而是想成为 Agent 时代的 Knowledge Infrastructure。从我们现在的知识框架来说这三个东西分别对应 Agent 系统里的三块核心能力会调用什么工具会按照什么流程做事能稳定拿到什么知识MCP 解决的是第一个问题工具如何被 Agent 发现、调用、连接。Skills 解决的是第二个问题人类已有工作流、操作习惯、执行步骤如何迁移给 Agent。Nexus 想解决的是第三个问题企业知识如何被 Agent 稳定、低成本、可治理地使用。我们之前常说的 Agentic RAG Nexus 可能就是其中一种实现至于这一切是如何实现的有个关键词编译知识。编译知识编译知识这个词听起来有点玄但如果你是程序员应该很好理解。我们写代码的时候不是每次运行程序都重新理解一遍源代码而是会经过编译、构建、打包形成可执行产物。传统 RAG 的流程是每次用户提问 ↓临时去文档里搜索 ↓临时找上下文 ↓临时让模型理解 ↓临时生成答案Nexus 想表达的流程是企业原始数据 ↓提前解析、清洗、结构化 ↓围绕任务生成 Knowledge Artifact ↓Agent 查询时直接使用也就是说它把大量工作从运行时前移到了构建时这种编译知识的好处是提前结构化提前消歧提前绑定来源提前做好权限提前形成任务视图提前沉淀可复用资产这里核心想解决的是怎么让 Agent 在企业复杂任务中稳定、低成本、可治理地使用知识。值得注意的是编译知识是一个美好的愿望暂时来说 Nexus 也没有被大量使用他更像是一种在 AI 知识库上新技术范式的尝试概念很清晰官方给了典型案例和早期效果数据但真实大规模落地案例还不多。这里有个官方案例我这里做下详细说明大家可以感受下我们从产品/技术范式出发Nexus 的使用方式可以拆成四步第一步接入企业数据第二步定义 Agent 任务第三步编译 Knowledge Artifact第四步Agent 查询并使用结构化知识这里第二步、第三步对于企业来说都是黑盒任务定义企业大概率还得参与而知识编译由 Nexus 这类平台黑盒完成。意思是他内部怎么抽实体、怎么建关系、怎么生成 Knowledge Artifact我们是不知道的因为这套范式不稳定我们重点看看 Agent 知识查询这块官方案例# 企业开发者更可能做的是配置而不是手写知识编译逻辑nexus_project NexusProject.create( namesales_agent_knowledge, data_sources[ salesforce, gong, slack, gmail, jira, confluence ], scenariosales_agent, tasks[ customer_360, deal_brief, competitor_signal, next_step_recommendation ], policies{ rbac: True, pii_masking: True, field_level_citations: True })# 下面这一步大概率是平台黑盒完成nexus_project.build_artifacts()# Agent 运行时只负责查询result nexus.query( scenariosales_agent, taskdeal_brief, entity{ customer: Acme Corp }, output_formatstructured, include_citationsTrue)喷两句好了都已经到这了大家应该会感觉内容有点空那确实很空因为这东西还很不成熟而就是这么不成熟的东西很多人看了都会想去做一个什么Knowledge Engine…先说要不要再说能不能暂时当然是不要其次 Nexus 代表的是一个可能的高级方向但并不代表普通企业今天就应该照着做并且多数公司也做不了毕竟做向量数据库还是需要一些门槛的而且现在很多企业连最基础的知识治理都没做好他们资料散落在 飞书文档、 企业微信、 微信群、 PDF、 PPT、 Excel、 CRM、 客服聊天记录、 销售个人电脑、 老板脑子里 …然后这些资料本身还充满问题版本冲突、内容过期、口径不一…如果企业内部连文档在哪、两个相同的文档哪份资料是最新版都说不清那就算给你 Nexus你也很难用好。那么问题来了对于 Nexus 这种东西普通企业真正该关注什么我觉得是关注趋势以及吸收一些方法论比如 AI 知识库建设的方法论因为 Nexus 本身未必会成为最终答案但它释放出来的信号很明确AI 知识库正在从检索系统走向知识工程系统。Agentic RAG现阶段 AI 知识库的主线确实正在沿着黑盒化知识引擎这个方向演进。这个未必是我们技术人期望的技术主线但一定是各个基模/向量库企业想要做的事情因为这样的话他们收益足够大。这个事情的背后不会简单等于把数据丢进去什么都自动解决而是会经历一个从 RAG 工具链 → 产品化 RAG → Knowledge Engine → Agent Knowledge Infrastructure 的过程事实上这也是之前我们常说的一个名词 Agentic RAG只不过后面大家渐渐不用了因为 Agentic RAG 这个词有点泛化了没有最佳实践甚至没有稳定的定义。有些人说 Agentic RAG指的是模型自己决定要不要检索模型自己生成多个 query模型自己反复检索模型自己判断资料够不够模型自己根据结果继续查这是在传统 RAG 上加了一层 Agent 调度解决的是检索流程更灵活。但效果有点差而且**企业私有知识如何被稳定、低成本、可治理地使用**这个问题没有被很好的回答。Manus、OpenClaw、Hermes 这类 Agent 产品的关注点会放在 Harness他包含了 任务拆解、 工具调用、 浏览器操作、 代码执行、 多 Agent 协作、 上下文管理、 权限控制、 执行观测…于是黑盒知识库产品的架构设想或者产品设想出现了而且大概率会出现只不过不能解决所有问题这种产品大概长这样企业把数据源接进去 ↓系统自动解析、清洗、去重、结构化 ↓系统自动建立多种索引和知识 artifact ↓系统自动处理权限、引用、版本、冲突 ↓应用或 Agent 通过 API 查询 ↓返回的不是 chunk而是任务需要的结构化知识这就是 Knowledge Engine as a Service这跟之前的 Dify、Coze 里的知识库不太是一类东西一个是面向应用开发者的 RAG 配置工具另一个是面向企业 Agent 的知识基础设施举个例子NotebookLM 现在更偏 2C 的 AI 知识库产品但 Google 已经有 NotebookLM Enterprise官方介绍里已经包括企业级共享 notebook并且文档里也有创建 notebook、添加 sources 的 API 说明。NotebookLM 这类产品如果继续往 2B 走确实可能变成企业上传资料/接入数据源然后通过 API 消费知识的基础设施。AI 知识库会越来越像这样你只需要告诉系统这些资料是什么哪些人可以用这个知识空间服务什么任务返回结果需要什么结构哪些结论必须可引用哪些问题必须拒答或转人工。至于底层是向量检索、关键词检索、图检索、树检索、rerank、多 query、long context用户不应该关心。所以回到最开始那个问题RAG 时代真的终结了吗那当然是没有的学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】