腾讯基于 LLM 的智能数据分析平台 OlaChat 的落地实践

导读 在当今快速发展的数据分析领域，智能分析平台正经历从传统 BI 到敏捷分析，再到智能分析的转变。随着移动互联网的兴起和大语言模型的出现，数据分析变得愈加普及，用户可以通过自然语言与系统进行互动，获取所需数据。然而，即使在敏捷分析阶段，仍然存在一定的学习成本。大语言模型的引入为数据分析带来了新的机遇，它不仅提升了语言理解和生成能力，还使得逻辑推理与工具使用变得更加高效。通过对用户自然语言指令的理解和转化，智能分析平台能够实现更直观的数据查询和分析过程，为用户提供更为便捷的服务。本文将分享腾讯基于 LLM 的智能数据分析平台 OlaChat 的落地实践。

主要内容包括以下几大部分：

1. 从传统 BI 到智能 BI

2. LLM 时代智能 BI 的新可能

3. 腾讯 OlaChat 智能 BI 平台落地实践

4. 问答环节

分享嘉宾｜ 谭云志 腾讯 高级研究员

编辑整理｜ 陈思永

内容校对｜李瑶

出品社区｜ DataFun

---

01

从传统 BI 到智能 BI

随着大语言模型（Large Language Models, LLMs）的快速发展，智能分析在商业智能（Business Intelligence, BI）领域的影响日益显著。本节将探讨从传统 BI 到智能 BI 的过渡过程，分析这一转型所带来的新机遇与挑战。

1. 传统 BI 的局限性

传统的商业智能体系通常是基于一种自上而下的模式，业务负责人提出需求，开发人员进行数据提取和分析，最终经过一段时间的开发后，将结果反馈给业务方。这种流程不仅效率低下，还存在较大的沟通成本，导致决策的延迟。用户常常需要等待一周甚至更长的时间，才能获得所需的数据分析结果。

2. 移动互联网时代的敏捷分析

随着移动互联网的崛起，数据的丰富性和复杂性不断增加，市场对数据分析的需求也在发生变化。敏捷分析应运而生，它旨在使更多的用户能够方便地获取数据并进行自助分析。通过简单的拖拽操作，用户可以轻松进行数据探索。然而，调研显示，即便是这种简单的操作，对某些用户来说依然存在较高的学习成本。比如，用户在进行环比计算或其他复杂操作时，仍需掌握相关功能的使用方法，存在一定的门槛。

3. 智能 BI 的初步探索

到了 2019 年，智能分析的构想开始萌芽。虽然大语言模型尚未全面普及，但一些在自然语言处理领域表现良好的模型已经出现。这一时期，业界开始关注如何让更多的用户能够轻松进行数据分析，目标是将每个人都转变为“数据分析师”。智能分析的概念逐步形成，致力于简化数据分析流程，降低用户的技术门槛。

现如今，随着大语言模型的普及，智能BI 迎来了新的发展机遇。大语言模型不仅能够处理复杂的数据查询，还能通过自然语言与用户进行交互，使得数据分析变得更加直观和人性化。用户只需用自然语言描述他们的需求，系统便能自动生成相应的分析结果，这大大提高了分析的效率和准确性。

02

LLM 时代智能 BI 的新可能

大语言模型（Large Language Models, LLMs）的发展历程展现了自然语言处理（Natural Language Processing, NLP）领域的显著进步。接下来将梳理大语言模型的发展脉络，并探讨其对数据智能分析所带来的新机遇。

1. 大语言模型的发展脉络

（1）初期阶段：基于概率的语言模型

自然语言处理的早期阶段主要依赖于概率模型，如条件随机场（Conditional Random Fields, CRF）和马尔可夫模型。这些模型基于历史数据，通过词袋模型（N-gram Model）来计算词语出现的概率。此时，语言模型的能力相对有限，主要侧重于基于历史词语的概率预测。

（2）神经网络时代的崛起

2013 年，谷歌发布了一项具有里程碑意义的方法 word2vec，标志着基于神经网络的语言模型时代的到来。在这一阶段，长短期记忆网络（Long Short-Term Memory, LSTM）等模型开始得到广泛应用。神经网络的引入大大提高了语言模型的性能，增强了其对上下文的理解能力。

（3）Transformer 模型的兴起

2017 年，Google 发布了 Transformer 架构，由此在 2018 年前后出现了一系列基于此的模型，如 BERT、GPT1/2 等。相较于之前的模型，BERT 和 GPT1/2 模型的参数量显著增加，达到千万、数亿规模。这些模型通过在大量语料上进行统一训练，可以快速适应不同任务，展现出强大的语言理解能力。

（4）当前的万亿参数时代

随着 GPT-3 和后续版本的推出，语言模型的参数量达到了千亿、万亿级别。这使得一个模型能够同时在多个任务上达到较好的效果，降低了对多个模型的依赖。在这一阶段，语言模型在文本生成、理解和逻辑推理等方面的能力都得到了极大的提升。

2. 大语言模型对数据智能分析的影响

大语言模型为数据智能分析带来了以下四个方面的改进：

• 语言能力 ：大语言模型在语言理解和生成方面的能力非常强大。它能够有效解读文本和表格数据背后的含义，使得数据分析变得更加直观、易于理解。通过自然语言交互，用户可以更轻松地进行数据分析，而不需要深入掌握复杂的工具和技术。

• 工具使用 ：大语言模型能够将用户的指令转化为工具调用或代码生成。例如，用户可以通过简单的自然语言请求，生成相应的 API 调用或代码。这种能力显著提高了数据分析的效率，降低了技术门槛。

• 逻辑推理能力 ：尽管大语言模型的逻辑推理能力相对有限，但它在模式识别、趋势分析和关联性发现方面仍然表现出色。这为数据智能分析提供了有力支持，使得用户能够从数据中提取有价值的洞察。

• 学习能力 ：在早期，训练一个模型以适应特定任务通常需要大量的数据。然而，得益于大语言模型的“上下文学习”（In-context Learning）能力，用户不需要进行模型训练也能在一些任务上取得不错的效果。即使需要微调，用户也可以通过较少的数据（仅需几千条）就能调整模型以满足特定需求，这种适应性使得大语言模型在各类任务中的应用变得更加灵活。

基于腾讯PCG 大数据平台部资产管理平台“Ola”和数据分析平台“灯塔”丰富的元数据和用户行为日志，结合大语言模型的能力，我们构建了 OlaChat 这一智能数据分析平台。OlaChat 能够提供高效和智能的数据分析服务，满足用户问数、人群洞察、NL2SQL 等需求，有效降低了查数、取数、用数的门槛。

接下来将详细介绍 OlaChat 平台落地实践。

03

腾讯 OlaChat 智能 BI 平台落地实践

OlaChat 智能数据分析平台主要目标是通过自然语言交互，为用户提供流畅的数据分析体验。系统的核心模块包括多任务对话系统、任务编排引擎、众多的 AI 工具以及底层的公共服务能力。以下是 OlaChat 的关键功能与技术架构的深入解析。

1. OlaChat 关键能力

• 多轮对话系统 ：用户与 OlaChat 交互的第一入口是一个多任务对话系统，类似于智能助手，用户通过自然语言与系统进行交互，系统需要具备理解用户意图并执行相关任务的能力。

• 任务编排与执行 ：系统理解用户意图后，规划出执行任务所需的步骤，并按顺序调用相关工具和数据。

• AI+BI 工具箱： 包括 Query 改写、text2SQL、指标分析等工具，这些工具通过不同的组合可以实现不同的能力，从而解决不同的任务。

• 公共服务 ：底层由一些公共服务来支撑相关能力，主要包括三个部分：

  统一 LLM 调度（包括腾讯的混元模型，以及其他一些微调过的模型），系统建立了统一的模型调度机制，根据不同任务自动选择合适的语言模型，并进行负载均衡和模型加速，针对不同模型输入输出的格式差异，系统通过公共服务屏蔽这些差异，提供一致的交互接口。

  知识检索增强：提供了检索元数据的功能。

  标注系统：在数据分析过程中需要处理大量与特定领域相关的数据，因此引入了标注系统，可以对自定义数据和指标进行标注，用于增强大语言模型的领域理解能力。

接下来将具体介绍其中一些能力。

2. 多任务对话系统

多任务对话系统提供的基础功能为拒绝/澄清，以及引导/推荐。

系统具备的关键能力包括：

• 上下文理解 ：持续跟踪上下文，基于用户的历史对话，准确理解用户的需求，补充缺失信息。

• 意图识别 ：基于上下文理解，进行意图识别，将用户需求传到对应的 Agent。

• 自然语言理解模块（NLU） ：将用户文本消息转化为可以被机器理解的语义标签。

• 对话状态跟踪模块（DST） ：在对话中的每一轮基于对话历史维护最新的对话状态，通常表示为一组槽位-槽值对。

• 对话策略模块（DPL） ：基于当前的对话状态，决定对话系统的下一步动作。

• 自然语言生成模块（NLG） ：将对话策略模块决定的系统对话行为转换为人类语音，回复给用户。

3. 元数据检索增强

在数据分析中，元数据的检索是一个关键步骤，尤其当数据呈现结构化形式时，传统的基于非结构化自然语言的检索方法无法完全适用。腾讯的智能分析平台通过增强元数据检索能力，解决了结构化数据中的多层次、复杂性问题，为用户提供更精准的分析支持。

结构化数据，比如表和指标，每个表有表名、字段，指标下有维度（如年龄、性别等），这些数据有层次性和明确的结构。这种层次结构不同于非结构化文本，不能简单地通过自然语言的检索增强方法来处理。传统的自然语言检索主要基于 embedding（嵌入向量）技术，将文本分块后，通过相似度匹配来检索相关信息。然而，结构化数据并不遵循自然语言的逻辑，导致传统方法难以直接应用。

通用RAG 在解决元数据检索增强任务时存在一定的不适用性，主要因为：

• 元数据是按特定的结构、层次组织的。

• 指标、字段、维度的组合 没有固定的前后顺序或自然语言中的常见规律。如自然语言中“中国的首都是“，后面跟着的大概率会是“北京”，然而元数据并不符合语言模型的基本假设。

• 特定修饰词很重要，某些特定的字段或维度往往具有关键性意义，比如“有效播放次数”和“付费播放次数”表示的是截然不同的指标，这种差异无法通过传统的检索方式精确捕捉。

• 字段名可以很短，这就要求检索方法能准确地捕获用户问题中的关键信息。

我们有两种方案，分别从两个角度来解决元数据检索增强的问题。

第一种方案是 FlattenedRAG，在已有元数据基础上进行组合，将结构化的元数据变为非结构化的自然语言，当接收到用户问题后，进行检索、排序，找到与知识库中一致的数据。

第二种方案是 StructuredRAG，充分利用好元数据的结构化信息，优先检索出最核心的元素，再围绕这些核心元素进行二次检索，找到所需的数据。

FlattenedRAG 的具体流程如下：

元数据打平 ：将数据表、字段、指标等信息组合成类似于问答式的自然语言。例如，指标为“活跃用户数”、维度为“男性”的查询组合可能会被打平为：“腾讯视频男性活跃用户数有多少？”。

基于知识库进行检索 ：当用户提出问题后，系统会从打平后的知识库中进行检索，找出与用户问题相似的文本。

排序和匹配 ：系统通过预训练的分类模型对检索结果进行排序，最终选择出最相关的答案返回给用户。

这种方法的核心在于将结构化信息转化为非结构化文本，从而使得传统的自然语言检索技术可以直接应用。

StructuredRAG 的主要流程如下：

核心元素的检索 ：当用户提出问题时，系统首先会利用结构化信息的层次性，优先检索出最重要的元素，如指标、维度等。例如，在用户询问“腾讯视频的男性活跃用户有多少”时，系统会首先确定“活跃用户数”这个关键指标。

围绕核心元素的进一步检索 ：在找到核心元素后，系统会进行二次检索，匹配用户的问题和核心元素的其他相关信息，比如在上面的例子中会二次检索和“男性”相似的多个维度。

返回结果 ：系统根据核心元素的检索结果，再结合进一步的二次搜索，最后经过一次排序之后给出最符合用户问题的答案。

两种方法各有优缺点：

• 打平方法 ：通过将结构化数据打平为非结构化文本，简化了复杂的数据结构，方便了自然语言处理的应用。此方法的优势在于能够直接利用已有的自然语言检索技术，操作简便，但是如果指标和维度的数量非常多时该方法可能会面临组合爆炸的问题。

• 结构化方法 ：充分利用了元数据的层次结构信息，能够在保持数据层次关系的同时提高检索的准确性。此方法在处理非常复杂且层次分明的数据时更加有效，尤其是包含多个维度的长尾问题。

在实际应用中，这两种方案各有其适用场景。例如，当指标和维度的数量相对有限时，打平方法可能更为高效；而在指标和维度组合较多的场景下，结构化方法则能够提供更自由的检索方式。这两种方案的结合，使得系统能够在不同场景下灵活应对用户提出的各种数据分析需求。

在泛数据分析架构中，底层是指标、库表等元数据，以及画像和历史问答集；这些数据进入标注系统后，会经过各种标注处理；之后是各种检索，包括关键词检索、语义检索等；检索后进行知识精简，继而为上层的指标分析、人群圈选等各种应用提供支持。知识精简和知识检索就是由前面介绍的元数据 RAG 实现的。

4. Text2SQL

Text2SQL 真实业务场景下存在着诸多问题：

• 首先，数据隐私与安全始终是不可逾越的红线。例如，一些知名模型在使用协议中规定，企业如果月活跃用户数超过一定数量，就必须申请使用权限。这对于腾讯等大企业而言，意味着许多闭源和开源模型都不可用，因此必须开发自有模型以满足业务需求。

• 尽管大型语言模型在技术上表现强大，但在业务理解方面却存在显著不足。许多企业的数据质量较低且结构混乱，模型很难准确理解。此外，模型常常缺乏领域知识，可能会产生“幻觉”。

• 另外，模型的稳定性和准确率也存在不足。真实情况下用户问法非常个性化，现有方案的抗噪声能力不足（BIRD~70%），导致稳定性和准确率较差。

• 企业在实际应用中常常难以获取到高质量数据，尤其是冷启动阶段，高质量的 query 到 SQL 的数据非常匮乏。

基于上述问题，我们最终采取了微调大模型+Agent 的方案来实现 Text2SQL。

高质量的数据对于训练高效的模型至关重要。然而，开源数据集大多面向英文场景，即使翻译成中文，结构也较为简单，通常为单表，字段在 10 个以下，而实际业务场景中可能有上百个字段。这使得大型模型在处理这些数据时容易产生误解或无法准确解读业务中的复杂逻辑。此外，开源数据集在操作符的使用上也比较有限，常用的操作符较少，这进一步降低了模型在复杂任务上的表现。

在我们内部，已经建立了一套数据生成的逻辑流程。该流程主要包括以下几个步骤：

数据收集与脱敏 ：首先，我们会基于收集到的腾讯内部数据，进行必要的脱敏处理，以确保用户隐私和数据安全。

随机选取数据 ：在经过脱敏处理后，我们会从数据集中随机选择一些样本，并将这些样本拼接成类似的提示（prompt），然后输入到大型模型中。

数据增强 ：利用这些样本，我们会使用数据增强的方法，让模型基于已有样本生成新的样本，通过这种循环不断丰富数据集。

在数据增强过程中，有两个关键点需要特别关注，即准确性和多样性。

• 准确性 ：我们必须确保大型模型生成的 SQL 是准确的。如果模型生成的 SQL 错误并被加入训练集，就会导致模型性能下降。因此，我们设计了一套代码逻辑来检查生成的 SQL 是否正确，首先这个 SQL 要能够执行，并且与用户输入的查询语义相匹配，为此我们使用一个专门的模型来验证生成查询的语义正确性。

• 多样性 ：我们还需要确保数据的多样性，避免模型生成大量相似的数据。为此，我们采用了一些相似性检测的方法，剔除过于相似的样本。此外，我们会对生成的数据进行分类，确保各类别之间的平衡。如果某个类别的数据过多，我们会减少该类别的生成；而对于数据较少的类别，则会重点生成更多样本，以提升数据集的整体准确性和多样性。

在数据生成过程中，我们将样本划分为不同的难度等级，包括简单（easy）、中等（medium）、困难（hard）和特别困难（extra hard）。我们发现，开源数据集在困难和极度困难的数据生成上分布不均。因此，我们特别重点生成这些困难类型的数据，以弥补开源数据集的不足。

经过这样的数据增强与补充后，我们对模型的表现进行了评估。在真实的业务数据集上，模型的准确率通常较低，例如，GPT-4 的准确率为 32%，而我们自己的模型可以达到 52%。除此之外，我们训练的模型还能实现对复杂问法、复杂 Schema 和复杂计算逻辑的支持，具有较好的稳定性。

我们还发现，单独使用一个模型很难达到理想效果，原因如下：

• 数据集覆盖不全 ：业务中的各种查询可能非常复杂，而我们很难覆盖所有同学所编写的查询样本。

• 语言多样性与歧义 ：用户的语言表达多种多样，可能存在歧义和同义词，使得生成的查询难以满足所有需求。

• 噪音与信息干扰 ：在数据集中，存在一些噪音数据，这些信息会干扰模型的训练效果。

在我们的系统中，除了依赖于大型模型外，我们还开发了一套智能体流程，旨在辅助大模型生成更高质量的 SQL。这个智能体的流程能够针对大模型在理解力、稳定性和准确率等方面的不足，实施相应的策略，以解决这些问题。

• 减少冗余信息，引入辅助信息

我们认识到，将一张表的全部字段都传递给大型模型以供其理解并不现实。为了提高模型的准确性，我们会首先进行字段的精选，过滤掉冗余字段，留下更相关的字段，从而使得模型在理解时更加集中和高效。

• 适当融入传统模型/策略

用户的问题表述往往较为随意，为了提升准确性，我们可以通过模型对用户输入的问题进行规范化处理，并加入一些 fewshot 检索，从而提高模型的理解能力和生成准确性。

• 对模型结果进行后验优化

生成的 SQL 可能并不总是能正确执行，我们设计了一个后续纠错机制，利用大模型对生成的 SQL 进行审核，并进行必要的修改，同时可以进一步提升准确性。

我们将上述思想整合成了一篇论文，探讨了如何通过信息精简、分类处理、针对性生成和自我纠错的过程来提升模型性能。在生成过程中，对不同复杂程度的查询采取不同处理方式，简单的查询与复杂的查询应有不同的生成策略。在生成时设定特定条件，确保生成查询符合执行要求。同时，实施自我纠错机制，让模型对自己生成的查询进行反思与调整。此外，我们还实施了主动学习（active learning）的策略，针对常见问题进行重点提示。通过让模型专注于规范化问题，进一步提高模型的准确性。这一过程将智能体与大型模型相结合，提升整体的准确率。

5. Text2SQL 之外

在进行智能分析时，用户的需求不仅限于 text2SQL，还会有改写、纠错、优化、解读、问答、补齐等多种需求。为了满足用户多元化的需求，我们在系统中构建了多个智能体，旨在辅助用户进行数据智能分析，提升效率。

上图展示了 OlaChat 的整体架构，自下而上包括底层服务、中间公共服务、Agent、统一后端、统一前端，以及所支持的各种应用。不同模块相互配合，实现整个平台的统一体验，提升用户在数据分析过程中的效率与效果。

04

问答环节

Q1：取数时使用了多大的模型？

A1 ：取数模型为 8B，相对较小，适合快速判断用户的查询。

NL2SQL 采用的是 70B 的模型进行微调。

Q2 ：如何保证归因的准确率？

A2：归因的准确率依赖于归因工具。虽然大模型推理能力强，但要结合外部数据提高准确率。所以我们的做法为，基于归因工具拿到数据后，大模型负责在中间串联，做一些语言上的整理归纳，呈现给用户。

Q3