为什么缺少本体（Ontology）的 agentic AI 分析会失败

New Story Why Agentic AI in Analytics Fails Without an Ontology by Dinesh P September 15th, 2026 TLDR Your browser does not support the audio element. byDinesh P@dineshp_1ha45qc byDinesh P|@dineshp_1ha45qcsr principal BI Analyst at Emerson Electric Analytics and Data Technology leader specializing in enterprise BI modernization, cloud data platforms, and AI-driven insights. I help organ Story's Credibility Your AI Agent Can Find the Data. It Still Doesn't Know What It Means. Every enterprise I talk to right now seems to be running some version of the same project: connect an AI agent to the data warehouse, let business users ask questions in plain English, and reduce the dashboard backlog. The demos are impressive. The agent writes SQL, joins tables, and returns a chart. Then it reaches production. Someone asks, "What was our revenue last quarter?" The agent confidently returns a number that is wrong. The SQL did not fail. The agent simply chose one of several fields that could plausibly mean revenue, and it chose the wrong one. In more than 18 years of building enterprise analytics solutions, I have watched organizations invest heavily in cloud warehouses, pipelines, semantic models, and visualization tools while underinvesting in the thing that determines whether any of it can be trusted: shared meaning. In my previous article, I argued that the dashboard is not the product. The decision is. Agentic AI raises the stakes because an agent does more than display data. It interprets data, reasons over it, and increasingly acts on what it finds. Its reasoning is only as reliable as the meaning we have encoded. That meaning sits across two layers that are often treated as interchangeable: metadata and ontology. They are related, but they solve different problems. An agent needs both. The Two Layers Your Agent Needs Metadata describes the data itself. It tells the agent where information lives and what is known about it: table names, column names, data types, source systems, owners, refresh timestamps, lineage, sensitivity classifications, and certification status. Metadata answers questions such as: What is this table? Where did it come from? When was it refreshed? Who owns it? Is it approved for use? Ontology describes the business meaning behind that data. It defines concepts and relationships: a Customer places an Order, an Order contains Products, an Invoice can become overdue, and a disputed invoice may be excluded from collectible receivables. Ontology answers a different set of questions: What does this concept mean? How does it relate to other concepts? Which business rules apply? A human analyst often carries much of this ontology in their head. They know that CUST_MSTR in one ERP and dim_customer in the analytics mart represent the same business concept. They know that one field called target is a sales quota while another is an operational forecast. They know what the company means by an active customer even when no column name explains it. An AI agent does not have that institutional memory. It has only what the organization makes available to it. Figure 1. A governed path resolves business meaning before the agent reaches physical data. The Trap Runs in Both Directions Metadata without ontology gives an agent highly searchable data with uncertain meaning. It can enumerate hundreds of tables and thousands of columns faster than any analyst. That speed becomes a liability when several fields look equally plausible. The agent can produce syntactically correct SQL and still answer the wrong business question. The reverse problem is just as real. Ontology without metadata creates an elegant conceptual model that is disconnected from the warehouse. An organization can define Party, Agreement, Product, Customer, and Invoice perfectly, but if those concepts are not bound to physical tables, columns, joins, and governed metrics, the agent cannot reliably query them. The practical value comes from connecting the two. Metadata makes enterprise data discoverable and governable. Ontology gives it meaning. Explicit bindings connect that meaning to the physical implementation. Why Agents Break Where Humans Cope Traditional BI has survived weak semantics for decades because people compensate. Analysts rely on tribal knowledge, old reports, hallway conversations, and colleagues who remember why a particular table should not be used. That informal layer can keep a reporting process alive, even when the underlying definitions are poorly documented. Agents remove that safety net. Agents scale mistakes A human analyst who misunderstands a metric may publish one incorrect report. An enterprise agent can repeat the same misunderstanding hundreds of times a day, in fluent language that makes the result sound authoritative. Agents cannot use knowledge that was never written down If the rule "exclude intercompany transactions from external revenue" exists only in someone's memory or inside a filter on one certified dashboard, the agent has no dependable way to discover that rule. Agents increasingly act on the answer Analytics agents are moving beyond question answering. They can trigger alerts, draft collection emails, reprioritize work queues, and pass results to other agents. A wrong number on a dashboard can mislead a person. A wrong number inside an automated workflow can cause the system to take the wrong action. A Concrete Failure: "What Are My Outstanding Receivables?" Consider a question I have engineered answers to many times: "What are my outstanding receivables by customer?" It sounds straightforward. In a real enterprise environment, the agent must resolve several business decisions before it can calculate the number. ·        Which customer representation is authoritative, and how duplicate accounts across ERP instances resolve to one customer. ·        Whether disputed invoices count, and where the dispute status is maintained. ·        How partial payments reduce the open balance. ·        Which date defines the reporting state: invoice date, due date, posting date, or warehouse load date. ·        How currency conversion is applied and which exchange-rate date is used. ·        Whether credit memos reduce the invoice balance or are treated as separate transactions. Those decisions are not obvious from a database schema. They are business meaning. Metadata can tell the agent where invoice amount, payment status, customer ID, and due date live. The semantic layer must tell it how those fields combine into the governed concept of outstanding receivables. Without that connection, the agent can produce a plausible SUM at the wrong grain with the wrong filters. The query may run perfectly. The answer can still be wrong. Layer One: Make Metadata Machine-Readable Most organizations already have the raw ingredients for this layer. Warehouses expose system catalogs and information schemas. Catalog platforms collect ownership, lineage, classifications, and documentation. Transformation frameworks carry model descriptions and tests. The problem is usually not the absence of metadata features. It is that the fields are incomplete, inconsistent, or written for people who already know the system. For agentic analytics, metadata needs to become an engineering artifact rather than optional documentation. A useful table description should state the grain, the important inclusions and exclusions, the unit of measure, the owner, and any restrictions that affect how the data can be used. Governance signals also need to be machine-readable. Certification status, sensitivity classifications, refresh expectations, and ownership should be available to the agent at query time. If a dataset is not documented or approved, the safest default is to keep it outside the agent's available context. This changes metadata from passive documentation into part of the execution contract. Layer Two: Encode the Business Meaning The ontology or semantic layer is where business concepts, relationships, and metric rules are defined once and shared. Some organizations may implement this through formal knowledge graphs. Analytics teams can start more pragmatically with governed semantic models that their BI and AI tools can consume. For example, the organization should not rely on an agent to infer the meaning of outstanding receivables from column names. The metric should already have an agreed definition: which invoices qualify, how disputes are handled, how payments and credit memos affect the balance, which currency rule applies, and who owns the definition. The technical representation is less important than the discipline behind it. Every recurring argument between finance, sales, operations, and analytics about what a number means is a candidate for explicit semantic definition. As relationships become more complex, such as product hierarchies, parent and subsidiary relationships, or concepts that span several business domains, a knowledge graph can make those connections traversable. The important point is that the agent should not be inventing those relationships during a user conversation. Figure 2. Ontology defines the business concepts; metadata connects those concepts to governed enterprise data. Wire the Agent to the Semantic Layer, Not the Raw Schema This is the architectural decision that separates a useful analytics agent from an impressive demo. The agent should reason over governed business concepts and resolve those concepts through metadata to physical data. It should not receive hundreds of raw tables and be asked to work out the business meaning on its own. Three production patterns make this much more reliable. Resolve the metric before generating SQL If a user asks, "How much do customers owe us?" the agent should first map that phrase to the governed outstanding receivables metric. Only after the metric is resolved should it generate or select the query. That way, the business rules travel with the metric. Prefer verified queries when they exist A library of reviewed question-to-query patterns gives the agent proven paths for common business questions. Novel generation still has a place, but a verified pattern should take priority when the intent matches. Allow the agent to refuse to guess If a user asks for active customers and the organization has never defined active customer, the agent should surface the ambiguity and ask for clarification. That is not a product failure. It is evidence that the governance layer is doing its job by exposing a definition gap instead of hiding it behind a confident answer. Governance for Agents Is Not Optional Once an agent becomes a consumer of enterprise data, governance has to apply to it just as it applies to people and applications. The agent needs an identity and an authorization model. Row-level and column-level security should follow the user or role it is serving rather than relying on an unrestricted service account. Its queries should be auditable so that teams can answer a basic question after the fact: Where did this number come from? Metric certification should influence what the agent can use, not simply what a catalog recommends. Sensitivity classifications should be enforced when the query runs. If the agent is not allowed to reveal a field, that field should not be selectable through an alternate reasoning path. The compliant path should be the normal execution path, not a set of instructions the agent is expected to remember. Design Backward From the Questions A practical way to build this foundation is to start with the questions the business actually asks rather than trying to model the entire enterprise at once. Collect the fifty questions that repeatedly appear in meetings, dashboards, emails, and analyst requests. For each question, identify the entities it references, the metric definitions it requires, the business rules that affect the answer, the physical data that implements those definitions, and the owner who can certify them. Every unresolved concept is a place where the agent may guess. Close those gaps in the semantic layer before expanding the agent's scope. An agent that answers thirty important questions correctly will earn more trust than one that can attempt three hundred questions with uncertain definitions. The Real Foundation of Agentic Analytics The conversation around agentic AI in analytics is dominated by model choice, orchestration frameworks, tool calling, and text-to-SQL accuracy. Those pieces matter, but they are not the foundation. The foundation is whether the organization has written down what its data means, agreed on those definitions, governed them, and connected them to the physical warehouse. Metadata makes data findable and trustworthy. Ontology makes it meaningful. The semantic layer connects business language to governed data so the agent does not have to guess. That is what turns an AI-generated answer from an interesting demo into something a business can actually use. The goal is not simply to build an agent that can query more tables. It is to build an agent whose answers can be acted on without someone reconciling the numbers in a spreadsheet first. ← Previous The Strategic Shift: Moving from a Reporting System to a Decision System About Author byDinesh P|@dineshp_1ha45qc sr principal BI Analyst at Emerson Electric Analytics and Data Technology leader specializing in enterprise BI modernization, cloud data platforms, and AI-driven insights. I help organ Read my storiesLearn More TOPICS Software Engineering #agentic-ai#data-analytics#ontology#ai#big-data-analytics#ai-agents#metadata#agents