re:Invent 2024: Amazon Bedrock Knowledge Basesで構築するRAGアプリ
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Build scalable RAG applications using Amazon Bedrock Knowledge Bases (AIM305)
この動画では、Amazon Bedrock Knowledge Basesを活用したスケーラブルなRAGアプリケーション構築について解説しています。Amazon BedrockのPrincipal Product ManagerのMarcelo Silvaが、Knowledge Basesの進化と新機能を紹介し、EnverusのMayank PatelがInstant Analystプラットフォームの構築事例を共有します。さらに、AWSのMani KhanujaがStructured Data Retrieval、GraphRAG、Foundation Model Parserなどの高度なテクニックを説明します。特に、25年分のデータを扱うEnverusの事例では、Infrastructure as Codeの重要性や、52,000人以上のユーザーを1四半期未満で導入した実績など、具体的な成功要因が示されています。RAGアプリケーションの構築において、小規模からスタートし、データ戦略を立て、継続的に改善していく方法論が詳しく解説されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon Bedrock Knowledge Basesの進化と本セッションの概要
こんにちは。スケーラブルなRAGアプリケーションの構築方法について学びにいらっしゃったことと思います。私はAmazon Bedrockのプリンシパルプロダクトマネージャーを務めるMarcelo Silvaです。本日は、皆様が60分のお時間を割いて、私たちの話を聞き、本日のキーノートで発表されたAmazon Bedrock Knowledge Basesに関する新機能についてご確認いただけることを、大変光栄に思います。本日は、EnverusのMayank PatelとAWSのMani Khanujaの2名の同僚も登壇します。
それでは始めましょう。今日は盛りだくさんの内容です。デモやハンズアップしていただく双方向のQ&Aもご用意しています。まず、Knowledge Basesの現状と、この1年の歩みについて概要をお話しします。次に、本日発表された機能と12月1日に発表された機能について説明します。さまざまなお客様との経験についてお話しし、EnverusがRAGアプリケーションを構築する過程についてもご紹介します。また、私たちが開発した方法論や、成功事例から得られたベストプラクティスについても取り上げます。その後、高度なテクニックに進み、Maniが本日の発表内容について詳しく説明します。素晴らしいデモもご用意していますし、最後には皆様に挑戦していただきたい課題もあります。
RAGの基本概念とAmazon Bedrock Knowledge Basesの成長
RAGについては皆様ご存知だと思いますが、もし別の講演と間違えて入室された方がいらっしゃるかもしれませんので、RAGについて説明させていただきます。モデルをカスタマイズする方法には、Fine-tuningによる出力のカスタマイズ、継続的な事前学習、そして最も一般的な方法の1つである、組織固有のデータに基づいてモデルの出力をコンテキスト化する方法があります。このデータには、音声、テキスト、画像など、構造化・非構造化データを含めることができます。Retrieval Augmented Generationでは、実行時に検索可能な独自のデータやコンテキストを追加し、クエリに基づいて拡張し、カスタムプロンプトやフィルタリングを導入して、モデルからレスポンスを生成することができます。
出力は必ずしもテキストである必要はありません。本日ご覧いただいたように、異なる種類の出力を生成できるマルチモーダルモデルが多数存在します。ただし、カスタマーエクスペリエンスやパーソナライズド検索に関する現在のユースケースの大半は、テキストで行われています。ドキュメントを取り込むデータ取り込みパイプラインを作成し、最終的に検索可能な埋め込みとしてそれらのドキュメントの表現を取得し、モデルの出力をコンテキスト化するための特定の情報を取得します。出力の種類に関係なく、モデルが伝える内容を、お客様独自のデータに基づいて根拠付けるのです。
昨年、私たちはRAGワークフローを作成するためのエンドツーエンドのマネージドサービスであるAmazon Bedrock Knowledge Basesをローンチしました。比較的シンプルな形でスタートし、会場にいらっしゃる多くの皆様のおかげで、現在の製品に成長することができました。本日は1社、Enverusにその journey についてお話しいただきますが、会場には多くの方々がいらっしゃいますし、現在Knowledge Basesを使用している何千ものお客様、そして私が日々やり取りをしている何百ものお客様が、この製品を形作ってきました。重要なのは、私たちが小さく始めて、本日ご覧いただいた高度なテクニックを含む、さまざまなテクニックを構築してきたということです。
Knowledge Basesの機能拡張とEnverusの事例
過去12ヶ月間の製品の進化についてご説明させていただきます。Knowledge Basesは、データを取り込み、それを検索可能な形式で表現することで機能します。これにより、モデルの出力に対してコンテキストとして活用することができます。つまり、パブリックな情報ではなく、社内文書や構造化データ、独自のデータに基づいた応答を得ることができるのです。
Knowledge Basesの素晴らしさは、そのAPIにあります。特にRetrieve APIとRetrieve-Generate APIは、バックエンドで使用するモデルやVector Databaseを変更することなく、自由に選択できます。本日の発表でもご覧いただいたように、現在ではRAG Evaluationも導入され、アプリケーションの構築、評価、改善を行うというパイプライン方式が完成しました。この方法論については後ほど詳しくお話しします。
皆様のご支援なしには、ここまで来ることはできませんでした。 この1年を振り返りますと、50以上の機能を開発してきました。これは素晴らしい成果です。AWSには最高の開発チームとサイエンスチームがいます。お客様のご要望を取り入れ、改良を重ね、アプリケーションをより迅速かつ正確に本番環境へ展開できる機能を作り上げてきました。Hybrid Search、Metadata Filters、SalesforceやConfluenceなどへのConnector、そして多くのお客様が話題にされているChunking Strategiesなどを導入しました。Chunking Strategyは単なる要件ではありません。使用するモデルに基づいて、目的の出力に最適な形でデータを表現する方法を検討する必要があります。
Hierarchical ChunkingやSemantic Chunkingを導入し、当初開発したFixed Chunkingに加えてCustom Chunkingも可能にしました。また、AWS CloudFormation、Terraform、SDKやCDKのサポートも提供しています。さらに、今年のNetwork Summitで発表した高度な機能として、画像やテキスト、複雑な表を含む文書からエンティティを抽出しカスタマイズできるFoundation Model Parserがあります。また、RetrieveとGenerate APIで使用できるCustom Promptsや、複雑なクエリを分解してMulti-step Searchのように異なる部分を理解できるQuery ReformulationとDecompositionも導入しました。
今週は多くの発表がありました。詳細についてはManiが説明しますので、ここでは触れませんが、いくつかピックアップしてお話しします。一つはStructured Data Retrievalです。昨年、Agentを使用してKnowledge Basesに構造化データを追加する方法について説明しましたが、製品進化の方法論に従って、Knowledge Baseをカスタマイズできる機能を開発しました。最終的に、データソースの取り込みや最適化技術の開発における負担を軽減し、アプリケーション全体をより良く、より効率的にする組み込み機能を作成しました。Structured Data Retrievalを導入し、Maniがその詳細を説明します。さらに、既存のManual Filtersに加えて、クエリから自動的にフィルターを生成するAuto-generated Query Filtersを導入しました。また、Rerank APIもリリースしました。
Rerank APIを使用すると、データを取得する際に最も優先順位の高いコンテンツを得るために、検索結果の後処理を行うことができます。これには、取得されたすべてのチャンクを検証し、その中から最も関連性の高いチャンクを特定して優先順位をつけるランカーモデルが含まれています。優先順位付けされたチャンクは、より良い回答を得るためにLarge Language ModelやFoundation Modelに送られます。また、Maniが後ほど説明するGraphRAGもあり、これによってナレッジベースのソースの1つとしてNeptuneをGraph DBとして使用し、多くのドキュメントやデータソースにまたがる様々なタイプのデータ間のリンクやグラフを作成することができます。
Streaming responsesも12月1日にリリースされました。Foundation Modelが生成する回答全体を待つ必要がなくなり、最初のトークンまでの時間が短縮され、Foundation Modelが回答を生成する際にタイピングのような体験で次々とトークンを受け取ることができるようになりました。これにより、モデルやアプリケーションのパフォーマンスが大幅に向上します。先ほど触れたように、RAG evaluationとLLM judgeまたはLLM as a judgeをリリースしました。これにより、アプリケーションの作成、レスポンスの妥当性評価、そして改善のための反復というサイクルを完結させることができるようになりました。
スケーラブルなRAGアプリケーション構築の方法論
これは私のプレゼンテーションの中で最も重要なスライドだと思います。ここでお話ししたいのは、お客様がスケーラブルなアプリケーションを構築する際に私たちが観察してきたことについてです。まず一般的な観点からお話しし、その後、Membersの Mayanが、この方法論を一緒に構築することができた彼らの journey についてお話しします。RAGアプリケーションでは、データ戦略が不可欠です。様々なドキュメントや異なるタイプの構造化データを扱うことになります。これらの構造化データドキュメントには、マニュアル、財務諸表、きれいにフォーマットされたPDF、CSVファイル、スプレッドシート、その他様々な種類があります。
構造化データを扱う際には、データのタイプとChunking戦略の両面から適切なデータ戦略を持つことが重要です。Foundation Modelの応答を適切にコンテキスト化するために、アプリケーションに投入するデータの準備と変換が極めて重要です。そのため、RAGインフラストラクチャの観点からデータの準備が非常に重要になります。また、レイテンシーの観点や、モデルの持つ様々な機能の観点から、ModelとVector Databaseの選択も非常に重要です。モデルには会話に適したものや計算処理に適したものなど、様々なタイプがあり、ユーザーが何をしたいのかを理解しておく必要があります。
ユースケースとPOCを決定したら、私たちが見てきた中で最も重要なのは、小規模でシンプルに始めることです。初日から50以上ある機能のすべての機能を有効にしないでください。そうすると、余分なコストがかかり、レイテンシーが発生し、何がアプリケーションのパフォーマンス、精度、リコールに影響を与えているのかわからなくなってしまいます。現在はRAG evaluationを使用して、応答をJudgeと比較し、その応答が期待通りのものか、会社のセキュリティガイドラインに適合しているか、ブランドのコンプライアンスや規制要件を満たしているかを判断することができます。それらが確認できたら、デプロイしてユーザーに使ってもらうことができます。特に強調したいのは、これらのChatbotとの対話で人々の行動が変化していることです。ユーザーは詳細な会話を好み、非常に会話的なやり取りを期待しています。
あらゆる種類の質問が寄せられることでしょう。そして、ユーザーがどこにいるのか、最初は全く見当もつかないでしょう。そこで、まずは小規模なものをデプロイし、ユーザーに提供しようとしているサービスの概念に慣れてもらい、評価を行い、必要に応じて変更を加え、継続的な改善プロセスとして再デプロイを行うというのが基本的な進め方です。
これから Mayank Patel が Enverus のデモを通じてお見せするのは、スケーラブルなインフラストラクチャに基づいていなければならないということです。つまり、小規模からスタートして複雑なものへと進化させる際、異なるデータタイプや構造化データ、その他の要素を追加していく中で、プラットフォームがより複雑になり、大規模化し、より多くのドキュメントが取り込まれ、より多くの顧客が参加してきても、インフラストラクチャを変更する必要がないように準備しておく必要があるということです。
Enverusが実践したInstant Analystの開発プロセス
それでは、Knowledge Base を使用した RAG アプリケーションの構築における journey についてお話しいただくために、Enverus の Mayank Patel をご紹介したいと思います。ありがとうございます、Marcelo。ありがとうございます。みなさん、こんにちは。まず、自己紹介をさせていただきます。私は Enverus の Distinguished Architect を務める Mayank Patel です。 Enverus は、エネルギー分野全般にわたるソリューションを提供する大手プロバイダーです。サプライチェーンのバックオフィス、電力および再生可能エネルギー取引など、あらゆる種類のソリューションを提供しています。本日は、AWS のパートナーシップを通じて Marcelo や Mani とともに取り組んできた journey、そしてスケーラブルな RAG プラットフォームである Instant Analyst の構築アプローチについてお話しできることを大変嬉しく思います。
まず、今日誰もが直面している課題についてお話ししましょう。それは、生データと、創出したい価値との間にあるギャップです。 エネルギー業界には膨大なデータが存在し、その中に価値が埋もれています。これが情報の断絶を生み出しているのです。そしてこの問題を解決するのは、インテリジェントな接続を通じてなのです。 この問題を解決することで、私たちが顧客に提供できるのは、エネルギーの予測や将来に関して彼らができることの新しい価値、新しい可能性を解き放ち、業界に価値を提供する journey を形作ることです。
このギャップを埋めることは、エネルギー企業だけでなく、エネルギーを消費するエンドユーザーにとっても大きな恩恵となります。そのため、Enverus はあらゆる取り組みの中心に、 技術革新を推進する力強いミッションを掲げています。私たちは、エコシステム全体にわたってエネルギーの民主化を進めています。先ほど申し上げたように、大手生産者から小規模サプライヤーまで、金融機関やグローバルトレーダー、地域事業者など、あらゆる方々が私たちのソリューションと様々なサービスを利用しています。質の高いデータが意思決定を導くとき、エネルギーは誰にとってもより手頃で、信頼性が高く、よりクリーンなものとなります。これこそが Enverus におけるイノベーションを推進する原動力であり、グローバルな生活の質を向上させることにつながっているのです。
それでは、Instant Analystをスケーラブルで柔軟なソリューションとして構築することで、すでに達成している規模とインパクトについてご紹介させていただきます。Enverusの強みを示す数字が、Energy Intelligenceにおける規模と変革について驚くべきストーリーを語っています。その理由をご説明しましょう：エネルギー生産者の98%と35,000社以上のサプライヤーがプラットフォームを利用しています。彼らは、製品スイート全体と様々なサービスの中の1つの製品だけでも2,000億ドル以上の支出を処理することを信頼しており、5,000社以上のエネルギー企業と300社以上の金融機関が、Enverusを毎日利用しています。
Instant Analystに焦点を当ててみましょう。私たちのエキスパートアナリストは、構造化データと非構造化データを組み合わせた25年分のSEC認証済みの情報を提供しています。ここで一つのシナリオについて考えてみましょう。皆さんも経験があると思いますが、何かを調査しようとして、膨大なデータの中から必要な情報を集め、見つけ出し、統合して、最終的に意思決定ができるようになるまでの過程です。これは、まさに私たちのお客様が直面している課題なのです。
私たちは多くの業界調査レポートを提供していますが、各レポートを読むのに10～15分かかります。ルイジアナ州で新しい油井を掘削しようとしている生産者が、規制の変更を理解したいと考えた場合を想像してみてください。彼らは各レポートを読み、フォローアップして意思決定を行う必要があり、それには数日から数週間、あるいはそれ以上の時間がかかります。Instant Analystを使用することで、ユーザーの作業時間を短縮し、多くのお客様の効率性を向上させることができます。Instant AnalystはRAGプラットフォームを通じて25年分のデータをサポートしており、ユーザーは引用付きで事実に基づく回答を得られるため、データの検証が可能です。このソリューションにより、1四半期未満で52,000人以上のユーザーをInstant Analystに導入することができました。
では、Enverusの取り組みについてご説明します。Marceloは方法論について話しましたので、Instant Analystのための体系的な取り組みについて説明させていただきます。私たちは、スケーラブルで柔軟なソリューションを構築するために、5つの重要なフェーズを設定しました。まず第一に、プランニングと戦略です：ビジネスビジョンを持ち、それに基づいて戦略を構築します。アイデアを早期に検証し、業界の反応を待って長期的なプロセスを経るようなことは避けます。適切なチームと文化が確立されていることを確認します。これは、ビジネスからエンジニアリングチームまで、組織の上から下まで全員が変化をサポートし、受け入れる必要があります。
Generative AIは、アプリケーション開発と統合の方法が根本的に異なります。私たちは常にInfrastructure as Codeに重点を置いています。ここにいる多くの方々は、自社のデモアプリケーションを構築した経験があり、その結果がどうなるかご存知でしょう - デモが本番ソリューションになってしまうのです。そのため、デモが製品になった時にスケールできるよう、最初からインフラストラクチャの自動化から始めることが重要です。Generative AIの議論になると、誰もがアルゴリズムや科学的研究を主な要件と考えがちです。しかし、エンジニアリングアーキテクチャのオーケストレーションを必要とする要素が他にもたくさんあります。メモリベクターストアやAWS統合を含む、スケーラブルなRAGアプリケーションを構築する際に重点を置くべきはそこなのです。
開発プロセスにおいて最も重要な点は、AWSのアカウントチームとのパートナーシップを築き、設計と実装の妥当性を確認することです。課題が発生した際は、BedrockやAWSの各チームと共有し、様々なソリューション、サービス、設計パターンについてのガイダンスを受けることができます。Generative AIアプリケーションの構築において、テストと検証は最も重要な要素となります。 Generative AIに携わる方々は皆さん、AIが生成するレスポンスやコンテンツのテストが非常に難しいということに同意されると思います。私たちは3つの異なる観点からアプローチを行いました。まず、すべてを完璧にしようとせず、最適な顧客を見つけて市場テストフェーズに持ち込むことに注力しました。幸運なことに、2ヶ月足らずで何百もの顧客がInstant Analystプラットフォームにサインアップし、通話やシステム、アカウント担当者を通じて貴重なフィードバックを提供してくれました。また、Infrastructure as Codeのテストにも注力し、異なるVector Store、設定、Embedding ModelをA/Bテストで並行して複数のKnowledge Baseをデプロイしました。これにより、ユーザーは比較して好ましいソリューションやレスポンスを教えてくれ、市場からのフィードバックと、どの設定が最適かのA/Bテスト検証を得ることができました。
評価については、当初はRAGメトリクスを提供するオープンソースのRagasフレームワークを使用しました。エンド・ツー・エンドのソリューションを実装しましたが、開発のオーバーヘッドが大きくなりました。最近発表されたRagas 2.0は完全な刷新版であり、開発チームは評価フレームワークの再実装に多くの時間を費やす必要がありました。そのため、先ほどMarceloが紹介したモデル評価とLLMをジャッジとして使用する機能に特に期待しており、これらの機能を試すことを楽しみにしています。
Instant Analystの技術的詳細とデモンストレーション
プラットフォームとセキュリティに関して、AIが関係する場合、セキュリティは極めて重要な懸念事項となります。 私たちがAmazon Bedrockを特に評価している理由は、データが仮想プライベートネットワーク内で保護され、外部に流出することがないためです。サードパーティのAPIを呼び出したり、他の場所でモデルをホストしたり、セキュリティチームの懸念事項に対処したりする必要がないため、Amazon Bedrockは理にかなった選択肢となります。テストと検証から得られたフィードバックを基に、私たちは継続的にシステムを反復的に最適化しています。
プラットフォーム開発において、Enverusで構築するものはすべてスケーラビリティを重視しています。各ユースケースごとにプロセスを最初から始めるのではなく、複数のユースケースに対して容易にスケールできるシステムを設計したいと考えています。Instant Analystでもこのアプローチを採用しました。設定をコアモデルとして設計したため、Research Intelligence データに関する最初のRAGユースケースを構築した後は、6～8ヶ月以上かかっていた新しいユースケースを数時間から数日で私たちのプラットフォームに導入できるようになりました。
製品が好意的なフィードバックを受け、良好な精度を達成できたと確信できたら、GA（General Availability）ローンチの準備を進めます。 しかし、それが旅の終わりではありません。製品のステークホルダーやビジネスの顧客がより複雑な要件を持ち込んでくるため、改善のサイクルは続きます。異なるタイプの質問への対応や、様々なデータタイプの統合など、このパターンを何度も目にしてきました。私たちのシステム設計では、 あらゆる段階でスケーラビリティと柔軟性を優先し、Infrastructure as Codeの検証と評価を自動化された方法で実装しています。これにより、Instant Analystに新しいユースケースや機能を迅速に導入することが可能になっています。
スケーラブルなアーキテクチャの構築を進める中で、 多くの企業が経験したであろう重要な技術的課題に直面しました。具体的には、ユースケースやデータタイプに適したChunking戦略の選定、APIコールを通じたプライマリソースシステムからVector Storeへのデータ同期の維持、そしてAPIの制限やエラーを回避するための適切なThrottlingやバックプレッシャー制御の実装などです。これらの機能の実装には、チームの多大な開発工数が必要でした。さらに、RAGソリューションや他のGenerative AIアプリケーションにおいて、Retrieverの精度は決して100%にはならず、常に改善の余地があります。AWS チームと協議した結果、Amazon Bedrock Knowledge Basesが解決策となることがわかりました。
Amazon Bedrock Knowledge Basesは、TerraformによるInfrastructure as CodeとA/Bテスト機能を提供し、同じデータに対して異なるChunking設定や埋め込みモデルを使用した複数のKnowledge Baseを並行してデプロイすることができます。これにより、データに基づいた統計的な意思決定が可能になります。個別の反復作業に時間を費やすのではなく、並行して素早くデータドリブンな判断を下すことができます。Amazon Bedrock Knowledge Basesは同期処理も担当し、データを同期状態に保ちます。データの更新や削除などの操作が発生した場合、Throttlingの手動管理は不要で、これらの機能はBedrock Knowledge Basesにネイティブに組み込まれています。
検索精度に関しては、Hybrid SearchとMetadata Filteringを提供しています。これらの技術は、私たちのシステムに対する様々な機能要望やニーズに応え続けてくれたAmazon Bedrockチームとの連携とパートナーシップから生まれました。精度向上に向けた彼らの継続的なサポートには本当に感謝しています。
Instant Analystのハイレベルアーキテクチャについて詳しく見ていきましょう。 これは100%サーバーレスなイベントドリブンアーキテクチャです。手動操作やポーリングメカニズムは避けています。このアーキテクチャにより、アナリストが私たちのプラットフォームにリサーチレポートを公開してから5分以内に、Vector Storeのためのデータ準備に様々な技術を用いたデータ取り込みパイプラインを通過します。このRAGへのデータ取り込みは非常に重要です。なぜなら、入力データの品質が悪ければ出力も悪くなるからです。様々な方法でクエリを実行して必要な情報を取得できるよう、データはVector Store内で適切に強化される必要があります。
このアーキテクチャには3つの主要な焦点があります。1つ目は、構造化・非構造化データを含む様々なフォーマットからの情報取得です。PDF、JSON、CSV、さらにはオーディオやビデオフォーマットもサポートしています。2つ目はクリーンアップセクションで、自動データクリーンアップとHuman-in-the-loopプロセスが含まれます。データがパイプラインを流れる際、Vector Storeへの自動処理を経て、必要に応じて人間のレビュアーがデータを強化できます。最後のパートは、選択したインデックスへのデータのベクトル化です。
先ほど申し上げた通り、これはAWS Lambda関数とSNSを活用した100%サーバーレスのアーキテクチャです。データ取り込みパイプラインでは、Amazon TextractとAmazon Bedrockを使用しています。表、チャート、さまざまな構造化・半構造化コンテンツを含むPDFデータに対しては、Amazon TextractでOCRを行い、JSON形式で出力を得ています。その後、標準フォーマットに変換し、自動化された処理と人間によるレビューを組み合わせたプロセスを経て、Amazon Bedrockを活用してコンテキストを強化してからVector Storeに格納します。当初はAmazon Kendraを使用していましたが、システムが成熟し、さまざまなアルゴリズムでVector Storeをより詳細に制御したいと考えたため、後にBedrock Knowledge Baseを通じてOpenSearchに移行しました。
検索側では、拡張と生成のために、OpenSearchを実装してOpenSearch LangChainレトリーバーを活用することで、セマンティック検索機能を実現しました。しかし、ニーズが拡大するにつれて、より多くの機能が必要になりました。メタデータフィルタリングにより、データとビジネスに関する広範なメタデータが提供されます。
Instant Analysisを通じたクエリをサポートするために、大量のメタデータと顧客情報を処理できるソリューションが必要でした。OpenSearchとLangChainはハイブリッド検索を直接サポートしていないため、Amazon Bedrock Knowledge BasesのRetrieve APIを活用する方式に切り替えました。Retrieve APIは任意のVector Storeに対する優れた抽象化レイヤーを提供し、異なる設定で複数のVector Storeを作成しながら、同じRetrieve APIを使い続けることができます。Vector Store間の切り替え時にコードを変更する必要がないのは、Retrieve APIがその抽象化を処理するためです。また、セマンティック検索とハイブリッド検索の機能や、暗黙的・明示的フィルターなど、多くの利点ももたらします。
では、Pre-retrieval、Retrieval、Post-retrievalという3つの重要なステージを通じて、精度をどのように向上させているかを見ていきましょう。Pre-retrievalステージでは、クエリの強化とクエリパース機構によるクエリからの情報抽出に焦点を当てています。これらの機能は当初、自社開発のソリューションとして実装しました。後にAmazonとパートナーシップを組み、これらの機能をAmazon Bedrock Knowledge Baseに組み込んで、誰もが使えるようにしたいと考えました。そのようにして、機能要望やソリューションをAWSチームに提供することで貢献しました。クエリのパース、書き換え、用語の拡張による再構築は非常に重要です。なぜなら、ユーザーのクエリから特定のメタデータ情報を抽出し、検索時に暗黙的に適用することで、精度の向上につながるからです。
Retrievalステージでは、暗黙的・明示的フィルターの組み合わせをサポートするハイブリッド検索とダイナミックフィルタリングを行い、アンサンブル技術により異なるメカニズムからのデータを組み合わせます。Post-retrievalについては、25年分のデータを扱う中で課題に直面しています。何千何万もの文書にわたって用語や意味が異なるため、特定の質問に対する回答を得ることが困難な場合があるのです。Re-rankingは、コンテキストに対する関連性に基づいてチャンクの優先順位付けを行うため、非常に重要です。3年前のレポートや数週間前の情報など、特定の期間に関する質問をされた場合、時間的な新しさと関連性が重要になります。履歴的なコンテキストを失うことなく、システムを通じて関連性と新しさを適切に処理することが不可欠です。最後に、Streamingにより、モデルが最初のレスポンストークンを生成した時点で情報を配信することで、シームレスなユーザーエクスペリエンスを実現しています。
主なポイントとしては、完全に統合されたAmazon Bedrockの利点が挙げられます。 これにより、セキュリティと高いパフォーマンスが提供されます。私たちは、サードパーティを介してLLM APIをホストしたりアクセスしたりするよりも、Bedrockの使用を好んでいます。ユーザーからは、調査に費やす時間が減り、本当に重要な意思決定により多くの時間を割けるようになったという声を頂いています。すべての情報は、アナリストが公開し、SECが検証した25年分のリサーチレポートなど、信頼できる情報源から得られています。AWS パートナーシップについて、スケーラブルなRAGソリューションを構築する方には、アカウントチームに相談し、Bedrockチームの担当者を招くことを強くお勧めします。私たちは2週間ごとの統合ミーティングを通じて、設計と実装のアイデアをAWSに提示し、検証とガイダンスを受けました。これにより、課題や機能要望をAmazonチームに持ち込み、Bedrock Knowledge Baseプラットフォームに組み込んで、誰もが利用できるようにするソリューションを提案することができました。
Instant Analystの実際の動作をお見せしましょう。お客様であれば、今すぐにご利用いただけます。Instant Analystのモバイルアプリケーションと、 Webを通じたInstant Analystプラットフォームをご用意しています。非常にシームレスな体験が得られ、 レイテンシーが非常に低く、瞬時に情報を得られることを実感していただけます。これにより、ユーザーは最初のステップを踏み出すことができます。これは、質問をしたり情報を得たりする方法の根本的な変革です。
どのような質問ができるかのイメージを掴んでいただくために、例題を用意しています。また、引用情報も利用可能です。私たちのモットーは「信頼しつつ、常に検証する」です。ユーザーは常に、特定のレポート、ページ番号、セクションにアクセスして、その情報の出所を確認することができます。それでは、この数日間にAmazonが発表した新機能について詳しく説明するために、Maniを壇上にお招きしたいと思います。この1年を通じて、Enverusでのさまざまな課題に対応し、多くの機能を実現してくれたManiに感謝の意を表したいと思います。ありがとう、Mani。
高度なRAG技術：マルチモーダル処理、構造化データ取得、GraphRAG
午後になり、セッションの50%以上が終了し、残り20分となりました。 皆さんがまだ元気で、眠くなっていないことを確認したいと思います。眠くても文句は言いませんが、私のパートだけは起きていてほしいですね。Mayankは多くのことを共有してくれました。そして、Enverusのような製品の形成に協力してくれるお客様がいることを、私たちは幸運に思っています。本日はご参加いただき、ありがとうございます。自己紹介を忘れていましたので、させていただきます。私はAWSのTechnical Lead Generative AI SpecialistのMani Khanujaです。本日は皆様とご一緒できることを大変嬉しく思います。スケーラブルなRAGアプリケーションを構築するための高度なテクニックについてお話しさせていただきます。MayankとMarceloは既に多くの内容を共有してくれましたので、さらに続きをお楽しみください。
彼らは、Proof of Conceptを構築することから始めて、それを本番環境に移行する方法や、ベストプラクティスについて話してくれました。私はそれを繰り返すつもりはありません。代わりに、RAGアプリケーションでマルチモーダルデータ処理をどのように実現できるかについてお話しします。これは重要な要素です。なぜなら、私たちのドキュメントはテキストだけではないからです。 皆さんご存知の通り、画像やテーブルがあり、それらのドキュメントには私たちがRAGアプリケーションで活用したい情報が多く含まれています。そのため、マルチモーダルデータ処理が重要になってくるのです。そして朗報として、これはAmazon Bedrock Knowledge Baseの一部として提供されています。完全マネージド型のソリューションです。必要なのは、データを持ち込み、Knowledge Baseの作成時にAmazon Bedrock Data AutomationまたはFoundation Modelをパーサーとして選択するだけです。
作業が完了したら、同期することを忘れないでください。同期しないと何も機能しません。ドキュメントを同期する、つまりVector Storeにドキュメントを取り込んだことを確認してください。取り込みが完了したら、質問するだけで、画像から回答が取得される場合は、引用に画像が表示されます。特別な作業をしなくてもこれが実現できるなんて、すごいと思いませんか？すべてをAWSが代わりに処理してくれます。これが、私たちが発表したすべての機能の中で、私が特に気に入っている理由です。これは、データのマルチモーダル性と、このマルチモーダルデータをどのように処理しているかということに関するものです。しかし、非構造化データだけでは解決できない質問や、このようなマルチモーダル性を導入するだけでは対応できない質問があったらどうでしょうか？例えば、「2024年11月の最も売れた商品は何ですか？」というような質問の場合はどうでしょう？そして、なぜこのような単純な質問を取り上げているのでしょうか？それは、データベースやData Warehouseの検索が必要になる可能性があるからです。
集計が必要になるかもしれません。期待される回答は「最も売れた商品はカーシートカバーです」というようなものでしょう。これはあくまで例で、実際の商品がこれである必要はありません。データベースの検索に基づいて、正しい商品と販売数量を取得する必要があります。
ここでまだRAGアプリケーションについて話していることを覚えておいてください。つまり、会話について話しているということです。会話を継続できるようにしたいのです。例えば、商品名を明示的に言及せずに「その商品の現在の在庫数はいくつですか？」というような質問をすることもあるでしょう。期待される回答は、前に議論された同じ商品を参照するはずです。しかし、ここでは非構造化ドキュメントについて話しているわけではありません。これにはデータベースの検索、集計、データスキーマの理解、そしてテーブル間の関係の理解が必要です。
このような質問に答えるためには、自然言語のクエリをSQLクエリに変換する必要があります。モデルやシステムがデータ、スキーマ、クエリエンジンを理解できなければ、それは不可能です。これを構築する際には多くの課題や複雑さがあります。構造化データへのアクセスはもはや類似性検索だけではなく、それ以上のものなのです。
今日、良いニュースがあります：Amazon Bedrock Knowledge Basesが構造化データの取得に対するネイティブサポートを提供するようになりました。これはどういう意味でしょうか？この機能を活用するために何をする必要があるのでしょうか？構造化データを使用してKnowledge Baseを構築し、データベースを接続したら、画面に表示されているような自然言語で質問することができます：「11月の最も売れた商品は何ですか？」複数のクエリについて考える必要がないように、最も売れた商品の例を使い続けることにします。
Knowledge Baseに自然言語で質問すると、まずSQLクエリが生成されます。そして、そのSQLクエリがあなたに代わってデータベースに対して実行されます。どのように実行されるのでしょうか？Marceloが説明した2つのAPIのうち、Retrieve APIを使用します。このRetrieve APIが生成されたSQLクエリを実行して結果を返してくれます。もしSQLの生成だけを行いたい場合は、Generate Query APIという別のAPIも用意されており、生成されたクエリだけを取得することもできます。
Retrieve APIを使用すると結果が返されますが、私たちはそれ以上のものを求めています - これだけではまだRAGアプリケーションとは言えません。もう1つ重要な要素があります：結果を要約して自然言語で回答を返し、ソースの帰属と引用を提供することです。この例でのソースの帰属と引用には、RetrieveとGenerate APIを使用して得られる生成されたSQLクエリが必要になります。
ユーザー体験がどのようなものか、クイックデモでご覧いただきましょう。最初のステップはモデルの選択です。この場合、私はClaude 3 Haikuモデルを選択していますが、他のサポートされているモデルを選択することもできます。選択が完了したら、質問をします：「2024年11月のトップセラー商品は何ですか？」この質問をすると、3つのことが行われます。まず、SQLクエリが生成され、次に、そのSQLクエリがデータベースに対して実行され、最後に結果が要約されて回答が提供されます。
回答は自然言語で提供されます。フォローアップの質問もできます。例えば、「その商品の現在の在庫レベルはどれくらいですか？」と質問すると、会話履歴が保持されているため、セッションIDなどを管理する必要なく結果が返されます。このように、私たちがすべての重労働を代わりに行うと言える理由がここにあります。
ここで、この機能が気に入った方は手を挙げていただけますでしょうか。素晴らしいですね。もしこの機能が気に入ったなら、これから私が話すことにも興味を持っていただけるはずです。先ほど説明したデータソースだけを見たい場合は、「Retrieve data sources only」を選択して質問してください。完全な応答ではなく、検索結果だけが表示されます。クエリが生成され、実行されて、結果が返されます。生成されたクエリだけを見たい場合は、RetrieveとResponse Generationセクションのオプションを「Generate SQL query」に変更すれば、生成されたクエリだけを確認できます。
この機能に興味を示す方が多かったので、構造化データの取得に特化した別のセッションがあることをお伝えしたいと思います。この機能についての1時間のセッションです。 興味を持って手を挙げてくださった皆様には、ぜひこちらのセッションにもご参加いただきたいと思います。セッションは金曜日の12月6日、午前10時30分から11時30分まで、同じVenetianのレベル3で開催されます。
さて、構造化データの取得についてはここまでにして、非構造化データ、マルチモーダル、ベストプラクティスについて話してきました。多くのことをカバーしましたが、これはまだ始まりに過ぎません。では、異なるドキュメント間の関係性を理解する必要がある質問をする場合はどうでしょうか？例えば「エッフェル塔がある国の首都はどこですか？」というような質問の場合はどうでしょう？簡単そうに聞こえますよね？私たちは答えを知っています。しかし、RAGシステムにこれを質問した場合、RAGシステムはどのように応答するのでしょうか？私たちが話してきた基本的なRAGシステムで対応できるでしょうか？
この質問を2つのパートに分けてみましょう。まず、エッフェル塔の場所を取得する必要があります。基本的なRAGシステムであれば、エッフェル塔に関するドキュメントを確実に提供できます。フランスの首都についても話すことができます。しかし、多くのドキュメントにまたがるこれら2つの情報を結びつけることができるでしょうか？できるかもしれませんし、できないかもしれません。では、このような種類のクエリを効果的に処理するにはどうすればよいのでしょうか？ GraphRAGを使用することで、それが可能になります。Amazon Bedrock Knowledge BasesではGraphRAGがプレビュー版として提供されています。
また、「重労働を軽減する」というフレーズをよく耳にしますが、これは完全マネージド型だからです。GraphRAGについて話すとき、私たちは多くのドキュメントにまたがるエンティティ間の関係性を理解することについて話しています。これは何を意味するのでしょうか？つまり、GraphRAGシステムの性能は、作成するナレッジグラフの質に依存するということです。大量のドキュメントがある場合、ナレッジグラフの作成は難しい場合があります。完全マネージド型というのは、私たちがお客様に代わってナレッジグラフを構築するということです。ドキュメント内に存在する可能性のあるすべてのエンティティと関係性を管理します。お客様がすべきことは、Vector StoreをNeptuneに接続してグラフを生成・保存できるようにし、作成後は、すでに使い慣れているRetrieveおよびRetrieve and Generate APIを使って質問を始めることだけです。
これらのAPIは、より包括的なGenerative AIアプリケーションの構築に役立ちます。これが私たちが言うスケールの意味です - 何千、何万ものドキュメント、さらにはそれ以上のドキュメントにわたってシステムが連携して機能することを確実にする必要があります。これがGraphRAGについての説明でした。ナレッジグラフを使用してより関連性の高いレスポンスを生成するのに役立ちます。
本日議論した重要なポイントをまとめさせていただきたいと思います。スケーラブルなRAGアプリケーションを構築する方法論、Marceloが共有してくれた継続的な改善のためのアプリケーション評価の重要性、そしてEnverusが小規模から始めて本番環境への移行のためのベストプラクティスを実践していった素晴らしい取り組みについてお話ししました。
また、先ほどチャレンジについても触れましたが、そのチャレンジとは、まだ始めていない方はこの旅を始めることです。すでに取り組みを開始されている方は、私たちに声をかけていただき、担当チームにご連絡ください。RAGアプリケーションを構築し、新しい課題を投げかけ、フィードバックを提供してください。このRAGアプリケーション構築の旅を一緒に進めていきましょう。そうしているうちに、皆様が素晴らしい新機能で私たちのプロダクトの形成を支援し、新しい課題を一緒に解決する中で、来年はここにいる皆様の誰かがステージに立ち、ご自身の経験を皆様と共有しているかもしれません。それでは、お時間をいただき、ありがとうございました。こちらがQRコードになります。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion