滴滴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 厂商的玩法，可以看作是 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 最难啃的骨头之一。我们从三方面入手：

模型从最早的 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 差异化竞争的关键所在。

四、问答环节

A1：我们内部的基础模型也是基于开源模型，比如现在用的 LLM 72B，在此基础上进行微调。但说实话，微调数据的积累非常耗时，开源数据集只能提供基础起点，离真实业务场景差距很大，必须自己大量补充。此外，很大程度上取决于你原有的 BI 基础设施。如果 BI 本身建设得就很完善，今天开发 ChatBI 会省力很多。

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

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

以上就是本次分享的内容，谢谢大家。