本文系统性地介绍了AI知识库的八种技术范式包括模型原生、Naive RAG、Advanced RAG、Modular/Reasoning RAG、Structured Data RAG、GraphRAG、Ontology与KAG以及LLM Wiki。通过深入分析不同范式特点结合SOP复杂度与数据复杂度为企业提供了选择合适技术路径的参考。文章强调企业应根据自身业务需求合理运用RAG、SQL、API、图谱等技术实现AI知识库的有效构建与应用。受今年小龙虾 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这个词有点疑问。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取