隐藏表拦不住Text-to-SQL？schemagate检索器实测反击

论文揭示的困境：告诉模型“不能看”，它偏要答

据 Reddit 用户分享，一篇 SIGMOD'27 论文《Benchmarking Text-to-SQL under Role-Based Access Control》（arXiv 2607.22115）提出了一个反直觉的发现：在基于角色的访问控制（RBAC）下，仅向模型展示其有权查看的列，并不能阻止 Text-to-SQL 代理回答问题。如果答案需要隐藏列，正确的做法是拒绝作答，但模型仍会利用可见部分拼凑出一个答案。

论文在 BIRD 数据集上测试了纯 schema 过滤的最佳配置，结果仍有约 27% 本应拒绝的问题被回答了。这个数字意味着，传统的“隐藏受限表”策略在安全边界上存在显著漏洞——模型并不理解“缺失即禁止”，反而会基于不完整信息进行推测。

RBAC（基于角色的访问控制） 是一种在数据库和企业系统中广泛使用的权限模型：系统为每个用户分配一个或多个角色，每个角色绑定一组可访问的表、列或行，用户只能看到其角色被授权的数据子集。在 Text-to-SQL 场景中，RBAC 意味着同一个自然语言问题，对不同角色可能产生"可回答"和"应答"两种合法结果——例如财务角色能查询薪资列，而普通业务角色即使问同一问题也必须被告知无权获取。因此，Text-to-SQL 代理不仅要生成正确 SQL，还要判断当前角色是否有权覆盖回答问题所需的信息，这正是论文所考察的安全边界。

AC-F1 是该论文评估中使用的核心指标，通常指"准确率（Accuracy）与合规性（Compliance）的综合 F1"：只有当模型的输出既在语义上正确、又符合角色权限约束（该答的答对、该拒的拒答）时才计为正确。这使得单纯"答对问题"不够，乱答被禁止的问题或错误拒答都会拉低分数。理解这一指标有助于判断 schemagate 的 90.1 与论文 88.1 之间差距的实际含义。

schemagate 的回应：从“被动隐藏”到“主动防御”

schemagate 的维护者（即原帖作者）将自家检索器放到了论文的评估器中，使用与论文最佳运行相同的模型 Claude Sonnet 4.5，进行了 5 次试验。schemagate 本身是一个为 SQL 代理执行 schema 过滤的检索器 / MCP 服务器，与论文场景高度契合。

结果显示，在 BIRD 数据集上，schemagate 的 AC-F1 达到 90.1，而论文中 13 个模型的最佳成绩为 88.1（该模型能看到完整 schema 和策略）。在 Spider 数据集上，schemagate 与同模型得分持平，均为 93.0；但论文在 Spider 上的最佳成绩来自 DeepSeek^广告 V3.2-Reasoning，达到 95.9，schemagate 在此仍有差距。两个数据集上，实际读取禁止列的查询数均为 0。

这一对比表明，在相同模型下，schemagate 的检索策略在 BIRD 上优于论文中让模型直接看全量 schema 加策略的做法，同时在安全违规上保持了零记录。

MCP（Model Context Protocol）服务器 是一种向大模型客户端暴露工具与数据源的标准化接口协议。将 schema 过滤实现为 MCP 服务器，意味着模型在生成 SQL 前通过该服务器检索可用的表与列元数据，服务器在检索阶段就完成权限裁剪，而不是把全量 schema 交给模型后再依赖其自觉遵守策略。这种架构把"权限边界"前移到数据供给环节，与论文中"展示可见列并期望模型理解缺失即禁止"的做法形成对照。

Claude Sonnet 4.5 是 Anthropic 推出的中高端推理模型，在代码与结构化生成任务上表现较强，常被用作 Text-to-SQL 基座。schemagate 选择与论文最佳运行相同的模型进行对比，是为了排除模型能力差异，把差异归因于检索与提示策略本身，这也是该复现实验在方法论上较有说服力的原因。

两个关键改进：提示词与策略校验

schemagate 与普通 schema 过滤的差异主要体现在两处。第一，在提示词中加入一句话：“你看到的是这个数据库的一部分，如果需要更多信息就拒绝作答。”这句话没有点名任何隐藏内容，但在 100 道问题的试点中，将错误答案从 16% 降到了 5%。第二，对每个生成的查询在执行前进行策略校验，移除这一步骤会使违规率翻倍。

作者也给出了局限性：仅测试了一个模型，提示词措辞是在 100 道 BIRD 问题上选定的；去掉这两个因素后分数基本不变（90.08），说明改进并非依赖特定措辞的偶然效果。

对 LangChain SQL 代理的实践启示

原帖作者在结尾提问：是否有人在 LangChain SQL 代理中做按用户的 schema 过滤，以及如何处理“模型仍然作答”的问题。这个问题指向了当前 Text-to-SQL 落地中的一个普遍痛点——多数框架默认信任模型会遵守权限边界，但论文和 schemagate 的实测都表明，模型倾向于“能答就答”。

对于构建企业级 SQL 代理的团队，可借鉴的思路包括：在检索层做 schema 裁剪，在提示层明确声明信息不完整，在生成后增加策略校验作为最后一道闸门。三者叠加，才能将“隐藏受限表”从一种假设转化为可验证的防线。

完整结果与复现方式见作者提供的 GitHub 仓库 BENCHMARKS.md。

LangChain SQL 代理 是 LangChain 框架中用于连接关系数据库、将自然语言转为 SQL 并执行的一类组件，常见实现包括 SQLDatabaseToolkit 与基于 agent 的查询链。默认情况下，它会把数据库的 schema 信息注入提示词，并允许模型自行决定查询哪些表和列。要在其中实现按用户的 schema 过滤，通常需要自定义工具层：在构造提示词前按角色裁剪表/列清单，并在执行前对生成 SQL 做解析与权限校验（例如检查 FROM/JOIN 与 SELECT 中是否出现未授权对象），而不是仅依赖提示词中的"请勿访问"说明。