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

在数据分析领域，从传统BI到智能BI的演进，并非简单的技术迭代，而是一场关于“谁有权问数据”的认知革命。而大语言模型的出现，恰好为这场革命提供了最关键的那把钥匙。腾讯OlaChat平台的落地实践，正是这把钥匙锻造过程的真实记录。

从传统BI到智能BI

传统商业智能的运作模式，本质上是一个自上而下的“需求-开发”闭环。业务负责人提出需求，开发人员介入数据提取与分析，经过漫长的开发周期后，结果才反馈到业务方。这个流程的问题在于：效率低下，沟通成本高昂，决策往往滞后。用户等待一份数据分析结果，常常需要一周甚至更长的时间——这在瞬息万变的业务场景中，几乎是不可容忍的延迟。

移动互联网的崛起，带来了数据量的爆发和复杂性的激增，也催生了“敏捷分析”的理念。其目标是让更多用户能够自助获取数据，通过简单的拖拽操作完成探索。然而，现实并不完美。调研显示，即使是“拖拽”这样看似简单的操作，对许多用户来说仍然存在学习成本。当需要计算环比、筛选复杂条件时，用户依然得去学习特定功能的使用方法——问题不在于操作的物理难度，而在于思维范式的转换成本。

到了2019年前后，智能分析的构想开始萌芽。尽管当时大语言模型还未全面普及，但业界已经意识到一个方向：能否让每个人都成为“数据分析师”？智能分析的概念逐步成型，核心目标直指降低技术门槛、简化分析流程。如今，随着大语言模型的普及，这个构想终于找到了落地的支点。用户只需要用自然语言描述他们的需求——比如“看看上周视频会员的付费转化率”——系统便能自动生成分析结果，效率与准确性都得到了质的提升。

LLM时代智能BI的新可能

大语言模型并非一夜之间横空出世。回顾其发展脉络，能更清楚地理解它为何能重塑智能BI的格局。

早期阶段，自然语言处理主要依赖概率模型，如条件随机场和马尔可夫模型。这些模型基于历史数据，通过词袋模型计算词语出现的概率，能力相对有限，主要侧重于预测——换句话说，它们更擅长“猜词”，而不是“理解”。2013年，谷歌发布的word2vec标志着神经网络时代的到来，LSTM等模型的广泛应用大大提升了语言模型对上下文的理解能力。而真正的转折点出现在2017年——Google发布了Transformer架构，随后BERT、GPT1/2等模型相继问世，参数量从千万级跃升至数亿规模，模型开始在大量语料上统一训练，展现出前所未有的语言理解能力。当前，GPT-3及其后续版本的参数量已经达到千亿、万亿级别，一个模型可以同时胜任多种任务，在文本生成、理解和逻辑推理方面都有了质的飞跃。

对于数据智能分析而言，大语言模型带来了四个维度的切实改进：

• 语言能力
  ：模型对文本和表格数据背后含义的理解已相当精准。用户不需要掌握复杂的工具或技术，直接用自然语言就能与数据对话。

• 工具使用
  ：大模型可以将用户的自然语言指令转化为具体的API调用或代码生成。这意味着数据分析效率大幅提升，技术门槛显著下降。

• 逻辑推理能力
  ：尽管模型的逻辑推理并非无懈可击，但在模式识别、趋势分析和关联性发现方面，它已经展现出足够强大的能力，能够帮助用户从数据中提取有价值的洞察。

• 学习能力
  ：得益于“上下文学习”能力，用户不需要重新训练模型，就能在特定任务上取得不错的效果。即使需要微调，也只需要几千条数据即可完成——这大大降低了模型落地的成本。

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

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

OlaChat的目标很简单：通过自然语言交互，让用户获得流畅的数据分析体验。但实现这个目标，需要一套精密的系统架构来支撑。其核心模块包括多任务对话系统、任务编排引擎、AI工具集以及底层的公共服务能力。

多任务对话系统

用户与OlaChat交互的第一入口是多任务对话系统。它就像一位智能助手，需要理解用户意图并执行相关任务。系统提供的功能包括“拒绝/澄清”和“引导/推荐”——当用户的问题表述不清时，系统不会直接报错，而是尝试澄清需求或推荐相关分析方向。

这背后依赖几个关键技术模块：上下文理解模块持续跟踪对话历史，准确捕获用户需求变化；意图识别模块将用户需求路由到对应的Agent；自然语言理解模块将文本消息转化为机器可读的语义标签；对话状态跟踪模块在每一轮对话中维护最新状态；对话策略模块决定下一步动作；自然语言生成模块则将系统动作转换为人类语言回复给用户。

元数据检索增强

在数据分析中，元数据的检索是核心瓶颈之一。问题在于：结构化数据——比如表和指标——有明确的层次结构（表名、字段、指标维度），其组织逻辑完全不同于非结构化文本。传统的基于embedding的检索方法在这里失效了，因为元数据不遵循自然语言的“前文预判后文”规律——“有效播放次数”和“付费播放次数”是完全不同的指标，而传统的语义检索很难捕捉这种差异。

为此，OlaChat采用了两种方案：

• FlattenedRAG
  ：将结构化的元数据“打平”为非结构化的自然语言文本。例如，指标“活跃用户数”+维度“男性”会被组合成“腾讯视频男性活跃用户数有多少？”这样的问答式文本。然后系统对用户问题进行检索、排序，找到最匹配的答案。这种方法的好处是能直接利用已有的自然语言检索技术，但当指标和维度数量太多时，容易面临组合爆炸问题。

• StructuredRAG
  ：充分利用元数据的层次结构，优先检索出最核心的元素（比如指标名称），再围绕核心元素进行二次检索，匹配用户问题中的其他条件（比如维度值）。这种方法在处理复杂、长尾问题时更加精准。

两种方案各有适用场景。在实际应用中，它们被灵活结合，以应对用户不同的数据分析需求。

Text2SQL

将自然语言转化为SQL语句是智能BI的核心能力之一，但真实的业务场景比实验室复杂得多。

首先，数据隐私与安全是不可逾越的红线。许多知名模型的使用协议中明确规定，月活跃用户超过一定数量的企业需要申请权限——对于腾讯这样规模的企业意味着大量闭源和开源模型都不可用，必须开发自有模型。其次，大模型虽然技术强大，但在业务理解方面存在显著不足：企业数据质量参差不齐、结构混乱，模型容易出现“幻觉”。第三，模型在真实场景下的稳定性和准确率不足——公开数据集BIRD的准确率约为70%，但实际用户问法更加个性化和多样化，抗噪声能力远远不够。最后，高质量的数据——尤其是“query到SQL”的配对数据——在项目冷启动阶段极度匮乏。

基于这些问题，OlaChat最终选择了一条务实路径：微调大模型 + Agent辅助。

高质量数据的生成是训练高效模型的关键。开源数据集大多面向英文场景，即使翻译成中文，结构也较为简单（单表、字段在10个以下），而实际业务场景中可能涉及上百个字段。OlaChat内部建立了一套数据生成逻辑：基于腾讯内部数据进行脱敏处理，随机选取样本，拼接成prompt输入到大模型，再由模型生成新的样本。在数据增强过程中，有两个关键控制点：准确性——必须确保生成的SQL能正确执行，且语义与用户查询匹配，为此设计了一套专门的验证逻辑；多样性——通过相似性检测剔除过于相似的样本，并按类别平衡数据集分布，特别重点关注困难（hard）和特别困难（extra hard）类型的样本生成，以弥补开源数据集的短板。

经过数据增强后，模型在真实业务数据集上的表现显著提升。例如，GPT-4在同样场景下的准确率为32%，而OlaChat自研的模型可以达到52%。不仅如此，自研模型还能更好地支持复杂问法、复杂Schema和复杂计算逻辑。

然而，单独依靠一个模型仍然难以达到理想效果。原因在于：数据集中查询类型的覆盖面有限，用户语言表达存在歧义和同义词问题，数据集中还夹杂噪音信息。因此，OlaChat开发了一套智能体流程来辅助模型生成更高质量的SQL：先进行字段精选，过滤冗余信息，只把最相关的字段传递给模型；适当融入传统模型和策略，比如通过少量样本检索帮助模型更好理解用户意图；最后对模型生成的SQL进行后验纠错，利用大模型对执行结果进行审核和修正。

这套方案的整体思路可以概括为：信息精简、分类处理、针对性生成、自我纠错。不问复杂程度一视同仁，而是根据查询难易度采用不同的生成策略；加入自我纠错机制，让模型对自身输出进行反思和调整；同时引入主动学习策略，重点对常见问题进行提示。通过将智能体与大模型相结合，整体准确率得到了有效提升。

Text2SQL之外

用户的智能分析需求远不止Text2SQL。改写、纠错、优化、解读、问答、补齐等多元化需求同样常见。为了满足这些需求，OlaChat在系统中构建了多个智能体。从底层服务到中间公共服务，再到Agent层、统一后端、统一前端，各模块相互配合，共同支撑起各类上层应用。

问答环节

A1：取数模型为8B，相对较小，适合快速判断用户的查询需求。而NL2SQL采用的是70B的模型进行微调。

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

A3：是的，但仅用大模型准确率较低，因此需要引入更多信息来优化。例如，可以加入SQL中用到的表的元数据，也可以将SQL执行中的报错信息纳入上下文。不能单纯依赖大模型，而是要根据具体场景补充信息。

A4：直接生成SQL与基于语义层的简化方法各有优势。前者灵活性高，后者更适合对SQL不熟悉的用户，为提效提供了一条可选的路径。