蚂蚁集团金融数据知识本体实践：让 Agent 从“会查数”到“懂业务”

数据已经连通，Agent 为什么仍然不懂业务？

在消费金融业务中，花呗、借呗等业务线积累了大量数据资产，覆盖用户、授信、支用、余额和运营等不同环节。这些数据通过数仓、指标平台和报表系统供业务人员使用，但对于 Agent 而言，能够访问数据，并不意味着理解数据。

例如，当业务人员询问“本周余额为什么增长”时，Agent 可以找到余额、支用人数、授信额度等相关数据，但余额增长可能与用户支用增加、营销触达效率改善或额度调整有关。缺少明确的业务关系和指标口径，即使生成了正确的 SQL，也未必能够得出可靠的分析结论。

崔伟斌认为，企业不必将所有业务经验都固化到本体中。不同业务人员对经营问题可能有不同判断，而字段含义、对象关系、指标口径和加工规则，则可以从已有数据资产中进行核对与沉淀。

因此，蚂蚁集团选择建设数据知识本体，将分散在表结构、SQL、报表和工程代码中的语义提取出来，让 Agent 不仅知道数据在哪里，还能理解数据代表什么、如何计算，以及受到哪些约束。

从存量数据反萃取本体，把业务规则沉淀下来

传统本体建设通常依靠业务专家定义对象与关系，再逐步映射到底层数据。随着数据规模扩大，人工建模和持续维护的成本也随之增加。

蚂蚁集团采用应用驱动的自动反萃取方式，从已有数据资产的实际使用过程出发，逐步还原业务语义，整个过程可以归纳为四个环节。

第一步，选择重点场景，确定数据范围。

团队不会一开始就将所有数据表交给模型，而是优先选择支用、还款、额度等重要场景，从核心数据表出发，沿上下游血缘关系获取相关 SQL、查询日志、报表及工程代码，了解数据在实际业务中如何被加工和使用。

第二步，全面探查，核对真实业务含义。

数据库中的字段注释未必与实际业务逻辑一致。崔伟斌分享了一个案例：某些字段在数据库注释中标注的“可用”和“不可用”，与线上代码实际写入的取值含义正好相反。如果直接依据注释生成本体，错误定义就可能被保留下来。为此，系统会结合代码逻辑、数据分布和相关表进行交叉核验，对无法自动判断的歧义再交由人工确认。

第三步，提取实体、关系、动作和规则。

系统结合规则引擎、大模型及代码分析，识别 Entity、Attribute、Action、Relationship 和 Metric 等本体要素，并建立底层数据映射。例如，Customer（客户）不仅包含属性，还关联申请、支用、还款等动作及相应约束。“可用额度”也不再只是字段名称，而是明确为总额度减去已用额度，并保留对应的计算规则。

第四步，设置工程门禁，保证本体质量。

蚂蚁集团通过本体生成 Meta-Agent，将构建过程划分为输入解析、全量感知、实体识别、矛盾消融、本体合成和质量验证六个阶段，并在关键节点设置 Gate 门禁。对于字段歧义，系统通过七步消融规则逐步核对；最终生成的 YAML 文件，还需经过 Python 与 LLM 双重校验。未通过质量检查的结果不会直接进入下游应用。

通过这套流程，企业可以减少对人工逐表梳理的依赖，同时借助工程约束控制自动生成知识的质量，让本体成为能够持续构建和维护的数据知识资产。

三层知识联合召回，让 Agent 找到规则和证据

本体构建完成后，还需要解决如何让 Agent 准确检索和使用这些知识的问题。

传统 RAG 主要通过向量相似度找到相关文档，但相关内容并不一定包含完整的业务关系和指标口径。为此，蚂蚁集团采用分层知识组织与联合召回机制。

其中，KGCS（Schema-Constrained Knowledge）保存受 Schema 约束的实体、属性、动作和业务规则；KGFRI（Schema-Free Relation Information）保存从文档、历史 SQL 等材料中提取的开放关系；RC（Raw Chunks / Evidence）则保留字段说明、文档原文等原始证据。

三类知识通过图索引、文本与向量索引、概念索引建立关联，并利用跨索引映射实现相互定位。

当 Agent 接收到业务问题时，系统先通过 Logical Form Planner 规划查询所需的对象与关系，再结合 KGCS 精确图检索、语义路径扩展和 RC 原文检索获取相关知识。最终，检索结果经过去重、证据合并与完整性检查，被封装为 Knowledge Package，供下游 Agent 使用。

例如，分析余额增长原因时，Agent 不仅可以找到余额、支用和还款之间的直接关系，还能进一步关联营销活动、客群结构及外部市场等潜在因素，并根据知识来源补充分析依据。

与单纯的相似度检索相比，这种方式更关注业务关系是否完整、指标口径是否一致，以及分析所依据的知识能否追溯到原始数据。

从查数到业务分析，让本体进入生产流程

在应用层，蚂蚁集团将本体知识召回作为多个 Agent 共享的基础能力，支持数据资产查询、智能问数、经营分析和特征挖掘等场景。

数据资产助手可以结合表结构、字段口径、加工逻辑与血缘关系，帮助 Agent 理解数据表的实际使用条件；分析类 Agent 则能够利用本体中的业务关系和指标定义，完成跨表查询与业务分析。

在信用卡还款流失预警场景中，团队从业务命题出发，基于本体定义的数据资产选择相关特征因子，形成包含 150 项特征的体系，并将其用于后续模型或规则及线上提醒流程。本体由此不再局限于提供查询知识，而是进一步参与特征构建和业务策略执行。

不过，本体并不能消除所有业务歧义。例如，用户询问“昨天的日均余额”时，究竟应该使用日终余额快照，还是根据余额流水进行计算，需要有明确的时间粒度和统计规则。如果无法确认，Agent 应进一步澄清，而不是自行选择字段完成计算。

对于跨表关联和敏感数据访问，同样需要经过关系与权限校验，避免因字段名称相似或数据可访问而产生错误关联和越权使用。

这些实践表明，本体的作用不是替代业务判断，而是为 Agent 提供统一的数据语义、明确的使用边界和可追溯的知识依据。

从蚂蚁集团的探索来看，企业建设本体并不需要推翻已有数据体系。数仓、SQL、报表和工程代码中已经沉淀了大量业务知识，关键在于如何将其准确提取、校验并持续维护。

随着 Agent 从数据查询走向业务分析，真正重要的已不只是能否找到数据，而是能否正确理解数据、识别业务规则，并在可靠的知识基础上开展分析。

分享嘉宾

INTRODUCTION

崔伟斌

蚂蚁集团

资深数据技术专家

崔伟斌，现任蚂蚁集团资深数据技术专家，长期深耕消费金融、工程架构、数据架构与数据智能领域。近年来重点探索大模型与数据技术的深度融合，围绕营销智能体、数据智能体、业务本体、智能分析与数据工程智能化开展实践，推动数据能力从传统的数据生产与分析，向“AI理解业务、智能体自主完成数据任务”演进。曾获多项国家奖项和专利，并受邀参与多次大型技术分享。