受今年小龙虾 OpenClaw 热潮影响，AI 办公领域得到了长足的发展，数字员工、超级 AI 员工、员工蒸馏等概念层出不穷。
随着企业老板在 AI 侧的“认知提升”，AI 在业务侧的应用变得更丰富，最大的特点是：由去年的工作流类项目为主变成了现在的 AI 知识库，这也说明很多企业逐渐进入了深水区。
但是，不同于工作流类项目，AI 知识库类项目难度会更高，很多企业在这块付出了不低的试错成本，所以今天我们尝试系统性的介绍下各种 AI 知识库技术范式，让大家更为了解其特点：
范式一：模型原生与上下文直载
直接与模型对话依旧是现在最常用的交互模式。
知识直接进入模型参数，在调用时整体放进上下文，并不一定需要外部检索系统。
最常见的 Coding Agent 就是这种模式，这也给大家提了个醒：SFT、RL等后训练技术，其实是正确的技术路径，只不过因为成本问题不被应用层接受而已。
范式二：Naive RAG
这是经典的线性 RAG，就是大家熟悉的那套：文档解析 → 文档分块 → Embedding → 向量数据库 → 相似度检索 → 拼接上下文 → LLM生成
原始 RAG 确立了模型参数知识 + 外部非参数知识的最基本架构，也是最经典的架构，后续很多架构都是在这个框架下做优化。
他同时几乎将向量数据库技术等同了 RAG，只不过其实 RAG 并不是非向量库不可，而且这个阶段的架构是很粗糙的，他会暴露出很多问题：
用户问题和原文措辞不一致 Chunk切断上下文 相似度高不代表答案相关 跨文档、多跳问题表现较差 检索结果缺少验证 数据更新后可能存在脏索引 ...
为了解决这些问题，下一个范式就产生了，与其说是新范式，不如说是缝缝补补：
范式三：Advanced RAG
Advanced RAG 围绕检索前、检索中、检索后三个阶段做优化，Naive、Advanced 和 Modular 的分类已经被主流 RAG 综述广泛采用。
这里主要的优化动作如下：
检索前优化，查询重写、查询扩展、查询分解、HyDE、意图分类； 检索过程优化，多路召回、分层检索、Hybrid Search； 检索后优化，LLM Reranker、证据聚合、去重......
依旧类似的缝缝补补衍生：
范式四：Modular / Reasoning RAG
Modular 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 深度学习感兴趣的可以点击：
