大模型与数据库的交互，从使用数据者到数据管理者

01

背景：大模型与数据库的交互

1. 背景：MCP 的兴起

（1）MCP协议

2025 年 2 月,MCP 协议逐渐兴起，AI 技术市场热议 MCP 协议是否成为一个统一开源的工具接口。

国内魔搭社区 4 月发布了国内最大的 MCP 市场平台，包含 1500 个 MCP Server。国外 Smithery 平台，也提供了非常多的 MCP Server。

（2）MCP Server VS Function Calling

MCP 的兴起让市场用户觉得是否应把自己的能力 MCP 化，以及现有工作是否嵌入 MCP 进行优化。基于 OpenSource 的 Task benchmark，从结论上看，部分 MCP 协议相对效果提升，但 MCP 生态更友好,且它确实有助于简化开发流程、降低技术门槛并促进生态系统的协作。

（3）三个案例

①Case1:数据助手

这个案例的核心目标是通过 MCP 与 AI influence 技术搭建数据助手，简化数据库问答流程。

在这个演示中，用户通过 MCP 连接 MySQL 数据库并展示其结构，使用开源 goose 客户端配置 MCP 后，可直接以自然语言发起查询（如“查看 XX 的所有数据”），系统调用析言 MCP 服务完成数据检索。与现有聊天式 BI 产品功能相似，但 MCP 方案的优势在于完全开源且终端灵活（支持 client、cursor、claude desktop 等），使数据查询从重应用开发转变为仅需 MCP 配置和简单 AI 推理即可快速实现的轻量级方案。

②Case2:小红书运营助手

小红书运营案例展示了 AIGC 技术在内容创作与发布的自动化应用。

当前小红书运营的核心痛点在于：尽管 AIGC 能够生成图片或视频内容，但最后一步的上传操作仍需人工完成，形成“最后一公里”的效率瓶颈。

MCP 的引入改变了这一状况。通过本地存储的小红书账号 cookie 实现自动化流程：首先调用文生图服务在魔搭平台生成视觉内容，随后无缝衔接至小红书 MCP 服务。MCP 通过程序化控制浏览器，自动完成图片上传、文字描述填写等发布全流程，实现从内容生成到平台发布的端到端自动化。这一演示性方案验证了 LLM（大型语言模型）通过控制 MCP 技术，能够逐步打通 AIGC 应用的最终环节，显著降低人工操作依赖。整个过程无需人工介入，完整复现了传统需要手动操作的发布流程，展示了自动化技术在内容分发场景中的应用潜力。

③Case3:支付宝服务

支付宝 MCP 服务作为最新发布的市场服务之一，展示了通过技术组合实现自动收银的潜力。

• 订单创建：比如用户通过支付宝 MCP 服务发起请求，系统生成一个金额为 0.01 元的订单。

  
  

• LLM调用与链接生成：该请求由 LLM（大语言模型）调起支付宝 MCP 服务器，服务器响应后返回一个可执行链接，该链接可在 PC 或手机端直接访问以完成支付操作。

  
  

• 支付执行：用户点击链接后，需扫描生成的二维码完成支付，整个过程通过扫码即可实现。

  
  

通过 LLM 与 MCP 的协同（即由 AI 驱动的自动化代理），替代传统人工收银流程，为商家提供自动化收款解决方案。目前此案例仍属演示性质，但体现了技术整合在提升服务效率方面的应用方向。

2. 背景：LLM 的数据平权

MCP 的改变使得市场对于 LLM 和 Agent 的讨论变得更加丰富,这不得不延伸到 LLM 模型的数据管理和数据平权的讨论，研究 LLM 对数据库的交互技术是数据平权的最后一环。

用户日常会使用的数据都是 LLM 的数据源之一，故而“数据源是 LLM 的外脑”。

（1）数据源的类别

①网页

网页作为常见数据源被广泛应用于 AI 模型的知识扩充。用户在使用通义千问、Kimi 等工具时，可通过启用网络搜索功能调用搜索引擎。该过程实质是通过浏览器或搜索引擎对网页内容进行索引，获取相关检索结果后，将这些信息整合到模型的知识库中，从而生成更全面的回答。因此，网页数据因其丰富性成为 AI 系统获取实时信息的重要来源，其应用方式已被普遍采用。

②文件

文件作为常见数据源：当使用通义模型生成 PPT 时，该模型不仅负责部分内容的创作，还会在工作过程中访问用户本地文件进行操作。这种通过直接读取和处理文件数据的方式，体现了文件类型数据在外脑型 LLM 模型中的典型应用——即模型利用外部文件资源完成特定任务处理的模式。

③知识库

知识库分两类：

• 文档类型知识库：以结构化或非结构化的文档形式存储知识

  
  

• 知识图谱类型：通过实体关系网络构建的语义化知识体系（该领域已积累大量研究成果）

  
  

知识库的核心价值在于两类知识库均能实现海量数据的系统性整理，为 LLM 模型提供了可访问、可调用的结构化知识资源，为模型应用提供了重要的数据基础。

④数据库

数据库概念可分为：基础数据库、数据仓库、数据湖等多种数据存储概念。

（2）数据源的差异性

使用数据源常见问题：

①网页

搜索引擎通过专业维护的索引系统，能根据关键词快速返回高质量网页结果，是良好维护的数据内容。但其检索到的网页内容存在以下痛点：

• 面向人类设计：网页包含大量非文本元素（如 HTML 标签、视频等），这些内容只对人类用户具有展示价值；

  
  

• 噪音干扰显著：网页存在非核心信息对 LLM 模型构成处理障碍，模型需额外进行去噪操作才能有效提取关键信息。当通过浏览器或 AI 搜索调用时，LLM 需要面对网页中复杂格式与冗余内容的挑战，直接影响信息处理的准确性和效率。

  
  

②文件

企业文件管理和存储存在的问题：

• 企业存在大量零散存储的 Excel、文本等各种格式文件，虽包含丰富模态数据，但因缺乏系统组织（如随意存放在桌面或文件夹）。

  
  

• LLM 模型在访问时面临索引困难，难以精准定位到具体问题相关的数据文件。

  
  

针对这些问题，采用 compute use 方式访问文件系统的数据检索方法作为未来可能的解决方案方向。

③知识库

知识库是经过系统化组织且具有较高可信度的信息管理方式，许多企业会投入资源构建和维护自己的知识库体系。

自 2000 年代起，知识库管理便已开始发展。然而，其存在显著的扩展成本问题：企业需投入大量人力进行知识库治理，并依赖专人清洗数据。每当需要扩充知识库内容时，均需额外增加人力成本，导致长期维护负担较重。

目前，部分企业尝试通过 RAG（Retrieval-Augmented Generation）或知识图谱（KG）等技术手段，让大语言模型（LLM）更高效地访问和利用知识库资源。

④数据库

数据库通过数据工程师的工作,通常具有数据建模完善、可信度高等优势，但其存储的表结构（尤其是日志表）高度抽象且物理化，导致 LLM 模型难以直接理解其中字段的具体含义。

当通过 MCP、Agent 或 Function Call 等方式接入 LLM 时，会引发数据平权问题：模型无法自主判断不同来源数据的权重与可信度优先级。

例如某公司数据库中记录的销量数据（如 10 万台）与网页公开数据（如 13 万或 9 万台）存在差异，这种多源数据冲突凸显了问题本质。当 LLM 需要整合数据库、网页等多源信息时，必须通过交叉验证和数据审查机制，才能确保模型准确识别真实可靠的数据源。随着多数据源接入技术（如 MCP）的普及，如何实现数据间的权重区分与可信度判定，将成为数据平权领域亟待解决的核心问题。

（3）总结

数据库平权是数据平权领域里最难处理的部分，因为数据库是技术底层的设计，关键性的结论是研究 LLM 模型对数据库的交互，就是数据平权中的最后一环。

3. 背景：海量的技术方案

有海量方案来处理 LLM 模型对数据库的交互的问题，基本上,可以分为以下类型。

4. 背景：Text-to-SQL

Text-to-SQL 是一个挑战相对较大，但是极具潜力的方向。SQL 是最被广泛使用的编程语言之一。

51.52% 的专业开发者会在工作中使用 SQL，但他们中仅有 35.29% 经受过系统性训练。所以，实际很多人不会写 SQL，或者说写的 SQL 并不好。

Text-to-SQL 这个问题被定义为直接把问题变成 SQL 的过程通过程序自动化执行。

Text-to-SQL 十年发展史分成四大阶段：

第一个阶段：基于规则方法，用语法树语法规则结构。

第二个阶段：深度神经网络，用 Encoder-Decoder 的架构,。

第三个阶段：预训练语言模型，用 pre-training、Schema-linking 方法，结合 NLP+SQL 访问数据库。

第四阶段：大语言模型，用 ICL、Fine-tuning、Multi-Agent 等方式，来执行 SQL 访问数据库。

5. 背景：The Dawn of Natural Language to SQL：Are We Fully Ready？

下图也展示了这四个阶段，分别是四个颜色，然后每个小块是一个典型算法。

不同块分为实心块，空心块以及虚线块，分别代表了不同的 benchmark，分别是 WikiSQL、Spider、BIRD。

可以明确看到从 2021 年以后，所有的预训练模型和大语言模型阶段上的研究者，主要都局限在 Spider、BIRD 这。并且 Spider 现在半开源状态，基本选择 BIRD 较多一点。

02

研究现状与技术挑战

1. 典型方案：CHESS+GPT4 by Stanford

典型方案,斯坦福采用的 CHESS+GPT4 的一个方案

方案核心流程：

（1）橙色流程

①获得用户问题，先进行关键词理解，这里处理方法有抽取、NER、Rewrite 等方式

②这个部分对 Question 增强,并且完成业务属性调整,进行关键词抽取意图识别等

（2）蓝色流程

①Database 处理,针对数据库进行 Dump DDL;

②针对 DDL 挑战进行处理

• Schema 理解挑战：数据库 DDL 中包含复杂元素,比如数据建模 Schema 时会存在 A_ID 之类的要素，LLM 模型无法理解

  
  

• Schema link 挑战：Dump DDL 中存在海量表和海量的列，LLM 进行理解时,

  
  

  受限于大模型上下文窗口，数据库信息无法完全上载

  
  

  海量数据库信息，会导致精度大大降低

  
  

③Schema Retrieval机制，是把用户问题和数据库建立起一个语义连接，即 Schema 建立一个语义连接。通常只选出用户问题相关的 Schema，选出来之后，通过结合业务处理过的用户问题内容以及筛选出来的 Schema，一起给到 LLM 模型进行生成。

（3）绿色流程

用户问题与数据库 Schema 进入到 LLM 模型的增强生成 SQL 语句时，也会面临多方言挑战,关于主流的 SQL 方言支持度比较好，但是当遇到小众数据库，比如 Sqlite，LLM 总是会试图去写 Sqlite 语法，但是会出现很多问题。

2. Text-to-SQL 的关键挑战

Text-to-SQL 存在一些相当复杂的挑战，包括 Schema 理解挑战、Schema linking 挑战、SQL 生成能力挑战、方言支持偏斜挑战、业务属性挑战。

其中：方言支持偏斜挑战，导致同样一个用户问题，用两种不同的方言写出来，差异性就会非常的大。

业务属性挑战：当用户问题相当复杂，尤其是业务逻辑的黑盒，因为业务属性中存在大量的行业黑话，以及如何让模型理解私有行业企业业务术语的内在含义，这大大提升了使用成本。

• 比如案例中的长库龄车，长库龄在这家公司的定义时长范围是多少;

  
  

• 比如关于“近一个月”的定义范围,一种是从上个月的今天到本月的今天；另一种说法是从本月 1 号到现在；还有一种是从上个月的前一天到昨天。由于多方关于定义的混淆，LLM 无法推理出“近一个月”的详细定义。这就是一个二义性的问题。

  
  

03

析言（XiYanSQL）的探索

1. 已有研究和 XiYan-SQL 在挑战上的表现

析言（XiYanSQL）的探索：

在这些挑战上面，阿里云智能集团开展了析言(XiYan-SQL)的项目。目前此项目已经跨越了长周期，针对之前提到的挑战，也对应进行了一些方案上的探索。主要的进展有以下方面：

• 把 Schema 的增强部分进行了技术拓展

  
  

• 生成 SQL 复杂性过程中，主要面向多方言偏斜的支持进行优化

  
  

• 关于用户业务问题复杂性理解方面，通过知识增强使得工具可以开箱即用。

  
  

2. XiYan-SQL Solution

析言项目的主方案流程

（1）橙色流程解决方案

当获得用户 Question 时，此模块用于保证和理解行业企业内部业务逻辑内容的正确性和一致性。

①核心功能

通过知识增强技术将两类业务知识(Evidence Retrieval 和 DateResolver)注入模型，帮助模型理解专业术语并解析复杂问题。

②知识类型与作用

• 术语知识

  
  

  包含指标、业务术语及同义词

  
  

  解决模型对业务专有词汇的认知空白

  
  

  检索结果以「Evidence」形式补充（参考 BIRD 模型知识注入方式）

  
  

• 时间表达标准化

  
  

  处理模糊时间描述（如“近一个月”）

  
  

  建立标准化定义：将用户表述的时间概念强制映射至预设标准解释

  
  

  通过补充知识库配置实现语义校正（例如：用户问“近一个月”时自动调用预定义时间范围）

  
  

③最终模块输出

• 完整保留原始用户问题(questoin)

  
  

• 生成包含业务术语解释和时间标准化的增强型证据（evidence）

  
  

（2）蓝色流程解决方案

该模块针对复杂数据库表及列的两大难点，提出两种自动化处理方案：

①整体架构

SQL 探针描述生成与生成半结构化描述符生成两部分共同构成数据库理解的核心模块，其核心输出 M-Schema 可视为 DDL 的增强替代方案，通过自动化与语义分析显著提升复杂数据库的可解释性与查询效率。

②方法一：SQL 探针描述生成

SQL 探针多 Agent 系统

• 构建多 Agent 系统，通过执行 SQL 查询直接分析数据库实际数据

  
  

• 利用 LLM 模型对查询结果进行语义解析，推测表/列的实际含义

  
  

• 聚合 Multi-Agent 的分析结果生成结构化描述（即 M-Schema 的组成部分）

  
  

效果验证：

• 对比实验：人工 DBA 手写描述（参照组）的端到端精度与自动生成描述（实验组）精度约为参照组的 50%

  
  

• 优势：完全自动化，无需人工标注成本

  
  

③方法二：海量列筛选与相关列提取

两阶段筛选策略

• 粗糙阶段（coarse-to-fine）：以高召回率优先，在海量表/列中进行粗粒度列级别的召回，允许一定精度损失

  
  

• 精排阶段：通过 LLM 多次生成式精排，精准定位用户问题(Question)相关的列

  
  

输出成果：生成半结构化描述符 M-Schema

• 融合自动描述(description)与原始结构化信息(Schema-树状结构）

  
  

• 消融实验验证：相比传统 DDL 格式，M-Schema 在多种模型中均表现更优

  
  

（3）绿色流程解决方案

该模块是 SQL 生成模型的训练及线上推理流程的设计,主要分为 Offline 和 Online 的两大阶段：

首先，Offline 模型训练阶段

• 第一部分,进行基础语法微调：以 Qwen-code 等基础模型为基础，进行不区分具体方言的语法层面微调，使模型具备通用 SQL 生成能力。此阶段开展持续预训练，不针对特定语法变体进行区分训练。

  
  

• 第二部分,强化学习多任务训练：通过分阶段训练多方言、多任务，将基础模型扩展为多个细分模型（如 V1、V2、V3）。其中核心模型（如 V1）开源，其他模型作为辅助，用于补充核心模型在特定方言或能力上的不足。

  
  

然后,Online 线上推理阶段

• 多模型多候选生成：

  
  

  不同于单模型生成多个候选（如 majority-voting 或 self-consistency），采用多模型协同生成：利用离线阶段训练的多个模型（核心+辅助）分别生成 SQL 候选，提升候选多样性。

  
  

  优势在于不同模型经过针对性训练，能覆盖更全面的语法和场景，避免单模型生成候选相似度高、质量受限的问题。

  
  

• 候选验证与执行：对多模型多候选的生成方式生成的 SQL 候选进行验证和实际执行，最终输出结果。

  
  

通过离线阶段构建多样化模型组，在线阶段结合多模型生成提升候选质量，既增强生成多样性，又提高 SQL 的精度上限。

2. Major Techniques

（1）主要技术小结

• M-schema 一种半结构化的 schema 描述

  
  

• Schema Filter 一种 column/value 多路，coarse-to-fine 的召回选择方法

  
  

• Schema Generator 一种探测&观察风格的多代理描述生成方法

  
  

• Ensemble Generator 一种多候选生成和选择的集成学习策略

  
  

• Hybrid Training 一种多任务，多方言混合的模型训练策略

  
  

• MoMQ 一种多方言的 Text-to-SQL MoE 模型及训练方法

  
  

• Evidence Solver 一种通用的 evidence 召回和生成方法

  
  

以上技术要点综合到一起形成了一组新特性，使得析言项目能够保证对于用户问题、数据库逻辑理解的增强，以及进行 SQL 多方言的生成时，可以更好支持多样化，保证具备一定的开箱即用的能力。

（2）

3. XiYan-SQL 评测

（1）公开基准数据

首先基于公开基准数据，2024 年底析言项目在 BIRD 与 Spider 榜单荣获第一。

右图圆柱状的紫色部分是析言的柱状体，其他颜色的柱状体是业内比较有名的其他工作项目，析言在其中具备比较强的领先优势。

下图是各项目具体得分值,析言处于相对一流的行列

（2）多方言支持机制

多方言支持程度的实际效果

基于 SQLite、PostgreSQL、MySQL、NGQL(图数据库，非常小语种)

（3）伪客户问题数据集评测

通过真实收集设计了一个充满企业业务黑话的客户数据集进行实际技术可用性的测试，明显看到准确率提升较大，虽然达到 50% 左右，但未达真正企业级可用的程度。

04

新的方向

1. 新的方向 1：Declarative Interface in MCP

在数据平权的发展过程中,MCP 中的声明式接口是一个新方向

（1）MCP 传统协议与声明式接口对比

上图左侧反映的是 MySQL-MCP-server

MCP 的工作机制如下：客户端连接至 MCP 后，可直接发送 SQL 语句进行执行。当用户需要查询特定信息（如“模型 S 的销量”）时，LLM 模型会先构造包含相应 SQL 语句的参数，MCP 服务器接收到该参数后，直接对数据库执行其中的 SQL 指令，最后将查询结果返回给客户端。整个过程实现方式直接高效，代码量较少，但能够有效完成数据库交互任务。

上图右侧 Xiyan-mcp-server 则是 MySQL-mcp-server+Declarative Interface

声明式接口的定义：让模型专注于处理非结构化自然语言而非结构化/半结构化数据

用户提出将接口从 SQL 转换为自然语言处理方式，以专注于处理非结构化自然语言而非结构化/半结构化数据。具体方案是通过构建精简版的析言 MCP Server 实现：该版本与主链路不同，仅保留核心功能——接收自然语言输入，调用模型处理后直接传递给数据库，完成从语言到数据库操作的全流程。整个方案强调简化流程，核心逻辑为自然语言输入→模型处理→数据库输出的直接对接。在开源数据标准上,这一设计效果提升要近 20%。

（2）方案降低了 Client 的 Token 消耗

该方案通过自然语言交互方式显著降低客户端的 Token 消耗。

• Schema 不可见性优势客户端无需知晓数据库 Schema 结构，摆脱了传统MySQL MCP 模式下必须预知 Schema 才能编写 SQL 语句的限制。

  
  

• token 消耗减少机制由于 DB 层被析言 MCP Server 封装，交互过程仅需极少量 token 即可完成操作，实际消耗量仅为原有方案的约十分之一。

  
  

• 成本效益显著的 token 节约特性在多轮对话场景中成本优势更加明显，直接降低运行费用。

  
  

• 性能权衡响应时间有所延长，主要原因是请求需经过析言模型处理增加了中间处理环节。

  
  

2. 新的方向 2：LLM as database manager

关于“LLM as database manager”，是 LLM 模型在数据库管理中的潜在应用新方向。

因为直接通过 LLM 生成物理 SQL 存在较大难度，团队探索了让 LLM 模型辅助维护数据库的思路，具体如下：

• 核心概念提出“LLM 模型作为数据库管理者（LLM Model as DB Manager）”的概念，目前虽无成熟技术，但已有初步研究成果且将公开。

  
  

• 具体实现通过让 LLM 模型针对数据库创建有效视图（View），简化后续数据访问流程。该方法实现了与现有技术的完全解耦，可独立应用。

  
  

• 效果验证实验显示，该方法带来了显著提升（提升幅度达 7%），具体表现为数据访问效率的优化。

  
  

• 行业反馈与展望同行对此方向表现出高度兴趣，研究团队认为未来 LLM 不仅可辅助数据访问（Access Data），还可能部分承担数据库管理员（DBA）的工作，参与数据管理（Manage Data）任务。

  
  

3. 总结

本文内容可归纳为以下四个核心部分：

（1）数据平权与数据库交互的关系

数据平权的实现关键在于数据库交互的有效性。LLM 的数据平权最后一环是对数据库的交互。

（2）Text-2-SQL 技术的现状与前景

当前 Text-2-SQL 技术的开箱精度仍存在不足，但通过行业共同研究与实践，该技术有望取得显著进步。同行协作是推动其发展的关键因素。

（3）析言 SQL 的探索实践

在技术探索层面，已验证以下方向的有效性：

• 半结构化 Schema 设计

  
  

• 多候选生成策略

  
  

• 多方言协同机制

  
  

上述方法均通过实证验证具有实际效果，相关代码实现已基本完成开源，可供研究者参考或直接应用。

（4）未来技术方向展望

实验表明，声明式接口（MCP）与 LLM 模型参与数据库管理的结合，是具有潜力的新方向。该方向探索了更高效的人机协同数据库操作模式。

05

Q&A

Q1：大概需要多长时间能生成准确的 SQL？

A1：主方案作为最复杂的版本，在启用所有功能时，整体延迟接近20 秒（范围在 10 到 20 秒之间），这一延迟的代价是为了换取更高的精度。而在一般使用场景中，额外增加的延迟主要来自模型部分。根据评测数据，复杂版本的模型部分会带来约 7 秒左右的延迟，而部分情况下这一数值可低至 2 秒左右。最终，不同版本的延迟表现可归纳为：精简版本的延迟控制在 2 到 7 秒左右，而复杂版本的延迟则达到约 20 秒。

Q2：LLM as database manager，是用大模型建模，这个概念如何解读？

A2：聚焦 LLM 模型作为管理者的探索方向。目前业内尚未对“LLM as manager”进行明确定义，而是以开放态度邀请行业共同思考可行方向。现阶段已尝试让模型承担管理角色并取得有效成果，团队认为这仅是初步尝试，相信通过集体协作能挖掘更多有效玩法。此探索强调开放性和协作性，鼓励行业共同参与而非单一团队主导。

Q3：在 Text to SQL 里，解决 SQL 计算结果的准确性和计算效率方面有没有好的解决方案？

A3：这个问题可以拆解成两个方面：

第一个是关于延迟时间与精度的粗细程度；第二个是关于 SQL 语法对了，但是业务逻辑错误。

第一个方案，从客户视角和技术视角分析了模型延迟时间与精度的平衡问题：

1. 客户视角

• 在上个技术周期内，用户对延迟敏感，并要求必须控制在 3 秒内，无法接受 10-20 秒的延迟；

  
  

• 但近期需求逐渐转向接受更长延迟以换取更高精度的过程，用户开始认可"慢思考"带来的准确性提升，DeepSeek 的技术发展对此趋势产生推动作用；

  
  

• 所以市场对延迟容忍度提高，但同时也存在对快速响应的持续需求。

  
  

2. 技术视角

（1）模型迭代带来的变化：

• LLM 推理模型较基础 LLM 会导致延迟增加

  
  

• 短平快的基础模型仍具备极大的开发价值

  
  

（2）模型尺寸与性能的分化：

• 大参数模型（30B/70B 级）：

  
  

  延迟较高但精度优势显著

  
  

  代表技术发展趋势

  
  

• 小参数模型（如 3B 模型）：

  
  

  保持快速响应特性
  

  市场需求旺盛
  

  在基础补全和快速回答场景中仍有效

对于趋势研判，两类模型将长期并存：

• 大模型凭借高精度占据需要深度推理的场景

  
  

• 小模型依托低延迟优势满足基础需求

  
  

当前技术生态不存在单一模型完全取代另一类的可能性，市场呈现双轨并行格局。

第二个方案，解决 SQL 语法正确、业务逻辑业务理解错误的问题：

1. 核心问题现象

代码模型发展现状呈现明显失衡：

语法正确率近年显著提升（横向对比新旧模型差异明显），但逻辑正确率未同步改善，成为主要瓶颈。

2. 问题根源分析

（1）需求理解层缺陷

用户问题理解偏差是根本制约因素：

• 即使语法完全正确，未准确捕捉用户真实需求，结果仍无意义

  
  

• PPT 图示左侧“Question/Evidence Solver”以及“M-Schema”模块并未随基础模型提升而优化

  
  

（2）数据表征层缺陷

表结构(Schema)选择陷阱：

• 数据湖环境中存在大量血缘关联表

  
  

• 表面可用的表 A/表 B 可能因数据口径差异导致结果错误

  
  

• 这类“语法正确但表征错误”的案例普遍存在

  
  

3. 解决方案建议

（1）优先强化需求理解能力：

需重点突破“Question/Evidence Solver”模块

（2）针对性优化数据层处理：

• 对存在大量相似表的场景建立专项解决方案

  
  

• 需建立表血缘关系识别机制以防范数据口径偏差

  
  

Q4：析言是生成的是逻辑计划还是直接生成的 SQL？

A4：直接生成的 SQL 。 

Q5：View 层是用于支持复杂 SQL，还是作为子查询。

A5：视图（View）的作用在于替代原始表。例如，若不使用视图，数据库中直接存储的就是原始表结构。而使用视图时，数据库会通过创建视图来替代原始表——例如原本存在 200 个原始表，但可通过创建 30 个视图来取代这些表，使后续链路流程直接基于这 30 个视图运行，原始表则不再需要保留。整个数据链路在替换后仍可继续正常执行。

Q6：析言代码还有很多部分没有开源，就是想问一下什么时候能开源。

A6：研究部分存在未开源内容，主要原因是相关稿件目前处于审核阶段，而审稿方要求不得提前公开。对于符合开源条件的其他模块，团队已全部开放。后续计划中，团队将优先加快开源进程，争取在年内推进更多内容公开。

Q7：复杂 SQL 是怎么支持的？包含子查询、窗口函数、聚合、多表 join。

A7：

1. 多表连接问题及解决方案

（1）现存问题：

• 当需要 5 张及以上表连接时，系统性能显著下降，实际应用效果差

  
  

• 传统方案主要集中在单表或双表查询，现仅能支持到 3 表连接

  
  

（2）解决方案：

• 在 Schema 设计层面强化表间关系：

  
  

  增加表间关联的描述性说明（如明确表间常用联合关系）

  
  

  补充主外键等元数据信息

  
  

• 通过 Schema 优化，使系统能更自然地识别并组合相关表

  
  

2. 窗口函数问题

现存问题：

• 不同语法体系间存在显著差异

  
  

• 系统支持能力不足

  
  

• 当前解决方案效果有限，落后于行业水平

  
  

3. 聚合查询优化

（1）核心问题：

• 表面表现为聚合函数使用困难

  
  

• 实质是指标与维度的识别问题（将维度字段错误聚合）

  
  

（2）解决方案：

• 在 Schema 中显式声明指标和维度字段：
  标识哪些字段是度量指标
  标识哪些字段是维度属性

  
  

• 通过元数据约束避免维度字段的不当聚合

  
  

Q8：如何看待 Text-to-sql 和微调方案的关系

A8：在 2024 年，针对服务的重点客户，团队通常提供微调后的模型而非原始基础模型。

核心原因在于微调能显著提升模型性能：通过融入客户特有的数据结构（Schema）及业务术语，模型精度可得到增强。例如，一汽公开披露其基于微调模型的端到端测试 SQL 使用精度达 92%，而未经过微调的开源版本效果则低 10%-20%，这直接体现了微调的有效性。

然而，微调模式存在规模化瓶颈——每次模型迭代均需依赖算法团队重新训练，导致资源消耗大且效率低下。因此，技术方向转向算法层面的优化，旨在通过提升模型本身的通用能力，减少对定制化微调的依赖，推动“开箱即用”解决方案的落地。

尽管如此，从实际应用角度出发，仍建议同行采用微调策略以快速提升特定场景下的模型表现。

Q9：析言的 MCP 为什么会减少 token？

A9：

1. Token 消耗关键点
节省 Token 的核心在于避免向 LLM 模型（如 Claude/GPT/通义千问）传递数据库 Schema 信息。传统方案中 Schema 描述会占用大量预填充提示的 token 空间。

2. MCP 方案对比

• 析言/MCP 方案：无需暴露数据库结构（DDL 或 Schema），模型仅需处理用户自然语言问题，避免 Schema 信息的重复传递

  
  

• MySQL 官方 MCP 方案：需先告知数据库结构才能生成 SQL，强制要求在每次交互中包含 Schema 描述，导致：初始提示词（prompt）体积显著增大；多轮对话中重复传输 Schema 产生叠加消耗。

  
  

3. 传统方案成本

传统方案在连续对话中需持续携带 Schema 信息，导致每轮交互的 token 消耗呈线性增长，实际使用成本快速攀升。

4. 析言方案成本

析言方案通过以下方式降低消耗：

• 剥离 Schema 依赖，消除结构信息传输需求

  
  

• 采用小模型架构（如析言模型），在保证功能的前提下减少基础计算量

  
  

• 避免多轮对话中的重复数据传输，实现整体 token 使用量的阶梯式下降

  
  

Q10：关于选表的精度问题

A10：选表精度问题是当前讨论的焦点。

若选表准确率无法达到 100%，可能导致关键列信息丢失，进而影响最终生成结果的正确性。由于表选择错误会导致后续错误累积，因此用户普遍关注召回模块的开源进展。目前析言开源进度受阻的主要原因是该模块依赖多个尚未开源的内部模型。

关于选表精度的解决，召回策略采用“从粗到细”的分阶段方法，核心逻辑为：

• 首先通过列召回同时携带表名和具体值，结合值与表信息进行多维度召回，以此保证较高的记录覆盖率（Recall）。

  
  

• 后续生成阶段采用经过特定训练的模型（可理解为精调后的分支模型），该模型具有较低幻觉风险。

  
  

• 用户也可通过自训练模型或调整提示工程实现类似效果。

  
  

实践效果方面，该方法能将召回率稳定在 97%-98% 区间。值得注意的是，我们关注的不仅是单列召回率，更强调“全列召回率”——即在 100 个案例中，所需全部列均被召回的案例比例。