我要投稿

有数 ChatBI：大模型驱动下的数据分析技术探索和实践

发布日期：2025-01-29 20:35:01 浏览次数： 3090 作者：DataFunTalk

导读在当今数字化时代，数据分析技术正经历着前所未有的变革，大模型的出现为数据分析带来了新的机遇和挑战。网易数帆的 ChatBI 作为一款创新的数据分析工具，在大模型驱动下，融合了 AI 和 BI 的优势，为企业提供了更加智能、高效的数据分析解决方案。本文将深入探讨 ChatBI 的技术实现原理、产品功能、应用案例以及未来展望，展示其在数据分析领域的独特价值。

本文主要围绕以下五点展开介绍：

1. 网易有数 BI 产品简介

2. AI 技术给数据分析带来的机遇与挑战

3. ChatBI：网易有数 AI+BI 的产品新模式探索

4. ChatBI 的技术实现原理

5. ChatBI 的开放能力及落地应用案例

分享嘉宾｜张佃鹏网易网易有数BI技术负责人

编辑整理｜李硕

内容校对｜李瑶

出品社区｜DataFun

网易有数 BI 产品简介

我们的定位是做一款企业级一站式数据分析平台，灵活满足企业数据收集、多维度分析、多端展示等不同阶段需求，具备业内领先的高性能保障和权限管控能力。充分提升用户数据分析体验，降低使用门槛，用数据连接组织各角色，实现数据驱动决策。

上图是我们整体的产品功能架构图，整个产品使用流程可以分为下面几步：

数据接入：目前我们已经支持了市面上常用的 40 多种数据源，包括关系型、分布式、文本型、API 等数据源类型。
数据准备：数据源接入以后，我们可以通过新建一些自定义 SQL、或者通过拖拽式的 ETL 等方式做数据的加工和清洗，将数据抽取到我们内置的高性能 MPP 仓库，从而提升性能。
数据建模：通过拖拉拽的方式进行数据建模，在建模阶段我们支持跨引擎构建物化视图，通过物化视图 + CK 大宽表查询优势，可以将报表查询性能发挥到极致，另外最近一年我们上了关系模型的功能，可以彻底解决因为笛卡尔积产生的数据膨胀问题。
数据应用：有了宽表模型定义以后，我们就可以基于模型做一些报告、取数、大屏等数据应用，图中蓝色的部分是我们最近 2 年发布的两个新的产品模块，一个是数据表格，解决中国复杂式报表制作的场景，比如财务报表、监管报送、会计审计等报表，另外一个功能是今天要分享的 ChatBI 模块，可以利用大语言模型的能力直接通过自然语言提问的方式进行数据分析。
数据分发：最后还可以将做好的数据应用，通过邮件、分享链接、微信小程序、移动端等方式分发和共享出去，让更多的人看到数据并提供决策。

02 AI 技术给数据分析带来的机遇与挑战

1. BI 技术的演进趋势

整个 BI 的发展和演进的趋势可以总结为下面三个阶段：

传统 BI：随着大数据技术的崛起，传统 BI 产品开始流行，这个阶段主要面向 IT 人员，分析师或者业务提出数据需求，由 IT 人员进行报表的开发，技术门槛高，周期也长。
敏捷 BI：目前大部分 BI 产品都处在这个阶段，得益于 MPP 等性能优化技术的加持，业务人员可以自己通过拖拽式的方式自助完成报告制作，整体效率提升 10 倍以上。
智能 BI：”智能 BI“这个概念很早大家都在提，但是因为技术的原因一直没有做起来，伴随着大模型技术出现和快速发展，”智能 BI“ 才开始真正的普及，通过自然语言对话的方式进行数据分析，进一步降低了使用门槛，普及所有人，让每个人都可以做自己的数据分析师。

2. AI 技术给数据分析带来了哪些机遇？

伴随着 AI 技术的崛起，给数据分析领域也带来了很多的机遇，首先结合大模型的理解能力，通过 NL2SQL 和 NL2API 等方式可以轻松实现自然语言的数据查询能力；另外大模型的上下文记忆能力，让多轮交互数据问答实现成为可能，并可以进行问题的自动纠错等能力；在数据理解和数据推理上，我们借助大模型可以实现图表的智能解读以及数据的归因洞察等高级分析功能。据敏

整体上通过大模型的赋能，给业务带来的价值主要体现在三个方面：数据分析的门槛更低、效率更高、更加智能化。

3. AI+BI 面临的问题和挑战

在 AI + BI 相结合的过程中，我们也遇到了不少问题和挑战，这些问题应该每个做智能 BI 厂商都可能面临的问题：

准确性和可信问题：大模型有个致命的问题就是幻觉，但是数据分析本身又是一个很严谨的事情，另外缺少行业知识和属性，再加上用户问题缺少规范化，如何解决数据的信任问题成了智能 BI 最大的挑战。
查询性能问题：智能问答都是很随机的问题，查询复杂性会更高，包括大模型推理、数据查询、数据渲染都有一定的耗时，会让性能问题更加凸显。
客户场景落地难点：如果没有完善的工程化能力的辅助，AI 的价值很难变现，客户场景问题千奇百怪，我们如何运营和优化成了在客户场景落地的难点。

03 ChatBI：网易有数 AI+BI 的产品新模式探索

1. ChatBI 产品架构

ChatBI 是网易数帆 23 年推出来的新产品模块，基于原有敏捷 BI 系统统底座基础上进行研发和设计，主要目标是做一个对话式的数据分析助手，降低用户数据消费的门槛，实现对话即分析的能力，下图是 ChatBI 的整体产品架构图：

ChatBI 整个产品是基于现有 BI 能力的基础上构建的，所以有天然的优势，包括数据建模、数据查询、数据可视化、用户权限体系等能力都不需要二次设计和开发。另外光靠 AI 能力远远不够，真正可落地的 chatBI 离不开工程化技术的加持，所以这里搭建了一套完善的运营体系以及高效的问答辅助工具用来提升准确率和用户体验。有了运营能力以后，我们就可以通过 chat 的方式实现智能取数、多轮问答、数据分析等高级能力。另外在问答应用上，我们支持很多对外开放的能力，支持开放的数据问答 API，集成页面的嵌入等，另外我们将 ChatBI 作为 Copilot 助手，辅助我们各种数据应用的开发。同时支持问答收藏、分享、移动端等数据分发的能力，可以实现和业务系统的完美融合。

2. ChatBI 的产品定位：锚准数据可信

我们 ChatBI 整体的产品定位是瞄准数据可信，从而解决 AI + BI 分析最棘手的问题，用户对大模型返回的数据的信任其实是 ChatBI 可用可落地的前提，既要追求查询的准确率更要追求数据的可信。下面主要从数据可理解、用户可干预、过程可验证、产品可运营四个方面阐述如何打造可信的 ChatBI。

数据可理解：

首先我们利用大模型的技术能力，能够准确理解用户自然语言提问和业务数据，同时自研的 NL2SQL 大模型生成 SQL 的准确率高于 GPT4，在同环比、分组、排序、子查询等方面都有增强，保证用户的需求是可理解的。

过程可验证：

我们将 SQL 的执行过程翻译成用户可以理解的语言描述，这个描述一定代表了背后 sql 的执行逻辑，用户可以通过数据解析快速验证数据的对错，从而保证了数据的百分之百可信。

另外对于专业的人员，可以通过查看 sql 判断数据的正确性，逻辑 sql 是大模型基于逻辑表生成 sql，物理 sql 是背后数据库真正执行的 sql，通过这两种方式保证了查询过程的可理解。

用户可干预：

我们将查询的过程结构化，转换成修改的 DSL，用户可以自己去调整查询条件，比如筛选、分组、聚合方式等，从而保证即使在数据有问题的情况下，可以让用户快速干预获取准确的数据。

产品可运营：

另外我们提供了一套成熟的运营方案，很多 AI 的产品都是非常依赖运营的，这里运营也是 ChatBI 可落地的关键一环。我们提供了知识库、训练语料、提示词等成熟的运营手段来提高问答的准确率；产品方面也会提供运营的培训、最佳实践等能力；同时会不断地强化大模型调优 badcase，从而让整个运营过程形成闭环，保证 ChatBI 是可持续健康迭代的。经过调优后，大部分场景的准确率都可以达到 90% 以上。

04 ChatBI 技术原理

1. ChatBI 的技术架构方案设计

上图 ChatBI 的整体技术架构图，最上面是前端展示层，当用户输入问题后会经过我们意图识别模块，意图识别主要包括数据查询、归因分析、指标解读等能力，如果发现是数据查询会经过我们下面的核心查询流程，包括前处理模块、自研 NL2SQL 大模型、后处理模块、数据查询基建层四个模块：

前处理模块：

首先前处理模块主要是基于用户配置的提示词、知识库、筛选集等信息，使用智能选表和检索增强等技术优化 prompt，最后输入给自研的 NL2SQL 大模型。

自研 NL2SQL 大模型：

自研的 NL2SQL 大模型是经过专门调优训练的，在聚合、排序、排名、同环比等方面都做了非常大的增强，同时支持一些自定义的特性，比如 UDF 函数、筛选集等。其中同环比函数由于涉及到子查询生成的 SQL 较为复杂，就是通过自定义 UDF 函数能力实现的。

后处理模块：

最后大模型生成的逻辑 SQL 会进入我们后处理模块，这个模块实现会对一些幻觉问题（比如字段或者表名不存在等）进行重试，接着会把逻辑 SQL 转换成我们定义好的 DSL 结构，有了这个 DSL 以后就可以对结果做一些校正澄清，也就是我们的智能感透出功能，比如用户问”东的销售额“的时候，我们发现“东北”和“华东”里都包含了”东“这个关键词，会提示用户让用户选择确认。另外用户也可以配置一些后处理的规则，比如添加默认筛选器、返回指定字段等，这些自定义的规则会在规则引擎中进行处理最后生成一个完整的 DSL。接着根据这个 DSL 进行图表类型的推断、图表可视化配置、字段格式配置推断等，最终生成我们的有数 BI 图表配置结构 VisualQuery。

数据查询基建层：

有了 VisualQuery 进入了架构图图的右侧，是我们有数 BI 已有的数据查询基建层，包括可视图图表推导引擎、数据计算引擎、数据查询引擎三个核心模块，最终生成可执行的物理 SQL 并将数据返回给前端进行展示。

整个技术方案细节会比较多，左边是我们新开发的 chatBI 相关的技术能力，右边是原先 BI 已有的技术能力，整体构成了我们 chatBI 的技术架构图。

2. 自研 NL2SQL 大模型

（1）自研大模型介绍

我们自研的 NL2SQL 大模型主要以提升自然语言生成 SQL 代码的准确性为训练目标，使用了大量的数据进行预训练和微调。对于模型基座的选择我们评测了 20 多个国内外模型，最后选择表现最优的网易玉言模型进行训练。支持私有化部署和多语言提问。其中数据构造这块我们结合了金融、教育等 10 多个领域的数据，最终生成的标准的 PG SQL。另外我们 saas 环境每天都有大量的真实客户的访问数据，用这些真实客户数据可以不断的持续微调优化大模型。在评测方面，我们建立了合理的评测指标体系，整体上准确率高于 GPT4。

（2）SQL 标注规范

SQL 标准规范的重要性

这里为什么要提到 SQL 标注规范呢，首先在真实的业务场景下，用户的问题偏口语化，比如问”今年的销冠是谁？“，专有模型可能不会理解销管的意思。

另外用户的问题一般比较模糊，可能有多个答案，不同人理解也可能都不一样，比如”每个季度的销售额分布“这个问题，是需要所有年份加起来每个季度的销售额呢？还是要看每年每个季度对应的销量呢？

另外很多 SQL 写法不同，但是结果都满足，比如“查询 ≥1 且 ≤5 的数据的平均数”，可以用“WHERE num BETWEEN 1 AND 5”表达，也可以用“WHERE num ≥ 1 AND num ≤ 5”实现。因为存在这些问题，所以我们必须要有一套 SQL 标注规范来解决这些歧义问题。

如何进行 SQL 规范标注

我们的大模型核心资产其实就是这些 SQL 训练集，训练集的数据质量非常重要，直接会影响到最终的准确率，高质量的数据集是建立在规范的定义上的：

我们定义了一套标准的 SQL 规范和数据表的规范，只有规范先行，大家去标注数据时才会得心应手。数据表的规范包括字段类型、字段名称等，是否是快照表；SQL 规范基于对应的数据表定义的，下面是我们对于常用的日期生成 SQL 规范，比如“年末”、“最近一个月”都按照规范来生成 SQL，让最后生成的 SQL 没有歧义。

最后如果发现 badcase，我们会有一套快速定位来源并修复 badcase 的机制，持续增强数据的质量。

（3）自建 NL2SQL 评测方案

因为实际场景的问题都是偏业务的问题，而且非常口语化，传统的 SQL 评测集可能没办法真实反映实际的用户问题。为此我们自建了一套标准的 NL2SQL 的评测的数据集，包含了 1000 多条涉及多个场景的评测用例。

评测的方式是首先通过 SQL 执行引擎判断 SQL 的执行结果是否符合预期，并且还会通过 SQL 模式对比算法进行对比，判断 SQL 执行的逻辑是否相同，只有两个完全一致才符合要求，如果只要有一个不一致就会走到人工来评估。

（4）准取率评测效果

下边是我们整体的评测效果，首先我们对比了 GPT、开源通用模型等，模拟多个业务场景进行评测，效果如下：

我们整体的准确率有 84%，高于 GPT4 的 74.3%，从评测结果可以看到，不同的业务场景下，准确率差别较大，所以有些复杂的业务场景需要经过一定调优才能达到业务使用要求。

另外我们也对比排序、比较、聚合等多个能力维度的数据，整体上评测结果都高于 GPT4、千问、百度 GBI 等模型：

3. 可信能力技术实现

本节讲下我们前面提到的可信的技术实现原理，最核心的就是把 SQL 转换成我们定义的 DSL 这一步，DSL 是我们定义一套查询语法，包括维度、度量、筛选、排序、计算表达式等，只有把 SQL 转换成通用的查询结构，才能真正做到查询过程的可解释和可干预。

这里大模型生成是标准的 GP 语法的 SQL，先转换成 DSL，再转换成不同的数据源的的 SQL 语法，整个过程是“one SQL -> DSL -> N SQL”。

SQL2DSL 的实现逻辑就是先把 SQL 解析成对应的语法树，再根据语法树里每个节点转换成我们定义的 DSL 结构，右边是对应的转换翻译关系。比如 select 部分会转换成我们的维度和度量等。

下图是一个翻译的具体例子，可以看到这里的 SQL 里的 DATE_PART 函数最后翻译到是我们内部定义的 mapFuntion 字段属性，用来表达日期的粒度。整个翻译工作量还是蛮大的，因为有很多特殊 case 都要一对一的翻译，我们持续优化了大半年，目前已经基本稳定，覆盖了 99% 的常见 SQL 场景。

SQL2DSL 中最复杂的部分是带有子查询的嵌套 SQL 的翻译工作，我们会把子查询的 SQL 转换成独立的 SQL2DSL 的问题，同时将子查询转换成我们 BI 里面支持的 LOD 计算字段表达式。LOD 表达式其实本质上就是一个子查询，从而实现了同一个图表上跨视图粒度分析的能力。

像图中这条 SQL 我们转换成两个 LOD 表达式的相减。从而解决了子查询翻译难题：

4. ChatBI 背后的性能保障-物化视图技术

（1）chatBI 面临的性能挑战：

接下来回到前面的痛点，看下我们是怎么保障 ChatBI 的查询性能的，ChatBI 面临的主要性能挑战主要有以下几个方面：1）首先真实落地场景的都是百万级或者千万级的数据量，必然会造成性能压力；2）另外自然语言问答一般都是灵活的查询分析，他不像我们报表看板，里面的图表配置是固定的，所以最常用的缓存技术已经对 ChatBI 基本无能为力了；3）另外很多场景下模型都是多表关联，多表关联本身会带来巨大的性能开销；4）还有虽然 80% 的查询都是筛选部分数据，但是每次却要全表扫描。

（2）物化视图的产品能力：

面对这些性能问题，我们去年刚开发了基于 BI 的物化视图技术来解决这块的类似的性能问题。通过物化视图配置，我们可以把整个模型的 join 关系物化成我们 mpp 中的单张物理表，并且支持按需物化，可以物化部分列字段，或者部分行的数据。比如你原始模型有上千个字段，但是 ChatBI 里只用到了 20 个字段，完全可以只物化这 20 个字段，减少数据量提高查询性能。一个数据模型可以配置多个物化视图，另外物化视图支持了丰富的调度和管理能力。

（3）物化视图实现原理：

这边简单讲下我们物化视图的视线原理，首先我们会根据物化视图和模型的配置将其转换成我们的一个 ETL 任务，这样就可以利用我们已有的 ETL 的处理能力进行的管理和调度，并将数据物化到 MPP 中。

当我们执行一个图表的查询的时候，就会改写我们的图表查询的流程。首先会将图表查询生成 AST，然后根据这个 AST 来判断是否命中物化视图，以及物化视图的优先级判断和选择，选择一个成本最小的物化视图，然后根据物化视图元信息进行 SQL 的改写，最终从 MPP 中查询到数据以后再在内存中进行数据的重新组合。

因为命中物化的查询都是单表查询，正好可以充分利用我们 ClickHouse 大宽表查询的 MPP 性能优势，物化视图 + CK 可以将这种 BI 的性能优化做到极致。

（4）物化视图的产品能力：

这里讲一下在 BI 产品上构建物化视图的一些优势：

①传统的物化视图是直接改写 SQL 的，而我们是基于结构化的 DSL 改写的，复杂度会小很多；

②另外我们可以支持跨数据源引擎构建物化视图，比如你可以将 mysql 和 oracle 的数据表进行模型关联，然后构建一个物化视图；

③物化视图在实现上屏蔽数据源的差异，支持任意类型的数据源去构建物化视图；

④业务人员可以直接在模型上通过可视化的无代码的方式进行物化视图的配置，不需要开发能力；

⑤和 BI 深度结合，我们可以根据历史用户查询的行为做更好的智能推荐配置。

05 ChatBI 的开放能力和落地应用案例

1. Copilot 助手

ChatBI 作为 Copilot 助手嵌入到我们内部多个产品模块来进行提效：

报告制作和看数助手：辅助编辑者完成报告的制作，快速生成图表，辅助预览者对报告当前数据灵活问答分析和总结。
自助取数助手：用户取数时可以通过问答的形式快速生成结果再进行微调，从而提效。
大屏语音助手：用户可以直接在大屏面前通过语音唤起问答助手展示对应的数据。
指标问答助手：在指标中台也嵌入了 ChatBI 的能力，用户可以灵活的对指标数据进行问答分析。

2. 开放能力

其实 BI 和 ChatBI 都是服务于业务的工具，所以只有比较完善的开放和插件化能力才能更好的在客户场景落地。ChatBI 整体的开放能力体现在用户账号打通、数据模型打通、大模型插件化对接、以及产品应用四个方面：

用户账号：首先在用户账号这块，我们支持标准的单点登录对接和 token 鉴权，同时提供了丰富的用户和权限的同步 API 接口，可以实现和业务系统的账号体系的自动化打通。
数据模型：因为 ChatBI 是基于数据模型构建的，数据模型能够打通非常关键，目前已经支持数据源和数据模型同步接口，可以对接第三方 BI 的数据模型、指标平台等。
大模型：ChatBI 除了对接网易自研的大模型以外，还可以对接第三方大模型，但是准确率肯定是低于我们自研的大模型的，另外我们还可以对接外部的 RAG 系统，插件化的对接实现前处理和后处理的逻辑等。
产品应用：在上层应用上，我们提供了标准的问数 API 接口实现和业务系统的深度打通，同时客户也可以把我们的 ChatBI 页面集成到自己的业务系统里，支持很多自定义配置从而使其和业务系统融合更加完善。

3. 应用案例

HR 部门 XP 机器人：

HR 部门在办公软件 popo 里实现了 XP 机器人，通过对接我们 chatBI 提供的标准开放接口，实现了深度的集成嵌入，从而解决了管理者灵活问答的场景，大家每天打开手机就可以直接问答，下面这些使我们真实场景下的问答效果：

云音乐自助取数场景：

为了提高自助取数效率，我们将 SQL 取数、可视化取数、ChatBI 取数三种模式结合在一起，相辅相成，大大的降低了用户取数的门槛，提升了数据的消费的频率，全面覆盖用户的取数场景，整体上每周取数的人数从 50 人左右提高到 220 人。94% 的取数需求都可以通过自助几分钟内完成，效率显著提升。

重庆烟草自助问数

重庆烟草以数帆 ChatBI 为基座，搭建了多个智能问答场景应用，包括财务预算执行场景、烟草合同收购场景、营销会员模型场景、专卖许可证模型场景等多个场景都有初步成效，问答准确率达到了 90% 左右，数据查询时间从原来的 15 分钟提升到现在的 10 秒钟，对全市 45 家单位进行了工具的使用培训，培养了近 160 个 ChatBI 开发者，提高了全员数字化工具应用水平，已有 65 家单位使用 ChatBI,其中有 37 家单位深入进行业务模型的建设，共建设 269 个模型。

助力北京某理工高校实现智能问数助手

将有数 ChatBI 问答页面嵌入到学校 app 中，学校高层领导每天通过 app 就可以实时查询到学生的上课课时情况、上网情况、在校情况、考分情况等；同时也可以对老师的授课课时情况、论文发表情况、性别、在岗情况、教学数据等进行问答，在 ChatBI 的协助下，领导每天 80% 的数据都可以通过智能助手完成。

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

53AI，企业落地大模型首选服务商

产品：场景落地咨询+大模型应用平台+行业解决方案

承诺：免费场景POC验证，效果验证后签署服务协议。零风险落地应用大模型，已交付160+中大型企业