「SnapLogicがAmazon Bedrockを使用してテキストからパイプラインアプリケーションを構築し、ビジネスの意図を行動に変換します」

「SnapLogicがAmazon Bedrockを利用し、テキストからパイプラインアプリケーションを構築し、ビジネスの意図を実行に繋げる！」

この投稿は、SnapLogicのChief ScientistであるGreg Benson、Sr. Product ManagerのAaron Kesler、およびEnterprise Solutions ArchitectのRich Dillと共同で執筆されました。

多くの顧客は、自然言語に基づいたコードアーティファクトを作成するために、Amazon BedrockとAmazon CodeWhispererを使用して、生成型AIアプリを構築しています。このユースケースでは、大型言語モデル（LLMs）が人間の言語（英語、スペイン語、アラビア語など）と機械解釈可能な言語（Python、Java、Scala、SQLなど）の翻訳者になる能力があり、洗練された内部推論と共に、LLMsを自動化およびUX強化ツールとして利用することがソフトウェア開発者に要請されています。これにより、自然言語を特定のドメイン固有言語（DSL）に変換することができます。システムの命令、APIリクエスト、コードアーティファクトなどです。この記事では、AWSの顧客であるSnapLogicが、Amazon Bedrockを使用して、SnapGPT製品をパワーアップするためにこれらの複雑なDSLアーティファクトを自然言語から自動的に作成した方法を紹介します。

顧客がLLMsからDSLオブジェクトを作成する際、結果として得られるDSLは、既存のインターフェースデータとスキーマの正確な複製または派生物です。これは、UIとバックエンドサービスのビジネスロジックとの間の契約を形成するものです。このパターンは、独立系ソフトウェアベンダー（ISV）とサービスとしてのソフトウェア（SaaS）ISVの間で特にトレンドとなっています。それらはコードを通じて設定を表現する独自の方法と、顧客のユーザーエクスペリエンスを簡素化したいという欲求によるものです。例としては、以下があります。

• ツール固有のビジュアルと計算式への自然言語の変換（例: Amazon QuickSightの最新の生成型BI機能）
• 個々のユーザーの意図とコンテキストに基づいて正しいAPI呼び出しを生成する（例: AWS AppFabricの今後の生産性向上機能）
• 人間のプロンプトから複雑な統合パイプラインを作成する（この記事で詳しく読むことができます）

AWS上でLLMsを使用してテキストからパイプラインアプリケーションをビルドしスケールするもっとも簡単な方法は、Amazon Bedrockを使用することです。Amazon Bedrockは、Foundation Models（FMs）を使用して生成型AIアプリケーションをビルドしスケールするための最も簡単な方法です。これは、一つのAPI経由で主要なAI企業から提供される高性能なFoundation FMへのアクセスを提供する完全管理型サービスであり、プライバシーとセキュリティを備えた生成型AIアプリケーションを構築するために必要な幅広い機能を提供します。信頼性のある解釈可能で操作可能なAIシステムを構築するAI安全性と研究の研究所であるAnthropicは、Claudeという最新のLLMをAmazon Bedrock上で提供している主要なAI企業の一つです。Claudeは、思慮深い対話、コンテンツ作成、複雑な推論、創造性、およびコーディングなど、さまざまなタスクにおいて優れた性能を発揮するLLMです。Anthropicは、ClaudeとClaude Instantモデルの両方をAmazon Bedrockを介して提供しています。Claudeは、英語のテキストの約200ページに相当する100,000トークンのコンテキストウィンドウをサポートしており、複雑な推論、詳細な指示、包括的な例が必要なテキストからパイプラインアプリケーションをビルドする際に頼りになる重要な機能です。

• アイドルアプリの自動シャットダウンを使用して、Amazon SageMaker Canvasのコストを最適化する
• 「アマゾンベッドロックを使った商品説明の自動生成」
• 「Amazon SageMaker Studioを使用してBMWグループのAI/MLの開発を加速」

SnapLogicのバックグラウンド

SnapLogicは、エンタープライズオートメーションを世界にもたらす使命を持つAWSの顧客です。SnapLogic Intelligent Integration Platform（IIP）は、事前に構築されたインテリジェントコネクタ（Snaps）を使用して、アプリケーション、データベース、ビッグデータ、デバイス、APIなど、組織のエコシステム全体を接続することで、エンタープライズワイドな自動化を実現します。 SnapLogicは最近、SnapGPTという機能をリリースしました。これは、簡単な自然言語で作成したい統合パイプラインを入力するテキストインターフェースを提供します。SnapGPTは、SnapLogicの主力統合ソリューションを介して使用される、これらの統合パイプラインを自動的にコード化するために、Amazon Bedrockを介してAnthropicのClaudeモデルを使用しています。ただし、SnapLogicのSnapGPTへの道のりは、AIの領域での数年間の活動の集大成です。

SnapLogicのAIの旅

統合プラットフォームの領域では、SnapLogicは常に先駆者となり、人工知能の変革力を活用してきました。年月が経つにつれ、SnapLogicのAIに対する取り組みが明らかになりました。特に、IrisからAutoLinkへの旅をたどると、その取り組みが見えてきます。

Irisとの謙虚な始まり

2017年、SnapLogicは業界初のAIパワード統合アシスタントであるIrisを発表しました。Irisは、機械学習（ML）アルゴリズムを使用してデータパイプラインの次のステップを予測するために設計されました。数百万ものメタデータ要素とデータフローを分析することにより、Irisはユーザーに知的な提案を行い、データ統合を民主化し、技術的なバックグラウンドの深くない人でも複雑なワークフローを作成できるようにしました。

AutoLink：勢いをつける

Irisの成功と学習を基に、SnapLogicはデータマッピングプロセスをさらに簡素化するための機能であるAutoLinkを導入しました。ソースとターゲットシステム間のフィールドを手動でマッピングする煩雑な作業がAutoLinkによって容易になりました。AIを使用することで、AutoLinkは自動的に潜在的なマッチを特定し、提案します。以前数時間かかっていた統合が数分で実行できるようになりました。

SnapGPTとの潜在的な飛躍

SnapLogicの最新のAIへの挑戦は、SnapGPTです。SnapGPTは、統合をさらに革新することを目指しています。SnapGPTでは、世界初の生成統合ソリューションを導入しています。これは既存のプロセスを単純化するだけでなく、統合のデザイン方法を完全に再構築するものです。生成AIの力により、望ましい結果やデータの特性に基づいて統合パイプライン全体をゼロから作成できます。

SnapGPTは、最初のSnapLogicパイプライン生成に必要な時間を大幅に削減できるため、SnapLogicの顧客に非常に影響力があります。従来のSnapLogicの顧客は、統合パイプラインの設定に数日または数週間を費やす必要がありました。今では、これらの顧客は単純にSnapGPTに対して、「すべてのアクティブなSFDC顧客をWorkDayに移動するパイプラインを作成してください」といった要求をするだけで済みます。この顧客に対しては、パイプラインの動作する初稿が自動的に作成され、基本的な統合パイプラインの作成にかかる開発時間が大幅に短縮されます。これにより、エンドユーザーは統合パイプラインの設定ではなく、真のビジネスへの影響に重点を置くことができます。以下の例は、SnapLogicの顧客がSnapGPT機能に説明を入力してパイプラインを素早く生成する様子を示しています。

AWSとSnapLogicはこの製品構築において密接に協力してきました。この記事の残りの部分では、AWSとSnapLogicがテキストからパイプラインへの応用でLLMを使用する際に得た技術的な学びに焦点を当てます。

ソリューションの概要

このテキストからパイプラインへの問題を解決するために、AWSとSnapLogicは次のアーキテクチャを設計しました。

SnapGPTへのリクエストは、以下のワークフローを経ます：

1. ユーザーがアプリケーションに説明を提出します。
2. SnapLogicはリトリーバルオーグメンテーションジェネレーション（RAG）アプローチを使用して、ユーザーのリクエストと類似のSnapLogicパイプラインの関連例を取得します。
3. これらの関連例をユーザーの入力と組み合わせ、Claudeに送信する前にテキストの前処理を行います。
4. ClaudeはSnapLogicパイプラインを表すJSONアーティファクトを生成します。
5. JSONアーティファクトは、SnapLogicの統合プラットフォームに直接統合されます。
6. SnapLogicパイプラインは、ビジュアルフレンドリーな方法でユーザーに表示されます。

AWSとSnapLogicの間で行われたさまざまな実験により、高品質な出力を生成するためにソリューションダイアグラムのプロンプトエンジニアリングステップが非常に重要であることがわかりました。次のセクションでは、この領域でClaudeに使用された特定の技術についてさらに詳しく説明します。

プロンプトの実験

SnapGPTの開発段階で、AWSとSnapLogicは、SnapLogicのテキストからパイプライン出力への精度と関連性を改善するために、Claudeに送信されるプロンプトの迅速な反復が重要な開発タスクであることを発見しました。 Amazon SageMaker Studioのインタラクティブノートブックを使用して、AWSとSnapLogicチームは、Boto3 SDK接続を使用してAmazon Bedrockに異なるバージョンのプロンプトを迅速に作業することができました。ノートブックベースの開発により、チームはAmazon Bedrockへのクライアント側接続を迅速に作成することができ、Pythonコードとともにテキストベースの説明を含めてAmazon Bedrockにプロンプトを送信することができました。また、複数のペルソナ間で迅速に反復が行われる共同のプロンプトエンジニアリングセッションも行うことができました。

Anthropic Claudeのプロンプトエンジニアリング手法

このセクションでは、「例示的なユーザー要求に基づいて、ExampleCompanyデータベースを使用してすべてのアクティブな顧客を取得するパイプラインを作成してください」という高性能なプロンプトを作成するために使用した反復的なテクニックのいくつかを説明します。SnapGPTのスキーマではなく、テキストからパイプラインのアプリケーションを説明するために使用される例であることに注意してください。

プロンプトエンジニアリングのベースラインとして、次の元のプロンプトを使用します：

例：「ExampleCompanyデータベースを使用してすべてのアクティブな顧客を取得するパイプラインを作成してください」

期待される出力は次のようになります：

{  "database": "ExampleCompany",  "query": "SELECT * FROM ec_prod.customers WHERE status = 'active'"}

改善策１：ヒューマンとアシスタントの注釈を使用する

Claudeのトレーニング手順では、FMにヒューマンとアシスタントの対話のプロンプト構造を理解させます。ユーザーは、自分のプロンプトをAssistant:で終わらせることでこの構造を活用することができ、これによりヒューマンが言ったことに基づいてクエリへの応答を生成するようにClaudeがトリガーされます。ただし、Claudeは停止するまでテキストを生成し続けるため、APIリクエストのAmazon Bedrockへの送信時に\n\nHuman：のような停止シーケンスを使用することを確認してください。これにより、対話チェーン内のヒューマンからの予測された次の応答ではなく、アシスタントからの応答のみを受け取ることができます。これらの\n\nHumanおよび\n\nAssistantの指示子は、Claudeの応答を関連する情報に制限するのに役立つだけでなく、主要なヒューマンの入力と他の相互作用からのアシスタントの応答との明確な区別を提供するのにも役立ちます。これは特に、複数のクエリと\n\nHumanでタグ付けされたクエリと\n\nAssistantでタグ付けされた以前の応答を持つフューショットプロンプト設定で役に立ちます。改善されたプロンプトと関連するイラスト付きAPI呼び出しをBoto3 SDKを介してAmazon Bedrockに示します。

以下のプロンプトを使用します：

Human: 例Companyデータベースを使用してすべてのアクティブな顧客を取得するパイプラインを作成してください

Assistant:

出力は次のようになります：

以下はExampleCompanyデータベースからすべてのアクティブな顧客を取得するためのMongoDBパイプラインです：

pipeline = [    {        '$match': {            'database': 'ExampleCompany',             'status': 'active'        }    }]db.customers.aggregate(pipeline)

キーの手順は次のとおりです：

– `$match`を使用して、ExampleCompanyデータベース内のドキュメントをフィルタリングしてステータスが「active」に等しいものだけを取得します。

– `db.customers.aggregate()`は、パイプラインを顧客コレクションに適用し、フィルタリングされた結果を返します。

これにより、ステータスフィールドが「active」に設定されたExampleCompanyデータベースのすべての顧客ドキュメントが返されます。

以下の出力で、クロードが文脈なしで質問に対する回答を作り出していることに注意してください。回答は潜在的に役立つかもしれませんが、十分な文脈がないため、解決しようとしている問題に特化していません。また、Anthropicは、Claudeモデルを使用する際にこのヒューマンとアシスタントの形式を要求しますが、この手順を含めない場合、Amazon Bedrockはエラーメッセージを返します。

改善策２：クロードに何をするかを指示する前に、クロードのハイパースペシフィックなコンテキストを含める

クロードは、何を達成する必要があるのか、そしてそのタスクをどのように達成するかについての良好な文脈が与えられた場合に最も優れたパフォーマンスを発揮します。以下は、クロードにタスクを伝える前に、クロードの文脈として含めるべき事柄のいくつかの例です：

• クロードが果たしてほしい求人機能を説明してください。これにより、クロードはその仕事に従事しているかのように考えるか、あるいは特定の仕事の役割に採用されたばかりの人物のように考えることができます。これにより、クロードはその特定の仕事の役割の視点から回答を形成し、回答の幻覚やランダム性を減らすことができます。
• 出力形式に関する技術的な詳細を含めてください。基礎となるモデルは一般的にアクションを追跡するのに適しているため、クロードに出力を特定の形式やスキーマで生成するように依頼したり、いくつかの例を示すことで、クロードが正しい形式で回答を提供するのに役立ち、出力のフィルタリングや後処理の必要性を減らすことができます。以下のプロンプトの例では、予期される出力に一致する架空のスキーマが示されています。

これらの提案を組み合わせて、元のプロンプトを改善しましょう：

Human: あなたの仕事は、ETLパイプラインの専門家としてアクトすることです。具体的には、ユーザーリクエストを解決するためのETLパイプラインのJSON表現を作成することがあなたの仕事です。

JSON出力は以下の形式に従う必要があります：

{  "database": "ここで使用するデータベースの名前",  "query": "タスクを解決するためのSQL表現をここに配置してください"}

以下があなたのタスクです：ExampleCompanyデータベースを使用して、すべてのアクティブな顧客を取得するパイプラインを作成してください。

Assistant:

出力は以下の通りです：

ExampleCompanyデータベースからすべてのアクティブな顧客を取得するETLパイプラインのJSON表現は以下の通りです：

{  "database": "ExampleCompany",  "query": "SELECT * FROM customers WHERE status = 'active'"}

このパイプラインはExampleCompanyデータベースと、ステータスが「アクティブ」である顧客テーブルからすべてのレコードを選択するためのSQLクエリを使用しています。

文脈の追加により、モデルは回答の大部分を把握することができるようになりました。出力の構造化方法を把握し、タスクを解決するためにSQLステートメントを作成する必要があることを理解しています。ただし、予想しているec_prod.customersの名称法を正しく使用していないことに気付くでしょう。改善の余地があります！また、実際の場面では、テキストからパイプラインへの使用事例では、本例で提供したものよりもはるかに多くの文脈を含める必要があります。

改善点3：XMLタグで例を囲む

フューショット学習は、FMと共に正確性を高めるための人気のある方法です。これは、テキストからパイプラインへのアプリケーションで特に重要です。このようなハイパースペシフィックなパイプラインの出力は通常、パブリックデータセットに含まれていないため、個々の顧客データ表現に固有です。クロードを使用する場合、いくつかのフューショット形式でこれらの例を提供するために、任意のXMLタグに対するクロードの固有の知識を活用することができます。次の改善されたプロンプトでは、<example> XMLタグで囲まれた例の追加に注意してください。また、クロードに特定の対話の一部であると思わせることなく、人間およびアシスタントの略語であるHおよびAを使用して、クロードに文脈を提供することができます。

以下のプロンプトを使用します：

Human: あなたの仕事は、ETLパイプラインの専門家としてアクトすることです。具体的には、ユーザーリクエストを解決するためのETLパイプラインのJSON表現を作成することがあなたの仕事です。

JSON出力は以下の形式に従う必要があります：

{  "database": "ここで使用するデータベースの名前",  "query": "タスクを解決するためのSQL表現をここに配置してください"}

以下は、課題を正しく解決するユーザーリクエストと関連する出力JSONアーティファクトの例です。同じデータベースを使用する場合は、提供された例と同じ命名規則を使用してください。

<example-1>

H: 顧客＃1234のアクティブな注文をExampleCompanyデータベースでクエリしてください

A:

{  "database": "ExampleCompany",  "query": "SELECT * FROM ec_prod.orders WHERE customer_id = 1234 AND status  = 'active'"}

このクエリの理由は、顧客＃1234がフィルタリングされ、私たちは「アクティブ」フィルターの後に「注文」テーブルを検索しています。

</example-1>

<example-2>

H: ExampleCompanyデータベース内の最後の1ヵ月で非アクティブだった顧客をすべて削除してください

A:

{  "database": "ExampleCompany",  "query": "SELECT * FROM ec_prod.customers WHERE status != 'active'"}

このクエリの理由は、「ec_prod.customers」テーブルがExampleCompanyデータベース内で顧客のレコードのみを含んでいるためです。

</example-2>

以下があなたのタスクです：ExampleCompanyデータベースを使用して、すべてのアクティブな顧客を取得するパイプラインを作成してください。

Assistant:

以下の出力です：

ETLパイプラインのJSON表現は、ExampleCompanyデータベースからすべてのアクティブな顧客を取得するためのものです：

{  "database": "ExampleCompany",  "query": "SELECT * FROM ec_prod.customers WHERE status = 'active'"}

理由は次のとおりです：

ExampleCompanyデータベースは使用するデータベースとして指定されています

ec_prod.customersテーブルには顧客データが含まれています

statusフィールドは顧客がアクティブかどうかを示していますので、クエリはアクティブな顧客のみをフィルタリングします

これにより、ExampleCompanyデータベースからすべてのアクティブな顧客レコードを取得できます。ETLパイプラインに関する追加の要件や説明が必要な場合はお知らせください！

JSONの出力には正しいデータベース用語が含まれており、私たちが提供した例のおかげでクロードが使用できました。XMLタグと人間およびアシスタントの指標を組み合わせることで、クロードがタスクと回答を非常に明確に区別して理解しやすくすることができます。クロードが理解しやすければするほど、回答はより良く、関連性があり、モデルが空想してランダムな関連のない回答を提供する可能性がさらに低くなります。

改善策4：XMLタグを使用し、クロードにJSON生成を開始させる

FMsを使用したテキストからパイプラインへのアプリケーションでは、出力を正確に解析してダウンストリームのアプリケーションでコードとして解釈できるようにする必要があります。この問題をクロードとともに解決する方法の1つは、XMLタグの理解とカスタムの停止シーケンスを利用することです。次のプロンプトでは、出力を <json></json> のXMLタグで囲むようにクロードに指示しています。その後、プロンプトの末尾に <json> タグを追加しました。これにより、クロードから最初に出力されるテキストがJSON出力の開始であることが保証されます。これを行わないと、クロードは通常、会話のテキスト、その後にコードの応答を返します。クロードにすぐに出力生成を開始させるように指示することで、閉じる</json>タグが表示されるまで出力生成を簡単に停止できます。これは更新されたBoto3 API呼び出しで示されています。このテクニックの利点は2つあります。まず、クロードからのコード応答を正確に解析できます。さらに、余分なテキストではなく、クロードはコードの出力のみを生成するため、コストを削減できます。これにより、すべてのFMsから出力された各トークンの数に応じてAmazon Bedrockでのコストが発生します。

次のプロンプトを使用します：

人間：あなたの仕事は、ETLパイプラインの専門家として振る舞うことです。具体的には、ユーザーの要求を解決するためのETLパイプラインのJSON表現を作成することです。

JSONの出力は次のフォーマットに従う必要があります：

{    "database": "ここに使用するデータベースの名前"    "query": "ここにタスクの解決のためのSQL表現を置く"}

次に、ユーザーの要求と関連する出力JSONアーティファクトのいくつかの例を示します。同じデータベースを使用する場合は、例で提供された同じ用語を使用してください。

<example-1>

H: ExampleCompanyデータベースで顧客#1234のアクティブな注文をクエリしてください

A:

<json>

{  "database": "ExampleCompany",  "query": "SELECT * FROM ec_prod.orders WHERE customer_id = 1234 AND status  = 'active'"}

</json>

このクエリの理由は、顧客#1234がフィルタリングされており、私たちは「orders」テーブルで「アクティブ」フィルター後の既存のレコードを検索しています。

</example-1>

<example-2>

H: ExampleCompanyデータベースで過去1ヶ月間にアクティブでなかったすべての顧客を削除してください

A:

<json>

{  "database": "ExampleCompany",  "query": "SELECT * FROM ec_prod.customers WHERE status != 'active'"}

</json>

このクエリの理由は、”ec_prod.customers” テーブルが ExampleCompanyデータベースの唯一の顧客レコードを含んでいるからです。

</example-2>

常にJSONの出力を<json></json>タグで囲むことを忘れないでください。

以下があなたのタスクです：ExampleCompanyデータベースを使用し、すべてのアクティブな顧客を取得するパイプラインを作成する。

アシスタント：

<json>

以下のコードを使用します：

body = json.dumps({"prompt": prompt, "stop_sequences": ['\n\nHuman:', '</json>']})response = bedrock.invoke_model(   body=body,   modelId='anthropic.claude-v2')

出力は以下の通りです：

{  "database": "ExampleCompany",  "query": "SELECT * FROM ec_prod.customers WHERE status = 'active'"}

これで、期待される出力だけがJSONオブジェクトとして返されました！この方法を使用することで、直ちに利用可能な技術アーティファクトを生成することができ、出力トークンを減らすことで生成のコストを削減することができます。

結論

SnapGPTを今日から始めるには、SnapLogicの無料トライアルをリクエストするか、製品のデモをリクエストしてください。これらのコンセプトを今日からアプリケーションの構築に使用したい場合は、この投稿のプロンプトエンジニアリングセクションで実験を手掛けることをおすすめします。ビジネスに適したDSLジェネレーションの別のユースケースで同じフローを使用し、Amazon Bedrockを介して利用可能なRAGの機能に深く入り込むことができます。

SnapLogicとAWSは、Amazon BedrockによってカバーされるSnapLogic統合パイプラインの複雑なスキーマと人間の言語との間の高度な変換を効果的にパートナーとして構築してきました。この旅の中で、Claudeによって生成される出力が特定のプロンプトエンジニアリング技術を使用してテキストからパイプラインアプリケーションで改善される方法を見てきました。AWSとSnapLogicは、Generative AIのパートナーシップを続け、この急速な進化する領域での将来の共同作業とイノベーションに期待しています。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!