受今年小龙虾 OpenClaw 热潮影响AI 办公领域得到了长足的发展数字员工、超级 AI 员工、员工蒸馏等概念层出不穷。随着企业老板在 AI 侧的**“认知提升”**AI 在业务侧的应用变得更丰富最大的特点是由去年的工作流类项目为主变成了现在的 AI 知识库这也说明很多企业逐渐进入了深水区。但是不同于工作流类项目AI 知识库类项目难度会更高很多企业在这块付出了不低的试错成本所以今天我们尝试系统性的介绍下各种 AI 知识库技术范式让大家更为了解其特点范式一模型原生与上下文直载直接与模型对话依旧是现在最常用的交互模式。知识直接进入模型参数在调用时整体放进上下文并不一定需要外部检索系统。最常见的 Coding Agent 就是这种模式这也给大家提了个醒SFT、RL等后训练技术其实是正确的技术路径只不过因为成本问题不被应用层接受而已。范式二Naive RAG这是经典的线性 RAG就是大家熟悉的那套文档解析 → 文档分块 → Embedding → 向量数据库 → 相似度检索 → 拼接上下文 → LLM生成原始 RAG 确立了模型参数知识 外部非参数知识的最基本架构也是最经典的架构后续很多架构都是在这个框架下做优化。他同时几乎将向量数据库技术等同了 RAG只不过其实 RAG 并不是非向量库不可而且这个阶段的架构是很粗糙的他会暴露出很多问题用户问题和原文措辞不一致Chunk切断上下文相似度高不代表答案相关跨文档、多跳问题表现较差检索结果缺少验证数据更新后可能存在脏索引…为了解决这些问题下一个范式就产生了与其说是新范式不如说是缝缝补补范式三Advanced RAGAdvanced RAG 围绕检索前、检索中、检索后三个阶段做优化Naive、Advanced 和 Modular 的分类已经被主流 RAG 综述广泛采用。这里主要的优化动作如下检索前优化查询重写、查询扩展、查询分解、HyDE、意图分类检索过程优化多路召回、分层检索、Hybrid Search检索后优化LLM Reranker、证据聚合、去重…依旧类似的缝缝补补衍生范式四Modular / Reasoning RAGModular RAG 是针对传统 RAG 系统僵化、难以应对复杂需求的问题提出的新范式。Modular RAG 将 RAG 系统拆解为索引、预检索、检索、后检索、生成、编排等独立模块并进一步细化为更细粒度的操作符如查询改写、重排序、路由等。Modular RAG 和 Advanced RAG 相似度较高但真要去区分又没必要所以大家看看就好类似是实现还有 Self-RAG、Adaptive RAG 等但实际真的用得好的还是范式三Advanced RAG通俗易懂。范式五Structured Data RAG从这里开始知识库开始切入各个企业真实业务因为企业知识很大一部分存在于 CRM、ERP、工单系统 等系统。向量检索不适合回答某客户最近三个月付款多少这类精确问题于是核心实现就变了自然语言问题 → 意图和实体识别 → 选择数据库或API → 生成SQL/API参数 → 权限校验 → 执行查询 → 结果校验 → LLM解释Text-to-SQL 是这条链路中最核心的技术类似的名称还有 Table RAG、API RAG…总之在 AI 知识库的体系中结构化数据 RAG 属于一个极其重要的分类他的成熟度直接决定了 AI 知识库从闲聊问答升级为业务决策助手的深度。范式六GraphRAG、Ontology 与 KAG这一大类可能存在三层经典组合层次解决的问题典型结构知识图谱业务事实如何连接实体、关系、属性、事件本体业务世界如何统一表达类、谓词、约束、继承、状态规则与推理哪些结论可以推出规则、路径、逻辑、适用条件知识图谱是事实层本体是语义约束层规则引擎是推理层。这类方案特别适合法律、医疗、金融、工业制造等关系复杂且规则不可随意违反的领域也是当前知识库技术路径的当红炸子鸡。范式七Agentic RAG到范式七整个系统实现就有点玄妙了Agentic RAG 属于运行时控制架构。它可以把向量库、SQL、知识图谱、Web、Wiki 和 API都当成工具。Agent需要动态完成判断是否需要知识分解任务选择知识源生成检索条件阅读和评价结果发现信息缺口继续检索或者更换工具交叉验证决定停止、回答或者转人工。关于 Agentic RAG 这个词我也听得非常多但实际工作中居然没见着说实话现在我都无法很好的定义他我理解的 Agentic RAG 其实就是 Agentic Workflow所以整个这块存疑我还得再研究…范式八LLM Wiki然后就是 LLM Wiki 了他最近跟 Obsidian、WorkBuddy 等配合也算得上风生水起这套范式属于文件原生、持续编译、可维护的知识工程范式。看上去很高级大家直接称他为懒人知识库即可这东西的出现就是为了把我们从数据处理解放出来只不过效果就见仁见智了…这里值得深究的是LLM Wiki 和我们刚才提到的所有 RAG 变种底层逻辑有本质不同或者说这套架构将传统 RAG 进行了工程化包装前面七种范式是在查资料而 LLM Wiki 是在建 wiki传统 RAG无论是 Naive 还是 Agentic都是临时拼接每次提问模型都在从碎片化的资料里现拼答案知识用完即走没有沉淀。而 LLM Wiki 的思路是让 LLM 提前把资料编译成一个结构化的 Wiki 系统持续维护实体页、主题页、交叉引用甚至自动标记不同资料间的矛盾点。这带来两个显著变化从问答升级为研究用户不再只是提问而是拥有了一份知识资产。从根本上缓解 RAG 的碎片化痛点因为答案不是临时拼凑的而是基于已经梳理好的知识结构生成的引用和溯源的稳定性会大幅提升。当然这套范式眼下最大的门槛在于编译成本和时效性但如果我们真的希望 AI 知识库能成为企业的长期记忆LLM Wiki 可能才是更接近终局的路径。这或许也正是像 NoteBookLM 这类产品在暗处持续努力的方向但他很难的要做好这块需要前期数据管理得很好我觉得可能不亚于做微调了…其实前面的八大范式介绍只有做过的人才会有感受如果没有做过是没有感受的。如果要让大家有感受就必须进入场景映射这里我们就用最初说的员工蒸馏概念做说明员工蒸馏所谓员工蒸馏即是对个人乃至群体的某一段工作内容的 100% AI 化替代那么如何实现员工蒸馏呢答案是将员工关于某项工作任务的认知也就是我们常说的 KnowHow 形成 SOP 与数据所以员工蒸馏 将员工某一段 KnowHow 程序化而 KnowHow 又可以被拆解为 SOP/Workflow 和 Data。这里就会出现两个核心指标SOP复杂度或者叫Workflow复杂度x 数据复杂度数据量、数据结构SOP 复杂度这里对SOP的描述不用非常复杂大家就按高中低来理解就行第一所谓低SOP就是个人流程几步就可以走完那种工作流。典型的场景是身份证、简历信息识别公众号文章生成.skill或者查询AI率的工具。这种SOP要形成往往问某个人就搞清楚了沟通成本比较低。第二是中SOP大家可以简单理解成两种单人SOP步数很长或者需要多人协作那种工作流。典型场景是HR招聘流程、销售线索分配流程一整套公众号文章编写发布流程。这种SOP收集整理难度会显著提升要么需要跟一个人聊很久或者需要跟多人反复沟通但整体来说复杂度依旧不难。第三是高SOP这个往往是非常复杂的流程了可能会形成回路步数呈网状结构会有回退步骤或者就是参与的人极多。这里典型场景就是我们之前做的电商企业全案业务AI化SOP了。而因为这种SOP会涉及多人、多部门整理起来的复杂度是最高的并且他的更新复杂度更高很多公司都很容易出现做好一套AI系统后由于组织结构变了导致系统无法使用而放弃的情况究其原因还就是SOP复杂度太高的原因所致。所以如果没有专门团队在维护这套系统这种公司往往是没办法用起来的这也是追求AI原生路上最容易发生的情况。数据复杂度然后就是数据复杂度了数据是行业 KnowHow 的经验数字化他是为了配合 SOP 而出现的行业里面处理数据这块的工作被称为数据工程数据工程的任务是用数据去理解或者解释真实的业务世界所以这块可能很难。我们按高中低无四个等级来划分第一是数据无也就是没有私有数据需求或者私有数据极少放到提示词中就完事了模型当前材料已经足够完成任务了。这里往往用最基本的提示词工程功底就能拿到不错的结果比如做翻译这种工作。这里也需要强调的是其实这里也不是不需要知识而是知识已经被内化进了模型我们在后续微调技术路径的时候会提到。第二是数据中这种开始需要调用私有数据了但往往数据量较小处理起来很简单。比如大家案例里面的历史考题和 RAG 都是这个复杂度的数据一般来说 RAG 就可以完全消化不需要对数据怎么做特殊处理。第三是数据高这个场景需要多数据源了比如做一个客户全景档案就需要从 CRM、投诉客服系统、付款系统等不同地方拉数据。这种东西构建复杂度也要高些可能会涉及各种SaaS系统混用。第四部分数据复杂度极高也就是今天会涉及的部分这个场景中数据之间是存在关联关系的可能会用到知识图谱这种技术维护、更新成本极高这个时候我们再从蒸馏的角度去填这个12象限他是这样的接下来就是具体的场景映射了场景映射前面一口气说了八种范式又说了员工蒸馏的本质但这没用企业最初也搞不懂什么是 SOP 复杂度与数据复杂度啊他们只关注一件事我现在到底该用哪一种这个时候前面说的SOP复杂度和数据复杂度才有意义。大家可以把那张12象限的图竖着看也可以横着看**横着看是数据。**数据越来越复杂技术路径大概就是模型原生知识、普通RAG、多系统数据、知识图谱与本体。**竖着看是SOP。**SOP越来越复杂技术路径大概就是提示词和脚本、Workflow和Skills再往后是Agent。所以企业判断问题时可以先记住两句话AI 答不对看数据AI 做不完看 SOP一、数据复杂度举个最简单的例子如果你只是让 AI 写文章、做翻译、写代码、整理会议纪要其实根本没有必要做什么知识库。模型已经知道这些知识最多上传几份参考资料写一个 Skill把你的要求固定下来就完事了。现在很多企业一上来就要做 RAG、向量库、知识图谱我有时候也不知道他们到底在折腾什么。最后文档切了几万段向量库也装好了实际效果还不如直接把文件丢给模型。什么时候会发生变化呢当企业开始有自己的产品资料、制度、合同、FAQ和历史案例了这时候才轮到RAG。比如老板说我们有几千份产品资料能不能做一个AI客服这个场景很典型问一句、答一句SOP很简单数据也就是一批扁平文档用RAG就对了。刚开始可以用Naive RAG快速跑通但如果要上线最后大概率还是要做到Advanced RAG。因为用户不会按照产品手册里的标准术语提问会有错别字会有指代会连续追问文档分块还可能把一句完整的话切成两半。于是查询重写、意图识别、混合检索、Rerank、置信度判断、引用溯源和转人工一个都跑不掉。这也是我为什么认为大多数企业当前最值得做的依旧是Advanced RAG先把文档问答做好把常见问题覆盖掉把拿不到、拿不准、拿太多的问题解决掉已经能产生很大的业务价值。没必要看到GraphRAG火了就急着给自己的产品手册建一张图谱。但接着老板又会问能不能顺便帮我查一下这个客户最近买了什么他的订单到哪里了上个月一共付了多少钱到这一步继续调Embedding和Rerank已经没什么用了。因为订单、金额和客户状态根本不在产品文档里它们存在CRM、ERP、订单和财务系统中。这时候需要的是Structured Data RAG说得再直接一点就是Text-to-SQL和API调用。制度、手册和FAQ可以通过RAG查询订单状态应该调用订单系统客户付款金额应该查询数据库退款操作应该调用业务接口。**很多企业知识库做到后面效果很差就是因为他们想用一个向量库或者模型本身解决所有问题。**产品说明扔进去、订单数据扔进去、用户反馈扔进去、经营报表也扔进去最后模型查到一堆相似文本却回答不了一个精确数字。到了多系统数据这一步项目难点已经不只在AI了。数据口径、系统接口、权限隔离、身份识别、数据回写都会冒出来。然后还有一些更麻烦的场景。比如律师问这个主体在合同里承担了哪些义务违反某一条款后会触发什么责任医生问这个患者正在使用的几种药物之间有没有冲突当前病情是否命中某个禁忌证。这类问题的答案往往不在某个独立段落里它藏在实体关系、适用条件和专业规则中。这时候普通RAG就开始吃力了因为它擅长寻找相似内容却很难稳定还原整个业务世界。企业确实走到这一步才需要考虑知识图谱、本体、KAG和规则引擎。知识图谱负责保存患者、症状、疾病、药物之间的具体事实本体负责定义这些对象属于什么类型、允许建立什么关系、状态如何流转规则引擎则负责执行那些不可随意违反的硬约束。从大模型舒适度来说这种带关系的数据是他最舒服的区间但我要再次提醒图谱和本体都很贵画一张实体关系图很简单让医生、律师或者业务专家长期配合你整理知识解决不同部门之间的口径冲突还要保证数据持续更新这些工作才麻烦。所以只有当业务判断确实依赖关系、规则和多跳推理并且普通RAG已经明显撑不住时企业才有必要进入这条路。说实话大多数企业走到Advanced RAG加SQL/API这一层已经够用了。二、SOP 复杂度上面说的主要还是数据接下来再说SOP。假设AI客服已经能够准确查到退款政策也能查询订单状态但用户要真的办理退款时它却不知道先核验什么什么时候补充材料哪个条件需要转人工接口失败以后又该怎么办。这种情况继续折腾知识库没有用因为AI已经知道了问题出在它不会做。企业这时候需要梳理SOP直接清晰的告诉AI先核验订单 → 判断退款条件 → 收集必要材料 → 调用退款接口 → 写回工单 → 通知用户 → 异常情况转人工流程相对稳定就用Workflow固定下来SOP数量太多、变化比较频繁可以把它们写成Skills执行路径很难提前列完整再让Agent根据现场情况选择工具和下一步动作。所以我一直对Agentic RAG这个词有点疑问。因为在实际工程里面我看到的往往是Agentic Workflow。Agent负责拆任务、选工具、补信息和做判断RAG、SQL、API、Web和图谱负责提供每一步需要的数据。所谓Agentic RAG落地以后大概率就是**Agentic Workflow 多种数据工具。**从这个角度来说我根本不知道哪里会再出现Agentic RAG了…最后就是大家最喜欢讲的数字分身、数字员工了这类项目位于整个矩阵的右上角SOP极其复杂数据也极其复杂。它既要有文档知识库又要查询数据库和业务系统既要理解实体关系和专业规则又要完成多轮任务规划、工具调用最后还要处理权限、转人工和错误回流。到这里已经没有什么单一技术范式可以解决了。RAG要用SQL和API要用图谱和本体可能要用Workflow和Skills也要用必要时还要上Agent和Multi-Agent…这里一时间大家也遇不到我们这里就不赘述了。结语写到这里前面介绍的八种知识库技术范式也就可以全部收回来了。企业表面上是在选择RAG、GraphRAG、Agentic RAG、LLM Wiki落到具体项目里最后都要回答同一个问题AI执行SOP的每一步时究竟需要拿到什么数据这些数据又该如何组织SOP比较简单数据也比较扁平普通RAG就能解决SOP开始变长AI需要查询多个系统Workflow、Skills、SQL和API就要加入当一次判断同时依赖多个实体、历史状态、关系链和专业规则时知识图谱、本体和规则引擎才会逐渐出现。学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%免费】