从表结构理解到权限控制：Text-to-SQL企业落地的关键挑战

1. 先澄清一个误区：Text-to-SQL 在企业里卡住大家的地方，真不是生成 SQL 的那一步

Text-to-SQL 这两年已经从论文里的热门选题，变成了越来越多企业认真评估的内部项目。我在企业里做了几轮落地之后，越来越确定一个观点：让模型写出一句像样的 SQL，往往是最简单的一步；真正决定项目生死的是表结构理解与权限控制这套外围系统。

很多人看到“自然语言转 SQL”这个名词，第一反应是“这不就是个翻译问题吗”。模型负责把人类语言翻译成 SQL，翻译对了，任务不就完成了。可惜，这个想法在企业场景下错得相当离谱。

1.1 演示环境一团和气，一进生产环境就失灵

在公开数据集上评测的时候，表结构是干净且标准的，每个字段都有明确含义，所有表关系都像教科书画好了一样摆在那里。你拿大模型去生成 SQL，剩下的工作就是对照参考 SQL 看执行结果是否一致，准确率确实可以做得很好看。

但企业里的真实库表是另一番景象：几十个库、几百张表、上千个字段，命名习惯完全由历史项目决定。有的表叫 t_orders，有的表叫 B2B_ORDER_2020；同一张表里既有 status 又有 order_status；同一个 user_id，在订单表里是客户 ID，在运营表里是注册用户 ID。这些信息，光靠把建表 DDL 丢给模型是学不会的。

我在实际落地中见过一个最典型的例子：业务方问“上月新签客户有多少”，模型把 create_time 当成签约时间，实际上这张表的 create_time 是客户档案的录入时间，真正的签约时间在合同表里的 sign_time 字段上。结果 SQL 写得很工整，执行也毫无报错，但数据就是错的。这类错误最可怕，因为它不报错，你甚至不会第一时间想到要去质疑结果。等发现时，可能已经基于这个错误数字出了一份决策周报。

1.2 企业里的精确性要求，和公开数据集评测是两码事

公开数据集通常是在任务执行完成后对比结果判定对错，指标反映在一个相对孤立的环境里。但企业里衡量一个 Text-to-SQL 系统能不能用，标准远比“执行正确”复杂。除了执行结果要正确，你还要考虑：

• 这个查询涉及的字段，提问人有没有权限看？
• 查询跑在哪个数据源上，不同库之间的数据口径是否一致？
• 查询会不会扫描整张表，把线上业务库压力打满？
• 同样的口径换个说法，系统还能不能稳定识别出来？
• 结果里有没有需要脱敏的敏感信息？

一个能让业务方安心点“运行”的 Text-to-SQL 系统，本质上是一个完整的数据服务系统。SQL 生成只是其中最外层的壳，壳里面的表结构理解、权限控制、执行治理，哪一个环节没做好，都会在线上炸掉。这也是为什么我不能接受“Text-to-SQL 就是调个模型写 SQL”这种简化说法。

1.3 从大家关心的方向，也能看出落地的真实门槛

我平时会留意跟 Text-to-SQL 相关的搜索词和讨论方向，发现大家搜得最多的往往不是“怎么用大模型生成 SQL”，而是“sql 优化”“慢 sql 优化”“权限控制”“sql 注入”这类落地层面的东西。这个信号很有意思。

搜索“sql 注入万能密码绕过”的人，本质上是在担心生成式 SQL 会不会把系统安全边界撕开一个口子；搜索“慢 sql 优化”的人，显然已经见过模型生成的 SQL 在线上把数据库跑挂的场景；搜索“dify权限控制”这类词的人，是想在自己的 Agent 框架上补齐企业级权限能力。这些需求加在一起，拼出的才是 Text-to-SQL 在企业落地的真实图景：写 SQL 是入口，稳定、安全、可控地拿到数据才是出口。

2. 表结构理解：为什么模型“读过 schema”和“看得懂业务”是两回事

表结构理解这个词，看着像是给模型喂点元数据就行，实际上要做的工作量远超想象。我把它拆成三层来看：第一层是元数据收集，第二层是语义建模，第三层是检索注入，三者缺一不可。

2.1 裸元数据在企业里有多“难读”

先说我见过的一个真实库表字段：

sql复制CREATE TABLE `order_info` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `order_no` varchar(64) DEFAULT NULL,
  `user_id` varchar(32) DEFAULT NULL,
  `product_id` bigint DEFAULT NULL,
  `status` tinyint DEFAULT NULL,
  `pay_time` datetime DEFAULT NULL,
  `amount` decimal(10,2) DEFAULT NULL,
  `create_time` datetime DEFAULT NULL,
  `update_time` datetime DEFAULT NULL
)

没头没尾的时候，你根本不知道 status=1 是已支付还是待支付，amount 是订单总价还是加上运费和优惠券后的实付金额，user_id 究竟是买家还是卖家。模型就算把这段 DDL 背下来，也回答不了这些问题。

数据字段的命名和注释，反映的往往是最初建表时的状态，而不是业务当前的状态。很多表上线后经过多次迭代，字段含义早就变了，DDL 却没人回头补。这就要求我们必须在模型之外建一层“语义表”，把字段的业务含义、枚举值、计算口径、单位、敏感级别，甚至联动关系都整理清楚。

2.2 列级业务词典：整个系统的地基

我推荐所有准备做 Text-to-SQL 的团队，都先花时间建一张这样的词典表，而不是急着调 Prompt：

这张表不只是给模型看的，也是给权限系统和语义检索系统用的。用户问“看看昨天成交订单有多少”，我们首先要做的不是直接让大模型生成 SQL，而是先在词典里把“成交”匹配到 status=1 或 2，“昨天”匹配到对应的 pay_time 时间范围，然后带着这些上下文去生成 SQL。

建这个词表的过程需要业务方深度参与。我一个常用的方法，是把字段清单发给核心业务同事，请他们按模块逐表批注，允许带“待确认”标记，后续根据实际错误不断纠正。这一步看上去慢，但它决定了整个系统准确率的上限。

2.3 表关系也需要单独建模，别让模型自己猜 JOIN

企业数据库的表关系从来不是教科书里的星形模型，而是一个盘根错节的网状结构。同一张事实表可能既可以通过 order_id 关联订单主表，也可以通过 refund_id 关联退款表。如果你把所有可关联路径都丢给模型，它很容易选出错误的路径。

我比较推荐的做法，是把表关系单独维护成一张关系图，里面记录：

• 关系类型：1:1、1:N、N:M
• 关联字段：例如 order_info.user_id = user_profile.uid
• 业务含义：例如“订单表与用户表通过 user_id 关联，用于聚合客户维度的消费统计”
• 可信度或优先级：有些关联只适用于特定场景，用于区分常用路径和特殊路径

在生成 SQL 前，系统根据用户的问题先做一次表筛选，把可能相关的表限定在 5 张以内；如果超过 5 张，就按照关系图里的优先级挑选最合适的路径。这样既节省了模型输入 token，也减少了 JOIN 写错的可能。

2.4 把整个库表塞给模型是最笨的做法

有些团队图省事，直接把所有表的 DDL 拼在一起放进 Prompt，让模型自己“理解”。这种做法的坏处非常明显：一是 token 成本高得离谱，二是表一多，模型会“无所适从”，被不相关字段干扰的概率剧增。

正确的方式是“按需检索”。先把用户的自然语言通过 embedding 和关键词在语义词典里召回候选表、候选字段，再把命中内容的字段描述、枚举值、关联关系拼接成定制化的 schema 上下文，喂给大模型。召回做得越精准，后续生成 SQL 的准确率越高。

这一点也是很多团队从 POC 走向生产的门槛。POC 阶段表少，把全量 schema 给模型没问题；生产环境一上，就必须有检索和路由的中间层，否则系统迟早会卡在成本和准确率两头。

3. 权限控制：让模型“会写 SQL”的前提，是它“只能写被允许的 SQL”

权限控制是企业在落地 Text-to-SQL 时最不敢让步的部分，也是我见过翻车最多的部分。很多团队以为给模型配一个只读数据库账号就万事大吉，实际上这套方案远远不够。

3.1 为什么数据库账号层面的限制不够用

先用一个很实际的场景说明：一个公司内部所有业务数据都在同一个库里，为了支撑运营自助取数，你给 Text-to-SQL 服务配了一个只读账号。数据库账号确实只能执行 SELECT，但问题是：

• 运营 A 能查销售大区数据，是不是意味着运营 B 也能查？
• 销售总监能看全国数据，是不是意味着普通销售经理也能看本大区以外的数据？
• 薪资表字段在库里存在，是不是每个提问人都能通过自然语言绕过前端界面直接查出来？

只读账号解决的是“不能写”的问题，解决不了“谁能看哪些行、哪些列”的问题。企业里的数据权限从来不是一个平面，它是多维度的：按角色分、按部门分、按地域分、按时间范围分，甚至按照某个客户是否是“自己的客户”来区分。

如果 Text-to-SQL 把这层逻辑漏掉，它就会变成一个非常高效的“越权查询口”。业务方只要学会了几个关键词，就能用自然语言绕开所有前端限制，直接问到没权限的数据。这会成为合规审计里非常严重的问题。

3.2 查询前校验：把权限判断放到模型之外

我强烈建议把权限判定做成一个独立的模块，在 SQL 真正执行前做一次严格的程序化校验，而不是指望大模型在生成 SQL 时自己“考虑权限”。模型很不擅长做这种强约束的事，它本质上是一个概率生成器，这次生成对了，不代表下次也能生成对。

校验模块的输入是大模型生成后的 SQL，输出是“通过”或者“拒绝”。具体要做的事包括：

1. 解析 SQL，提取所有引用的表、字段、JOIN 条件、WHERE 子句里的谓词列
2. 对每张表判断：当前用户有没有这张表的查询权限
3. 对每个字段判断：当前用户有没有这个字段的读权限
4. 检查是否存在行级过滤缺失，比如用户属于大区经理，SQL 里却没有对大区 ID 做任何过滤
5. 判断是否有危险操作特征，比如函数套函数、笛卡尔积、没有 LIMIT 的全表扫描

这里建议用 sqlglot 这样的 SQL 解析器来做 AST 解析，比纯正则匹配靠谱得多。下面是一个简化版的校验思路：

python复制import sqlglot

def validate_sql(sql, user_permissions):
    ast = sqlglot.parse_one(sql, read="mysql")
    tables = set()
    for table in ast.find_all(sqlglot.exp.Table):
        tables.add(table.name)
    for t in tables:
        if t not in user_permissions["tables"]:
            return f"无权访问表 {t}"
    for column in ast.find_all(sqlglot.exp.Column):
        if column.name in user_permissions["sensitive_columns"]:
            return f"无权访问字段 {column.name}"
    # 行级权限检查
    if user_permissions["row_filter"]["required"]:
        filter_col = user_permissions["row_filter"]["column"]
        where_columns = {c.name for c in ast.find_all(sqlglot.exp.Column) if c.name == filter_col}
        if not where_columns:
            return f"缺少行级过滤条件：{filter_col}"
    return "pass"

这个模块必须做到“零信任”，默认拒绝，只有显式命中允许列表才放行。这样可以最大限度避免因为模型幻觉导致的越权查询。

3.3 查询后拦截和结果脱敏：兜住最后一道防线

即使前置校验做得再严，我也建议再加一道查询后防线，用来处理那些前置阶段不容易发现的问题。典型的场景是：某个字段本身不敏感，但通过聚合计算后可以反推出敏感信息。比如一个查询把“销售订单数”按“员工”分组，再结合订单金额做逆推，就有可能还原出某个小团队的薪资或奖金水平。

这类问题很难靠简单的“字段黑白名单”解决，需要在查询后对结果做动态脱敏或抑制。常见的手段包括：

• 对手机号、身份证号这类固定模式的字段做掩码显示，比如 138****1234
• 对数值型敏感列做分桶或者四舍五入，避免精确到个人级别
• 对返回结果行数做限制，防止用户一次性拉取全量明细
• 对某些维度组合做“最小规模限制”，比如当分组后的记录数少于 5 条时，不返回具体数值

脱敏规则和权限规则一样，应该做到可配置，并且和业务词典里的 sensitive_level 挂钩。一个 L2 级别的字段，默认显示脱敏结果；当用户拥有对应的权限时，才在原 SQL 执行后再放行原值。

3.4 行级权限和多租户场景的动态拼装

行级权限是 Text-to-SQL 落地过程中最容易让技术团队头大的部分。以电商公司为例，运营 A 只能看华东大区的数据，运营 B 只能看华南大区。直接让模型在生成的 SQL 里添 WHERE region = '华东' 是不可靠的，因为模型可能会把条件写错、写漏，甚至被用户的口语化提问带偏。

更稳妥的做法，是由权限系统在 SQL 执行前自动改写，而不是让模型在生成时动态拼接。简单说，我们把用户所属的可见数据范围固化成一段 SQL 片段，在最后执行前强制拼接进 WHERE 子句。如果你用 MySQL，可以封装一层视图或者直接做 SQL 改写：

sql复制-- 权限系统自动追加的逻辑
AND dept_id IN (SELECT dept_id FROM user_dept_tree WHERE user_id = '当前用户')
AND region = '华东'

这样无论模型生成了什么，最终执行的 SQL 都会被强制叠加该用户的行级过滤条件，也就从根上斩断了越权查询的可能性。多租户系统也是同一个思路：租户 ID 的过滤条件永远由系统注入，不信任模型生成的任何条件。这一点跟很多数据库原生的行级安全特性本质上是同一个思想，只不过在应用层做，更容易适配异构数据库。

4. 一套可落地的实现路径：从 POC 到生产环境的改造清单

前两部分解决了“能不能写对”和“能不能安全写”的问题，接下来讲从演示到生产，整个系统应该长成什么样。我这里给的是我自己在实际项目里反复调整后相对稳定的架构分层。

4.1 架构分层：Agent、语义层、执行层各管一段

我所采用的成熟结构大致如下：

1. 交互层：接收用户的自然语言，允许用户对生成结果做确认、修改或追问。这是产品体验的主战场，但不要在这里做太多数据相关逻辑，保持界面和逻辑解耦。
2. Agent 编排层：负责理解用户意图，决定是否需要查词典、是否需要多轮澄清、调用哪个执行通道。它管理大模型的对话上下文，处理生成失败时的重试。
3. 语义层：负责表结构理解、业务词典、关系图的维护与检索。它向下连接元数据存储，向上为 Agent 提供定制化的 schema 上下文。
4. 权限校验层：对模型生成的 SQL 做解析、权限校验、行级条件注入、脱敏策略配置，是安全边界所在。
5. 执行治理层：负责数据库连接池、超时控制、限流、熔断、SQL 执行计划分析，以及对查询性能的基本保护。
6. 审计服务：记录每一次查询的完整链路日志，包括提问人、问题、生成 SQL、校验结果、执行时长、返回结果摘要。

很多团队一开始只做了前三层，上线后才急着补后三层，结果发现权限和审计这块一旦早期没设计好，后面补起来的成本特别高。我的建议是在 POC 阶段就把这六层画出来，哪怕先做简化版，也别跳过。

4.2 让系统学会“拒绝”：这是产品成熟度的分水岭

Text-to-SQL 系统最怕的不是答错，而是“知道不该答还硬答”。比如有人问“去年采购部的奖金发放明细”，这个请求如果落在没有权限的用户头上，最理想的行为不是生成一条 SQL 去查，而是直接拒绝并说明原因。

要做到这一点，需要让模型在意图理解阶段就识别出权限边界。具体做法是：在 Prompt 里告诉模型“你只能回答与可访问数据相关的问题；当用户问题超出可访问范围时，直接回复无法查询，并说明原因”。同时在权限校验层设置一道规则：如果解析出的 SQL 引用了不在当前用户权限内的表或字段，一律返回“无权限”，而不是“该表不存在”或“查询失败”。

不要低估“会拒绝”这一点带来的产品价值。实际上，业务方对系统信任度的建立，有很大一部分来自于系统知道哪些问题它不擅长。一个不管什么请求都硬着头皮生成的系统，即便准确率有 90%，剩下那 10% 的错误也会让用户对它完全丧失信心。

4.3 审计与可追溯：每一个查询都要能复盘

企业的数据查询都会涉及合规问题。Text-to-SQL 这类产品因为引入模型，天然带了一层“不可完全预测”的属性，更需要把可追溯性做足。至少要记录以下几类信息：

有了这套记录，当业务方质疑某个数据不对，或者合规团队要求排查某段时间的所有查询时，我们可以在几分钟内还原当时的完整链路。注意不要小看 model_version 和 prompt_version 这个字段，模型升级或者 Prompt 微调后，行为可能发生肉眼不可见的变化，不记录版本号，排查问题会非常痛苦。

4.4 性能、超时、限流与熔断

最后聊聊执行链路上的治理。Text-to-SQL 和直接调一个接口不同，它在数据库执行前先要做意图理解、schema 检索、SQL 生成、权限校验，这四步每一步都可能带来延迟。一个合理的端到端目标可以设定在 3 到 8 秒，其中模型推理通常占大头。

为了达到这个目标，常见几个优化手段：

• 对高频问题做 SQL 模板缓存。比如“昨日各区域销售额”如果每天都有人问，可以让系统第一次生成后把问题与 SQL 映射缓存起来，后续直接命中。
• 对 schema 检索的嵌入向量做预计算，避免每次请求都重新 embedding 整个表结构。
• 在数据库层面统一设置 statement_timeout，比如超过 10 秒的查询直接 kill，避免慢 SQL 拖垮线上资源。
• 对数据源的连接池做细化隔离，Text-to-SQL 的查询全部走独立的只读账号和独立连接池，防止跟业务系统互相影响。

这里也顺便说一句，很多看起来是 Text-to-SQL 本身的问题，其实底层是 SQL 质量问题。比如模型生成了一个没有 LIMIT 的 COUNT(*) 查询，或者一个大表和小表直接做笛卡尔积，这些都会把数据库打爆。所以执行治理层里最好再放一个“执行计划预检”，用 EXPLAIN 看一下扫描行数和 join 方式，如果扫描行数超过阈值，直接拒绝执行，让模型修改 SQL。这本质上就是在做慢 SQL 优化前置化。

5. 落地过程中我踩过的几个坑，以及最后的几点体会

这部分没有统一的操作清单，就是想从实际经历出发，聊聊几个最值得提醒的点。

5.1 不要放过“看上去很简单的查询”

我早期有个刻板印象，觉得像“查询订单总数”这种 SQL 太简单了，模型肯定能写对。直到某次生产环境里，业务方问“查询本月订单总数”，模型的 SQL 返回了全量订单数，因为 create_time 和月结时间之间的转换规则错了。排查到最后发现，这张订单表里的 create_time 存的是下单时间，但系统内的月结周期是按自然月还是按财务月，完全取决于这个业务线的配置，光看字段名根本看不出来。

解决方案就回到了语义层：把这种“看似常识其实各业务线不一样”的口径，显式写进业务词典，并且让权限系统在生成阶段就把对应的时间范围规则注入到 Prompt 里。所有简单查询都要过一遍口径确认，哪怕多花一点时间，也要确认是真的简单，而不是隐藏着复杂业务规则。

5.2 模型“幻觉”可以用 Prompt 约束，但不能指望完全消除

模型生成 SQL 时出现“幻觉”，典型的表现是生成了根本不存在的表名或字段名，或者把两张没有业务关联的表硬关联起来。你可以通过 Prompt 里强调“只能使用给定的 schema 范围”，但就算加了这句，也不能保证 100% 不出现幻觉。

我的建议是前置校验 + 生成后校验双重拦截。前置校验用规则把不存在的表、字段拦截下来；生成后校验再用 sqlglot 解析、用 EXPLAIN 检查是否可执行。如果出现错误，最简单的兜底方案是让模型重新生成一次，并给它一个明确的反例提示，比如“用户没有权限访问 t_salary，请基于当前可见 schema 重新生成”。这种“先提示错误再重试”的方式，比单纯让模型自己检查要高效得多。

5.3 给业务方留一条“人工写 SQL”的逃生通道

最后一个体会可能跟技术无关，但我觉得值得写出来。Text-to-SQL 解决的是“把自然语言转成 SQL”的便利性问题，但它不能替代一个有经验的取数分析师，也不应该试图替代。

在系统里保留一个“专家模式”，让有 SQL 能力的用户可以自由编辑生成结果、保存为自定义模板，甚至直接上手写 SQL，能够极大提高系统在团队里的接受度。因为业务方不会完全信任模型，但他们信任一个可以抄作业然后自己改的工具。

我在几个项目里都坚持做这个功能，效果出奇的好。用户开始使用系统时往往是半信半疑的，但当他们发现生成的 SQL 可以一键复制到自己的编辑器里修改，并且系统还能记录他们的修改历史用于后续 Prompt 优化时，整体使用率和满意度反而比纯自动化生成高得多。这让我意识到，Text-to-SQL 在企业里真正落地的形态，不是替代人，而是让人更高效地验证和产出数据结论。至于权限控制、表结构理解这些地基工作，前期做得越扎实，后续模型升级和业务扩展时，系统才不会成为那个随时可能塌掉的空中楼阁。