从腾讯 DataBuddy 看企业级 Data Agent 设计：架构、本体与语义层。- 大数跨境

首页

从腾讯 DataBuddy 看企业级 Data Agent 设计：架构、本体与语义层。

AI大模型应用实践

2026-11-09

导读：构建业务语义层，让大数据 Agent 从演示走向真正可用。

点击上方蓝字加入我们

自从大模型诞生，其在大数据领域的应用一直被寄予厚望。特别是如何让决策者能够跨越技术鸿沟，快速地问数与分析，而不是等待技术部门的加班结果。

企业级的分析型 Data Agent 的代表性方案是 NL2SQL（自然语言转 SQL） — 但行业知识门槛、复杂的数据模型与分析需求，都会让 LLM 的幻觉率极高。

本篇将站在腾讯的 DataBuddy 这款 Data+AI 产品的“肩膀上”，探讨企业级数据 Agent 系统的架构设计，特别是业务语义层在 ChatBI 这类场景的应用。

DataBuddy 能力与架构初探

DataBuddy 是供企业数据团队与业务人员共同使用的大数据 + AI 云端工作台。在这个工作台，数据团队可以准备好各类数据源；定义业务模型、指标与口径；业务人员通过自然语言对话做问数与分析 — 所有这些工作，都有 Agent 的辅助。

三个层次看架构

如果抛开 DataBuddy 一些绑定腾讯云设施的部分，它的核心架构具有一定的普适性，大概长这样：

业务交付层

提供了面向不同角色的具体任务能力 — 由对应的工程、治理和分析 Agent 做 AI 赋能，可以执行数据集成工作流，开展数据质量治理，提供交互式分析能力。

能力平台层

负责多层数仓的加工与创建（从 ODS 到 DW 的各级明细与汇总）、数据资产的目录管理。这一层还有一个重要的任务，也是本文关注的重点：业务语义层 — 包括业务本体和数据指标、维度、血缘关系等语义的定义。

DataBuddy 中用“本体”定义业务对象、属性及关系；用“语义模型”定义业务指标等。两者都表达语义，侧重点不同。本文将两者统称为“业务语义层”。

存储计算层

负责保存原始数据和提供批量计算引擎 — 来自于企业生产系统的各种形态的数据，RDBMS、NoSQL、SaaS、消息、事件、文档等等。

身份与权限

借助数据安全标签、风险识别、SQL 防护、身份管理与授权、Agent 跟踪审计等手段，实现企业级数据的纵向防御。

理解架构中的三类 AI Agent

我们更关注 AI 在整个架构中的角色与职责，它们代表了典型的大数据系统中的三类常见任务：

数据工程 Agent：数据的加工、集成与开发

涵盖数据同步、增量接入、SQL 架构、数据工作流的开发与定期执行。如原始数据的清洗与标准化；主题事实数据生成与汇总；定时的数据挖掘模型更新。

数据治理 Agent：发现数据质量等问题并修复

通过唯一性校验、数据剖析、血缘分析和分布变化检查发现数据质量问题并处理。比如，检查重复数据、数据更新的一致性、数据同步的及时性等。

数据分析 Agent：把自然语言提问变成分析结果

结合业务语义层的模型、LLM 的推理能力、数据分析 Skill、确定性的代码与工具等，将自然语言的分析要求转化成数据层可以执行的查询语句，并执行。

这里的数据分析 Agent 是我们关注的焦点。特别是如何借助业务语义层来控制传统 NL2SQL 方法的语义幻觉、口径混乱等问题。

腾讯：有语义层与无语义层的准确率测试结果

本体与语义模型如何让 AI 分析更准确

我们用 DataBuddy 中的一个电商零售行业智能体来做测试，研究本体与语义模型是如何参与到 Agent 的分析任务中 — LLM 负责什么、语义层又是如何参与、整个任务过程是怎样展开的。

先看下业务本体的定义，大致关系如下：

同时，定义了一个面向卖家经营与品类表现分析的语义模型：

那么，现在有一个简单的分析问题：

2016 年 9 月至 2018 年 10 月，平台每月的 GMV 和订单数分别是多少，整体呈什么走势？

传统方法，AI 为什么容易出错

上面问题如果直接交给大模型，当然有可能回答正确，但也有很大概率会出错，这来自于一些潜在的问题：

口径歧义：比如 GMV 是否计入运费、哪些订单状态参与统计？
时间条件歧义：比如按月统计，那么是按照下单日期还是送达日期？
多种问法的归一：交易额、销售额、GMV 是一个东西还是三个东西？
其他可能的错误：比如把订单与商品明细 JOIN 后导致重复计算。

这就会导致潜在的不确定性：

同一个问题多次提问，可能会得到完全不同的答案。

DataBuddy 如何把问题变成确定性的结果

根据我们的测试，可以把 DataBuddy 的处理过程拆成这样的步骤：

其做法是：

借助 LLM 的理解能力，把自然语言问题通过语义层（本体与语义模型），找到相关的指标、维度等；并生成一种语义“SQL”语句，再通过工具将其转化为数据层的物理 SQL 并执行；最后由 LLM 对执行结果做分析、总结与可视化。

以下是详细的步骤解释：

1. 意图解析，识别其中的候选概念和要求，例如“GMV”“订单数”“月度统计”，以及时间范围等。

2. 获取相关的业务本体定义，借助本体理解：企业如何定义“订单”，订单与商品之间有什么关系、哪些名称实际指向同一个业务概念等。

3. 读取语义模型的定义，获得企业已经发布的 GMV、订单数等指标清单，核对其具体定义。比如“GMV”指标，从下图你可以有更具体的认识：

LLM 根据需要，选择到相关的业务指标、确定统计维度等。

4. 此时，如果指标定义中还有需要解释的业务条件，比如用户要求同比、环比、贡献分析等，LLM 还可以调用知识查询工具，获取相关的指南和约束。

对于更复杂的分析需求，如果仍然存在缺失条件或者会影响结果的歧义，还可以通过用户澄清、扩大知识库查询等做进一步消除。

5. 现在，LLM 已经把用户的意图对应到明确的企业业务含义，并确定了本次要使用的指标（GMV、去重订单数）、统计粒度、时间范围和筛选条件等。

这时候需要“语义 SQL 查询工具”出场，它的作用是把类似这样的查询：

编译成数据层可执行的确定性查询语句（比如 SQL），并提交执行，获得结果：

6. 在获取到结果数据后，根据用户的分析意图，做进一步的整理、解释、报告生成、图表配置生成，完成输出。

由于有了足够的业务理解、指标口径等知识，Agent 可以给出充分的数据来源的解释，帮助用户理解数字的含义。

当然，对于复杂的分析需求，Agent 有可能要经过多次 Loop，继续调用更多次的语义模型、指标和工具，获取更多数据做进一步解读。

以上就是 DataBuddy 如何把一个自然语言的问数需求，借助业务语义层，转化为确定性的查询结果，而不是简单的 NL2SQL。

这里“确定性”的提高主要来自于：

业务含义经过本体确认，指标口径被语义模型固定。模型并不生成直接查询的语句，而是生成一种中间态的“语义 SQL“。

各个组件，分别负责什么

总结下在上面的过程中各个组件的分工：

所以，为什么业务语义层对于构建企业级的数据智能体至关重要？

统一口径，让不同入口的结果能够对得上：当多个 Agent、报表和应用使用同一套指标时，用户改变提问方式，或者换一个应用，计算规则就能保持一致。
集中维护业务知识，减少每次任务的临时判断：确认后的语义层可以持续复用（即使底层结构变化），Agent 可以把更多精力放在理解意图、优化流程上。
让结果“可解释”，把数据访问规则落实到执行过程：系统可以保留指标版本、查询条件和执行记录，帮助准确地回答“这个数是怎么算出来的”。

构建企业自己的 Data Agent 系统

DataBuddy 在架构上的参考意义在于：如何借助企业受治理的业务本体与语义层，让 Data+AI 的应用能够从 Demo 真正走向生产级决策。

特别对于已经有了自己的数仓、报表与身份系统的企业来说，如果希望构建这样的 Agent 系统，把数据分析能力留在内部，你必须对此有清晰的思路。

大数据 Agent 整体架构

从一个端到端的场景链路开始：

用户从应用入口或办公智能体（如 WorkBuddy）提出问题，Data Agent（分析型）加载技能，在权限范围内读取并理解业务与相关指标，调用语义 SQL 查询工具，并转化为数仓的执行输入，最后将结果组织成图表、解释、分析报告。

基于这个场景，设计这样的系统架构：

数据底座

使用已有数仓或独立建设，本质上还是属于传统企业数仓层：生产系统经过同步、清洗和质量检查，形成明细、维度、汇总等主题数据层。查询引擎（分布式）承担筛选、关联和聚合，已有的数据开发与集成平台可以继续运行。

业务语义服务

这是最核心的增强。保存已发布的本体、指标等语义数据（借助图数据库）；结合 BM25、向量等索引，向上层提供语义模型的检索与读取接口；提供语义 SQL 引擎：将基于语义的查询转化为底层数据库的语言并执行。

Agent 运行层

这是 Agent 的应用层。Harness 负责管理任务状态、上下文、加载 Skills 和工具调用；LLM 提供理解、规划与解释能力，借助模型网关连接自部署模型或获准的公开模型，统一管理调用范围、配额与日志。

用户交互层

前端应用层，提供交互入口并呈现结果。可以是原生 ChatBI 应用；也可以是嵌入的 Copilot；甚至可以集成到办公智能体如 WorkBuddy 中，真正让决策者无缝与 Data Agent 协作。

身份、权限与审计

贯穿多层的数据安全。在应用入口验证员工身份；在语义层过滤不可见模型；在执行侧要落实可访问的数据源、甚至行列限制；并记录详细的 Trace 用于审计。

下面对架构中的几个重点做深入。

业务语义层的建设

业务语义层的核心任务可以抽象为：语义建模、模型存储与查询、语义 SQL 引擎三个部分。实际建设中，这是难度最大的部分，比较理想的方式是借助 AI 以及开源项目来降低复杂度：

开发“建模 Agent”，让 AI 辅助建模

面对存量的数仓表，完全靠人工梳理本体与指标语义不太现实。因此开发一个语义建模的 Agent 是必须的，以实现这样的建模过程：

通过自动扫描（或者人工指定）数仓元数据、对象与文档，起草跨源本体的对象、关系与指标草案（比如声明式的 YAML 语义模型），然后交给人工查看、审阅甚至试运行验证；经过数据团队确认后的模型才可以正式发布上线。

这里推荐两个可学习的 GitHub 开源项目 Helix Foundry 和 Cube。

模型存储与索引，提供模型召回能力

建模 Agent 发布的本体与语义模型，需要存储、索引，并发布给上层 Data Agent 使用。通常的方法是将这些模型的实体、关系、指标口径、维度定义、血缘关系等落盘至图数据库与元数据中心（数据目录）。

同时结合图遍历、BM25 关键词与向量索引等，提供统一的语义模型检索工具给上层 Agent，按任务意图召回最小的模型子集。

语义 SQL 引擎

将带参数的语义 SQL 编译为数据层语言执行。这是消除大模型幻觉的关键防线：大模型不再直接生成底层语句，而是生成面向语义层的逻辑查询。比如：

语义 SQL 引擎先校验语法，再将其“编译”成目标数仓的物理 SQL 执行。

这种语义 SQL 引擎的实现可以去看另一个腾讯早期的开源项目 SuperSonic，它提供了一个从语义检索映射，到语义 SQL 生成、编译执行的完整参考实现，即“自然语言 → Semantic SQL → 物理 SQL”。

构建分析型 Data Agent

有了可靠的语义层底座，数据分析 Agent 就不再是简单地把任务交给 LLM 做 NL2SQL 转换，而应该是一个能够自主规划、学习语义、并调用工具的分析型智能体：

数据分析 Workflow

一种方法是借助 LangGraph、Google ADK 这样带工作流编排能力的开发框架，构建属于自己的 Harness。

另一种方式是基于已有开源 Harness（如 DSH、Codex-Harness）做个性化，结合自定义的数据分析 Skill 与工具来完成。

无论哪种方式，上图中的核心工作流是一致的。

核心的受控工具

无论查询语义层的模型和指标，还是调用语义 SQL 引擎，Agent 都需要借助工具。以下是一些主要的工具：

语义召回：输入任务意图，调用语义层的检索接口，按需召回本体与指标语义的子集（实体、关系、指标口径、维度定义等）；目的是避免把全量的语义层输入 LLM。实际应用中，可能还需要配合一些其他的知识库查询工具。
语义 SQL 查询：基于上一步锁定的相关指标口径，结合输入任务，组装结构化的参数与语义 SQL，由语义 SQL 引擎完成物理 SQL 的编译与执行。
图表渲染：根据分析任务的需要，生成并校验结构化的图表配置（如 ECharts ），并随查询到的数据与结论一起返回，交给客户端做渲染。
分析沙箱：这是供 Agent 在必要的时候使用的隔离沙箱，用于对取回的数据做进一步的本地分析或挖掘（借助代码），如相关性、归因、预测等。