5 篇博文 含有标签「sql」

一个支持团队向他们的新 AI 助手提了一个简单的问题：“上周有哪些企业客户提交了工单？”助手给出了一个自信、流利的回答，列出了六个账户。其中五个是正确的。有一个客户在两个月前就已经流失了，而另一个提交了三个工单的企业账户却完全遗漏了。直到一次续约会议谈崩了，才有人发现这个问题。

错误不在于模型，而在于架构。在设计评审的某个环节，一个带有硬性谓词（如方案层级、日期范围、工单计数）的问题被路由到了向量索引。团队因为拥有检索系统，所以就选择了检索。他们将工单记录向量化，将问题向量化，然后试图让余弦相似度（cosine similarity）来完成 WHERE 子句的工作。它做不到，也从来都做不到。

这是生产环境 AI 系统中最常见且讨论最少的故障模式之一：当真正的查询是关系型时，却动用了语义搜索。数据明明整齐地存储在带有外键的行中，答案本可以通过一个 JOIN 轻松获得。结果却经过了嵌入模型，导致精度化为乌有。

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

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

Text-to-SQL 演示看起来出奇地简单：把 schema 粘贴到提示词里，向 GPT-4 提个问题，拿到一条整洁的 SELECT 语句，然后 Slack 里就开始涌现"要不要把这个集成进数据平台？"的消息。等到你真正打算上线时，麻烦来了。基准测试显示 85% 的准确率，但内部数据团队反映大约一半的答案是错的，而安全团队则在追问：生成的查询在执行前有没有经过审查？没人能给出一个像样的答案。

这正是 text-to-SQL 作为研究问题与作为工程问题之间的鸿沟。研究问题关注的是让模型生成语法正确的 SQL；工程问题面对的是 schema 歧义、访问控制、查询验证，以及你的企业数据库根本不像 Spider 或 BIRD 数据集这一现实。

Spider 基准测试看起来很棒。GPT-4 在数百个测试查询中的 text-to-SQL 转换得分超过 85%。团队看到这些数字，配置好 LangChain 的 SQLDatabaseChain，然后上线“询问你的数据”功能。两周后，一位分析师关于按地区划分收入的无心提问触发了全表扫描，导致报表系统宕机 30 分钟。

基准测试数字是真实的。问题在于，基准测试不使用你的模式 (schema)。

Spider 1.0 在包含 5–30 个表和 50–100 个列的数据库上测试模型。而你的生产数据仓库有 200 个表、700 多个列，根据你查询的系统有三种 SQL 方言，以及在四年前编写代码的工程师看来有意义，但对其他任何人来说都毫无意义的列名。当研究人员推出 Spider 2.0——一个具有企业级规模 schema 和现实复杂性的基准测试时——GPT-4o 的成功率从 86.6% 下降到 10.1%。这种断崖式下跌才是生产环境的真实写照。

大多数构建智能体（agent）的团队将数据库模式（schema）视为后端关注的问题。这种模式是由工程师为工程师设计的，遵循了数十年关系型数据库的最佳实践：积极规范化、避免冗余、拆分引用表、强制执行外键。这种方法对于联机事务处理（OLTP）系统是正确的，但对于 AI 智能体来说通常是错误的。

当智能体读取你的模式以确定如何回答问题时，它并不是在解析数据结构，而是在构建你业务的心智模型。如果你的模式是为已经理解该领域的应用程序代码构建的，那么智能体将根据为别人绘制的地图进行工作。结果就是幻觉式的联接、错误的聚合，以及原本只需两步却需要八步的工具调用链。