导读

近年来，大语言模型（LLM）的迅速崛起，为数据分析领域注入了全新的活力。从传统商业智能（BI）到敏捷分析，再到如今的智能分析，数据使用的门槛持续降低。移动互联网的全面普及带来了数据量的爆发式增长，而大模型的出现更让“通过自然语言查询数据”成为现实——用户无需学习复杂的分析工具，仅凭日常对话即可与系统交互。然而，即便在敏捷分析阶段，仍有大量用户认为拖拽操作存在一定学习障碍。大语言模型在语义理解、逻辑推理和工具调用方面的技术突破，恰好弥补了这一短板。它能够理解用户的自然语言指令，将其转化为数据查询，并输出直观的分析结论。本文将深入探讨腾讯基于大语言模型的智能数据分析平台 OlaChat 的落地实践，详细解析其如何逐步将“智能 BI”从概念变为可用的产品。

主要内容包括：

• 从传统 BI 到智能 BI
• 大语言模型时代智能 BI 的新机遇
• 腾讯 OlaChat 智能 BI 平台落地实践
• 问答环节

01 从传统 BI 到智能 BI 的演进之路

大语言模型的快速发展，正在深刻改变商业智能领域的格局。我们不妨回顾一下这一转变是如何发生的，以及它带来了哪些全新的机遇与挑战。

1. 传统 BI 的局限性

传统的商业智能体系通常采用自上而下的运作模式：业务负责人提出需求，开发人员负责提取数据并进行分析，经过一段时间的复杂流程后，再将结果反馈给业务方。这个过程不仅效率低下，沟通成本也相当高昂。一个分析请求往往需要等待一周甚至更长时间才能得到结果。等数据终于到手时，业务决策的最佳时机可能早已错过。

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

移动互联网兴起后，数据量急剧膨胀，数据结构也变得日益复杂。市场对数据分析的需求发生了根本性变化，从而催生了敏捷分析模式——让更广泛的用户能够自助获取数据。通过简单的拖拽操作，用户可以自主探索数据。然而，调查发现，即便是这种“简单”的操作，对于部分用户而言，学习成本依然不低。例如，要计算环比增长率，或者处理一些稍微复杂的分析逻辑，许多用户仍然感到困惑——真正的使用门槛并未消失。

3. 智能 BI 的初步探索

大约在2019年前后，虽然大语言模型尚未全面普及，但自然语言处理领域已经涌现出多个表现出色的模型。当时，业界开始探索一个核心问题：如何让更多人无需学习专业工具即可完成数据分析？目标很明确：让每个人都具备成为“数据分析师”的潜力。智能分析的概念逐渐成型，其核心在于简化流程、降低技术门槛。

如今，随着大语言模型的成熟，智能 BI 终于迎来了真正的爆发期。它不仅能处理复杂的数据查询，还能与用户进行自然语言对话——你说一句话，系统就能直接给出分析结果。无论是效率提升还是用户体验的改善，都实现了质的飞跃。

02 大语言模型时代智能 BI 的新可能

大语言模型的发展，是自然语言处理领域数十年技术积累的成果。理清这一发展脉络，有助于我们理解其对数据智能分析带来的深远影响。

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

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

早期的语言模型主要依赖概率计算，例如条件随机场和马尔可夫模型。它们基于历史数据，使用 N-gram 方法估算词语出现的概率——能力相对有限，只能完成简单的预测任务。

神经网络时代的崛起

2013年，谷歌发布了 word2vec，这成为了一个重要的里程碑。此后，神经网络模型开始在自然语言处理领域大放异彩，语言模型对上下文的理解能力显著增强。

Transformer 模型的兴起

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

当前的万亿参数时代

GPT-3 及其后续版本将模型参数规模推至千亿、万亿级别。一个模型即可在多种任务上表现优秀，无需再为每个特定任务单独训练。在文本生成、深度理解以及逻辑推理等能力上，均达到了前所未有的高度。

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

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

• 语言能力：它能够很好地理解文本和表格背后的深层含义，使数据分析过程更加直观。用户只需用自然语言描述需求，无需学习复杂的工具。
• 工具使用能力：它能够将用户的自然语言指令转化为具体的工具调用或代码生成。例如，用户只需说一句“帮我查一下这个月的活跃用户”，系统就会自动生成对应的 API 调用或 SQL 查询。
• 逻辑推理能力：虽然其逻辑推理并非完美无缺，但在模式识别、趋势分析以及关联性发现等方面已经足够实用，能够从数据中挖掘出有价值的商业洞察。
• 学习能力：以往训练一个模型以适应特定任务需要大量的标注数据。如今，得益于“上下文学习”能力，即使不经过微调也能取得不错的效果。即便需要微调，几千条数据就足以应对——灵活性大大提高。

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

接下来，我们将重点介绍 OlaChat 平台的落地实践。

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

OlaChat 的核心目标非常明确：让用户通过自然语言交互，获得流畅且高效的数据分析体验。该系统由多任务对话系统、任务编排引擎、AI 工具箱以及底层公共服务等核心模块构成。下面我们将深入剖析其关键能力与技术架构。

1. OlaChat 关键能力

• 多轮对话系统：用户与 OlaChat 交互的首要入口是一个多任务对话系统，它就像一个智能助手。用户用自然语言下达指令，系统需要准确理解意图并执行相应任务。
• 任务编排与执行：系统在理解用户意图后，会自动规划出执行任务所需的步骤，并按照顺序调用相应的工具和数据资源。
• AI+BI 工具箱：包括 Query 改写、text2SQL、指标分析等多种工具，通过不同的工具组合能够解决不同类型的分析任务。
• 公共服务：底层由统一 LLM 调度、知识检索增强、标注系统三部分支撑。统一 LLM 调度可以根据任务特性自动选择最合适的模型，并实现负载均衡与加速；标注系统则用于处理领域特定的数据，增强大模型对具体业务场景的理解。

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

2. 多任务对话系统

多任务对话系统的基础功能包括意图拒绝、信息澄清以及引导推荐。其核心能力主要体现在：

• 上下文理解：持续跟踪对话历史，准确理解用户不断变化的需求，并自动补全缺失信息。
• 意图识别：基于上下文信息，精准识别用户意图，并将请求分发至对应的 Agent 进行处理。
• 自然语言理解：将用户的文本输入转化为机器可理解的语义标签。
• 对话状态跟踪：在每一轮对话后，维护并更新最新的对话状态（即一组槽位-槽值对）。
• 对话策略：根据当前的对话状态，决定系统下一步应采取的动作。
• 自然语言生成：将系统的决策结果转化为自然语言，回复给用户。

3. 元数据检索增强

在数据分析中，元数据检索是至关重要的一环。然而，数据本质上是结构化的（包含表、字段、指标、维度），因此传统的非结构化检索方法并不适用。例如，表名、字段名、指标名之间具有明确的层次关系，不能简单地使用 embedding 进行匹配。

通用 RAG 在元数据检索上存在的主要问题包括：

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

为此，我们设计了两种解决方案：

• FlattenedRAG：将结构化的元数据“扁平化”处理成自然语言文本。例如，生成“腾讯视频男性活跃用户数有多少？”这样的问答对。当用户提问时，系统从扁平化的知识库中检索最相似的文本，再进行排序匹配。
• StructuredRAG：充分利用数据结构信息，优先检索核心元素（如指标），再围绕该元素进行二次检索（如维度）。例如，先确定“活跃用户数”，再匹配“男性”等具体维度。

两种方案各有优劣：扁平化方法简单直接，但指标与维度的组合过多时容易导致数据爆炸；结构化方法更加精准，适合处理复杂的长尾问题。在实际应用中，可以根据具体场景灵活切换使用。

在泛数据分析架构中，底层包含指标、库表等元数据，以及用户画像和历史问答集。这些数据经过标注系统处理后，再通过关键词检索和语义检索，最终经过知识精简步骤，为上层的指标分析、人群圈选等应用提供强有力的支持。

4. Text2SQL

Text2SQL 在真实的业务场景中面临着诸多挑战：

• 数据隐私与安全：许多知名模型的使用协议要求，如果月活用户数超过一定规模，就需要申请特殊权限。对于大型企业而言，很多闭源和开源模型都无法直接使用，必须自行开发。
• 业务理解不足：大模型虽然技术能力强，但并不了解具体的业务背景。对于低质量、结构混乱的数据，模型难以准确理解，还容易产生“幻觉”现象。
• 稳定性与准确率不足：现实场景中用户提问方式千变万化，现有方案的抗噪声能力有限，稳定性和准确率都有待提高。
• 冷启动数据匮乏：高质量的 query 到 SQL 的标注数据非常难以获取。

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

高质量的数据是模型效果的基础。然而，开源数据集大多面向英文场景，翻译成中文后结构相对简单，字段数量也很有限。而在实际的业务环境中，数据表可能拥有上百个字段，操作符也更加复杂。这都导致了模型表现不佳。

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

• 数据收集与脱敏：收集腾讯内部的数据，并进行严格的脱敏处理。
• 随机选取数据：从脱敏后的数据中随机选择样本，拼接成 prompt 输入大模型。
• 数据增强：让大模型基于已有的样本生成新的样本，通过循环迭代不断丰富数据集。

数据增强过程中，我们重点把握两个关键点：准确性和多样性。在准确性方面，我们确保生成的 SQL 能够成功执行且语义正确，并采用专门的模型进行验证；在多样性方面，我们通过相似性检测剔除重复样本，并尽量保持各类别数据的均衡分布。同时，我们将样本按难度分为 easy、medium、hard、extra hard 四个等级，重点补充开源数据集中较为稀缺的 hard 和 extra hard 样本。

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

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

• 减少冗余信息，引入辅助信息：首先精选字段，只将最相关的字段传递给模型，降低其理解难度。
• 适当融入传统模型或策略：利用模型对用户问题进行规范化处理，并加入 few-shot 检索，提高理解准确性。
• 对模型结果进行后验优化：生成的 SQL 如果执行出错或语义不对，利用大模型进行审核和纠错。

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

5. Text2SQL 之外的能力

用户在进行智能分析时，需求远不止 text2SQL，还包括 SQL 改写、错误纠正、性能优化、结果解读、问答互动以及信息补全等。我们在系统中构建了多个智能体来辅助用户完成这些任务，从而全面提升整体分析效率。

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

04 问答环节

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

A1：取数模型使用的是 8B 参数的小模型，适合快速判断用户意图。而 NL2SQL 则采用 70B 的模型进行微调，以处理更复杂的查询任务。

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

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

Q3：SQL 纠错和 SQL 解读是否用到了大模型？

A3：是的，SQL 纠错和解读都运用了大模型的能力。但仅靠大模型本身的准确率还不够，需要引入更多信息，例如 SQL 中用到的表元数据，以及执行过程中的报错信息。因此，不能完全依赖大模型，而要根据具体场景补充必要的上下文信息。

Q4：直接生成 SQL 语句是否过于复杂？

A4：直接生成 SQL 和基于语义层的简化方法各有优势。前者灵活性更高，能够应对复杂查询；后者则更适合不熟悉 SQL 的用户，能有效提升工作效率。两种方式可以并存，以满足不同用户的需求。