不透明主键拖垮通用文本到 SQL：Kensho 的 FLINT 已在金融检索里上线

从基准到生产：一套面向复杂金融数据的文本到 SQL 系统

Arijit Sehanobish、Bruno Gomes Coelho（同等贡献）、Guillaume Michel、Sophia Zhi、Valerie Faucon-Morin、Kristen Howell，单位均为 Kensho Technologies。通信：arijit.sehanobish@kensho.com。

摘要

通用的文本到 SQL 系统（T2S，把自然语言问题写成可执行数据库查询）在 Spider、BIRD 这类学术基准上表现强。这些基准的模式（schema，表和列的结构）比较浅，列值往往是人能读的字符串。在生产金融数据库里，概念存成不透明的整数主键，而不是人能读的字符串。这些方法掉到 50% 以下：即便简单查询也要多次连接（join，按键把多张表拼在一起），过滤条件引用的是不透明 ID。

本文给出 FLINT（Financial LINking Text-to-SQL），一个面向该领域的 T2S 系统。它用三个部件补上这个缺口：（1）查找智能体，把自然语言概念动态解析成该问题专用的参考表约束；（2）用嵌入检索，从一小本专家编写的查询库里取出结构相似的查询模板；（3）模式链接（schema linking，选出要用的表、列和连接），沿外键链（foreign key，用整数指向另一张表某一行的列）裁剪大模式，而不是只靠列名相似。

作者在两套数据、共 359 道题上评测，题目都落在生产金融模式上。在同一个大语言模型下，FLINT 超过多种现有方法。该系统已作为金融数据检索服务的一部分部署到生产。服务地址：https://kensho.com/solutions/adaptive-retrieval 。

1 引言

T2S 已成为非技术用户访问结构化数据的一种接口。靠模式链接、多智能体架构和提示词工程，近期系统在 Spider（Yu 等，2018）和 BIRD（Li 等，2023b）上达到 70%–85% 的准确率。

这些结果迁不到金融行业的真实库模式。问一家公司的季度营收、或某个行业最大的并购，自然语言很好说，写成可上线的 SQL 却难。商业金融库为存储效率而不是为人读而优化，于是财务指标、期间类型和货币被编成整数外键，散落在几十张规范化的参考表里。一个时间序列问题要走过六表连接链；区分「年度营收」和「季度净利润」的过滤值是不透明整数，不能只从列名推断（例子见附录 A.2、A.3）。

这个设定露出学术基准不量的缺口。在 Spider 和 BIRD 里，列值自我说明（例如 country = 'USA'），连接浅（平均 1–2 次），整份模式放得进一次提示。作者在两套生产金融数据上评测七种现有方法，没有一种准确率超过 50%，尽管生成的 SQL 执行成功率超过 99%。查询能跑，却常因参考表过滤值错误而返回错误数据。

FLINT 用第 3 节的三个部件对准这一点：查找智能体、查询库上的嵌入检索，以及沿外键链裁剪模式的模式链接。

这个设计把领域知识从模型权重里拆出来。模式演变、新增指标或发现覆盖缺口时，领域专家直接改配置，不必重训，也不必机器学习工程师介入。架构针对各行业常见的规范化模式。作者聚焦金融，并在附录 G 检验科学与工业领域上的可推广性。

贡献如下：

1. 瓶颈诊断。在规范化的生产式模式上，主要失败不是 SQL 生成，而是值落地（value grounding，把说法对上库里的具体取值）：76%–96% 的错误是参考表过滤 ID 错了。
2. 一种轻量的值落地方法。作者给出与具体模型无关的配置层，对准这个瓶颈。在四个公开基准上，它在三个数据集上超过 CHESS 和 ReFoRCE，生成成本约为五分之一。
3. 语义评测。作者给出三层评测流水线：抽象语法树规范化，再按列对齐比较，再用大语言模型裁判。它把语义等价的改写和真正的错误分开。抽象语法树（AST）是把 SQL 解析成的树。

2 相关工作

面向 T2S 的提示词工程（Gao 等，2024；Pourreza 与 Rafiei，2023；附录 I 有更多讨论）大体已被多智能体分解取代：SQL 生成被拆成多个专门阶段，再产出最终查询。近期系统处理不同失败：候选多样性与选择（Talaei 等，2024；Pourreza 等，2025）、交互式探库（Wang 等，2025；Pham 等，2026），以及用执行反馈做迭代修正（Deng 等，2025）。这些策略减少结构上的 SQL 错误，但都没有专门机制去解析不透明的参考表 ID。在金融的规范化模式上，这个共同缺口是主要错误来源（见第 4.3 节）。

评测方法和基准仍是活跃问题。Spider 用精确集合匹配比较 SQL 部件，会拒绝等价改写。BIRD 只看查询输出，于是格式差异会和语义错误混在一起。SpotIt（Klopfenstein 等，2026）用形式化验证量化这一限制，并猜想至多 20% 的 BIRD 评测数据可能不正确，因为测试库会碰巧让不等价查询给出相同结果。本文基准在内容和评测上都与 Spider、BIRD 不同：模式深度规范化、ID 不透明，简单问题也必须多表连接，自然语言里没有隐含的领域惯例。作者用三层流水线评测（AST 规范化、输出比较、大语言模型裁判），以容纳这类模式上大量合法改写。更多相关工作见附录 I。

3 系统架构

FLINT 把自然语言到 SQL 拆成一条专门阶段的流水线，每段处理一个子问题。给定用户问题 q，系统经六段产出 SQL 查询：查找、相似查询检索、实体链接、模式链接、SQL 生成，以及执行与反思。没有数据依赖的阶段并行：查找与相似查询检索并行，随后实体链接与模式链接并行（图 1）。这种并行使端到端延迟的中位数为 10–20 秒（附录 D.12）。

图 1：FLINT 流水线。横排的阶段并行。虚线箭头是由错误驱动的反思环。原文这一图在 HTML 中没有独立图片文件。阶段顺序是：问题进入查找智能体和相似查询检索；再进入实体链接和模式链接；然后 SQL 生成、执行 SQL；成功则返回结果，失败则反思后再生成。

3.1 查找智能体

金融库把行业、期间类型、财务指标等类别信息编成参考表里的数字 ID。问题里出现「季度 EBITDA」时，必须知道哪个整数对应「季度」、哪个对应「EBITDA」。这不能从模式推断：模式只显示它们是整数外键（图 4）。查找智能体分两步解析：

1. 选表。大语言模型判断哪些参考表与问题相关。「加拿大公司」触发地理表；「营收」触发财务指标表。
2. 生成约束。智能体对找出的生产参考表执行 SELECT，把取回的行交给大语言模型，让它写出合适的 SQL 过滤。在 Financials 上，指标解析是两段漏斗：完整的 11,412 项指标表先收成专家整理的约 2,500 个常用项（其余约 9,000 项很少被问，这份整理本身就是领域知识）；再按问题做模糊匹配，收到约 50–100 个候选，由模型从中选择。Transactions 的参考表小，整表传入。

在评测集上，这一预过滤相对金标准查询保持 98% 召回。输出是一组查找约束：传给后续阶段的 SQL WHERE 片段。

3.2 相似查询检索

FLINT 维护一本专家编写的查询库。每条含问题、推理轨迹和参考 SQL。推理时，用向量库上的余弦相似度取出最相似的 k=3 条。

每条例子由领域专家手写，覆盖不同查询模式（例如单实体查找、多期间比较、跨货币排序）。查询库例子使用固定的规范实体（一家固定的参照公司），使相似度抓住的是检索类型，而不是表面的实体重叠。查询库与评测集严格不相交。取出的例子有两个用途：给模式链接当结构模板（展示正确连接），给生成当 SQL 范例（展示语法和过滤放在哪里）。

3.3 实体链接

实体链接把自然语言提及（公司名、股票代码）对上库里的不透明整数键。没有这一步，模型无法从「Nvidia」走到正确的数字标识：核心数据表没有人能读的名称列，对 2,000 万以上实体做模糊字符串匹配在生产规模上不可靠。FLINT 把解析交给外部实体消歧服务 Kensho Link（https://kensho.com/solutions/core-ai-capabilities#link）。它处理名称变体和标识类型，返回规范整数 ID。解析出的 ID 作为具体的 WHERE 约束注入生成提示。

3.4 模式链接

模式链接决定查询需要哪些表、列、连接条件和过滤谓词。给定问题、参考表约束、查找 ID 和检索到的例子，大语言模型选出模式的相关子集。难点在于答案很少住在单张表里，到达它要先认出只作连接桥的中间表。例如，取一家公司的股价要先解析它的证券，再解析交易品种，才到价格表：Company → Security → TradingItem → PriceEquity。

提示包含：（1）完整数据库模式，含列说明和写明的连接路径；（2）查找智能体给出的查找约束（该用哪些整数 ID 过滤）；（3）编码隐含惯例的领域指令（例如默认时间粒度、几列价格里用哪一列、主上市所需的标志过滤）；（4）带推理轨迹的检索例子。

模型输出结构化表示：选定的列、连接条件和过滤。这把「查什么」和「SQL 怎么写」拆开：模式链接负责选表，生成负责语法。因为模式链接看得到完整模式，这一设计适合目标是固定、经整理的模式。

3.5 SQL 生成

给定模式链接、实体 ID 和 SQL 范例，模型生成最终查询。领域约束由提示执行：只用指定的表和列，把实体 ID 写成具体过滤，为可读性带上上下文列（公司名、货币），并遵循目标 SQL 方言。执行前，安全校验器确保查询只访问允许的模式和表，避免无意暴露数据。

3.6 执行与反思

查询在数据库上执行。成功则直接返回结果。失败则进入反思环：模型收到原问题、失败的 SQL 和数据库错误，再做有针对性的修正后重新生成。这一步对复杂模式尤其有用。执行错误常来自局部失误，例如缺连接、别名错、列名笔误；有了错误信息就可以诊断。为守住生产延迟，作者只允许一次反思；若某个用途把准确率放在响应时间之前，次数可配置。

3.7 数据集配置

FLINT 适应新数据集时不微调、不重训。配置要四样产物：

1. 一份模式 CSV，把表和列映射到说明和连接路径文档。
2. 一份给查找智能体的参考表清单（标出带类别 ID 的表）。
3. 一本 15–30 条例子的查询库，覆盖主要查询模式。
4. 给模式链接和生成用的领域指令提示（编码隐含惯例）。

这些产物是结构化领域知识，由主题专家而不是机器学习工程师编写。以作者的经验，中等复杂度的数据集大约一个人周；复杂的（参考表多、隐含惯例多）连迭代打磨要两到三周。为新模式加一条例子约 30 分钟（附录 B）。流水线是通用的：把 FLINT 接到新的金融数据集，只需要新的配置产物，不必改实现。部署细节，包括缓存、回退和延迟约束，见附录 H。

4 实验

作者先描述自有数据集（第 4.1 节），再描述多阶段评测协议（第 4.2 节），与多种已知多智能体系统比较（第 4.3 节），然后是消融（第 4.4 节）和错误分析（第 4.5 节）。

4.1 数据集

FLINT 在一套大规模、深度规范化的金融库上建了两个数据集，汇总见表 1。

Financials 覆盖全球上市公司的公司信息、市场数据、财务指标和证券。模式有 24 张表（8 张核心数据表、16 张参考表）。财务数值不带人能读的标签；指标名、期间类型、单位类型和货币各自编成整数外键，指向单独的参考表。典型查询要连接 6 张表；复杂筛选查询最多 13 次连接。数据集有领域专家编写的 221 道自然语言题，覆盖公司基本面（44%）、市场数据（14%）、市值（10%）、筛选与排序（8%）、行业分类（7%）和其他混合查询（17%）。

Transactions 覆盖并购、融资轮次、股票回购和公司关系。模式有 18 张表（6 张核心、12 张参考或查找表），记录交易类型、顾问角色、公司关系和交易状态。解析实体关系和交易细节平均要连接 5 张表。数据集有 138 道专家编写的题，覆盖收购（50%）、股票回购（14%）、一般交易筛选（14%）、破产（8%）、分拆与剥离（6%）、投资与融资（4%）和其他交易类型（4%）。

表 1：两套数据的模式与基准统计。参考表存查找值（指标、期间类型、货币）；核心表存财务数据和交易。

359 道评测题来自 6 个月生产查询日志，去重并过滤，以保证查询类别、用表和难度都有覆盖。每题配有数据库领域专家写的金标准 SQL。这可能使基准偏向「已知有 SQL 解法」的问题；作者认为，用来衡量系统对生产用例的覆盖，这是可接受的。金标准查询强制规范化模式上决定对错的约束：显式连接、选择主上市所需的标志过滤、跨国比较的货币归一，以及正确的时间粒度。这些正是通用 T2S 系统不能满足的约束（第 4.3 节）。作者聚焦金融，但所处理的约束也出现在其他领域。附录 G 在两个外部基准上检验可推广性，范围包括科学与工业领域。

少样本检索用的查询库（Financials 27 条，Transactions 18 条，见第 3.2 节）与评测集不相交：没有评测题出现在查询库里、由查询库派生，或与任何查询库例子共享实体。为量化残余相似度，作者在 sqlglot 的 AST 上计算每条评测查询到最近查询库邻居的规范化树编辑距离（TED，把一棵树改成另一棵所需的最少编辑）。重叠度定义为 1−TED。内容感知的重叠很小，Transactions 上没有近重复，因此查询库提供的是结构模式而不是答案（附录 F）。CTE（公共表表达式）是写在主查询前面、可被主查询引用的命名临时结果。

4.2 评测

语法不同的 SQL 可以产生相同结果；结构相似的查询也会因过滤的细小差别返回不同数据。作者使用三层评测：

1. 执行。金标准查询和生成查询都在生产库上执行；执行失败立刻记 0 分。
2. 启发式。用 sqlglot 把两条查询解析成 AST，做规范化变换（别名规范化、日期函数标准化、JOIN 重排），再算树编辑距离。只在别名、列顺序或语义等价改写上不同的查询（例如 CTE 对子查询）判为匹配。AST 未匹配的，用大小写不敏感的列名对齐检查金标准列与生成列，并用与顺序无关的集合相等比较值。这一启发式以可忽略的成本解决近 60% 的情形。
3. 大语言模型裁判。提示模型对照原问题比较结果表，判断语义是否等价。裁判只决定约 40% 的比较（其余由启发式或执行解决）。在一份已验证样本上，它与人工判断的一致率至少 94%，从而把所报告准确率的最坏偏差界在 ±3 个百分点。

准确率是第 2 步或第 3 步被判为等价的题目百分比（细节见附录 C）。

图 2：多阶段评测流水线。成功执行的生成查询先用 AST 与金标准匹配；未匹配的再走启发式，最后到大语言模型裁判。原文这一图在 HTML 中没有独立图片文件。

4.3 与现有方法比较

对照七个 T2S 系统，覆盖多智能体架构（CHESS，Talaei 等，2024；Chase-SQL，Pourreza 等，2025；MAC-SQL，Wang 等，2025；FlexSQL，Pham 等，2026；ReFoRCE，Deng 等，2025）和提示词工程（DAIL-SQL，Gao 等，2024；DIN-SQL，Pourreza 与 Rafiei，2023）（表 2）。全部使用 Claude 4.5 Opus（Anthropic，2025）。

表 2：规范化金融模式上与现有 T2S 方法的比较。全部使用 Claude 4.5 Opus，并共享基础设施工件（附录 D.1）。DAIL-SQL、DIN-SQL 和 FlexSQL 还额外收到共享流水线部件（附录 D.10），因此比较是保守的。所有方法的执行成功率都不低于 99%。

所有方法都能产出合法 SQL（执行成功率不低于 99%），但语义上失败。主要错误是语法正确、过滤值错误。没有基线超过 50%，尽管它们在列值往往有语义（例如 country = 'USA'）的 Spider/BIRD 上高得多。在本文模式上，从自然语言（「年度营收」）映射到不透明整数 ID，需要查询基线都没有提供的参考表。CHESS 在 Financials 上 k=10 比 k=1 高 8.5 个百分点，来自抽样多样性（偶尔撞上正确 ID），但自一致修不好所有候选共有的错误。基线失败里，64%–96% 含有不正确的 ID（附录 D）。这些差距远在抽样噪声之外：FLINT 的 Wilson 95% 区间是 Financials 68.8% [62.4, 74.5]，Transactions 65.2% [56.9, 72.6]。相对最强基线的差距比区间宽。裁判在第 4.2 节把最坏偏差写成 ±3 个百分点，本段原文另写 ±4，两种写法都合不上这个差距。FLINT 也是所评测系统里最快的，中位延迟 10–20 秒，快于全部七个基线（图 5）。

#### 向其他领域推广

为检验领域一般性，作者在两个外部基准上评测 FLINT，范围包括医学、科学和公共部门。只做少量配置改动（模式文档、查询库和领域规则），FLINT 超过 CHESS 和 ReFoRCE，同时快近 5 倍。附录 G 有进一步讨论、SM3（Sivasubramaniam 等，2024）上的结果，以及与少样本提示的比较。

图 3：ScienceBenchmark（CORDIS、OncoMX、SDSS）上的准确率对生成时间，同一套测试具和同一个大语言模型。左上最好：又快又准。FLINT 在每个库上都最准，生成 SQL 比多智能体系统快 5 倍。CHESS 每题生成 k=10 个候选，仍落后于 FLINT 的单次生成；ReFoRCE 的迭代修正收不回那些仍能执行、但语义错误的过滤。生成时间不含数据库执行。原文这一图在 HTML 中没有独立图片文件，图内各点的精确坐标未在正文中列出。

4.4 消融实验

每次关掉一个部件、其余保持完整，以分开各部件的贡献（表 3）。去掉查找智能体时，提示里放入最常见的 100 个 Financials ID 和 50 个 Transactions ID 的静态映射，覆盖约 78% 的查询。去掉模式链接时传入完整模式；去掉检索时不提供范例查询；去掉反思时第一次 SQL 直接提交、不重试（细节见附录 E）。

表 3：消融（严格准确率，%）。每行关掉一个部件，流水线其余部分保持完整。行按平均降幅排序。

查找智能体最关键：去掉后 Financials 降 14 个百分点，Transactions 降 32 个百分点。静态映射覆盖了大部分查询，仍代替不了按问题消歧、选出正确标识所需的步骤。检索是第二大贡献（降 11 与 25 个百分点），尽管只用 27 条例子，说明多样性比规模更重要。模式链接对 Transactions 尤其重要（降 15 个百分点，Financials 只降 4），因为它消除语义相近列之间的歧义。反思只在出现执行错误时有帮助：Financials 上收益小，Transactions 上收回 22 次失败中的 15 次。

4.5 错误分析

FLINT 的 117 个错误预测分成三类（表 4）。列选择是主要失败，占 71 个错误。部分匹配里，有些返回了正确值，只是多了或少了非必要列（只影响呈现）；真正的错误来自指标歧义（例如把「股价」对上调整收盘、最后收盘或 OHLC），或选了标识列而不是对应的值列。有 30 个失败发生在表和列都已选对之后，原因是查找约束错了。在 Financials 上，这 15 例全都是查找解析错误，模式落地本身是对的。选表错误不常见（占查询的 4.5%）。实体链接在 Financials 上贡献 5 个失败，在 Transactions 上贡献 11 个。

表 4 按严格精确匹配计数：结果表与金标准表不同就记错。另一份人工审计发现，不低于 50% 部分匹配的失败里，很多返回了正确值，只是加了或漏了非必要列。按这一解释，有效准确率升到约 85%（Financials）和约 76%（Transactions）；这些情形被当作正确，尽管严格分类把它们记成实质性错误（附录 D.11）。其余集中在值落地、指标或列的消歧，以及查找约束的解析。所有失败模式在部署中仍可检查：分析师看得到生成的 SQL、解析出的 ID 和中间步骤。

表 4：FLINT 117 个错误预测的错误分类。所有失败都产出可执行的 SQL。

5 结论

FLINT 是为生产金融库设计的 T2S 系统：模式深，值是不透明整数键，问题还带有自然语言里没有写出的隐含领域约束。它把模式链接、例子检索、实体解析、领域提示规则和基于执行的反思收成单次流水线，每条查询 10–20 秒。在两个自有金融基准上，FLINT 超过七个学术基线。在另外四个科学与医学领域上，同一架构只做很少改动就能推广。结果说明，学术 T2S 基准和生产部署之间的缺口，主要不是 SQL 生成能力，而是周围的领域知识：该连哪些表、值是什么意思、用户问题的意图是什么。FLINT 的架构是补上这个缺口的一种可复用模式。

限制

领域规则由熟悉各模式惯例的主题专家手工编写。这有效，但带来按领域的配置成本，不能自动扩到新库。检索部件也需要整理过的查询库。新模式若没有历史查询，这一部件不可用，准确率会下降。评测流水线有一个部件用大语言模型判断语义等价；作者在留出子集上对照人工标注做了验证，但一致并不完美，可能给所报告的准确率带来噪声。最后，FLINT 是单轮的：每个自然语言问题生成一条 SQL，不支持引用先前上下文的后续过滤或修正。

参考文献

按原文保留作者、题名和出处，不另增文献。

• Anthropic，2025，Claude Opus 4.5，博客。第 4.3 节引用。
• Deng 等，2025，ReFoRCE，arXiv:2502.00675。
• Dong 等，2023，C3: zero-shot text-to-sql with chatgpt，arXiv:2307.07306。
• Gao 等，2024，Text-to-SQL empowered by large language models，PVLDB 17(5):1132–1145。
• Klopfenstein 等，2026，SpotIt，ICLR。
• Li 等，2023a，RESDSQL，AAAI。
• Li 等，2023b，BIRD，NeurIPS Datasets and Benchmarks。
• Pham 等，2026，FlexSQL，arXiv:2605.02815。
• Pourreza 等，2025，Chase-SQL，ICLR。
• Pourreza 与 Rafiei，2023，DIN-SQL，NeurIPS。
• Sivasubramaniam 等，2024，SM3-text-to-query，NeurIPS Datasets and Benchmarks。
• Talaei 等，2024，CHESS，arXiv:2405.16755。
• Wang 等，2025，MAC-SQL，COLING，540–557。
• Yu 等，2018，Spider，EMNLP，3911–3921。
• Zhang 等，2023，ScienceBenchmark，PVLDB 17(4):685–698。

附录 A 数据集例子

作者给出不同难度的代表例子，说明基准的结构复杂度。表名为可读而缩短（例如用 Company 代替内部全名）。

A.1 难度级别

按金标准 SQL 的结构复杂度分层（连接数和是否有 CTE）。连接数不是难度的完美代理：一条需要隐含领域知识的 3 连接查询，可以难于例行的 7 连接遍历。但它与错误累积的机会数相关，而且可客观测量。三级如下：

• 简单（1–3 次连接，无 CTE）：实体查找、单表检索、基本过滤。
• 中等（4–6 次连接，无 CTE）：标准财务检索，要走完期间表和指标表的整条连接链。
• 复杂（7 次及以上连接，或有 CTE）：多实体比较、跨货币排序、时间聚合。

分布见表 5。

表 5：按金标准 SQL 结构复杂度的题目难度分布。

A.2 Financials 数据集

#### 简单（1–3 次连接）

「Town Pump 总部在哪里？」地理查找，两次连接，从外键 ID 解析州名和国名。2 次连接。companyId 由实体链接从「Town Pump」解析。

SELECT Company.companyName, State.state, Country.country
FROM Company
JOIN State ON Company.stateId = State.stateId
JOIN Country ON Company.countryId = Country.countryId
WHERE Company.companyId = 4222311

#### 中等（4–6 次连接）

「Nvidia 2020 到 2025 年的营收。」标准财务检索，要走完期间类型、指标、单位和货币的六表连接链。6 次连接。dataItemId（28 = 总营收）和 periodTypeId（1 = 年度）必须从查找表解析。这条连接链是大多数 Financials 查询的骨干。

SELECT Company.companyName, FinancialData.dataItemValue AS revenue,
       DataItem.dataItemName, UnitType.unitTypeName AS unit,
       FinPeriod.fiscalYear, Currency.currencyName
FROM FinancialData
JOIN DataItem ON DataItem.dataItemId = FinancialData.dataItemId
JOIN FinPeriod ON FinPeriod.financialPeriodId = FinancialData.financialPeriodId
JOIN Company ON Company.companyId = FinPeriod.companyId
JOIN PeriodType ON FinPeriod.periodTypeId = PeriodType.periodTypeId
JOIN UnitType ON FinancialData.unitTypeId = UnitType.unitTypeId
JOIN Currency ON FinPeriod.currencyId = Currency.currencyId
WHERE Company.companyId = 32307
  AND FinancialData.dataItemId = 28
  AND FinPeriod.fiscalYear BETWEEN 2020 AND 2025
  AND PeriodType.periodTypeId = 1
ORDER BY FinPeriod.fiscalYear DESC

#### 复杂（7 次及以上连接或 CTE）

「阿里巴巴 2024 年年度营收。」意图与上一例相同，但是非美国公司，财报以人民币报告，需要货币换算 CTE 归一到美元。10 次连接（CTE 里 3 次，主查询 7 次）。CTE 用美元计价的汇率做三角换算，计算主要货币对之间的交叉汇率。任何跨货币比较实体的查询都会重复这一模式。

WITH CurrencyConversion AS (
  SELECT ExchangeRate.priceDate, ExchangeRate.currencyId,
         Currency.isoCode AS isoCodeSource,
         ER2.currencyId AS currencyIdTarget,
         C2.isoCode AS isoCodeTarget,
         ER2.priceClose / ExchangeRate.priceClose AS exchangeRate
  FROM ExchangeRate
  JOIN Currency ON ExchangeRate.currencyId = Currency.currencyId
  JOIN ExchangeRate ER2 ON ExchangeRate.priceDate = ER2.priceDate
  JOIN Currency C2 ON ER2.currencyId = C2.currencyId
  WHERE ExchangeRate.latestSnapFlag = 1
    AND ER2.latestSnapFlag = 1
    AND Currency.majorCurrencyFlag = 1
    AND C2.majorCurrencyFlag = 1
)
SELECT Company.companyName, FinancialData.dataItemValue,
       DataItem.dataItemName, UnitType.unitTypeName AS unit,
       FinPeriod.fiscalYear, Currency.currencyName,
       FinancialData.dataItemValue * CurrencyConversion.exchangeRate AS revenueUSD
FROM FinancialData
JOIN DataItem ON DataItem.dataItemId = FinancialData.dataItemId
JOIN FinPeriod ON FinPeriod.financialPeriodId = FinancialData.financialPeriodId
JOIN Company ON Company.companyId = FinPeriod.companyId
JOIN PeriodType ON FinPeriod.periodTypeId = PeriodType.periodTypeId
JOIN UnitType ON FinancialData.unitTypeId = UnitType.unitTypeId
JOIN Currency ON FinPeriod.currencyId = Currency.currencyId
JOIN CurrencyConversion
  ON CurrencyConversion.priceDate = FinPeriod.periodEndDate
 AND CurrencyConversion.currencyId = FinPeriod.currencyId
WHERE Company.companyId = 42083601
  AND FinancialData.dataItemId = 28
  AND FinPeriod.fiscalYear = 2024
  AND PeriodType.periodTypeId = 1
  AND CurrencyConversion.isoCodeTarget = 'USD'

A.3 Transactions 数据集

#### 简单（1–3 次连接）

「2020 年有多少 IPO 被取消？」按交易类型和状态过滤的聚合，二者都经参考表 ID 解析。2 次连接。transactionIdTypeId（6 = IPO）和 statusId（3 = 已取消）从参考表解析。

SELECT COUNT(tr.transactionId) AS cancelledIPOs
FROM Transaction tr
JOIN TransactionType tt ON tr.transactionIdTypeId = tt.transactionIdTypeId
JOIN TransactionStatus ts ON tr.statusId = ts.statusId
WHERE tr.transactionIdTypeId = 6
  AND tr.statusId = 3
  AND tr.announcedYear = 2020

#### 中等（4–6 次连接）

「亚马逊何时收购了 Whole Foods？」具体收购查找，要走过买方–标的关系链上的三张中间表。6 次连接。Transaction → TransactionCompanyRel → CompanyRel → Company 这四表链是解析买卖方关系的标准路径，大多数并购查询都会重复。

SELECT target.companyName AS "Target", buyer.companyName AS "Buyer",
       tr.announcedDay, tr.announcedMonth, tr.announcedYear
FROM Transaction tr
JOIN TransactionType trtype ON tr.transactionIdTypeId = trtype.transactionIdTypeId
JOIN Company target ON tr.companyId = target.companyId
JOIN TransactionCompanyRel cr ON cr.transactionId = tr.transactionId
JOIN TransactionRelType crt
  ON crt.transactionToCompRelTypeId = cr.transactionToCompRelTypeId
JOIN CompanyRel crel ON crel.companyRelId = cr.companyRelId
JOIN Company buyer ON buyer.companyId = crel.companyId
WHERE target.companyId = 36602
  AND buyer.companyId = 18749
  AND trtype.transactionIdTypeId = 2
  AND crt.transactionToCompRelTypeId = 1

#### 复杂（7 次及以上连接或 CTE）

「2022 年金融业最大的 10 笔并购。」排序查询，结合行业过滤、货币归一和交易规模排序。7 次连接（CTE 里 3 次，主查询 4 次）。货币换算 CTE 与行业过滤合在一起。IN (46, 48, 49, 50, 51) 反映映射到「金融业」的多个子行业 ID，这是另一项参考表解析难题。

WITH CurrencyConversion AS (
  SELECT ExchangeRate.priceDate, ExchangeRate.currencyId,
         Currency.isoCode AS isoCodeSource,
         ER2.currencyId AS currencyIdTarget,
         C2.isoCode AS isoCodeTarget,
         ER2.priceClose / ExchangeRate.priceClose AS exchangeRate
  FROM ExchangeRate
  JOIN Currency ON ExchangeRate.currencyId = Currency.currencyId
  JOIN ExchangeRate ER2 ON ExchangeRate.priceDate = ER2.priceDate
  JOIN Currency C2 ON ER2.currencyId = C2.currencyId
  WHERE ExchangeRate.latestSnapFlag = 1
    AND ER2.latestSnapFlag = 1
    AND C2.majorCurrencyFlag = 1
)
SELECT tr.transactionId, Company.companyName, tr.announcedYear,
       TransactionType.transactionIdTypeName,
       Industry.simpleIndustryDescription,
       tr.transactionSize * exrate.exchangeRate AS transactionSizeUSD
FROM Transaction tr
JOIN TransactionType ON tr.transactionIdTypeId = TransactionType.transactionIdTypeId
JOIN Company ON tr.companyId = Company.companyId
JOIN Industry ON Company.simpleIndustryId = Industry.simpleIndustryId
JOIN CurrencyConversion exrate
  ON tr.currencyId = exrate.currencyId
 AND DATE_FROM_PARTS(tr.announcedYear, tr.announcedMonth, tr.announcedDay) = exrate.priceDate
WHERE Industry.simpleIndustryId IN (46, 48, 49, 50, 51)
  AND TransactionType.transactionIdTypeId = 2
  AND tr.announcedYear = 2022
  AND tr.transactionSize > 0
  AND exrate.isoCodeTarget = 'USD'
ORDER BY transactionSizeUSD DESC
LIMIT 10

A.4 关键观察

这些例子说明三件让通用 T2S 系统困难的性质：

1. 深度规范化。即便简单问题也要从查找表解析不透明整数 ID（例如营收的 dataItemId = 28，年度的 periodTypeId = 1）。没有专门的查找机制，模型写不出正确的过滤谓词（图 4）。
2. 长连接链。标准财务检索以 6 次连接为基线。这就是「中等」难度，也就是访问任何时间序列财务指标的最短连接路径。
3. 货币归一。任何跨国比较都需要一个对汇率做三角换算的 CTE，再加 3 次连接和不少 SQL 复杂度。这一模式不能只靠检查模式发现，需要知道汇率表如何编码美元计价汇率的领域知识。

模式声明（模型看得到的）：

ciqFinancialData.dataItemId INTEGER REFERENCES ciqDataItem(dataItemId)
ciqFinancialData.periodTypeId INTEGER REFERENCES ciqPeriodType(periodTypeId)

问题：「季度 EBITDA 是多少？」查找智能体查询参考表后，解析为 periodTypeId=2 AND dataItemId=42。

参考表：

图 4：Financials 里的不透明标识。模式只露出整数外键。因此把「季度 EBITDA」解成具体过滤值，必须查询参考表。查找智能体自动做这一步。原文这一图在 HTML 中没有独立图片文件，上表是图中的参考表。

A.5 基准规模

本基准（359 题）小于 Spider（开发集 1,034）或 BIRD（开发集 1,534）。作者认为这足够，有两个理由。第一，两套数据共享单一固定模式，去掉了多模式基准里抬高样本量需求的跨库方差。第二，在 77% 准确率、n=221 时，95% Clopper-Pearson 置信区间是 ±5.5 个百分点，窄到能在 p<0.001 上把 FLINT 和所有基线分开。基准不是用来估计彼此只差几个点的系统之间的细粒度差别，而是用来测量领域专门化的基础设施是否补上了通用方法补不上的缺口。

A.6 与现有 T2S 基准的比较

表 6 把本文基准与 Spider、BIRD 对照。

表 6：与 Spider、BIRD 的比较。关键差别：带不透明 ID 的深度规范化、简单问题也必须多表连接，以及已部署到生产的模式。

三点把本文基准区分出来：

#### 不透明模式

Spider 和 BIRD 在人能读的值上过滤（country = 'USA'）。本文模式把概念编成整数外键（「总营收」的 dataItemId = 28），需要现有基准都不要求的查找步骤。

#### 以结构深度为基线

在 Spider 上，78% 的查询用 0 到 1 次连接。在本文基准上，大多数查询用 4–6 次连接。标准路径是 Company → FinPeriod → FinancialData → DataItem → PeriodType → UnitType → Currency。BIRD 把模式规模提高得有限，但没有提高连接深度：约 84% 的查询至多 1 次连接。

#### 隐含的领域惯例

问题带有自然语言里没有的约束。例如「股价」意味着 priceClose；「营收」意味着年度（periodTypeId = 1）；「市值」要求 primaryFlag = 1；跨国比较要求货币归一。Spider 和 BIRD 的问题是自足的，本文的问题要靠领域知识消歧。

附录 B 配置成本

配置工作的大头是编写查询库：相关问题、金标准 SQL 和推理轨迹。每条都比常规评测题更久（评测题平均约 30 分钟，含 2–3 轮复核），因为要写思维链走查。Transactions 大约 12 人时，Financials 大约 18 人时。模式 CSV 通常直接：生产库往往已有元数据或面向客户的文档。指令提示和例子轨迹对复杂模式再加约 4–8 人时。

合计，中等复杂度的数据集大约一个人周；复杂的（24 张表、16 张参考表、多条隐含惯例）连生产流量露出缺口后的迭代打磨，要两到三周。配置完成后，为新模式加一条例子约 30 分钟。

敏感度在产物和数据集上都不对称。领域规则是前提。单靠规则就能超过多种多智能体系统。收益对查询库规模不是线性的：过了一小套多样的例子之后，收紧一条规则往往比再加例子更有帮助。

附录 C 评测流水线细节

判断 T2S 对错从根本上难于字符串匹配：语法不同的查询可以产生相同结果，结构相似的查询也会因一个错误过滤值返回不同数据。标准基准用执行准确率绕开这一点（两条都跑，比较输出），但对生产规模的模式这不够：结果集相等对行顺序、空值处理和浮点精度敏感。

C.1 与标准基准的比较

Spider 使用精确集合匹配（ESM）：金标准 SQL 和预测 SQL 被分解成 SELECT、WHERE、GROUP BY、ORDER BY 等部件再做结构比较。ESM 脆，会拒绝结构不同但语义等价的查询（例如子查询改写成 JOIN，或 EXISTS 换成 IN）。BIRD 改用执行准确率（EX）：两条查询都在库上跑，比较结果集。但 EX 把输出的任何差异都当失败，即使差异来自列顺序、别名或等价的空值处理。

本文评测针对这两点。它不单靠结构匹配（不同于 ESM），因为本文查询有很多合法改写（CTE 对子查询、不同连接顺序、别名选择）。它也不止于朴素的执行比较（不同于 EX），而是加入列对齐、与顺序无关的比较、AST 规范化和用于语义等价的大语言模型裁判。

C.2 三层流水线

对规范化金融模式，单一评测方法不够。考虑取苹果年度营收的查询：金标准 SQL 经 ciqCompany、ciqSecurity、ciqTradingItem、ciqFinPeriod、ciqFinancialData 和 ciqDataItem 连接，并带特定过滤。正确预测可能用不同别名、重排连接、把一部分逻辑包进 CTE，或按不同顺序选列，同时产生相同结果。

下面两条返回相同的行，但 CTE 节点和重排后的自连接别名造成无法消去的树差异。没有单一比较方法能处理所有这类情形，因此需要级联流水线，每一层接住上一层漏掉的。

-- Gold: two aliases of ciqCompany via inline joins
SELECT target.companyName, acquirer.companyName
FROM ciqTransactionV2 tr
JOIN ciqCompany target ON tr.companyId = target.companyId
JOIN ciqTransactionToCompanyRelV2 cr ON ...
JOIN ciqCompany acquirer ON crel.companyId = acquirer.companyId
WHERE target.companyId = 24937

-- Generated: equivalent result, CTE + different join topology
WITH TargetCo AS (
  SELECT companyId FROM ciqCompany WHERE companyId = 24937
)
SELECT c.companyName, acq.companyName
FROM ciqTransactionV2 tr
JOIN TargetCo tc ON tr.companyId = tc.companyId
JOIN ciqCompany c ON tr.companyId = c.companyId
JOIN ciqCompany acq ON crel.companyId = acq.companyId
...

第一层用 sqlglot 把金标准和生成查询都解析成 AST，并做规范化：别名规范化（把所有别名换成由底层表派生的规范名）、日期函数标准化、JOIN 重排（内连接按表名排序）、谓词规范化（交换谓词和 IN 子句取值排序的规范化）。规范化之后，树编辑距离判断剩余差异是否在语义上有意义。对自连接，测试所有别名排列；本文模式典型是 2–3 个自连接别名，这是可处理的。在这些变换下结构等价的查询，不执行就判匹配。

AST 匹配失败时，第二层在生产库上执行两条查询并比较输出。执行失败立刻记 0 分。成功的查询里，金标准列与生成列按 SQL 的 SELECT 子句或大小写不敏感的名称匹配；含糊时退回到数据类型和值分布相似度。值用与顺序无关的集合相等比较，数值比较对浮点差异使用 10 的 −6 次方的相对容差。

输出表仍然不同时，第三层调用大语言模型裁判。它收到原问题、金标准结果和生成结果，在上下文里判断语义等价，处理列名不同但值匹配、以及结果格式不同的情形。作者人工验证了 50 个随机抽取的裁判决定，与人工标注者一致率为 94%（50 个里 47 个正确，2 个假阳性，1 个假阴性）。

附录 D 基线改编细节

所有基线方法原先在 Spider 或 BIRD 上评测，那些模式扁平，每条查询 1–3 次连接。改编到重度规范化的金融库（平均 6 次以上连接、16 张以上参考表）既要基础设施决定，也要架构选择。本附录记录所做改编及其理由。

D.1 共享基础设施

所有基线收到同一套不构成方法优势的基础设施：

• 数据库连接：只读的 Snowflake 访问，在生产模式上执行 SQL。
• 实体链接：经外部服务（Kensho Link）做公司名消歧，把自然语言实体（例如「Nvidia」→ companyId=32307）解成标识。提供给把实体解析当作单独预处理的流水线方法。直接探库的方法（MAC-SQL）通过交互查询达到等价解析。
• CTE 注入：金标准 SQL 引用已物化的 CTE，用于货币换算和时间归一。评测时这些 CTE 注入金标准和预测查询；它们是基础设施，不是模型输出。
• 后处理：所有基线使用与 FLINT 相同的安全校验器和时间后处理器（第 3.5 节）。
• 评测：三层评测（启发式表比较、SQL AST 匹配、大语言模型裁判）统一用于所有方法。

D.2 直接提示（零样本和少样本）

为给出没有任何 T2S 专门架构时模型能做到的下限，作者评测两种直接提示：

• 零样本：完整模式（所有表和列及说明）和外部链接服务给出的实体 ID 作为提示上下文。模型单次生成 SQL，没有例子、没有查找、没有模式链接、没有反思。
• 少样本（k=3）：与零样本相同，另加从查询库检索的 k=3 个相似例子（只有问题和 SQL，没有中间推理轨迹）。

两种配置都用与 FLINT 相同的实体链接服务，保证公司名解到正确整数 ID。少样本与 FLINT 之间的差距，隔离的是领域专门化流水线（查找智能体、模式链接、领域提示、反思）的贡献。

D.3 CHESS

CHESS 是多智能体 T2S 系统，靠模式链接、带自一致的候选生成和基于单元测试的选择，在 BIRD 上达到当时的高准确率。

作者使用原始 CHESS 代码，只做最少修改：把 SQLite 执行换成 Snowflake 连接；按 CHESS 从 BIRD 的 database_description 文件所期望的格式提供列级模式文档；不提供实体链接，CHESS 用自己的模式–值匹配和列值检索做实体解析；在单候选（k=1）和完整自一致（k=10 个候选，用单元测试选择）两种配置下评测。核心部件都保留，唯一改动是执行后端（SQLite 换成 Snowflake）。

D.4 DAIL-SQL

DAIL-SQL 用词元级相似度选择问题–SQL 例子，并用把模式表示与上下文例子分开的结构化提示。

它是没有自己流水线基础设施的提示词工程方法。作者在本文流水线里实现它，提供：用基于嵌入的检索做模式链接以找出相关表；用于参考表约束解析的查找智能体（共享基础设施）；用于公司名消歧的实体链接（共享基础设施）；从查询库做相似查询检索（即 DAIL-SQL 的「例子选择」）；DAIL 风格提示，即通用的模式链接指令和 SQL 生成提示，没有领域规则（没有货币换算提示、没有期间类型默认、没有指标消歧指导）；没有反思（零次重试）；没有结构校验。比较因此是保守的。

D.5 DIN-SQL

DIN-SQL 把 T2S 分解成子任务：模式链接、查询分类（易 / 中 / 难），以及按难度生成 SQL 并自我修正。

与 DAIL-SQL 一样，它是提示词工程方法。作者在本文流水线里实现：共享基础设施与 DAIL-SQL 相同（实体链接、查找智能体、相似查询检索）；DIN-SQL 风格提示，即分步模式链接指令和按分类生成的提示；带 1 次反思的自我修正（对应论文的自我修正步骤）；没有结构校验。作者保留其关键贡献：通过提示结构和单次反思，分解成按分类的子任务并自我修正。共享基础设施给它与 DAIL-SQL 相同的优势，因此比较是保守的。

D.6 MAC-SQL

MAC-SQL 提出 Selector → Decomposer → Refiner 架构。Decomposer 通过多轮工具调用循环交互访问数据库。

作者把 MAC-SQL 实现为独立流水线，不依赖 FLINT 的基础设施：

• Selector：一次大语言模型调用，收到完整模式（所有表和列及说明），返回与问题相关的裁剪子集。没有基于嵌入的检索，只有纯模型选模式。
• Decomposer：多轮智能体循环，两个工具：execute_sql（在 Snowflake 上跑中间查询，返回截断结果）和 submit_final_sql（以最终答案结束）。中间查询预算为 5 次。模型探索参考表、核对列值，并在提交前测试子查询。
• Refiner：若最终 SQL 执行失败，一次大语言模型调用根据错误信息尝试修复。最多 2 次重试。
• 没有实体链接、没有查找智能体、没有相似查询检索、没有模式链接嵌入。

Decomposer 的工具调用循环在功能上等价于实体链接。模型不经外部服务解析实体，而是直接查库（例如 SELECT companyId FROM ciqCompany WHERE companyName ILIKE '%Nvidia%'）。因此 MAC-SQL 不需要 Kensho Link，通过交互探索完成实体解析。

D.7 Chase-SQL

Chase-SQL 用多样的推理策略生成多条候选 SQL，再经成对比较选出最好的一条。

作者把它实现为独立流水线。三个生成器并行：

1. 分而治之的思维链：把问题分解成子问题，分别求解，再用 CTE 合并。
2. 查询计划思维链：按执行计划步骤推理（扫描 → 过滤 → 连接 → 聚合 → 投影）。
3. 在线合成：当场生成 3 个相似的问题–SQL 例子，再当作少样本上下文。

失败候选最多用错误信息重试 2 次。所有可执行候选进入锦标赛成对比较。每一对由大语言模型裁判评估，裁判看到两条查询、它们的结果（前几行）和原问题。胜场最多的候选被选中。所有生成器收到全文形式的完整模式。没有模式链接、没有实体链接、没有查找智能体。作者保留论文的三种生成策略和成对选择。与 MAC-SQL 不同，Chase-SQL 没有交互探库或实体解析，而是单次生成 SQL，因此更容易在参考表解析上失败。

D.8 FlexSQL

FlexSQL 提出五段流水线：模式探索、计划生成、计划澄清、SQL 生成，以及带重试的自我评估。作者实现全部五段，并带实体链接和 Snowflake 执行。在 3 样本配置里，检索到的例子（含模式链接和 ID 解析）在计划生成时注入，以告知选表和连接路径。自我评估会重新执行，失败时重试一次。

D.9 ReFoRCE

ReFoRCE 使用迭代自我修正：探索阶段对数据库生成诊断查询，然后模型用执行反馈迭代修正 SQL（最多 N=5 次迭代，成功则提前停止）。作者用 Snowflake 执行实现完整的探索和修正环。在 3 样本配置里，带 ID 解析的检索例子注入初始生成提示。

D.10 改编汇总

表 7 汇总每个方法收到哪些基础设施部件。星号：CHESS 用自己的模式–值匹配。剑号：MAC-SQL 通过交互式数据库查询达到等价解析。

表 7：各方法的基础设施与架构部件。

给 DAIL-SQL、DIN-SQL 和 FlexSQL 的实体链接与查找智能体使比较偏保守。没有这些，它们无法解析公司名或参考表 ID，准确率会接近零。作者给它们尽可能强的实现，以表明差距来自生成策略和领域提示，而不是缺预处理。MAC-SQL、Chase-SQL 和 ReFoRCE 不收这套共享件，因为架构自足。前两者靠探库做实体解析；Chase-SQL 没有任何解析机制，是架构本身的限制。

作者承认评测里的几处张力：

1. DAIL-SQL 和 DIN-SQL 放在本文流水线里：提供实体链接和查找之后，比较的实际上是「通用提示的 FLINT」对「领域提示的 FLINT」。这些方法的字面移植（独立、无基础设施）准确率接近零，没有有用信号。作者认为当前比较更好地隔离了提示工程的贡献。
2. Chase-SQL 没有值检索：原版用 LSH（用哈希把相似项放进同一桶的近似近邻）把相关列值注入提示。本文实现省略了它，可能使实体解析重的查询吃亏。把 LSH 改编到值是 ID 而非可读字符串的参考表，需要超出原设计的再工程。
3. MAC-SQL 的 Selector：原版用基于嵌入的模式选择，本文实现是对完整模式文本的一次大语言模型调用。在本文规模的模式上（18–24 张表），基于模型的 Selector 可能与嵌入检索表现不同，但二者目标都是裁剪模式。

D.11 失败分析

强基线在 Spider 上达到 80%–90%，在 BIRD 上达到 60%–75%。那里列值人能读，查询只要 1–2 次连接。在本文模式上，共同失败是无法解析不透明的参考表 ID。

为直接量化，作者定义过滤谓词准确率：对每条需要数字 ID 过滤的查询（占查询的 95%），检查所有金标准过滤值是否出现在生成的 SQL 里。表 8 报告这一指标，以及失败中可归因于错误 ID 的比例。

表 8：过滤谓词分析。ID 准确率：所有必需数字 ID 都正确解析的查询比例。失败归于 ID：错误预测中，至少 1 个必需 ID 错误的比例。在 Financials 上，全部失败的 64%–96% 可归因于不正确的过滤值。

FLINT 解析了 94% / 75% 的必需 ID（Financials / Transactions）。去掉查找智能体后，ID 准确率掉到 10% / 7%，与 Chase-SQL 相同，93%–94% 的失败变成 ID 错误。基线里，Chase-SQL 只在 6%–7% 的查询上解析出全部必需 ID。DAIL-SQL 和 DIN-SQL 同时收到实体链接和查找智能体，却只在 21%–29% 的查询上解析出 ID。这说明给出正确的 ID 候选不够，还需要领域提示，才能在含糊选项里选出正确值（例如区分总营收和净营收，或选对期间类型）。FLINT 与 DAIL/DIN 的差距不是基础设施使用权，而是指导 ID 消歧的提示层领域知识。

• CHESS：自一致修不好各样本一致的 ID 错误。所有 k 个候选共享相同的错误过滤谓词。它的模式–值匹配提供部分解析（46% ID 准确率），这解释了它相对较强。
• Chase-SQL：当瓶颈是过滤什么值、而不是查询怎么搭时，三种生成策略收敛到相同 SQL。没有任何值检索机制时，ID 解析接近零。
• MAC-SQL：交互访问能发现一些参考值（30%–39% ID 准确率），但 5 次查询的预算在复杂查询里用完之前，解不完所有必需查找。
• ReFoRCE：修正能修执行错误，修不了语义错误的过滤值。查询带着错误 ID 成功执行，于是没有错误信号触发修正。
• DAIL-SQL / DIN-SQL：二者都收到实体链接和查找智能体，ID 准确率仍只有 21%–29%。查找智能体提供候选 ID，但通用提示缺少在相似选项里消歧所需的领域规则（例如哪个营收指标、哪种期间类型）。
• FlexSQL：在 Transactions 上是例外，不到一半的错误可归因于 ID 解析。在 Transactions 上，FlexSQL 只在 65% 的时候选对表、46% 的时候选对列，这解释了大部分非 ID 失败。它的 ID 解析不错（69%），但选错表或列，说明基于计划的模式探索仍会漏掉结构路径。

消融确认这一诊断：去掉 FLINT 的查找智能体后，准确率降到 55% / 33%（Financials / Transactions），与最强基线相当。最干净的检验是固定模式：给定 FLINT 自己的模式链接，DAIL/DIN 与金标准仍有约 0.97 的表重叠和 0.70–0.81 的列重叠，得分却只有 32%–40%。因此剩余错误是错误的过滤 ID，不是错误的表或列，是值落地的缺口。激进裁剪的方法则会丢掉模式本身：MAC-SQL 只保住金标准列的 0.39 / 0.20（Financials / Transactions）；ReFoRCE 的迭代修正裁得足够狠，重叠崩掉。这是表 8 没有分开的另一种失败。一旦给对了模式，剩下的就是值落地。

#### 理解 FLINT 的失败

最后检查 FLINT 自己在 Transactions 上的模式链接失败，混淆集中在两组列。（1）买方 / 标的关系链：中间的交易到公司表和公司关系表，以及平行的参与方 ID 列和关系类型键（多跳的「谁和谁交易」路径），在没有裁剪的情况下被丢掉。（2）货币 / 状态脚手架：汇率和货币换算表及其标志列，加上交易状态表，被过度选中。这提示，像 Transactions 这样的模式，会受益于在模式链接提示里把连接路径和货币用法写得更明确。

表 9 按结构复杂度给出 FLINT 的准确率。表现在中等查询上最高。正文写的是 75% / 70%，这是系统设计点：标准连接链被少样本例子和查找约束覆盖得好。简单查询（64% / 66%）尽管结构更简单，却差于中等。作者为此做了单独的人工审计。只把「返回正确值、但非必要列或表不同」的失败记为通过，有效准确率从 68.8% / 65.2% 升到约 85% / 约 76%。作者称之为只影响呈现的失败。简单查询上残余的差距不是规定不足：Financials 上八个简单查询失败里，大约一半只影响呈现；真正的失败是在本该很简单的问题上的实体链接错误，以及把它们过度工程化的倾向（加上多余的货币换算或额外连接）。这种过度工程化，是有助于复杂查询的稳健性的另一面。复杂查询（正文写 54% / 52%）因 7 次以上连接上的错误复合而下降。

表 9：FLINT 按查询难度的准确率（%）。表中 Transactions 的中等为 71、复杂为 53，与上段正文的 70 和 52 不完全相同，两处都按原文保留。

D.12 延迟分析

作为已部署的生产系统，FLINT 的端到端延迟是关键设计约束。图 5 在对数刻度上比较所有方法的查询延迟中位数。

图 5：端到端查询延迟中位数（对数刻度）。FLINT 的中位数为 10–20 秒，在 Financials 上几乎比次快的基线快 2 倍，几乎比 CHESS 快 100 倍。原文这一图在 HTML 中没有独立图片文件。

10–20 秒的中位数使交互式生产部署成为可能，并快于所比较的全部 T2S 系统。CHESS 的延迟来自顺序的候选生成和数据库探索，不适合实时使用。

附录 E 消融细节

每次消融恰好关掉一个部件，流水线其余部分保持完整。本节说明每个实验条件。

#### 查找智能体

动态查找智能体被换成最常见的 100 个 Financials ID 和 50 个 Transactions ID 的静态映射，覆盖约 78% 的查询。这些映射作为预先解析的约束注入生成提示。这测量的是：按问题的约束解析，是否比全面的静态知识更有价值。

#### 模式链接

模式链接阶段被完全绕过。SQL 生成器收到完整模式（所有表和列），没有中间的表或列选择。其余部件（查找、检索、实体链接、反思）保持活动。

#### 模式链接的消融条件

去掉模式链接后，模型必须从完整模式文本的数百列里选择。表重叠仍然高（0.96），因为查找约束和检索例子仍会隐含地引导选表，但列选择变差。

#### 少样本检索

相似查询检索节点返回零个例子。模式链接和 SQL 生成在零样本模式下运行，不提供范例查询。查找智能体仍提供参考表约束，从而隔离结构模板的贡献。

#### 反思

第一条生成的 SQL 不论执行结果如何都直接提交、不重试。在 Financials 上，触发反思的查询不到 1%，因此这一消融影响很小。在 Transactions 上，16% 的查询最初执行失败，给反思留下挽回的机会。

附录 F 查询库重叠分析

作者检验评测准确率是否可能由检索查询库与评测集的相似来解释。对每条评测查询，在规范化的 sqlglot AST 上计算到最近查询库邻居的规范化树编辑距离，使用内容感知模式：表名、列名和字面量都计入距离（这是与泄漏相关的度量）。重叠度报告为 1−TED。

表 10：每条评测查询到查询库的最近邻内容感知重叠（1−TED）。

三点说明重叠并不驱动准确率。（1）对照：拿到同一查询库的基线（少样本 k=3，以及经同一检索的 DAIL、DIN、FlexSQL、ReFoRCE）仍落后约 20–30 个百分点；若重叠能带来准确率，它们也会继承。（2）构造上不相交：查询库例子使用固定的规范实体，与评测集不共享问题，因此即便结构相似，过滤的也是不同实体、指标和日期，不能靠抄写来回答。（3）是结构级而不是答案级：高结构相似反映的是共享的连接骨干（常见的多表链加上货币处理），这是设计使然；与泄漏相关的内容感知度量显示，Transactions 上实质上没有近重复。

附录 G 向其他领域推广

为检验 FLINT 的架构是否超出金融，作者在两个外部基准上评测，范围包括多个科学与工业领域。对每一个，只改配置来改编 FLINT，也就是模式文档、用于检索的查询库和领域提示规则，不改流水线代码。代码在 https://github.com/kensho-technologies/flint 。

SM3-Text-to-Query（Sivasubramaniam 等，2024）是医学基准，建在 Synthea 合成患者数据上（19 张 PostgreSQL 表，SNOMED、LOINC、RxNorm 编码作为不透明标识）。少样本基线高，是因为结构简单：68% 的问题是单表。FLINT 的增益集中在更难的切片：多表连接准确率达到 97%，不可回答问题的检出达到 97%，少样本分别是 90% 和 42%。

ScienceBenchmark（Zhang 等，2023）是更难的检验：三个来自不同科学领域的 PostgreSQL 库，少样本也只有 50%–82%。CORDIS（欧盟研究资助，19 张表）要在连接项目、机构和资助计划的复杂多对多模式里导航。OncoMX（癌症生物标志物，25 张表）要求在连接基因、疾病和临床检验的深外键图上走对路径。SDSS（天文巡天，6 张表、420 万行）检验在宽列测光目录上的检索，并带领域专用的类型查找。

图 6：ScienceBenchmark 上的准确率。CORDIS（欧盟资助，19 张表）、OncoMX（癌症生物标志物，25 张表）、SDSS（天文，6 张表）。图中三组比较零样本、少样本（k=3）和 FLINT。原文这一图在 HTML 中没有独立图片文件，各柱精确高度未在正文中逐项列出。

表 11：SM3-Text-to-Query 的结果。难子集是多表连接和不可回答的问题。FLINT 的增益集中在难子集（比少样本高 11 个百分点）。

FLINT 在每个领域都高于少样本，最多高 14 个百分点（图 6 和表 11）。增益来自同样的部件：检索展示该领域模式拓扑上的正确连接；领域规则执行惯例（大小写敏感、算子选择、表特定语义）；基于执行的反思通过发现空结果，从错误连接路径上挽回。不需要架构改动，只有配置层适应每个领域。

附录 H 部署考量

FLINT 对一个数 TB 的金融库提供生产流量。与离线评测不同，部署没有金标准查询，因此系统必须在没有真值监督的情况下保证安全并发现失败。

H.1 查询安全

所有生成的 SQL 经只读连接执行，并带行级访问控制。查询若引用用户授权范围之外的表或列，在网关被拒绝。结构校验器在执行前检查每条查询，拦截含变更关键字、没有 WHERE 的无界扫描，或连接超过可配置扇出阈值的语句。查询执行受仓库强制的会话级资源限制（超时、内存、结果集大小），防止失控查询拖垮共享基础设施。

H.2 监测与质量信号

没有真值时，作者依靠代理信号发现退化。执行失败（语法错误、权限违规、超时）提供不含糊的错误信号，并经反思环立即重试。对语义错误但可执行的查询，监测结果集异常：本该返回数据的问题得到空结果、意外大的结果集，以及与所查表不一致的空值比例。用户反馈（显式评分，以及把问题换个说法再问一次这类隐含信号）提供稀疏但质量高的正确性信号。汇总指标（执行成功率、延迟中位数、用户满意分）在滚动窗口上跟踪；持续退化会触发对检索索引和提示模板的复查。

附录 I 扩展的相关工作

在多智能体系统之外，更早的提示词工程不靠多智能体编排来处理这个问题。DAIL-SQL 用词元级相似度做少样本选择，并用把模式与例子分开的结构化格式；DIN-SQL 把任务分解成带自我修正的子问题。两种方法都表明提示结构重要，但都没有机制去找出现在问题或模式文本里的值（FLINT 第 3.1 节的查找智能体）。

另一条工作把模式链接当作预处理，以减少交给 SQL 生成器的词元量。C3-SQL 用 ChatGPT 经零样本推理识别相关模式。RESDSQL 训练单独的排序模型来选择相关表和列，再把裁剪后的模式交给生成器。在规范化模式上，额外的挑战不只是识别答案所在的目标表，还要识别用于外键遍历的桥表。FLINT 用连接路径、已解析的查找约束和检索到的相似例子，来引导桥表的识别。

出处：Arijit Sehanobish，Bruno Gomes Coelho，Guillaume Michel，Sophia Zhi，Valerie Faucon-Morin，Kristen Howell，From Benchmarks to Production: A Text-to-SQL System for Complex Financial Data，2026-10-02，https://arxiv.org/abs/2610.03524，CC BY 4.0。