From MCP to Dynamic Ontology: How Enterprises Can Choose the Right ChatBI and Data Agent Architecture on Apache Doris

When enterprises begin building ChatBI or Data Agents, the hardest question is often not whether a large language model can generate SQL. It is how to choose a cost-effective architecture that can evolve with the company’s existing data foundation, business complexity, and risk profile.

A team that has just completed a real-time data warehouse and wants to validate the value of conversational analytics should not use the same architecture as an enterprise that already has a mature metrics platform and needs to coordinate analysis across sales, supply chain, production, and service. Direct NL2SQL is not inherently wrong. When the data scope is limited, business definitions are clear, and access is read-only and low-risk, it can be the fastest way to validate value. The problem begins when enterprises take an architecture designed for a proof of concept and expose it directly to hundreds or thousands of tables in a complex production environment, leaving schema discovery, business semantics, permissions, security, cost, and result correctness to a single probabilistic model.

This session will first explain why Apache Doris is well suited to serve as the trusted data and execution foundation for enterprise ChatBI and Data Agents. In addition to unified SQL execution for real-time analytics, Doris can use views and materialized views to deliver Agent-facing data products, establish execution boundaries through access control, masking, workload management, and auditing, and allow Agent platforms such as Dify to discover metadata, inspect SQL execution plans, and run read-only queries through the official Doris MCP Server.

On that foundation, I will present a route-selection framework based on an enterprise’s current capabilities:

1. Exploratory PoC: raw schemas + Doris MCP + a read-only Agent. This route offers a low-cost, fast-feedback way to validate demand in a small, low-risk scope. It is not suitable for exposing thousands of raw tables directly to a model, and an executable SQL statement must not be mistaken for a correct business answer.
2. Data-product route: domain-oriented wide tables, views, or materialized views + a constrained query surface. This route suits enterprises with a basic data warehouse that want to improve the accuracy of high-frequency operational analysis. Data modeling reduces the model’s search space and is often more effective than adding more prompt instructions, but it also introduces data-product development and maintenance costs.
3. Metrics-layer reuse: an existing metrics platform or semantic API + LLM intent mapping. This route suits enterprises that already have well-governed metric definitions, permissions, and service interfaces. The model primarily understands the question and maps parameters instead of reinventing metric SQL. It provides stable definitions but is better suited to standardized metric Q&A than to long-tail analysis involving cross-domain objects and states.
4. Dynamic-ontology-oriented semantic layer: unified modeling of business objects, relationships, events, states, metrics, and permissions. This route fits complex cross-domain analysis, evolving semantics, and scenarios that require explanation, regression testing, and auditing. It is not the starting point for every enterprise. Rather, it becomes valuable when data products and metric governance have reached sufficient maturity and a more advanced semantic model and execution-control layer is required for complex Data Agents.

To test these judgments, we used the same Apache Doris data snapshot, model, and official MCP Server with an enterprise data environment containing more than 1,000 tables. We evaluated the approaches with 100 executable questions and 20 additional questions covering clarification, security, and capability boundaries.

Finally, I will use YuanYi’s dynamic-ontology-oriented semantic layer as a concrete implementation example for complex enterprise scenarios:

Natural-language question → Semantic Catalog / Candidate Graph → YuanYi Logic Plan (YLP) → Query Guard → Doris SQL → Answer Contract → Trace / Audit

Dynamic ontology is neither another layer floating above the semantic layer nor simply a longer prompt. It is a higher-order modeling kernel inside a stronger semantic layer. It extends metric semantics to business objects, relationships, events, states, and controlled actions. Through intermediate representations, compilation, permissions, and regression mechanisms, the large language model is responsible for understanding and planning, while system boundaries remain responsible for facts, security, and traceability.

Attendees will leave with a route-selection map that can be used directly in enterprise architecture discussions, a phased implementation playbook from PoC to production, and a practical understanding of the costs, benefits, limitations, and common pitfalls of each route. The session will not argue that every enterprise should build a heavyweight platform from day one. Instead, it will help teams choose the smallest viable architecture for their current stage while preserving the right extension points for what comes next.

Speaker:

Yijia Su: Founder of YuanYi Intelligence, Apache Doris Committer, Apache Doris 2025 MVP, Doris-MCP Contributor, and PowerData Community Initiator

Yijia has long contributed to the Apache Doris community and to enterprise implementations of real-time data warehouses, ChatBI, and Data Agents. His current work focuses on enterprise semantic layers with dynamic ontology as the modeling kernel, and on explainable, regression-tested, and auditable infrastructure for Data Agents.