数据洞察加速器：LLM Copilot 如何让 SQL 查询效率提升 50% 以上？

LLMs 可以充当副驾驶，将人类指令转化为 SQL 查询，向人类解释复杂的 SQL 查询，并提出优化建议以加快计算速度。结果是显而易见的：更快的迭代，降低非技术用户的门槛，以及减少浪费在查找语法上的时间。

瓦罗兰特顶级C位

705人浏览 · 2025-11-08 11:20:20

瓦罗兰特顶级C位 · 2025-11-08 11:20:20 发布

SQL 是数据世界的语言；然而，任何花时间编写查询的人都知道其中的痛苦。记住窗口函数、多表连接的确切语法，以及调试隐晦的 SQL 错误可能既繁琐又耗时。对于非技术用户来说，获取简单的答案往往需要求助于数据分析师。

大型语言模型（LLMs）正在开始改变这种局面。LLMs 可以充当副驾驶，将人类指令转化为 SQL 查询，向人类解释复杂的 SQL 查询，并提出优化建议以加快计算速度。结果是显而易见的：更快的迭代，降低非技术用户的门槛，以及减少浪费在查找语法上的时间。

为什么 LLM 适用于 SQL

LLMs 擅长将自然语言映射到结构化文本。而 SQL 本质上就是具有明确模式的结构化文本。向 LLM 提问：“找出上个季度销量前 5 的产品”，它就可以起草一个使用 GROUP BY（用于不同渠道）、ORDER BY 和 LIMIT（用于获取前 5 名）子句的查询。

除了起草查询之外，LLMs 还可以充当有用的调试伙伴。如果查询失败，它可以总结错误，指出您输入的 SQL 中的错误，并推荐不同的修复方案。它们还可以建议更高效的替代方案，以减少计算时间并提高效率。它们甚至可以将 SQL 问题翻译成纯英语，以便更好地理解。

使用场景

最明显的用例是自然语言到 SQL，它允许任何人表达业务需求并接收查询草稿。但还有很多其他用途。分析师可以粘贴错误代码，LLM 可以帮助调试错误。这位分析师可以分享用于准确调试错误的正确提示，并与同事分享，以节省时间。新手可以依靠副驾驶将 SQL 翻译成自然语言。有了正确的模式上下文，LLMs 可以生成针对组织实际数据库结构定制的查询，这使得它们比通用语法生成器强大得多。

尽管 LLMs 潜力巨大，但它们也有一些已知的限制。最突出的是列幻觉（column hallucination）以及在未提供上下文时生成随机的表名。如果没有正确的模式上下文，LLM 很可能会诉诸于假设并出错。LLMs 生成的查询可能可以执行，但它们可能效率低下，导致成本增加和执行时间变慢。除了所有这些问题之外，还有一个明显的安全风险，因为敏感的内部模式可能会与外部 API 共享。

结论非常简单：LLMs 应该被视为副驾驶，而不是完全依赖它们。它们可以帮助起草和加速工作，但在执行之前，需要人工干预进行验证。

通过提示工程改进 LLM 结果

提示工程是学习有效使用 LLMs 最关键的技能之一。对于 SQL 副驾驶来说，提示是一个关键杠杆，因为模糊的提示往往会导致不完整、错误，有时甚至是毫无意义的查询。通过提供正确的模式上下文、表列信息和描述，输出查询的质量可以显着提高。

除了数据模式信息，SQL 方言也很重要。所有 SQL 方言，如 Postgres、BigQuery 和 Presto，都有细微的差异，向 LLM 提及 SQL 方言将有助于避免语法不匹配。对输出的细节描述也很重要，例如：指定日期范围、前 N 个用户等，以避免不正确的结果和不必要的数据扫描（这可能导致昂贵的查询）。

根据我的经验，对于复杂的查询，迭代提示（iterative prompting）效果最好。先要求 LLM 构建一个简单的查询结构，然后逐步细化效果最佳。您也可以使用 LLM 在提供最终 SQL 之前解释其逻辑。这对于调试和指导 LLM 关注正确的方面非常有用。您可以使用少样本提示（Few-shot prompting），即在要求 LLM 生成新查询之前向其展示一个示例查询，以便它有更多的上下文。最后，错误驱动提示（error-driven prompting）有助于最终用户调试错误消息并获得修复。正是这些提示策略区分了“几乎正确”的查询和实际可运行的查询。

您可以从下面的示例中看到这一点，其中一个模糊的提示导致了列名幻觉。相比之下，一个经过精心设计、更详细的提示，您会得到一个定义良好、匹配所需 SQL 方言且没有幻觉的查询。

最佳实践

在使用 SQL 副驾驶时，可以遵循一些最佳实践。始终建议在运行查询之前进行人工审查，尤其是在生产环境中。您应该将 LLM 输出视为草稿而不是最终输出。其次，集成是关键，因为一个与组织现有 IDE、Notebooks 等集成在一起的副驾驶将使其更具可用性和效率。

安全与风险

SQL 副驾驶可以带来巨大的生产力提升，但在组织范围内推广它们之前，我们应该考虑一些风险。首先是过度依赖的担忧；副驾驶可能导致数据分析师严重依赖它，而从不构建核心 SQL 知识。这可能导致潜在的技能差距，即团队可以创建 SQL 提示，但无法排除故障。

另一个担忧是数据治理。我们需要确保副驾驶在没有正确权限的情况下不会与用户共享敏感数据，从而防止提示注入攻击。组织需要建立正确的数据治理层，以防止信息泄露。最后，还有成本影响，频繁调用副驾驶 API 可能导致成本快速累积。如果没有正确的用量和令牌策略，这可能会导致预算问题。

评估指标

在投资 LLMs 用于 SQL 副驾驶时，一个重要的问题是：你如何知道它们正在发挥作用？ 你可以从多个维度来衡量副驾驶的有效性，例如正确性、人工干预率、节省的时间和重复支持请求的减少。

正确性是一个重要的指标，用于确定在 SQL 副驾驶提供了一个没有错误运行的查询时，它是否产生了预期的正确结果。这可以通过抽取提供给副驾驶的输入样本，并让分析师起草相同的查询来比较输出来实现。这不仅有助于验证副驾驶的结果，还可以用于改进提示以提高准确性。除此之外，这个练习还会为您提供每次查询节省的估计时间，有助于量化生产力提升。

另一个简单的衡量指标是无需人工编辑即可运行的生成查询的百分比。如果副驾驶持续生成可工作的可运行查询，它们显然在节省时间。一个不那么明显但强大的衡量标准是非技术人员重复支持请求的减少。如果业务团队能够使用副驾驶更多地自助解决他们的问题，数据团队就可以花更少的时间回答基本的 SQL 请求，将更多时间专注于高质量的洞察和战略方向。