📰 AI 资讯

从 AI 取数到智能分析：企业级数据 Agent 的多阶段演进与工程化落地

2026-07-14 09:53

在大模型技术蓬勃发展的背景下，企业数据消费正从传统的 BI 报表和自助式分析，迈向 AI 原生的 Agent 时代。然而，将学术界看似成熟的 Text-to-SQL 技术落地到复杂的 OLAP 场景中，其准确率可能从纸面上的 90% 骤降至 10%。本文整理自 Shopee 技术专家王新波在 QCon 全球软件开发大会 2026 北京站的分享《从 AI 取数到智能分析：企业级数据 Agent 的多阶段演进与工程化落地》。王新波详细复盘了过去两年其所在团队在打造企业级 Data Agent 过程中的实践与反思。他系统性地揭示了从解决找表不准、语义错误到引入 Multi-Agent、语义模型与 Skill 机制的完整技术演进路径，并分享了如何通过工程底座与运营闭环，将一个简单的取数工具逐步雕琢为支持个性化与场景化智能分析的可靠生产力工具。以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。<h2 data-type="heading" data-id="heading0">背景与挑战：从 BI 演进到 AI 原生数据消费</h2>数据消费的发展通常被划分为四个阶段。1.0 时代是传统 BI 时代，以 SAP 等系统为代表，报表交付高度依赖 IT 团队通过编写 SQL 来实现。2.0 时代迈入了自助式 BI，Dashboard 成为主流。以我所在公司的数据平台为例，Dashboard 的月活大约有两万多，但在这两万多用户中，只有不到百分之十是数据的生产者，也就是报表的编辑者。这说明绝大部分人的数据消费，依然要指望着少数的 BI 同学进行手工操作。到了 3.0 的增强分析时代，开始引入 AI 作为辅助，但主要的分析流程依然由人驱动。而现在，我们正大踏步跨入 4.0 ——AI 原生 Agent 时代。在这个阶段，数据消费者终于可以直接通过自然语言提交需求，Agent 则能够自主完成从取数到智能分析的全过程。我们团队对 AI 取数的探索始于 2024 年。起初，我们对 Text-to-SQL 这条路信心满满，因为学术界当时的 Benchmark 数据非常亮眼。在 Spider 这类榜单上，一些 State-of-the-art 的解决方案准确率可以达到 85% 到 91%，这甚至已经接近了人类标注员的水平。基于这份信息，我们设计了一个初代 Text-to-SQL 的 Demo 架构，不到一周就完成了搭建。当时的技术方案采用了典型的 RAG 链路：我们把平台上近三十天内有访问记录的大约一百万张表做了 Embedding 索引，用户提问后，系统通过向量近似检索召回相关的表，然后利用这些表的元数据构造 Prompt，交给大模型一步生成 SQL。然而，这套方案上线后的效果非常差。我们构造了一个内部评测集来摸底，甚至还是简化版本的评测集。但就在这个评测集上，找表的平均倒数排名仅能达到 56% 左右，而 Text-to-SQL 的执行准确率更是不到 40%。更令人沮丧的是，就连最基本的语法准确率也徘徊在百分之五六十。差不多同一时间，Spider 发布了 2.0 版本的 Benchmark，这个新版本号称是基于企业真实 OLAP 场景构造的评测集。当时比较先进的商业化模型 GPT-4o，其裸模型在 Spider 2.0 上能达到的准确率只有百分之十左右。结合 Spider 2.0 的这个数据和我们的初版实践，我们得出了一个残酷的结论：企业级 OLAP 场景下的 Text-to-SQL，是一件极其困难的事情。<h2 data-type="heading" data-id="heading1">Text2SQL 技术演进之路</h2>面对前期的技术难点，我们对初代 Demo 和种子用户的负反馈进行了深入分析，归纳出了五大核心问题。第一是找表不准。数仓有着严格的分层，每一层之间和内部都存在大量结构相似、只有细微区别的表。对于 Embedding 模型来说，通过语义相似性检索去区分这种微弱的差异是非常困难的，结果往往会召回看起来相关但实际上完全错误的表。第二是 SQL 语义错误。第一版架构仅仅使用了表元数据，严重缺失了业务规则和数据口径，导致生成的 SQL 虽然能跑出结果，但计算逻辑和数据结论完全不对。第三是 SQL 语法错误。大模型经常会混用 MySQL、PostgreSQL 等专有语法，而我们的底层引擎是 Presto 或 StarRocks，这些不兼容的语法会导致 SQL 直接报错。同时，模型幻觉也频繁出现，比如编造出表中根本不存在的数据列，甚至引用其他表的列。第四是交互体验差。系统里的找数、取数等功能入口各自独立，用户需要在不同模块间来回切换，体验感很差，系统响应时间也慢。第五是评测缺失。我们当初只构造了一个仅包含五十多条数据的极简评测集，完全脱离了生产环境，即便把 Agent 调校到很高的分数，也不敢放心交给业务使用。带着这五大核心问题，我们开启了 Text-to-SQL 的技术演进之路。这段路可以总结为五次关键的跃迁，每一次都由真实的生产痛点所驱动。第一次跃迁是从单链路 RAG 转变为 Multi-Agent 加元数据渐进式披露的解决方案，主要解决找数和体验割裂的问题。第二次跃迁引入了用户画像和持久化记忆，实现了从“千人一面”到个性化响应的跨越。第三次跃迁引入了语义建模，利用语义模型和辅助建模 Agent 来突破纯大模型生成 SQL 的准确率天花板。第四次跃迁则是设计了一套包含文件系统上下文和 Sandbox 等工具的复杂 Agent 工程底座，用以支撑复杂分析和长时间稳定运行。第五次跃迁我们引入了 Skill 机制，使用户能够自定义多步骤的流程化分析主题，最终实现了从取数到场景化分析的转变。先来看第一次跃迁，其核心设计在于 Multi-Agent 架构。系统被分为两层。上层是 Supervisor Agent，负责背景知识加载、意图识别以及任务的拆解与编排，然后把具体任务交接给下层的专业子 Agent。下层是专业 Agent 层，包含了三个关键角色：Data Scope Clarity Agent 负责确认用户问题归属的数据域；Data Discovery Agent 负责在已确认的数据域内精准找到相关的表；而生成 SQL 的 Agent 则基于已确认的表元数据和业务知识，完成最终的 SQL 生成。在这个过程中，我们加入了两层 Human-in-loop 机制。在 Data Scope Clarity Agent 找到业务域后，会引入用户确认环节；在 Data Discovery Agent 找到相似表后，同样会引入用户确认。只有用户确认通过，Agent 才会进入下一步。这种两层确认体系能够确保 Agent 的推理过程不走偏。另一个重点设计是元数据的渐进式披露。传统的 RAG 系统习惯于一次性通过相似性检索召回所有候选信息，但假设召回了十几张表，每张表又有上百个字段，如果把这些表描述、Schema 和列描述全部塞进上下文，真正有价值的信息可能只占其中一到三张表，这会造成极大的上下文浪费和严重的上下文腐化问题。针对这点，我们引入了三层元数据披露逻辑。第一层是业务域定位，基于意图识别和公司已有的业务域基础元数据，直接在百万级表中定位出用户问题所命中的数据域，将范围从百万级缩小到域内的数百张表。第二层是域内表发现，基于语义检索、热度排名，结合表的语义规则，从数百张表中进一步挑选出候选表并交由用户确认。只有当用户确认后，我们才会来到第三层：深度知识展开，即加载这些候选表的完整 Schema、字段和关联业务规则。比如，当用户提问“东南亚地区昨天的 GMV 是多少”，系统会在 L1 阶段定位到“Marketplace Order”业务域，接着在表发现阶段锁定订单明细表和每日 GMV 增量表等一到三张表，用户确认后，这些表的完整信息才被加载。这一机制让上下文窗口既可控又精准。找到了正确的表之后，流程进入 SQL 生成阶段。整个生成 Workflow 被我们拆分为四个步骤。当系统拿到用户问题和候选表上下文后，第一步会引入歧义和缺失检测。例如，如果候选表中包含多个与 GMV 相关的指标，系统会通过 Human-in-loop 方式让用户确认具体的计算口径，消除歧义后再进入下一步。第二步是多路并行生成候选 SQL。我们会同时启动三条生成路径：第一条是自校正模式，模型生成后会进行反思并自我修正，然后交出候选 SQL；第二条是任务分治模式，将问题拆解成子任务，分别生成结果后再合成为候选 SQL；第三条是简单直接生成模式。这三条路径产生的候选 SQL 会进入第三步选优环节，由 Agent 从中挑选出最优的一个，然后进入第四步验证和修复。在这一步，我们会先用 SQL 编译器验证语法错误，如果发现错误，则开启一个修复与再验证的闭环，由大模型结合我们植入的专用语法知识来提升修复效果，最终交出可执行的 SQL。为了支撑高质量生成，我们将相关的上下文信息分为四层。第一层是最基础的 Hive 表元数据，包括表名、表描述、字段名、字段描述等信息。第二层是业务域知识文档，我们内部称之为 Mart，这里包含了仓库建模介绍、数据使用帮助文档及 FAQ 等，我们对其做了语义压缩和结构化提取。第三层是 Topic 运营知识，这允许 BI 同学补充业务口径、业务术语，并将其与少量的专有表或语义模型绑定，从而在根源上规避找表阶段的不确定性。第四层是技术类元数据，包含三类信息：一是高质量 SQL 硬样例，这是我们从线上日志中基于打分机制筛选出来的；二是表的一些 Sample Data；三是表的统计数据，这部分主要来源于 Metastore 中的 Hive Statistics 数据，比如行数和列分布情况，以及我们通过枚举值挖掘链路识别出的离散列可能取值，这些知识在生成 SQL 时能有效帮助大模型写对查询条件。引入 Multi-Agent 后，效果和体验的割裂问题有了很大改观，但我们很快遇到了新的痛点：AI 的回答千篇一律。比如，同样是问“GMV 为什么下跌”，新加坡运营的同学关心的是他负责的特定市场订单表，而全球财务的同学则关注全局财务汇总的 GMV 数据。为了解决这个问题，我们进入了第二次跃迁，引入了双层个性化体系。第一层是用户画像，我们从权限平台等系统拉取用户的组织架构、角色、所属区域、数据权限等静态数据，在对话开始前就将其加载到上下文中，这样 Agent 在开口前就已经“认识”了用户。如果线上询问的是新加坡的运营同学，Agent 就会倾向于推荐新加坡市场相关的数据表，并在生成 SQL 的查询条件里自动加上 region = ‘SG’。第二层是用户记忆，我们实现了跨 Session 的持久化偏好记忆。用户在平台上的交互行为，比如点赞、点踩、经常搜索的表、曾经做过的口径确认、配置的数据映射等，都会被持久化存储。在用户发起新一轮对话时，系统会基于相似性规则，将相关的历史记忆加载到上下文中，实现 Agent“越用越懂你”的效果。有了个性化能力和多路生成的 SQL 框架，我们依然发现，纯靠大模型生成 SQL 的准确率很难突破预期的天花板。我们分析总结了三重挑战。第一重是业务语义理解，比如要生成正确的 SQL，系统需要推断出 GMV 的口径、活跃用户的定义，但在缺失业务规则的文本上下文里，这种多步加工过程中的幻觉会不断累加，导致语义类错误频发。第二重是表关联推理，OLAP 场景下的数据加工往往需要复杂的多表 Join，其关联链路又因数仓层级的复杂性而极难推导。第三重是 SQL 的物理实现，比如分区的选择、数据表查询分区范围的确定，以及各种函数语法的混用，这些直接导致了很高的语法错误率。这三层复杂度的叠加，是纯大模型方案难以提升的核心原因。对此，我们的第三次跃迁是引入语义模型，作为一个数据抽象层，它充当大模型与底层物理数据之间的桥梁。我们做了三件事：一是将业务数据映射到物理表字段和计算逻辑上；二是预定义好标准指标、维度和过滤条件，使得大模型不再需要从零开始推理业务逻辑；三是让语义模型封装技术的复杂性，对外呈现得像一张统一的宽表或 Cube，封装了底层的 Join 关系和过滤条件。大模型看到的将是业务概念而非原始的物理表，这显著降低了其生成任务的难度，直接带动了整体准确率的提升。例如，计算“昨天新加坡区域的 GMV”，在纯 Text-to-SQL 模式下，系统需要推断统计口径、定位物理表和字段、绑定过滤条件、确定聚合维度，任何一步出错结果就不对。而基于语义模型，系统只需要生成一个极其简单的 DSL，描述清楚统计指标、时间范围和区域，剩下的 DSL 到 SQL 映射就不再依赖大模型生成，而是由语义引擎以工程化的、确定性的方式翻译为可执行的 SQL。有了语义模型之后，我们就面临了一个工程决策：后续所有查询生成是否都要交给 Text-to-DSL 来处理？我们最终选择了混合 Workflow 的方式。用户问题提交后，会先经过一个意图识别与复杂度评估环节。这个环节分为两个维度：我们可以让大模型自主评估，用户也可以配置策略进行自路由，例如将个人的 Topic 数据域设置为一直走语义模型或一直走 Text-to-SQL。如果交给 Agent 评估，Agent 会基于问题的复杂度来做路由选择。如果问题简单且偏探索性，就走传统的 Text-to-SQL 链路；如果问题涉及复杂的计算逻辑且有可用的语义模型，就走 Text-to-DSL 链路。两条链路最终都会生成物理可执行 SQL，交付给后续的取数、可视化和分析。语义模型虽然能提升准确率，但其构建过程本身非常复杂。传统方式是由数据专家人工构建，周期长且费力。为了缩短这个工作量，我们设计了辅助语义建模 Agent，目前还处于 Beta 阶段。它的输入包含三类元数据：第一类是表结构、字段描述和数仓层级等基础元数据；第二类是已经在线上运行的 SQL，以供 Agent 学习查询模式、字段常见的计算逻辑、指标与过滤条件的绑定关系等；第三类是公司现有报表平台上已配置的数据集和看板，从这些定义中学习维度与指标配置，从数据集中学习指标的计算口径。拿到这些信息后，语义建模 Agent 基于用户的建模意图执行四项操作：指标推荐、维度识别、关键路径发现、数据关系识别与映射填充。它生成的结果是一份语义模型的草案，这份草案并不会直接上线，而是需要交由启动建模的数据专家进行审核、修改和确认，确保没有质量问题后才会上线，用以支撑 Text-to-DSL 链路。这个思路的核心是，通过辅助工具降低复杂度，但最终的数据质量交由专家把关。语义模型上线也并不意味着终点。我们在生产环境中认识到，打造一个完美的 Agent 或语义模型从来不是一蹴而就的，它更像一个需要不断带教、辅助优化的实习员工。为此，我们建立了一个“四步循环”来持续优化语义模型。第一步是 AI 辅助建模，快速产出草稿。第二步是语义驱动查询，模型上线，执行 Text-to-DSL 查询，但会打上 Beta 版本的标签。第三步，线上用户对 Agent 输出结果的反馈信息，会被回流给数据专家，由专家进行 Review 和审核，从中发现语义模型的缺陷并进行优化。第四步，优化后的语义模型重新上线。这样就形成了一个“建模、查询、验证、优化”的反馈闭环，保证语义模型在线上能够持续正向迭代。<h2 data-type="heading" data-id="heading2">Data Agent 工程体系</h2>AI 取数的准确性问题得到阶段性解决后，另外一个核心挑战浮现了出来：如何保证 Agent 在线上能够 24 小时稳定运行，并拥有完整的评测和运营闭环？我们的工程体系全貌可以被划分为技术体系、评测体系和运营体系三大部分。技术体系内部又细分为六大块：知识管理、文件系统上下文、隔离环境、Agent 工具箱、Agent Skill 以及个性化能力。我挑选其中两个最关键的技术点展开。第一个是文件系统上下文。在 Data Agent 场景下，模型上下文比一般的聊天 Agent 要复杂得多，它涉及表的基础元数据、Schema、语义规则、个性化数据、语义建模知识等。如果一股脑地把所有信息都塞进上下文窗口，不仅很容易撑爆窗口，还会触发严重的上下文腐化问题。我们的做法是引入一个虚拟的文件系统，其后端存储可以是 MySQL 或分布式文件系统。我们把各类知识按层级结构组织起来，这和元数据的渐进式披露相辅相成。在对话开始时，只加载最上层的元数据，如用户画像；在确定数据域时，加载 L1 层的业务域知识；只有当用户确认了具体的表之后，我们才展开最详细的信息和语义规则。而那些在当前阶段不再需要的信息，则会被择机从上下文窗口中卸载下来。此外，文件系统上下文另一个重要作用是缓存多步分析产生的中间结果。比如在一个归因分析任务中，第一步取出的数据集，后续的每一步分析都依赖于它。如果把这个庞大的数据集一直放在模型上下文里，窗口会被严重占用。我们的做法是将取到的数据以标准化 DataFrame 的方式存储到文件系统中，模型上下文中只保留一个 Reference 或数据路径。当后续步骤需要使用工具时，直接传递这个 Reference 即可，而不必在上下文里流转一个超大的数据集。第二个重点是隔离环境，也就是 Sandbox。我们给每个 Session 中运行的 Agent 都提供了一个权限隔离和资源隔离的沙箱环境，以此保证运行的安全与可控。我们提供的一些关键工具，比如批处理执行和 Python 代码执行，全都在这个沙箱环境中完成，从而有效防止恶意 Prompt 利用工具进行破坏性操作。接下来的评测体系同样至关重要。它包含评测集建设、评估执行、结果评分三部分。在评测集建设上，我们踩了不少坑。最早一版的评测集由 QA 团队帮忙生成，只有五六十条数据，严重脱离真实的业务场景，我们根本无法依据它得出的数据去优化一个面向生产的 Agent。后来我们转变思路，决定基于线上真实使用的 SQL 来构造评测集。我们面向特定的分析主题或重点优化领域进行表的选择，搜索线上被执行成功且执行频繁的 SQL，以及源自成熟稳定报表平台的 SQL，然后让大模型依据这些 SQL“反向生成”出对应的自然语言问题。生成的问题全部交由人工 Review，审核通过后才积攒到评测集中。最终，我们积累了一个包含数千条数据的评测集，它面向不同的分析主题和难度级别，成为我们的离线评测基准。在结果比较方面，我们也做了很多探索。我们最先尝试了通过 AST 抽象语法树来比较两个 SQL 是否一致，但很快发现，相同的语义逻辑可以有多种多样的表达方式，它们对应着完全不同的语法树，这种比较方法效果很差。然后我们选择了基于大模型的准确性比较，这在简单场景下效果不错，但在复杂场景中，由于存在多种等价的写法，大模型评估的分数并不理想。我们通过人工比较和模型评估的交叉验证，确认了这个现象。最终，我们决定以执行准确性比较作为主要的评估手段。为了解决执行结果比较中的一些问题，比如 AI 生成的 SQL 可能带有临时别名，或者时间列的格式灵活多变，我们对时间字段做了归一化处理，并基于类似编辑距离的算法来计算列名的一致性；针对浮点数或经过类型转换的数据，我们设计了基于残差和容差的数据比较策略。我们把这一整套结果比较逻辑做成了一个工具，集成在评估 Pipeline 中。现在，平台上的知识库、Agent、模型的任何改动，都可以方便地触发离线评估链路，来对比改动前后的效果变化。在介绍运营体系之前，我想插入一段关于元数据治理的实践，因为它对整体效果的影响非常关键。我们在开始做 Text-to-SQL 的时候就发现，平台上有大量的 Hive 表完全没有表描述和列描述。大模型在只有干巴巴的表名的情况下，几乎不可能找到符合用户需求或语义正确的表。所以我们同步启动了一个元数据治理流程。平台上有百万级别张表，靠人工去治理是不可想象的，因此我们设计了一个 AI 与人工协同的四步治理流程。第一步，我们按照业务过程和数仓的层级，对一些表进行分组。例如，将相同业务语义的表，或是按 Region 拆分的表，都放到同一组内。这些同组的表共享相似的业务语义。第二步，以表组为基本单位，交给 AI 生成描述。它依赖的信息不仅是平台上的名字、字段，更大量地依赖了业务域建模的相关知识、用户帮助文

🔗 查看原文 ↗

← 返回资讯列表