谭云志_基于LLM的智能数据分析平台在腾讯的落地实践

谭云志/腾讯高级研究员 DataFunSummit#2024 从传统BI到智能BI LLM时代智能BI的新可能 腾讯OlaChat智能BI平台落地实践 01 从传统BI到智能BI 从传统数据分析到智能数据分析 •使用人群：一线业务人员 •用户范围：多数人 •响应周期：天级别 •使用门槛：中 第二代敏捷BI 第一代传统BI 第三代智能BI •使用人群：老板、业务负责人•用户范围：少数人•响应周期：周级别•使用门槛：高 •使用人群：人人都是分析师•用户范围：全部人•响应周期：秒/分钟级别•使用门槛：低 02 LLM时代智能BI的新可能 大语言模型(LLM)给智能分析带来全新的可能 •语言能力：理解和处理人类语言的复杂结构和含义，理解和分析各种形式的数据，包括文本、表格等；自然语言的交互形式可以使得数据分析更加直观和易于理解 •工具使用：能够实现对工具的调用和代码的生成，如：text2api、text2sql、text2code、text2x •逻辑推理：从数据中发现模式、趋势和关联性，帮助用户进行更深入的数据分析和洞察 •学习能力：使用少量优质的数据集微调能快速的学会某一个领域的知识，模型迁移成本低 大语言模型(LLM)给智能分析带来全新的可能 欧拉&灯塔数据表、指标、画像、看板 语言能力、工具使用、逻辑推理、学习能力 OlaChat 基于LLM和腾讯大数据平台丰富的数据资产所打造的智能数据分析平台，基于自然语言的交互形式，有效降低用户查数、取数、用数的门槛 03 腾讯OlaChat智能BI平台落地实践 ü多任务对话系统ü元数据检索增强ütext2sqlütext2sql之外 腾讯OlaChat智能BI平台的关键能力 智能的多任务对话系统，低门槛的人机交互入口 •上下文理解（Context Understanding）：基于用户的历史对话，准确理解用户的需求，补充缺失信息•意图识别（Intention Detection）：将用户的需求映射到某一项特定的意图，便于后续流程更有针对性的进行处理•自然语言理解模块（NLU）：将用户文本消息转化为可以被机器理解的语义标签，如意图、槽位和槽值•对话状态跟踪模块（DST）：在对话中的每一轮基于对话历史维护最新的对话状态，通常表示为一组槽位-槽值对•对话策略模块（DPL）：基于当前的对话状态，决定对话系统的下一步动作，比如确认用户的需要，查询数据库和提供满足条件的结果等•自然语言生成模块（NLG）：将对话策略模块决定的系统对话行为转换成人类的语言，回复给用户 拒绝/澄清&引导/推荐 元数据检索增强（MetaRAG） 结构化元数据检索：基于用户的Query，确定用哪个“指标+维度”或者哪些“表+字段”可以获取到数据来满足用户的需求。要求尽可能精确，以便减少传递给LLM的噪声，避免获取到的数据不符合要求 通用RAG在解决元数据检索增强任务时存在一定的不适用性，主要因为： ①元数据是按特定的结构、层次组织的②指标、字段、维度的组合方式不符合语言模型的基本假设③特定修饰词很重要，如“有效”、“付费”④字段名可以很短，如“播放vv” 元数据检索增强（MetaRAG） FlattenedRAG(F-RAG) •通过枚举元数据的不同组合，将元数据所对应的数据集转化为问答知识库，从而实现结构化元数据的非结构化表示•问答知识库作为自然语言和结构化元数据的中间层，MetaRAG问题转化为传统的RAG问题•准确度高，无法有效解决长尾问题 StructuredRAG(S-RAG) •充分利用好元数据的结构特性，先召回用户的核心数据需求（如：指标），再基于此进行过滤召回修饰条件（如：维度、维度值）•基于召回的候选实体（如：指标、维度、维度值），训练数据选取大模型用于确定最符合用户需求的元数据组合•准确度稍低，可以有效解决长尾问题 元数据检索增强：FlattenedRAG 离线知识库生成 在线元数据检索增强 1.基于用户的真实Query，从知识库中多路召回相似Query2.将用户的Query与相似Query进行拼接，输入经过微调的语言模型（PLMEncoder）进行匹配程度打分3.选取相似度排序较高的相似Query对应的元数据作为检索增强的元数据 1.人工标注所需支持的指标、维度及Query模版；2.枚举元数据的组合方式，对应的Query模板完成匹配，生成离线知识库（亿级别），该过程实现了结构化元数据的非结构表示3.将知识库构建成多种类型的索引，供召回等模块进行使用 元数据检索增强：StructuredRAG 精选 训练数据选取的大模型，选择最终用于回答用户问题的元数据，包括指标和维度 策略 基于语义相关性、计算逻辑相关性、实体去重、模型打分等方式进行过滤，减少噪音 排序 1.利用知识库信息，构建样本训cross encoder模型2.使用时对召回的指标进行在线scoring，给后续排序策略层提供筛选依据 召回 1.多路召回核心候选实体2.围绕核心实体，召回核心实体下相关的维度 泛数据分析架构 Text2SQL真实业务场景下存在的问题 •大模型对业务数据理解不够：业务数据质量低，表数据脏乱，建表习惯不一，模型理解信息困难；大模型没有业务相关的知识且容易产生幻觉 •稳定性和准确率不够：真实情况下用户问法非常个性化，现有方案的抗噪声能力不足（BIRD~70%），导致稳定性和准确率较差 高准确的Text2SQL模型需要高质量的训练数据 ü开源数据集缺少对高难度计算逻辑的覆盖，遇到相对困难的问题时容易出错 ü开源数据集面向英文场景，少数的中文开源数据集也与业务实际场景存在较大的差距 高准确的Text2SQL模型需要高质量的训练数据 高准确的Text2SQL模型需要高质量的训练数据 ü实现对复杂多样的问法和复杂的Schema的支持ü实现对部分业务专有名词、使用范式、通用计算逻辑的支持ü能够生成具有较高准确和高性能的标准SQL语句ü返回的SQL具有较高的稳定性，相同的Query多次请求结果完全一致 Text2SQL智能体为模型鲁棒性保驾护航 大模型对领域知识理解能力不高 减少冗余信息，引入辅助信息探索沉淀数据标注规范，对冗余信息进行排序 精简，通过检索与预提示（时间、连表、领域词汇知识库、计算逻辑）提升整体准确率 源数据质量较低；信息过多导致模型注意力涣散；模型缺乏业务领域知识，复杂计算逻辑能力欠缺 适当融入传统模型/策略问题改写规整，问题分类&fewshot检索（mask, query） 大模型生成SQL的稳定性不高自然语言天然具备多样性和多义性，同时大模型为生成模型，本身也不稳定 对模型结果进行后验优化对模型结果进行错误分类；借助外部信息纠正潜在错误 大模型生成SQL的准确率不高模型生成结构化SQL的挑战很大，大模型本身对该任务支持度不高，任务类型难度大 Text2SQL智能体为模型鲁棒性保驾护航（DEA-SQL） Text2SQL之外：SQL能力矩阵辅助用户高效写SQL 腾讯OlaChat架构图 统一体验：提供Copilot和Polit2个页面，和一套魔法棒前端组件来支持应用层嵌入，保持了统一的交互体验 快速接入：页面可以通过微前端方式快速接入应用系统，通过统一的配置为应用定制需要的智能化能力，如果基于已有功能和数据，只需配置即可完成对接 提高复用：通过Agent智能体和公共服务提高代码复用，同一功能之实现一套 持续优化：算法同学通过持续升级智能体的效果来提升应用的准确率和覆盖率 THANKS