如何利用 Looker 建模语言数据与 Amazon Bedrock 生成 SQL 机器学习博客
Twilio 使用 Looker 建模语言和 Amazon Bedrock 生成 SQL 查询
关键要点
Twilio 通过与 AWS 合作，开发了一个虚拟助手，帮助数据分析师从数据湖中获取所需数据。该助手将自然语言问题转换为 SQL 查询，提升了数据检索的效率和准确性。解决方案采用了 RAG 方法，结合了 Looker 的元数据，提高了用户体验。该工具使用 Amazon Bedrock 和 Claude 3 大语言模型，从而提升了生成 SQL 查询的能力。今天的领先公司信任 Twilio 的客户参与平台CEP，用于在全球范围内建立与客户的直接和个性化关系。Twilio 允许公司利用通信和数据，在销售、营销、客户服务等客户旅程的每个环节中添加智慧和安全性。全球 180 个国家数百万开发者和数十万企业利用 Twilio 为客户创造个性化体验。作为 AWS 最大的客户之一，Twilio 利用数据、人工智能AI和机器学习ML服务来处理每日的工作负载。
数据是所有生成式 AI 和 ML 应用的基础层。在管理和检索合适信息时，尤其是对于处理大型数据湖和复杂 SQL 查询的数据分析师来说，任务可能会很复杂。为了解决这一问题，Twilio 与 AWS 合作开发了一个虚拟助手，帮助数据分析师通过将自然语言的问题转换为 SQL 查询，从其数据湖中查找和获取相关数据。这个虚拟助手工具使用了 Amazon Bedrock，一个全面管理的生成式 AI 服务，可以访问高性能的基础模型FMs和像 检索增强生成RAG这样的能力。RAG 通过为模型扩展到特定领域或组织的内部数据，优化语言模型输出，为用户提供更量身定制的响应。
本文将重点介绍 Twilio 如何利用 RAG 和 Amazon Bedrock，实现自然语言驱动的商业智能BI数据探索。
Twilio 的用例
Twilio 希望提供一个 AI 助手，帮助数据分析师在其数据湖中查找数据。他们利用其数据报告工具 Looker 的元数据层架构信息，作为真实来源。Looker 是一个企业平台，用于 BI 和数据应用，帮助数据分析师实时探索和分享洞察。
Twilio 使用 Anthropic Claude 3 在 Amazon Bedrock 上实现 RAG，开发了一种名为 AskData 的虚拟助手工具，供数据分析师使用。该工具将数据分析师用自然语言提出的问题例如：“哪个表包含客户地址信息？”转换为 SQL 查询，使用来自 Looker 建模语言LookML模型和视图的架构信息。分析师可以直接运行生成的 SQL，从而节省了识别相关信息所在表和编写 SQL 查询的时间。
AskData 工具为其用户提供了便捷和效率：
用户需要迅速、准确的信息，以便做出业务决策。提供工具来减少他们寻找表和编写 SQL 查询所花费的时间，使他们可以更多地专注于业务成效，而不是后勤任务。当用户对嵌入数据湖的深层数据有疑问，无法通过各种查询访问时，通常会求助工程支持渠道。拥有一个 AI 助手可以减少响应这些查询所需的工程时间，并更快地提供答案。解决方案概述
在本文中，我们将逐步介绍 AskData 工具的实施和设计，使其成为 Twilio 数据分析师的 AI 助手。我们将讨论以下内容：
如何使用 RAG 方法，根据用户的问题检索相关的 LookML 元数据，并从自然语言生成 SQL 查询。如何从 Amazon Bedrock 中选择适合您用例的最佳大型语言模型LLM。分析师如何使用自然语言问题查询数据。使用 RAG 进行数据分析的好处，包括提高生产力和减少查找数据表及编写 SQL 查询所需的工程开销。该解决方案使用了 Amazon Bedrock、Amazon 关系数据库服务Amazon RDS、Amazon DynamoDB和 Amazon 简单存储服务Amazon S3。以下图示展示了解决方案的架构。
工作流程包括以下步骤：
终端用户数据分析师用自然语言提出关于数据湖中数据的问题。此问题利用存储在 Amazon RDS 的元数据架构信息和存储在 DynamoDB 的会话历史记录，进行个性化检索：RDS 数据库PostgreSQL 和 pgvector以嵌入格式存储 LookML 表和视图，通过向量相似度搜索进行检索。DynamoDB 表存储该用户的先前会话历史记录。上下文和自然语言问题通过 Amazon Bedrock 结合基础模型在此案例中为 Anthropic Claude 3 Haiku解析，形成个性化的 SQL 查询，用户可以利用此查询准确地从数据湖中检索信息。以下是生成 SQL 查询所用的提示模板：
人类 以下上下文信息代表 LookML 数据、Looker 视图和模型。请使用此上下文数据生成一个将在用户问题中返回正确结果的 presto SQL 查询。请提供一个语法正确的 SQL 查询，包括表名和基于提供的 LookML 数据的列名。
lt指令gt
使用正确的基础 SQL 表名在 sqltablename 中的表名和列名使用视图中的维度列名，因为它们是正确的列名。请使用以下示例：{{示例已删减}}
必要时联接表以获取正确结果。
如未明确请求，请避免不必要的联接。
如未明确请求，请避免不必要的过滤。
如果视图有派生表，请使用派生查询来回答问题，并使用派生查询中的表名和列名。请使用以下示例：{{示例已删减}}
在 LookML 视图中，架构名称表示为 。如果未指定架构名称，则使用现有架构名称或“public”作为架构名称。
lt/指令gt
这是先前消息的聊天历史记录：
lt聊天历史记录gt
{chathistory}
lt/聊天历史记录gt
lt上下文gt
{context}lt/上下文gt
这是用户的问题：
lt问题gt
{question}
lt/问题gt
助手 这是用户问题的 SQL 查询：
这个解决方案主要包括四个步骤：
在 LookML 元数据中使用语义搜索，检索与用户问题相关的表和视图。利用 Amazon Bedrock 上的基础模型生成准确的 SQL 查询，基于检索到的表和视图信息。使用 LangChain 和 Streamlit 创建一个简单的 Web 应用程序。使用战略方法优化现有应用程序，例如 提示工程、优化 推断参数 和其它 LookML 内容。前提条件
要实现该解决方案，您应该拥有一个 AWS 账户，以及访问您选择的 Amazon Bedrock 基础模型的 模型访问权限，并且熟悉 DynamoDB、Amazon RDS 和 Amazon S3。
默认情况下，无法访问 Amazon Bedrock 的基础模型。要访问某个模型，需要具有 AWS 身份和访问管理IAM权限的 用户通过 Amazon Bedrock 控制台提交访问请求。请求模型访问后，该模型会在账户中可供用户使用。
要管理模型访问，请在 Amazon Bedrock 控制台的导航窗格中选择模型访问。模型访问页面可让您查看可用模型列表、模型输出类型、您是否已获批访问及最终用户许可协议EULA。在请求访问模型之前，您应查看 EULA 以了解使用模型的条款和条件。有关模型定价的信息，请参阅 Amazon Bedrock 定价。
结构与索引数据
在本解决方案中，我们使用 RAG 方法从 LookML 元数据中检索与用户问题相关的架构信息，然后基于该信息生成 SQL 查询。
该解决方案在我们的向量存储中创建了两个独立的集合：一个用于 Looker 视图，另一个用于 Looker 模型。我们使用 sentencetransformers/allmpnetbasev2 模型创建向量嵌入，并使用 PostgreSQL 和 pgvector 作为我们的向量数据库。只要 LookML 文件不超过用于生成最终响应的 LLM 的上下文窗口，我们就不将文件分块，而是将文件整体传递给嵌入模型。向量相似度搜索能够找到包含 LookML 表和视图的正确文件，相关于用户问题。我们可以将整个 LookML 文件内容传递给 LLM，利用其大的上下文窗口，使 LLM 能够选择数据库中相关表和视图的架构以生成 SQL 查询。
这两个 LookML 元数据子集提供了有关数据湖的不同类型信息。视图表示单个表，模型定义了这些表之间的关系。通过将这些组件分开，我们可以首先根据用户的问题检索相关视图，然后利用这些结果识别捕获检索视图之间关系的关联模型。
这个两步程序可以为相关表及其与用户问题的关系提供更全面的理解。以下图示展示了如何将两个元数据子集分块和存储为不同的嵌入，以提高检索效率。LookML 视图和模型信息通过单独的数据管道引入到 Amazon S3未显示。
为您的用例选择最佳语言模型
为任何用例选择合适的 LLM 至关重要。每个用例对上下文长度、标记大小以及处理各种任务如摘要、任务完成、聊天机器人应用等的能力有不同要求。Amazon Bedrock 是一个全面管理的服务，提供多家顶尖 AI 公司如 AI21 Labs、Anthropic、Cohere、Meta、Mistral、Stability AI 和 Amazon 提供的高性能基础模型，以及构建具有安全性、隐私性和负责任 AI 的生成式 AI 应用的广泛功能。
该解决方案使用了通过 Amazon Bedrock 提供的 Anthropic Claude 3，选择这一模型的主要原因有两个：
增强的上下文窗口 Anthropic Claude 3 能够处理多达 200000 个标记的上下文，能够处理更大的 LookML 查询和表。这一扩展能力在处理复杂或大数据时至关重要，使 LLM 可以访问必要的信息，以便准确、合理地响应用户。增强的推理能力 Anthropic Claude 3 在处理更大上下文时表现出色，使其能够更好地理解和回应需要深入理解视图、模型及其关系的用户查询。您可以通过多种提示工程技术对推理能力进行细致控制。构建 Web 应用程序
该解决方案使用 LangChain 和 Streamlit 构建 Web 应用程序，并将 Amazon Bedrock 集成其中。LangChain 是一个专门设计用于简化使用 LLM 创建应用程序的框架，您可以通过 LangChain 内可用的 Amazon Bedrock 组件轻松使用 Amazon Bedrock。我们使用 Streamlit 开发该 Web 应用程序的前端。
为了便于数据分析师与数据湖交互、获取提取相关数据的查询，该解决方案实现了一个聊天引擎，使用 ConversationalRetrievalChain 机制，这允许您将自定义向量存储检索器、提示和会话历史记录传递给 LLM，生成个性化的用户问题回答。为了存储聊天历史，我们使用 DynamoDB，以用户会话 ID 作为主键。DynamoDB 是一个高度可扩展和耐用的 NoSQL 数据库服务，能够高效地存储和检索多个用户会话的聊天历史。以下截图展示了使用 Streamlit 开发的聊天界面的示例。
以下是与 AskData 互动时用户工作流的一个示例场景：
用户问题 我该如何查找客户地址？
快鸭加速器下载安装AskData 响应 根据提供的 LookML 数据，您可以通过查询 rawmailingaddresses 表找到客户地址，该表包含与地址相关的信息。以下是检索客户地址的 SQL 查询：
SELECT account address1 address2 city province postalcode isocountryFROM rawmailingaddresses
此查询将返回帐户 SID可用于识别客户、地址的第一行、地址的第二行如果有、城市、省/州、邮政编码和所有在 rawmailingaddresses 表中的条目的 ISO 国家代码。如果您有具体客户的帐户，并希望检索该客户的地址，可以在查询中添加 WHERE 子句：
SELECT account address1 address2 city province postalcode isocountryFROM rawmailingaddressesWHERE account = YourCustomerAccount 请替换为实际帐户
将 YourCustomerAccount 替换为您希望查找地址的客户的实际帐户。
优化应用程序
尽管使用 LLM 回答用户关于数据的问题是高效的，但也存在着明显的局限性，例如 LLM 可能产生不准的响应，通常是由于虚构信息。为了提高应用程序的准确性并减少幻觉，我们做了以下几件事：
将 LLM 的温度设置为 01，以减少 LLM 产生过于创造性响应的倾向。在提示中加入说明，仅根据提供的上下文架构、聊天历史生成 SQL 查询。在将 LookML 数据引入向量数据库之前，仔细删除重复和冗余条目。在 AskData 的用户界面中增加用户体验反馈15 的评分和可选的文本输入评论。我们利用反馈来改善数据、提示和推断参数设置的质量。基于用户反馈，该应用程序实现了 40 的净推荐值NPS，超过了最初 35 的目标得分。我们设定这一目标的原因有几个：LookML 数据中的特定用户问题缺乏相关信息，SQL 查询结构中的特殊规则可能需要添加，以及尽管采取了所有措施，LLM 有时仍可能出错。
结论
在本文中，我们阐释了如何利用生成式 AI 显著提高数据分析师的效率。通过使用 LookML 作为我们数据湖的元数据，我们构建了视图表和模型关系的向量存储。凭借 RAG 框架，我们有效地从这些存储中检索相关信息，并将其与用户查询及任何先前聊天历史记录一起作为上下文提供。LLM 随即无缝生成 SQL 查询作为响应。
我们的开发过程得益于各项 AWS 服务，特别是 Amazon Bedrock，促进了 LLM 在查询响应中的集成；以及 Amazon RDS，作为我们的向量存储服务。
请查阅以下资源以了解更多信息：
