导读 本文将分享腾讯 PCG OlaChat 团队在智能数据分析领域的一些研究和实践。
1. 智能数据分析新时代
2. 腾讯智能数据分析平台 OlaChat 功能一览
3. OlaChat Agent 建设
4. OlaChat 关键能力介绍
5. 附录
分享嘉宾｜谢苑珍 腾讯 高级算法研究员
编辑整理｜孙迎港
内容校对｜李瑶
出品社区｜DataFun
智能数据分析新时代
1. DIKW 模型介绍
没有经过加工处理的底层数据并没有太多意义，无法回答很多特定的问题。而数据分析则帮助人类从数据中提炼知识，形成智慧。DIKW 模型主要描述的就是如何从数据层到信息的抽取，再到知识，最终形成人类所积淀的智慧。
信息是经过初始加工的、具有一定逻辑关系的数据，能够回答“是什么”、“在哪里”这种比较简单的问题；知识，则是基于信息进行过滤、提炼和加工得到的有用资料，可以解决“如何”等较为复杂的问题；而智慧，又在知识之上进一步抽象，会形成一些能够长期流传或传播的知识，或者形成一些前瞻性的看法。
2. 数据分析平台发展史
1996 年出现第一代传统 BI，传统 BI 的主要使用群体是老板或者是业务负责人，会对产品日活是多少、盈利是多少这种数据比较感兴趣。当时业务人员使用相对较少，当时的形态是老板提出一些需求点，然后让技术人员去做开发。这时的BI相应周期长，使用门槛高。
到 2011 年，随着移动互联网的发展，很多一线业务人员也参与到了数据决策的过程当中，因此诞生了拖拽式的敏捷 BI，非技术人员通过简单的点击、拖拽就能够实现基础的数据分析功能。
再到 2019 年，进入智能 BI 时代，主要目标是让人人都成为数据分析师，通过非常简洁的自然语言去与平台交互，使用门槛非常低，能够实现准确的找数、取数、用数。
3. 大语言模型对智能数据分析的影响
大模型的发展给智能数据分析平台带来了前所未有的机遇。回顾 NLP 相关技术的发展历程，上世纪 90 年代，初期的统计语言模型主要解决非常基础的自然语言问题；到 2013 年左右，以神经网络语言模型为主，可以解决典型的 NLP 问题；再到 2018 年左右，出现了 BERT 这种 transformer 类的模型，越来越多的 NLP 任务得以实现；2020 年生成式大语言模型问世，直到现在万亿模型也已经出现，已可以解决各种真实世界中的问题。
语言能力: 理解和处理人类语言的复杂结构和含义，理解和分析各种形式的数据，包括文本、表格等；自然语言的交互形式可以使得数据分析更加直观和易于理解。
工具使用：能够实现对工具的调用和代码的生成，如: Text2API、Text2SQL、Text2Code、Text2X。
逻辑推理：从数据中发现模式、趋势和关联性，帮助用户进行更深入的数据分析和洞察。
学习能力：使用少量优质的数据集微调能快速学会某一个领域的知识，模型迁移成本低。
4. 第三代数据智能化产品挑战
基于上面的时代背景，我们希望搭建一个数据智能化平台。在搭建之前通过调研和总结发现了一些问题：
一、目前大模型本身能力有限，如下图所示。第一，大模型存在幻觉问题，可能给出错误的回答；第二，大模型知识是有限的，缺乏特定业务领域知识；第三，上下文能力有限，不能把无限多的信息都塞进去，而业界的数据表都是非常大的。
二、智能BI的准确率比较低，而用户期望是比较高的，因此落地使用难度大。
三、当时的智能分析平台大部分是针对取数或者数据洞察等单点需求，而我们希望构建的是一个全链路的产品。
5. OlaChat 介绍
下图展示了我们当时设想的 OlaChat 产品的整体能力，目标就是去建设贯穿整个 BI 流程，从找数据到数据的描述与加工，再到数据分析与洞察、数据可视化，最后形成数据报表以及最终的数据洞察。
利用我们本身的大数据平台，其拥有非常丰富的数据，包括指标、画像、看板等数据，再联合 LLM 加 Agent 的方案去实现整个智能化分析平台。我们希望它能够易集成、高可用、智能化，能够有效降低查数、用数、取数的门槛，提高数据分析效率。
下图中可以看到三个 S（Solution），是分别对应前面三个问题的解决方案，后文中将会详细讲述。综合，整体的解决方案是 LLM+Agent 来推进数据领域的发展。
腾讯智能数据分析平台 OlaChat 功能一览
接下来先带大家看一下 OlaChat 的主要功能。
1. 功能展示
首先是 OlaChat 一站式的产品形态，一站式指通过一个 query 这种自然语言的问题，它能够理解用户意图，明确任务，完成从找数据表，到生成分析图，最后再去展示分析图和分析结论的整个过程。
第二个功能是灯塔 Copilot，提供了一个询问窗口，比如提出代码问题，它会回填到代码框里面。
第三个是 OlaChat 做了一个 IDE 的产品形态，这一块跟技术人员比较相关，可以在这里做快捷的代码开发，比如可以进行 SQL 纠错优化。
第四个是 WeTable 助手，这个主要是对 excel 表格这种单表的智能数据分析和处理平台。
2. 对话系统
接下来介绍一些具体的能力点。首先是对话系统的能力，它可以回答非常基础的问题，比如“你是谁”，“给我唱首歌吧”等等。不在其能力范围时，它会拒绝回答。当用户表述不清时，它还会继续追问，并根据上下文理解用户意图。
3. Text2SQL
接下来是 Text2SQL 的能力，下图截取自 Ola IDE，使用步骤是首先去选择表、输入 query，然后系统就可以理解意图，生成一段 SQL，点击插入光标位置，就可以快捷地回填代码，执行查询。查询如果报错，会自动去做纠错。
4. Text2DSL
Text2DSL 的功能与前面类似，是第二代敏捷 BI 的能力基础上增加了 AI 的能力。通过选择模型或者表，输入 query，接下来就会根据用户意图，由模型生成查询条件来进行回填，这样就避免了繁琐的拖拽。
5. 智能绘图
智能绘图功能会根据生成的数据表自动选择分类字段，如下图左侧所示，最上面是维度，以及指标等过滤条件，系统能够自动选择哪些应该作为指标，哪些作为维度，然后再去显示填充名字，因为生成的是英文字段名，这里则要替换成有中文含义的名称，然后自动生成报表并展示出来。从而可以大幅降低用户生成报表的成本。
6. 智能仪盘表
接下来是智能仪表盘功能，可以根据二维 excel 表格一键生成整个图表。
7. SQL 纠错
当执行的 SQL 有错时，在右边会有一个自动纠错的能力，也可以做 SQL 的回填。
OlaChat Agent 建设
从去年开始 Agent 领域开始变得非常热门，下图罗列了一些去年的相关工作，从最早期的 AutoGPT 这种通用化 Agent 发展到 2023 年 5 月出现的数据领域的 Data-Copilot，但是它不太适用于业界，因为它是完全自动化去生成接口，因此在同时期我们团队提出了 OlaGPT（通用 agent 框架，论文和代码均已开源）。
2. OlaGPT-赋予 LLMs 人类解决问题的能力(理论篇)
接下来介绍 OlaGPT 的整体设计，在架构设计时我们做了很多尝试，发现大模型虽然能解决简单问题，但是在数据分析领域这种涉及到非常复杂的推理逻辑的情况下效果并不是很好。既然我们想要去降低人类在整个过程当中的工作负担，那就需要让它拥有像人类一样去解决问题的能力。因此我们研究了人类认知的框架，提出了下图所示的架构。
整个方案包括六个模块：首先是 Intention Enhance 模块，它能够去识别 query 里所有相关的基础信息；然后是 Controller 模块，它主要负责整个任务的串联，具备计划编排以及记忆提取的能力；第三个是 Memory 模块，它可以看做是一个 RAG 模块，可以沉淀非常多的历史记录，比如错题记录、工具说明、思维模板，数据库信息等；第四个是 Reasoning 模块，这里主要是去创建了一些思维模板，让它照着思维模板去做一些实际的解答；第五个是最上面的 Active Learning 模块，它会把过去的错误样例沉淀下来，然后重新经过人类或者是我们设计的模型进行重新的标注；最后是 Voting 模块，可以对生成的多思维模板或者多方案进行判断，得到一个最终答案。
OlaChat 关键能力介绍
1. OlaChat-平台关键能力支撑
整个平台的支撑主要可以划分为四个部分：第一个部分是刚刚提到的多任化对话系统，主要负责跟人类进行对话以及意图的分类，也就是要路由到哪个任务；第二部分是 OlaChat 智能体，主要负责任务的编排和规划；第三部分是面向 ABI 的工具箱，这里提供了非常多的基础原子能力；最后是公共服务层，在实际开发过程当中能够提供一些公共的支撑能力，比如大模型调度的能力，开源大模型或者是内部的闭源大模型都可以进行调度，同时支持检索增强，此外还有标注系统，可以进行数据标注和数据沉淀。
2. 意图&对话系统
首先来介绍意图和对话系统的实现，主要六大模块，即上下文理解、意图识别、自然语言理解、对话状态跟踪、对话策略以及自然语言生成。其具体作用如下图所示。
设计目标是实现拒绝和澄清以及引导和推荐能力。拒绝是指有些解决不了的任务就不要硬解，而是应该拒绝。引导和推荐指的是有些用户在刚使用系统时不知道该如何使用，引导/推荐模块可以去生成一些相关问题，引导用户去使用。
下图中可以看到，左边的对话历史以及领域知识检索实现了澄清、改写以及回答三种能力。
接下来介绍一下意图分类的实现细节，这里跟传统意图分类有比较大的区别，因为我们要支撑很多产品形态，而且每个产品的候选意图并不一样。下图右侧可以看到 OlaChat 有更多的能力。为了实现一个通用化的意图识别方案，我们提出了一个多方案投票的策略去提升其整体的准确性，并能够做到线上 badcase 的快速修复。
方案细节包括：实现分类模型，训练所有问题类型下的基于 BERT, Roberta, Ernie 等的大分类模型，基于分类分数重训练/基于策略适配业务的子分类需求以及模型定期更新；提出召回候选集+排序方案的检索策略，针对提升高频问题准确率以及及时扩展性；微调大模型，通过 prompt 的方式进行提示输出，提升问题泛化性和及时扩展性。
3. 记忆模块
接下来介绍一下记忆模块，也就是 RAG 模块的实现。与传统 RAG 不同，因为我们是做数据分析任务，更多的是表或者指标维度，存在结构化的特点，因此我们实现了一个结构化数据检索的方案，基于用户 query，确定用哪个“指标+维度”或者哪些"表+字段”可以获取到教据来满足用户的需求。要求尽可能精确，以便减少传递给 LLM 的噪声，避免获取到的数据不符合要求。元数据检索增强和传统文本 RAG 检索的最大区别是元数据是按照特定结构层次组织的，原来的指标、字段、维度的组合方式不符合语言模型的基本假设。
接下来介绍两个元数据增强的方案，首先是 FlatteredRAG（F-RAG）方案，通过把结构化的数据转成非结构化的数据，再利用非结构化这种传统的方案做检索；另一个是 StructuredRAG（S-RAG）方案，利用元数据的结构特性先召回用户的核心数据需求 (如指标)，再基于此进行过滤召回修饰条件 (如维度)。
先看一下 FlatteredRAG 的实现细节，在一开始会准备一些 query 模板，将指标和维度组织成类似人类提问的话。元数据就是刚刚提到的，由多个指标、多个维度组成。元数据和 query 模板之间进行组合，就会组合出一个非常庞大的知识库。这个知识库会经过一层校验，因为里面会有一些脏乱的数据，我们就会将其放到检索里面，当用户问题进来的时候，比如问男性 DAU 变化趋势，这时我们会从检索库里面去寻找相似的 query，如果打分足够高就由这个模块直接进行输出。下图右侧可以看到我们搭建了一个模型，模型结构是在传统分类模型之上又增加了适配结构化数据的设计。
再来看 StructuredRAG 的设计。它借鉴了推荐的方案，通过字段或者用户问题里面拆出来的实体去检索，再多路召回。召回之后对召回的指标利用 Cross Encoder 模型进行粗排，然后在策略层基于语义相关性、计算逻辑相关性、实体去重、模型打分等方式进行过滤，减少噪音。最后精选层通过大模型做精选。这里为什么要选大模型？因为排序模型只能知道 Top N，它没有办法精确知道字段到底对应几个字段，但大模型具备这样的能力。通过这个设计，我们以表数据为例，比如几万张表，最终可能精选到只有五张表，其中字段信息也会有极大幅度的减少。
4. S2:工具箱组成丰富功能，以 SQL 矩阵为例
我们当时有提出一个丰富性的挑战，因此我们搭建了非常丰富的功能，这边以 SQL 功能矩阵为例，目前已实现 SQL 生成、改写、纠错、优化、解读、问答、补全所有这些能力。
5. Text2SQL
SQL 生成，也就是 Text2SQL 的能力，即通过文本（自然语言）去自动化生成 SQL 代码。我们调研了一些学术界的方案，比如阿里的 DAIL，它是基于 fewshot 还有一些 prompt 优化，借助 GPT4 实现的。其优点是实现简单，效果较好，但是最大的不足是它需要非常多的高质量数据，而这正是业界非常缺乏的。类似的，下图中列出的另外几个方案也都无法在业界使用。
我们又分析了真实业务场景存在的问题，主要包括以下几大方面：首先是数据隐私和安全问题，这是企业红线，GPT3.5/4 等第三方闭源模型不可用，开源模型也有限制商业条款；其次是大模型对业务数据理解不够，业务数据质量低，表数据脏乱，建表习惯不一，模型理解信息困难，大模型没有业务相关的知识且容易产生幻觉；此外稳定性和准确率不够，真实情况下用户问法非常个性化，现有方案的抗噪声能力不足 (BIRD~70%)，导致稳定性和准确率较差；而且高质量数据少，处于冷启阶段时缺少高质量的 query-SQL 数据。
基于上面提到的情况，如何去构建数据成了一个很大的问题。开源数据主要面向英文场景，少数的中文开源数据集也与业务实际场景存在较大差距。举个例子，比如单表的公开数据集，一张表可能只有二三十个字段，多的也只有三四十个字段。但实际业务中有非常多的大宽表，甚至是上千个字段都有可能。
另外，开源数据集缺少对高难度计算逻辑的覆盖，遇到相对困难的问题时容易出错。下图中红色和粉色就是类别比较少的数据集。用这些数据集微调的模型就很容易出错。
由上面提到的数据集问题我们思考如何去构建元数据，我们的数据构建是通过 Query2SQL 以及 SQL2Query 这两个方向来实现的。企业其实存在很多 SQL 数据，但没有直接使用。第一是因为存在非常多的领域语义，比如指标计算逻辑是很复杂的，但这种复杂逻辑是不应该训练在模型里面的，因为我们希望通过模型模块去解决问题，所以我们设计了一套 SQL 数据清洗策略，从里面能挑选出实际有价值的一些 SQL，把一些复杂逻辑或者业务逻辑非常强的 SQL 全部去掉，清洗出一批正常的 SQL。拿到 SQL 之后，将表信息以及 SQL 语句给到大模型，让其去总结出这个 SQL 在做什么，最后让它精简成一句话，这个过程就有了从 SQL 到 query 的数据集。
这个数据能否直接使用？肯定是不能的，语义层还是会有一些问题，因此还会经过一个数据校验的模块，除了语义校验之外，我们还去做语法和规则的 check，以及线上执行测试，保证这个 SQL 一定是对的。语义层的 check 就是保证它跟 query 之间是匹配的。除了这三种之外，我们还会做一个人工抽样检测，因为数据质量是重中之重。
解决了数据层面的问题之后，接下来介绍 Agent 的设计。下图右下方列出了存在的一些问题：
- 为解决大模型对领域知识理解能力不高的问题，我们引入了辅助信息，对数据进行规整，再通过元数据检索方案，补充信息。
- 针对大模型生成 SQL 稳定性不高的问题，我们适当融入了一些传统模型和策略，不完全依赖于大模型。
- 针对大模型生成 SQL 准确率不高的问题，我们添加了后校验模块，即下图右上中的 Self-Correction 模块。
下图左侧和右上面的图都来自于我们的一篇相关 paper。我们在 Spider 和 BIRD 数据集上进行了尝试，效果比较理想，目前已被 ACL 接收。
经过前面数据加模型再加 Agent 的努力，目前在我们自己的数据集上效果可以从直接用 GPT4 的 32% 提升至 52%。它能够支持复杂多样的问法 (灵活、歧义等)和复杂的 Schema；实现了对部分业务专有名词、使用范式、通用计算逻辑的支持；能够生成具有较高准确和高性能的标准 SQL 语句；返回的 SQL 具有较高的稳定性，相同的 Query 多次请求结果完全一致。
6. 智能图表绘制
图表智能辅助生成：一键智能生成图表配置，提升图表配置效率，智能选择图表类型、配置出图指标维度及坐标轴、图表标题生成、视觉元素美化。
Query 生成图表：支持自然语言交互的图形生成能力用户可通过文本描述出图需求，AI 智能生成查询条件及图表配置。
仪表盘生成：数据表语义分析理解，一键生成包含多张图表的仪表盘，辅助进行数据探索总结。
7. 智能数据解读
智能化数据解读实现的主要能力包括描述统计、趋势预测、数据可视化和基础归因分析等。我们通过 query 去分析用户意图，比如它适用于归因、趋势，还是异常或者描述统计；识别出来之后，会做任务的规划，确定需要哪些 task，要选哪些工具，哪些函数，有一些工具的函数是我们事先准备好的，如果没有就通过 NL2Code 模块进行补充；编排好之后会经过数据计算，对得到的数据结果逐一验证并总结；这里可能会经过多轮，我们会让大模型从中挑选出最适合的，最后再加上可视化的能力，汇总成最终的一个分析报告。
8. 开放的一体化智能分析平台架构
- 统一前端：提供了 Copilot 和 Polit 两个页面，和一套魔法棒前端组件来支持应用层嵌入，保持了统一的交互体验。
- 统一后端服务：API 层与应用端进行交互，提供初始信息加载、通用对话能力和历史信息上传等接口；编排基座:实现用户需求的正确路由，组合不同的服务与 Agent 满足用户的需求。
- Agent 层：组合不同的原子能力，构成丰富多样的 Agent，满足不同的任务所需。
- 公共服务层：通用能力接口 (元数据获取等)，为后端服务层与 Agent 层提供公共能力。
9. OlaChat 团队相关研究论文
除了上述产品相关实践之外，我们还有一些相关的科学研究。目前公开了两篇论文，还有六篇论文在整理中，预计也会放到 arxiv 当中。这些论文都是与前面介绍的能力相关的内容，比如 SQL 纠错、怎么选表等等。
附录
下文为团队在 24 年 ACL 发表的 text2SQL 论文介绍。
论文标题：Decomposition for Enhancing Attention: Improving LLM-based Text-to-SQL through Workflow Paradigm
代码仓库：https://github.com/FlyingFeather/DEA-SQL
立即咨询 JOTO
JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询
