ChatBI：基于文心一言的生成式数据分析技术探索

先说几个核心判断：BI技术从诞生到现在，经历过报表式、自助式两个阶段，如今正站在智能化的门槛上。大模型的出现，让这个转变变得更加现实——不仅仅是能对话取数，而是真正让“人人都是分析师”这件事有了落地的可能。

当然，技术是一回事，落地是另一回事。从百度内部的ChatBI实践来看，这里面既有设计理念的选择，也有不少实打实的技术硬仗要打。

BI技术的发展与大模型带来的新机遇

1. 技术视角

聊技术趋势，说到底绕不开一个词——“普惠”。任何一项新技术，只有当它能让更多人、以更低的成本去使用，才能真正产生规模化的价值。BI的发展史，本质上就是一部降低门槛的历史。

往远看，从HDFS和MR技术开始普及的时候，报表式BI产品就已经登场了。那时候的玩法很直接：分析师或者业务方提出需求，数据同学按需开发。好是好，但每张报表的开发周期长、边际成本高，自然也就限制了它的普及范围。

后来，硬件在进步，MPP、向量化、内存化这些技术让查询效率提升了不止一个量级。量变带来质变，在大多数场景下，宽数据集上的动态查询就能满足性能需求。于是，自助式BI产品开始流行起来。用户不再靠提需求等排期，而是自己上BI平台拖拖拽拽就能完成取数。这个阶段，BI的使用门槛降低了，但还远远不够。

现在，第三波浪潮来了。大模型的理解能力和推理能力，可以把底层细节彻底屏蔽掉。用户不用管数据是哪个平台的，也不用管查询语言怎么写，只需要用自然语言对话，就能完成取数、洞察、分析。这个思路如果能跑通，带来的量级变化就不是10倍了。

2. 业务视角

从业务的视角来看，新技术的价值最终要看它能解决什么问题。

先说近的。NL2SQL这个研究方向，业内早有评测，LLM-base的方案在多个公开榜单上都表现最好，这意味着“说话查数”这件事的门槛已经降到了历史最低。大模型不仅能理解用户的意图，还能在对话中举例、纠偏、追问，也能基于上下文进行逻辑推理。这就让数据分析从一个“单向取数”的行为，变成了“多轮交互、层层深入”的过程。

落到具体价值上，主要体现在两个方面：

• 降低新手门槛
  ：Chat交互、AI解读、数据洞察，这些能力让那些不会写SQL、不会拖报表的一线运营和销售，也能直接上手做数据分析。

• 存量用户提效
  ：对于已经在用BI平台的老用户，智能化技术可以帮助自动纠错SQL、生成周报，把日常重复性劳动减下来。

再看远一点。随着大模型的持续进化，未来真正的形态可能不再是“人问机器答”，而是一个“主动的数据助手”。它可以学习你的习惯，记住你的偏好，在你每天醒来的时候，就推送一份用自然语言写成的核心指标概览。哪些维度出了异常、哪个方向需要关注，一清二楚。这才叫真正的提效。

可能有人会问：这事儿靠谱吗？看看AI时代的摩尔定律就知道了。算力在涨、模型在强、推理成本在降，每一条都在朝着这个方向走。把时间轴拉长，技术进步的速度往往是惊人的。就像十年前谁能想到手机上能跑下10G、20G的游戏？同样的道理，AI带来的产业变革，才刚刚开始。

所以，可以确定的是，智能化将是第三代BI技术的核心主题。谁能先跑通，谁就能拿到下一阶段的生产力红利。

ChatBI的设计理念和平台介绍

1. NL2SQL需要具备的能力

现在市面上的NL2SQL开源工具确实不少，但真要在生产环境落地，还有三道坎要过：

• 具备完备的BI能力
  ：不只是取数，还要能生成丰富的图表，能处理复杂的业务计算，比如留存率、周日均、同环比。这对SQL生成的质量要求就高了。

• 极速的交互速度
  ：实时对话意味着推理和查询都不能卡壳，面对PB级的数据要做到秒级响应，这是硬指标。

• 结果的正确性
  ：数据分析是严肃业务，错的结论比没有结论更麻烦。生产环境下，正确率必须尽可能逼近100%。

2. ChatBI的实现

下面说说百度内部的ChatBI平台。它的核心设计思路，其实就围绕两个问题展开：

• 运营人员能不能用自然语言直接问数，平台及时给出答案；
• 如果看到数据出现异常波动，能不能自动帮助归因分析。

从实际效果来看，用户可以通过对话完成数据查询，比如“最近3天女性用户的DAU波动情况”，系统会识别意图、选择指标和维度、生成图表，并支持保存到仪表盘复用。

产品层面也做了一些原生的AI交互创新。比如在首页和输入框里，为用户推荐高频的查询意图，用户可以直接选择提问。这里的查询结果不是模型生成的，而是来自存量仪表盘数据，数据置信度高，还支持一键跳转。

多维度波动归因是另一个亮点。比如在对新增用户的查询结果上，用户可以在城市级别或操作系统维度做归因分析，系统在几秒内就能给出归因结果，帮助快速定位数据波动的来源和贡献度。

ChatBI背后的技术内幕

平台上线之后，走了不少弯路，也踩了不少坑。下面重点说说前面提到的那三个产品化挑战，分别是怎么应对的。

1. 完整的解决方案

第一个挑战是BI的完整性。一个真正能用的BI平台，不能只生成SQL，还要能控制图表展示、与平台联动。解决这个问题有两种思路：

• 方案一：让NL2SQL只负责出SQL，查询和展示交给下游BI平台。但问题在于，模型和BI是割裂的，很多BI平台特有的能力（比如图表选择、同环比展示、结果修改保存）就用不上。
• 方案二：让大语言模型直接控制BI平台——不只是返回SQL，还返回平台的操作指令集，相当于让模型学会“使用”BI。这种思路更灵活也更优雅，模型可以决定用什么图表展示、是否展示同环比信息等等。

实际情况证明，方案二的效果要好得多。

2. 端到端性能

第二个挑战是整体响应时间，主要分为两部分：

• 推理性能
  ：基于文心一言模型，推理已经能做到秒级，还在持续优化。

• 查询性能
  ：底层依赖MPP引擎，业务平均查询在2-3秒内完成。

两个耗时加起来，整体交互体验是跟得上的。

3. 准确性

第三个挑战是准确的底线。大模型是概率生成的，但数据平台要求的是百分百的准确。这个矛盾怎么解决？我们从模型层面和产品层面两个方向同时入手。

，主要靠prompt优化和SFT微调：

• 一个好的prompt，要包含三个关键元素：明确定义角色、清晰描述任务、提供few shot样例。同时在BI场景下，还要补充表结构和业务黑话的增强知识。
• SFT微调，就是在预训练的基础上补充业务场景的样本数据。这里的关键是样本质量一定要高，bad case会让模型学到错误模式；数据要充足，覆盖的场景越多，泛化能力越强。

在冷启动阶段，我们让用户少量标注数据；平台跑起来之后，依靠用户“踩/赞”反馈形成数据飞轮，不断微调，闭环提升准确度。这里用到了百度云千帆平台，它集成了样本管理、模型调优、部署等能力，帮我们省去了自建训练环境的成本。

也很关键：

• 选表问题。实际业务中，一个业务有成百上千张表，每个表字段还多。如果一股脑全丢给大模型选表，token限制和模型理解成本都太高。我们把选表抽出来，用一个小模型做分类处理。分类模型成熟度高，正确率容易做高，耗时还能控制在毫秒级。
• 字段幻觉问题。模型偶尔会输出不存在的相近字段名。这个问题主要靠SFT强化和结果后置校验来缓解。

同样在为准确性兜底：

• 用户输入时，用sug推荐结构化的话术，引导用户规范提问，减少模糊表达和缺失信息。
• 结果展示时，把查询语句的结构化信息展示出来——用的哪个数据集、纬度指标、过滤条件，一目了然。用户能直观检查，错了可以直接在界面上改。
• 对于历史仪表盘中已经沉淀的图表，会优先召回存量结果，而不是每次都靠模型生成。既能保证准确，也能省成本。

说到底，模型生成的准确率理想目标是100%，但在实际做不到的时候，要靠产品层面的创新来兜底，让用户始终能拿到可靠的结果。

落地效果

平台上线至今，已经有多个业务线、数百名用户在用了，反馈普遍不错。

用户的直观感受集中在两点：

• 门槛降了
  。尤其是一线的运营和销售同学，不需要学复杂技术，一句话就能拿到数据，解决了他们以前“想查但查不了”的问题。

• 效率高了
  。老用户也发现，用Chat做数据分析比传统的拖拽方式快很多。以前做一张报表可能要查数据集、翻资料，现在直接提问就能生成，保存就完事了。就算生成结果不理想，二次修改也比从零拖拽方便不少。