企业级 Text-to-SQL 实战：从AI取数工具到智能分析Agent的演进之路

本文整理自QCon北京《王新波 - AI取数到智能分析演进之路》通过AI音视频转录总结工具Ai好记视频转文字转录整理以下为精炼整理后的会议笔记内容。做 AI 取数Text-to-SQL的同学应该都体会过那种落差。学术界的 benchmark 上Spider 这类数据集的 SOTA 方案准确率能做到 85% 到 91%跟人的水平差不多了。可一旦把同样这套方案搬到真实企业的生产环境里准确率直接掉到 10% 到 40%连 SQL 的语法准确率都只有五成上下。这篇内容讲的就是一个团队用两年时间把一个简单的一周做出来的 AI 取数 demo一步步迭代成支撑几千人生产使用的企业级智能分析 Agent 的全过程。整个过程踩坑密集很多思路对做数据平台和 Agent 的人都挺有参考价值。背景数据消费进入 4.0 阶段数据消费大体经历四个阶段。1.0 是传统 BI 时代以 SAP 为代表报表交付靠开发团队写 SQL。2.0 是自助式 BI以看板类工具为代表但作者提到自家月活 2 万多的看板里只有不到 10% 的人是报表生产者大部分人的数据消费还是要靠少数据 BI 同学手工操作。3.0 是增强分析开始引入 AI 辅助但流程仍由人驱动。4.0 才是 AI 原生的 Agent 时代用户直接用自然语言提交分析需求Agent 自主完成从取数到智能分析的全过程。第一版 demo 暴露的五大问题他们的第一版架构很典型把平台上近 30 天有访问的约 100 万张表做向量索引用户问题来了就基于相似检索召回相关表构造 prompt 交给大模型直接生成 SQL。结果第一版评测集上找表准确率只有 56%SQL 执行准确率不到 40%。同时期商业模型裸跑企业级 benchmark 也只有 10% 左右。总结下来有五大核心问题找表不准数仓分层多相似表成百上千向量模型难以区分细微差别召回的通常是语义相关但不正确的表。SQL 语义错误只用 Hive 元数据缺少业务规则和数据口径生成的 SQL 能跑但计算逻辑和结果不对。SQL 语法错误大模型混用各引擎专有语法在目标引擎上直接报错。模型幻觉生成表里不存在的字段、引用其他表的列名。交互割裂取数、找数、可视化几个入口相互独立连续分析要在入口间来回切。评测缺失评测集只有 50 多条脱离生产环境没有说服力。五次关键跃迁从单链路到场景化分析整个演进就是被这五大问题驱动的五次跃迁。第一次跃迁Multi-Agent 加元数据渐进式披露核心是双层架构。上层 Supervisor Agent 负责背景知识加载、意图识别、任务拆解和编排调度下层专业 Agent 分三个角色数据域确认 Agent、表发现 Agent、SQL 生成 Agent。关键设计是在确认数据域和发现相似表之后都引入用户确认环节两层确认机制保证 Agent 生成过程不走偏。配合渐进式披露解决上下文浪费。传统 RAG 一次性召回十几张表、每张上百字段上下文能占到 100K 上下但真正有用的可能只有 1 到 3 张表还容易触发长上下文腐化。他们的方案分三层先基于意图和背景定位业务域从百万级表缩到域内数百张再做域内表发现靠语义检索加热度排名挑出候选表交用户确认确认后才展开完整字段和业务规则。一个用户问「东南亚昨天 GMV 多少」能精准定位到 marketplace_order 域再落到订单明细表。第二次跃迁双层个性化AI 回答千篇一律是新的痛点。同样是问「GMV 为什么下跌」电商运营关心的是 marketplace 订单表数据财务关心的是全局汇总数据。他们引入两层个性化一是用户画像从权限平台拉取组织架构、角色、地域、数据权限等静态数据让 Agent 开口之前就认识用户自动倾向于推 SG 相关表和加地域过滤条件二是用户记忆把点赞、点踩、常搜表、历史口径确认等交互行为持久化跨 session 加载让 Agent 越用越懂用户。第三次跃迁语义模型突破准确率天花板纯大模型生成 SQL 有三重挑战业务语义理解口径怎么定表关联推理数仓层级多SQL 物理实现分区怎么选、多方言语法方案是引入语义模型作为数据抽象层做三件事业务数据映射到物理表字段和计算逻辑预定义标准指标、维度、过滤条件封装复杂性对外呈现统一的宽表概念。处理同一个问题纯 Text-to-SQL 要串行推断口径、对应物理表、过滤条件、按什么口径算任何一步错数据就错。基于语义模型只需生成一个极简 DSL后面的 SQL 映射交给语义引擎用工程方式翻译。最终采用混合路由简单探索性问题走传统 Text-to-SQL复杂且有语义模型覆盖的走 Text-to-DSL 链路。配套做了辅助语义建模 Agent输入表结构、线上 SQL 运行日志、现有报表配置三类元数据输出指标推荐、维度识别、关键路径发现、数语关系映射的建模草案人工审校后才上线并形成「建模、查询、验证、优化」四步反馈循环持续迭代。第四次跃迁复杂工程底座面向生产稳定运行工程体系分技术、评测、运营三块。技术部分重点讲了两个。文件系统上下文取数场景的上下文比普通 chat agent 复杂得多表元数据、语义规则、个性化数据、用户补充的内容全塞进去必然溢出。他们把知识用文件系统接口按层级组织最上层只加载用户画像定位数据域再加载域知识确认表后才展开详情不需要的信息随时从窗口 offload。中间结果也以 dataframe 形式存进虚拟文件系统模型只持有路径引用按需加载避免了多步骤分析中途结果挤爆上下文。隔离沙箱每个 session 的 Agent 跑在权限隔离、资源隔离的沙箱里高危的代码执行、Python 执行工具都在沙箱内运行防止恶意 prompt 借强大工具做破坏性操作。评测体系从踩坑中总结早期 QA 只做了 50 多条脱离场景的评测集没法用。后来改为面向分析主题、用线上真实执行成功且频繁的 SQL 构造评测集让大模型反向生成自然语言问题再人工 review最终积累三四千条。结果比较放弃语法树对比同一语义多种写法和大模型对比复杂场景分数差改以执行准确性为主配合时间字段规整、列一致性编辑距离、浮点容差比较。第五次跃迁Skill 机制实现场景化分析让 Agent 自由做归因探索时发现它常绕过关键维度下钻直接给结论专业 BI 无论对错都不敢用因为过程不可验证。Skill 机制在模型自主分析和定制流程间找到平衡。以归因分析典型 Skill 为例是严格五步指标趋势判断按国家品类渠道维度拆解计算贡献度排名和交叉分析按影响因子排序找根因生成结构化分析报告步骤不可跳过中间结果可追溯可验证。价值在于一次定义全员出发、过程可信、可扩展。元数据治理这个脏活作者特意强调data agent 不能只关心模型和工程架构数据质量同样关键。平台百万级表大量缺描述他们设计了 AI 加人工的四步治理按业务过程和数仓层级分组AI 生成描述草案依赖表名字段和业务域建模文档业务方逐条审查采纳血缘扩散自动为下游生成效果是 AI 生成描述直接被采纳的比例 70%一张 40 列表治理时间从 30 分钟缩到 10 分钟人工治理 2000 张表通过血缘扩散覆盖了 15 万张以上找表准确率最大提升 15 个百分点。未来趋势判断作者给了几个个人判断harness 会是 Agent 的操作系统Agent 等于 LLM 加 harnessAgent-First 是说数据平台应该面向 Agent 设计Agent 成为人和数据交互的新界面从工具到员工演进Agent 会获得自主调度、Skill 自我生成与进化能力变成可独立接收任务、修复、迭代的劳动力Agent 治理能力要始终伴随落地。以上内容由 Ai好记 转录整理。Ai好记是一款支持音视频转图文笔记的AI知识库工具支持B站、小红书、抖音、小宇宙等平台链接及本地音视频文件视频转文字后自动生成精华速览、思维导图和结构化图文笔记帮助你把几小时的视频内容变成可搜索、可复习的图文笔记。