一文分享 ChatBI 实践经验

一、前言

大语言模型（LLMs）一路高歌猛进，给商业智能（BI）领域带来了什么新可能？

先简单回顾一下BI的几个关键阶段：

① 第一阶段（报表式BI产品）：用户提需求，数据研发取数、用图表组件渲染出可视化报表。按需开发，能满足基本查询需求，但开发成本高、静态报表场景有限、灵活性差，边际效益越做越低。

② 第二阶段（自助式BI产品）：在宽数据集上支持用户拖拉拽自助搭建报表。减少了数据开发依赖，灵活性也上来了，能适应多样化分析场景。但用户得对指标体系有深入了解，还得具备一定的配置技能，门槛依然不低。

③ 第三阶段（智能式BI产品）：大模型的理解和推理能力让用户只需点击按钮或对话，就能完成报表搭建和数据分析洞察。使用门槛大幅降低，让“人人都是数据分析师”不再是空话。

▲BI产品发展历程

二、大模型在BI领域的落地场景

经过近一年对“LLM+BI”业务场景的探索，主要落地了三个应用场景：

1、数据解读与总结

把结构化数据转化成用户易懂的文本报告，比如总结客户动态、分析员工行为轨迹。本质上是基于固定业务规则组装数据集，再利用大模型的归纳总结能力，按指令生成总结和建议。

<iframe src="https://mp.weixin.qq.com/mp/readtemplate?t=pages/video_player_tmpl&action=mpvideo&auto=0&vid=wxv_3784674984996634630"></iframe>

▲数据总结演示

2、动态可视化模板

自助报表分析阶段，用户得先理解指标和维度，才能拖拉拽搭建报表，对配置能力要求很高。常见做法是为不同行业提供多样化的报表模板，一定程度上降低了配置难度，但用户还得一个个翻模板找合适的，既繁琐又耗时。

智能化阶段来了：我们可以对报表模板进行标注和向量化存储。用户简单描述需求，系统通过“RAG+LLM”快速匹配模板，自动搭建出合适的报表。

3、对话式查数（ChatBI）

ChatBI（基于聊天界面的商业智能工具）主要支持用户用自然语言与数据交互，轻松完成业务数据查询。下面重点聊聊ChatBI。

三、有关ChatBI的实现方案选择

ChatBI是CRM产品智能化改造中遇到的挑战最大的项目之一，碰壁无数。最终效果不仅依赖大模型的性能，产品的实现方案同样关键。行业内讨论最多的两种方案是“Text2SQL”和“Text2DSL”。

Text2SQL

Text2SQL（Text-to-SQL）简单说，就是大模型把自然语言问题转换成结构化查询语言（SQL），让数据库理解并返回结果。

▲Text2SQL流程

这种方式有效利用了大模型的泛化能力，灵活性高，极大简化了数据分析过程。但挑战也不少：

• 生成SQL的准确性与可执行性：
  生成准确且可执行的SQL查询是一大挑战，需要大模型深入理解SQL语法、数据库模式和特定方言，同时依赖Prompt中对表名、字段及表间关系的清晰描述。

• 特定业务的复杂查询：
  比如跨表或跨数据集查询。特定业务场景的数据分析可能涉及多表关联（JOIN），要求模型具备强大的语义理解和逻辑推理能力。

• 性能问题：
  企业级数据查询中，宽表可能包含上百个字段，输入Prompt和输出SQL的复杂度会影响大模型响应时间。超过3秒的响应会严重影响用户体验，导致用户流失。

Text2DSL

Text2DSL（Text-to-DSL）是将自然语言转换为领域特定语言（DSL）。领域特定语言听起来抽象，但可以理解为一种更易用户理解的语言——比如在BI领域，它指从底层数据集中抽象出的指标、维度和过滤条件等报表配置化参数。

结合SQL这种数据库操作标准语言，Text2DSL既简化了用户表达，又确保系统能高效执行查询。基本流程如下：

① 用户提问时，大模型依据Prompt理解需求意图，将自然语言转换为结构化的DSL查询。
② 业务方根据规则将DSL转换为SQL，执行数据查询，并将结果可视化展示。

▲Text2DSL流程

举个例子：

“我要找到华南区上个月业绩表现最好的3名员工”

Text2SQL方案中，需要大模型理解后输出一段可执行的SQL：

SELECT
    f_user_name, SUM(f_amount) AS total_amount
FROM user_performance 
WHERE f_department_id='华南大区'   /* '华南大区'是部门名称 */
      AND f_date >='2024-11-01'     
      AND f_date <='2024-11-30'   /* 时间筛选为上个月 */
GROUP BY f_user_name              /* 对员工进行分组 */
ORDER BY total_amount DESC        /* 对订单成交金额进行倒序 */
LIMIT 3;                          /* 取前三 */

Text2DSL方案中，对SQL做了一层业务封装，只需要大模型识别提问后返回关键参数：

时间='上月'
数据范围='华南大区'
指标='订单成交金额'
维度='员工名称'
排序='倒序'

然后业务方基于大模型返回的参数（DSL），根据规则生成对应的SQL，执行查数。

可见，Text2DSL本质上是text to DSL to SQL的过程。小结一下：DSL是对SQL的一层抽象，SQL是对数据输出的具体执行。

Text2DSL方案也有挑战：搭建ChatBI需要依赖成熟的指标体系，查询的灵活性和扩展性受限于现有指标和维度，本质上是报表搭建参数智能检索召回后的自动化数据查询流程。

但相比Text2SQL，Text2DSL更易实现，而且在指标体系能满足大多数用户需求的情况下，能提供更准确、时效性更强的结果。

适用场景

两种方案各有适用场景和限制，选择最合适的方案需要综合考虑业务需求、BI基础能力、实现成本和用户体验。

• Text2SQL：
  适合没有特定复杂业务分析要求、需要高度灵活性和可扩展性的标准化数据分析场景，比如平台级BI工具。

• Text2DSL：
  适合业务场景明确、产品已建立成熟数据资产（如完善的指标体系和数据服务API）且分析深度可控的情况，比如企业内部系统或垂直业务软件系统的BI工具。

四、ChatBI的实现思路分享

接下来以负责的ChatBI项目为例，分享实践经历。

1、背景分析

所在SaaS CRM产品主要面向中小型企业用户，他们的BI需求更多围绕CRM产品内的数据进行分析，比如员工销售行为分析、客户转化分析等。

经过近几年的打磨，团队已经搭建了一套完善的指标体系，覆盖7个数据域，包含400多个指标。用户可以根据业务需求，通过指标、维度、过滤条件和图表组件等配置化参数，自助搭建报表来完成数据分析。

▲报表配置框架图

尽管自助分析能覆盖大多数日常需求，实际使用中仍有一些问题：

• 使用门槛：
  CRM产品用户主要是销售人员，配置报表前需要掌握“指标”“维度”等抽象概念，还要理解每个指标的具体含义，这对他们尤其困难。

• 数据获取链路过长：
  即使用户已配置了一个满足业务需求的数据看板，实际使用中仍需根据不同分析场景动态调整过滤条件来获取数据。例如报表默认配置“本周直销部的业绩数据”，若临时需要查看“上周渠道部的业绩数据”，得找到【时间】与【统计成员】过滤条件后切换。

以上问题也是BI自助分析阶段普遍存在的。因此计划通过ChatBI来解决这些问题。

2、Text2SQL or Text2DSL ？

ChatBI的效果与所选方案密切相关。前期调研中首选了Text2SQL方案，但多次测试结果未达预期。举例：

在当前自助分析BI产品中，用户可以在一张报表内配置多个跨数据集的指标，例如“通话次数”和“订单成交量”，这些指标存储在不同数据集中，且每个指标支持多个实时过滤条件。因此无法创建太多的大宽表，也无法进行大量数据预聚合。

▲支持跨数据集搭建报表

前端报表搭建实际上是对底层数据查询的业务封装。用户只需选择适合业务的指标来搭建报表，跨数据集的查询等复杂业务由业务方统一处理。

这种特定业务场景并不适用于Text2SQL方法，因为需要将大量元数据整合到Prompt中以支持跨数据集查询，与大模型交互时可能导致表字段识别不准和返回SQL响应时间过长。

最终团队确定采用Text2DSL方案。该方案本质上是在保持现有报表搭建框架的基础上，将用户手动选择参数和拖拉拽搭建报表的过程交由大模型完成。此外，对于常规SQL难以处理的特定业务查询，Text2DSL能通过原生的快速计算功能轻松实现。

3、方案设计

确定Text2DSL方案后，开始做ChatBI的业务方案设计。一开始遇到几个问题：

• 涉及7个数据域、400多个指标和50多个维度，若全部整合到Prompt中，可能影响大模型语义理解和意图识别的准确性。

• 用户对数据指标的叫法各异，例如“订单成交量”可能被用户称为“成交业绩”或“订单转化”。

因此，将BI元数据库和业务知识库进行了向量化存储。BI元数据库涵盖指标、维度、过滤条件、图表类型、同环比和排序等基本信息；业务知识库则包含行业特定术语和针对特定业务的SQL编写规则等垂直领域知识（维护知识库需要定期投入，但对提高语义解析和结果生成准确性至关重要，也是产品近年沉淀的重要数据资产。）

ChatBI初步业务流程如下：

① 知识召回：用户提问时，先通过RAG技术对知识库进行相似度检索，召回高匹配度的知识。

② 关键信息提取：针对召回的知识动态组装Prompt，让大模型进行语义理解与关键词识别。当无法识别关键词时，通过多轮对话交互，直至提取用户提问中的关键信息（如指标、维度、过滤条件等），再让大模型按Prompt中的规则返回DSL。

③ SQL转换：接收大模型返回的参数后，进行参数合法性和数据权限校验，确认无误后将DSL转换为SQL执行数据查询。

④ 数据可视化：查询结果后，进行数据报表组装，在前端可视化展示。

▲ChatBI业务流程图

落实这一流程时很快又遇到了新问题。方案在处理用户常规的结构化数据查询（如“昨天入库多少个客户”“上周打了多少通电话”）时表现良好，但在应对“总结欧汶本周新增客户的转化情况”或“欧汶最近的业绩表现如何”这类要求非结构化回答的问题时，就力不从心了。因为基于结构化SQL语言生成的回答过于生硬，有时甚至让用户有答非所问的感觉。

▲生硬的回答

因此引入了意图识别机制。大模型首先通过识别意图来区分用户是需要简单数据查询，还是针对特定业务的分析。后者会在SQL查询得到数据后，重新组装Prompt，再次利用大模型进行语义理解分析，并根据用户的提问提供针对性回答。

▲意图识别后再走一次LLM

4、产品效果

以下是ChatBI的初步演示效果

▲ChatBI演示

ChatBI主要聚焦于解答What（是什么）的数据查询。为了帮助用户探索Why（找原因）和How（给方案）的问题，形成完整业务闭环，从应用层面提供了以下方案：

• Why：
  在数据可视化环节，支持用户根据需要调整维度、指标和图表组件等，进行全面分析，并能够根据用户设定进行“多维分析”以及“下钻分析”。

▲帮助用户找原因

• How：
  通过“推荐提问”功能，针对不同指标数据异常的场景，提供针对性解决方案，如设置指标预警、调整销售目标、分配销售任务等。

▲给用户提供方案

团队还通过嵌入式将ChatBI产品整合到多端。PC端用户可以直接在输入框中输入文字；移动端用户则可以通过语音描述数据需求，快速查询数据，增强体验。

▲移动端语音描述需求

以上就是ChatBI产品实践的一个简要分享。落地过程中还需克服种种困难，比如报表配置参数的混合检索召回、用户提问的多轮会话识别、大模型参数提炼不准的应对措施等，此处不再细说。

五、结语

ChatBI是今年比较火的话题，也是ToB领域落地难度较大的Agent应用。但无论采用哪种技术方式落地，最终还是要以用户价值为导向，核心目的始终是帮助用户更便捷、更低成本地解决业务问题——这也是“SaaS+AI”的初衷。