滴滴ChatBI技术实践：智能数据分析的前沿探索与应用

1. ABI 方向的演进及 ChatBI 领域现状

2. 滴滴 ChatBI 的探索和实践

3. 走向 ChatBI 的未来

4. 问答环节

分享嘉宾｜王涛滴滴产研负责人

编辑整理｜大民

内容校对｜李瑶

出品社区｜DataFun

ABI 方向的演进及 ChatBI 领域现状

1. BI 产品的演进方向

BI 产品的发展经历了从报表式 BI 到自助式 BI 的演变，而当前智能 BI 则吸引了大家的广泛关注与大量投入。无论是早期的增强分析技术，还是如今新兴的 ChatBI 产品形态，其核心目的都在于降低用户利用数据的门槛与成本。我们期望通过融入 AI 的洞察力，使用户能够更加便捷地访问并应用数据资源，从而实现数据普惠。

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

在 23 年之前，或许有些同学已经听说过增强分析这一领域。增强分析技术涵盖了智能图表、数据解读、数据预测、异动分析、智能归因等多个方面，这些功能的实现依赖于机器学习和规则引擎等底层技术。然而，那时这一领域似乎并未引起广泛的热潮，处于一种相对平稳的发展状态。尽管我们拥有了这些技术能力，但在帮助用户获得深刻的数据洞察和满足期望的结果方面，似乎还有所欠缺。

自 23 年起，业内众多公司在传统 BI 基础上进行了大量探索，技术上涵盖了智能问答、意图识别等领域。有趣的是，在 ChatGPT 时代，我们通过 LLM 大模型的意图识别能力，将以往的增强分析功能都串联了起来，用户现在可以通过自然语言进行数据的解读、预测和异动分析。事实上，我们团队在 22 年之前已经开发了许多增强分析的功能，现在开发 ChatBI 时，发现这些功能被完美地整合在了一起，形成了 ChatBI 的坚实基础。

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

目前，业内对于 ChatBI 的探索呈现出百花齐放的态势。无论是创业公司还是传统BI 优势企业，都在这一领域投入了大量精力，显然对此抱有极高的期望。这一领域的发展主要有两条路径。

一条路径是以 BI 平台为核心，许多拥有传统 BI 优势的企业倾向于采用这种方式。他们侧重 Copilot，以 BI 平台为起点，构建和运用 ChatBI。这一路径的启动成本相对较低，BI 平台背后已有成型的数据集，这些数据集可直接用于提问和初步分析。然而，这一路径也面临着一定的历史遗留问题。因为这些数据集并非专为提问和终端消费者而构建，而是主要服务于报表制作人员。因此，数据集的非标准化可能导致问答的准确率相对较低。

另一种路径则是以指标平台为中心，我们可以看到许多新兴的 BI 创业公司倾向于采用这种方式，他们更注重 AI-Native，即先建立指标平台，再在此基础上搭建 BI 产品。这一路径被视为实现 ChatBI 的理想方式，因为指标是标准化的，问答口径也相对清晰，可以有效避免重名、同义或模糊字义等问题。然而，这一路径对基础设施建设的要求相对较高。在大型企业或公司中，要实现指标的全面标准化，需要付出一定的成本。这些公司的产品在形态上大同小异，都是基于数据集的问答形态，相似度很高。

4. 个人观察到的 ChatBI 行业发展现状

总体而言，ChatBI 似乎仍处于行业探索的早期。

从技术现状来看：

用户意图理解的准确性已得到验证。
NL2SQL 取数的准确性有待进一步突破。
深度数据分析所依赖的模型基座能力还有待大幅提升。

从应用现状来看：

垂直标准场景（标准数据源）落地速度较快。
通用非标场景（非标数据源）落地挑战较大。

滴滴 ChatBI 的探索和实践

1. 滴滴 BI 平台发展

滴滴 BI 平台的发展和业内相似，从可视化报表平台，到一站式报表平台，再到自助分析平台，最后到今天的智能分析平台。

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

数小智是我们内部 ChatBI 的落地产品，产品形态包含 Copilot、PC 站点、IM 移动端，核心功能包括找数、分析、SQL 辅助 ALL In One，其中绝大部分流量是在 Copilot 这个形态下贡献的。

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

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

分析技术：LLM 升级 + 规模化训练集

LLM：LLM1 10B>LLM2 33B->LLM3 72B
NL2SQL 微调数据：数万量级 + 半自动标注平台
每周线上巡检：快速修复用户提问的 badcase

分析对象：指标标准化建设

滴滴统一指标平台建设：1w+服务化标准业务指标
数据口径清晰唯一，指标加工逻辑封装在指标平台内
通过 API 对外直接服务指标

分析产品：可信度增强设计

模型拒答、反问机制
提问可视化为筛选项
生成 SQL 的可视化
行业黑话支持传入 prompt

在 NL2SQL 的流程上，存在许多节点会影响准确率。首先，关于用户提问的处理，会经过多轮问题的合并，整合成一个问题进行输出，这一环节的准确率高达约 98%。接下来，整合后的问题会进入意图识别的小模型，该模型负责将问题的意图归类。这一环节的模型准确率大约维持在 96% 左右。随后，如果是一个数据分析任务，会遇到 LLM 72B 模型，这是一个经过高质量微调数据精心调校的自研模型。当面对异动分析、数据解读或数据预测等类型的问题时，通常会直接调用 NL2API 功能。普遍情况下会进入 NL2SQL 取数环节，在这一环节，我们首先利用模型生成一个 SQL 的结果，随后将其转化为 DSL。最后通过 SQL 或者调用 API 生成智能图表。

在整个流程中都会有所损耗，综合来看，数据分析类的问题，目前端到端的解决率为 85% 左右，端到端是指从用户提问到最终渲染出图表。

要实现理想态的 ChatBI 对数据资产标准化建设不足的企业而言，会是一个长期工程。报表数据集和底层 Hive 表，指标维度定义不规范，并非面向终端分析人员建设，灵活问答准确率低。需要推动标准指标集，快速覆盖公司内各种关键用数场景，并逐步替代其它分析源。

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

虽然对 ChatBI 的产品探索如火如荼，但用户层面尚未到深度依赖的程度。准确性固然有影响，但用户习惯也是很大的因素。

基于 Copilot 形态，设计面向灵活分析场景的产品触点。例如充当报表组件的灵活筛选器、报表上任意波动字段的归因分析、数据集/Hive 表的字段灵活探查。

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

ChatBI 产品要能够提供灵活的异动分析和归因能力。异动分析是用户迈入深度分析的刚需，也是智能BI 的典型产品功能，ChatBI 产品形态对该功能起到灵活放大的作用。

生成业务数据分析日报：借助 ChatBI + LLM 在特定的业务分析场景下每日自动生成类似上图的业务数据分析日报。

4. 滴滴数小智产品架构

最终，我们的产品架构涵盖了 Copilot、PC 站点、IM 移动端的三种主要产品形态。从分析到 SQL 再到找数，都已实现了全面的落地实施。就今年而言，在公司内部的整体落地情况符合预期。

走向 ChatBI 的未来

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

NL2SQL 问答取数只是 ChatBI 实现深度分析价值的基础，行业的期待远高于此。而深度分析价值的实现是要基于业务场景的，非通用性分析。

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

在分析深度增强的过程中，业务场景和背景知识的融入至关重要。这包括了解特定行业（如能源业务）的关键指标和趋势，以提供针对性的分析建议，为决策提供有力支持。

问答环节

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

A1：我们内部一些基础模型也是基于开源模型去做的，包括这块 LLM 72B 的开源模型，然后在这个模型的基础上进行微调。但是微调数据的过程相当耗时，并且需要大量积累资源。尽管存在一些现成的开源训练数据集可供使用，但在应对我们真实的业务场景和用户提问时，这些开源数据集所能提供的帮助只是一个基础起点，远不能满足我们的全部需求，仍需我们自己补充大量内容。

除此之外，很大程度上依赖于原先 BI 的基础设施，如果 BI 的基础设施原本就建设得相对完善，那么今天开发 Chat BI 就会省力很多。

Q2：指标解读是指什么？

A2：指标解读指的是指标的极值、均值、趋势以及指标间的相关性等基本信息。目前，我们尚未发现除了提升语义润色效果之外的其他深度价值。因此，我们还需要思考如何更好地利用大模型，结合真正的业务背景知识进行数据解读，发挥出更好的效果。

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

A3：NL2SQL 的过程中灵活度过高，包含了一些子查询，甚至可能涉及多表查询，这些都对底层支持提出了很高的要求。如果底层支持不够完善，就可能会遇到解析困难的问题。相对而言，DSL 至少能够对这些复杂的查询进行较好的解析和处理，此外，对于模糊指标的处理，也有部分可以在此阶段进行一定程度的优化。

还有一个历史原因，因为在 Chat BI 系统建立之前，BI 平台就已经存在这一层，并且承担了一些权限相关的校验任务，以及与其他系统的关联工作。因此，在 Chat BI 的架构中，我们依然保留了这一层，因为它确实为我们提供了一些必要的帮助和支持。

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

文章版权归作者所有，未经允许请勿转载。

THE END