Text-to-SQL 基准测试难在真实数据
Any text-to-SQL benchmark should address difficulties of real-world data stores
Text-to-SQL 技术在实验室里表现优异，但一旦面对真实世界的数据库，往往就原形毕露。现有的基准测试大多基于简化、干净的数据集，完全忽略了现实场景中普遍存在的脏数据、复杂模式和不规范命名。如果无法解决这些实际困难，再先进的模型也难以落地。真正的挑战不在于生成语法正确的 SQL，而在于理解混乱且充满陷阱的真实数据存储。
任何 Text-to-SQL 基准测试都必须正视真实世界数据存储所面临的困难。
HN 评论区
21- fivetenpen
业务用户（不懂 SQL）用 LLM 写 SQL 最大的问题在于：没人能验证这条查询是否正确。结果，这些业务用户就会把 LLM 的回复奉为圭臬，拿去开会、做演示、发给客户。LLM 可能漏掉了某个过滤条件，用错了营收的定义，或者因为过于字面地理解用户意图而写出了答非所问的查询。
这才是问题的核心。除非 LLM 能读懂用户的心思以消除提示词中的歧义，否则再多的语义层和上下文也无济于事。
在我看来，LLM 的大部分好处应该是让懂 SQL 的数据分析师能更高效地工作。
- programmertote
挺有意思……在我现在的公司，我和团队正在解决如何让 LLM 理解我们的 SQL 数据仓库，以便回答客户的分析类问题。正如博客文章所述，我们有一个 20 年历史的数据库，架构已经烂透了。所以我们不得不以结构良好、治理规范的方式重建数据库。一旦完成这项艰巨的工作，我们就在业务指标之上覆盖 dbt 模型，利用模型 YAML 文件（以及一些通用的 MD 文件）来承载大量的语义和元数据信息。
然后，我们的软件工程团队会导入 dbt 模型（我们必须策略性地创建 dbt 模型；也就是说，在实现时始终思考“怎么做才能让 LLM 少产生幻觉”）以及语义层的信息，为 LLM 构建上下文，并用它来回答分析类问题。到目前为止，前景令人鼓舞。不过准确率也并非像博客作者暗示的那样为零。上个季度，我们在 dbt 和语义层中构建了大约 30 个指标，并让研究和数据分析团队对 LLM 应用进行了内部测试。我很快就能从反馈中得知这种方法的准确程度。
- data-ottawa
SQL 生成本身其实相当不错，90% 的问题出在数据质量上。
你能为数据智能体做的最好的事，就是围绕你特定的目标用例构建一个干净的前端层——拥有非常清晰的文档，以及建立在清晰数据集市之上的、显而易见的惯用连接模式。这很费力，但我做了一段时间了，这是唯一可行的路。
全面自上而下的重建很少可行，而且可能耗时数年。我建议专注于重建基础层，并引入版本化的架构/模型方法（以隔离破坏性变更）。即使这会引入数据和计算冗余，将销售报表从 customers_v1 迁移到 customers_v2 也比评估“当从 customers 表中移除 salesforce id 作为主键时，所有下游依赖会发生什么”要容易得多。