从 MCP 到动态本体：企业如何基于 Apache Doris 选择 ChatBI 与 Data Agent 技术路线

当企业开始建设 ChatBI 或 Data Agent，真正困难的往往不是“大模型会不会生成 SQL”，而是如何根据自己的数据基础、业务复杂度和风险等级，选择一条成本可控、能够逐步演进的技术路线。

一个刚完成实时数仓建设、只想验证自然语言问数价值的团队，和一个已经拥有成熟指标平台、需要跨销售、供应链、生产与服务协同的企业，显然不应该采用同一套架构。 直接 NL2SQL 并非天然错误：在数据范围有限、口径清晰、只读低风险的场景中，它反而是验证价值最快的方式。 问题在于，很多企业把适合 PoC 的方案直接推向数百、上千张表和复杂生产环境，于是将 Schema 发现、业务语义、权限、安全、成本和结果正确性同时交给了一个概率模型。

本次演讲将首先回答：为什么 Apache Doris 适合作为企业 ChatBI 与 Data Agent 的事实和执行底座。Doris 不仅提供面向实时分析的统一 SQL 执行能力，还可以通过视图与物化视图沉淀面向 Agent 的数据产品，通过权限、脱敏、负载管理和审计建立执行边界，并借助官方 Doris MCP Server 让 Dify 等 Agent 平台以通用工具方式完成元数据发现、SQL Explain 与只读查询。

在此基础上，我将给出一套面向企业现状的路线选择框架：

1. 探索型 PoC：原始 Schema + Doris MCP + 只读 Agent。 适合小范围、低风险地验证需求，成本低、反馈快；但不适合把上千张原始表直接暴露给模型，更不能把“SQL 执行成功”误认为“业务答案正确”。
2. 数据产品路线：主题宽表、视图或物化视图 + 查询范围约束。 适合已经有基本数仓能力、希望先提升高频经营分析准确率的企业。它通过数据建模缩小模型搜索空间，通常比继续堆 Prompt 更有效，但会带来数据产品建设和维护成本。
3. 指标层复用路线：既有指标平台或语义 API + LLM 意图映射。 适合已经拥有较完善指标口径、权限和服务接口的企业。模型主要负责理解问题和映射参数，而不是重新发明指标 SQL；优势是口径稳定，局限是更适合标准指标问答，对跨域对象关系、状态和长尾分析的覆盖有限。
4. 动态本体导向的语义层：业务对象、关系、事件、状态、指标与权限的统一建模。 适合跨域分析复杂、语义持续变化，并要求解释、回归和审计的场景。它不是所有企业的起点，而是在数据产品和指标治理达到一定基础后，为复杂 Data Agent 提供更高阶的语义建模与执行控制。

为了验证这些判断，我们在同一 Apache Doris 数据快照、同一模型和同一官方 MCP Server 上，借助一份包含 1000 余张表的企业数据环境，并使用 100 道可执行题和 20 道澄清、安全及能力边界题进行对照测试。

最后，我将以元一动态本体化语义层的实践为例，介绍一条更适合复杂企业场景的实现链路：

自然语言问题 → Semantic Catalog / Candidate Graph → YuanYi Logic Plan（YLP）→ Query Guard → Doris SQL → Answer Contract → Trace / Audit

动态本体不是悬浮在语义层之上的另一层，也不是一个更长的 Prompt。它是更强语义层内部的高阶建模内核：把指标语义扩展到业务对象、关系、事件、状态和受控动作，并通过中间表示、编译、权限与回归机制，让大模型负责理解和规划，让系统边界负责事实、安全与可追溯性。

大家将带走一张可直接用于企业方案讨论的路线选择图、一套从 PoC 到生产的分阶段实施建议，以及对不同路线成本、收益、天花板和常见误区的真实判断。演讲不会主张所有企业都建设一套重型平台，而是帮助团队先选择当前最小可行架构，再为下一阶段留下正确的演进接口。

讲师:

苏奕嘉：元一智能创始人、Apache Doris Committer、Apache Doris 2025 MVP、Doris-MCP 贡献者、PowerData 社区发起人

长期参与 Apache Doris 社区建设与企业实时数仓、ChatBI、Data Agent 落地。目前专注于以动态本体为建模内核的企业语义层，以及可解释、可回归、可审计的 Data Agent 基础设施。