本文将深入剖析商业智能（BI）与生成式模型结合带来的业务价值和技术实践经验。重点从三个视角和大家进行了交流分享。第一，从技术趋势和业务需求视角，论证了生成式智能 BI 必然技术趋势和带来的巨大业务价值；第二，从系统设计视角，介绍了百度数据中台 ChatBI 设计思路和关键点。第三，从新技术实践实践视角，介绍了 Chat BI 在百度落地过程中遇到的问题和解决思路。

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

　　1. 技术视角

　　从技术视角看，不管是什么新的技术，想要成为新的趋势，本质是要做到技术的普惠，让更多的人可以更低成本地使用从而产生更多的价值，BI 的技术趋势也是一样的。我们先来回顾下 BI 在这么多年的发展过程中经历的几个阶段：

　　第一阶段（报表式 BI 产品）：随着大数据技术的产生，HDFS 技术和 MR 技术开始在各个公司流行，产生了此类 BI 产品。其往往需要按需开发，由分析师或经营者提出数据需求，再由专业的数据研发同学进行取数开发。需求开发成本和周期长，边际成本高，限制了其广泛应用。

　　第二阶段（自助式 BI 产品）：近些年随着计算机底层硬件的不断发展以及数据查询技术的迭代（如 MPP 架构、向量化、内存化技术等），和早期 MR 时代对比，取数效率有了 10 倍以上的提升。量变带来质变，在多数场景下，在宽数据集上进行动态查询就能满足性能需求，这减少了对数据的开发依赖，用户可通过 BI 平台进行自助化、可视化查询，使得 BI 技术更为普及。

　　当前第三阶段 BI 技术展现出明显的技术趋势，即智能化的发展。随着大模型技术的出现和快速发展，笔者认为现有 BI 产品可以通过和其结合，更具智能化，做到更好的技术普惠。

　　第三阶段（智能式 BI 产品）：借助大模型强大的理解、推理能力，屏蔽更多的底层细节。用户无需再考虑使用哪个平台、数据从哪里来以及查询方言等问题，只需要自然语言对话，即可完成取数、洞察分析等流程。极大地降低了使用门槛，人人都可以是分析师。　　

　　2. 业务视角

　　从业务视角看，核心在于新的技术是否能带来足够的业务价值：

　　首先，从业界近些年对 NL2SQL（自然语言转化 SQL）的研究看，LLM-base 的解决方案在各个评测集上都取得了更好的分数，这降低了问数场景的使用门槛；其次大模型的超强理解能力使其能够总结背后数据报表的本质，并进行多轮交互式沟通，提高效率。记忆能力和推理能力使其能够在数据分析中执行逻辑推理，解决问题，为用户提供更为深入的数据分析支持。

　　大模型对业务带来的价值主要体现在两个方面：

　　（1）降低新手门槛：chat 交互、AI 解读、数据洞察等能力的建设，实现数据分析的普及，使得全员都能够轻松进行数据分析；

　　（2）存量用户提效：通过智能化 BI 技术（例如：自动化纠错 SQL、生成周报等），对于已经使用 BI 产品的同学，可以帮助提升效率。　　

　　其次，从长远视角来看，随着大模型的进一步发展，未来可能演变为一种数据助手的状态，为每个人提供实时的、个性化的数据支持。

　　在进行数据分析和报表生成的过程中，我们不仅仅是在处理数据，更是在追求数据的深层次理解，以指导未来业务的发展趋势。现有可视化 BI 工具与人的协同方式有其局限性，限制在细分的纬度上。然而，随着 AI 的介入，我们可以期待更为精细化的分析，应对上千个维度的实际经营需求。

　　在 AI 模型逐步成熟并掌握了长期记忆的情况下，它也可以通过学习用户习惯，变得更为主动。想象一下，在互联网行业工作的人每天早上醒来，不再需要花费数小时查看报表，而是收到一份 AI 生成的短文，简洁明了地指示着昨天业务的重点，哪个维度出现问题，需要重点关注。这样的智能推动无疑提高了工作效率。

　　最后，对于这样的愿景，有人可能怀疑其是否能够实现。然而，AI 时代的摩尔定律已经开启，算力的不断提升、模型水平的升级以及推理成本的逐步降低，都在向我们展示这一可能性。

　　以发展的眼光看待，技术进步的速度往往是惊人的。正如在十年前无法想象将 10G 或 20G 的游戏搬移到移动手机上一样，当前 AI 时代的发展也为我们带来了巨大的潜在价值。

　　因此，我坚信 AI 将成为第三代技术探索的热点，先行突破的公司将具备先进的生产力，这一领域的价值将会是巨大的。　　

　　02 ChatBI 的设计理念和平台介绍　　

　　1. NL2SQL 需要具备的能力

　　目前开源的 NL2SQL 的工具一抓一大把，但是想要落地到真实工程上，往往还有很长一段路要走：

　　（1）需要具备完备 BI 能力：比如丰富的图表能力、复杂的 BI 计算（例如：留存率、周日均、同环比），对 SQL 的生成提出了更高的要求；

　　（2）需要具备极速的交互速度：交互耗时包含推理耗时和查询耗时，对话式交互需要及时的响应，如何基于 PB 级的数据进行秒级的 Chat 交互挑战很大。

　　（3）需要保证结果的正确性：数据分析是一个严肃的场景，结果要尽可能得正确，以满足实际生产环境的需求。

　　2. ChatBI 的实现

　　下面开始介绍一下我们实现的 ChatBI 平台，当前平台核心设计思路关键点聚焦在解决如下两个问题：

　　使运营人员能够通过自然语言提出问题，平台能够及时作出取数应答；

　　如果运营人员发现了数据异常波动，可以通过平台进行波动归因分析。

　　下面截图展示百度的 Chat BI 的核心能力，以进一步说明平台的实际效果。

　　首先，用户可以通过自然语言对话进行数据分析。例如，用户可以查询最近 3 天内女性用户的 DAU 波动情况，系统会自动识别用户的意图，并在相应的数据集中选择指标和维度，生成相应的图表结果。这些结果可以被保存到仪表盘来进行复用。　

　　其次，我们对 AI 原生产品创新，在产品首页和输入框为用户推荐了常用查询意图，用户可以选择并提问。查询结果并非模型生成，而是来自存量的业务功能仪表盘数据，数据置信度高且支持一键跳转至图表所在仪表盘，来满足一些高频场景。　　

　　最后，展示的是多维度波动归因服务。例如，在新增用户查询结果上，用户可以在城市级别和操作系统维度进行归因分析，系统将在秒级内产出归因结果，帮助用户快速定位数据波动的原因和贡献度，提高业务决策的效率。　　

　　03 ChatBI 背后的技术内幕　　

　　该平台已经在线上运行了一段时间，吸引了众多用户的使用。接下来，我们将探讨在平台开发过程中所面临的困难以及应对方法，这里分别讨论上一章提到的 3 个 NL2SQL 的产品化挑战。

　　1. 完成的解决方案

　　我们首先面临的挑战是 BI 的完整性。一个真实可用的 BI 平台，不仅包括生成基本 SQL，还需能够产生丰富的图表，并与平台实现联动。解决这一问题的思路有两种：

　　方案一：BI 平台对接在 NL2SQL 模型下游，进行 SQL 的查询和可视化操作。

　　方案二：让大型语言模型与现有 BI 平台结合，模型不仅返回 SQL，而且返回 BI 平台的操作指令集，实现模型对平台的控制。

　　方案一的问题在于模型和 BI 并没有打通，只传递一个 SQL 给到 BI 平台，会导致大量BI特有功能缺失。例如应该选择什么图表样式进行展示、结果修改保存能力等。方案二的思路类似于让大语言模型执行生成 PPT 或打游戏的任务，通过模型控制 BI 平台，可以做到更加灵活优雅。例如由模型确定数据展示图表样式、由模型确定是否在展示当期数据的同时也展示同环比信息。

　　2. 端到端性能

　　第二个挑战是产品的端到端性能，其中主要包含了模型的推理性能和数据的查询性能两个耗时：

　　推理性能方面，现在的文心一言模型性能可以达到秒级的实时推理，且在持续优化中；

　　查询性能方面，数据存储基于百度内部强大的 MPP 引擎基座，业务平均查询能够做到 2-3s 内完成。

　　3. 准确性

　　第三个挑战是产品的准确性，因为数据平台提供的数据往往要求百分百的准确性，而大模型则是基于概率生成的，这成为了数据平台和模型结合中最关键的一点。在此背景下，我们在优化模型本身的基础上，还尝试了在产品层面做了大量设计，来提升准确性。

　　先来说下模型本身的优化，这里主要是通过 prompt 优化和 SFT 微调两个手段进行的。

　　首先是 prompt 优化，一个良好的 prompt 应当包含三个关键元素：

　　在 prompt 中明确定义模型的角色，使其能够在特定领域完成任务；

　　对任务的描述要清晰见解，避免歧义，确保模型不会理解错误；

　　提供一些 few shot，可以让模型更好地学习范式。

　　此外，在 BI 场景下，prompt 中还需要添加相关的表结构和一些业务私域的增强知识，以确保模型能够理解一些业务黑话。

　　而 SFT 微调则是在模型预训练完成后，通过补充业务场景的样例数据，对模型本身进行二次训练，让模型更加擅长解答该业务场景的手段。对于 SFT 来说，训练样本集尤为重要。从我们微调的踩坑经验来看：样本的质量一定要高，样本中出现的 bad case 会导致模型学习到不正确的模式；数据要充足，要尽可能覆盖更多场景，才能得到更高的泛化能力。

　　我们在 ChatBI 的冷启动阶段让用户标注少量数据，然后在平台转动起来时，依赖用户反馈的数据飞轮（用户在使用过程中会提供踩或赞的反馈），进行进一步微调，从而形成一个闭环的反馈机制，提升模型的准确度。

　　这里额外介绍下我们 SFT 训练使用的百度云 千帆平台，平台提供了模型开发的一站式解决方案，其集成了样本数据管理、模型调优（含 SFT）、模型部署等功能。不需要使用者具备模型训练、部署的专业知识和 GPU 资源，极大地提升了我们的模型迭代效率。　　

　　在模型的真实落地过程中，还有 2 个模型的前后置优化，这里也一并和大家分享一下。

　　首先是选表问题，在实际的业务场景下，同一个业务会有成百上千个表，每个表的字段也比较多。如果打包扔给大模型，让它进行选表选字段，会受到 token 的限制，且模型理解成本也比较高。选表是一个典型的分类问题，我们将选表阶段从大模型 prompt 中抽取出来，采用独立小模型进行。分类模型已经比较成熟，正确率比较容易做到很高，同时耗时也可以做到毫秒级。

　　第二个是模型小概率会出现字段幻觉问题，模型返回的字段并不是表中真实存在的，而是一个相近的字段名称。这里主要是通过 SFT 进行强化，同时对模型结果后置添加校验，来缓解幻觉问题。　　

　　最后，我们再讨论下在产品层面如何通过设计进行准确性提升。

　　在用户输入层面，我们发现用户经常会有独特的口语表达方式，还可能缺失查询所需要的必须信息。为此，我们会在用户输入的时候，以 sug 的形式给用户推荐一些相关的结构化表达话术，引导用户使用结构化的提问方式。

　　在结果展示层面，在给出数据结果的同时，我们还会将查询语句结构化地呈现给用户，这里包含查询的数据集、数据纬度、数据指标、过滤条件等等。这样用户可以直观地检查查询是否正确，如果发现有错误，也可以通过在界面上进行二次修改，得到正确的答案。

　　另外，BI 平台历史上已经沉淀了大量的业务图表，其实很多用户的问题都可以通过已经存在的图表来进行满足，对于这种情况，我们会直接召回已经存在的结果，而不是进行生成式产出。　　

　　总体而言，产品的目标在于追求模型生成的准确率达到 100%。然而，当准确率未达到 100% 时，通过一系列产品创新进行兜底，以确保用户依然能够得到可靠的查询结果。

　　04 落地效果

　　该平台已经在线运行了相当一段时间，得到了多个业务线的使用，累计用户数量达到了数百人，用户的评价也普遍较好。

　　用户认为智能查询和智能分析方面表现出色，其中两个主要优势受到用户青睐：

　　首先，该平台降低了用户的门槛。特别是对于一线运营销售等用户，他们无需学习复杂的技术，只需提出一个问题，即可获得结果。这有效地降低了他们的操作难度，解决了实际工作中的问题。

　　其次，老用户发现使用 chat 的效率比传统的拖拽方式更高。以前制作仪表盘可能需要查找数据集、资料等多个步骤，而现在只需通过提问即可生成报表，用户只需保存即可。即便在生成结果不理想的情况下，也可以进行二次修改，这比从零拖拽要方便不少。