有数ChatBI正式接入DeepSeek，万字长文揭秘ChatBI实现原理和应用实践

最新推荐文章于 2025-04-09 20:52:41 发布

网易数帆大数据

最新推荐文章于 2025-04-09 20:52:41 发布

阅读量1.1k

点赞数 13

文章标签：网易数帆有数BI deepseek 大数据

本文链接：https://blog.csdn.net/wangyiyungw/article/details/145608396

版权

网易数帆自推出有数ChatBI以来，持续在智能数据分析领域深耕，始终致力于为企业提供更高效、灵活的自然语言交互式数据洞察能力。作为领先的AI驱动型数据分析平台，其核心能力源于两大创新引擎的深度融合：

一是自主研发的NL2SQL私有化模型，通过持续微调训练实现企业级场景的高精度语义解析；

二是"插件化"大模型兼容框架，可无缝接入ChatGPT、阿里通义、百度文心、星火等国内外主流AI引擎，形成“私有+开放”双轮驱动的技术生态。

近日，随着DeepSeek（深度求索）的爆火，网易数帆大数据团队再次展现其敏捷的技术迭代能力，率先完成有数ChatBI与DeepSeek大模型的快速适配。

通过集成该模型先进的语义理解与推理能力，平台在复杂查询解析、归因分析等场景中的表现，实现突破性的提升。

更值得关注的是，网易数帆技术团队正基于DeepSeek的蒸馏模型展开深度微调训练，通过知识蒸馏技术将大模型能力“提纯”注入私有模型，在保障数据安全的前提下持续优化核心算法。

这种“前沿技术快速落地+自主模型持续进化”的双轨策略，标志着有数ChatBI正朝着更智能、更可靠的企业级AI智能数据分析平台迈进。

下面我们将从产品设计理念、核心技术原理、行业应用实践等维度，全面揭秘有数ChatBI如何通过创新的技术架构，助力企业构建下一代智能数据分析中枢。本篇内容主要围绕以下五点展开介绍：

有数BI产品简介
AI技术给数据分析带来的机遇与挑战
有数ChatBI：AI+BI的产品新模式探索
有数ChatBI技术实现原理
有数ChatBI开放能力及落地应用案例

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

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

目前有数BI已经支持了市面上常用的40多种数据源，包括关系型、分布式、文本型、API等数据源类型。

数据源接入后，我们可以通过新建一些自定义SQL或者通过拖拽式的ETL等方式做数据的加工和清洗，将数据抽取到我们内置的高性能MPP仓库，从而提升性能。

通过拖拉拽的方式进行数据建模，在建模阶段有数BI支持跨引擎构建物化视图。通过物化视图 + CK大宽表查询优势，可以将报表查询性能发挥到极致。另外最近一年有数BI上了关系模型的功能，可以彻底解决因为笛卡尔积产生的数据膨胀问题。

有了宽表模型定义以后，我们就可以基于模型做一些报告、取数、大屏等数据应用，图中蓝色的部分是我们最近2年发布的两个新的产品模块：

一个是数据表格，解决中国复杂式报表制作的场景，比如财务报表、监管报送、会计审计等报表；

另外一个功能是今天要分享的ChatBI模块，可以利用大语言模型的能力直接通过自然语言提问的方式进行数据分析。

最后还可以将做好的数据应用通过邮件、分享链接、微信小程序、移动端等方式分发和共享出去，让更多的人看到数据并提供决策。

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

随着大数据技术的崛起，传统BI产品开始流行，这个阶段主要面向IT人员，分析师或者业务提出数据需求，由 IT人员进行报表的开发，技术门槛高，周期也长。

目前大部分BI产品都处在这个阶段，得益于MPP等性能优化技术的加持，业务人员可以自己通过拖拽式的方式自助完成报告制作，整体效率提升 10 倍以上。

这个概念大家早都有在提，但是因为技术的原因一直没有做起来，伴随着大模型技术出现和快速发展，“智能 BI”才开始真正的普及，通过自然语言对话的方式进行数据分析，进一步降低了使用门槛，普及所有人，让每个人都可以做自己的数据分析师。

伴随着AI技术崛起，给数据分析领域也带来了很多的机遇，首先结合大模型的理解能力，通过NL2SQL和 NL2API等方式可轻松实现自然语言的数据查询能力。

另外大模型的上下文记忆能力，让多轮交互数据问答实现成为可能，并可以进行问题的自动纠错等能力。

在数据理解和数据推理上，我们借助大模型可以实现图表的智能解读以及数据的归因洞察等高级分析功能。

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

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

大模型有个致命问题就是幻觉，但是数据分析本身又是一个很严谨的事情，另外缺少行业知识和属性，再加上用户问题缺少规范化，如何解决数据的信任问题成了智能BI最大的挑战。

智能问答都是很随机的问题，查询复杂性会更高，包括大模型推理、数据查询、数据渲染都有一定的耗时，会让性能问题更加凸显。

如果没有完善的工程化能力的辅助，AI 的价值很难变现，客户场景问题千奇百怪，我们如何运营和优化成了在客户场景落地的难点。

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

ChatBI整个产品是基于现有有数BI能力的基础上构建的，所以有天然的优势，包括数据建模、数据查询、数据可视化、用户权限体系等能力都不需要二次设计和开发。另外光靠 AI 能力远远不够，真正可落地的ChatBI 离不开工程化技术的加持，所以这里搭建了一套完善的运营体系以及高效的问答辅助工具用来提升准确率和用户体验。

有了运营能力以后，我们就可以通过Chat的方式实现智能取数、多轮问答、数据分析等高级能力。另外在问答应用上，我们支持很多对外开放的能力，支持开放的数据问答API，集成页面的嵌入等，另外我们将ChatBI作为Copilot助手，辅助我们各种数据应用的开发。同时支持问答收藏、分享、移动端等数据分发的能力，可以实现和业务系统的完美融合。

有数ChatBI整体的产品定位是瞄准数据可信，从而解决 AI+BI分析最棘手的问题，用户对大模型返回的数据的信任其实是ChatBI可用可落地的前提，既要追求查询的准确率更要追求数据的可信。

下面主要从数据可理解、用户可干预、过程可验证、产品可运营四个方面阐述如何打造可信的ChatBI。

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

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

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

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

另外我们提供了一套成熟的运营方案，很多AI的产品都是非常依赖运营的，这里运营也是ChatBI可落地的关键一环。

我们提供了知识库、训练语料、提示词等成熟的运营手段来提高问答的准确率；产品方面也会提供运营的培训、最佳实践等能力。

同时会不断地强化大模型调优 badcase，从而让整个运营过程形成闭环，保证ChatBI是可持续健康迭代的。经过调优后，大部分场景的准确率都可以达到90%以上。

上图是ChatBI的整体技术架构图，最上面是前端展示层，当用户输入问题后会经过我们意图识别模块，意图识别主要包括数据查询、归因分析、指标解读等能力。

如果发现是数据查询，会经过我们下面的核心查询流程，包括前处理模块、自研 NL2SQL 大模型、后处理模块、数据查询基建层四个模块：

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

自研的NL2SQL大模型是经过专门调优训练的，在聚合、排序、排名、同环比等方面都做了非常大增强，同时支持一些自定义的特性，比如UDF函数、筛选集等。

其中同环比函数由于涉及到子查询生成的SQL较为复杂，就是通过自定义UDF函数能力实现的。

最后大模型生成的逻辑SQL会进入我们后处理模块，这个模块实现会对一些幻觉问题（比如字段或者表名不存在等）进行重试，接着会把逻辑 SQL 转换成我们定义好的DSL结构。

有了这个DSL后就可以对结果做一些校正澄清，也就是我们的智能感透出功能，比如用户问“x东的销售额”的时候，我们发现“东北”和“华东”里都包含了“东”这个关键词，会提示用户让用户选择确认。

另外用户也可以配置一些后处理的规则，比如添加默认筛选器、返回指定字段等，这些自定义的规则会在规则引擎中进行处理最后生成一个完整的DSL。

接着根据这个DSL进行图表类型的推断、图表可视化配置、字段格式配置推断等，最终生成我们的有数BI图表配置结构 VisualQuery。

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

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

我们自研的NL2SQL大模型主要以提升自然语言生成 SQL代码的准确性为训练目标，使用了大量的数据进行预训练和微调。

对于模型基座的选择我们评测了20多个国内外模型，最后选择表现最优的网易玉言模型进行训练。支持私有化部署和多语言提问。

其中数据构造这块我们结合了金融、教育等10多个领域的数据，最终生成的标准的PG SQL。

另外我们SaaS环境每天都有大量的真实客户的访问数据，用这些真实客户数据可以不断的持续微调优化大模型。在评测方面，我们建立了合理的评测指标体系，整体上准确率高于GPT4。

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的机制，持续增强数据的质量。

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

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

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

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

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

本节讲下我们前面提到的可信的技术实现原理，最核心的就是把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表达式的相减。从而解决了子查询翻译难题：

接下来回到前面的痛点，看下我们是怎么保障ChatBI 的查询性能的，ChatBI面临的主要性能挑战主要有以下几个方面：

1）首先真实落地场景的都是百万级或者千万级的数据量，必然会造成性能压力；

2）另外自然语言问答一般都是灵活的查询分析，他不像我们报表看板，里面的图表配置是固定的，所以最常用的缓存技术已经对ChatBI基本无能为力了；

3）另外很多场景下模型都是多表关联，多表关联本身会带来巨大的性能开销；

4）还有虽然80%的查询都是筛选部分数据，但是每次却要全表扫描。

面对这些性能问题，我们去年刚开发了基于BI的物化视图技术来解决这块的类似的性能问题。通过物化视图配置，我们可以把整个模型的join关系物化成我们mpp中的单张物理表，并且支持按需物化，可以物化部分列字段，或者部分行的数据。

比如你原始模型有上千个字段，但是ChatBI里只用到了 20个字段，完全可以只物化这20个字段，减少数据量提高查询的性能。一个数据模型可以配置多个物化视图，另外物化视图支持了丰富的调度和管理能力。

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

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

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

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

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

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

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

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

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

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

辅助编辑者完成报告的制作，快速生成图表，辅助预览者对报告当前数据灵活问答分析和总结。

用户取数时可以通过问答的形式快速生成结果再进行微调，从而提效。

用户可以直接在大屏面前通过语音唤起问答助手展示对应的数据。

在指标中台也嵌入了 ChatBI 的能力，用户可以灵活的对指标数据进行问答分析。

其实BI和ChatBI都是服务于业务的工具，所以只有比较完善的开放和插件化能力才能更好的在客户场景落地。

ChatBI整体的开放能力体现在用户账号打通、数据模型打通、大模型插件化对接、以及产品应用四个方面：

首先在用户账号这块，我们支持标准的单点登录对接和 token鉴权，同时提供了丰富的用户和权限的同步API 接口，可以实现和业务系统的账号体系的自动化打通。

因为ChatBI是基于数据模型构建的，数据模型能够打通非常关键，目前已经支持数据源和数据模型同步接口，可以对接第三方 BI 的数据模型、指标平台等。

ChatBI除了对接网易自研的大模型以外，还可以对接第三方大模型，但是准确率肯定是低于我们自研的大模型的，另外我们还可以对接外部的RAG系统，插件化的对接实现前处理和后处理的逻辑等。

在上层应用上，我们提供了标准的问数API接口实现和业务系统的深度打通，同时客户也可以把我们的 ChatBI页面集成到自己的业务系统里，支持很多自定义配置从而使其和业务系统融合更加完善。

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

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

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