NL2SQL的致命弱点：数据关联难题与IntaLink破局之道发表时间：2025-04-15 15:47 NL2SQL（Natural Language to SQL）是将自然语言自动转换为结构化查询语言（SQL）的技术。其发展始终围绕“降低数据查询门槛”的目标，从规则驱动到AI泛化，逐步成为连接自然语言与结构化数据的重要桥梁。任何技术都不是孤立发展的，NL2SQL技术也从1970S开始时采用的“基于规则与模板”方法，经历了“统计方法、深度学习、预训练模型”几个阶段后，目前主要研究方向是”大语言模型与Few-shot”。所有的技术都是为了解决问题出现的，我们现在从本质上分析一下NL2SQL的核心问题所在。
先给出我认为的两个本质点： *理解自然语言的意图 *理解数据资源的含义 1、理解自然语言的意图 我们先给出两个示例，来说明一下NL2SQL的可能场景。 示例1：请按顾客分组，汇总一下各顾客本月的订单量及订单金额总数？ 示例2：请帮我查一下本月最大的客户是哪个？ 对于示例1的问题，NL2SQL实现的是按照用户给定的代码编写思路，将明确的需求转换成SQL代码。而对于示例2的问题，则需要先理解问题的意思，再推理出如何解决这个问题，然后根据解决问题的方法，转换成数据问题，再形成SQL代码。现在大语言模型技术的发展，理解问题、分析问题及逻辑推理能力越来越强。因此，示例2的问题，我们可以简单认为，大语言模型是有能力将其简化到示例1问题。 本文聚焦的是NL2SQL，即使大语言模型在这方面有欠缺，也暂不列为本文讨论的范围。但可以给出一个结论，即NL2SQL的技术实现中，对于自然语言的理解，目前一定是由大语言模型实现。 2、理解数据资源的含义 我们先看下面一组数据：
给定的样例数据，数据项分别命名为C1、C2、C3、C4、C5。数据值也没有明显的意义。这样的数据是无法被理解和使用的。我们可以给这几列数据赋于一定意义，如：C1(产品种类)、C2(产品数量)、C3（单价）、C4(是否质保)、C5（结算标志）。也可以给定另一组定义，C1(顾客ID)、C2(本次消费)、C3（余额）、C4(VIP客户标志)、C5（折扣标志）。这个示例可以简单说明，如果不理解数据的含义，无论对自然语言理解的再好，推理逻辑再准确，也没有办法转换成对数据的操作。 在对NL2SQL这一领域进行探索时，已经公布的论文或开源产品，对于这一问题采用了类似的做法。主要有两种形式，一种是通过RAG方式，以某种方式提供数据库的结构说明；另一种是通过样本，根据问题和答案的对应关系，由大模型推断数据的意义。
在现有技术背景下，我们可以认为上面所讨论的两个本质问题都能解决了。但是为什么到现在为止，为什么没有出现“明星”式的应用呢。部分软件产品在一些应用场景，实现了通过自然语言进行数据查询和数据分析这样的功能。但还没有一个被业内普遍认可的成功案例。更多的是一种探索，意义大于实用。 笔者亲自做了几个实验，先给出结论，后面再扩展讨论：
下面进行一些扩展说明，笔者设计了7张数据表，分别是课程信息、教材信息、学院信息、班级信息、学生信息、考试成绩评判标准及考试成绩。数据表和数据项的命名和代码都比较规范，如学号，在学生信息和考试成绩两张表中，都用”学号 STUDENT_NO”来表示，将这些信息输入到大模型后，提出相关问题，都能正确理解和回答（注：没有Few-Shot）。说明自然语言的理解和推理能力占了主层作用。对于上面这组数据表，数据表结构不变，但是对于数据表、数据项的名称和代码改变了，变成非常识性逻辑，如将课程改成“麻瓜”，考试改成试练，班级改成洞府，并且相同含义的数据项，在不同数据表中用不同的名称和代码。也将这组信息输入给大模型，然后将相同的提问，转换成新命名规范的问题，这时我们发现，已经无法给出正确的答案了。能够看出，其理解和推理能力，限制于数据结构信息的输入和问题的逻辑。（笔者保留了测试的数据集和问题集，有兴趣的朋友可以联系索要）。其关键问题就是，给定的数据定义中，基于常识无法理清数据之间的逻辑关系。
基于前面的论述，现引出本文要讨论的一个核心问题：如何分析数据表间的逻辑关系，也可以简化为如何建立给定数据表之间的关联关系。 我们先说一下，为什么目前主流的技术路线不是解决这个问题的有效路径。 第一种，依靠大模型自身的能力有两大限制，无法面对复杂的现场应用场景。第一个限制，通识性的基模，在一些专业性的场景，或者是一些私有化的场景，其业务内容和业务逻辑自成体系。对于给定的数据资源，无法通过常识性的认知，理解数据的内存关系。第二个限制，数据集成应用是发挥数据价值的必经之路，而多系统、多数据源带来的数据标准不统一问题成为必然。对于数据确源、表间关系等项工作，在专项的数据治理工作都是一个难题，大模型在没有输入的情况下，是无法建立起数据表间的逻辑关系。 第二种，通过预训练的方式。如果我们给定足够的样本，是能够通过大模型学习和推理，形成正确的数据表间的关联关系。我们可以简单理解一下这种技术实现的本质。 Question1: *****? Answer1: select a.c1,b.c2 from a join b on a.c3=b.c4; Question2:******?Answer2:select a.c1,c.c3 from a join c on a.c3=c.c2; …… 根据类比，如果我们要访问b、c两个表的数据时，可能的关联关系就是b.c4=c.c2。 也就是说给出的样本数据可以没有所使用的场景，但是要包含有能够推理这个逻辑的信息。对于生产环境中，这种方式需要输入大量的样本数据，才有可能让大模型分析出正确的数据关系。但面临新增数据资源时，有新的数据集成可能时，这个工作就需要重新进行。因此，这种方式的实施成本比较高，并且一旦面临需求更新时，整个流程可能需要重做。
IntaLink是一个开源的数据链路智能生成技术，其核心包括几大部分：智能表间关系分析、数据链路生成、数据链路评分、数据链路优选。 这个技术的应用成果，可以做为NL2SQL的输入，替代预训练这个过程。我们现对其解决的问题，以及对NL2SQL的互补性进行分析。 我们先假定NL2SQL已经对自然语言问题的理解正确，也清楚回答这个问题的逻辑，但是转化为数据操作时，将会面临这样的问题。 现实应用场景中，所需的数据可能来源于多个系统，这些系统间的命名规范和编码并不统一。例如，一个产品的标识，在不同系统不同数据表中，有产品名称、产品编号、产品代码、产品编码、产品CODE等多种存在的形式，甚至同一张表中，就有产品名称和产品编码两个数据项。我们前述已经讨论利用样本数据理解数据关系的不足。所以在没有足够样本输入情况下，大语言模型自己是无法确定不同数据表之间应该如何关联，是A.产品名称=B.产品编码，还是A.产品代码=B.产品编号呢？尤其是数据表和数据项的名称的实际意义很难通过常识去理解时，这种关系就更无法进行分析。现在可以通过结合检索增强（RAG）、SQL执行反馈（如DAIL-SQL）提高SQL的准确率。但只是局部性的提升，不是解决这个问题的根本方法。在笔者参与过的数据治理项目，曾面临几十个系统，数千张数据表，几十万个数据项的数据规模。我们模拟这样一个示例，有三张数据表A、B、C。其中A表记录的是产品生产日报，产品以“产品名称（CPMC）”表示，B表是产品销售情况，产品以“产品编码（CPBM）”表示，而C表则是一个中间表，描述的是产品名称和产品编码的对应关系，两个字段分别为（CPMC、CPBM）。如果给定这组信息到大模型中，大模型是能够自动建立这组关系的。但是如果给定的大模型是8000张数据表，这个映射关系中的数据项没有用产品名称和产品编码来表示，而是用一个中性词CODE1、CODE2,这时大模型就没有分析的依据，无法建立起有效的逻辑关系。再退一步来说，当多源数据集成时，可能建立起的逻辑关系有多种可能。那么应该按何种关系建立连接呢？这些问题都是具体数据资源情况息息相关的。 IntaLink从数据资源出发，智能化分析数据表间关系，在给定数据集成需求时，能够快速的生成可行链路，并根据评分结果，给出合理的链路。当我们将这个结果做为大语言模型生成SQL的限定条件时，大语言模型就不需要推理（猜测）不确定性的数据关联关系。 IntaLink可以做NL2SQL的能力补足，并不是替代品。二者结合，可以完美的提高NL2SQL的准确度。同时，减少了对预训练的依赖，工作重点可以放在RAG的建立上，而这个是可扩充的，可以不断提升NL2SQL对业务的理解，适应新的数据资源。 |
