---
title: 本体驱动企业级 Data Agent：从“查到数字”走向“解释原因”
description: 企业 Data Agent 如何从查到数字走向解释原因？本文结合销售分析与银行问数场景，介绍 OceanBase DataPilot 如何通过本体组织业务对象、关联、属性和指标口径，支持指标选择、变化分析与证据核验，并通过专家校验和真实问答持续完善业务语义。
image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

[AI](https://www.oceanbase.com/obi) 咨询热线

## 核心要点

- 企业问数的挑战，不仅是找到一个相似指标，还要选对业务口径、沿业务关系分析变化。
- 本体将对象、关系、属性和口径组织起来，为 Data Agent 提供可以逐步探索的业务语义。
- 本体建设可以从具体业务场景开始，借助已有数据资产生成初稿，再通过专家校验和实际使用持续完善。

企业都想要一个会“问数”的 AI：用大白话问一句，就能把经营数据查出来，把问题分析明白。

为了让 AI 理解企业业务，很多团队会先整理指标、口径和文档，再通过 RAG（检索增强生成）找出与问题相关的内容，交给大模型生成答案。这套方法上手快，在查找资料和归纳文本时很有价值。但在企业问数场景中，我们发现两个问题反复出现：**一是“是多少”可能选错口径，二是查出数字后，答不好“为什么”。**

这两个问题，不只是换一个更强的模型就能解决。模型回答之前，需要先拿到与问题相关的业务知识。如果它拿到的只是几段相似的文字，却不知道指标适用什么范围、业务对象之间怎么关联，就很难靠模型自己把整件事拼完整。

## 为什么企业问数会遇到“选不对”和“走不通”

先看“选不对”。

假设业务人员问：“上个月销售额是多少？”企业的指标体系里，可能同时有销售额、净销售额、含税销售额，以及扣除退款后的销售额。它们的名字很像，算出的数字却可能不同。

如果系统只按名称和问题的相似度召回，就可能选中一个看起来合理、却不符合提问者意图的口径。更麻烦的是，答案有时并不会显得离谱：一个错误口径算出来的数字，也可能像模像样。

银行场景也有类似问题。管理者问“经营情况怎么样”，他想了解的可能是一组指标：一般性存款余额、贷款余额、净利润、中间业务收入等。它们未必都与“经营情况”这几个字相似，却共同构成业务人员理解的经营状况。**相似度不等于业务相关性；要选对指标，还需要知道它属于什么业务、适用什么范围、怎么算。**

再看“走不通”。

运营负责人看到华东区销售额下降，很可能接着问：“为什么跌了？是哪些客户、哪些品类拖累的？”这时，只找到一个销售额指标已经不够。Agent 需要知道销售额可以按区域、渠道、品类和客户等角度拆解，还要能把区域、客户、订单和商品之间的关系连起来。

如果知识只以相互独立的文档片段呈现，“客户”可能是一段文字，“订单”是另一段文字，但它们之间的业务关系未必以 Agent 可以直接使用的方式表达出来。找到了相关内容，不一定就知道下一步该查什么。

这就是我们在客户实践中看到的共同问题：当业务知识的结构和关系没有被保留下来，Agent 要么在相近口径之间选错，要么在追问“为什么”时不知道该沿哪条路继续走。

## 本体：把散落的业务知识组织成一张图

我们的思路是，在企业底层数据和上层 AI 应用之间，建立一层围绕业务组织的语义结构。我们把它称为本体。

可以把本体理解为一张业务地图：地图上有哪些地方，它们之间有哪些道路，每个地方有什么特征、可以做什么计算，都需要被清楚地描述出来。它并不要求把所有企业数据物理搬到一处，而是把已有的数据和知识组织成 Agent 能理解、能追溯的业务表达。

在我们的实践中，这张图主要由四部分构成：

- **业务对象，是图上的点。** 客户、订单、商品、账户、存款，都是业务人员认识的对象。一个对象背后可能对应多张表，但业务人员不应该被迫先弄清每张表的名字。
- **业务关联，是点与点之间的边。** 客户下单、订单包含商品，或客户开立账户、账户关联存款。这些关系把原本分散的数据连成可理解的业务路径。
- **业务属性，是对象身上的信息。** 客户有等级和区域，订单有状态和金额；这些属性帮助 Agent 了解一个对象能提供哪些信息，也帮助它区分相近概念。
- **业务口径，是指标背后的计算规则。** 销售额如何计算、哪些订单需要排除、存款余额由哪些部分构成，这些规则决定了最终数字的含义。

四者放在一起，AI 面对的就不再只是一些散落的表名、字段和文档片段。它可以先判断问题涉及哪个业务对象，再查看对象的属性、关联和指标口径，逐步找到回答所需的数据。

在实际使用时，还需要区分物理关系和业务关系：两个字段看起来可以连接，不意味着这条连接一定符合业务语义。对象、关系和口径都需要结合企业实际情况校验。

## 选对指标：先看业务身份，再逐层缩小范围

有了地图，第一步是解决“选不对”。

回到刚才的销售额例子。面对多个名称相近的指标，Agent 不应只问“哪个名字最像”，还要看每个指标的业务定义：它覆盖什么范围、包含或排除了哪些订单、挂在哪类业务对象上，以及是否适用于当前问题。

这些信息相当于指标的“身份”。用户问区域经营大盘时，Agent 可以结合提问中的区域、时间和业务场景，核对候选指标的定义；如果口径仍有歧义，就需要进一步澄清，而不是猜一个看起来最顺眼的答案。

另一点是逐层缩小范围。企业可能积累了大量指标，平铺在一起时，相近名称很容易造成干扰。如果口径按业务对象和业务域组织，Agent 可以先定位相关业务，再展开对应对象及其指标，一步步缩小候选范围。

在银行例子中，用户问“某支行的个人活期存款余额是多少”，Agent 可以先定位存款对象，查看个人活期存款的定义和计算口径，再沿账户与机构之间的关联找到支行条件，最后生成查询。这个过程既要理解“个人活期”，也要理解“某支行”是怎样映射到数据中的。

这里的关键不是保证 AI 永远不会选错，而是给它更多可以核对的业务信息，并让选择过程能够被检查。

## 走出“为什么”：让 Agent 沿业务关系继续探索

选对指标，只是第一步。用户问“为什么下降”时，还要沿关系继续分析。

我们希望 Agent 不只接收一次检索结果，然后根据手里的材料拼答案；它可以先查看有哪些业务对象，判断要核对哪一项口径，再沿相关关系展开可分析的维度。发现一条线索不匹配，可以回头查看其他候选；有多个可能方向，也可以分别探索和比较。

这个过程中，给模型的信息既要足够覆盖问题，又不能一次性塞进所有知识。我们的做法是通过本体分步组织上下文：每走一步，就提供当前判断需要的对象、属性、关联和口径。

拿“华东区销售额为什么下降”来说，一个可能的分析路径是：

1. **确认指标。** 结合问题中的区域和时间，检查采用的是哪一项销售额口径，以及计算中是否包含退款等因素。
2. **寻找拆解方向。** 从指标关联的业务对象出发，查看可以按哪些维度分析，例如区域、渠道、品类和客户。
3. **逐层比较。** 沿区域、订单、商品等业务关系，比较不同维度的变化，找到对整体变化贡献较大的方向。
4. **回到数据验证。** 进一步检查相关订单、退款或客户明细，为业务人员提供可以复核的依据。

假设分析发现，线上渠道某个品类的退款变化与整体下跌有关，Agent 就可以把这条线索及其数据依据呈现出来，帮助业务人员决定下一步看什么。

这个例子说明的是分析方法，不意味着有了关系图就能自动证明因果。相关性、变化贡献和真正的业务原因是不同层次的判断，最终仍需要结合指标口径、明细数据和业务规则核实。

我们所说的“从找相似到会行动”，在这里主要指 Agent 能在本体上主动探索、查找和分析，并不等同于自动执行有外部影响的业务操作。涉及写入或触发流程时，仍需要相应的权限、审批和审计。

## 在 DataPilot 中，这张图如何长出来？

讲到这里，很多人会问：既然本体要描述对象、关系、属性和口径，是不是得先把全公司梳理一遍，才能开始使用？

我们的实践是从一个边界清晰的业务场景开始。先围绕这个场景引入已有数据和知识，形成初步模型，再让业务人员通过真实问题验证它。随着使用和反馈增加，模型逐步得到修正；不同业务域积累成熟后，再探索如何让语义跨域复用。

### 从已有资产生成初稿

企业通常已经积累了不少可以利用的材料：表结构、字段类型、主外键、数据样本、知识库文档、历史 SQL、BI 看板和 ETL 中的计算逻辑。

不同材料提供的线索并不相同。表名、字段和样本值，有助于识别可能的业务对象及属性；外键等信息可以提供关联线索；知识库、历史 SQL 和 ETL 中，则可能保留了指标筛选条件、业务计算逻辑等更明确的规则。

例如，一项销售额口径可能要求排除测试订单或取消订单。这类规则不一定能从字段名称看出来，但可能已经写在企业文档或历史查询中。建模时，我们需要把这些线索结合起来，映射到业务对象及其口径，并保留与底层数据的对应关系。

大模型和 Agent 可以辅助整理这些材料，减少从头梳理的工作量。但机器生成的是**初稿**：它可能误解字段、遗漏条件，也可能把物理连接错当成业务关系。因此，初稿必须经过业务专家校验。

### 在真实问答中校验和完善

让专家直接检查一张图是一种方式；用真实问题来测试，也往往更直观。

业务人员提出经常遇到的问题，查看 Agent 选用了什么口径、沿着什么关系找数据、给出的答案是否符合业务认知。出现错误时，专家可以指出是指标定义不对、关联路径有误，还是缺少了某个业务条件。

这个过程还能帮助企业发现“暗知识”。有些规则没有写进文档，而是存在于有经验的员工脑海里：比如一个指标在特定场景下需要排除哪类记录，或遇到异常时应该先核查什么。通过问答和纠错，这些知识才有机会被记录下来。

但一次用户反馈未必适用于所有部门和所有时间。我们更重视的是：先把反馈作为待确认的线索，明确它的适用范围，再由业务人员决定如何更新共享语义。使用本身能帮助暴露问题，却不能代替对知识正确性的判断。

## 为什么我们不从一张全域大图开始

当一个子域的本体能够服务真实业务后，大家自然会想到下一步：能否把多个场景连起来，形成覆盖更广范围的业务理解？

这确实是我们关注的方向。但如果一开始就自上而下铺开全域建模，很容易遇到几个问题。

首先是**过度抽象**。不同部门为了达成统一，可能把“客户”定义成“与企业发生商业关系的主体”。这句话没有错，但太宽泛，到了具体的零售存款、对公信贷或风险管理场景，仍然需要区分不同的对象和规则。

其次是**对齐成本高**。跨部门反复开会可以帮助厘清分歧，但如果缺少具体问题牵引，讨论可能停留在概念层面，业务部门迟迟看不到自己的问题被解决。

还有**静态化**的问题。业务在变化，口径也在变化；如果本体被当成一次性工程，建完之后缺乏使用和维护，就可能逐渐偏离现实。

因此，我们更倾向于从局部开始：先让一个子域解决问题，再以经过验证的知识为基础，探索跨域关联和复用。相同概念需要识别共性，也需要保留差异；不能简单地把所有同名对象合并成一个。

我们的长期方向，是让多个业务子域的语义逐步汇聚，并探索让新场景复用已有知识。但这一方向仍需持续实践，目前还不能简单理解为所有子本体都能自动合并，或新 Agent 接入后就天然理解整家企业。

## 从找相似，到找路径

模型会越来越强，但企业的业务定义、数据关系和分析经验，不会因为模型能力提升就自动变得清晰。

对于企业 Data Agent，能查到数字只是第一步。更进一步，需要选对口径，知道从哪里找证据，能够沿业务关系展开分析，也能让业务人员看清结论是如何得出的。

我们对本体驱动的理解，就是把这些分散的业务知识组织起来，让 Agent 有路可走；再通过具体场景、专家校验和持续反馈，让这张图跟着业务一起演进。

从一个经常被追问“为什么”的问题开始，定义清楚相关对象和口径，走通一条可验证的分析路径，再根据使用中的错误逐步完善。让一个问题的答案更可靠，比一开始画出一张覆盖全公司的大图更有价值。

![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*5Oy_QZjvTg8AAAAAAAAAAAAADiGDAQ/original)