任何文本到 SQL 基准测试都应该解决现实世界数据存储的困难

【HN用户评论摘要】 如果你正确设计系统，文本到 SQL 绝对可以工作。我承认单次射击是一条死胡同。然而，如果您运行具有并行假设生成、多个外循环等功能的研究代理，那么您遇到正确查询的机会就会大大增加。该游戏旨在迫使主管比较两个试图完成相同报告但结果不同的查询。让人类操作员参与到这个循环中就可以完成剩下的工作。 业务用户（不懂 SQL）使用 LLM 编写 SQL 的最大问题是没有人验证该查询，而现在业务用户会将 LLM 响应视为在会议、演示和与客户中共享的规范。 LLM 可能忘记了过滤器，使用了错误的收入定义，或者通过编写以最字面的方式回答用户问题的查询来误解用户的意图。这就是问题的关键。没有多少语义层和内容 有趣的是......在我目前的工作中，我和我的团队正在解决如何确保 LLM 理解我们的 SQL 数据仓库来回答客户的分析问题的问题。正如博客文章所述，我们有一个已有 20 年历史的数据库，其架构已经腐烂。因此，我们必须以结构良好、管理良好的方式重建数据库。完成这项艰苦的工作后，我们将 dbt 模型置于业务指标之上，并使用模型 YAML 文件（和一些常见的 MD 文件）携带大量语义和元数据 FCO-IM 优雅地弥合了数据和语言之间的差距。有没有人尝试/比较过基于此的 SQL 查询生成？ SQL 生成非常好，90% 的问题是数据质量。您可以为数据代理做的最好的事情是围绕您的特定所需用例构建一个干净的前台 - 具有非常清晰的文档和建立在清晰市场上的明显惯用连接模式。这是一项艰苦的工作，但我已经这样做了一段时间，这是唯一的方法。完全自上而下的重建很少可行，可能需要数年时间。我的建议是专注于重建基础层并引入版本化模式/m 原始链接：https://cacm.acm.org/blogcacm/if-you-think-you-can-do-real-world-text-to-sql/