EMNLP 2025 Main · Schema Linking · Multi-Database Text-to-SQL

LinkAlign：让 LLM 在海量数据库里先找对库，再找对表字段

这篇论文不是又做一个 SQL 生成器，而是专门解决真实企业场景里的前置难题：用户一句自然语言进来，系统面对很多库、几千个字段，怎么把问题精确对齐到正确数据库、表和列。

论文：Wang, Liu, Yang · EMNLP 2025 ACL Anthology ID: 2025.emnlp-main.51 核心任务：schema linking 官方 PDF 已本地保存

核心结论

做了什么

LinkAlign 把真实 Text-to-SQL 前面的 schema linking 拆成三步：语义增强检索、无关 schema 隔离、表字段抽取。它关心的是“问什么、在哪个库、要哪些字段”，而不是只盯着最后 SQL。

为什么重要

企业里往往不是一个干净小数据库，而是多库、多域、字段名重复、字段语义相近。直接把所有 schema 扔给 LLM，模型很容易拿错库、漏字段、选错 join 线索。

最适合借鉴点

对你的 skill + MCP 项目来说，它提供了一个清晰可落地的中间层：先用检索和 LLM 定位业务资源，再把候选 schema 过滤成 SQL 生成器能消化的上下文。

一句话版：LinkAlign 像一个“数据问询导游”。用户说“哪个学期硕士和本科都入学了？”，它不会立刻写 SQL，而是先改写问题、扩大召回、判断目标库、过滤无关库，最后抽出真正需要的表和字段给 SQL 模型。

它解决的问题

论文认为大规模多数据库场景下，schema linking 至少有两个关键挑战：第一是 Database Retrieval，也就是从很多数据库里找出目标数据库；第二是 Schema Item Grounding，也就是在复杂冗余 schema 中找出真正需要的表和列。

错误 1：目标库没有被召回

用户问题里的词和真实库表字段不完全一致，embedding 检索可能搜不到正确库。例如用户说“学位类型”，库里字段可能叫 degree_type，还有表名、列名、别名之间的错位。

错误 2：召回了太多无关库

为了提高 recall，检索会引入很多语义相近但实际无关的库。LLM 看到这些噪声后，可能误以为另一个库更合适，导致后续 SQL 完全跑偏。

错误 3：表选错

即使目标库找对了，表结构复杂、同义表很多时，模型仍可能选错表，特别是那些名字相似但业务口径不同的表。

错误 4：字段漏掉或拿错

SQL 需要 SELECT、WHERE、GROUP BY、JOIN 的字段。漏一个关键字段，SQL 就可能生成不出来，或者能执行但答案错。

方法：三步把问题对齐到 schema

LinkAlign framework — 论文图 1：LinkAlign 的整体框架。可以看到它不是单次检索，而是把检索、过滤、抽取拆成可组合模块，并支持 Pipeline 与 Agent 两种实现。

Align Semantics

先把用户原问题改写成更贴近数据库表达的查询。论文用 Schema Auditor 分析实体、属性、约束，再由 Query Rewriter 补全缺失语义，生成更适合 embedding 检索的问题变体。

Reduce Noise

把召回结果按数据库分组，让 LLM 判断哪个库最能覆盖用户意图。Agent 模式下由 Data Analyst 和 Database Expert 讨论，最后保留目标库，隔离无关库。

Extract Schema

在过滤后的目标库里，进一步抽取需要的表和列。Agent 模式下 Schema Parser 和 Data Scientist 从 SELECT、WHERE、JOIN、GROUP BY 等角度补齐字段。

用一个查询例子理解

假设用户问：“Which semester the master and the bachelor both got enrolled in?” 正确 schema 里可能有 degree_programs.degree_type 和 enrollment_records.semester。LinkAlign 会发现原问题没有显式说出这些 schema 线索，于是生成带有 degree_type、semester、group by 等语义的改写问题，再去检索。

原问题 Q0: Which semester the master and the bachelor both got enrolled in?

改写 Q1: 在 degree_programs 中，如何找出 master's / bachelor's degree_type 都存在的学期？
改写 Q2: 在 enrollment_records 中，如何按 semester 聚合并筛选硕士和本科都有入学记录的学期？

Pipeline 模式

每一步基本用固定 prompt 一次完成。优点是快、便宜、容易工程化，适合在线问询中对延迟敏感的场景。缺点是复杂问题上反思能力较弱。

Agent 模式

每一步用多个角色协作，例如 Auditor/Rewriter、Data Analyst/Database Expert、Schema Parser/Data Scientist。优点是准，缺点是慢、调用成本高。

关键设计取舍：Query Rewriting 会提高召回，但也会带来更多噪声；Response Filtering 就是用来抵消这个副作用的。也就是说，它不是“越召回越好”，而是“先敢召回，再会过滤”。

论文中的形式化表达

多轮语义增强检索可以概括为：对原问题和改写问题分别检索，然后把结果合并排序。

$$Z = \bigcup_{t=0}^T f_{retriever}(S, Q_t, c \mid E)$$

目标数据库定位则是从候选数据库里选出与用户问题和召回结果最匹配的数据库：

$$D_t = \arg\max_{1<i<N} P_M(D_i \mid Q_0, Z)$$

最后抽取 SQL 生成所需的表和字段子集：

$$S'_u = \{T_i, C_i \mid I(Q_0, C_i)=1\}$$

实验结果

33.09%

Spider 2.0-Lite

论文称在提交时达到 Spider 2.0-Lite 新 SOTA，并且只使用开源 LLM 接入 DIN-SQL 管线。

47.7

Spider 多库 EM

Agent 模式在多数据库 schema linking 的 Spider 设置上 EM 达到 47.7，高于基线。

80.7

Spider 多库 Recall

Agent 模式在 Spider 多库 schema recall 达到 80.7，说明关键字段召回能力显著增强。

schema linking results tables 2 and 3 — 表 2/3：上半部分是多数据库场景，下半部分是单数据库场景。重新裁剪后保留了 Spider、Bird、AmbiDB 等完整分组表头。

设置	代表结果	怎么读
Multi-Database Spider	Agent: LA 86.4, EM 47.7, Recall 80.7	在多库里既能定位数据库，也能召回表字段。
Multi-Database Bird	Agent: LA 83.4, EM 22.1, Recall 64.9	Bird 更难，但 Agent 仍比多数基线稳。
AmbiDB	Pipeline: LA 69.4；Agent: EM 22.4	AmbiDB 故意制造多库歧义，用来测试真实混乱场景。

Spider 2.0 Lite results — 表 1：Spider 2.0-Lite 端到端 Text-to-SQL 结果。LinkAlign 接入后提高了后续 SQL 生成管线的表现。

ablation figures — 图 2/3：消融实验展示 Query Rewriting 与 Response Filtering 对错误率和评估指标的影响。

ablation table — 表 7：去掉问题改写或响应过滤都会损害指标。尤其 Agent 去掉 response filtering 后，Spider 的 LA/Recall 明显下降。

runtime table — 表 8：运行效率对比。Pipeline 更快，Agent 更准，适合按查询难度分流。

放到 DataEngine / skill + MCP 里怎么用

如果你的系统是“用户问题 → skill 调 MCP 查数据库”，LinkAlign 最有价值的地方是把中间过程拆清楚。不要让 skill 直接从自然语言跳 SQL，而是先输出一个可检查的 查询意图包。

LinkAlign 模块	在项目里的对应实现	输出物
Semantic Enhanced Retrieval	用业务词典、字段描述、历史问法、embedding 索引改写并检索候选资源	候选库/表/字段列表，带分数和理由
Irrelevant Information Isolation	让 LLM 或规则判断候选资源是否属于同一个业务域，过滤掉相似但无关的库	目标数据源和被排除资源
Schema Extraction Enhancement	按 SELECT、WHERE、GROUP BY、ORDER BY、JOIN 分解字段需求	结构化 schema linking JSON
Pipeline / Agent	简单问题走低延迟 pipeline，复杂问题走多角色审核	可控成本与质量分级

建议你的 skill 先产出这种结构

{
  "user_question": "统计各学院近三年科研经费同比增长率",
  "intent": "aggregate_trend",
  "target_domain": "科研 / 财务",
  "candidate_databases": [
    {"name": "research_dw", "score": 0.82, "reason": "包含项目和经费字段"},
    {"name": "finance_dw", "score": 0.74, "reason": "包含到账金额和年度字段"}
  ],
  "selected_database": "research_dw",
  "required_schema": {
    "tables": ["project_fund_fact", "department_dim"],
    "columns": ["department_name", "fund_amount", "year", "project_id"]
  },
  "sql_slots": {
    "select": ["department_name", "year", "sum(fund_amount)"],
    "group_by": ["department_name", "year"],
    "derived_metrics": ["year_over_year_growth"]
  },
  "excluded_candidates": [
    {"name": "student_fee_fact", "reason": "金额字段相似，但业务域是学生缴费"}
  ]
}

工程上最该学的一点：把“字段召回”和“SQL 生成”解耦。先让 skill 解释自己为什么选这些字段，再调用 MCP 获取 schema 或样例值，最后才生成 SQL。这样出了错也能定位是召回错、过滤错，还是 SQL 生成错。

创新点与评价

创新点 1：面向多库的 schema linking

许多 Text-to-SQL 工作默认目标数据库已知。LinkAlign 把“先定位数据库”作为一等问题处理，更贴近企业数据中台和多系统问询。

创新点 2：召回与过滤成对设计

它承认 query rewriting 会引入噪声，所以专门加入 response filtering。这个设计比单纯提高 recall 更成熟。

创新点 3：Agent 与 Pipeline 双模式

论文没有只押注复杂 Agent，而是提供快慢两种路径。对生产系统来说，这比“全 Agent”更现实。

创新点 4：AmbiDB 评测

作者构造 AmbiDB 来模拟多库歧义，让评测不再只停留在干净、单库、字段数量有限的场景。

需要谨慎的地方：Agent 模式调用成本和延迟明显更高；论文依赖 LLM 判断数据库相关性，真实系统里还需要日志、权限、血缘、字段样例值和业务口径文档共同约束，否则仍可能“解释得很像但选错口径”。

我对这篇论文的判断

这篇适合作为你的 DataEngine 问询链路的“schema linking 参考架构”，尤其适合多库、多业务域、多字段别名的场景。它的价值不在某个 prompt，而在把自然语言到 SQL 之间那段混乱的中间地带拆成了可观察、可评估、可替换的模块。

资料来源

论文页面：ACL Anthology - LinkAlign

官方 PDF：https://aclanthology.org/2025.emnlp-main.51.pdf

论文代码仓库：https://github.com/Satissss/LinkAlign

本页面根据本地下载的官方 PDF 抽取正文、图表并重新组织中文解读生成。公式使用 MathJax 渲染，首次打开需要能访问 MathJax CDN。