分解以提升注意力：通过工作流范式提升 text-to-SQL 的落地性能

摘要：第一部分：OlaChat 的诞生背景、挑战与架构演进深入探讨平台诞生的根源—业务的真实痛点，以及我们为应对挑战而设计的两代 Agent 架构。第二部分：DEA-SQL 方案介绍详尽拆解我们发表于 ACL 2024 的 DEA-SQL 工作，包括其背后的学术思考

导读本文将系统性地分享腾讯 PCG 大数据平台部在 Text-to-SQL（自然语言转 SQL）这一核心技术方向上的研究思考与在智能 BI 产品“OlaChat”中的落地实践。

本文内容包括以下四大模块：

第一部分：OlaChat 的诞生背景、挑战与架构演进深入探讨平台诞生的根源—业务的真实痛点，以及我们为应对挑战而设计的两代 Agent 架构。第二部分：DEA-SQL 方案介绍详尽拆解我们发表于 ACL 2024 的 DEA-SQL 工作，包括其背后的学术思考、相关工作对比，以及五个核心模块的设计哲学与实现细节。第三部分：Text-to-SQL 落地建设全面揭示在将研究成果转化为生产力时，我们在自研模型与核心数据建设上所做的精细化、体系化的工程努力。第四部分：OlaChat 的能力全景与产品形态立体化展示 OlaChat 覆盖数据分析全链路的能力矩阵、分层解耦的系统框架，以及多样化的落地产品形态。

分享嘉宾｜谢苑珍腾讯高级算法研究员

编辑整理｜陈锡杜

内容校对｜郭慧敏

出品社区｜DataFun

在项目启动之初，我们明确了必须攻克的三大核心挑战，它们构成了我们后续所有技术与产品设计的出发点：

挑战一：工作流设计 (Workflow Design)
如何设计一个完善、严谨且能无缝贴合真实数据分析场景的工作流，来有效支撑工业级的智能化使用？挑战二：功能可扩展性 (Function Extensibility)
如何丰富平台的功能矩阵，同时保证每一项功能都具备独立、可持续的迭代与优化能力？挑战三：业务落地效果 (Practical Effectiveness)
如何确保我们的技术方案能够在真实的业务环境中稳定运行，并产生切实可见的价值和效果？

针对这三个根本性问题，我们提出了三位一体的宏观解决思路，分别对应上述挑战：

思路一：拟人化思维的 Agent (Human-like Agent)
我们设计的核心是一个模仿人类专家思维模式的智能体（Agent）。它不是一个简单的“问-答”机器，而是一个能够进行规划、推理和反思的“大脑”，以此来构建一个稳定且强大的工作流。思路二：可插拔的模块化工具箱(Pluggable Toolbox)
我们将所有具体的功能（如搜索、绘图、代码生成等）都开发成独立的工具。这个“工具箱”是独立于 Agent 大脑的，可以灵活地嫁接到任何需要这些能力的平台之上，确保了功能的复用性和可维护性。思路三：原子化能力的嵌入式产品形态 (Embedded Atomic Capabilities)
我们将所有能力，无论是前端交互还是后端服务，都封装成可以独立嵌入的“原子能力”。这使得我们的技术可以以极其灵活的产品形态落地，从而最大化其业务价值。

2. 第一代 Agent 架构：源自人类认知系统的六模块框架

为解决工作流设计的核心挑战，我们提出了一个专门面向数据分析的 Agent 框架。

设计动机： 我们观察到，早期的一些智能化系统思路（如 ReAct、Tree of Thought 等），其共同弱点在于“基本上完全交由大模型去做决策”。这种模式导致系统在处理复杂问题时，路径发散，稳定性差，结果不可控。理论基础： 为了解决这一问题，我们依据一篇关于人类认知系统的综述（Survey），从中拆解并设计出了一个包含六大核心模块的 Agent 框架，旨在通过结构化的引导来提升大模型的推理能力和决策稳定性。

这六大模块分别是：

意图识别模块 (Intent Recognition):负责解析用户输入，识别出任务的具体类型，例如是“查询指标”还是“进行一次完整的数据分析”。控制器模块 (Controller):扮演“大脑中枢”的角色，负责调度和管理整个任务的执行流程。记忆模块 (Memory):用于提取和利用过往的经验与知识。这包括从我们沉淀的 “错误笔记（Bad Case 库）” 中学习，也包括从业务逻辑知识库中检索相关信息。推理模块 (Reasoning):这是 Agent 进行思考的核心。我们设计了多种多样的推理思维模板，如分解模板（由难到易）、计划模板、汇总模板等，这些都源自人类在解决问题时常用的思维模式，通过提示（Prompt）引导大模型进行更深入、更有条理的思考。主动学习模块 (Active Learning):我们称之为 “错题本”机制。当系统出现错误时，我们可以由人类专家编写正确的解决方案，并将其存入“错题本”。Agent 会在后续的学习进化中，利用这些案例进行针对性提升。●投票模块 (Voting):在推理模块中，不同的思维模板可能会得出不同的答案。投票模块会对这些答案进行汇总和投票，选择最优解作为最终输出，进一步增强结果的鲁棒性。

这项研究是当时最早尝试通过模拟人类认知框架来提升大模型能力的工作之一。实验结果非常显著，与当时基础的 COT（思维链）方法相比，我们的框架在部分数据集上最高实现了约 85% 的性能提升。

在将上述理论框架落地到 OlaChat 系统的早期版本时，我们参考其核心思想，形成了一个包含 7 个环节的、更贴近实际运营的 Agent 逻辑：

用户问题输入:用户发起一个自然语言请求。意图识别:系统首先判断任务类型，如“查指标”、“查业务表”或“数据分析”。意图澄清 (新增环节):如果识别出的意图信息不完整（例如，用户说“我要做数据分析”，但未指定时间段或业务范围），系统会主动触发 “用户意图澄清” ，反问用户以补充必要信息。任务修正:这是一个精细化的策略模块。针对一些边界模糊、极易混淆的任务类型（如“查指标”和“数据分析”），该模块会进行二次甄别和修正，确保任务分类的准确性。计划列表生成:根据最终确定的任务类型，系统会生成一个专属的、按步骤排列的行动计划。控制器执行:控制器依据计划列表，从记忆模块（如错误笔记、业务逻辑库）中提取相关信息，并从工具箱（包含搜索、代码生成、查指标、分析、绘图等工具）中选择合适的工具来执行每一步计划。Bad Case 沉淀与学习闭环:在整个系统运行过程中产生的所有失败案例（Bad Case），都会流入一个标注系统。经过人工或模型辅助修正后，这些宝贵的经验会反哺给模型，用于下一轮的学习和能力提升，形成一个完整的自进化闭环。

4. 最新 Agent 架构：基于 MCP 协议的现代化框架

随着新技术的诞生和我们研究的深入，OlaChat 最新的架构已经全面升级为基于 MCP 协议的现代化框架。

核心变化:在这个框架下，我们侧重于工具的标准化。原有的“工具箱”中的所有工具，现在都可以通过 MCP 协议无缝地被改造为一个标准的 MCP Tool，供大模型直接调用。特殊设计 - “思考与规划 Agent”:我们设计了一个非常特殊的工具，它本身就是一个“思考与规划 Agent”。在处理任何复杂任务前，主模型可以先调用这个“思考工具”，让它先进行一次宏大的计划制定和详尽的思考过程。递归式循环调用 (Recursive Loop):整个流程是递归的。客户端将请求和工具列表发给大模型 -> 大模型返回它决定调用的工具及参数 -> 客户端调度服务器执行工具 -> 客户端将执行结果再返回给大模型。这个循环会一直持续，直到大模型认为任务已经完成，最终返回的是最终结果，而不再是下一次的工具调用指令。这一步的完成，标志着整个请求流程的结束。

为了应对“功能扩展性”和“落地效果”这两大挑战，我们将所有智能化能力进行原子化封装，并以极其灵活的产品形态落地到多个产品中：

一站式全自动化平台:一个独立的 Web 应用，能够端到端地完成从数据接入到分析报告生成的复杂任务。嵌入式 Copilot:以智能助手的形态，轻量化地加载到现有成熟产品中。例如：搭载在公司内部主流的 BI 看板平台“灯塔”内，辅助用户理解和分析图表。搭载在“欧拉 SQL“智能编辑器旁，提供 SQL 生成、优化等伴随式编程能力。上下文“魔法棒”形态:直接集成在代码编辑区内部。用户可以主动唤起“魔法棒”进行提问，或对选定的代码进行操作。对于代码修改类的任务，它还会呈现 “左右对比” 的清晰视图。Table助手:一个专注于处理单表（类似 Excel）数据的智能化分析工具，提供了丰富的数据处理和图表生成能力，极大降低了轻量级数据分析的门槛。

DEA-SQL 方案介绍

Text-to-SQL，即自然语言到结构化查询语言的转换，是一项旨在弥合人类自然语言与数据库结构化语言之间鸿沟的关键技术。其核心目标有两个维度：

赋能非技术用户：使业务人员、运营等非技术背景的用户，能够通过日常对话式的语言（如“查询北京地区上个季度的销售冠军是谁？”）直接与数据库进行交互，从而摆脱学习复杂 SQL 语法的束缚，实现数据查询的“平民化”。提升技术用户效率：让数据分析师、工程师等技术用户，能够通过自然语言快速生成复杂的查询逻辑，将他们从繁琐、重复的 SQL 编写工作中解放出来，更专注于数据洞察和业务分析，从而极大地提升工作效率。

2. Text-to-SQL: 现有学术方案不适用于业务场景，高质量数据有限-> 先 Agent 后微调

在将 Text-to-SQL 技术应用于真实业务场景时，我们发现现有的学术方案存在“水土不服”的问题。

学术界主流方案大致可分为三类：

强力闭源 API + Agent：使用 GPT-4 等模型，效果好，但存在严重的数据隐私和安全风险，不适用于企业核心数据。模型微调：方案可控，但其命门在于对海量、高质量、与业务场景匹配的标注数据（(Query, SQL) pair）的极度依赖。传统方法：效果已远不如生成式模型，基本被淘汰。

这些方案在面对真实、复杂、且不断变化的业务环境时，共同的痛点被急剧放大：高质量的标注数据极其有限且获取成本极高。没有优质的“养料”，再好的模型也无法在特定业务场景下发挥出理想的效果。

基于这一核心困境，我们制定了清晰的、分两步走的落地策略：“先 Agent，后微调”。

第一步：先 Agent。在项目初期，我们利用现成的、能力较强的基座模型，集中精力设计并验证一套行之有效的 Agent 工作流。此阶段的核心目标是打磨方法论，并利用这个工作流在真实业务交互中沉淀和积累高质量的数据。第二步：后微调。当 Agent 工作流被验证有效，且我们积累了足够的高质量数据后，我们再启动自研模型的微调工作，用我们自己训练的、更懂业务的微 is 模型，去逐步替换掉 Agent 工作流中依赖外部基座模型的环节，最终实现一个完全自主可控、且深度适配业务的解决方案。

我们的研究建立在对该领域既有工作的深入理解之上。相关技术主要可以划分为两大范式：监督学习（Supervised Learning），即传统的模型训练；以及基于上下文学习（In-Context Learning, ICL），即以大模型为代表的、通过提示（Prompting）进行学习的范式。 DEA-SQL 的设计深受以下几项前沿工作的启发。

（1）ReSQL

ReSQL 的核心思想是 “解耦” 。它主张将复杂的端到端 Text-to-SQL 任务分解为两个更简单的步骤：

Schema Linking：首先，识别出用户问题中涉及的相关数据库表（Table）和列（Column）。Skeleton Parsing： 然后，在已识别出的相关 Schema 基础上，生成 SQL 的查询骨架。
通过这种方式，显著降低了模型的推理难度。

另一项启发性的工作是探索更高级的思维链（Chain-of-Thought, COT）范式。它不再将问题作为一个整体来解决，而是引入了问题分解（Problem Decomposition）的思想。例如，在生成最终 SQL 之前，先让模型思考并列出需要选择哪些字段（SELECT 部分），这为多步推理提供了更清晰的路径。

DIN-SQL 进一步发展了 “分步 COT” 的理念。它的贡献主要体现在：

模块化解决：利用专门的模块（如 Schema Linking）解决特定的子问题。难度分级：对问题按难度进行分类，并为不同难度的问题适配不同的、经过优化的提示词。后验自纠：在生成 SQL 后，增加了一个自我修正的环节，以提升准确性。

尽管上述相关工作提供了宝贵的思路，但单纯依赖提示工程（Prompting）或上下文学习（ICL）的方案，在落地时依然面临着难以逾越的四大挑战：

性能天花板：对于结构极其复杂的 SQL 任务，提示工程的性能始终存在上限，难以实现稳定、高精度的生成。注意力涣散：当数据库的 Schema 信息非常庞大时（例如包含上百个表和上千个字段），将其全部塞入模型的上下文窗口，会导致模型的注意力被严重稀释，从而遗漏关键信息，做出错误判断。业务语义理解鸿沟：模型对深层业务逻辑的理解几乎为零。例如，它无法从字面上区分“折扣率”和“净利率”的计算差异，也无法理解用户口中的“华东”地区在数据库里对应的是英文字段'east_china'。缺乏动态适应性：业务是动态变化的，例如维度值会不断新增。如果将业务知识硬编码在提示中，那么每次变更都需要人工去维护提示，这是不现实且不可扩展的。

为了系统性地解决上述所有挑战，我们提出了 DEA-SQL 方案。它并非一种新的模型，而是一套以“模仿人类专家思维”为核心，以“聚焦模型注意力”为目标的工作流范式。其遵循的核心原则是：将一个宏大、复杂的问题，分解为一系列模型力所能及的、简单的子任务，并在执行每一个子任务时，都为其提供最精简、最必要的上下文信息，从而针对性地增强模型在特定范围内的解决能力，最终提升整体性能。

DEA-SQL 的架构由五个核心模块组成，它们环环相扣，模拟了人类专家解决一个复杂数据库查询问题的完整心路历程：

（1）信息确定(Information Determination)目标：解决用户问法多变的问题，精准锁定相关的表和字段。方法：我们设计了一个巧妙的两阶段方案。第一阶段，元素识别，从用户问题中提取核心业务概念（如“歌手”）。第二阶段，Schema 链接，利用这个核心元素去元数据中匹配最相关的表和字段。这种方式能有效抵御句式变化的干扰。（2）分类与提示(Classification & Prompting)目标：长期优化，不断突破模型的能力边界。方法：我们将用户反馈的真实错误案例及其正确解法，整理成“错题本”。对于那些模型存在系统性能力短板、仅靠提示难以解决的问题，通过学习这些“错题”，模型可以实现持续进化。

DEA-SQL 这项研究的初衷，是验证这套 “以分解和注意力为中心”的工作流范式本身的有效性。因此，在论文的实验阶段，所有的模块功能都是通过提示词工程（Prompt Engineering）来实现的，而非依赖于模型的微调。

演讲中展示了每个模块所使用的具体提示词内容。这些提示词被精心设计，用以引导一个通用的基座大模型，让它按照我们设计的五个步骤来行动。例如，在“SQL 生成”模块，提示词的结构会清晰地包含 Few-shot 样例、精简后的数据库 Schema、明确的表连接关系、用户问题以及输出格式要求等部分。这些具体的提示词内容是该研究工作的核心实现细节，感兴趣的读者可以查阅我们的 ACL 2024 论文原文。

我们在论文中开展了详尽的实验，以回答以下四个核心研究问题（RQ）：

RQ1 (效果对比): 与当时最先进的（SOTA）方法相比，DEA-SQL 的表现如何？RQ2 (模块有效性): 框架中的每一个模块是否都必不可少？（消融实验）RQ3 (成本分析): 方案的 Token 消耗和推理时间成本如何？RQ4 (参数敏感性): Few-shot 样例的数量、信息过滤模块的准确率等超参数如何影响最终效果？

我们在权威的 Spider 和 BIRD 等 Text-to-SQL 数据集上进行了全面的评估，主要结论如下：

性能领先：DEA-SQL 工作流在所有数据集上的表现，均显著优于当时的 SOTA 方法，证明了该范式的有效性。模块必要：消融实验证明，移除五个模块中的任何一个，都会导致整体性能出现明显下降。最佳策略：实验还发现，基于问句模板（Template）的相似度来检索 Few-shot 样例是最佳策略，其结论与 DEA-SQL 等前沿工作相符。成本可控：我们的方法在推理时间上消耗相对较少，保证了实际应用效率。通用性强：我们将此方法加载到不同的基座模型上，均能取得性能提升，验证了其通用性。

Text-to-SQL 落地建设

1. Text-to-SQL 落地：自研模型落地更安全

在将 Text-to-SQL 技术投入实际应用时，团队出于对安全性与准确率的双层严格考量，最终选择了自研模型的方案。相比直接使用外部模型，自研模型能更好地掌控数据流转和内部业务逻辑，确保敏感数据和核心业务规则的安全性。同时，通过对模型的自主微调和控制，可以更有针对性地提升其在特定业务场景下的准确率。

高质量的数据是模型成功的关键。由于开源数据存在语言不符、场景过于简单、缺乏复杂逻辑等问题，团队设计了一套完善的数据合成方法。

核心策略：正向 (Query-to-SQL)：此过程为反向构造。首先基于数据库表（Table）生成自然语言问题（Query），然后再让模型为这个 Query 生成对应的 SQL。反向 (SQL-to-Query)：筛选出业务中高质量、逻辑清晰的已有 SQL，让模型根据 SQL 和库表信息生成对应的自然语言问题（Query）。数据扩散与校验：数据扩散：基于少量高质量的“种子样本”，通过自动化链路扩散生成成百上千条样本，包括对“问法”的扩散和对“Query-SQL”完整样本对的扩散。严格校验：所有生成的数据都需经过严密的多阶段校验，包括 Query 通顺度校验、SQL 语法校验、语义匹配度校验、SQL 执行测试，并辅以多模型交叉验证和最终的人工抽检，以确保数据质量。

经过上述数据、模型及 Agent 技术的综合加持，项目取得了显著成效：

性能提升：在一次具体的业务数据集评测中，模型的准确率得分从 32 分大幅提升至52分。能力扩展：实现了对复杂多样问题和复杂表结构 (Schema)的有效支持。能够准确理解业务专用名词和通用的计算逻辑。最终生成的 SQL 兼具高准确率和高稳定性。

整个系统（命名为 OlaChat）采用分层架构设计，前端、后端、智能体（Agent）等各模块相互独立，可以灵活插拔、快速复用和接入其他平台。

能力支持：提供了数据全链路的智能化能力，覆盖从“找数”到“分析”再到“解读”的全过程。数据发现：查表、查指标。数据分析：指标分析、SQL/Python 探索、SQL 补全与优化、代码纠错。深度解读：人群分析、数据解读、归因分析、图表绘制、异常检测等。2. 腾讯智能数据分析平台 OlaChat: text-to-SQL