From Querying Data to Understanding Business: Ant Group's Financial Data Ontology Practice

01 Data Connected but Agents Don't Understand Business

In consumer finance, business lines like Huabei and Jiebei have accumulated massive data assets across user, credit, drawdown, balance, and operations. These are served via data warehouses, metric platforms, and reporting systems. However, accessing data does not mean understanding it . For example, when asked "Why did this week's balance grow?" an agent can find balance, drawdown count, and credit limit data, but balance growth may stem from increased drawdowns, improved marketing efficiency, or limit adjustments. Without explicit business relationships and metric definitions, even correct SQL may yield unreliable analysis conclusions.

Cui Weimin argues that not all business experience needs to be codified into an ontology. While practitioners may differ on operational judgments, field meanings, object relationships, metric calibers, and processing rules can be verified and precipitated from existing data assets. Ant Group therefore builds a data knowledge ontology to extract semantics scattered across table schemas, SQL, reports, and engineering code, so agents know not only where data resides but also what it represents, how it is calculated, and what constraints apply.

02 Automatic Reverse Extraction of Ontology from Existing Data Assets

Traditional ontology construction relies on business experts defining objects and relationships, then mapping to underlying data. As data scale grows, manual modeling and maintenance costs rise. Ant Group adopts an application-driven automatic reverse extraction approach, starting from actual usage of existing data assets to gradually restore business semantics. The process comprises four stages:

Step 1: Select key scenarios, determine data scope. The team does not feed all tables to the model at once. Instead, they prioritize core scenarios such as drawdown, repayment, and credit limit, starting from core tables and tracing upstream/downstream lineage to collect related SQL, query logs, reports, and engineering code to understand how data is actually processed and used in business.

Step 2: Comprehensive investigation, verify real business meaning. Database field comments may not match actual business logic. Cui shared a case where fields annotated as "available" and "unavailable" in comments had opposite meanings in the online code. Directly generating ontology from comments would preserve errors. The system cross-validates code logic, data distribution, and related tables; ambiguities that cannot be resolved automatically are escalated for manual confirmation.

Step 3: Extract entities, relationships, actions, and rules. Combining rule engines, large models, and code analysis, the system identifies ontology elements — Entity, Attribute, Action, Relationship, Metric — and establishes mappings to underlying data. For instance, Customer includes not only attributes but also associated actions like application, drawdown, repayment, and corresponding constraints. "Available credit limit" becomes more than a field name; it is explicitly defined as total limit minus used limit, with the calculation rule retained.

Step 4: Set engineering gates to guarantee ontology quality. Ant Group generates a Meta-Agent that divides construction into six phases: input parsing, full perception, entity identification, contradiction resolution, ontology synthesis, and quality validation. Key nodes have Gate checkpoints. Field ambiguities are resolved through a seven-step disambiguation rule. The final YAML output undergoes dual validation by Python and LLM; results failing quality checks do not enter downstream applications.

This workflow reduces reliance on manual per-table sorting while using engineering constraints to control the quality of automatically generated knowledge, turning the ontology into a continuously buildable and maintainable data knowledge asset.

03 Three-Layer Knowledge Joint Retrieval for Rules and Evidence

After ontology construction, the challenge is enabling agents to accurately retrieve and use this knowledge. Traditional RAG relies on vector similarity to find relevant documents, but relevant content may not contain complete business relationships and metric calibers. Ant Group employs a layered knowledge organization and joint retrieval mechanism :

KGCS (Schema-Constrained Knowledge) — stores entities, attributes, actions, and business rules constrained by schema.

KGFRI (Schema-Free Relation Information) — stores open relations extracted from documents, historical SQL, and other materials.

RC (Raw Chunks / Evidence) — retains field descriptions, document originals, and other raw evidence.

The three knowledge types are linked via graph index, text and vector index, and concept index, with cross-index mapping enabling mutual localization. When an agent receives a business question, a Logical Form Planner first plans the required objects and relations. Then the system combines precise graph retrieval from KGCS, semantic path expansion, and RC raw-text retrieval to gather relevant knowledge. Results are deduplicated, evidence merged, and completeness checked before being packaged as a Knowledge Package for downstream agents.

For example, when analyzing balance growth causes, the agent can not only find direct relationships among balance, drawdown, and repayment, but also further associate marketing campaigns, customer structure, and external market factors, with analysis 근거 supplemented by knowledge sources. Compared with pure similarity retrieval, this approach focuses on whether business relationships are complete, metric calibers are consistent, and analytical knowledge can be traced back to original data.

04 From Data Query to Business Analysis: Ontology in Production

At the application layer, Ant Group makes ontology knowledge retrieval a shared foundational capability for multiple agents, supporting scenarios such as data asset query, intelligent Q&A, operational analysis, and feature mining.

Data Asset Assistant combines table schemas, field calibers, processing logic, and lineage to help agents understand actual usage conditions of data tables.

Analytical Agents leverage business relationships and metric definitions in the ontology to perform cross-table queries and business analysis.

In a credit card repayment churn warning scenario, the team started from a business proposition, selected relevant feature factors based on ontology-defined data assets, and built a system of 150 features used for subsequent models, rules, and online reminder processes. The ontology thus moves beyond providing query knowledge to participating in feature construction and business strategy execution.

However, the ontology cannot eliminate all business ambiguities. For instance, when a user asks for "yesterday's daily average balance," it is unclear whether to use end-of-day balance snapshots or calculate from balance flow; explicit time granularity and statistical rules are needed. If unconfirmed, the agent should clarify rather than arbitrarily choose a field. Similarly, cross-table joins and sensitive data access require relationship and permission verification to prevent erroneous associations and unauthorized use due to similar field names or accessible data.

These practices show that the ontology's role is not to replace business judgment but to provide agents with unified data semantics, clear usage boundaries, and traceable knowledge evidence . Ant Group's exploration indicates that enterprises need not overthrow existing data systems; warehouses, SQL, reports, and engineering code already contain vast business knowledge. The key is how to accurately extract, verify, and continuously maintain it. As agents evolve from data querying to business analysis, the critical capability is not merely finding data but correctly understanding it, identifying business rules, and conducting analysis on a reliable knowledge foundation.

The value of the ontology lies not in how many entities and relationships it generates, but in gradually verifying originally scattered, implicit, or even erroneous business semantics and converting them into knowledge that agents can reliably use. This is the key to moving agents from "knowing how to query data" to "understanding business."