SnapLogic与Amazon Bedrock联合打造文本转管道应用程序

关键要点

SnapLogic 创建了 SnapGPT，一个利用 Amazon Bedrock 的文本转管道应用，使用户可以通过自然语言创建集成管道。通过使用大型语言模型LLMs，SnapGPT 可以快速生成符合用户要求的代码，显著减少配置时间。本文探讨了如何使用 LLMs 提高文本到管道输出的质量，包括提示工程的最佳实践。

由 Greg Benson、Aaron Kesler、Rich Dill、Clay Elmore、Farooq Sabir、Sandeep Rohilla 和 Sina Sojoodi 共同撰写于 2023 年 11 月 24 日，发布在 Amazon Bedrock、Customer Solutions、Generative AI、Intermediate (200) 和 Thought Leadership。

在当今，大量客户正在利用 Amazon Bedrock 和 Amazon CodeWhisperer 构建 生成性人工智能 应用程序，以根据自然语言生成代码。这个案例展示了大型语言模型LLMs如何成为人类语言如英语、西班牙语、阿拉伯语等与机器可理解语言如 Python、Java、Scala、SQL 等之间的翻译器。这种新兴能力使软件开发者将 LLMs 视为自动化和用户体验增强工具，能够将自然语言转换为特定领域语言DSL：系统指令、API 请求、代码工件等。本文介绍了 AWS 客户 SnapLogic 如何通过 Amazon Bedrock 为其 SnapGPT 产品提供动力，自动生成这些复杂的 DSL 工件。

当客户利用 LLM 创建 DSL 对象时，结果 DSL 要么是现有接口数据和架构的准确复制品，要么是其衍生型。这种模式在独立软件供应商ISVs和软件即服务SaaS ISVs 中尤其流行，因为它们通过代码表示配置的独特方式，以及简化客户体验的愿望。典型案例包括：

用例描述自然语言转特定工具的可视化和计算表达式最近发布的 Amazon QuickSight 生成 BI 能力基于用户意图和上下文生成正确 API 调用即将在 AWS AppFabric 中推出的生产力功能使用简单的自然语言创建复杂集成管道与本文内容进一步探讨

构建和扩展 AWS 上的文本到管道应用程序最简单的方法是使用 Amazon Bedrock。Amazon Bedrock 提供了一个快速构建和扩展生成性AI 应用程序的平台，能够通过单一 API 访问领先 AI 的高性能基础模型FMs，并提供您在构建具有隐私和安全性的生成性 AI 应用程序时所需的一套广泛功能。Anthropic 作为一家人工智能安全和研究实验室，提供其最先进的 LLM Claude，该模型很快就因其改进的推理能力而在这些文本到管道应用程序中获得了极大的人气。这种能力让 Claude 能够出色地解决模糊的技术问题。在 Amazon Bedrock 上的 Claude 2 支持 100000 个令牌的上下文窗口，相当于大约 200 页英文文本。这项功能在构建需要复杂推理、详细指令和全面示例的文本到管道应用程序时尤为重要。

SnapLogic 背景

SnapLogic 是一家 AWS 客户，使命是将企业自动化带入全球。SnapLogic 智能集成平台IIP使组织能够通过连接其应用程序、数据库、大数据、机器和设备、API 等整个生态系统来实现企业范围内的自动化，采用称为“Snaps”的预构建智能连接器。SnapLogic 最近发布的 SnapGPT 功能，提供一个文本接口，用户可以在其中以简单自然语言输入想要创建的集成管道内容。SnapGPT 通过 Amazon Bedrock 的 Anthropic Claude 模型自动生成这些集成管道的代码，这些代码在 SnapLogic 的旗舰集成解决方案中使用。然而，SnapLogic 的 SnapGPT 之旅是多年来在人工智能领域运作的积累结果。

SnapLogic 的人工智能之路

在集成平台的领域，SnapLogic 一直处于前沿，充分利用人工智能的变革力量。这些年来，该公司对 AI 创新的承诺日益明显，特别是我们追溯从 Iris 到 AutoLink 的旅程。

Iris 的谦卑起步

2017 年，SnapLogic 推出了 Iris，业界首个 AI 驱动的集成助手。Iris 旨在利用机器学习算法来预测构建数据管道的下一步。通过分析数百万个元数据元素和数据流，Iris 能够向用户提供智能建议，从而使没有深厚技术背景的人也能创建复杂的工作流。

AutoLink 建立势头

在 Iris 成功的基础上，SnapLogic 推出了 AutoLink，旨在进一步简化数据映射过程。通过使用 AI，AutoLink 自动识别和建议潜在匹配，手动映射源系统与目标系统之间的字段这一乏味的任务变得轻而易举，以前需要数小时的集成，现在可以在几分钟内完成。

SnapGPT 的生成性飞跃

SnapLogic 在人工智能领域的最新尝试就是 SnapGPT，旨在进一步颠覆集成的方式。借助 SnapGPT，SnapLogic 推出了全球首个生成集成解决方案。它不仅简化了现有流程，甚至重新构想了集成的设计方式。生成性 AI 的强大功能能从零开始创建完整的集成管道，并根据期望的结果和数据特征优化工作流。

SnapGPT 对 SnapLogic 的客户产生了极大的影响，因为它们能够显著减少生成第一个 SnapLogic 管道所需的时间。以往，SnapLogic 客户通常需要花费数天甚至数周的时间从头配置集成管道。现在，这些客户可以简单地让 SnapGPT 例如“创建一个将我所有的活跃 SFDC 客户迁移至 WorkDay 的管道”，系统会自动为该客户生成一个可用的草稿管道，极大地减少了创建集成管道基础所需的开发时间。这使最终客户能够更多地专注于对他们真正有业务影响的事情，而不是配置集成管道。以下示例展示了 SnapLogic 客户如何在 SnapGPT 功能中输入描述，以快速生成管道，利用自然语言。

AWS 和 SnapLogic 在整个产品构建过程中进行了紧密合作，并在此过程中获得了许多宝贵经验。本文的其余部分将重点探讨 AWS 和 SnapLogic 在使用 LLMs 进行文本到管道应用方面的技术学习。

解决方案概述

为了解决文本到管道的问题，AWS 和 SnapLogic 设计了一种全面的解决方案，如下图所示。

对 SnapGPT 的请求经历以下工作流程：

用户向应用程序提交描述。SnapLogic 采用检索增强生成RAG的方法，检索与用户请求相似的 SnapLogic 管道示例。提取的相关示例与用户输入结合，并在发送给 Amazon Bedrock 的 Claude 之前进行文本预处理。Claude 生成一个表示 SnapLogic 管道的 JSON 工件。该 JSON 工件被直接集成到核心 SnapLogic 集成平台。SnapLogic 管道以可视化的方式呈现给用户。

在 AWS 和 SnapLogic 之间进行的多次实验中，我们发现解决方案图中的提示工程步骤对于生成高质量的文本到管道输出至关重要。接下来将进一步探讨在这一领域中使用 Claude 的一些具体技术。

提示实验

在 SnapGPT 的开发阶段，AWS 和 SnapLogic 发现快速迭代发送给 Claude 的提示是提高 SnapLogic 输出的文本到管道输出准确性和相关性的关键开发任务。使用 Amazon SageMaker Studio 的交互式笔记本，AWS 和 SnapLogic 团队能够快速通过 Boto3 SDK 与 Amazon Bedrock 进行不同版本的提示的工作。基于笔记本的开发使团队能够快速创建客户端与 Amazon Bedrock 的连接，将文本描述与发送给 Amazon Bedrock 的 Python 代码结合，并举行联合提示工程会议，以便在多方之间迅速进行迭代。

Anthropic Claude 提示工程方法

在本节中，我们描述了一些迭代技术，以基于以下用户请求生成高性能提示：“创建一个使用 ExampleCompany 数据库并获取所有活跃客户的管道。”请注意，这个示例并不是 SnapGPT 所使用的架构，仅用于说明文本到管道的应用程序。

我们使用以下原始提示进行基准：

创建一个使用 ExampleCompany 数据库并获取所有活跃客户的管道。

预期输出如下：

json{ database ExampleCompany query SELECT FROM ecprodcustomers WHERE status = active}

改进 #1：使用人类和助手注释

Claude 的训练过程教会了基础模型理解人类与助手之间的对话结构。Claude 用户可以通过在提示的末尾添加 “Assistant” 来利用这一结构，这将触发 Claude 根据人类所说的内容开始生成查询的响应。请注意，因为 Claude 会继续生成文本直到被告知停止，所以在向 Amazon Bedrock 的 API 请求中确保使用停止序列 nnHuman。这将确保您只接收到助手的响应，而不会在对话链中包含人类的预测下一个响应。这些 nnHuman 和 nnAssistant 指标不仅有助于限制 Claude 的响应信息，还提供了明确的界限，区分主要人类输入与助手响应之间的其他交互。特别是在 Fewshot 提示设置中，您可以用 nnHuman 标记多个查询，用 nnAssistant 标记先前的响应。让我们看一下改进后的提示和通过 Boto3 SDK 发往 Amazon Bedrock 的相关 API 调用。

我们使用以下提示：

Human 创建一个使用 ExampleCompany 数据库并获取所有活跃客户的管道。

Assistant

输出如下：

这里是一个 MongoDB 管道，用于从 ExampleCompany 数据库获取所有活跃的客户：

pythonpipeline = [ { match { database ExampleCompany status active } }]dbcustomersaggregate(pipeline)

关键步骤是：

match 用于过滤文档，仅返回在 ExampleCompany 数据库中且状态为“活跃”的文档。

dbcustomersaggregate() 在客户集合上运行管道并返回过滤结果。

请注意，输出中 Claude 回答了我们的问题，但没有提供足够的上下文。这种回答虽然可能有帮助，但并不针对我们要解决的问题。值得一提的是，Anthropic 要求在使用 Claude 模型时遵循这种人类与助手的格式；如果不包括这一步，Amazon Bedrock 将返回错误。

改进 #2：在指令之前为 Claude 提供超具体上下文

Claude 在提供良好的上下文时表现最佳，它知道自己需要完成什么以及如何完成该任务。以下是一些包含在提示中、在指示 Claude 执行任务之前应该提供的上下文示例：

描述您希望 Claude 执行的工作职能。这样做的目的是让 Claude 从事该职位，就像刚刚入职的人一样，从而帮助其从特定职位的视角形成答案，减小产生虚构及随机性。包括与输出格式相关的技术细节。基础模型通常善于遵循操作，因此要求 Claude 生成特定格式或架构的输出，以及一些示例将有助于 Claude 在正确格式中提供答案，减少对输出的过滤和后处理。以下提示中的示例展示了一个与预期输出匹配的虚构架构。

让我们结合这些建议以改进我们的原始提示：

Human 您的工作是作为 ETL 管道方面的专家。具体来说，您需要创建一个 JSON 形式的 ETL 管道，该管道将解决用户提供的请求。

JSON 输出应遵循以下格式：

json{ database 您将在此使用的数据库名称 query 为解决当前任务提供的 SQL 表达式}

您的任务是：创建一个使用 ExampleCompany 数据库并获取所有活跃客户的管道。

Assistant

输出如下：

这是从 ExampleCompany 数据库获取所有活跃客户的 ETL 管道的 JSON 表示：

json{ database ExampleCompany query SELECT FROM customers WHERE status = active}

此管道使用 ExampleCompany 数据库，以及将所有记录从客户表中选择的 SQL 查询，条件是状态为 “活跃”。

通过增加上下文，模型现在能够接近正确的答案。它知道如何结构化输出，并理解它需要编写 SQL 语句来解决任务。然而，您会注意到，模型未能正确使用我们所期待的 ecprodcustomers 命名法。这仍有改进空间！同样需要注意的是，在实践中，对于高质量的文本到管道生成，您需要提供比此示例中更多的上下文。

改进 #3：将示例封装在 XML 标签中

Fewshot 学习是一种通过相关示例引导基础模型完成任务的流行方法。这在文本到管道应用中尤其重要，因为这些超具体的管道输出通常不包含在任何公共数据集中，因为它们特定于单个客户的数据表示。使用 Claude，您可以利用它对任意 XML 标签的内在知识，以便将这些可在多个示例中使用的示例以 fewshot 格式提供。在以下改进后的提示中，请注意添加的示例被封装在 ltexamplegt XML 标签中。同时，您可以使用人类与助手的缩写H 和 A，为 Claude 提供上下文，而无需将其视作已经发生的特定对话部分。

我们使用以下提示：

Human 您的工作是作为 ETL 管道方面的专家。具体来说，您需要创建一个 JSON 形式的 ETL 管道，该管道将解决用户提供的请求。

JSON 输出应遵循以下格式：

json{ database 您将在此使用的数据库名称 query 为解决当前任务提供的 SQL 表达式}

这是一些用户请求和相关输出 JSON 工件的示例，能够正确解决所提供的任务。如果您使用相同的数据库，请确保使用示例中提供的相同命名法。

H 检索 ExampleCompany 数据库中客户 #1234 的所有活跃订单。

ios稳定机场

A

json{ database ExampleCompany query SELECT FROM ecprodorders WHERE customerid = 1234 AND status = active}

此查询的推理是，客户 #1234 被过滤，我们在“订单”表中搜索任何存在的记录，经过“活跃”过滤条件。

H 删除 ExampleCompany 数据库中过去一个月未活跃的所有客户。

A

json{ database ExampleCompany query SELECT FROM ecprodcustomers WHERE status != active}

此查询的推理是，“ecprodcustomers”表是 ExampleCompany 数据库中唯一包含客户记录的表。

您的任务是：创建一个使用 ExampleCompany 数据库并获取所有活跃客户的管道。

Assistant

输出如下：

这是从 ExampleCompany 数据