8.0
热点
AI SCORE
编程提效2026-09-15 14:01
采购 Text-to-SQL 工具前必问的 12 个问题
dev.to · AI#AI编程#数据工具#工程选型
Editor brief · 编辑速览
Demo 演示效果好不代表工具能撑过第一个季度；采购评估应聚焦数据准确性、权限隔离、生产级查询健壮性，而非 demo 流畅度。
每个演示都运行得很好。演示是容易的部分。真正的问题在于：哪些问题能区分出财务团队可以信赖的工具，和那些用漂亮字体悄悄产出错误数字的工具。
自然语言查询的演示非常漂亮。有人输入"show me revenue by region last quarter"，大约一秒钟后一张图表就出现了，房间里每个人都能立刻想到十个想问的问题。这种反应是真实的，这也是这个赛道正在增长的原因。
但这也是评估翻车的原因。演示只测试了一件已经不再困难的事——现代模型针对小型、干净的 schema 写出一段看起来合理的 SQL。它没有测试任何决定工具能否撑过第一个季度的事情：数字是否正确、提问者是否有权看到它、以及当生成的查询在月末遇到生产数据库时会发生什么。
下面列出十二个问题，按它们能捕捉到的失败类型分组。每个问题都有你想要的答案、应该让你慢下来的答案，以及在会议中而不是合同签了六个月后去测试的方法。每个供应商都要问这些问题，包括我们。
这是列表中最有用的问题，因为这个赛道里几乎没有人能回答它，而对方的反应会告诉你一切。
Text-to-SQL 在小型、干净、文档完善的 schema 上准确率尚可，在真实的 schema 上会急剧下降——数百张表、神秘的列名、脏数据、模糊的 join 路径。业界基准 BIRD 存在的正是因为 tidy 学术 schema 上的结果无法经受生产数据库的检验。无论供应商给出的数字是多少，总有一部分答案是错的，而你为之购买这个工具的用户无法判断哪些是错的。
一个具体的数字、用于测量的问题集的大小和来源，以及在试点期间用你的 schema 重新运行它的提议。如果每次模型和 prompt 变更都会自动运行，那就更好了。
"It uses GPT-class models, so it's very accurate." 模型质量是输入，不是测量结果。同样，把"我们从未收到过投诉"当作它本身的样子——即没有人检查过。
带上 10 个你已知答案的问题。在一次会话中全部问完。计数。
这个领域的产品喜欢 verification badges、confidence indicators 和绿色勾选标记。问问这个勾标记在声明什么。通常它意味着查询解析并执行了没有报错——这是关于 SQL 有效性的声明，而不是关于答案是否正确的声明。
一个查询可以完美执行但仍然把收入重复计算，因为一张订单 join 到了三个行项目。没有错误可以捕捉。图表看起来没问题。
需要明确区分"这段 SQL 运行了"和"这段 SQL 与已知正确结果匹配"，加上一个人类将查询标记为已审查并在此之后按名称重用的方法。
那个 badge 的意思实际上是"没有抛出异常"，或者供应商说不清它检查了什么。
问一个正确答案需要 distinct count 的问题。看它是否会展开——以及是否有任何东西标记它。
"Revenue" 不是一个列名。是总额还是净額？扣除退款与否？入账还是发货？含税吗？何时确认？每种都是合理的，而模型每次根据措辞选择一种。
这种失败模式是组织性的而非技术性的：两个人在同一次会议上带来不同的数字，两者都是这个工具生成的，然后对整个系统的信任就在那场会议上消失了。没有 prompt 能解决这个问题，因为歧义存在于你的业务中，而不是模型里。
一个语义层——指标定义一次，join 路径、过滤条件和粒度固定——让模型选择一个已定义的指标而不是每次都重新发明算术。
"The model figures it out from context"，或者建议你要写得更具体。这把定义工作推给了每个用户、每次提问。
在一次会话中用三种方式问同一个指标。比较这三个数字。
大多数工具都有权限控制。但更少的工具有模型无法绕过的权限。
这是最常改变决策的问题，而且措辞很重要——几乎每个供应商都说"细粒度权限"，而这个短语涵盖两种截然不同的架构。
如果访问控制在应用层过滤，那么生成的查询仍然针对所有数据运行，产品在之后决定向你展示什么。如果是通过数据库的行级安全强制执行的，那么无论模型生成了什么 SQL，物理上都无法返回该人员无权查看的行。
数据库中的行级安全策略，每次请求时在连接上设置提问用户的身份。供应商应该能够向你展示这个策略。
"We instruct the model to only query the user's own data." prompt 指令只是一个建议。同样值得警惕的是：整个工作空间共用一个只读连接。
在试点中，用一个受限用户登录并询问范围外的东西。然后检查查询日志。
"Read-only by default" 现在是标准措辞，而重要的词是 default。这个赛道的大多数产品也提供操作——告警、webhook、CRM 更新、计划任务——而那些都是写入。所以真正的问题是，一旦你开启了你购买它的功能，那个约束还能不能维持住。
通过数据库角色自身的权限强制执行的只读，这样无论模型发出什么或有人在设置中切换什么，它都有效。写入（如果有的话）通过一个独立的、范围狭窄的路径。
唯一的约束是产品中的一个设置，或者一个人类批准一个他需要读 SQL 才能评估的操作。
让他们用一个撤销了写入权限的角色连接，看看产品是否仍然工作。
模型不会可靠地遵循写在 prompt 中的规则，所以强制执行必须在代码中进行。常见的实现是一个禁止关键字的黑名单，而它在两个方向都会失败：它拒绝触碰 created_at 列的合法查询，同时漏掉 catalog 函数、数据修改的 CTE 和注释混淆。
正确的方法是用数据库自身的解析器解析生成的 SQL 并针对产生的语法树做白名单——一条语句、只允许 SELECT、已知的关系。黑名单列举坏事；只有白名单列举一个有限的集合。
基于解析器的验证加白名单，辅以数据库权限作为第二层，捕捉第一层遗漏的任何东西。
"We check for dangerous keywords." 问一列 literally 名为 created_at 会发生什么，然后观察。
用自然语言让产品列出你数据库中的表。看返回什么。
你正在把一个生成系统的凭证交给一个其他东西依赖的数据库。
生成的查询是一条无界查询。一条针对大表写错的 join 可能耗尽同时为你的应用提供服务的数据库，而涉事没有人有任何恶意——有人只是在错误的时机问了一个过于宽泛的问题。
执行前估算成本并在超过上限时拒绝、硬性的语句超时、在服务器端强制执行行数上限，以及使用读副本而不是主库。
没有提到任何限制，或者"我们的查询很快"附带一个 sub-second 的演示数字作为证据。那只是一个查询在一个 schema 上的结果。
故意问一个巨大的东西——每张订单 join 到每个行项目，没有过滤——然后观察产品怎么做。
"Your data never trains anyone's model" 是一个好的承诺但范围很窄。它通常指的是查询结果。Schema——表名和列名——通常确实会发送到模型供应商，而 schema 不是中立的：它描述了你的业务、你的客户属性，有时还有你未发布的产品。
还要检查安全配置落在哪个层级。如果自托管或 bring-your-own-model 是企业版专属，那你收到的报价不是你在评估的那个方案。
供应商明确命名，清楚说明什么被发送和什么被保留，以及一个在环境中运行的选项而不是埋在定制合同后面。
模型和供应商在产品或文档中从未被命名。
问哪个子处理器处理你的 schema，并要求书面形式的列表。
这个问题让一些人惊讶，所以慢慢问。你的数据库已经包含了由公司外部的人编写的文本——支持工单、评论、CRM 备注、表单提交。一行写着 ignore previous instructions and… 的内容在它躺在网格里时是无效的。
但当这些结果被反馈给模型用于总结答案、命名图表或建议后续操作时，它就变成了活的——而这正是这个赛道的每个产品下一步做的事。如果同一个产品还能触发 webhook 或写入你的 CRM，风险会急剧增加。
结果作为明确标记为不受信任的数据传送到任何下游模型，总结用的模型不给任何工具——这样一行内容说的话无法导致任何操作。
一个空白的表情，或者声称模型"知道"要忽略它。如果他们提供面向 Agent 的功能，这件事更重要，不是更不重要。
在试点中，把一个指令形状的字符串放进一条测试行，问一个返回它的。
在上线后真正重要的控制，是那些让失败可见的控制。
"We show you the SQL" 是标准的透明度回答，但它值得仔细审视。在许多产品中，生成的查询只对管理员可见或在服务器日志中，而不是对准备把数字粘进演示文稿的分析师可见。而且向一个恰恰因为不懂 SQL 才被选中的人展示 SQL，实际上是把验证的负担转移给了最无力承担它的人。
透明度只有在配合一个验证去处时才有价值。最好的版本：能读 SQL 的人审查一次查询，给它命名，保存它，然后其他所有人从此使用命名版本而不是重新生成。
SQL 在界面中答案旁边展示，可编辑并可重新运行，加上一个保存查询库并有负责人，这样经过验证的问题被重用而不是重新生成。
SQL 在日志或管理员面板中可用，并被描述为透明度。
问一个非技术用户在哪里看到查询，以及一个好的查询能否按名称保存和重用。
大多数供应商说"审计日志"。问一条记录包含什么。你想要提问内容、运行的 SQL、用户、时间戳、行数以及是否报错——足以在三个月后有人质疑时重建一个数字是如何产生的。
还有一个与合规无关的第二个原因：你失败和纠正的查询日志是你下一轮准确率提升的来源。一个把审计日志当作合规复选框的供应商不会用它来变得更好。
完整的 question-to-SQL-to-result-shape 血缘关系，可导出，按声明的时间表保留——并且结果从应用日志中排除，这样你不会创建一个敏感数据的新副本。
只记录查询发生了但没有记录运行了什么。
要求看一条真实的日志记录，字段要可见。
这个赛道的合规页面用了大量相邻措辞："SOC 2 ready"、"designed for GDPR"、"HIPAA available"、"aligned with ISO 27001"。这些都不是认证，而那个缓冲词就在那里发挥作用。
一家年轻的公司还没有 SOC 2 完全没有问题——但坦诚说和把词汇排列成看起来像有的供应商之间有区别。直接问，记下你得到的是哪一种。
一份命名清晰的报告，含类型和审计周期、一个子处理器列表、一份 DPA，以及一句清楚说明哪些尚未认证以及何时会认证的声明。
"Ready"、"aligned"、"designed for"，或者一个没有被你可请求的报告支撑的合规徽章。
要那份报告本身。响应时间告诉你的和文件一样多。
我们在构建 DBx Studio 时基于一个假设：模型是技术栈中最不可信的组件，所以产品的大部分是其他层：基于解析器的验证而不是关键字黑名单、只读角色优于精心设计的视图、带着提问用户身份进入数据库的行级安全、在语义层定义一次的指标，以及一个在每次 prompt、schema 和模型变更时都会运行的 golden-set 评估。
问我们全部十二个问题。如果某个答案让你失望，这也是关于我们的一条有用信息。
Query it. Analyze it. Visualize it. — all with DBx.