高准确的 Text2SQL 在腾讯落地的智能数据分析平台最佳实践

导读

这两年大语言模型（LLM）的爆发，给数据分析领域带来了久违的新鲜感。从传统BI到敏捷分析，再到如今的智能分析，这一路走来，数据的使用门槛其实一直在降。移动互联网的普及让数据量暴增，而大模型的出现更是让“自然语言问数据”变得触手可及——用户不用再学复杂的工具，直接用日常说话的方式就能和系统交互。不过，即便是在敏捷分析阶段，还是有不少用户觉得拖拽操作有门槛。而大语言模型在语言理解、逻辑推理和工具调用上的突破，正好补上了这块短板。它可以听懂你的自然语言指令，转化成数据查询，再给出直观的分析结果。这篇文章就来聊聊腾讯基于LLM的智能数据分析平台OlaChat的落地实践，看看它是怎么一步步把“智能BI”变成现实的。

主要内容包括：

• 从传统BI到智能BI
• LLM时代智能BI的新可能
• 腾讯OlaChat智能BI平台落地实践
• 问答环节

01 从传统BI到智能BI

大语言模型（LLMs）的快速发展，正在深刻改变商业智能（BI）领域的格局。我们来看看这个转变是怎么发生的，以及它带来了哪些新的机会和挑战。

1. 传统BI的局限性

传统的商业智能体系通常走的是自上而下的路线：业务负责人提需求，开发人员去取数据、做分析，折腾一段时间后把结果反馈回去。这流程不仅慢，沟通成本也高，一个分析需求往往要等上一周甚至更久才能拿到结果。等数据到手，业务决策的黄金窗口可能早就过了。

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

移动互联网起来之后，数据量猛增，结构也越来越复杂。市场对数据分析的需求变了，催生了敏捷分析——让更多人能自助式地获取数据。通过简单的拖拽操作，用户可以自己探索数据。但调查发现，即便是这么“简单”的操作，对一些用户来说学习成本依然不低。比如要做个环比计算，或者处理一些稍微复杂的逻辑，很多人还是懵的——门槛并没有真正消失。

3. 智能BI的初步探索

到了2019年前后，虽然大语言模型还没全面铺开，但自然语言处理领域已经有一些表现出色的模型了。那时业界开始琢磨一件事：怎么让更多人不用学工具也能做数据分析？目标是让每个人都能成为“数据分析师”。智能分析的概念逐渐成形，核心就是简化流程、降低技术门槛。

现在，大语言模型成熟了，智能BI终于迎来了真正的爆发期。它不仅能处理复杂的数据查询，还能跟用户用自然语言聊天——你说一句话，系统直接给你分析结果。效率和体验的提升，都是质的飞跃。

02 LLM时代智能BI的新可能

大语言模型的发展，其实是自然语言处理领域几十年积累的结果。理清这个脉络，才能理解它对数据智能分析意味着什么。

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

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

最早期的语言模型靠概率计算，比如条件随机场（CRF）和马尔可夫模型。它们基于历史数据，用N-gram来估算词语出现的概率——能力有限，只能做简单的预测。

神经网络时代的崛起

2013年谷歌发布word2vec，是个里程碑。从那以后，神经网络（比如LSTM）开始大放异彩，语言模型对上下文的理解能力明显增强。

Transformer模型的兴起

2017年Google推出Transformer架构，紧接着2018年前后出现了BERT、GPT-1/2等模型。参数量一下飙到千万甚至数亿级，这些模型在大量语料上统一训练，然后快速适应不同任务，语言理解能力有了质的飞跃。

当前的万亿参数时代

GPT-3及其后续版本把参数量推到千亿、万亿级别。一个模型就能在多个任务上都表现不错，不用再为每个任务单独训练模型。文本生成、理解、逻辑推理——这些能力都达到了前所未有的水平。

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

大语言模型给数据智能分析带来了四个核心改进：

• 语言能力
  ：它能很好地理解文本和表格背后的含义，让数据分析变得更直观。用户只需用自然语言描述需求，不用学复杂的工具。

• 工具使用
  ：它能把用户的自然语言指令转化成工具调用或代码生成。比如说一句“帮我查一下这个月的活跃用户”，系统就自动生成对应的API调用或SQL查询。

• 逻辑推理能力
  ：虽然它的逻辑推理不是完美的，但模式识别、趋势分析、关联性发现这些方面已经够用，可以从数据中挖出有价值的洞察。

• 学习能力
  ：以前训练一个模型适应特定任务需要大量标注数据。现在得益于“上下文学习”（In-context Learning）能力，你不用训练也能取得不错的效果。即使需要微调，几千条数据就够了——灵活性高了很多。

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

接下来重点讲讲OlaChat平台的落地实践。

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

OlaChat的核心目标很简单：让用户通过自然语言交互，获得流畅的数据分析体验。系统由多任务对话系统、任务编排引擎、AI工具箱以及底层公共服务几个核心模块组成。下面深入拆解一下它的关键能力和技术架构。

1. OlaChat关键能力

• 多轮对话系统
  ：用户跟OlaChat交互的第一入口就是一个多任务对话系统，像智能助手一样。用户用自然语言下达指令，系统需要理解意图并执行任务。

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

• AI+BI工具箱
  ：包括Query改写、text2SQL、指标分析等工具，不同组合能解决不同任务。

• 公共服务
  ：底层由统一LLM调度（包括腾讯混元模型及其他微调模型）、知识检索增强、标注系统三部分支撑。统一LLM调度可以根据任务自动选择合适模型，并做负载均衡和加速；标注系统用于处理领域特定数据，增强大模型对业务的理解。

下面具体介绍其中几个关键能力。

2. 多任务对话系统

多任务对话系统的基础功能包括：拒绝/澄清、引导/推荐。它的一些关键能力：

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

• 意图识别
  ：基于上下文，识别用户意图，将请求分发到对应的Agent。

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

• 对话状态跟踪（DST）
  ：每一轮对话后维护最新的对话状态（一组槽位-槽值对）。

• 对话策略（DPL）
  ：根据当前状态，决定下一步动作。

• 自然语言生成（NLG）
  ：将系统决策转化为自然语言回复给用户。

3. 元数据检索增强

数据分析中，元数据检索是关键环节。但数据是结构化的（表、字段、指标、维度），传统的非结构化检索方法并不适用。比如表名、字段名、指标名之间有明确的层次，不能简单用embedding去匹配。

通用RAG在元数据检索上的问题在于：

• 元数据是按特定结构和层次组织的。
• 指标、字段、维度组合没有固定顺序，不符合自然语言模型的基本假设。
• 特定修饰词很重要，比如“有效播放次数”和“付费播放次数”截然不同，传统检索难以区分。
• 字段名可能很短，需要精确匹配用户问题中的关键词。

我们设计了两种方案：

• FlattenedRAG
  ：把结构化元数据“打平”成自然语言文本。比如“腾讯视频男性活跃用户数有多少？”这样的问答对。用户提问后，从打平的知识库中检索相似文本，再排序匹配。

• StructuredRAG
  ：充分利用结构信息，优先检索核心元素（如指标），再围绕它进行二次检索（如维度）。先确定“活跃用户数”，再匹配“男性”等维度。

两种方案各有优劣：打平方法简单直接，但指标维度组合多了容易爆炸；结构化方法更精准，适合复杂长尾问题。实际应用中可以根据场景灵活切换。

在泛数据分析架构中，底层是指标、库表等元数据，还有画像和历史问答集。这些数据进入标注系统处理后，经过关键词检索、语义检索，再通过知识精简（由元数据RAG实现），最后为上层的指标分析、人群圈选等应用提供支持。

4. Text2SQL

Text2SQL在真实业务场景中面临的挑战不少：

• 数据隐私与安全
  ：很多知名模型的使用协议要求月活超过一定数量就得申请权限，对大企业来说，很多闭源和开源模型都用不了，必须自己开发。

• 业务理解不足
  ：大模型虽然技术强，但不懂具体业务，对低质量、结构混乱的数据很难准确理解，还容易产生“幻觉”。

• 稳定性与准确率不足
  ：现实中的用户问法五花八门，现有方案的抗噪声能力有限（BIRD~70%），稳定性和准确率都不够。

• 冷启动数据匮乏
  ：高质量的query到SQL的标注数据很难获取。

我们最终选择了“微调大模型+Agent”的方案来实现Text2SQL。

高质量数据是模型效果的基础。但开源数据集大多面向英文场景，翻译成中文后结构简单（通常单表，字段不到10个），而实际业务中可能有上百个字段，操作符也很少。这都会导致模型表现不佳。

我们内部建立了一套数据生成流程：

• 数据收集与脱敏
  ：收集腾讯内部数据，做脱敏处理。

• 随机选取数据
  ：从脱敏数据中随机选样本，拼接成prompt输入大模型。

• 数据增强
  ：让大模型基于已有样本生成新样本，循环丰富数据集。

数据增强时重点把握两个点：

和。准确性方面，我们要确保生成的SQL能执行且语义正确，会用一个专门的模型验证；多样性方面，通过相似性检测剔除重复样本，并尽量保持各类别数据均衡。同时，我们将样本按难度分为easy、medium、hard、extra hard四级，重点补充开源数据集中缺少的hard和extra hard样本。

经过数据增强后，模型在真实业务数据集上的准确率从GPT-4的32%提升到了52%，还能更好地处理复杂问法、复杂Schema和复杂计算逻辑。

但单独一个大模型很难达到理想效果，原因有三：数据集覆盖不全、语言多样性与歧义、噪音信息干扰。所以我们开发了一套智能体（Agent）流程来辅助大模型生成更高质量的SQL：

• 减少冗余信息，引入辅助信息
  ：先精选字段，只传递最相关的字段给模型，降低理解难度。

• 适当融入传统模型/策略
  ：用模型对用户问题做规范化处理，并加入few-shot检索，提高理解准确性。

• 对模型结果进行后验优化
  ：生成的SQL如果执行出错或语义不对，用大模型进行审核和纠错。

我们将这些思想整理成论文：通过信息精简、分类处理、针对性生成和自我纠错来提升模型性能。简单查询和复杂查询采用不同策略，生成时设定条件确保SQL可执行，并实施自我纠错机制让模型反思调整，再配合主动学习（active learning）针对常见问题重点提示，最终将智能体与大模型结合，显著提升了准确率。

5. Text2SQL之外

用户在做智能分析时，需求远不止text2SQL，还有改写、纠错、优化、解读、问答、补齐等。我们在系统中构建了多个智能体来辅助用户完成这些任务，提升整体效率。

上图展示了OlaChat的整体架构：底层服务、公共服务、Agent层、统一后端、统一前端，以及上层各种应用。各模块协同配合，为用户提供一致、高效的数据分析体验。

04 问答环节

A1：取数模型用的是8B参数的小模型，适合快速判断用户意图。NL2SQL则采用70B的模型进行微调。

A2：归因的准确率主要依赖归因工具本身。大模型推理能力虽强，但需要结合外部数据才能提高准确率。我们的做法是：基于归因工具拿到分析数据后，大模型负责中间串联和语言整理，最后呈现给用户。

A3：是的，纠错和解读都用到了大模型。但光靠大模型准确率不够，需要引入更多信息，比如SQL中用到的表的元数据，以及执行过程中的报错信息。不能只用大模型，要根据具体场景补充信息。

A4：直接生成SQL和基于语义层的简化方法各有优势。前者灵活性高，后者适合不熟悉SQL的用户，能有效提效。两种方式可以并存。