摘要：导读在数据智能与业务场景深度融合的时代，如何通过智能技术释放数据价值、提升分析效率，已成为企业数字化转型的核心课题。蚂蚁集团通过两年技术沉淀打造的 DeepInsight Copilot，完整演绎了 AI+BI 探索的全过程。本次分享将系统性的介绍 AI+BI

导读 在数据智能与业务场景深度融合的时代，如何通过智能技术释放数据价值、提升分析效率，已成为企业数字化转型的核心课题。蚂蚁集团通过两年技术沉淀打造的 DeepInsight Copilot，完整演绎了 AI+BI 探索的全过程。本次分享将系统性的介绍 AI+BI 融合的技术突破与实践思考，揭示智能分析从辅助工具向自主决策演进的过程。

今天的介绍会围绕下面六点展开：

1. DeepInsight 智能化简介

2. SFT 模型时代

3. 聚类推理模型时代

4. 知识是业务落地的关键

5. 评测集，Agent 的指南针

6. 新一代智能分析产品 DataSage，端到端场景的探索

分享嘉宾｜余志鹏 蚂蚁智信(杭州)信息技术有限公司 高级技术专家

编辑整理｜孟立诗

内容校对｜郭慧敏

出品社区｜DataFun

01

DeepInsight 作为蚂蚁集团历时八年打造的核心数据分析产品，其 AI 技术演进历程值得重点关注。

2020 年，早在大模型技术兴起之前，我们就已开始探索自然语言取数技术路径，这也是 DeepInsight 尝试通过自然语言降低产品门槛的第一次探索。在当时是基于 NLP 分词技术进行自然语言取数，但是缺点就是无法理解语义，仅能做到支持形式化提问。

随着 2022 年底 ChatGPT 的横空出世，蚂蚁快速布局 AI+BI 方向，并于 2023 年 9 月上线支持自然语言取数 Copilot。

2024 年进入全面建设阶段，逐步实现报表制作、报表阅读和自助分析等核心功能的智能化支持。

到 2025 年，随着 DeepSeek 推理模型的出圈，大模型可以支持复杂的任务，我们基于规划、推理、反思等技术探索更加复杂的分析任务。

在蚂蚁集团的技术架构中，我们对 Copilot 和 DeepInsight 有着自己的一套定义：Copilot 作为产品层的核心模块，本质上是一个 Agent 集合体，每个 Agent 都是能够精准感知用户意图并完成特定任务的智能实体。具体而言，一个完整的 Copilot 系统通常包含多个协同工作的 Agent，以自助分析场景为例，就集成了智能门控、数据查询等多个功能 Agent。这种架构设计与业界通用定义存在显著差异，体现了我们在智能体技术领域的深度思考。

在过去的两年多时间里，DeepInsight 已成功构建了五个核心 Copilot 模块和八个智能体。这些模块的具体功能实现和协同机制，我们将在后续的专项交流环节中进行详细的技术分享和案例演示。

当前 Agent AI 架构采用五层设计：基础层为大模型能力层，向上依次是智能平台层、数据分析核心能力层、Agent 层和 Copilot 应用层。在这个架构中，多个专用 Agent 通过智能组合的方式形成完整的 Copilot 应用。具体实现案例在此不做详细展开。

当前大模型技术在数据分析领域的核心挑战在于如何将自然语言指令精准转化为各类分析产物。在数据分析领域，这些产物主要包括可视化图表、DAL 代码以及完整分析报告等，实现从自然语言到结构化分析产物的高效转换，是行业亟待解决的关键技术难题。

回顾 2023 年的技术发展状况，当时国内大模型能力相对有限，特别是在数据安全合规要求下无法使用开源模型的情况下，我们面临着模型参数规模较小、性能不足的挑战。

在此背景下，要让模型掌握生成特定领域 DSL 语言或分析报告等新技能，目前主要的技术手段主要在两个阶段完成：

在预训练(pre-train)阶段融入领域知识，在后训练(post-train)阶段主要采用 SFT（监督微调）、RL（强化学习）以及 RAG（检索增强生成）等方法。在 Pre-Train 阶段需要足够的语料才会有效果，另外 PreTrain 的成本高，难度大。那么作为蚂蚁内部特定领域的 DSL，显然没有足够的语料，SFT 就作为这里唯一的选择。

在取数流程设计中，我们采用模块化架构将其分解为两个核心环节：自然语言理解（NLU）和自然语言转换为 DAL（NL2DAL）。这种设计的关键优势在于实现了职责单一化：NLU 模块专注于将用户自然语言查询转换为结构化查询语言，而 NL2DAL 模块则负责将结构化查询转化为可执行的 DAL 代码。这种解耦设计极大简化了 SFT（监督微调）过程中的语料构建难度，使每个模块只需处理单一维度的任务，既保证了 NLU 模块只需完成"自然语言→结构化查询语句"的转换，又确保 NL2DAL 模块专注实现"结构化查询语句→DAL 代码"的转换。这种方式最大限度降低了在训练阶段 NL2DAL 的难度，在后面章节中再次会讲到这种拆分的好处。

在构建 SFT 训练语料时，我们面临的核心问题是如何高效产出足够且高质量的语料，目前业界对于 SFT 阶段语料要求是 1 千~10 万条（实验阶段，基本万级别才会产生不错的效果）。准备语料目前有两种方式：一种是人工标注，这种方式效率低，但是质量高；另外一种方式就是通过合成的方式，这种刚好跟前面的相反，效率高，但是由于是形式化生成，质量可能一般。这里我们采用了合成的方式生成语料。通过对取数语言特征的深入分析，我们发现所有取数提问都可拆解为筛选、维度、度量和排序四大核心要素。基于这种结构化特征，通过采用要素组合的方式批量生成训练语料。这种方法不仅确保了语料覆盖率，还能快速扩展语料规模，在训练的过程中，提供了高效的支持。

然而这种语料构建方法也暴露了一个关键问题：当训练语料过于单一或提问过于形式化时，模型训练过程中的 Loss 值会快速跌 0，导致实际训练效果不佳。这正是我们在初期仅使用合成语料进行 SFT 训练时所遭遇的困境：为了满足 NL2DAL 的正确率，我们只能不断堆叠语料，但是不断堆叠的语料导致模型泛化能力越差，让训练陷入到一种负反馈。

针对这一问题，解决方案的核心在于提升训练数据的多样性与质量。正如上面《LIMA》的研究论文的结果：高质量且多样化的训练数据对模型性能具有显著提升作用——这一原则不仅适用于 SFT 训练，同样适用于 Pre-Train 等其他训练阶段。本质上，数据对于模型训练效果的关键影响因素可归纳为：数据多样性、样本质量以及不同类别数据的合理配比这三个维度。

我们采用多维度语料来解决这一问题，主要引入三类关键语料：

实践表明，这种融合人工标注、专业知识和合成扩展的混合语料策略，显著提升了模型训练效果。

CoT 语料的核心价值在于帮助大模型对 DAL 代码生成过程的逐步拆解。目前模型蒸馏也是用“教师模型”蒸馏出这样的语料。通过将完整的代码生成过程分解成多个步骤，使大模型能够深入理解 DAL 代码的组装逻辑和构建过程。这种分步拆解实现提升了模型对代码结构的“理解能力”，这有助于提升大模型的在 NL2DAL 中的泛化能力，这个在训练效果中有充分的体现。

我们前期的 SFT 训练取得了显著效果，其最大优势在于确定性——通过添加特定语料即可直接提升 NL2DAL 的正确率，这种线性改进特性在工程实施初期极具吸引力。然而这种确定性犹如"甜蜜的毒药"，随着训练深入，后期迭代效率明显下降，甚至出现负向优化的情况。

这一现象揭示了单纯依赖 SFT 方法的局限性：初期快速见效的优势，在模型的正确率达到一定水位后反而成为制约因素，导致边际效益递减，甚至变成负向收益。

03

推理模型时代

2025 年 2 月随着 DeepSeek 推理模型的出现，开源模型性能实现了质的飞跃。这一技术突破让我们面临一个关键方向选择：是继续沿用原有的 SFT 方案，还是直接使用更强大的推理模型。我们去年微调的模型都很小，最大的模型也只有 14B。而对于 DeepSeek 671B 的这种大模型微调的成本非常大，且不一定有效果。随着模型训练水平的迭代，模型的能力会越来越强，我们应该去享受基模带来的红利，基于这样一个趋势判断，我们选择直接使用推理模型。具体如下图所示：

在这一个阶段我们最大的改变是把 NLU 阶段的 SFT 模型换成了 DeepSeek-R1，通过 Prompt 的方式将口语化的提问转换成形式化提问，这一改进显著提升了处理口语化提问的能力。这里我们举一个例子，图中原始输入是“我要看杭州的交易金额，时间为最近 7 天”，我们通过大模型转换成形式化的提问“查询最近 7 天杭州市交易金额求和”，然后再通过底层的 SFT 模型把形式化提问转换成 DAL。

然而这套架构最大的瓶颈在于底层 SFT 模型支持的形式化提问的覆盖率，而根据过去的经验，当形式化提问越来越复杂时，已经很难覆盖。

那么，我们就得进一步思考：能否进一步突破现有技术框架，实现更彻底的性能提升？

既然底层的 SFT 模型是一个瓶颈，那么我们是不是可以直接通过一套模型完全实现，这就是端到端的方案。至少在我看来，端到端的方案是一个终极方案，是技术发展的一种必然结果。

在这个方案下最大的挑战是如何把自然语言转化成我们自定义的 DSL DAL。这里面我们用了现在比较流行的方案，就是 Context Engineering。给模型注入大量的知识，让大模型充分理解 DAL，从而在大模型不依赖 SFT 的情况下，实现用户的自然语言转换成 DAL。

这个方案最大的优点，就是可以最大限度的利用大模型本身的能力，然而这一架构引入了新的挑战——模型幻觉问题：当通过 Prompt 工程调优模型时，输出结果存在显著的不稳定性。正如前位演讲者所述，在 Pass@8 评估中，模型正确率可能从 70% 降至 20%，这种性能波动成为场景落地中最大的障碍。当前，如何有效控制模型幻觉成为我们亟需解决的核心技术难题。这个在后面章节中讲知识的时候也会再次提及，通过知识约束也是目前解决幻觉问题最有效的一种手段之一。

除了在技术上的探索，在产品形态演进方面，我们经历了重要改版：早期采用左右分栏模式（右侧自然语言提问区+左侧操作区），这种设计基于当时模型能力的局限性，允许用户通过人工修正来完善模型生成的结果。但随着 DeepSeek 等具备 COT 推理能力的大模型出现。产品的交互应该更匹配模型的能力，所以在交互上我们采用了目前比较流行的全屏 Chat 模式：以 Chat 为主，产品操作交互为辅的方式。这种模式的优点在于可以最大限度的利用模型本身的能力，比如展示模型的思维链，帮助用户知道模型的结果是如何生成的，这个对于后续复杂任务有非常大的帮助。这种产品交互会弱化产品交互，但是限于目前模型的能力还无法完全解决用户的问题，另外在一些场景下通过交互的方式显然比自然语言交互更加高效，所以仍然保留了一定的交互操作，最大限度的降低用户的操作门槛，提升用户的操作效率。

04

知识是业务落地的关键

接下来重点探讨知识确定性问题。正如此前强调的指标设计，其核心目标正是为了解决模型幻觉问题——通过在特定领域构建确定性约束框架，有效限制模型的随机性输出，确保生成结果的可控性和准确性。

现在在业务领域没有知识，只依赖大模型的通识，很难做到落地。这当然也是因为当前训练模型的数据主要来自于公网上的一些数据，显然不具备很多企业内部数据。如果大模型是发动机，那么业务知识作为燃料，在特定业务场景中发挥着决定性作用。在特定业务场景落地，以前我们经常讲“有多少人工，就有多少智能”，那么在这里，我可以讲“有多少知识，就有多少智能”。我在蚂蚁内部也经常讲，我们又回到了那个好好建设数据的年代，之前在大数据建设上做了很多工作，比如阿里的 onedata，蚂蚁也效仿阿里采用了类似的方式去做好数据的规范化。现在大模型时代强依赖知识，可能是倒逼数字化的一个非常好的契机。

这张图是一个常规的知识分类，这里算一个科普，目前知识主要是分为结构化和非结构化，大模型时代如何利用好非结构化知识是一个关键。这里当然有两个原因，第一：非结构化的知识是一种生产成本更低的知识，比如我们内部的文档或者外部采买的数据很多都是非结构化的知识，所以也就意味着非结构化的知识更加丰富。第二：非结构化是更倾向于人的方式，包括我们训练大模型用的知识最终也是非结构化文本。我们人类在天然生产“知识”的时候也是非结构化的，比如我这里的演讲，也是非结构化的输出。如何利用好非结构化知识就会成为一个关键。这里另外一个问题就是“知识的保鲜”，这个问题也会成为未来一个非常重要的课题。在过去非大模型时代，这个问题也非常严重，只是在非大模型时代，很多知识的更新和传递是由人完成的，而到了大模型时代，这中间的桥梁变成了大模型。而低质量的知识将会成为大模型的“毒药”，不会起到正向作用，反而会起反作用。

上面这张图算一个比较常规的 RAG 工程，这张图的核心主要是两块：一个是知识的 Embedding 过程，第二个就是在推理过程中如何获取相关知识的过程。

整体过程最难的就是当知识量大的时候，如何做到精准召回，所以前面两步都是在做这件事情。目前在 RAG 中有很多的技术优化，在存储阶段一般都会采取多套方式，比如向量化，或者按照 ES 的方式进行存储，甚至用 Graph 进行存储，最终的目标都是在推理阶段能召回更准确的知识。另外一个比较重要的就是知识按照分域存储，这个逻辑也非常简单，因为一个用户问题不可能跟所有的知识是相关的，只会用到某一个领域或者某几个领域的知识，这个可以大大缩小召回阶段的检索范围，不管是检索性能和检索性能的精准度。

下面我们讲一个实际的案例，这是一个来自蚂蚁生意参谋的实际案例：当商户交易金额出现异常下跌时，如何让大模型找到其中的原因。这个案例里面就需要几个关键点：第一，这是一个复杂任务，需要大模型强大的推理能力；第二，这是一个特定领域，需要领域知识才能让大模型理解这个领域。否则靠大模型本身的自有知识是非常困难的。所以在构建整个流程的时候，我们核心做了几件事情，第一：将用户的问题进行拆解成多个任务，这在人类解决问题也是一个非常常的思路，也就是分治的方法，把一个复杂的任务拆解成多个小任务，也方便大模型更好的去完成，也方便更好的通过工程的手段去介入。比如一个大任务，整个 Prompt 都不知道如何写，也无法调优。而拆解成一个一个独立的任务，每个任务都可以设计独立的 Prompt，这样就可以提高整体 Agent 完成复杂任务的准确率。所以目前大模型的架构也不断在往这个方向发展，不管是 MCP 协议还是 A2A 协议，其核心都是解决一个问题，复杂任务拆解成子任务，另外就是尽量利用已有的工具去完成，而不是完全依赖大模型去完成。在真实世界也同样如此，人类的大脑也不可能存储下所有的知识，所以会大量依赖外部的工具去完成，而大模型在完成任务的时候同样遵循这样的原理。我理解现在很多的技术框架或者模型的演进思路也越来越接近人类的工作模型，MCP 协议解决的就是人和工具交互的问题，A2A 协议就是解决人和人交互的问题。只是现在 Agent 和 Agent 还没有完全自动化的完成这些任务，这里原因就是前面讲的知识，因为这个世界所有数据的产生都是人类产生的。所以现在的人类承担的就是知识提供者的角色。未来如果大模型具备和人类一样实时学习的能力的时候，那将是一个新的篇章，这个在最后展望的时候会再次强调这个问题。

05

评测集，Agent 的指南针

评测集是现在很多 Agent 非常忽略的一个问题，原因非常简单，过去很多产品功能，都是由人去完成这些测试，到了大模型时代，同样会有这样的路径依赖。然而，这里面有一个非常本质的区别在于，功能是确定性的，而大模型是不确定的，中间在 Prompt 中改一些内容或者知识中心补充一些知识，都会对整个 Agent 的能力产生重大影响，那么这就依赖自动化评测去完成，否则效率极低。之前的产品功能，做完上线效果是确定的，但是 Agent 并非上线就达到 100% 可用，需要持续调优。而评测集的完善程度也就确定了 Agent 的迭代速度。

评测集的构建是一个“重资产”操作，要构建一套可用的评测集，需要大量的人力去完成，而且需要持续去迭代，这也是很多 ChatBI 并不重视构建评测集的原因。但是到了发展后期，没有评测集，迭代速度会越来越“举步维艰”，仍然要回到构建评测集这条路上。很多时候“慢就是快”，在依赖大模型的这条路上可以说发挥得淋漓尽致。

这张图是整个 Agent 构建的完整过程，评测集是 Agent 的“中枢”，中间 Agent 做了任何改动，都需要经过相关评测，保证 Agent 的改动是正向的。所以为什么我这一章节把评测集作为 Agent 的指南针，没有评测集，那么就会处于“盲人摸象”的状态，不同用户因为测试的问题不一样，最终结果就完全不一样，也就缺乏一个全局视角去评估当前 Agent 的水位，就更不要提未来的迭代方向。

当前 Text2SQL 领域的评测集存在显著局限性。深入分析发现，现有公开评测集存在三个关键缺陷：

一个评测集最重要的就是数据集和问题集的来源。

那么接下来最重要的是整个流程如何跑起来。这里我们不可能直接拿原始问题作为评测集，而是我们从这些种子问题中抽取特征集，然后通过这些特征集生成新的问题，从而完成问题的初始化，然后经过人工筛选、答案标注、难度分级，才算完成一个评测问题。这也是我前面为什么说评测集是一个“重资产”，这中间需要大量地的人工参与，特别是答案标准环节。

对于一个评测集最重要的有两个指标：难度分类和覆盖率。如果都是非常简单的难度，类似于现在的 Spider1.0 那么也失去了评测的意义。大模型也不断在迭代，如果说 2023 年的大模型还是小学生，那么现在的大模型可能就是高中生，评测集的难度也就需要“与时俱进”，不断迭代，问题集需要覆盖不同难度的问题，Agent 也可以根据当前自己的水位选择相应的难度进行评测。另外一个就是覆盖率，很多评测集由于覆盖率不足，和真实场景偏差较大，解决这个问题的核心一个是种子问题集收集要足够广泛，另外我们设计了一套唯一标识，保证评测集能够持续迭代。

在评测集的实际应用中，一个普遍存在的现象是评测分数与实际用户体验存在显著差异：评测结果可能高达 90 分，而用户实际使用效果仅为 70 分。这一问题的核心在于评测集与线上真实问题的匹配度。

我们的解决方案是：

随着 Agent 不断优化进行评测时，我们发现两种典型情况：当评测分数提升而线上得分停滞时，可能表明评测集覆盖不足或线上问题难度增加；反之，若评测分数持续高于线上表现，则反映评测集难度设置偏低，需要增加评测集的难度。

过去两年，我们在 Agent 和评测过程中做了非常多的探索，目前我们构建的这套评测集未来也会开源。确实，构建评测集是一个非常重的工作，我们也希望各厂商能够复用这套方案，不要再花大力气再去构建，另外如果有好的评测集，也可以分享出来，不断完善这个评测集。

今年 4 月份，Manus 突然在智能圈“炸街”，非常激进的进入到端到端的解决方案中。Manus 确实是一种更理想的解决方案，也意味着大模型可以解决更复杂的任务，其实在前面取数的时候我们也讲到了 Planner 以及“分治”法，其核心就是把一个大任务不断拆解成小任务，然后让不同的 Agent 去完成这些小任务，最终实现整个大任务这么一个过程。

在讲 DataSage 之前，我们讲一下人机交互的三个发展阶段（参考人机对齐领域专业著作）：Embedding 模式、Copilot 模式和 Agents 模式。这一分类体系揭示了AI能力范围的持续扩展——从早期的 Embedding 模式（比如基于小模型的推荐算法），到目前的 Copilot（人机协同的左右交互模式），直至未来的 Agents（自主智能体）。演进的核心驱动力在于模型能力的质变：从小模型到大模型，再到 Agents 所需的"大模型 Plus"版本。不过，现有大模型距离实现完全态的 Agents 仍存在理论和技术层面的显著差距。

当前 DeepInsight 的产品形态主要还处于 Copilot 阶段，而我们目前也在积极探索端到端的解决方案，分析版的 Manus。

我们新一代产品命名为 DataSage，寓意其将扮演"数据智慧专家"的角色。不过在当前技术条件下实现广泛适用性仍具挑战性——包括 Manus 在内的行业领先企业也仅能在特定场景落地。因此，我们聚焦 DeepInsight 的核心业务场景进行深度打磨，希望建立可复制的行业最佳实践。

低效的数据分析流程严重阻碍了数据价值的释放。基于长期行业积淀，DeepInsight 推出新一代数据分析智能体 DataSage，通过自主任务规划和端到端分析交付，帮助用户高效解决数据分析难题。DataSage 首批支持四大核心分析场景：

作为新一代数据分析智能体，DataSage 将持续迭代升级，致力于让每位用户都能拥有专属数据科学家的分析能力。

当前行业关键技术主要围绕三个关键协议展开：

需要特别指出的是，这些协议的实施效果与上下文管理密切相关——若将所有 Prompt 前置输入模型，极易因内容超长导致模型出现记忆丢失问题。

该整体架构采用分层设计：底层为接入层，通过 MCP 协议实现与各系统的交互；中间层为 Agent 层，现在 Agent 设计强依赖产品的工具，这也是 DeepInsight 的优势，过去积累的丰富工具能最大补齐模型的能力。实践表明，完全依赖大模型会导致效果欠佳，比如数值计算等任务若交由模型处理易产生幻觉导致算错，大模型 + 专业工具是完成用户任务一种比较好的形式，特别是这些要求较高的专业领域，不能出现数据错误，也不能捏造事实。当然这里其实是一个非常微妙的平衡。对于大模型来说，限制确实会显著降低模型的幻觉，但是同时也会降低模型的泛化能力。这个和我们写八股文和散文类似。所以在具体场景中，我们需要做的就是找到那个平衡点，发挥出模型最大的价值。

这是一个真实业务案例：在电商某企业的四月份支付成功率较三月份出现显著下跌，需要完成归因分析并产出报告。

该流程分为两个关键步骤：

值得注意的是，归因分析高度依赖 BI 系统提供的分析框架来确定归因维度和方法，而报告生成则需要用户提供分析模板作为基础框架。当前阶段，该流程仍需要大量人工参与，比如在分析阶段，我们会大量向模型注入专家的分析框架，这样有助于大模型取得更好的分析结果。很多人在这里可能会说，这跟人类的规则有什么区别。这里和规则最大的区别规则不具备泛化性，我们过往规则场景需要不断堆叠规则，导致规则系统完全无法维护。而大模型只需要给少量的 Few-shots，大模型基于模型内部的知识就能够泛化一些场景，未来随着模型的能力不断增强，这种泛化能力也会不断增强。

在落地实施方面，最关键的是与业务场景深度共建。这需要找到最佳实践路径，包括指标体系构建、知识库建设和 Prompt 调优等具体细节——"魔鬼都在细节"。从框架层面看，基础逻辑已经相对成熟，行业认知也达到了一定水平；真正的挑战在于实践过程中如何找到最佳平衡点，这类似于汽车制造或氢弹研发的原理虽然公开，但实际建造仍需要攻克大量技术难题。

以上就是本次分享的内容，谢谢大家。

来源：DataFunTalk