滴普科技赵杰辉：企业AI的核心在自进化的语义底座 | 2026 ITValue Summit 数字价值年会

本体（Ontology）是把企业数据、知识、业务逻辑结构化表达出来的体系。它目前的问题在于：每家企业情况不同，很难标准化，同时其搭建过程高度依赖人工，定制化程度高。因此很难快速复制到更多行业。能否用自动化的方式完成这一过程？ 滴普科技股份有限公司创始人、董事长、执行董事兼CEO赵杰辉在2026 ITValue Summit数字价值年会的演讲中，详细讲述了滴普科技对于本体、FDE、以及办公智能体平台的策略与见解。他表示，传统数据治理已无价值，因为它是给人看的指标，而现在数据治理必须面向模型训练与推理。 他进一步强调， 滴普科技正用自研的Deepexi企业大模型，把FDE工程师的大量工作自动化替代，将企业多模态知识从Wiki进一步自动抽取为本体，并在此过程中沉淀“轨迹数据”，构建Deepology数据集。 最珍贵的不是原始数据，也不是系统第一次生成的结果（因为可能不准），而是人在调整、纠错过程中留下的轨迹数据。这些轨迹能让模型越用越准。 滴普科技当前聚焦三件事：一是用Deepexi企业大模型，把企业多模态知识从Wiki自动抽取为本体，并以超过400家企业服务中积累的轨迹数据构建Deepology数据集，让FDE实现自动化，提升Token价值；二是推理效能和模型路由，打好语义基础，做业务语义层与通用执行层两层Plan，按任务选模型，解决Token成本的问题；三是DeepWorks，企业智能体平台打通企业ERP等遗留系统，让Token进入生产主流程。 他认为， 未来AI在产业落地的核心，是能否准确生成一个知识底座，让FDE实现自动化。 真正高门槛的不是行业模型，因为公开的行业知识很快会被卷入基础模型， 真正无法泛化的是企业内部的生产和经营决策逻辑。 以下是赵杰辉在2026 ITValue Summit数字价值年会上的演讲实录，经编辑： 本体的重要性已成为共识，但有几个现象值得重新审视：其一，FDE并非新概念，国内早有实践，却始终未能做好。根本原因在于缺乏自动化方式，单纯依赖人力的模式难以规模化。其二，Coding的热度正在回归理性。几个月后再看，它不过是基础设施的一环，而非企业智能化的全部。真正的挑战在于：企业智能化中约70%的场景，需要超越通用工具、深入业务纵深的深度能力——这正是本体价值的落脚点。 我们现在就做三件事情。 第一，Token价值的问题。 不管是CAD、CAE，还是企业里的各种数据，第一步都可以变成知识库Wiki。但Wiki只是第一步——它是词条之间的关联，只能做知识性和实时性查询。光有知识不行，就像大学生学了一肚子知识却干不了某些活儿，缺的是从知识中抽取的规则、动作和技能。比如大族激光的技术员拍一张故障照片：只有Wiki，AI只能告诉你“这是什么故障”；有了本体，AI才能完成整个系统的故障定位，给出处置动作。所以路径很清晰：先把企业多模态知识抽成Wiki，再自动化抽成本体。准确性会不会越来越高？每个Token的业务价值会不会越来越大？这就是Deepexi企业大模型在做的事。 滴普目前通过为大量的离散制造企业提供数据治理和本体搭建服务产生的轨迹数据，构建了Deepology企业本体数据集和技能。比如客户有个会议纪要的需求，我们会从L1到L5逐层搭建数据体系，这个过程中第一遍产生的数据不准确，就需要人工调整，而这个调整的过程就是“轨迹数据”。 一句话来讲，我们就是把FDE工程师用模型去替代，这也是我们研发投入最大的部分。 第二件事情是模型路由，解决Token的成本问题。 最近模型的尺寸越来越小了。当然，模型在C端突破尺寸越大越好，但最后不可能每一个任务都用大尺寸。一是体验不好、太慢，二是成本太高。为此在B端，要先把语义基础打好，然后做规划，比如一个任务拆解成哪几个步骤、每一步该用哪些模型。目前我们有两层Plan能力——业务语义层Plan和通用执行层Plan，进行了创新性投入。大部分情况下，企业根本不需要最强的模型，像Deepseek V4 Flash这种就可以，直接在本地桌面就能跑起来。 第三件事情就是DeepWorks在做的事情，解决协同问题。 所谓的Work大战，无论是我们还是WorkBuddy、TREA，其本质都是浏览器，是数据和基于数据本体形成的各行业领域专家。其核心其实是让Token进入主生产流程，通过知识库打通企业ERP等系统，基于对话式操作完成整个过程。比如调出一个对话框，打通大数据平台，把大数据平台部署的原始资料、IP地址、环境部署等体系资料全部整理出来。至于办公场景能力的提供，只是这一能力体系的自然延伸。 我还要补充两点：一是我认为传统的数据治理其实没有任何价值，因为传统方式最终是给人看的“指标”，而现在数据治理一定是给模型训练或推理用的，逻辑并不一样。这也是我们为什么用轨迹数据进行数据治理的原因。 二是在我看来不存在行业模型。原因很简单，只要行业数据公开，不需要几天都会被卷到模型里面去。因此我们也从来没做过零售模型，像百丽的经营数据拿到安踏去是不成立的，行业模型没有办法实现企业间的泛化。而即便有泛化能力的那部分知识也会被卷入基础模型训练。 像CAD、CAE，以及IoT数据、工业时序数据，这些被称为多模态数据——这是有一定门槛的部分，因为你首先要完成对这些模态数据的解析。我举一个工业场景的例子——假设要围绕某个故障对数据进行统一表征：故障图纸属于低频数据，往往只有一份静态文档；但要还原故障发生的真实过程，还必须结合IoT数据、设备振动数据这类高频时序数据。换句话说，你需要把同一秒内、不同采样频率、不同知识逻辑的数据，对齐到同一时间轴上，形成一个统一表征的空间。这件事非常复杂，一般的语言模型做不了。 而真正高门槛的是每家企业自身的决策逻辑。例如我们最近在推进的OTB（Open-to-Buy）整合，它涉及经营数据，即如何调整销售逻辑才能完成目标。这是一套复杂体系，企业一般不会把这个放在网上，任何基础模型都学习不到。我们现在就是用Deepexi企业大模型，实现数据的自动化抽取，搭建企业本体模型。在我看来，未来AI在产业落地的核心是能否准确生成一个知识底座，而这个知识底座可以让FDE实现自动化。 DeepWorks要做的事情就是把企业已经具备的本体，再加上SOTA模型，结合起来，与企业内部的遗留系统灵活打通，再由浏览器串联。你会看到，其核心就是将模型路由变成自动化过程，而自动化这件事情又会取决于语义基础：你的任务到底用哪个模型能够完成。 从行业上看，除制造、零售、公共事业，我们最近还有一个领域是科学研究，即AI for Science。最近有几个实验室围绕材料和生命科学领域展开，是把大量实验数据与大量论文知识整合起来，形成新的逻辑。但还是这一套逻辑，无非是有大量实验数据，再结合大量文件、大量论文数据的检索。 最后，提及下我们跟华为云发布最核心的方案。如果今天的数据治理仍需要从立项、需求分析、做项目计划、整理纪要等模式开发，花三到六个月时间实施，最后可能还不满意。这就太落后了。我们的方案是：和客户开会时直接录音，把会议纪要扔给系统。系统会判断缺什么信息，主动提出需求。比如你要做采购领域的数据治理，一直到数据应用开发，第一层输入就是这份会议纪要。围绕这个对话过程，系统会逐步完