生产环境中的Text-to-SQL：自然语言查询为何在Schema边界失败

演示每次都能成功。LLM把"显示上个季度收入前十的客户"翻译成完美的SQL，结果瞬间弹出，会议室里所有人都点头认可。然后你把它部署到你实际的数仓上——130张表、1400个字段、十年积累的有机命名惯例——模型开始自信地生成返回错误数字的查询。没有报错，只是答案是错的。

这就是Schema边界问题，也是为什么Text-to-SQL在所有AI能力中，基准测试性能与生产现实之间的差距最大。在Spider 1.0（标准学术基准）上得分86%的模型，在Spider 2.0上准确率下降到约6%，而后者更接近真实企业Schema的复杂度。供应商在干净的玩具Schema上演示，你却要在自己的Schema上部署。

理解这一差距为何存在——以及什么真正能缩小它——需要审视四种相互叠加的失败模式：Schema上下文过载、连接图盲区、列名歧义，以及静默错误答案问题。

Schema上下文封装问题

LLM并不理解你的Schema，它们只是对你注入提示词中的任何Schema上下文进行模式匹配。这立刻带来一个工程困境：包含的上下文太少，模型会幻觉出表名和列名；包含太多，模型淹没在无关token中，结果更差，同时还在烧预算。

学术基准在10-20张表、共50-100个字段的Schema上测试模型。真实企业数据库通常有100+张表、1000+个字段。把完整Schema塞进GPT-4o提示词，每次查询要花约8400个token，而最终生成的SQL只有16个token。按每天10000次查询计算，每年仅在无效上下文上就要消耗约43800美元——而且模型准确率还因噪音而下降。

正确的做法是在模型看到Schema之前先做Schema剪枝。一个确定性的剪枝阶段，利用外键图遍历和分层实体解析，能将注入的Schema token减少93%，同时保留查询实际需要的表和字段。三个层次分别是：从问题中直接匹配表名、业务术语映射（如果用户说"收入"，代表这一含义的是哪张表哪个字段），以及针对特定过滤或分组的字段级检测。

问题在于，纯文本匹配会遗漏那些结构上必要但语义上不可见的表——尤其是多对多关系中的关联表。名为order_line_items的表会匹配订单相关的问题；名为xref_product_campaign的表不会匹配问题中的任何词，即便查询可能需要它来桥接两个实体。这正是单靠Schema剪枝行不通的地方。

连接图注入

外键关系编码了文本相似度无法恢复的知识。当用户问"哪些活动在Q3驱动了销售"时，查询可能需要经过两三张中间表的连接路径。对表摘要做向量相似度检索会找到campaigns表和orders表，但不会找到那张名字普通、与问题没有语义相似性却是连接两个实体唯一途径的桥接表。

将外键图注入提示词——无论是以结构化Schema链接表示，还是以从问题中提到的实体出发可达的子图——能显著减少连接错误。在BIRD基准（使用37个专业领域的真实混乱数据库）上的研究表明，图感知的Schema链接方法在所需Schema元素上实现了92%的召回率，同时将注入的上下文减少了83%。

实际实现方式：在构建LLM提示词之前，从问题中提到的每个实体出发，通过遍历外键关系发现结构上必要的中间表，将这些表纳入Schema上下文，即使它们在语义上与问题不匹配。这比让LLM从Schema子集中推理连接路径更便宜、更可靠。

基于图的技术还能解决一个更隐蔽的问题：LLM可能知道需要连接，但构造出错误的连接。当实际外键关系使用的是不显眼的字段对时，模型经常"发明看似合理的连接键"。注入精确的外键约束就能消除这种歧义。

列名歧义问题

企业Schema中充满了在不同表中含义各异的字段：created_at出现在40张表里，status出现在60张，user_id根据所在表的不同可能指向不同的用户群体。当模型没有得到消歧上下文时，它通过模式匹配来解决歧义——即Schema中"应该"存在什么——而这取决于训练数据中占主导的电商或SaaS Schema是什么。

工程事故复盘中反复出现一种生产故障模式：查询干净地执行并返回看起来合理的数字，但它以错误的粒度对价格取了平均值，用了order_date而非shipped_date，或者从payments而非revenue_recognition中取数。SQL在语法上正确，语义上也连贯——对模型来说。只是不符合业务定义。

解决这个问题需要用人类可读的元数据来丰富Schema上下文：字段描述、哪些字段代表规范业务指标、哪些表包含"真实来源"数据而非派生或缓存数据，以及领域特定的同义词。对于有文档的Schema，这些元数据可以自动提取。对于文档不足的Schema（大多数真实数仓都这样），需要做一次性的标注工作。但投资回报是显著的：投入精力记录表描述和规范指标定义的团队，生产环境中的正确查询率从40%提升到了90%。

除了元数据，用来自你特定Schema的代表性查询-SQL对进行多样本提示，能让模型学习你的命名惯例。如果你的Schema用_amt后缀表示金额、_cnt表示计数，几个示例就能以描述单独无法实现的方式让这种模式变得明确。

澄清预言机

Text-to-SQL中最隐蔽的失败模式不是查询报错——而是执行后返回错误结果却毫无异常信号。用户问"我们最畅销的产品是什么"并得到了答案。这个答案基于销量。用户的意思是按收入。两种解读都合理，而模型静默地选择了其中一种。

在流水线中构建澄清预言机是生产级别的修复方案。在进行SQL生成之前，系统评估问题是否表述得足够清晰：

• 意图能否用单一无歧义的SQL查询来满足？
• 是否存在多种会产生不同结果的合理解读？
• 是否有隐式的必要过滤条件（例如"活跃客户"——按什么定义算活跃？）

当歧义程度超过阈值，系统生成有针对性的追问，而非直接进入生成阶段。"你是按件数还是收入衡量销售额？"只消耗一次交互轮次，而返回错误答案会影响业务决策。

工程决策在于阈值设在哪里。阈值太激进，系统会对简单查询也追问，令用户沮丧；太宽松，静默错误就会积累。一个实用的启发式规则：当问题包含表述不清的聚合指标（最好、最高、最多），包含没有明确基准点的相对时间引用（"上个月"，而Schema同时有自然月和财年月），或者实体引用映射到多张粒度不同的表时，就发起追问。

预期信息增益框架将这一过程形式化：对每个可能的澄清问题评分，以其解决歧义的概率乘以它能消除的信息熵。提出每轮能最大程度降低不确定性的问题。在实践中，大多数查询最多只需一轮澄清；需要更多轮的问题通常本身就表述不清，用户自己也不清楚究竟想要什么。

闭环：迭代纠错

即使有了良好的Schema剪枝、外键注入和澄清预言机，仍然会有查询出错。最后一道防线是基于执行的反馈：运行生成的SQL，检查它是否能执行、是否返回结果、返回的结果是否通过基本合理性检查——并将失败信息反馈给模型。

生成-执行-批判循环能自动捕获大量错误。语法错误会立即失败。Schema引用错误（幻觉出的列名）会带着数据库错误信息失败，这些信息可以重新注入提示词并附上修复特定引用的指令。语义错误更难——当期望有结果的查询返回零行时，这是可疑的；当期望返回分布的查询只返回单行时，这也是可疑的。这些信号不是决定性的，但能捕获最严重的错误。

多智能体架构在这里有帮助：生成器智能体产生SQL，批评器智能体评估查询是否与问题和Schema一致，循环智能体协调重试。在生产部署中，生成器-批评器模式能在到达用户之前捕获约30-40%的初始错误。

一个重要约束：永远不要在首次尝试时直接对生产数据库执行LLM生成的SQL。先用sqlglot等库解析并验证AST，确认所有引用的表和字段都存在，运行EXPLAIN空跑以捕获执行层面的问题而不返回数据。只有通过这些门控之后，查询才能执行。

生产环境中真正有效的方法

交付用户信任的Text-to-SQL系统的团队，基本上已经汇聚到同一种架构：由外键图遍历驱动的激进Schema剪枝、针对规范业务术语的元数据丰富、预检澄清步骤应对歧义问题，以及带有自动重试的后执行验证循环。

基准数字会持续提升——截至2026年初，BIRD上最好模型的执行准确率接近72%，两年前还不到50%。但基准与生产之间的差距是结构性的，不仅仅是模型能力的问题。基准在干净、规范化的Schema上测试，这些Schema有完整的语义文档。你的数仓有十五年的命名漂移、ETL中未记录的业务规则，以及在不同上下文中含义各异的字段。

缩小这一差距是工程问题，不是模型问题。LLM在做模式匹配；你的工作是给它准确、充分且无歧义的模式去匹配。这意味着要投资Schema元数据质量、构建能智能剪枝上下文的基础设施，以及设计能明确失败而非静默失败的流水线。模型会不断变好，Schema不会自己清理干净。