Ontology-Driven DataAgent: Retrieving Full Metrics & Explaining Root Causes

Introduction: The Problem of Incomplete Metrics and Shallow Explanations

When a bank manager asks "How is the business doing?", a typical AI system may return only net profit while missing critical indicators such as deposit/loan balances, non-performing loan ratios, and intermediary income. A follow-up question like "Why did deposits drop?" often stalls at surface-level numbers. OceanBase identifies two root causes: incomplete knowledge retrieval and inability to explain causes after retrieving numbers . The core issue is not the model but the lack of structured business relationships connecting data, metrics, SQL, and reports.

For example, "business situation" maps to five key metrics. Vector-based top-K retrieval picks "net profit amount" due to textual similarity, omitting the other four. This omission occurs because the business knowledge defining which metrics belong together is not encoded in the retrieval system. Similarity cannot replace business judgment.

Even when all five metrics are returned, explaining a decline requires drilling down through the metric's composition: general deposit balance breaks into personal demand, time, and notice deposits. The agent must follow these compositional relationships layer by layer to pinpoint which sub-item, customer, or channel changed. Deeper sub-metrics become increasingly dissimilar from the original query, making pure text retrieval insufficient.

Why Traditional RAG Fails: Missing Business Relationships

Traditional RAG chunks enterprise knowledge into retrievable fragments but loses the types, hierarchies, and calculation rules that bind them. The model can read a fragment but does not know where to go next. OceanBase shifts the problem to knowledge organization : structure business objects and metrics into a graph that preserves navigable relationships, establishing the knowledge paths needed to answer questions before retrieval begins.

Ontology-Driven Semantic Layer: Four Core Elements

The ontology semantic layer sits between data platforms (offline/real-time warehouses, lakehouses, OLAP) and AI applications. It provides a business-centric organization shared across scenarios like operational analysis, data insight, and cost control, while remaining grounded in raw data and existing computation logic. OceanBase distills the ontology into four elements:

Business Objects – entities like customer, account, deposit, institution (solves "who").

Business Associations – relationships such as "open", "hold", "belong" (solves "how to traverse").

Business Attributes – categories, statuses, dimensions (solves "which class").

Business Metrics (Calibration Rules) – calculation rules attached to objects (solves "how to compute").

All four live in a single graph, allowing a business question to stepwise resolve to concrete fields and filter conditions.

Example: Tracing Deposit Balance Decline in East China

The query "Which customers caused East China deposit balance to drop?" traverses: customer → associated accounts → deposits and transactions → institution relationships to scope East China → apply the predefined deposit balance calibration rule. The example shows time-deposit maturity and demand-deposit transfers affecting different customers. Without objects and associations, AI cannot stitch "customer", "region", and "balance change" into one query; without the calibration rule, even correct joins may produce a wrong number.

Agent Autonomous Exploration on the Knowledge Graph

Feeding the entire graph into the context window overwhelms the model; retrieving too little risks missing the entry point. OceanBase adopts AI autonomous exploration : the model first browses available business objects, then expands attributes, associations, and metrics as needed. Knowledge is supplied along the exploration path, preserving drill-down capability while avoiding full-graph reads.

Exploration is not a fixed path. The model can switch branches if conditions don't match, or pursue multiple candidates in parallel (e.g., "deposit balance" may appear in both retail and comprehensive management domains). A wrong step only adds read cost and does not mutate business data; stopping too early is riskier because it may miss the correct calibration rule.

From Metric Retrieval to Root-Cause Analysis

For "personal demand deposit balance of a specific branch", the agent: (1) locates the deposit object, (2) expands its metric list, (3) identifies "personal demand deposit balance" with subject code 2301, (4) follows "hold" to accounts, (5) follows "belong" to institutions, (6) binds the branch as a filter. Only after object, metric, and dimensions are confirmed does the information enter SQL generation. Natural-language tokens map to distinct graph elements: deposit → metric, account → access path, branch → filter scope.

Drilling into "Why did East China deposit balance drop?" shifts exploration from metrics to associated objects. The system finds general deposit balance down 12% MoM , then examines dimensions: deposit type, customer tier, institution, channel. It discovers time deposits down 22%, mobile banking transfers accounting for 68% . Deeper: 68% of time-deposit decline came from non-renewal at maturity , also via mobile banking. The two 68% figures reflect different calibration rules (channel transfer vs. maturity non-renewal). Root cause traces a result to concrete business actions, giving a direction for further customer verification.

In this design, the ontology does more than provide reference text for RAG. It turns objects, attributes, associations, and metrics into queryable, expandable, traceable capabilities . The next exploration step is decided by the model based on the question. "Action" here means graph exploration, data retrieval, and reasoning—not autonomous execution of transfers or approvals.

Iterative Ontology Construction: Start Small, Validate, Then Expand

Enterprises already have metric tables, SQL, BI dashboards, and ETL pipelines; many calibration rules live only in senior experts' heads. OceanBase avoids a big-bang enterprise-wide graph. Instead, it starts from a well-bounded business domain and lets the ontology prove itself in real Q&A.

The lifecycle: cold start (ingest tables and knowledge for one domain), processing (extract objects, relations, attributes, metrics), growth (refine through business questions and corrections). Only after a sub-ontology delivers accurate answers in its domain is it considered for cross-domain convergence.

Extracting Ontology from Existing Assets

Inputs include table/column names, types, foreign keys, data samples, existing knowledge bases, historical SQL, BI dashboards, and ETL lineage. An automated agent interprets these: e.g., t_deposit_acct → deposit account, cust_id links customer and account, acct_status → account status, and from historical queries it extracts rules like "exclude interbank deposits when calculating balance". The output is a verifiable draft that must pass business confirmation .

Verification doesn't require experts to audit every node. Instead, business users ask their usual questions; the system shows which objects, metrics, and paths were used. Errors surface quickly. For instance, an expert adds "deposit balance usually excludes margin deposits", prompting clarification of scope and manual entry into the knowledge base. Such rules often exist nowhere in documentation— only repeated correction along query results gradually precipitates them .

Cross-Domain Integration and Future Directions

After local validation, sub-ontologies (retail deposits, corporate credit, risk management) can be merged by extracting common concepts (e.g., "customer") while preserving necessary domain distinctions. Forcing a single shared definition too early yields vague statements like "entity with a commercial relationship" and loses precise filter conditions.

The long-term goal is domain knowledge reuse : new agents inherit accumulated enterprise-wide knowledge, reducing repeated concept explanation and metric recalibration. However, OceanBase notes this "global feedback" is still under exploration and not yet a delivered capability . Sub-ontology merging, conflict resolution, and stable reuse need further real-world validation.

Pursuing enterprise-wide unity upfront often leads to endless cross-department debates and a static knowledge base that decays with business changes. Answer one department's frequent questions correctly first, then expand incrementally , preserving the applicable scope and validation history of each piece of knowledge.

As business users continuously interact, the graph accumulates not just more tables and links, but the enterprise's internal consensus and disagreements on how metrics are calculated, how anomalies are investigated, and how different departments understand the same object. Previously scattered in code, reports, and tacit experience, these become reusable business knowledge for the next analysis cycle.

Product: DataPilot

OceanBase packages this approach into DataPilot , an ontology-driven Q&A product that enables DataAgent to locate metrics along business relationships and trace change causes. Harder than a single correct answer is building the knowledge structure that withstands repeated business scrutiny: every clarified metric, every validated association, every traced anomaly becomes a reusable asset for future analyses. Model capabilities will keep improving, but enterprise-specific definitions, experience, and judgment cannot be sourced from general models. Letting this knowledge be continuously verified, corrected, and inherited in real work is what moves DataAgent from occasionally getting one question right to reliably understanding enterprise business over the long term .