从简单 RAG 到本体论

我们这里先说说员工蒸馏，今年年初时候小龙虾热潮里，大家最喜欢说的就算员工蒸馏。

什么毛选.skill、什么张雪峰.skill、还有傅盛大佬龙虾员工大军：《傅盛龙虾日记：24 小时，我用 AI 干了 6 个人三周的工作》

对吧，这里他们到底是在说个撒？OpenClaw 到底解决了什么类型的问题、又遗留了什么类型的问题，而为什么我们感到如此熟悉又陌生呢？

这里就不得不提到底什么是员工蒸馏了，什么是员工蒸馏？

我认为是对个人乃至群体的某一段工作内容的 100% AI 化替代，这就是员工蒸馏，现阶段这也是很多 AI 原生的追求

具体来说如何实现员工蒸馏呢？答案是将员工关于某项工作任务的认知，也就是我们常说的 KnowHow 形成 SOP 与数据。

这里我们总结一下：员工整理 = 将员工某一段 KnowHow 程序化；而 KnowHow 又可以被拆解为 SOP/Workflow 和 Data

所以，这里就会出现两个核心指标：SOP复杂度（或者叫Workflow复杂度）x 数据复杂度（数据量、数据结构），我们这里来依次做下拆解。

这里对SOP的描述不用非常复杂，大家就按高中低来理解就行： 第一，所谓低SOP，就是个人流程，几步就可以走完那种工作流。

典型的场景是身份证、简历信息识别，公众号文章生成.skill，或者查询AI率的工具。

这种SOP要形成往往问某个人就搞清楚了，沟通成本比较低。

第二是中SOP，大家可以简单理解成两种，单人SOP步数很长或者需要多人协作那种工作流。

典型场景是HR招聘流程、销售线索分配流程，一整套公众号文章编写发布流程。

这种SOP收集整理难度会显著提升，要么需要跟一个人聊很久，或者需要跟多人反复沟通，但整体来说复杂度依旧不难。

第三是高SOP，这个往往是非常复杂的流程了，可能会形成回路，步数呈网状结构，会有回退步骤，或者就是参与的人极多。

这里典型场景就是我们之前做的电商企业全案业务AI化SOP了。 而因为这种SOP会涉及多人、多部门，整理起来的复杂度是最高的，并且他的更新复杂度更高，很多公司都很容易出现做好一套AI系统后，由于组织结构变了导致系统无法使用而放弃的情况，究其原因还就是SOP复杂度太高的原因所致。

所以如果没有专门团队在维护这套系统，这种公司往往是没办法用起来的，这也是追求AI原生路上最容易发生的情况。

然后就是数据复杂度了，数据是行业 KnowHow 的经验数字化，他是为了配合 SOP 而出现的，行业里面处理数据这块的工作被称为数据工程，数据工程的任务是用数据去理解或者解释真实的业务世界，所以这块可能很难。

我们按高中低无四个等级来划分： 第一是数据无，也就是没有私有数据需求，或者私有数据极少，放到提示词中就完事了，模型当前材料已经足够完成任务了。

这里往往用最基本的提示词工程功底就能拿到不错的结果，比如做翻译这种工作。

这里也需要强调的是，其实这里也不是不需要知识，而是知识已经被内化进了模型，我们在后续微调技术路径的时候会提到。

第二是数据中，这种开始需要调用私有数据了，但往往数据量较小，处理起来很简单。

比如大家案例里面的历史考题和 RAG 都是这个复杂度的数据，一般来说 RAG 就可以完全消化，不需要对数据怎么做特殊处理。

第三是数据高，这个场景需要多数据源了，比如做一个客户全景档案，就需要从 CRM、投诉客服系统、付款系统等不同地方拉数据。

这种东西构建复杂度也要高些，可能会涉及各种SaaS系统混用。

第四部分，数据复杂度极高，也就是今天会涉及的部分，这个场景中数据之间是存在关联关系的，可能会用到知识图谱这种技术，维护、更新成本极高

这个时候，我们再从蒸馏的角度去填这个12象限，他是这样的： 那么如何去更好的理解这一切呢？我们最经典案例又来了，这里会涉及到 Agentic Workflow 以及 知识库技术路径的几次迭代：

你本科时期是一名软件工程师，硕博读的是法律专业，毕业后从事律师工作，并且偶尔会接点软件外包。现在你遇到了一个问题：

你平时一天能接待100名客户，但现在每天有1000个客户需要处理，其中多数都是很简单的情况，需要你亲自处理的人不到100个，所以该怎么办呢？

在AI之前，这里唯一的策略就是加人，比如加入律师助理或者实习律师，但在AI时代，解法逻辑变了。

我们首先来看你掌握的能力：

1. 你具有工程能力；

2. 你具备法律服务的KnowHow，能够梳理清楚法律咨询需要的一套SOP/Workflow；

在这一步里面，最困难的工作不是代码，而是如何将自己的SOP/Workflow整理清楚，一般人在这块是很难的。

在你将SOP梳理清楚后，很快做了一套针对法律咨询的AI客服出来，它至少可以解决600个客户的问题，因为多数客户咨询的都是一些简单问题，或者只是希望获得一个初步判断，比如：

1. 我被公司辞退了，可以要求多少赔偿；

2. 我的租房合同还没到期，现在想提前退租，有什么需要注意的吗；

3. 我收到了一份合作协议，里面有几个条款看不懂，能不能帮我看看；

可以看出，这里没有什么额外的数据需求，完全依赖模型内置知识就够了，但是这里依旧出现了问题：

1. 第一是，你的AI客服偶尔会出现幻觉，这会导致错误的法律建议；

2. 第二是，你的AI客服在某些场景下运行不好，导致流程难以走下去，比如在法律依据和处理方案推荐这里，就喜欢引用一些已经失效的规定，或者忽略不同地区的司法差异。如果这些问题解决了，至少可以解决800人的问题；

3. 第三是，你的一些特有的案件研判知识乃至谈判、诉讼经验，无法在AI客服中产生影响；

为了解决这些问题，你开始有意识地整理独有数据，以及错误数据，于是形成了一套自己独立的小数据集，整个产品进入第二阶段。

PS：这里整个推衍逻辑是共用的，就算放到医疗、教育领域也是一样：

这一步其实很简单，你用了一些RAG技术，将自己的简单数据集融入了原本的工作流里面。

这里的目标是：能用自己的知识干预流程、能用自己的知识干预解决方案、能用自己的知识降低模型幻觉。

在这一步里面，相对于工作流AI，难点开始变多了：

1. 首先是整理什么数据，这个很难，多数人搞不清楚什么数据是有用的；

2. 其次数据倒是整理出来了，它应该是个什么结构，这个也很麻烦，需要不断地试错；

3. 最后就是用什么技术架构去承载这一切，这里比纯工作流难的点在于SOP会被数据所影响；

只不过，你要面对的场景较为简单、数据量也不大，直接上最朴实的那套RAG就好，很快就搞定了，于是你可以很好地服务900个用户了，真是可喜可贺！

到此为止，执行的都是简单SOP，根本没体现Agentic Workflow的能力。这里虽然用到了私有数据，但更多的工作是简单检索，其实很简单。

但是问题又出现了：你老婆是劳动法律师、你小舅子是知识产权律师、你小姨子是公司并购律师，他们看你服务那么多客户，于是也想要用，这个时候该怎么办呢？

于是乎，我将自己的代码做了一层抽象，将我的SOP与Data提炼了出来。这部分的代码没那么难，我很快就形成了一套Agent框架，或者叫Agent工厂。只要使用这套Agent平台，就能很快地将自己的SOP和Data上传上去。

这个东西对于我来说，几乎没有难度，因为它只需要工程能力，不需要我具备各个法律领域的KnowHow，更不需要特别的数据，它只需要我留出SOP编排的界面以及Data上传的地方即可。在这里我沾沾自喜，因为我还将编排做成了图形化，小姨子他们自己想怎么拖就怎么拖！

但是马上问题就出现了，小姨子他们并不开心，因为他们看着那个编排SOP的界面就烦。他们首先不想梳理自己的SOP，其次更不愿意去编排，最后让他们去设置数据和SOP的交互，几乎要了他们的命！

并且情况更糟糕了，律所主任对我赚钱的事情很眼红，他要让律所所有业务团队接入我的系统，并让我搞定......

于是没有办法，我放弃了本来的律师工作，被转到了律所的信息技术与知识管理部门，每天拿着电脑帮各个业务团队的律师梳理SOP、整理数据，并教他们如何使用系统。

并且，我在平台上加入了很多插件，比如实时法律法规插件，用于调取最新的法律法规，也防止引用已经失效的条款；比如类案检索插件；比如接入一些最新的司法解释和裁判文书，让整个平台的幻觉率降低……

只不过做到后面，我发现一个问题，我们这个平台跟Coze长得有点像...

但问题依旧存在，各个业务团队的律师依旧没办法改动SOP，也没办法处理最新的数据，这些工作依旧要我协助完成，这让我感到很无奈！

我这边真实案例就是，之前一个兄弟，他们是做客服的，最后那个Workflow流程自己都维护不动了：

注意，这里是产研人员都维护不动，遑论没有基础的业务人员。这个也是很多我实际服务过的公司正在遭遇的问题：

Workflow是真的解决了问题，但当Workflow变复杂后，当团队Workflow数量变多后，每改一个就很麻烦，到这里各种工程问题就出现了

当环境复杂度上升，Workflow的成本曲线会很难看：

其实大家的诉求很简单：

1. 第一是不想去整理SOP，但如果非要整理，这个他们可以克服；

2. 第二是一定不想去编排SOP，这对他们简直是一种折磨；

3. 第三是数据处理这块，几乎不可能学会；

所以，在这个背景下，我希望利用AI的能力，提升Workflow的泛化能力。也就是在我积累了足够多的SOP后，我希望用自然语言就能让AI生成符合要求的SOP，而就算不满足，也能用自然语言去调整、优化，不需要再去拖那个蜘蛛网。

于是乎，我改了下程序框架，引入了ReAct框架，也就实现了一句话生成完整SOP的效果： 只不过问题又来了，这次的问题有两点：

1. 这家伙实现得不太稳定，每次生成的SOP都不一样，并且它是个黑盒，就算出了问题我也不能改；

2. 然后就是因为它是个黑盒，本来我有些特别的SOP也无法注入进去，这个就很难受了；

反正结果就是，大家依旧不满意，原因也就是上面说的两点：

1. 第一，不稳定；

2. 第二，不能干预，不具备可观测性；

于是乎，我陷入了两难。所以说，他们需要Workflow，但又不想维护Workflow，那他们到底要不要Workflow呢？

他们当然是要Workflow的，但他们不想去拖拽，他们想用自然语言做表达. 于是我在工程架构上做了很多尝试，最终实现了一个叫Skills的技术，可以让大家用自然语言在Markdown里面描述工作流。

这里造成的结果就是，程序中最重要的80%的业务，被我几个Skills搞定了，其他的部分直接使用Agentic Workflow的方式就好。对于那部分的稳定性我要求不高，于是乎整个问题得到了解决，大家都很高兴。

只不过这里最后还遗留了一个最大的问题：数据该如何处理？

这个数据该如何处理，就是现在整个AI世界留下的最大工程课题了！

至此，我们可以看出来，Agentic Workflow是成立的，但Agentic RAG我们还没看到。而上述的每个场景都属于员工蒸馏，而且都是简单场景的员工蒸馏，因为上述都不涉及图谱。

那么什么是复杂的员工蒸馏呢？这里就要涉及数据工程与图谱或者本体对应的技术范式了：

我们前面说了，数字分身、员工蒸馏类项目最重要的就是KnowHow，而KnowHow被分为了两个部分：

1. 显性化的SOP

2. 结构化的数据

而这里的难点就来了，怎么保证SOP每一轮需要的数据被拿到，换句话说如何让AI拿到他应得的知识！

说人话就是，AI不仅要像我们一样去表达，还必须像我们一样去思考，如果AI不像我们那样去思考而得出的答案，那我是不信的。

要做到让AI像我们一样思考，好好执行这套SOP，这里的核心是如何组织数据，数据组织的背后就是技术架构或者说技术路径。

所以，今天最核心、最重要、最本质的问题来了，我们如果要实现一套管理数字分身，或者说蒸馏我管理相关的知识，我们这套SOP是什么样的，对应的数据结构应该是什么样的？

这里先说SOP对应的技术路径，也是我们之前探索出来最经典的技术路径：顾问范式，这套范式几乎可以解决80%复杂知识库的问题。

至于什么是顾问范式、如何构建本体论，今天的篇幅已经很多了，我们下次再讨论...

写到这里，我想回应一个现象。

最近确实有很多同行、客户在跟我聊本体论，聊知识图谱，聊实体关系建模，聊如何用更精妙的结构去逼近真实世界的复杂性。

大家的热情我能理解，毕竟，谁不想建一个一劳永逸的知识底座呢？

但我在生产线上摸爬滚打了几圈后，真实的感受是：本体论很好、知识图谱也很好，但它解决的是理得清的问题，而不是搞得定的问题。

也就是说，那部分知识确实能搞定问题，但你的团队却未必能用那些知识去解决问题，很多同学太小看本体论的复杂度了，这里面有大量的管理问题要处理！

一旦进入生产环境，你会发现，画出几张实体关系图，反而是整件事里最轻的一步。难点集中在后面几个环节。

第一，企业需要先把专业人员脑中的认知拿出来。

大量 KnowHow 并没有写在文档里，**专业人员很会处理问题，却很难解释自己为什么这样处理。**你让他直接整理知识，他交出来的通常是一堆资料、制度和案例，很少有人能主动拆出实体、关系、状态、规则和适用边界。

所以，知识梳理本身就是一项管理工程。你需要通过访谈、案例复盘、异常追问和结果验证，一点点把隐性认知逼出来，还要让不同岗位的人持续配合。

管理他们完成日常工作相对容易，让他们长期、稳定、结构化地输出自己的认知，难度会高很多，并且这里面是存在大量“文化/专业冲突的”！

第二，企业内部的知识经常存在冲突。

本体论的第一步是统一业务世界的表达方式：什么对象算同一个实体，什么关系可以建立，什么状态允许流转，什么条件下规则生效。这个过程往往会触碰部门边界、责任归属和历史流程，最后处理的已经不只是数据，还包括组织内部对业务事实的共识。

第三，真实世界可以无限建模，但项目预算和工程能力都是有限的。

实体类型越多，关系越复杂，工程实现成本越高；层级越深，知识整理、检索和维护的难度越大。生产级 AI 项目需要持续平衡业务还原度与数据工程 ROI

我实际做这类设计时，会非常克制地控制实体数量、关系数量和知识层级。

能够通过简单结构解决的问题，就不会为了追求完整而引入复杂模型。因为本体设计的目标是支撑业务任务，结构精妙只是手段，甚至于结构越复杂，工程复杂度越高，处理起来就很难。

第四，知识被整理出来以后，还要让 AI 用得上。

这就回到了我前面反复强调的那句话：

如何让 AI 在每一轮都能拿到、拿对、拿全，同时不拿多

你需要明确每个 SOP 节点依赖哪些实体、关系和规则，用户处于什么意图时应该进入哪条查询路径，信息不足时应该追问什么，关系链应该查询几层，什么情况下停止推理，什么情况下必须转交。

所以，知识结构必须与任务边界、SOP 和意图体系一起设计，这里很多经验是真的做过的，知道就知道，不知道就是不知道，不足为外人道也。

第五，本体和知识图谱还需要持续维护。

组织结构会变，产品会变，业务规则会变，专业人员对问题的理解也会变。今天正确的实体关系，半年后可能已经不再适用。企业如果没有专门团队维护，前期投入越大，后期形成的历史包袱也可能越重。

上述所有，就是复杂 AI 项目很少能够顺利落地的原因。它同时涉及知识工程、数据工程、模型工程、管理工程和项目管理工程。

你既要理解业务 KnowHow，又要懂数据结构和模型特性，还要有能力组织不同专业角色持续输出，并在漫长、反复的建设周期中稳住团队。

一般技术人员容易卡在业务抽象，高管又很难长期沉入实体、关系、规则和生产数据的细节。最后，大家都知道这件事很重要，却始终缺少一个能够把业务、数据、技术和组织贯穿起来的一号位。

在我做过的生产级 AI 项目里，这个一号位必须亲自完成核心产品和架构设计。代码可以交给团队写，但核心文档要接近伪代码的精度：任务边界是什么，实体如何定义，关系如何流转，每个节点调用什么知识，拿不到怎么办，拿错了怎么发现，生产问题如何回流。

文档写不到这个程度，下面的产品和技术很难凭空把它实现出来

这里再次强调，相信我，如果你文档写不清楚，程序员一定做不清楚，换什么AI都是一样

所以，当很多企业开始关注本体论和知识图谱时，我知道他们已经开始遇到传统 RAG 的边界了。但知道应该构建本体，只是走到了深水区入口。

后面还要回答：建什么、建多深、谁来整理、谁来维护、AI 如何调用，以及这套系统能否在生产环境里持续运转。