岑润哲-替代NL2SQL，Agent+业务语义的创新产品设计DataFunSummit2024_DigitForce

岑润哲/数势科技数据智能产品总经理 DataFunSummit#2024 引言：大模型技术对于数据分析领域能够解决哪些痛点 解决方案：智能分析产品常见设计思路以及优化路径 技术架构：Agent架构结合数据语义层（Semantic Layer）如何实现产品落地 应用场景：某零售连锁行业智能分析助手落地案例 产品设计理念与挑战：LUI+GUI融合的产品设计理念与挑战 未来展望：智能数据分析产品演进展望 01 引言：大模型技术对于数据分析领域能够解决哪些痛点 管理团队之痛：现有数据产品无法端到端快速产出深度结论 痛点 以下是3个不同客户发出的真实声音示例，反映了管理团队对现有数据驾驶舱大屏产品的痛点体验： Data ≠ Insight："我们公司花了很大精力建设了驾驶舱和各种大屏，看起来很高端，但数字并不等于见解。每次有具体问题，团队还得回去挖数据、分析指标，周报变成了无尽的等待游戏。" Speed is Everything："每当董事会要求针对数据作出快速反应时，我都希望能够立刻拿到结论，这个数据大屏却只能给我表面的数，深入分析还得是手工在数仓里建作业，太慢了。" 这些真实的客户声音例子反映了一个通用的诉求：管理团队需要的不单是数据的可视化展示，更是对数据的深入理解、快速获取结论和基于数据深度挖掘的原因解释，对数据分析工具的智能性和即时交互性有着更高的期待。 The Golden Why Question："我们的驾驶舱解决了数据展示的问题，但未触及数据解释的关键。当涉及到业务背后的为什么时，它似乎没有答案。" 业务人员之痛：BI产品学习门槛高，归因解读靠人工 痛点 以下是3个不同客户发出的真实声音示例，反映了业务团队在指标获取、数据分析与数据挖掘方面的核心痛点： SQL学习难度高："尽管我们有意愿深挖数据背后的真相，但SQL的复杂性让我们非技术人员望而却步。许多时间都浪费在了查询语言的学习上，而不是洞察和行动。" BI报表配置难度高："我们依赖BI工具来提供数据的可视化，但每次都需要技术团队介入来配置数据集和报表，它的复杂程度令人沮丧。" 大量时间花费在导出数据到Excel里输出结论："分析团队的日常就像Excel的奴隶，时常花费大把时间将数据导入、整理和分析，这种重复低效的工作限制了我们对数据快速反馈的能力。" 数据分析师/工程师之痛：重复报表需求杂、指标口径不统一、难以实时响应业务变化 痛点 以下是3个不同客户发出的真实声音示例，反映了数据团队在指标定义、指标开发和指标管理方面的核心痛点： 报表需求灵活多变，临时表冗余："我们数据团队大部分时间都花在了应对业务部门多变的报表需求上，每次业务流程一变，我们就得开发各种临时表、中间表。这不仅效率低，还很容易造成错误，甚至有的表用一次就废了" 指标口径不一致："虽然公司有众多部门在使用数据，但每个团队对同一指标的定义却截然不同，没有统一的数据口径和解释标准。这种不一致性给跨部门的沟通和决策带来了混乱" 难以实时响应业务新增指标需求："每次业务人员新增一个指标开发需求，都希望我们能半小时内提供相应的指标。现状是，虽然我们已经在数仓加班加点开发了，但还是被业务团队说反应慢，有苦说不出" 大模型的Agent架构结合指标语义层将加速数据民主化的进程 管理者/一线业务员直达数据，用数门槛降低，提升企业经营决策与日常业务流中数据参与度（民主化） 02 解决方案：智能分析产品常见设计思路以及优化路径 基于仓内指标语义的实现路径--繁琐复杂、业务指向性差 •ODS -> DWD -> DWS -> ADS,语义建在哪一层？ •数据产品经理、数据开发、终端数据使用者，谁来建数据语义？ 仓内语义结合LLM方案-- NL2SQL的瓶颈 ①准确率低 •企业级（千/万张表）数据查询准确率约60-70%•即使是GPT也难有一个直接可用的准确效果 ②成本高 •预训练大模型未掌握企业客户数据与数据格式定义，当数据源过大时，大模型对表的结构学习成本高（增量预训练、长窗口、functioncall等） ③性能差 •大模型写出的SQL未经优化，可能导致长查询的占比较多，性能不好甚至导致查询服务异常，多表关联的真实查询性能不可控 ④数据安全风险 •大模型直接对接数据查询，缺少数据权限管控，隐私与安全性风险较高，用户可通过问询获取非用户权限内的数据 ⑤能力单一 •很多高级的分析问题依赖底层引擎能力，无法靠大模型生成SQL 仓外数据语义灵活便捷，更加贴近业务 •数据建模右移，更贴近数据消费endpoint，更便于LLM Agent规划推理； •基于虚拟层做数据编织，口径管理更灵活、便捷。 仓外语义结合LLM Agent方案-- NL2semantics2API 结合大模型+指标分析平台，NL2semantics，提供更优方案 ①数据可信，准确率高 •预设数据指标的定义与管理，避免业务理解对不齐•借助思维链分析与歧义反问，提升泛化性，避免直接从文本到SQL ②学习成本低 •无需对大模型做预训练，仅需依据指标语义和知识库做用户意图理解，增强prompt语义•全流程白盒，企业客户用业务语言描述查询过程，方便快速排查 ③性能提升且稳定 •基于自研的数据查询加速引擎，智能优化查询语句•P95可实现从检索到回答的秒级出数 ④数据安全可保障 •利用指标分析平台的权限管理能力，结合RBAC基础，对数据与指标进行精细化的权限管控，实现数据查询的安全可控 ⑤能力覆盖更全 •高级数据分析问题，可通过精准的指标进行关联与展示，实现单项数据可查、报表可展示、总结报告可生成 03 技术架构：Agent架构结合数据语义层（Semantic Layer）如何实现产品落地 为什么复杂的数据分析场景需要Agent架构来支撑 大模型Agent架构结合数据语义层的整体技术架构分享 用户基于大模型Agent架构的理解和思考能力，实现基于自然语言的数据分析，并针对获取的结果数据进行智能解读与归因，提升经营分析效率 1.任务规划能力——将复杂任务化繁为简，逐步拆解让大模型自动执行。 2.数据理解能力——依托指标语义特性，让大模型更懂数据。 3.高效计算能力——将计算任务通过自研计算引擎提交执行，极大优化了计算效率。 04 应用场景：某零售连锁行业智能分析助手落地案例 零售案例分享：SwiftAgent赋能百名督导千家加盟商实现门店智能运营 在原有的数据仓库基础上，构建一套完整的指标体系框架，并帮助其打造一套可供战区负责人（管理团队）和门店督导（一线业务人员）快速使用的低门槛智能数据分析助手，推进数字民主化进程 项目内容：以产品分析和门店运营为切入点，建设统一的分析思路、分析语言、分析工具 构建统一财务经营、门店运营、门店管理、商品分析场景的指标体系，让分析能够进行多维度下钻 项目内容：以产品分析和门店运营为切入点，建设统一的分析思路、分析语言、分析工具 门店巡检场景一二级场景与依赖的原子能力与功能现状 1.目标设定 2.巡店计划 制定巡店的具体地址和其它信息。确定每次巡店的重点关注指标以及波动原因。 明确巡检的主要目的，如提升服务质量、确保标准执行、优化门店环境等。确定要达成的具体指标和当前达成率。 门店KPI查询 门店KPI归因 3.门店稽核 4.效果验收 对比巡检前后各项指标的变化情况。通过数据分析评估门店在服务、产品、运营等方面的提升效果。总结经验教训，为下一次巡检和持续改进提供参考。 检查门店的问题指标（如基础服务合格率、清洁卫生合格率、产品品质合格率、外卖点评合格率等），若有问题，从知识库中查找策略并推荐给加盟商 问题指标检索 门店前后对比 推荐策略查询 总结报告 指标平台能力SwiftAgent-数据分析技能SwiftAgent-知识问答技能 智能数据分析助手SwiftAgent在企业经营分析场景的产品演示 智能分析助手（SwiftAgent）帮助门店督导与总部管理团队分析提效核心成果 05 产品设计理念与挑战：LUI+GUI融合的产品设计理念与挑战 LLM加持下，产品设计需要结合LUI与GUI各自的优点，才能显著提升数据分析体验 常见挑战1：当用户提问模糊的时候，怎么提升交互体验 容错原则（Help users recognize, diagnose, and recover from errors） 理 想 中 的“让 用 户 随 便说 一 句 话 ， 大 模 型 产 品 马 上 开 始 完 全 自 动 化 执 行”，往 往 是 不太 可 能的 ， 因 为用 户 天生 就 是“懒”的 ， 而 且 语 言 本 身 也 具 有 一 定 的 模 糊 性， 因 此 在 产 品 设 计 环 节 里 ， 可 以 增 加 反 问 模 块 ， 让 大 模型 更 好 的 理 解 用 户 需 求 ， 一 步 一 步 把 需 求“精 细 化”， 提 升 正 确 结 果 概 率 ， 增 加 使 用 者 的 信 任 感 最近是多近？7天？30天？60天？ 按下单口径的订单量还是按支付成功口径算的订单量？ 是按一个区间做同比分析还是按时点？ 什么渠道啊？线上渠道？线下渠道？ 三方渠道？ 解决思路：用户可干预，让LLM反问并协助澄清 情况1：维度表述不清楚 情况2：指标表述不清楚 常见挑战2：如何让用户可以说企业内部的“黑话” 贴近场景原则（Match between system and the real world） 利 用 大 模 型 原 生 的 知 识 库 技 术 （e x . R A G） ， 来 更 好 地 让 用 户 说 他 熟 悉 的 用 词 、 短 语 和 黑 话 ， 而 不 是 强 迫他 说 系 统 术 语 。 常见挑战2：如何让用户可以说企业内部的“黑话” 通用文档 如文档性知识、QA对问答样例、客服FAQ等 企业内部专有名词 场景分析模版 多源数据读取：兼容不同格式的数据读取和处理，例如Word、PDF、CSV等 不同的业务角色在提出相似的问题时，分析场景和常用维度肯定是不一样的，因此需要预置让大模型理解。 企业内部的专有名词管理（如指标的在企业内的常见简称、缩写，还有一些行业或者企业内部的黑话） 文本向量化：清洗数据，将文本切块，并向量化存入数据库中。 •举例：当用户运营团队分析“门店情况”时，更多看的是新客首单人数、成熟用户复购人数、流失召回人数这类指标；而经营分析团队提出相似问题的时候，更多看营收、成本和利润类指标 •R12M指的是Rolling 12 Month•年级指的是会员年限•新客代表新增有效会员数 向量召回：查询向量数据库，并得到相似度TOP的文本块 Prompt构建：按照一定的规则组合Prompt，提高问答的准确率。 应用场景3：用户不仅需要提取数据，更需要分析思路 •我现在是拿到我想要的数据了，然后呢？•我接下来可以问什么类型的问题？•老板肯定不止要一份“数据”，要的是结论呀 创新价值3：通过持续反思学习让大模型形成追问机制，帮助用户解决特定场景的问题 06 未来展望：智能数据分析产品演进展望 对DataAgent的三个未来展望 能和人一样总结归纳了升级为总结之后自动决策 能生成一份报告--->通过连接让对应的系统自动执行 能像人一样规划了升级为像业务专家一样规划 本科生的规划能力--->研究生/博士生的垂直领域的规划能力 大模型从能听懂人话升级为帮人说话 让用户提出问题--->帮用户生成适合这个场景的问题