2026-08-18

Text2SQL 落地指南：架构、数据权限、SQL 安全与上线验收

系统介绍 Text2SQL 实践方法，涵盖应用边界、系统架构、数据权限、SQL 安全校验、指标口径治理与上线验收，帮助企业可靠实现自然语言查数。

一、先判断适不适合：Text2SQL 的企业应用边界

企业引入 Text2SQL，首先要回答的不是“模型能不能生成 SQL”，而是“生成结果在什么后果范围内可以被接受”。同一套能力用于分析师临时探查数据，和用于生成经营决策依据，风险等级并不相同。前者允许用户检查、修改和重跑；后者一旦把错误结果送入报表、审批或自动化流程，问题就不再只是语句写错，而可能变成业务判断失真。

从使用方式看，企业可以把场景按人工介入程度划分为不同层级。一种场景是 SQL 草稿辅助：模型负责把自然语言转成起始语句，工程师或分析师审核后再执行，适合验证模型是否理解表结构和基本查询意图。

场景本身并不限于 BI。企业可以把它放在自然语言查数入口，帮助客服根据授权范围检索业务信息，也可以作为低代码应用的数据操作层，或用于分析人员快速试探数据。但这些场景的验收标准不同：客服更关注回答是否越权、是否能说明数据来源；分析探索更关注灵活性和修改成本；业务自助查询则更依赖指标定义是否清楚；自动化流程还要额外证明错误结果不会无条件向下游扩散。

有些环境不适合直接把 Text2SQL 放在前面。例如，表之间缺少稳定关系，数据模型靠个人经验维持；同一个指标在部门之间存在不同算法，名称相同但含义不同；查询需要频繁跨库拼接，且数据库方言、更新延迟和主数据规则不一致；结果会直接影响预算、风控、绩效或其他经营动作。遇到这些情况，优先级应放在数据建模、指标定义和语义治理上。模型只能表达已经明确的业务规则，不能替企业补齐未达成共识的口径。

因此，评估项目时不要只看模型在公开榜单上的准确率。更实用的判断方式，是把以下问题放在一起看：数据是否敏感，问题是否经常需要多表或嵌套计算，错误一次的修正代价有多高，预计使用者是否足够多，以及是否有分析师、数据工程师或业务负责人承担人工兜底。若数据敏感度高、查询链路复杂、容错空间小，同时又缺少复核人员，应先缩小范围，而不是扩大模型权限。反过来，如果数据域边界清楚、问题相对固定、用户愿意核对结果，Text2SQL 更适合作为受控的查询辅助能力逐步验证。

二、系统架构：把自然语言查数拆成可治理的链路

企业场景不宜把用户问题直接交给模型，再让模型自行连接数据库。各环节都应保留中间产物，这样出现错误时，可以判断问题来自理解、选表、生成还是执行，而不是只看到一个最终答案。

这套拆分的关键，不是把流程做得更长，而是避免不同类型的问题互相掩盖。语义理解负责回答“用户想查什么”，生成模块负责把已确认的意图转成查询结构，后续修正模块再处理语法、字段引用和执行约束。三者可以分别建立测试集，也可以独立替换实现。比如，某类问题频繁选错指标时，应优先检查概念识别和元数据召回，而不是盲目调整 SQL 生成提示。

Schema 目录也不能停留在表名、列名和数据类型。对模型和审核流程真正有用的元数据，还包括字段的业务含义、常用称呼、指标计算方式、主外键关系、允许的连接路线、敏感等级以及少量经过处理的示例值。没有这些语义信息，模型即使写出语法正确的语句，也可能选中含义相近但口径不同的字段。

元数据检索应先缩小候选范围，再把必要上下文交给后续模块。把整个数据库的结构一次性塞入提示上下文，会增加无关信息，也会让关联路径和指标定义更难被稳定利用。更适合的方式是按业务域、问题实体和指标候选筛选，并明确哪些表可用、哪些字段不可用、表之间允许怎样连接。对于敏感字段，目录中还应标注其访问条件，但最终放行不能只依赖模型判断。

简单问题可以通过受约束的模板生成查询；涉及多表连接、嵌套聚合或分阶段计算的问题，建议先形成查询计划或抽象语法树，再转换成具体数据库方言。中间表示可以把“先过滤什么、如何关联、在哪一层聚合”等决定显式化，便于检查和修改，也能减少模型直接拼接长 SQL 时出现结构漂移的风险。转换器还应对目标数据库的函数、日期处理和分页方式作适配。

执行层必须与生成层隔离。模型只能提交待审核的查询对象，不能自行获得生产库的任意访问能力；执行服务负责再次套用访问边界、资源限制和运行策略，并把成功、失败或被拦截的状态返回给上游。结果解释也不应重新猜测数据，而应基于实际执行结果、采用的指标定义和查询条件，说明统计范围、时间口径及可能的缺失项。

落地时，建议为每个阶段定义可观测的输入、输出和失败原因，并保存版本信息：使用了哪份元数据、采用了哪条指标定义、生成了什么计划、最终执行了哪条语句。这样既方便回放单次请求，也便于定位是目录变更、口径调整还是模型行为导致结果变化。架构的目标不是让模型承担整条链路，而是把它放在有边界、可替换、能被审计的环节中。

三、企业数据权限：模型能看什么，用户最终能查什么

Text2SQL 的权限问题，不能靠提示词解决。Prompt 可以提醒模型不要访问某些表，但它不是强制边界：模型仍可能生成未授权字段，用户也可能通过改写问题、猜测列名或构造 JOIN 试探数据。真正的权限判定应落在数据库、查询网关或受控执行器一侧，SQL 在执行前必须绑定当前用户的身份与授权上下文。

1. 权限判断要跟着请求走

模型生成 SQL 之前，系统需要明确请求属于谁、来自哪个租户、可以使用哪些数据域，以及该用户在当前角色下拥有何种访问范围。这里的校验不是一次性的登录检查，而是贯穿元数据检索、SQL 生成、执行和结果返回的连续约束。

权限控制不能只在生成阶段检查一次。执行器应在 SQL 进入数据库前再次校验，并对租户条件、行级过滤和敏感列做强制约束。

2. 无权元数据也不应进入上下文

Schema 检索是权限控制的前置环节。系统不应把完整数据库结构交给模型，再依赖提示词说明哪些内容不能使用，而应先依据当前用户权限裁剪可见的表、字段、枚举值和示例数据。问题中的实体、关键词和业务值可以用于检索相关 Schema，例如将地区名称映射到数据库中的标准值，但检索候选集本身必须已经过授权过滤。

这样做有两个工程收益：一是减少模型接触无权元数据的机会，二是降低无关表列进入上下文后造成的误选。需要注意，隐藏字段名并不能替代执行侧权限；即使模型没有见过某列，用户仍可能通过猜测字段或函数构造请求，因此最终边界仍应由网关或数据库强制执行。

3. 给模型和生产库之间加执行隔离

模型不应直接持有生产数据库的高权限连接。更稳妥的做法是使用只读身份，将请求交给受控查询网关或执行器处理。

每次请求都应留下可追溯记录：操作者身份、租户和数据域、原始问题、实际提供给模型的 Schema、生成 SQL、权限判定、执行结果状态以及返回摘要。日志既用于事后审计，也用于定位“生成正确但授权错误”或“权限正确但结果异常”的问题。日志本身同样需要访问控制，不能因为审计而扩大敏感数据暴露面。

4. 权限验收不能只测正常查询

测试集应专门覆盖越权路径：用户猜测未授权字段时是否被拦截，跨租户条件是否无法成立，利用 JOIN 是否能够绕过行级限制，拆分筛选或改变聚合维度后是否会泄露小群体信息。还要验证模型输出中出现危险语句、未授权表名和外部函数时，系统是在执行前拒绝，而不是依赖数据库报错兜底。

判断 Text2SQL 是否可上线，关键不是模型“知道多少表”，而是系统能否稳定地把“模型可见范围”和“用户可执行范围”分开管理，并让后者成为不可绕过的工程约束。

四、SQL 校验与执行安全：生成出来不等于可以执行

Text2SQL 的安全边界不能建立在“数据库会报错”之上。数据库只能识别部分语法、对象和类型问题，无法判断查询口径是否正确、用户是否应当获得结果，也不会主动阻止一条合法但代价过高的查询。工程上应在执行入口前设置必要的串联校验；任一环节未通过，SQL 都不进入正式执行环境。

其中最容易被低估的是语义校验。SQL 可以成功运行，却仍然回答错问题。多表查询尤其需要核对关联路径是否在治理规则允许的范围内，筛选条件能否正确作用到相关表，以及一对多连接是否放大了聚合结果。对计数、去重和比率类指标，还应检查分母范围、去重键与聚合粒度，避免出现语法正确但重复统计的结果。

风险控制不宜只依赖关键词过滤。系统应解析语句结构，识别写操作、缺少有效约束的大表查询、笛卡尔积、高成本嵌套以及可能产生过量返回数据的请求。执行侧再配置超时、返回行数、扫描规模和修订次数的上限。阈值应按数据平台能力和业务场景设定，不应由模型临时决定。

正式执行前，可以先获取执行计划，或在隔离环境中进行试运行。检查重点不是“能不能跑”，而是访问了哪些对象、采用何种连接方式、预计扫描多大范围，以及是否触发资源限制。对于动态 SQL 或执行计划难以可靠评估的查询，应优先进入沙箱，而不是直接提交到生产数据库。

修订代理适合处理引号、对象名称和字段类型等可由数据库错误明确定位的问题。它不应借助报错无限循环，也不应擅自改变指标定义、连接关系或筛选范围。每轮修订都要受次数上限约束，并保留 SQL 版本、修改原因、校验结果与执行状态，形成可复核的过程链。

失败处理同样属于产品能力。系统应区分语法失败、权限拒绝、口径不清和资源超限，并向用户说明可采取的下一步：补充时间或范围条件、选择明确指标、缩小数据规模，或者转交人工分析。可靠的 Text2SQL 不是保证每次都生成可执行语句，而是在无法确认正确性与安全性时明确停止。

五、口径治理：先解决“查什么”，再解决“怎么写 SQL”

一条 SQL 可以通过语法检查、正常执行，却仍然回答错问题。原因通常不在查询语句本身，而在业务概念没有被明确。

因此，Text2SQL 不宜直接从用户问题跳到数据库结构。中间需要建立可治理的指标语义，将业务概念转换为确定的计算约束。模型应优先检索这层定义，再选择字段并组织 SQL；只有语义层没有覆盖时，才考虑从表结构和字段描述中推断。

指标定义之外，还要处理自然语言与数据库取值之间的差异。工程上可维护业务术语表、标准枚举及字段取值映射，再通过 Schema Linking 把问题中的词语连接到候选表、字段和具体值。这样既能减少模型猜测，也能只提供与当前问题相关的数据库上下文。

多表查询还需要单独治理关联关系。字段同名不代表可以连接，名称相似也不能证明业务含义一致。系统可维护经过确认的关联路径，记录主数据标识、关联方向、基数特征和结果去重方式。生成 SQL 时优先使用已登记路径；找不到可信关系时，应停止自动拼接并转入澄清或人工确认，而不是让模型根据列名自行补全 JOIN。

澄清机制是口径治理的一部分，不应被当作交互上的补丁。若问题没有说明日期区间、汇总层次或必要筛选项，直接采用隐含默认值会让结果看似合理，却难以审计。较稳妥的链路是先判断信息是否足够，再提出针对性问题，待用户确认后才进入 SQL 生成。澄清判断与语句生成分开处理，也更便于分别测试：前者检查是否识别歧义，后者检查是否忠实执行已确认的口径。

验收语义层时，不要只验证 SQL 是否运行成功。更有效的检查方式是选取同一业务概念的多种问法，确认它们能否落到同一版本的指标定义；再对容易混淆的时间、区域、用户状态和去重规则做反例测试。只有系统能够说明采用了哪项定义、哪些过滤条件以及哪条关联路径，查数结果才具备复核基础。

六、上线验收：用真实业务问题证明结果可靠

Text2SQL 验收不能等同于模型跑分。公开数据集适合比较基础能力，却无法覆盖企业内部的指标口径、权限边界和数据质量问题。

每道题都要有可复核的基准。基准可以是经审核的 SQL，也可以是固定数据快照下的预期结果；涉及经营指标时，还需记录定义、统计周期、过滤条件和适用组织。只有答案而没有口径，数据变化后便难以判断偏差来自模型、数据还是业务定义。题目、基准和所依赖的数据版本应一并管理，避免评测结果失去可重复性。

所有指标都应明确分母和失败归类。例如，SQL 因权限策略被拒绝，不应直接计入生成错误；用户问题本身缺少时间范围，也不宜按结果错误处理。验收报告应按业务域、查询复杂度和风险等级拆分，否则总体平均值会掩盖局部不可用的问题。

鲁棒性测试要主动制造异常，而不是等待生产环境暴露。测试输入可加入近义说法、输入错误和条件缺失；数据侧应覆盖时间临界点、无匹配记录及重复行；安全与运行侧则应模拟租户隔离、越权请求、大范围扫描和数据库异常。每类失败都要验证系统是拒绝、澄清、降级还是转交人工，并检查返回信息是否泄露表结构或敏感内容。

放量范围应由验收结果决定，不以单一准确率作为上线开关。查询风险较高时，界面应保留生成 SQL、指标定义和关键过滤条件，并在执行或交付结果前加入人工确认。复杂推理能力可以通过候选生成等方法改善，但不能替代权限检查、查询约束和业务复核。

验收集也不是上线前的一次性材料。生产运行后，应持续归集用户改写的 SQL、负面反馈、失败日志以及反复出现的澄清请求，经脱敏和审核后补充到评测集，并同步修订指标词典、参考示例与校验规则。每次模型、提示词、Schema 或口径变更，都应回归同一批核心问题，确认质量提升没有以安全性或稳定性下降为代价。

七、FAQ：企业落地 Text2SQL 前常见的问题

企业是否应该直接让大模型连接生产数据库？

不建议把数据库凭据交给模型，也不应让模型绕过现有的数据访问体系直接执行任意 SQL。模型适合完成意图解析、数据对象匹配和查询草案生成，真正的访问决策与执行应留在可控制的服务链路中。

更稳妥的架构是在模型与数据库之间设置执行层：模型只接触完成任务所需的元数据；执行层根据当前用户的权限处理查询，拦截写操作、越权访问与高风险语句，并对运行时间、扫描范围和返回规模进行约束。对于生产环境，是否允许查询还应取决于数据敏感性和数据库承载能力，而不是取决于模型“认为这条 SQL 没问题”。

技术选型时，应重点确认模型是否支持受控的上下文注入、结构化输出和稳定的工具调用。单次生成效果只是基础条件，无法替代访问控制与执行隔离。

Text2SQL 的准确率达到多少才适合上线？

不存在一个适用于所有企业的统一百分比。离线测试中的平均正确率，无法直接回答系统能否进入业务环境。企业更需要判断：错误发生在哪些问题上，错误能否被识别，以及错误结果会造成什么后果。

验收集应来自真实业务提问，并保留问题对应的统计口径、期望结果和可接受偏差。评估不能只看 SQL 是否与参考答案一致，还要检查查询结果、数据范围、指标定义和权限处理。两条写法不同的 SQL 可能返回相同结果；一条可以正常运行的 SQL，也可能回答了另一个问题。

上线判断应按场景进行。对错误成本较低、答案容易复核的查询，可以采用提示用户确认或展示计算依据的方式开放；涉及经营决策、敏感信息或不可逆操作的场景，则需要更严格的人工复核与拒答机制。关键不是追求一个好看的总分，而是让系统知道何时不能回答。

为什么 SQL 能执行成功，查询结果仍然可能是错的？

数据库执行成功只能证明语句符合语法，并且引用的对象在当前环境中可访问，不能证明它正确理解了业务问题。常见偏差来自指标含义、时间范围、数据版本和关联关系。

表关联同样可能引入重复行，空值处理、退款状态和历史快照也会改变最终结果。

因此，Text2SQL 不能只依赖表名与字段名。企业需要把指标定义、适用范围、数据来源和计算规则整理为机器可检索的语义信息，并让结果页能够说明本次查询采用了什么口径。发现歧义时，系统应先追问，而不是自行补全业务假设。

哪些企业暂时不适合落地 Text2SQL？

如果同一指标在不同部门存在长期争议，核心表缺少明确负责人，字段含义依赖少数员工口头解释，或者现有权限无法映射到查询执行链路，直接上线 Text2SQL 往往只会放大已有的数据问题。

另一个需要谨慎的情况是，业务方无法提供代表性的真实问题，也没有人员负责核对答案。缺少验收基准时，团队只能评价生成的 SQL “看起来是否合理”，无法证明结果是否可用。

这并不意味着必须先完成全面的数据治理。更可行的判断方法是选择边界清楚、口径已有共识且能够人工复核的范围进行验证；如果连这一范围也无法确定，应先补齐数据目录、指标定义、权限规则和责任归属。Text2SQL 的核心交付物不是一个大模型接口，而是一条可约束、可解释、可验收的数据产品链路。