在2026年3月19日，DataFun技术社区组织了一场围绕“本体论与人工智能”的深度直播对话。主持人吕航飞（资深系统智能化架构师）与两位重量级嘉宾——上海银行数据管理与应用部智能研发平台负责人胡申民、阿里云智能集团高级研发工程师隰宗正，共同探讨了“如何用本体构建AI时代可信的数字世界”。
这场长达90分钟的圆桌讨论直面核心问题：为何从事银行风控和云运维的专家，最终都指向了Palantir倡导的“本体论”？在没有本体之前，数据究竟混乱到什么程度？如何将专家脑中隐性的经验转化为机器可理解的知识？大模型与本体应该如何分工？当AGI（通用人工智能）到来时，我们是否还需要费力构建本体？三位嘉宾凭借各自的实战经验，为我们勾勒出本体论在理想与现实之间平衡的真实图景。
为何殊途同归：Palantir背后的本体论
“Palantir最近非常火，它的核心逻辑就是为数据建立‘本体’。胡老师做银行风控，隰老师做云可观测，为什么最终都指向了Palantir的本体论？这个东西到底解决了什么共同痛点？”主持人吕航飞开场便抛出了这个尖锐问题。
隰宗正的回应直接切入本质：“这个问题问得特别好。我们做可观测，最初的思路是先收集数据，再从数据里推理系统状态。但实践中发现，数据是海量的、异构的、动态变化的。从这些数据中逆向推导真实世界的状态，本质上是一个极其困难的工程问题。”
他进一步阐述：“数据只是一种现象，现象和本质之间存在巨大的认知鸿沟。我们团队从2019年就开始做可观测的数据建模，经历了数据标准化、实体关联、知识表达、行动能力等多个阶段，逐渐意识到——出路可能不在收集更多数据，而在于构建更好的系统模型。”
隰宗正分析了Palantir的成功关键：“它的核心价值或许不仅在于AI算法本身，更在于底层的本体（Ontology）。我们提出的U Model其实与Palantir的设计理念一致——将图模型和IT世界的三大要素统一起来：数据层对应全域实体和观测数据，知识层对应专业知识和分析模板，行动层则定义自动化决策和操作。”
胡申民从金融视角给出了补充：“本体并非全新概念，80年代就有人提出数字孪生。为什么当前本体论又变得如此火热？”他点出了一个关键驱动因素：“本质在于，Palantir在2023年前市值并不突出。但它推出了名为AIP的关键组件，将传统的本体论思想与大模型能力结合，市值随之飙升。虽然我个人对其军事用途持保留态度，但其指导方法值得我们借鉴。”
胡申民解释了本体在当下的独特价值：“过去数字孪生未能普及，是因为构建复杂度太高，规模化应用太难。但一旦通过大模型加持，可以显著降低本体构造的复杂度，同时实现规模化应用。因此，Ontology这个词在当前技术浪潮下变得尤为关键。”
这段对话揭示了一个核心洞察：本体论之所以能在金融风控和云运维这两个看似迥异的领域产生共鸣，是因为它们都面临着相同的困境——在海量、杂乱的数据中，AI缺乏一张“认知地图”来理解世界是如何运作的。
数据的三重鸿沟：没有本体前的混乱
当话题转向具体业务痛点时，隰宗正用三个“鸿沟”概括了没有本体时的典型困境。
“第一个是数据的鸿沟，”他说，“原始数据往往混杂、碎片化、噪声极多。你会发现过来的日志或指标，99%以上是无效信息。当一个故障发生时，可能触发几十上百条告警，但这些告警散落在不同的监控系统里——指标在Prometheus，日志在SLS，链路在Trace APM。工程师首先要在不同控制台之间频繁切换，还需要凭借相当的专家经验去手动拼凑碎片，自己理解到底发生了什么。”
“第二个是模型的鸿沟，”隰宗正的语气变得严肃，“AI模型存在黑盒特性，推理过程有时难以解释，面对不熟悉的数据还经常出现幻觉。例如，有两个服务A和B同时出现异常，如果直接把数据喂给AI，它可能因为时间上的相似性，就判断A导致了B的失败。但实际上，它们可能都依赖于同一个底层服务。如果AI不知道这个先验知识，就很难从数据里正确理解因果关系。”
“第三个是工程上的鸿沟。我们每天大概会收到PB到EB级的数据采集，涉及大量的清洗、存储、计算工作，成本和安全性都是巨大挑战。”
胡申民则从金融视角补充了痛点：“过去我们建设数据仓库和大数据平台时，‘数据治理’这个词一直不绝于耳。但过去的数据往往不是给人看的，机器也难以识别。没有本体会导致什么情况？我们用RAG技术整理文档，进行向量化召回，召回出来的结果无论对错，都被当作一个事实。但这个事实究竟描绘了什么业务场景，其实是模糊的。本体论正是要解决这个问题。”
本体的具象化：图、模型与五级建模
当吕航飞追问“本体到底长什么样”时，两位嘉宾分别从技术架构和业务视角给出了具体描述。
隰宗正用一个简单例子解释U Model：“在U Model里，Set就是节点，Link就是边，整个IT世界就是一张图。”他以一台服务器为例展开：“这台服务器本身是一个实体，归属于一个域，比如叫ECS.instance。我们会定义它的属性——IP地址、CPU核数、内存大小、操作系统、状态等。这台服务器上运行了一个微服务，这个微服务也是一个实体，比如叫APM.service。服务器和微服务之间有一条关系，类型是‘运行在’。”
“不同的实体还会产生各种可观测数据——CPU使用率、内存使用率归到指标集（Metrics Set），系统日志归到日志集（Log Set）。这些数据集通过‘data’关系和服务器实体关联起来。这样，一个实体及其相关数据，就构成了一个最小的可观测单元。”
隰宗正总结道：“所以本体不仅是表，不仅是数据，它更是一张图。用图来描述对象和关系，用属性来约束语义和质量。当故障发生时，AI Agent就可以从这台服务器出发，沿着这些Link关联查找服务、数据库、上下游依赖，从而实现自动化的根因排查。”
胡申民则从业务视角给出了不同的框架：“本体应该分为业务本体和技术本体两部分。业务本体澄清业务含义，技术本体对接我们现有的数字化系统、API和数据库。”他详细介绍了业务本体的五个维度：
“第一是实体模型，定义核心业务对象。比如在授信领域，客户是关键实体，拥有客户编号、姓名、年龄、地址等属性；授信申请、授信额度也是关键实体。第二是流程模型，通过五级建模——业务领域、价值链、活动、任务、步骤——来构造，这是IBM提出的方法论。第三是行为模型，描绘实体能做什么，比如客户可以‘提交申请’、‘支用额度’。第四是规则模型，把过去嵌入代码if-else里的业务规则提取出来。第五是数据模型，映射到现有的数据仓库和核心系统API。”
胡申民特别强调了流程模型的重要性：“如果不把流程定义清楚，AI在实际使用时可能会跳出既定流程，从而丧失可解释性。金融行业有铁的纪律——AI必须说得清清楚楚，所有操作必须可追溯。为什么给这个客户授这么多信？是否存在歧视性？这些都有严格的监管要求。”
大模型与本体：大脑、骨架与记忆的协奏
圆桌讨论中最精彩的部分之一，是关于大模型与本体如何分工的探讨。隰宗正给出了一个形象的比喻：“大模型是大脑，这没有任何疑问。那本体到底是什么？我更倾向于说本体是骨架加上记忆。”
他具体阐述了这个比喻：“首先是骨架，它定义了IT世界的结构——哪些实体存在，它们之间有什么联系和关系。其次是记忆，通过Runbook机制，把专家领域的经验、最佳实践、操作手册，以分层的方式存储在整个图谱当中。这不是大模型训练时的通用知识，而是特定于系统和业务的专有知识。第三是工具性，通过Toolkit和Skill机制，定义AI Agent可以调用哪些工具、哪些技能，比如查询指标、搜索日志、执行操作等。”
隰宗正还提到了一个关键能力——“反射”：“本体提供了类似反射的能力，让AI可以动态发现当前实体具备哪些能力。不同的实体可能挂载的能力也不同，因此AI可以自主决策针对这个实体能调用什么工具、查看什么数据。”
胡申民补充了本体在约束AI行为方面的价值：“本体为大模型提供了一个有规则、有边界的地图。大模型负责泛化能力，本体负责行为约束。把AI的行动边界收拢在本体模型中，这样它触发了什么规则、在哪个流程范围内操作，都是可以追溯的。”
关于Graph RAG（图检索增强生成），胡申民认为它起到“血肉补充”的作用：“知识图谱把实体间的关系定义在图谱中，当模型需要查看制度文件或特定数据时，通过图检索或向量召回为模型提供精准的语境信息。”
隰宗正补充了渐进式加载的设计考量：“因为本体规模可能很大，我们设计了类似目录的机制。大模型先看到目录，根据目录判断某一条信息是否需要，需要的再深入加载。这样避免了把大量内容全部塞到大模型上下文窗口，导致其被‘撑爆’的问题。”
最难的不是技术：把专家经验从脑中搬出来
构建本体的最大挑战是什么？隰宗正概括了两个核心问题：“一是认知隔阂。运维专家脑子里的知识是经验性的、模糊的，比如‘这个服务一般不会挂，除非数据库出了问题’。要把这种模糊的经验转化为结构化的U Model，需要大量的沟通和抽象工作。二是隐性依赖关系。很多系统间的依赖并没有被显性记录，例如服务A通过消息队列间接依赖服务B，但这个关系没有落在任何文档里，只有资深运维才知道。”
胡申民分享了一个生动的金融案例：“一位超级资深的授信审批专家，打眼一看就能直觉判断某个授信申请或客户存在问题。但你让他具体说出哪里有问题，他一时间也难以精确描述。这就是隐性知识的典型特征。此外，即使专家能写清楚，他们的时间也极其稀缺，很难配合长期的知识梳理工作。”
面对这些挑战，两位嘉宾分享了各自的应对方法。
隰宗正用“软硬兼施”来概括策略：“硬的方面，我们提供了Common Schema——阿里云预定义的标准化模型，覆盖了阿里云产品、K8s、APM等常见场景。用户不需要从零开始建模。同时我们开发了U Model Explorer，一个可视化建模工具，让建模过程像画架构图一样直观。软的方面，我们采取渐进式方法，不要求一步到位。先构建最核心的实体和关系，跑通一个具体场景（比如APM服务的故障排查），让团队看到实际价值，再逐步扩展范围。”
胡申民则强调了激励机制和工具辅助的重要性：“我们建立了类似维基百科的荣誉与激励体系，鼓励资深业务人员主动贡献隐性知识。同时利用大模型来提效——对于文档制度类知识，用大模型自动提炼关键信息；对于代码类逻辑，用Code LLM读取代码自动提取业务规则。这样可以缓解专家时间稀缺的问题。”
隰宗正补充了一个关键洞察：“最重要的是让建模的价值快速可见。当运维团队发现有了U Model之后，故障排查时间从几十分钟缩短到几分钟，他们自然愿意投入更多精力来完善模型。”
给新手的建议：第一件要做的事与不能做的事
在直播接近尾声时，吕航飞问了一个非常实用的问题：对于想用本体思路改造自己系统的同行，如果明天就要启动，第一件要做的事是什么？第一件不能做的事是什么？
隰宗正毫不犹豫地回答：“第一件不能做的事，就是不要试图一步到位。不要想着把所有系统都建模完，这种大而全的项目往往周期长、见效慢，容易失败。另外，千万不要走到‘为本体而本体’的路上——如果简单的RAG或现有工具就能解决问题，就不要过度设计。”
“第一件应该做的事，是把最痛的场景选出来，构建一个最小的可行模型，跑通一个MVP（最小可行产品）闭环。找到真正的业务痛点，找到高价值场景，然后集中火力解决它。”
胡申民补充道：“本体建设70%的工作量在业务侧，必须让业务人员深度参与知识梳理过程。当业务概念梳理不清楚时，要反复讨论、确认。不要只是技术团队闭门造车。”
结语：本体不会被AGI淘汰，而会成为新的操作系统
在直播的最后，三位嘉宾各自表达了对未来的展望。
胡申民的总结很务实：“在实践过程中，本体构建的成本确实非常高，尤其是需要业务和数据真正融合在一起。但这个投入是值得的，因为它让AI变得可解释、可信赖、可追溯。”
隰宗正的展望更加宏大：“最近AGI非常热，但我觉得当AGI真正到来的时候，它需要的不是更少的结构化知识，而是更好的结构化知识。本体不会被AGI淘汰，反而会成为AGI最重要的新操作系统之一。”
吕航飞最后总结道：“本体是一个既旧又新的东西——旧在其建模方法论源远流长，新在其与大模型的有机结合。它可以是骨架，可以是记忆，也可以是血肉。无论是银行风控还是云运维，共同的方向是一致的：为AI构建一张清晰的认知地图，让它在有规则、有边界的世界中高效、可靠地做事。”
本文由云栈社区整理发布，旨在为开发者提供更多关于人工智能与系统架构的深度讨论。
发表于 1 小时前
|
查看: 2|
回复: 0
