Pinterest的数据用户的核心任务是撰写查询以解决分析问题。然而，在一个快节奏的环境中，涉及大量数据分布在不同领域的情况下，找到正确的数据并将分析问题转化为正确高效的SQL代码可能是具有挑战性的任务。

我们看到大型语言模型（LLMs）的可用性增加为一个机会，我们探索是否可以通过开发文本转SQL功能来帮助我们的数据用户完成这项任务，将这些分析问题直接转化为代码。

在Pinterest Text-to-SQL如何工作

在Pinterest，文本转SQL的工作原理是通过我们自家开源的大数据SQL查询工具Querybook^[1]进行的。这个工具是我们开发和部署新功能以帮助我们的数据用户的自然选择，其中包括文本转SQL功能。

实现Text to SQL

初步版本：一种使用 LLM 的文本到 SQL 解决方案

第一个版本融合了一个简单直接的文本到 SQL 解决方案，利用了一个 LLM。让我们更仔细地审视它的架构：

用户提出了一个分析性问题，选择要使用的表格。

1. 1. 相关的表格模式从表格元数据存储中检索出来。

2. 2. 问题、选择的 SQL 方言和表格模式被编译成一个文本到 SQL 的提示。

3. 3. 这个提示被输入到 LLM 中。

4. 4. 生成一个流式响应并显示给用户。

表格模式

从元数据存储中获取的表格模式包括：

• • 表格名称

• • 表格描述

• • 列

• • 列名称

• • 列类型

• • 列描述

低基数列

某些分析查询，比如“‘web’ 平台上有多少活跃用户”，如果简单地生成，可能会生成与数据库实际值不符的 SQL 查询。例如，响应中的 where 子句可能是 where platform=’web’，而不是正确的 where platform=’WEB’。为了解决这类问题，低基数列的唯一值，通常用于这种过滤的列，被处理并纳入表格模式中，这样 LLM 就可以利用这些信息生成精确的 SQL 查询。

上下文窗口限制

极大的表格模式可能会超出典型的上下文窗口限制。为了解决这个问题，我们采用了一些技术：

表格模式的简化版本：这只包括关键元素，如表格名称、列名称和类型。列修剪：列在元数据存储中被标记，我们根据它们的标记从表格模式中排除某些列。

响应流式传输

LLM 的完整响应可能需要数十秒的时间，为了避免用户等待，我们采用了 WebSocket 来流式传输响应。考虑到除了生成的 SQL 外还需要返回各种信息的需求，一个结构良好的响应格式至关重要。虽然纯文本流式传输简单直接，但流式传输 JSON 可能会更加复杂。我们在服务器上采用了 Langchain 的部分 JSON 解析来进行流式传输，然后解析后的 JSON 将通过 WebSocket 发送回客户端。

提示

这是我们目前用于文本到 SQL 的当前提示^[2]：

评估与收获

我们对文本到 SQL 的初始性能评估主要是为了确保我们的实现在性能上与文献中报告的结果具有可比性，考虑到我们的实现主要使用了现成的方法。我们发现在 Spider 数据集上与其他地方报告的结果相当，尽管我们注意到这个基准测试中的任务要比我们的用户面临的问题要容易得多，特别是它只考虑了少量预先指定的表格，具有少量且标记良好的列。

一旦我们的文本到 SQL 解决方案投入生产，我们也能观察用户如何与系统交互。随着我们实现的改进和用户对该功能的熟悉度增加，我们对生成的 SQL 的首次接受率从 20% 提高到 40% 以上。实际上，大多数生成的查询在最终确定之前需要人工或 AI 多次迭代生成。为了确定文本到 SQL 如何影响数据用户的生产力，最可靠的方法是进行实验。使用这样的方法，先前的研究发现 AI 助手将任务完成速度提高了超过 50%。在我们的真实世界数据中（重要的是没有控制任务差异），我们发现使用 AI 助手编写 SQL 查询的任务完成速度提高了 35%。

第二次迭代：引入 RAG 用于表格选择

尽管第一个版本表现不错 — 假设用户知道要使用的表格 — 但在我们的数据仓库中从数十万个表格中识别正确的表格实际上对用户来说是一个重大挑战。为了缓解这一问题，我们集成了检索增强生成（RAG）来指导用户选择适合他们任务的正确表格。以下是包含 RAG 的优化基础设施的回顾：

1. 1. 一个离线作业用于生成表格摘要和历史查询的向量索引。

2. 2. 如果用户没有指定任何表格，他们的问题被转换成嵌入，并对向量索引进行相似性搜索，以推断出前 N 个适合的表格。

3. 3. 前 N 个表格，连同表格模式和分析问题，被编译成一个提示，供 LLM 选择前 K 个最相关的表格。

4. 4. 前 K 个表格被返回给用户进行验证或修改。

5. 5. 确认的表格后，标准的文本到 SQL 过程被恢复。

离线向量索引创建

在向量索引中有两种类型的文档嵌入：

• • 表格摘要

• • 查询摘要

• • 表格摘要

Pinterest 正在进行一个表格标准化工作，为表格添加分层。我们只索引顶级表格，促进使用这些高质量数据集。表格摘要生成过程包括以下步骤：

1. 1. 从表格元数据存储中检索表格模式。

2. 2. 收集使用该表格的最近样本查询。

3. 3. 根据上下文窗口，尽可能多地将样本查询纳入表格摘要提示中，连同表格模式。

4. 4. 将提示发送给 LLM 以创建摘要。

5. 5. 生成并存储嵌入到向量存储中。

表格摘要包括表格的描述、包含的数据以及潜在的使用场景。以下是我们目前用于表格摘要的提示：

查询摘要

除了在表格摘要中的作用外，与每个表格关联的样本查询也会单独进行摘要，包括查询的目的和使用的表格等详细信息。以下是我们正在使用的提示：

NLP 表格搜索

当用户提出分析问题时，我们使用相同的嵌入模型将其转换为嵌入。然后我们对表格和查询向量索引进行搜索。我们正在使用 OpenSearch 作为向量存储，并利用其内置的相似性搜索功能。

考虑到一个查询可能与多个表格关联，一个单独的表格可能会在相似性搜索结果中出现多次。目前，我们采用了简化的策略来汇总和评分。表格摘要比查询摘要更重要，这种评分策略在未来可能会调整。

除了用于文本到 SQL，这基于 NLP 的表格搜索也用于 Querybook 中的通用表格搜索。

表格重新选择

在从向量索引中检索到前 N 个表格后，我们让 LLM 通过评估问题和表格摘要来选择最相关的 K 个表格。根据上下文窗口，我们在提示中包含尽可能多的表格。以下是我们用于表格重新选择的提示：

一旦表格重新选择完成，它们将返回给用户进行验证，然后过渡到实际的 SQL 生成阶段。

评估与收获

我们使用来自先前表格搜索的离线数据对我们的文本到 SQL 功能的表格检索组件进行了评估。在一个重要的方面，这些数据是不足的：它捕捉了用户在他们知道基于 NLP 的搜索可用之前的行为。因此，这些数据主要用于确保基于嵌入的表格搜索不比现有的基于文本的搜索表现更差，而不是尝试衡量改进情况。我们利用这个评估来选择用于表格检索的方法和设置嵌入的权重。这种方法向我们展示了通过我们的数据治理工作生成的表格元数据对整体性能的重要性：在嵌入中没有表格文档的情况下，搜索命中率为 40%，但性能随着放在表格文档上的权重线性增加，最高可达 90%。

下一步

虽然我们目前实施的文本到 SQL 已显著提高了数据分析师的生产力，但仍有改进的空间。以下是一些进一步发展的潜在领域：

NLP 表格搜索

元数据增强 目前，我们的向量索引仅与表格摘要相关联。一个潜在的改进可能是包含更多元数据，如分层、标签、领域等，以便在检索类似表格时进行更精细的过滤。

定期或实时索引更新

目前向量索引是手动生成的。实施定期或即时更新，每当新表格创建或查询执行时进行更新，将增强系统效率。

相似性搜索和评分策略修订

我们目前用于汇总相似性搜索结果的评分策略相当基础。微调这一方面可能会提高检索结果的相关性。

查询验证

目前，LLM 生成的 SQL 查询直接返回给用户而无需验证，这可能存在查询无法按预期运行的风险。实施查询验证，也许使用受限束搜索，可以提供额外的保障。

用户反馈

引入用户界面，以高效地收集用户对表格搜索和查询生成结果的反馈，可以为改进提供宝贵见解。这些反馈可以被处理并纳入向量索引或表格元数据存储中，最终提升系统性能。

评估

在这个项目中，我们意识到文本到 SQL 在实际环境中的性能与现有基准测试显著不同，后者倾向于使用少量良好规范化的表格（还是预先指定的）。为应用研究人员产生更真实的基准测试将是有益的，其中包括更多的非规范化表格，并将表格搜索视为问题的核心部分。