滴滴ChatBI技术实践：智能数据分析前沿评测

ChatBI 无疑是当前数据分析领域最受关注的热点。回顾 BI 产品的发展历程，它代表了降低数据使用门槛的终极愿景。但理想与现实之间，技术挑战与落地难题往往比预想中更为复杂。

今天，我们聚焦滴滴在这条路上的探索与落地实践。核心内容围绕以下几个板块展开：

1. BI 产品的演进脉络与 ChatBI 行业格局
2. 滴滴 ChatBI 的探索与落地经验
3. 智能 BI 背后的技术迭代逻辑
4. 问答环节实录

一、ABI 方向的演进与 ChatBI 行业现状

1. BI 产品的演进方向

BI 的发展本质上是一部解放生产力的演进史。从早期的固定报表，到后来的自助式 BI，用户终于摆脱了无休止的“提需求”循环。如今，智能 BI 成为新焦点。无论是早年的增强分析，还是当下火热的 ChatBI，核心目标始终如一：实现数据普惠，让每位普通用户都能以最自然的方式获取数据洞察。

2. 智能 BI 背后的技术演进

事实上，在 2023 年之前，增强分析已是一个成熟概念。它涵盖智能图表推荐、数据解读、预测分析、异动归因等功能，底层依赖机器学习和规则引擎。但坦白讲，那段时间这项技术并未引发大规模应用。技术能力虽有，但在帮助用户真正读懂数据、定位根因方面，仍存在明显断层。

转折出现在 2023 年。大语言模型（LLM）的爆发，像一根主线将之前零散的增强分析能力串联起来。用户可以直接通过自然语言提问，让系统完成数据解读、预测和深度分析。滴滴团队在 2022 年之前已积累了大量增强分析功能，当开始研发 ChatBI 时，这些“存量能力”恰好构成了新系统的坚实底座。

3. 当前 ChatBI 的两种探索路径

目前行业内 ChatBI 的探索大致分为两派，各有利弊。

路径一：以 BI 平台为核心。 这是多数老牌 BI 厂商的 Copilot 模式。优势在于启动成本低，平台已有的数据集可直接复用。但隐患也很突出：这些历史数据集本为报表制作人员设计，并非面向终端用户的即席分析，口径不一致，问答准确率容易出现波动。

路径二：以指标平台为核心。 这是不少新兴 BI 创业公司偏爱的 AI-Native 路径。先建立标准化的指标体系，再基于此开发 BI 产品。指标标准化、口径统一，能有效规避歧义。但缺陷同样现实——对基础设施要求极高，在大企业中推动全面指标标准化本身就是一项长期工程。

4. 对 ChatBI 行业发展现状的观察

总体判断是：ChatBI 仍处于早期探索阶段，前景广阔，但距离成熟还有显著距离。

从技术角度看：

• 用户意图理解能力已相当可观。
• NL2SQL（自然语言转SQL）取数的准确性是目前最大的瓶颈。
• 要实现真正的深度数据分析，对底层模型基座的能力要求仍需大幅提升。

从应用场景看：

• 在垂直、标准化的场景中，落地速度较快。
• 一旦面对通用、非标准化的数据源，挑战和难度会呈指数级增长。

二、滴滴 ChatBI 的探索和实践

1. 滴滴 BI 平台发展历程

滴滴的 BI 平台演进堪称行业缩影：从最初的可视化报表，到一站式报表，再到自助分析平台，最终迭代为今天的智能分析平台。每一步都围绕用户效率与体验的极致优化展开。

2. 滴滴 ChatBI 产品功能及落地情况

我们内部将 ChatBI 产品命名为“数小智”。它提供三种产品形态：Copilot、PC 站点和 IM 移动端。核心能力涵盖“找数、分析、SQL 辅助”，实现 All In One。值得一提的是，目前绝大多数流量由 Copilot 形态贡献，表明用户对这种“与数据对话”的方式接受度很高。

3. 滴滴 ChatBI 实践中的关键思考

这段历程中，有几个绕不开的关键点值得深入探讨。

（1）技术关键思考：如何提升 NL2SQL 准确率？

这是整个 ChatBI 最棘手的难题之一。我们从三个维度着手：

分析技术：LLM 升级 + 规模化训练集。 模型从最初的 LLM1 10B 一路升级至 LLM3 72B。同时构建了一个数万量级、具备半自动标注平台能力的训练集。每周线上巡检，快速修复用户提问的 badcase，持续迭代优化。

分析对象：指标标准化建设。 滴滴搭建了统一的指标平台，沉淀了超过 1 万个服务化标准业务指标。确保每个数据口径清晰唯一，指标加工逻辑统一封装，通过 API 直接对外服务。

分析产品：可信度增强设计。 为让用户敢用、放心用，我们在产品层面做了大量细节设计：模型拒答与反问机制、提问的可视化筛选、生成 SQL 的可视化展示，甚至支持将行业黑话传入 prompt。

整个 NL2SQL 流程中每一步都有损耗。从用户提问到最终渲染出图表，目前数据分析类问题的端到端解决率维持在 85% 左右。这个数值意味着，对于数据资产标准化不足的企业，要实现理想的 ChatBI 体验，绝对是一项长期工程。必须推动标准指标集建设，快速覆盖关键用数场景，逐步淘汰非标准分析源。

（2）产品关键思考：如何培养用户使用 ChatBI 的习惯？

技术探索再热闹，用户不买账就是徒劳。除了准确性，用户习惯是另一大障碍。很多用户仍习惯用老方法制作报表。

我们的解法是：基于 Copilot 形态，设计面向灵活分析场景的产品触点。例如，将其打造成报表组件的灵活筛选器；对报表上任一波动字段进行一键归因分析；对数据集或 Hive 表字段进行灵活探查。使用户在原有工作流中，不知不觉切换到 ChatBI 上。

（3）业务关键思考：如何提供深度价值？

问答取数只是第一步，真正的价值在于深度分析。ChatBI 产品必须具备灵活的异动分析和归因能力，而 ChatBI 的交互形态恰好能放大这种能力。

更进一步，我们利用“ChatBI + LLM”能力，在特定业务场景下每日自动生成业务数据分析日报。这对一线业务团队而言，是实实在在的效率提升。

4. 滴滴数小智产品架构

最终的产品架构覆盖 Copilot、PC 站点、IM 移动端三种形态。从数据分析、SQL 编写到数据查找，已全面落地。今年公司内部的落地情况基本符合预期。

三、走向 ChatBI 的未来

1. ChatBI 提供的产品价值分层

NL2SQL 问答取数只是 ChatBI 实现深度分析价值的基础底座。行业的期待远不止于此。真正高价值的分析，必然基于特定业务场景，而非通用问答能够解决。这正是 ChatBI 未来必须与业务深度绑定的原因。

2. ChatBI 深度价值的实现有赖于 Agent 架构的场景化落地

在分析深度的增强过程中，业务场景与背景知识的融入至关重要。例如，面对能源业务，系统必须理解其特有的关键指标和行业趋势，才能提供有针对性的分析建议，为决策提供有力支撑。未来，这将是 ChatBI 差异化竞争的核心要素。

四、问答环节

Q1：如果要快速搭建 ChatBI，有哪些基础设施可以复用？

A1：我们内部的基础模型也基于开源模型，例如当前使用的 LLM 72B，在此之上进行微调。但坦率讲，微调数据的积累非常耗时，开源数据集仅能提供基础起点，与真实业务场景差距巨大，必须自行大量补充。此外，高度依赖原有的 BI 基础设施。如果 BI 本身建设完善，当前开发 ChatBI 会省力很多。

Q2：指标解读具体指什么？

A2：指标解读包括指标的极值、均值、趋势以及指标间的相关性等基本信息。目前我们能做的，主要还是语义润色层面的改善。要真正发挥大模型价值，必须结合具体业务背景知识进行数据解读，这也是我们正在思考和探索的方向。

Q3：为什么要先做一次 NL2SQL 再转 DSL？

A3：这个问题很有价值。NL2SQL 生成的 SQL 灵活度太高，可能包含子查询甚至多表查询，对底层支持要求极高。DSL 相对而言能更好地解析这类复杂查询，并在模糊指标处理上做出一定优化。还有历史原因：在 ChatBI 系统建立之前，BI 平台已存在这一层，承担权限校验和与其他系统关联的任务。所以我们保留了这一架构层级，实践证明它能提供必要的帮助。

以上就是本次分享的内容，感谢各位。