re:Invent 2024: Amazon BedrockのKnowledge Basesで構造化データ活用
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Unlocking power of structured data with Amazon Bedrock Knowledge Bases (AIM396-NEW)
この動画では、Amazon Bedrock Knowledge Basesの構造化データ処理機能について詳しく解説しています。Foundation Modelを活用したRetrieval Augmented Generation（RAG）の手法を説明し、特に自然言語からSQLへの変換における課題と解決策に焦点を当てています。Amazon Redshiftと連携したKnowledge Basesの具体的な設定方法やデモを通じて、データベーススキーマの理解、クエリの生成、セキュリティ機能などの実装詳細を紹介しています。また、Descriptionsやinclusion/exclusion filter、Curated Queriesといった高度なクエリ設定機能により、複雑なビジネスロジックや独自の用語をどのように扱えるかを実例を交えて説明しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon Bedrock Knowledge Basesの概要とRAGの重要性
Amazon Bedrock Knowledge Basesが持つ構造化データの可能性について解説させていただきます。私はニューヨーク在住のAWSのSenior Manager of Software DevelopmentのRon Widhaです。隣にいるのは、AWSのPrincipal Software EngineerのSaket Saurabhです。私たちはAmazon Bedrock Knowledge Basesチームをサポートしています。re:Playの翌日の金曜日の朝にお集まりいただき、ありがとうございます。会場の皆様に伺いたいのですが、Retrieval Augmented Generationについてご存知の方は手を挙げていただけますでしょうか？また、Bedrock Knowledge Basesをご存知の方、もしくはすでに使用されている方はいらっしゃいますか？素晴らしいですね。今日は、皆様に向けて準備した内容があります。まず、このトピックに比較的新しい方のために、RAGとは何か、なぜ重要なのかという文脈を確立します。次に、多くの方々が使用または構築している非構造化データに対するアプローチと、構造化データへのアプローチの違いを比較します。そして、最も時間を割いて、構造化データの側面に深く踏み込んでいきます。
Foundation Modelは自然言語の理解と生成に優れています。書籍、ウェブサイト、論文、記事、コードリポジトリからのデータと知識で事前学習されているため、一般的な知識を持っています。 しかし、ここで視点を変えてみましょう。もし皆さんがチャットボットやAIを前面に打ち出した新しい小売マーケットプレイスである架空の会社、AnyCompany Marketplaceのエグゼクティブだとしたら、 こう考えてみましょう：AnyCompanyにはどのようなプロンプトに応答してほしいでしょうか？ おそらく答えは非常にタスク重視のものになるでしょう。例えば、カスタマーサポートの最初の考慮事項として「返品ポリシーを教えてください」というものがあります。
私たちの会社は架空で最近設立されたものなので、どのモデルも私たちの具体的な返品ポリシーについての文脈を持っていません。モデルは一般的な返品ポリシーについては知っていますが、そのまま任せてしまうと、私たちのものではない別の返品ポリシーを想像して答えてしまう可能性があります - これは大惨事になりかねません。そのため、Foundation Modelが持つ知識を何らかの方法でカスタマイズまたは拡張する必要があります。 一つの方法として、Foundation Modelをゼロから学習させることができます。これは最も複雑で、時間がかかり、リソースを必要とするアプローチです。まずモデルのアーキテクチャを決定し、すべてのデータを収集・集約する必要があります。このデータには、言語、文化、話し方のトーン、割り当てたい役割の一部をカバーし、さらに自社のデータを取り入れ、満足のいくモデルができるまで、大量の計算リソースと専門知識を使って学習、ベンチマーク、そして繰り返しを行う必要があります。多くの場合、これはビジネスにとって現実的ではありません。小売に焦点を当てているAnyCompanyとしては、モデルを構築するビジネスに携わりたくはありません。
Amazon Bedrockで簡単に実行できる次のアプローチは、既製のFoundation Modelを使用し、自社のデータを持ち込んでカスタマイズすることです。Bedrockではこれを行うための2つの方法があります：Fine TuningとContinued Pre-trainingです。Fine Tuningではラベル付きデータセットを使用し、Continued Pre-trainingでは教師なし学習アプローチであるため、ラベルなしデータセットを使用できます。これは比較的静的で、ゆっくりと変化するデータに適しています。 私たちが日常的に使用しているのは、Prompt EngineeringまたはPrompt Tuningです。例えば、「あなたはカスタマーエージェントのQ&Aチャットボットで、あなたの責任は...」というようなPrompt Primingから始めることができます。
Prompt Engineeringの課題は、知識に限界があることです。本質的に、事前学習されたFoundation Modelにすでに含まれている知識を活用することになります。先ほどの返品ポリシーの例で議論したように、具体的な内容は知りません。ここで重要な疑問が生じます：Foundation Modelの外部にある、私たちのビジネスに特化した特定の情報を事前に選択してキュレーションし、それをユーザーのプロンプトと一緒にFoundation Modelに渡すことができれば、より良いのではないでしょうか？そうすれば、私たちの回答は、リポジトリで利用可能な情報と知識に基づいて確実なものとなります。ここで登場するのが、Retrieval Augmented Generation、略してRAGです。
構造化データ検索の課題と Amazon Bedrock Knowledge Basesの解決策
RAGとは何でしょうか？名前が示す通り、ユーザーのプロンプトが入力されると、まず情報の検索（Retrieval）から始まります。 これにより、Foundation Modelが選択できる可能性のある回答が全て用意されます。この方法の利点は、私たち開発者やビジネス側が、Foundation Model単独に依存するのではなく、モデルがお客様にどのように応答するかについて大きなコントロールと柔軟性を持てることです。これにより、ハルシネーション（誤った情報の生成）を減らし、精度を向上させ、特定のタスクに焦点を当てることができます。 関連コンテンツを取得したら、それをユーザーのプロンプトに追加し、最終的な応答を生成するためにFoundation Modelに渡します。
次に、検索の種類について説明しましょう。関連情報を取得・検索する際の最初のアプローチは検索です。キーワード検索は理にかなっています - ユーザーのプロンプトに特定のキーワードが含まれている場合、どのキーワードがより重要かを判断する方法があるでしょう。それを企業の検索エンジンに渡して、関連する結果を取得します。これは妥当な出発点です。しかし、完全一致のキーワードがない場合はどうでしょうか？ そのような場合に必要なのは、単語の意味に基づく意味論的な検索です。
多くの方がご存じかもしれませんが、このアプローチの一つは、すべてのドキュメントやフレーズをFoundation Modelを使ってベクトルに変換し、多次元のベクトル空間に配置することです。そうすることで、ユーザーのプロンプトが入力された際に、そのような質問に答えるのに役立つ可能性のある関連ドキュメントや情報を、ベクトル類似度検索で見つけることができます。 例えば、「New York」という単語を入力し、それを多次元ベクトル空間でベクトルとして表現すると、 ベクトル類似度検索を行った場合、完全一致でなくても「subway」や「Statue of Liberty」、「tall buildings」といった結果が得られるでしょう。「coffee」というワードのベクトル表現と「milk」のベクトル表現を算術演算で組み合わせると、「latte」という単語に近いベクトル表現になるということには、いつも感心させられます。これは、それらの単語の背後にある意味の深い理解を示しています。
Amazon Bedrock Knowledge Basesは、このようなRAGワークフローの構築をサポートします。非構造化データに対して、以下のような仕組みで動作します。この機能は昨年のre:Inventで発表されました。 ユーザーが商品の返品ポリシーについて質問すると、 Amazon Bedrockを呼び出し、Amazon Bedrock Knowledge Basesが返品ポリシーのドキュメントから関連情報を特定します。 次に、プロンプトを拡張します：「あなたはカスタマーエージェントです。与えられた情報のコンテキストに基づいて、事前知識は使わずに、以下の質問に答えてください。」質問と関連ドキュメントを含めます。 最後に、生成段階で、これら全てをFoundation Modelに渡すと、「はい、商品にご満足いただけない場合は、いつでも返品していただけますのでご安心ください」というような会話的な応答が返ってきます。
AnyCompanyのチャットボット体験に話を戻すと、これはお客様が尋ねたい質問の一つに過ぎないかもしれません。
「サイズ9は在庫がありますか？」「注文状況を教えてください」といった定型的な質問も予想されます。さらに興味深いのは、社内の従業員からの「2024年11月のトップセラー商品は何でしたか？」や「2024年11月のPrestige Partnerは誰でしたか？」といった質問です。 ここでのPrestige Partnerとは、その月間で最も収益を上げているチャネルパートナーを指す、私たちのビジネス特有の用語です。Foundation Modelはこれについて何も知りませんので、このような質問に答える方法を見つける必要があります。
「2024年11月のトップセラー商品は何でしたか？」という質問について、もう少し掘り下げてみましょう。先ほどのSemantic Searchのアプローチで解決できるでしょうか？もしアナリストが既にそのレポートを作成していれば、それを取得することはできますが、それにはアナリストが定期的にドキュメントを作成する必要があります。従来、企業はこの種の情報を構造化された形式で、データベースエンジンやデータレイク上のParquetファイルなどに保存しており、このような形になっています。 注文の合計金額が記録されたテーブルがありますが、トップセラー商品を知るためには、ここには商品情報さえ表示されていません。
そこで商品IDを持つ別のテーブルがあり、注文と結合すると情報が得られますが、商品IDだけでは不十分で、実際の商品名が必要です。そのため、さらに別のテーブルで検索する必要があります。データベースは通常大規模で、多くのテーブルがありますが、この特定のクエリでは、その一部分だけが必要です。実際のところ、答えは1つのドキュメントにも、1つのテーブルにも、1つの行にも存在していません。この質問に答えるには、検索、集計、11月のデータに限定するためのフィルタリングが必要で、「トップセラー商品を表示して」というクエリに変換した場合は、そのような応答の順序付けも考慮する必要があるかもしれません。
この多次元のVector検索空間は様々な方法で有用ですが、先ほど説明したクエリの複雑さを考えると、まったく異なるアプローチが必要です。 最適なアプローチは、ユーザーの自然言語クエリを、これらのデータベースエンジンが理解できる言語、つまり構造化クエリ言語に変換することだと考えています。これで、先ほどの検索タイプの話に戻ります。 Amazon Bedrock Knowledge Basesが対応すべき第三の検索タイプとして、Structured Dataがあると考えています。
Natural Language to SQLは構造化データのためのRAGだと考えており、Bedrock Knowledge Basesではこのように機能します。水曜日に、Knowledge Basesでのstructured data retrievalの発表を大変楽しみにしています。ユーザーのクエリが入力されると、この場合「11月のトップセラー商品は何でしたか？」を、Bedrock Knowledge Baseに送信します。Bedrock Knowledge BaseがSQLクエリを生成し、それを送信して、この場合Amazon Redshiftのデータベースで実行します。表形式の応答を受け取り、最後に選択したFoundation Modelに渡して、受け取った表の応答に基づいて最終的な回答を生成します。この場合、「11月のトップセラー商品は○○です」という形になります。
自然言語からSQLへの変換：課題と Amazon Bedrock Knowledge Basesのアプローチ
Ron、あなたは以前、Foundation Modelはコードリポジトリで事前学習されていると言っていましたね。おそらく皆さんの中にも、日々のコーディングやデザインドキュメントのレビューなどで、Foundation Modelを活用している方がいらっしゃると思います。私も同じです。では、なぜAmazon Bedrock Knowledge Baseが必要なのでしょうか？Foundation Modelを使うだけでは不十分なのでしょうか？この問題の何が難しいのでしょうか？この点について、Saket Saurabhに詳しく説明してもらいましょう。
Saketが、Amazon Bedrock Knowledge Base内での自然言語からSQLへの変換問題の解決方法について説明します。 まず、なぜ自然言語からSQLへの変換が難しいのか理解してみましょう。言語モデルは人間の言語を理解する問題をうまく解決していますが、テキストからSQLへの変換には独特の課題があります。いくつかの例を見ながら、その理由を理解していきましょう。
このクエリを見てみましょう。これはBIRDという標準的なテキストからSQLへの変換のベンチマークデータセットから取ったものです。 この質問は、Alameda Countyにある、テスト受験者が100人未満の学校の数を数えるものです。このクエリを言語モデルに与えてSQLクエリを生成させると、 一見、目的に合った妥当なクエリが生成されるでしょう。しかし、このデータセットに付属するデータベースでこのクエリを実行しようとすると、 実行は失敗してしまいます。その理由は、言語モデルに問い合わせた際、テーブルのスキーマ、テーブル名、カラム名などのコンテキストが与えられていなかったからです。
ここで両方のクエリの違いがわかります。 これは、テキストからSQLへの生成プロセスが、あなたのデータベーススキーマに合わせてパーソナライズされる必要があることを示しています。有用なクエリを生成するためには、テーブル名、テーブル構造、カラム名、そしてそれらのカラムがどのように接続されているかを理解する必要があります。もう一つ例を見てみましょう。これも同じデータセットからのものです。 今回は言語モデルに関連するメタデータスキーマも提供しました。すると、かなり素晴らしいクエリが生成されました。このクエリは実行可能ですが、問題は結果が0件になってしまうことです。データベースを確認してみると、 このデータベースでは国名ではなく国コードとして保存されていることがわかります。
これが示すのは、スキーマへのパーソナライズだけでなく、データとその形式へのパーソナライズも必要だということです。では、テキストからSQLへの変換エンジンが、データの形式を理解するために、データベースに保存されているすべてのデータを読み込んで処理する必要があるのでしょうか？必ずしもそうではありません。データベースで過去に実行されたクエリを見るだけで、他のユーザーがこれらのフィールドにどのようにアクセスしているかについての良い洞察が得られます。例えば、この場合、データベースで実行された過去のクエリを見れば、ユーザーが国フィールドを使用する際には常に国名ではなく国コードを参照していたことがわかったはずです。
別の例を見てみましょう。 このクエリは意図した通りの動作をするはずですが、実行しようとすると、データベース内のcontestant numberというフィールドが曖昧であるというエラーが表示されます。 SQLに詳しい方はすでにご存知かもしれませんが、カラム名を指定する際は、必ずテーブル名を前につける必要があります。これによってクエリエンジンは、どのカラム名を参照しているのかを理解できます。このことから、自然言語からSQLへの変換プロセスでも、SQLの文法の細かい部分や、クエリを正しく構築する方法を理解する必要があることがわかります。これこそが、クエリエンジンに合わせたパーソナライズが必要だと私が言う理由です。
これら3つの例を見ると、言語モデルをそのまま使用するだけでは、自然言語からSQLへの変換で高い精度を達成することはできないということがわかります。そして、これこそがKnowledge Baseチームが解決しようとしている課題なのです。その仕組みを見ていきましょう。 まず、Amazon Bedrock Knowledge Baseは、データベースのメタデータにアクセスし、データベーススキーマを取得し、過去に実行されたクエリを分析し、さらにお使いのクエリエンジンのSQL文法について深く理解します。
使用しているクエリエンジンのSQL文法を深く理解することで、お客様の特定のデータ構成に合わせてカスタマイズされたクエリを生成することができます。もしAmazon Bedrock Knowledge Basesが生成するクエリにまだ満足できない場合は、プラットフォームが提供するクエリ設定オプションを使用して、SQLの生成プロセスをさらにカスタマイズすることができます。カスタム語彙を追加したり、例を提供することで高度な複雑なクエリを組み込んだりすることができます。これらの機能の詳細については、デモのセクションでご紹介します。
Amazon Bedrock Knowledge Basesの設定とデモンストレーション
Amazon Bedrock Knowledge Basesは本質的に会話型の性質を持っており、セッション管理機能が組み込まれているため、データベースとのやり取りがより自然になります。これらすべてを組み合わせることで、パーソナライズされ、コンテキストを理解し、安全な、完全マネージド型の構造化データ検索を提供することができます。安全というのは2つの意味があります。1つ目は、BedrockがSQLデータベースからデータを読み取ったり移動したりすることは決してないということ、2つ目は、Bedrock Knowledge Basesで処理されるデータは、 SQLクエリの生成や実行のためであっても、サービス改善のために保存や使用されることはないということです。
それでは、セッションのデモパートに移りましょう。ここでは、いくつかの録画されたデモをご覧いただきます。 このデモではAWSコンソールを使用しますが、ご紹介する内容はすべてSDKを使用しても実行できます。Knowledge Basesは、コンソールのBuilder Toolsセクションにあります。始めるには、まず「作成」をクリックする必要があります。今週現在、作成できるKnowledge Basesには3つのタイプがあります。Vector StoreとKendra GenAI Indexは非構造化データ向けですが、今日のデモで注目するのは構造化データ用のKnowledge Basesです。
最初の設定では、リソースの名前を選択し、説明を追加する必要があります。これらは後からいつでも編集可能な管理用の設定です。私は"reinvent-demo"という名前を選択して次に進みました。次はQuery Engineの設定です。現時点では、Amazon Redshiftが唯一の選択肢となっています。もちろん、ここで止まるつもりはなく、他のQuery Engineもサポートしていく予定です。もし具体的に興味のあるものがありましたら、後ほどぜひお声がけください。
次はIAMパーミッションです。Bedrock Knowledge Baseを作成する際は、必ずIAM Roleを指定する必要があります。このIAM RoleはBedrockがデータとやり取りする際、つまりデータへのアクセスやクエリの実行に使用されます。このIAM Roleには、クエリの実行とデータの読み取りに必要な適切な権限が付与されている必要があります。IAM Roleは自分で作成して指定することもできますし、コンソールに作成を任せることもできます。最後に、他のAWSリソースと同様にタグ設定のオプションがありますが、今回のデモではスキップします。
次のページでは、データの保存場所とクエリの方法に焦点を当てています。最初の設定は、Query Engineの選択についてです。現在はAmazon Redshiftのみを提供しているため、RedshiftのServerlessかProvisioned Clusterのいずれかを選択することになります。これはあくまでもQuery Engineの選択であり、データは別の場所に置くことができます。私はこのデモ用に既にProvisioned Clusterを作成していますので、それを使用することにします。次のセクションは、BedrockがRedshiftと通信する際の認証メカニズムについてです。Redshiftは3種類の認証メカニズムを提供しており、私たちはそのすべてをサポートしています。ユースケースに合わせて選択できます。今回はSecrets Managerを使用します。つまり、特定の権限を持つデータベースユーザーを既に作成済みということです。
そのユーザー名とパスワードをSecrets Managerに保存し、Amazon BedrockがAmazon Redshiftにアクセスする際に使用できるようにSecrets Managerを提供します。
設定の最後のセクションは、実際のデータの保存場所に関するものです。RedshiftのWorkgroupやProvisioned Cluster内にあるテーブルであるAmazon Redshift Managed Storageを使用することも、AWS Glue Data Catalogとの統合を利用して、例えばAmazon SageMaker Lakehouseや S3のテーブルなど、任意のテーブルを持ち込んでクエリを実行することもできます。今回のデモでは、より簡単な方法を選択し、既に作成済みのClusterのデータベースを使用することにします。
これらは先ほど説明した高度なクエリ設定です。デフォルトの精度に満足できない場合や、クエリ生成プロセスをさらに細かくカスタマイズしたい場合に役立ちます。例えば、テーブル名から何を保存しているのかが分かりにくい場合や、カラムの用途が不明確な場合に自然言語での説明を追加できる「descriptions」という機能があります。次に「inclusion/exclusion filter」があり、これはBedrockのクエリ生成時の検索範囲を絞り込むのに役立ちます。このKnowledge Baseを使用する際に、特定のテーブルのみを使用する、あるいは特定のテーブルやカラムを使用しないように指定できます。最後に「curated queries」がありますが、これについてはデモの後半で説明します。
このページでは、すべての設定内容を確認することができます。問題がなければ、そのままボタンをクリックするだけです。 レビューページでCreateボタンをクリックすると、コンソールが自動的にIAM Roleを作成し、Knowledge Baseも作成します。ご覧の通り、Knowledge Baseは作成されましたが、まだクエリを実行できる状態ではありません。もう1つ必要なステップがあります。
それは、Knowledge Baseの同期です。同期するには、クエリエンジンを選択してSyncボタンをクリックするだけです。 同期中、Bedrockはメタデータ、スキーマ、テーブルスキーマ、 そしてデータベースの過去のクエリをすべて取得し、実行時にSQLクエリを生成するために使用される知識ベースをバックグラウンドで構築します。この処理では実際のデータはコピーせず、テーブルに関連するメタデータのみを取得することに注意してください。
同期が完了したので、テストの準備が整いました。参考までに、先ほどRonが紹介したのと同じモックデータベースを使用しています。先月の最も売れた商品について、同じ質問をしてみましょう。まずは、Bedrock Knowledge BasesがサポートするエンドツーエンドのRAGフローをテストしてみましょう。これは、Bedrock Knowledge Basesからの取得だけでなく、レスポンスの生成も行います。 そのためには、まずFoundation Modelを選択する必要があります。これは Redshiftから取得したレスポンスを要約するために使用されるモデルです。
高度なクエリ設定とカスタマイズオプションの実践
「2024年11月の最も売れた商品は何ですか？」と質問してみましょう。現在、SQLを生成し、そのSQLを実行し、言語モデルを使用してプロンプトを要約しているところです。 データベースによると、カーシートカバーが最も売れた商品であることがわかりました。他の機能と同様に、このレスポンスの生成に使用されたSQLクエリが引用として返されます。このデモで次に行った質問は、この会話体験の文脈的な性質を示すためのものでした。例えば、「最も売れた商品の現在の在庫数はいくつですか？」というフォローアップの質問をしました。
Bedrockは対象のProduct IDを理解し、適切なクエリを生成して正しい数量を返しました。ここまでRetrieval and Generationのエンドツーエンドのフローを見てきましたが、時にはエンドツーエンドではなく、より手動で自分独自のOrchestrationフレームワークを構築したいと考えることもあるでしょう。
必要なのは、Bedrockにただ検索をしてもらうことだけかもしれません。そのような場合は、をBedrockのRetrieve APIと統合することができ、これからそのデモをお見せします。コンソールでこれを行う場合、構造化データベースで提供している様々な抽象化レイヤーを見つけることができます。では、デモのRetrieval部分に移りましょう。同じ質問をしますが、今回はSQLを生成し、SQLを実行して、単にそのままの行を返すようにします。
ご覧の通り、これが返された行で、これは前のステップで自然言語の応答を生成するためにLLMが使用したものとまったく同じです。現時点でのUIについてはご容赦ください。コンソールの改善にまだ取り組んでいる最中です。数週間後には、より見栄えの良い体験をご提供できるはずです。次に、同じことを行いますが、今回はクエリを実行しません。というのも、時にはSQLクエリを直接確認したいだけで、そのクエリを実行したくない場合もあるからです。
このリリースの一部として、Generate Query APIという新しいAPIをローンチしました。このAPIは構造化Knowledge Baseに対してのみ使用でき、自然言語の質問に対応するSQLクエリを返します。これは実際に、先ほどの2つのデモで使用されたSQLクエリです。これは期待通りに動作する幸せなケースシナリオを見てきました。しかし、Bedrock Knowledge Baseが生成するものに満足できない場合はどうでしょうか？さらに改善したい場合はどうすればよいでしょうか？
そのような例を見てみましょう。このデモのために、私は意図的にOrderテーブルに3つの曖昧な列を追加しました。それらの列はTS1、TS2、TS3と名付けました。これらは注文履歴のライフサイクルにおける3つの異なるタイムスタンプです。Bedrock Knowledge Baseに、注文作成時間と出荷時間の時間差を尋ねてみましょう。Bedrockはデータベース内のこれら3つのタイムスタンプが何を意味するのか分からないため、間違った出力を生成しています。この場合の正しい答えは実際にはTS2マイナスTS1となるはずです。
このような例がある場合、どのように対処すればよいのでしょうか？必要なのは、Knowledge Baseにテーブル構造についてより多くのコンテキストを提供することです。そのために、Knowledge Basesのdescription configurationを活用します。Knowledge Baseを編集し、description configurationに移動します。ここでテーブル名、カラム名、そしてそのカラムが意味することを自然言語で説明を追加できます。ご覧の通り、TS1は注文作成時間、TS2は出荷時間、TS3は配達時間となります。
これはカラムだけに限定されません。ご覧の通り、カラムはオプションのフィールドです。そのため、テーブル名自体が分かりにくい場合は、テーブルに対しても自然言語での説明を追加できます。すべてを追加したら保存し、メインページに戻ってもう一度同期する必要があります。クエリ設定を変更するたびに、Knowledge Baseを再同期する必要があります。これはバックグラウンドで作成されたKnowledge Baseのナレッジバンクを新しい設定で更新するのに役立ちます。そして、同じクエリを再度試してみましょう。
今度は正しいクエリが生成されたことが分かります。これは、あいまいなカラム名やテーブル名がある場合や、カラム名に特定のカスタムロジックがあり、それを生成プロセスのワンショット学習として使用したい場合の良い例です。Ronが以前言及したもう一つの例を見てみましょう。Prestige Partnerという概念についてです。この会社では、Prestige Partnerは月間トップセラーを指し、つまり毎月のトップセラーにPrestige Partnerというタイトルが与えられます。
現時点では、BedrockはPrestige Partnerが何を意味するのか分かっていないので、この質問をしたときにどうなるか見てみましょう。予想通り、Prestige Partnerの意味のコンテキストを持っていないため、生成されたクエリは10月のトップセラーではなく、10月に登録されたセラーを出力します。これはCurated Queriesが非常に役立つシナリオです。Curated Queriesには2つの良いユースケースがあります。1つはこのようなカスタム用語がある場合や、複雑なSQLクエリがあり、すぐには良い精度が得られない場合です。
この例では、「10月のPrestige Partnerは誰でしたか」というサンプルクエリを使用します。すでにクエリを書いているので、ここに貼り付けます。このクエリは実際にトップセラーの役割を返します。保存して、再度同期する必要があります。これがCurated Queryの単なる検索ではないことを示すために、今回はBedrockに11月のPrestige Partnerについて質問してみます。クエリが生成されると、Bedrockは以前のCurated Query例から学習し、日付を11月に置き換えることがわかります。説明した通り、11月の月が含まれています。これで、ユースケースに応じたクエリ生成プロセスをカスタマイズする2つの高度な方法について説明しました。
さらに、安全性が非常に重要になることも認識しています。データの上にチャットインターフェースを構築する際は、意図しないクエリがデータベースで実行されないよう注意が必要です。そこで、データ変更クエリを検出する機能を追加し、そのようなクエリはシステムによって自動的にブロックされるようになっています。デモでいくつか例を見てみましょう。このチャットボットにテーブルの削除を依頼してみると、 Bedrock Knowledge Baseは読み取り以外のSQLが生成されたためにクエリを実行できないというユーザーエラーを表示します。 同様に、更新クエリを試みた場合も機能します。例えば、未配達の注文ステータスをすべて配達済みに変更するように指示すると、これもデータを変更するクエリとして検出され、システムによってブロックされます。
このようなデータ保護機能をシステムに組み込んでいますが、Knowledge Baseを作成する際に使用する権限は常に制限付きにすることを強く推奨します。これにより、意図しないクエリの実行を防ぐことができます。具体的には、データベースにアクセスするために作成したデータベースユーザーのIAM Roleは、ユースケースに必要な最小限の権限のみを持つべきです。これでデモセクションは終了です。ここで、デモで見てきた内容を振り返ってみましょう。 Knowledge Baseを構築する際の3つの設定タイプについて説明しました - 異なるクエリエンジンから選択でき、異なるデータストレージタイプから選択できます。データストレージとは、Amazon Redshiftのマネージドストレージか、SageMaker Lakehouseテーブルを取り込むことができるAWS Glue Data Catalogのいずれかを指します。
そして、IAMベースの認証かRedshift DBユーザーベースの認証のいずれかを選択できる認証メカニズムについて説明しました。次に、クエリのSQL生成プロセスをカスタマイズできる高度なクエリ設定について見ていきました。最後に、組み込まれている安全機能についてお話ししました。
まとめと今後の展望：カスタマイズされたAIエクスペリエンスの重要性
ここで、Ronに引き継ぎたいと思います。ありがとうございました。プレゼンテーションも終盤に近づいてきました。AmazonとAWSでは、お客様からの要望を基に製品開発を行うことを誇りにしています。現在、Bedrock Knowledge Base for Structured Dataを活用して開発を進めているOctusとの協業を大変嬉しく思っています。彼らは自社の会話型チャットボットであるCreditAI製品を強化し、独自のデータベースからデータを取り込めるようにしました。また、独自のMaster Data Managementソリューションからデータベースのメタデータも取り込んでいます。彼らがBedrock Knowledge Basesを使って今後どのようなものを構築していくのか、とても楽しみにしています。
まとめとして、ビジネスにおいてカスタマイズされたAIエクスペリエンスがいかに重要であるかについて説明しました。AIエクスペリエンスをカスタマイズする4つの方法を見てきましたが、その1つがRetrieval Augmented Generation（RAG）です。これは、Foundation Modelに従来のデータソースから最新の情報へのアクセスを提供することです。S3からのドキュメントやデータベースエンジンからのデータが対象となります。非構造化データは、Semantic Searchで最適に処理できると考えており、この手法は常に重要性を持ち続けます。一方、構造化データは、デモでご覧いただいたような自然言語からSQLへの変換でも処理できます。Bedrock Knowledge Basesは、両方のタイプのデータを扱えるRAGワークフローを統合管理するフルマネージドサービスです。
次のステップとして、皆さんの多くが帰国便を予定されていることと思います。週末にお時間があれば、ぜひ Amazon Bedrock Knowledge Basesを試してみてください。まだアンケートにお答えいただいていない方は、ぜひご回答をお願いします。また、具体的なご質問がございましたら、SaketとPrivate、この後も会場の端で待機していますので、お気軽にお声がけください。皆さまのユースケースについてお伺いできれば幸いです。ご参加いただき、誠にありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion