ChatBI 的技术发展历史

能让业务用户以非常低的门槛来使用数据分析类产品，促进数据驱动的决策流程，一直以来是很多 BI 类产品追求的终极目标。ChatBI 也并不是在这条发展道路上的第一次尝试。

搜索式 BI

在 ChatBI 出现之前，就有一类交互形式类似搜索引擎的 BI 类产品，以 ThoughtSpot 最为知名。其背后使用的技术是较为传统的分词，实体识别，信息检索，模板填槽等。其所能达到的效果还是非常局限，例如：

• 对用户来说，并不是完全自然语言的提问方式，而是需要像搜索引擎那样，有一定的使用技巧门槛，比如必须使用特定的关键词才能命中用户想要查询的指标、过滤条件等。
• 为了提升灵活度，也可以通过在后台配置“同义词”的方式，来适应用户口语化的表达方式。但这背后会带来巨大的维护工作量，需要持续投入。
• 即使有了同义词的维护，还是无法真正达到自然语言的灵活度。例如有很多场景，即使是相同的词都会有不同的含义，“屈臣氏”可以代表一个销售渠道，也可以代表一个品牌名称，这类有微妙多义性的场景无法通过旧有技术来解决。
• 词槽模式相当于内嵌了固定规则的限制，比如基本上只能把问题规范成维度、指标、过滤条件几个组成，相比动态生成 SQL 可以表达的问题范围局限很多，比如复杂的 join 等。
• 如果深入体验，也很容易发现搜索式与对话式的区别，比如无法支持多轮对话，模型主动提问，难以扩展更多的意图场景（口径查询，业务咨询，智能洞察等）。

ChatBI 技术变革

在理解新的产品形态时，我们先要理解其背后发生了哪些重要技术的“跳变”。就像 Uber 的成功是因为 iPhone 内置了高精度 GPS，Instagram 的爆火是手机上普遍配备了高像素相机，这一轮 ChatBI 热潮的掀起，很大程度上是由于 ChatGPT 的推出，导致生成式人工智能的巨大变革。

正如很少有人会问 ChatGPT 相比 Google 如何，ChatBI 与搜索式 BI 的区别也是显而易见的。

• 对于搜索式 BI 来说，所有获得的答案都是已有的内容，范围和灵活度非常受限。而基于生成式 AI 的 ChatBI 则具有很强的灵活度和泛化能力，可以适应用户的各种个性化需求和快速变化的业务场景，动态生成全新的内容。
• ChatBI 具有真正的自然语言理解和交互能力，我们不再需要把“常识”通过各种人工维护的规则教给系统。
• 搜索式 BI 经常标榜自己是 100%正确的，这其实是个很有迷惑性的说法。是的，对于搜索到的内容本身，它可能是 IT 维护好的正确的逻辑，但是你的问题是否对应这个内容，是需要用户自己去判断的。就类似你在搜索引擎上搜到的各个网页，需要用户自己去评估哪个才最符合自己的需求。
• ChatBI 的目标相比搜索更进一步，希望帮助用户整合信息后直接提供“答案”，而不是一系列参考信息。这从根本上来说就具有更高的效益上限，在产品的扩展性上有很大的想象空间。

典型价值

在与早期客户共创过程中，我们发现对于一个早期产品来说，如何阐述其业务价值，是一个不小的挑战。在这里也聊聊我们的一些思考。

个性化需求

企业如果已经有 BI 系统，建设了成熟的报表，指标体系，数据预警推送等，感觉已经可以满足很大一部分业务的看数需求了。但我们在访谈客户时，经常会发现几个维度的变化导致了大量个性化需求的产生：

• 不同地区、不同业务导致关心的重点指标，计算口径等不同。
• 随着时间变化，业务也在持续快速变化，比如每月每周可能都有不一样的营销活动，公司自身也会按季度调整自身的目标，组织方式等。
• 业务系统、IT 基础设施变化带来的额外数据变更。

在唯一不变的就是变化的大背景下，我们发现业务和 IT 人员需要投入很多额外精力来“曲线救国”。比如：

• 因为大家关心的指标略有不同，所以一个解决方法是搞个非常宽的报表，让大家各取所需。
• 一个宽表搞不定，那就多来几个宽表，多来几个页面……
• 业务人员需要数据的时候，就到几个页面里分别找到几个需要的宽表，下载下来，分别挑选需要的部分在 excel 里拼凑起来。
• 报表和页面越来越多，越来越复杂，名字也很像，而且权限管理比较复杂可能导致很多业务人员看不到。需求满足不了，那就只能提工单取数。
• 工单太多也没法及时满足，于是很多业务只能从大数来做些近似推断，甚至直接凭经验和感觉去做决策了。

ChatBI 的灵活性，很大程度上非常有助于解决此类问题。

复杂查询

很多 ChatBI 产品的演示都是以非常简单的问题开始的，比如“昨天销量是多少”这类。但我们仔细想想，这种核心且稳定的指标，大概率在企业内部已经有成熟的报表体系可以满足了。或者说这类问题用上一代的搜索式 BI，可能也能基本满足。

我们在与客户共创过程中发现，ChatBI 在很多复杂查询的场景中具有很大的优势。例如：

上个月 X 品牌会员在抖音渠道的 90 天复购率是多少？

像这样的复杂问题，其实传统的 BI 系统，指标平台都不能很好地解决，因为“复购率”这个指标的定义过于复杂了。所以我们往往需要把这类复杂指标“下沉”到数据开发层面去解决，通过开发复杂的 ETL 去提前计算好这类指标。

但我们前面讲过，用户的需求是很个性化的，所以上面的问题会在各个维度出现变化，例如：

24 年 6 月全集团会员的 30 天复购率是多少？电商渠道的复购率呢？去年双十一对比前年双十一的复购率呢？...

想要在 ETL 层面解决这个问题，我们需要构建一个“无限宽”的大宽表才行，这显然是不现实的。

快速响应

这些复杂且个性化的需求，我们是不是通过堆人力可以来解决呢？管理成本是一个问题，另一方面来说，人工处理工单的反馈周期也比较长。我们发现很多时候一个业务上的营销活动可能就做一周，如果看数的需求提上去也需要一周后才能开发完成，那这个过程中就没有机会借助数据来敏捷改进我们的决策动作了。

另一个很有意思的话题是，很多 AI 类项目的确需要企业高层的信任和推动，所以也有很多项目会比较专注于满足高层的问数需求。但我们分析发现，一方面高层很多时候就享有优先服务的权利，另一方面来说高层问数时往往需要的是更深层次的洞察，而不仅仅是个表面的数字情况。

所以 ChatBI 类项目的确非常需要高层的推动，但其价值本身来说并不是满足“老板看数”，而是由老板来推动整个企业实现敏捷看数，提升数据驱动文化。

如何评估一个 ChatBI 产品

从表面上来看，ChatBI 类产品的界面和交互都非常简单（不像传统软件功能按钮一大堆），而光问问“昨天销量是多少”的问题也很难看出差异来。我们需要结合前面提到的 ChatBI 带来的业务价值，更有针对性地思考如何评估一个 ChatBI 产品。

效果

根据我们的经验，最重要的一个考虑维度还是 ChatBI 的回答效果。如果效果不好，回答都是错的，不管看起来再酷炫，回答速度再快也留不住业务用户。

另一方面，我们也经常看到铺天盖地的新闻，各种赶超 GPT-4 的大模型，也把用户的预期拉得很高。但如果大家平时有深入使用各类基于大模型的产品，应该会对于模型能力和差异会有更清晰的了解。

对于 ChatBI 场景来说，为了满足前面提到的复杂场景个性化需求，我们建议结合业务用户日常的典型问题，来构建相应的效果评估集，例如：

• 复杂指标的计算（如同环比，增长趋势，客群分析等），而不是对某一列做聚合就能得到结果的简单问题。
• 过滤条件测试，业务提问中用到的词往往与底层数据表中的取值不同，例如某个产品的简称会对应到数据表中的 SKU 全称。
• 多表查询，包括基于单表的多个子查询 join，典型的事实表和维度表 join 等。如果不支持 join，根据我们的经验，日常业务问题中有接近 50%的比例难以满足。
• 模糊提问，业务用户提问时，往往不会把维度、指标、过滤条件等非常清晰明确地表达出来，所以需要根据用户日常提“一句话”需求的特点来测试 ChatBI 是否能够理解。
• 范围外问题，很多时候业务还会涉及到当前数据范围无法回答，或者并非当前业务主题的问题，也需要进行测试。
• 多轮对话，用户往往会在一个聊天 session 中进行连续提问，这时候很多背景信息的处理会非常微妙，也很考验产品能力。

这一系列复杂评估问题的满足，背后涉及到 ChatBI 产品的技术路线、模型选择、Agent 流程完善程度以及 BI 基础能力的支持。感兴趣的同学也可以参考 我们观远数据之前做的一些技术分享^[1]。

还有很重要的一点是，这个评估也不是一次性的，随着业务知识、数据体系、主题范围、模型能力的不断变化，我们也需要持续进行效果评估，保证终端用户的使用体验。因此在 ChatBI 产品层面上，需要能够让维护人员很方便地做自动化评估，而不是按照项目制的方式，人肉测试验收完就不管了。

从更广义的完整产品角度来说，ChatBI 的落地方法论，对分析师 workflow 的理解程度和用户体验设计，包括整体的服务与培训等，也是持续保障整体落地效果中不可或缺的。在这方面观远也与不少业界领先的客户一起探索出了一些初步成果。

企业级能力

由于 ChatBI 的火热，我们也发现很多原先并不是从事 BI 软件开发的厂商也进入到这个领域来做一些产品探索。但从根本上来说，ChatBI 首先还是一款 BI 产品，尤其是在企业级能力方面的积累可以说是项目落地的必要先决条件。

首先我们还是需要有 BI 的基础能力，包括可视化，数据源支持等。如果产品本身只能连接某一两种数据库，或者只能上传 excel/csv 来使用，显然并不是一个成熟的企业级产品。

接下来最多用户关心的是权限管控能力，包括不同的用户是不是在问数查询时能够按照他们的组织架构、角色等赋予不同的细粒度行列权限。像一些 Chat2DB 类产品就很难满足，他们更多面向的是企业中的数据开发者用户。

接入 ChatBI 之后，我们也会发现各类 ad-hoc 查询的数量随着易用性的提高而上涨。所以底层查询引擎的高性能与高可用能力就显得愈发重要了。这也是专业的面向业务用户场景设计的 BI 产品所具有的优势。

最后，各种企业内部集成能力也非常重要，业务用户往往更习惯在企业门户，内部 IM 或其他业务系统中来方便地访问 ChatBI 的问数能力，必须具有一定的开放集成与账号体系打通的能力。

成本

随着大模型相关知识的逐渐普及，大家对于采购硬件，做大模型私有化部署这条路线也越来越“认清现实”了。在 24 年 9 月这个时间点，想要部署一个 gpt-4o 水平的私有化模型，其投入和运维成本还是非常巨大的（买硬件的价格用来买 API token，可以用上 10 年了）。加上模型厂商频繁的更新发布，越来越多客户也认可接入模型 API 可能是更容易低成本启动的一种方式。再加上数据分析是一个价值产出比较高的动作（相比于简单的文档问答之类），所以 API 调用的成本在早期推广阶段也基本可以忽略。

但另一方面来说，从采购 ChatBI 到业务用户能够在第一个真实场景上线使用，这期间所需要花费的冷启动成本，以及后续持续维护成本仍然是一个需要关注的方面。要让一个公开的模型学会企业内部的各种数据分析相关场景的专有知识，我们必须要向其提供企业内部已有的数据分析资产知识。显而易见，这部分知识积累最为丰富的地方就是已有的 BI 系统，我们可以从中抽取到指标定义，业务常用看板/订阅，数据表定义，数据血缘，ETL 定义等等重要的信息。而从数仓或者业务系统出发，则很难低成本地获取到这些知识。

此外对于持续运维的成本来说，如果技术方案并不是最大化利用大模型的泛化和生成能力的，那么在这块的持续人力投入也会比较高。

速度

在与一些客户沟通中，我们也发现会对 ChatBI 的响应速度有一定诉求的用户。但总体来说，效果仍然是远比响应速度更重要的。如果把 ChatBI 问数与提工单取数的时效性来进行对比，即使一个请求需要 1 分钟时间来返回，也远比人工处理来得高效。所以我们会倾向于在保障用户心理体验的同时，尽可能去提升回答的质量，而把响应速度放在第二位。即使大家使用相同的大模型，在这方面的取舍可能也会有所不同。

有意思的是，最近推出的 OpenAI o1 也与我们的思路不谋而合。为了解决更复杂的问题，提升解决的质量，让模型花更多的时间“思考”，而不是“凭感觉”直接给出一个答案。

安全

最后，安全也是一个比较有意思的话题，随着知识的普及，大家的看法也在逐渐发生改变。一开始绝大多数人都认为不能把任何数据发送给模型 API 提供商，或许在十多年前，大家也同样认为，企业的数据如果放在云服务、云数据库里，是非常不安全的，必须自建机房。

但慢慢地，除了一些严格监管的行业外，大家对于“上云”的做法也越来越能接受了。现如今，我们企业的文档可能放在语雀、飞书，企业内部的各种即时通讯都放在了钉钉、企微、飞书等，企业内的数据放在各种云服务器、云数据库也越来越普遍。我们也可以思考一下，对接大模型的 API，其实本质上与使用各类云服务也并没有什么不同（当然服务商得有相应数据安全合规的承诺保障）。这可能也需要一个市场逐渐接受的过程，尤其是应用侧得产生足够明确的价值。

当然了，现阶段我们也并不是把所有数据都发送给模型 API 的，而会精心选取与业务情况无关的“元数据”与大模型发生交互。这也一定程度上限制了某些产品功能的开发，比如让大模型用自然语言总结一下查询的数据之类。

典型问题

前面已经聊了评估 ChatBI 产品的一些思考角度，我们再换个方式来看一下一些常见的客户问题。

与非 BI 厂商对比

由于很多玩家都加入到了 ChatBI 产品的探索中来，所以会有不少人在选型时会关心期间的区别。前面我们已经聊到一些，这里再来总结一下：

• 大模型厂商：像 OpenAI 自己也做了 code interpreter，也算一种数据分析与大模型结合的应用，但总体来说还是偏概念产品且偏向于开发者，并不是面向企业级用户的产品。
• Chat2DB：通过自然语言直接与数据库交互的产品，同样也是更加专注于开发者群体，对于 SQL 生成的准确率要求很低，因为开发者可以自己检查和修改。另外也不具备像高级的可视化，权限管控，第三方集成等能力。
• 指标平台：本质上来说还是更接近搜索式体验，需要提前建设指标体系，且对于复杂指标需求难以满足（例如复购率这类客群分析的例子）。后面讲不同技术路线还会再聊到这个问题。另外数据分析本身相关能力也相对欠缺。
• 业务系统：缺少数据分析资产的沉淀，也很难打通多个数据源，更多是垂直业务场景中简单统计分析工作的提效。
• 各种 IM Agent：同样也是缺乏专业 BI 的能力，比较难满足复杂深入的分析场景。且更加局限于自身的生态，比如钉钉就不太会去对接火山引擎的各种产品等。

大模型私有化部署

对于某些行业来说的确是刚需，但在采购时，我们建议统一采购某一家的大模型，并明确后续运维、迭代升级的支持。有几方面需要考虑的：

• 目前比较领先的大模型厂商基本上每个季度都会发布新的模型版本，能力提升很快，半年前的模型几乎都没有什么使用价值了。
• 不要按照应用来分别采购大模型，重复投入建设看起来没什么必要。模型一般是通用能力与垂直能力一起提升的，这方面已经有非常多的例子证明了。
• 从很多大模型厂商分享出来的技术报告来看，GPU 集群出问题的概率远远高于成熟的 CPU、存储、网络体系，所以在运维这块要有足够的技术储备或预案。

如果没有强制要求，现阶段选择接入模型 API 服务是非常轻量高效的一个方案。

技术路线

如果大家关心 ChatBI 的技术细节，会发现虽然大家在 RAG 等方面还是比较一致的，但对于生成内容方面的确有几种不同的路线，我们可以逐一来分析下。

Text2DSL

顾名思义，这个路线并不是选择生成 SQL，而是某种中间语言，比如 API/DSL 来调用已有 BI 中定义好的指标或者计算逻辑。这里又会进一步区分两类：

1. 完全基于已有的指标/报表定义，这基本等同于回退到了搜索式体验。仅仅是利用了大模型的语言能力来提升问题理解能力，但不包含新内容的生成。如果你没有定义过一个叫“税前营收”的指标，那么提问时只会得到一个反问：“请问您是想要看营收额吗”。
2. 基于查询数据的 API 来“封装一下 SQL”，主要是为了优化一些复杂计算逻辑，比如排名、占比、同环比等。这个方案主要的区别是生成代码的具体形式的不同，以及 DSL 本身可能相比 SQL 会有能力局限。如果 DSL 本身就不支持一些复杂指标，那么也不可能生成出来，当用户问到“复购率”时，只能给出一个错误的答案。即使是看起来很标准的“同环比”，真正要支持各种比较方式其实非常困难，比如今年春节对比去年春节这类场景。

之所以出现了这个方式，很大程度上还是在早期大家普遍倾向于使用开源/私有化部署的模型，而这些模型的能力几乎不足以支撑生成复杂的 SQL，所以退而求其次，希望通过这种方式来降低对于模型生成能力的要求。

但我们要认识到：

1. 数据分析的本质复杂度并没有发生改变，如果你想让模型生成的内容更简单一些，那么就需要在人工建设方面多投入些，不断建设新的宽表、指标、卡片等，甚至还会因为这类资产的增多花更多力气来知识库的构建上，让模型能够选择正确的资产。这还是把工作量从 AI 转移到了人工上，这里还是会有不少机械重复的投入，没有利用上大模型的知识泛化能力。更重要的是，我们前面提到的 ChatBI 能够敏捷响应业务变化带来的个性化需求的核心收益被大大减少了。
2. 如果想设计一种 DSL 来简化 SQL，现阶段看起来可能也不是一个好方法。首先大模型训练过程中见过大量的 SQL 的代码，而自定义的 DSL 往往需要大量的 prompt 甚至 fine tune 来达到接近的效果。而当进入到复杂指标的深水区时，也会发现 SQL 本身的设计已经很优秀了，也难怪这么多年一直是最主流的数据分析使用语言。
3. 最后，我们也要用动态的眼光来看模型的能力。开源模型的能力也在不断赶上，之前行不通的路径，或许以顺应智能摩尔定律的角度来看，在未来或许并不是问题，更应该从 第一性的角度^[2] 来设计产品的技术路线。

Text2Code

典型代表是 OpenAI 的 code interpreter，过程中会直接生成 Python 代码来做数据分析。这个方式更多面向的是专业的数据科学家，需要有比较好的 Python 基础才能上手使用。从我们的观察来看，目前无论是国内还是国外，数据分析的主流语言和生态环境仍然是围绕 SQL 的，所以即使面向专业分析师，这条路线也仍然值得商榷。

当然优点是 Python 在高级分析、机器学习方面的确有优势。而且作为最流行的通用编程语言，大模型对其熟悉程度也非常高，生成代码可实现的功能范围会比 SQL 更加广阔。

Text2SQL

不得不承认 SQL 是一门伟大的语言，跟他同时代出现的很多语言都没有如此旺盛的生命力。我们在过去也尝试过各种在 SQL 基础上做进一步抽象、封装的尝试，但如前面所说，数据分析的本质复杂度已经很好地被 SQL 这门语言抓住了，其它大多数的尝试都只是把工作量转移到了数据分析链路的其它地方。对于 ChatBI Agent 来说，模型预训练中最熟悉的语言必定是 SQL，在寻找灵活度，准确度和人工投入的“帕累托最优”中，SQL 仍然是最好的选择。

相比“搜索指标”的做法来说，生成 SQL 才能算是具有了一定的学习泛化能力。例如用户在指标平台已经定义了销售额和复购率两个指标，当用户提问复购金额时，基于指标的做法并不能帮用户新建出一个指标出来。而在 SQL 生成场景中，则能够直接生成相应的 SQL，真正体现出“生成式 AI”的特性。

从技术角度，我们可以比较一下这几种路线：

结合业务视角，对于 ChatBI 能支持的问题复杂度和人力投入成本，我们可以大致得到以下的对比：

越靠近检索，受限制的代码生成方向，则能够解决的问题复杂度越低，且越需要更多人力投入来预先构建数据资产。越接近通用代码生成的方向，则能够解决问题的复杂度越高，也越能利用大模型的泛化能力，减少重复人工建设。这里 Text2Code 由于当前稳定性不如 SQL，且对于知识建设方面对于人员专业技能要求很高，所以在投入成本方面会高于 SQL。在未来这个情况或许会出现变化。

当然，这些路线也不是完全互斥的。未来我们或许会发现在一些智能洞察、AI 预测的场景下，结合生成 DSL，Python code 的方式也能很好地补充 ChatBI Agent 的综合能力范围，也可以灵活集成进来。

智能洞察

还有很多 ChatBI 的客户会关心所谓的“智能洞察”能力，首先我们需要明确一下这个“洞察”的定义是怎么样的。

有些产品在用户问数之后，会进一步用自然语言总结一下查询结果内容，比如用户问商品销量排名，在结果中不光有可视化展示，还进一步用自然语言复述了一下“销量最高的产品分别是 xxx，yyy，zzz”。这在我们看来并不属于智能洞察，本身价值也不大。就好比我们去看股票行情时，一般不需要再有个自然语言总结说现在的股价是多少，相比前一天下跌了多少，几乎没有带来增量的信息。

典型的洞察场景是用户在“what”基础上询问“why”，比如用户先询问了某个渠道的环比利润率，在进一步询问利润率下降的原因是什么。这也是当前绝大多数智能洞察产品所支持的能力，我们观远也提供了类似功能。

更进一步来说，有些用户会期望 ChatBI 能回答“怎么做”的问题，例如利润率下降了，我应该采取什么措施。在当前企业普遍的数据基础和决策类 SOP、历史数据积累情况下，要达到这个层级还是比较困难的。由于缺乏“决策数据”的积累，哪怕再聪明的算法，也只能给出一些常识性的泛泛而谈的建议，很可能达不到用户的诉求。

智能洞察的确是个非常重要的方向，我们也很希望能与有这类高级需求的客户一起，深入到业务场景中，去观察业务人员具体在进行决策时，是怎么做人工的洞察和策略设计的，是怎么从 BI 中的数据转化为会议报告的 ppt 的。只有深入洞悉了这个过程，才有可能提炼出更满足用户需求的产品。

自我进化

在聊到 ChatBI 项目的持续维护时，很多客户会关心 AI 是否能“自我进化”，用户越问系统就越聪明。

从目前大模型本身的原理来说，部署之后它的参数就是固定的，所以同样的问题问两次，并不能指望第二次它就变得更聪明了。但随着我们与客户深入合作与持续运营，我们也发现并不是企业内部所有的业务变化、知识更新等都需要人工来介入。目前我们已经发现了一些方式来让 ChatBI Agent 自我进化，相信到下一个版本我们就能开始体验到能够半自主进化，只需要少量人工干预的数据分析 Agent 的强大之处。

另外前面也提到模型本身的能力也在持续提升，使用我们观远的 SaaS 端 ChatBI 服务，就能持续享受到模型能力提升带来的对于各类复杂问题解决能力的提升。

未来展望

企业知识飞轮

从短期来看，ChatBI 可以提升业务问数的效率，减少专业分析师的重复人工投入。从长远看，我们发现未来 AI Native 的企业，要更加以企业知识库的构建与自我更新为核心，这样才能更大程度发挥出 AI 擅长的能力，让人类专注在目标设定、过程监督、reward 反馈等关键任务上，使得人机结合取得 1 + 1 >> 2 的效果。

我们也在产品设计层面积极思考与探索，立志于打造业界最先进的数据与决策知识引擎，赋能我们的客户率先完成 AI Native 的业务与组织转型。

企业与 AI 协同进化

从最近推出的 Open AI o1 模型来看，大模型正式迈入了强化学习的新范式，从以往“死记硬背”人类知识，转变为更自主的“探索，记忆，进化”范式。

一方面 AI 对于我们的知识需求形式会进一步简化，会更关注人类提出问题的质量、reward 反馈和探索过程的“元知识”；另一方面来说，也对于企业自身业务的敏捷程度提出了更高的要求，现实世界中的业务迭代速度成了我们协同进化的“瓶颈”。

由此可见，更敏捷的业务与组织能够获取的竞争优势被进一步放大了。如果不想被甩在时代的浪潮之后的话，让我们先从 ChatBI 赋能数据驱动的敏捷决策开始吧！