※本記事は、AWS re:Invent 2024のセッション「Build scalable RAG applications using Amazon Bedrock Knowledge Bases (AIM305)」の内容を基に作成されています。セッションの詳細情報は https://www.youtube.com/watch?v=jSlNfr8Uuco でご覧いただけます。本記事では、セッションの内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルのセッション動画をご覧いただくことをお勧めいたします。

登壇者：

• Marcelo Silva (Amazon Bedrock, Product Manager) AWSのAmazon Bedrockチームにてプロダクトマネージャーを務め、RAGワークフローを実現するエンド・ツー・エンドの管理サービスとしてAmazon Bedrock Knowledge Basesの開発を主導。
• Maynak Patel (Enverus, Distinguished Architect) エネルギー業界のリーディングSaaSプロバイダーであるEnverusにてDistinguished Architectを務め、Instant Analystプラットフォームの設計・実装を主導。
• Mani Khanuja (AWS, Technical Lead, Generative AI Specialist) AWSにてTechnical Lead, Generative AI Specialistとして、高度な技術機能の開発とお客様への提供を担当。

AWS re:Inventの詳細：https://go.aws/reinvent その他のAWSイベント：https://go.aws/3kss9CP

1. イントロダクション

1.1 RAGの基本概念

Marcelo Silva: RAG（Retrieve Augmented Generation）は、モデルをカスタマイズする手法の一つです。モデルのカスタマイズには、出力のカスタマイズ、ファインチューニング、継続的な事前学習など様々な方法がありますが、その中でもRAGは組織が持つ独自のデータでモデルの出力を文脈化する最も一般的な方法となっています。

このデータは、構造化・非構造化を問わず、音声、テキスト、画像など様々な形式を扱うことができます。RAGの基本的な仕組みは、データ取り込みパイプラインを通じて文書を取り込み、それらの文書の表現（エンベディング）を生成し、検索可能な形で保存します。この保存された情報は、クエリに基づいて検索され、モデルの出力を生成する際の文脈として利用されます。

RAGの重要な点は、モデルの出力を組織独自のデータに基づいて制御できることです。つまり、モデルの回答を公開情報ではなく、内部文書や構造化データ、独自のデータに基づいて生成することが可能になります。現在、多くのユースケースはテキストベースの顧客体験やパーソナライズされた検索などに集中していますが、今日発表されたように、マルチモーダルモデルを使用することで、テキスト以外の出力を生成することも可能です。

RAGは単なる技術的な仕組みではなく、組織の知識を活用してAIモデルの応答を改善するための戦略的なアプローチとして位置づけられています。これにより、モデルは組織固有の文脈を理解し、より正確で有用な回答を提供することができるようになります。

1.2 Amazon Bedrock Knowledge Basesの1年間の振り返り

Marcelo Silva: 昨年、私たちはRAGワークフローを実現するエンド・ツー・エンドの管理サービスとしてAmazon Bedrock Knowledge Basesを立ち上げました。当初は比較的シンプルな機能からスタートしましたが、現在では数千の顧客が利用する製品へと成長しました。

この1年間で、50以上の新機能を開発し、AWSの中でも最高の開発・科学チームと共に、お客様の要件を取り入れ、より正確でパフォーマントなアプリケーションを迅速に本番環境に展開できるよう進化させてきました。

主な機能強化として、ハイブリッド検索、手動メタデータフィルター、Salesforce・Confluenceなどへのコネクタ、チャンキング戦略の改善などが挙げられます。特にチャンキング戦略については、単なる要件ではなく、データの性質とモデルの出力に基づいて最適化する必要があることを強調したいと思います。そのため、階層的セマンティックチャンキングや、固定チャンキングに加えてカスタムチャンキングの機能を導入しました。

また、CloudFormation、Terraform、SDK、CDKのサポートも追加し、より柔軟な開発環境を提供しています。さらに、今年のネットワークサミットでは、画像やテキスト、複雑な表を含む文書からエンティティを抽出するためのLLMパーサーや、複雑なクエリを分解して理解するクエリリフォーミュレーションなどの高度な機能も発表しました。

このような進化は、お客様との密接な協力関係なしには実現できませんでした。私たちは日々、数百のお客様と対話を重ね、製品の形を作り上げてきました。

2. スケーラブルなRAGアプリケーション構築の方法論

2.1 データ戦略の重要性

Marcelo Silva: RAGアプリケーションを構築する上で、データ戦略は最も重要な要素の一つです。私たちが顧客との協業を通じて学んだ知見を共有させていただきます。

まず、データ戦略を立てる際には、扱うデータの種類を明確に理解する必要があります。構造化データと非構造化データの両方を考慮に入れなければなりません。非構造化データには、マニュアル、財務諸表、PDFなど様々な形式の文書が含まれます。これらの文書は、時にはよくフォーマットされていたり、CSVファイルやスプレッドシートなど、多様な形式で存在します。

データの準備と変換のプロセスは非常に重要です。特に、データの性質を理解し、適切なチャンキング戦略を選択することが、アプリケーションの成功を左右します。チャンキング戦略は、単なる技術的な要件ではありません。データの性質と、基礎モデルの出力を適切に文脈化するために、慎重に選択する必要があります。

データの準備段階では、以下の3つの重要な側面を考慮する必要があります：

1. データの種類に応じた適切な前処理方法の選択
2. アプリケーションで使用する基礎モデルの特性に合わせたデータの変換
3. データの文脈を適切に保持するためのチャンキング戦略の設計

また、データ戦略は静的なものではありません。アプリケーションの進化に合わせて、継続的に最適化していく必要があります。例えば、新しいタイプの文書が追加された場合や、ユーザーの質問パターンが変化した場合には、データの準備方法やチャンキング戦略を見直す必要が出てくるかもしれません。

重要なのは、データ戦略がRAGアプリケーションの基礎となるということです。適切なデータ戦略なしでは、どんなに優れたモデルや検索機能を実装しても、期待する結果を得ることはできません。そのため、プロジェクトの初期段階から、データ戦略の設計に十分な時間と労力を投資することを強くお勧めします。

2.2 段階的な実装アプローチ

Marcelo Silva: RAGアプリケーションを構築する際の最も重要な教訓の一つは、小規模からスタートすることの重要性です。私たちが提供している50以上の機能を最初から全て有効にするのではなく、段階的なアプローチを取ることを強く推奨します。全ての機能を一度に有効にすると、追加のコストが発生し、レイテンシーが増加し、何がパフォーマンスや精度、アプリケーションのリコールに影響を与えているのかを理解することが困難になります。

特に使用開始時は、基本的な機能に焦点を当てることが重要です。新しいRAG評価機能を使用して、応答が期待通りのものかを判断し、会社のセキュリティガイドラインやコンプライアンス、規制要件に合致しているかを確認します。この評価が満足できるものであれば、ユーザーにアプリケーションを展開し、フィードバックを収集することができます。

ここで特筆すべき重要な点は、ユーザーの行動パターンの変化です。チャットボットとの対話において、ユーザーはより詳細な会話的なアプローチを取る傾向があります。例えば、ビジネスユーザーに「全てのファイルをこのシステムに入れました。何でも検索できて、インサイトや要約を得ることができます」と伝えると、彼らは予想もしなかったような質問をしてきます。

そのため、小規模な実装から始め、ユーザーにサービスの概念に慣れてもらい、どのような種類のサービスを提供しようとしているのかを理解してもらうプロセスが重要です。必要に応じて評価を行い、変更を加え、再デプロイするという継続的な改善サイクルを確立することが成功への鍵となります。

このアプローチは、インフラストラクチャのスケーラビリティも考慮に入れています。小規模から始めて複雑なものに発展させていく際に、より多くの文書が取り込まれ、より多くの顧客がプラットフォームを利用するようになっても、インフラストラクチャが変更を必要としないように準備しておく必要があります。これにより、サービスの成長に伴う技術的な課題を最小限に抑えることができます。

2.3 継続的な改善プロセス

Marcelo Silva: RAGアプリケーションの構築では、継続的な改善プロセスが不可欠です。私たちは今回、RAG評価とLLMジャッジという新機能を導入しました。これにより、アプリケーションの構築、応答の評価、改善のサイクルを完全なものにすることができます。

具体的な評価プロセスでは、RAG評価を使用して応答が期待通りのものかを判断します。この評価では、会社のセキュリティガイドライン、コンプライアンス要件、規制要件との適合性も確認します。評価結果に基づいて、必要な改善を行い、アプリケーションを再デプロイすることができます。

パフォーマンスの最適化については、インフラストラクチャのスケーラビリティが重要な要素となります。小規模から開始して複雑なものに発展させていく際に、より多くのデータタイプを追加し、構造化データなども組み込んでいくことになります。このとき、インフラストラクチャが変更を必要としないように準備しておく必要があります。

特に重要なのは、ユーザーの行動パターンを理解し、それに基づいて継続的な改善を行うことです。私たちの経験では、ユーザーはチャットボットとの対話において、より詳細で会話的なアプローチを取る傾向があります。そのため、評価とフィードバックのサイクルを確立し、ユーザーの実際の使用パターンに基づいて最適化を行うことが重要です。

スケーリング時の考慮点としては、以下の要素に注意を払う必要があります：

1. データ量の増加に対する対応
2. ユーザー数の増加に伴うパフォーマンスの維持
3. 新しい要件や複雑な要件への対応能力
4. コストの最適化

このような継続的な改善プロセスにより、アプリケーションは徐々に進化し、より正確で効率的なものとなっていきます。重要なのは、このプロセスを計画的かつ段階的に実施することで、各段階での成果を確実に評価し、次のステップに活かしていくことです。

3. Enverusの事例研究

3.1 ビジネス課題と規模

Maynak Patel: Enverusはエネルギー業界全体のスペクトルをカバーするソリューションを提供するリーディングSaaSプロバイダーとして、サプライチェーン、バックオフィス、電力および再生可能エネルギー取引など、あらゆる種類のソリューションを提供しています。

私たちが直面している最大の課題は、生データと創出したい価値との間のギャップを埋めることです。エネルギー業界には膨大なデータが存在し、その中に価値が埋もれています。この課題は、いわゆる情報の断絶を生み出しています。Enverusは、インテリジェントな接続を通じてこの問題を解決しています。

この解決策により、顧客は新しい価値や将来のエネルギー予測に関する新たな可能性を引き出すことができます。このソリューションがもたらす価値は、エネルギー企業だけでなく、エネルギーを消費するエンドユーザーにも及びます。Enverusの使命の中心にあるのは、技術革新を推進するこの強力なミッションです。私たちは、エネルギーのエコシステム全体を民主化しています。これは、大手生産者から小規模サプライヤーまで、金融機関、グローバルトレーダー、地域のオペレーターなど、すべての関係者がEnverusのソリューションを利用していることを意味します。

私たちの規模と影響力を示す数字を共有させていただきます：

• エネルギー生産者の98%が私たちのプラットフォームを利用
• 35,000以上のサプライヤーが参加
• Enverusの単一製品だけで2,000億ドル以上の支出を処理
• 5,000以上のエネルギー顧客と300以上の金融機関が日々利用
• 25年分のSEC認証済みの情報を保有し、構造化・非構造化データを組み合わせて提供

特に重要な課題として、研究レポートの処理があります。各レポートの読了には10〜15分を要し、例えばルイジアナで新しい井戸を掘削しようとする生産者が規制変更を理解するには、複数のレポートを読んで追跡し、意思決定を行う必要があります。これには数日から数週間、時にはそれ以上の時間がかかっていました。Instant Analystを通じて、私たちはこの時間を大幅に削減し、多くの顧客の効率を向上させることに成功しました。実際、1四半期未満で52,000以上のユーザーをInstant Analystに導入することができました。

3.2 Instant Analystプラットフォームの構築プロセス

Maynak Patel: 私たちはスケーラブルで柔軟なソリューションを構築するために、実装プロセスを5つの重要なフェーズに構造化しました。

まず、計画と戦略のフェーズでは、ビジネスビジョンを確立し、それに基づく戦略を構築することから始めました。重要なのは、アイデアの早期検証です。業界や関係者全員がどのようにアプローチするかを待つ長いプロセスを経るのではなく、できるだけ早く検証を行うことを重視しました。また、適切なチームと文化の確立も重要でした。これは、ビジネスからエンジニアリングチームまで、組織全体で変化を支持し、採用する必要があります。生成AIは従来のアプリケーション構築とは根本的に異なるアプローチを必要とするためです。

開発と統合のフェーズでは、Infrastructure as Codeを常に重視しました。多くの方がデモアプリケーションを組織向けに構築した経験があると思いますが、そのデモが本番ソリューションになることはよくあることです。そのため、最初からインフラストラクチャの自動化を開始することで、デモが完成した時点で製品部門が「スケールアップしよう」と言った際に、それをサポートできる体制を整えました。

エンジニアリングの焦点として、生成AIの議論では誰もがアルゴリズムや科学的研究の必要性を考えがちですが、実際にはオーケストレーション、エンジニアリングアーキテクチャなど、より多くのコンポーネントが必要です。スケーラブルなRAGアプリケーションを構築する際には、メモリ、ベクターストアなど、さまざまなコンポーネントを組み合わせるオーケストレーションが重要な技術となります。

AWS統合については、開発プロセス中にAWSのアカウントチームとパートナーシップを組み、設計と実装の検証を行うことが極めて重要でした。課題をチームに提起することで、Bedrockやその他の必要なチームからサポートを受け、様々なソリューションやサービス、設計パターンについてのガイダンスを得ることができました。

この構築プロセスを通じて、私たちは常にプラットフォームとしての視点を持ち続けました。各ユースケースを個別に処理するのではなく、複数のユースケースに容易にスケールできるシステムを設計することを目指しました。これにより、研究インテリジェンスデータのための最初のRAGユースケースを構築した後、新しいユースケースを6〜8ヶ月もかけることなく、数時間から数日で私たちのプラットフォームに導入できるようになりました。

3.3 技術的課題と解決策

Maynak Patel: スケーラブルなアーキテクチャを構築する過程で、私たちは多くの重要な技術的課題に直面しました。その中でも特に重要な課題が3つありました。

第一に、ユースケース、データ、および求める応答のタイプに適したチャンキング方法の確立です。データの性質が多様であり、それぞれに適切なチャンキング戦略が必要でした。第二に、プライマリソースシステムからベクターストアへのデータ同期の維持です。APIコールを通じて自前で実装すると、非常に面倒で継続的なメンテナンスが必要になります。第三に、Bedrock以外のプラットフォームとの直接統合において、スロットリングとバックプレッシャーの処理の実装が必要でした。これらの機能の実装は開発チームに多大な負担をかけ、継続的な改善と保守が必要でした。

これらの課題に対して、私たちはAmazon Bedrock Knowledge Basesを採用することで解決策を見出しました。Terraformによるインフラストラクチャのコード化とA/Bテストにより、同じデータに対して異なるチャンキング設定や異なる埋め込みモデルを持つ複数のKnowledge Basesを並行してデプロイできるようになりました。これにより、データ駆動の統計的な意思決定が可能になり、各イテレーションに時間をかけるのではなく、並行して素早く決定を下すことができるようになりました。

また、Bedrock Knowledge Basesは、データの同期や更新、削除などの操作をネイティブにハンドリングしてくれるため、これらの処理について心配する必要がなくなりました。スロットリングについても、Bedrock Knowledge Basesにネイティブに組み込まれているため、個別に実装する必要がありません。

検索精度の向上については、ハイブリッド検索やメタデータフィルタリング、そして最近追加されたリランキングなどの技術を活用しています。これらの機能は、私たちの統合とパートナーシップを通じて、システムに対する異なる機能要求や必要性を提起する中で、Amazon Bedrockチームから継続的に提供されており、非常に満足しています。

4. アーキテクチャと実装詳細

4.1 サーバーレスアーキテクチャの採用

Maynak Patel: 私たちはInstant Analystのアーキテクチャを100%サーバーレスで、イベント駆動型に設計しました。手動操作やポーリング型のメカニズムは避け、完全にイベント駆動のアーキテクチャを採用しています。

このアーキテクチャの主な利点は、アナリストがリサーチレポートを公開してから5分以内という短時間で、データ取り込みパイプラインを通じて様々な処理を行い、ベクターストアでクエリ可能な状態にデータを準備できることです。この迅速な処理は、リアルタイムな情報提供を可能にします。

使用しているAWSサービスには以下が含まれます：

• AWS Step Functions
• AWS Lambda
• Amazon EventBridge
• Amazon SQS
• Amazon SNS

特に重要なコンポーネントとして、PDF内に埋め込まれたテーブルや、チャート、様々な構造化・半構造化データを処理するためにAmazon TextractとAmazon Bedrockを活用しています。例えば、PDFからテーブルを抽出する際には、Amazon Textractを使用してOCR処理を行い、JSONとして出力します。その後、このJSONを標準フォーマットに変換し、自動化された処理と人間によるレビューのプロセスを経て、最終的にAmazon Bedrockを使用してデータのコンテキストを強化してからベクターストアに格納します。

このサーバーレスアーキテクチャの採用により、以下の利点を実現しています：

1. 運用の自動化と効率化
2. スケーラビリティの確保
3. コスト最適化
4. メンテナンス負荷の削減
5. 迅速なデータ処理と更新

このアーキテクチャは、私たちのプラットフォームの成長に合わせて柔軟にスケールでき、新しいユースケースや機能の追加にも容易に対応できる設計となっています。

4.2 データ取り込みパイプライン

Maynak Patel: 私たちのRAGシステムにおけるデータ取り込みは極めて重要なプロセスです。「ガベージイン、ガベージアウト」の原則に従い、ベクターストアに取り込むデータを十分に充実させることで、様々な方法でクエリを行い、必要な情報を取得できるようにしています。

データ取り込みパイプラインは3つの主要な焦点領域で構成されています。第一に、様々な異なるフォーマットの構造化・非構造化データからの情報検索です。私たちはPDF、JSON、Excel、CSV、さらには音声や動画フォーマットもサポートしています。これらのデータを標準フォーマットに変換する処理が最初のステップとなります。

第二の領域はクリーンアップです。自動クリーンアップと人間によるレビューを組み合わせたソリューションを構築しています。データがパイプラインを通過し、自動的にベクターストアに同期される一方で、人間によるレビューが必要なデータを特定し、後からエンリッチメントを行うことができます。

特に、PDFに埋め込まれたテーブルやチャート、様々な構造化・半構造化データの処理には、Amazon Textractを活用しています。TextractでOCR処理を行い、JSONとして出力されたデータを私たちの標準フォーマットに変換します。その後、自動化された処理と人間によるレビューのプロセスを経て、Amazon Bedrockを使用してデータのコンテキストを強化してからベクターストアに格納します。

最後の領域は、選択したベクターストアへのデータのベクトル化とインデックス作成です。このプロセス全体が自動化されており、アナリストがレポートを公開してから5分以内という短時間で、データを検索可能な状態にすることができます。また、人間によるレビューが必要な部分については、ワークフローを中断することなく後から改善を行うことができる設計となっています。

このパイプラインは完全にサーバーレスで、イベント駆動型のアーキテクチャで実装されており、スケーラブルかつ保守性の高いソリューションとなっています。

4.3 検索精度向上のための3段階アプローチ

Maynak Patel: 私たちは検索精度を向上させるために、3つの重要な段階でアプローチを最適化しました。

検索前の最適化では、クエリの強化と情報抽出に焦点を当てた「クエリパースメカニズム」を実装しました。これは当初、独自のソリューションとして開発しましたが、後にAmazonと協力して、この機能をAmazon Bedrock Knowledge Basesに組み込み、すべてのユーザーが利用できるようにしました。このメカニズムには、クエリの解析、書き換え、拡張、リフォーミュレーションが含まれます。特に重要なのは、クエリパースアプローチにより、時間に特化した質問からメタデータ情報を抽出し、RAG検索時に暗黙的にそれを適用できることです。これにより、検索精度が大幅に向上しました。

検索時の最適化では、ハイブリッド検索とダイナミックフィルタリングを実装しています。ダイナミックフィルタリングは、暗黙的フィルタと明示的フィルタの両方の組み合わせをサポートしています。また、アセンブリング技術を用いて、異なるメカニズムからのデータを組み合わせています。

検索後の最適化では、リランキングが非常に重要な役割を果たしています。25年分のデータを持つ私たちのシステムでは、数千または数百万の文書にまたがって特定の用語やセマンティクスが使用されているため、特定の質問に対して適切なチャンクを取得することは非常に困難です。そこで、リランキングを使用して、最大500〜1,000のチャンクを取得し、コンテキストとの関連性に基づいて再ランク付けを行っています。

また、時間的な新しさと関連性も重要な要素です。特定の時期に公開されたレポートに関する質問や、特定のトピックに関する最近の数週間や月のコンテンツが必要な場合があります。履歴を失うことなく、関連性と新しさの両方を処理することが重要です。

最後に、LLMモデルが応答の最初のトークンを生成し始めた時点から、ユーザーに情報を提供し始めるストリーミング機能を実装することで、ユーザー体験をシームレスなものにしています。

5. 最新の機能と高度な技術

5.1 マルチモーダルデータ処理

Mani Khanuja: RAGアプリケーションにおいて、マルチモーダルデータの処理は非常に重要な要素です。私たちが取り扱う文書は、単なるテキストだけではありません。画像やテーブルなど、様々な情報が含まれており、これらの情報をRAGアプリケーションで活用する必要があります。

この課題に対して、Amazon Bedrock Knowledge Basesは完全に管理されたソリューションを提供しています。ユーザーは、データを持ち込み、Knowledge Base作成時にAmazon Bedrock データオートメーション、もしくは基礎モデルをパーサーとして選択するだけで良いのです。

実装のプロセスは非常にシンプルです。まず、文書を同期する必要があります。これは、文書をベクターストアに取り込むことを意味します。同期が完了すれば、すぐに質問を開始することができます。特筆すべき点は、質問に対する回答が画像から取得される場合、引用として画像が表示されることです。これは追加の実装を必要とせず、AWSが代わりに全ての処理を行ってくれます。

このマルチモーダルデータ処理機能は、私たちが発表した機能の中でも特に気に入っている機能の一つです。なぜなら、複雑なマルチモーダルデータの処理を完全に抽象化し、ユーザーは単にデータを提供し、質問をするだけで良いからです。システムは自動的に適切なモダリティを理解し、それに応じた回答を提供します。

このアプローチにより、テキスト、画像、表を含む複雑な文書からの情報抽出が大幅に簡素化され、より豊かで正確な応答が可能になっています。

5.2 構造化データの検索機能

Mani Khanuja: 非構造化データやマルチモーダルデータの処理に加えて、データベースに格納された構造化データに対する質問にも対応する必要があります。例えば、「2024年11月の最も売れた商品は何か？」というような質問です。このような質問に答えるためには、データベースの検索、集計、スキーマの理解、テーブル間の関係性の理解など、多くの要素が必要となります。

Amazon Bedrock Knowledge Basesは、構造化データ検索のネイティブサポートを提供しています。この機能を使用すると、ユーザーは自然言語で質問を投げかけることができ、システムは以下の3つのステップで処理を行います：

1. まず、自然言語の質問からSQLクエリを生成します。
2. 次に、生成されたSQLクエリをデータベースに対して実行し、結果を取得します。
3. 最後に、取得した結果を自然言語の回答として要約します。

この処理は、既存のretrieve APIとretrieve and generate APIを使用して実現されています。また、SQLクエリのみを生成したい場合は、generate query APIを使用することもできます。

重要な特徴として、会話の履歴を保持する機能があります。例えば、「それの現在の在庫レベルはどうですか？」というフォローアップの質問に対しても、前の会話で言及された商品を正しく理解し、適切な回答を生成することができます。セッションIDの管理など、複雑な実装は必要なく、すべてシステムが自動的に処理します。

このように、私たちは構造化データの検索において、従来必要だった複雑な実装の手間を大幅に削減し、開発者がより本質的な機能の開発に注力できる環境を提供しています。この機能の詳細については、12月6日金曜日の10:30から11:30に、Venetianレベル3で行われる専門のセッションで深く掘り下げる予定です。

5.3 GraphRAGの実装

Mani Khanuja: 時にRAGシステムは、複数の文書にまたがる関係性を理解する必要があります。例えば、「エッフェル塔がある国の首都は何ですか？」という質問について考えてみましょう。これは一見単純な質問に見えますが、基本的なRAGシステムでは適切に処理することが難しい場合があります。

この質問は二つの部分に分けることができます：

1. エッフェル塔の所在地を特定する
2. その国の首都を見つける

基本的なRAGシステムでは、エッフェル塔に関する文書や各国の首都に関する文書を個別に見つけることはできますが、もしこれらの情報が異なる文書に分散している場合、それらの関係性を理解して適切な回答を生成することは困難です。

この課題に対応するため、私たちはAmazon Bedrock Knowledge BasesにGraphRAGをプレビュー機能として導入しました。これは完全に管理されたソリューションであり、「重い作業の軽減」という私たちの理念を体現しています。GraphRAGシステムの性能は、その基盤となる知識グラフの品質に大きく依存します。多数の文書から知識グラフを作成するのは複雑な作業になり得ますが、私たちのソリューションでは、この作業を代行します。

具体的には、文書内のエンティティと関係性を自動的に特定し、知識グラフを構築します。ユーザーは、ベクターストアとしてNeptuneを選択し、グラフの生成と保存を可能にするだけです。質問は、既存のretrieveおよびretrieve and generate APIを使用して行うことができ、より包括的なRAGアプリケーションの構築が可能になります。これにより、数千、数万の文書にまたがる複雑な関係性を持つ質問に対しても、正確な回答を提供することができます。

6. 実証実験と評価

6.1 A/Bテスティングの活用

Maynak Patel: 生成AIアプリケーションのテストは非常に困難な課題でした。AIによって生成されたレスポンスやコンテンツをテストすることは従来のアプリケーションテストとは大きく異なります。そこで私たちは3つの異なるアプローチを採用しました。

最も重要なアプローチは市場テストです。すべてが完璧になるのを待つのではなく、最適な顧客を見つけ、市場テストフェーズに移行しました。私たちは幸運にも、2ヶ月以内に数百もの顧客がEnverus Instant Analystプラットフォームに参加し、電話、システムを通じて直接、そしてアカウント担当者を通じて、非常に有益なフィードバックを提供してくれました。

次に、A/Bテストと評価に重点を置きました。Infrastructure as Codeを活用して、同じデータに対して異なるベクターストア、異なる設定、異なる埋め込みモデルを持つ複数のKnowledge Basesを並行してデプロイしました。これにより、ユーザーが比較して、どのソリューションやレスポンスが好ましいかを評価できるようになりました。この市場フィードバックとA/Bテストの検証を通じて、どの設定が最も効果的かを判断することができました。

また、当初はオープンソースのRAGAsフレームワークを使用してエンド・ツー・エンドのソリューションを実装していました。しかし、これには大きな開発オーバーヘッドが伴いました。例えば、最近発表されたRAGAs 2.0は完全な改訂版であり、開発チームは評価フレームワークを再実装する必要がありました。このような経験から、MarceloがA/Bテストと並んで強調したモデル評価、RAG評価、LLMジャッジなどの新機能の重要性を実感しており、私たちのシステムでこれらの機能を試すことを楽しみにしています。

このように、複数の評価アプローチを組み合わせることで、生成AIアプリケーションの品質と有効性を継続的に改善することができました。

6.2 市場テストからの知見

Maynak Patel: 私たちは市場テストを通じて、貴重な知見を得ることができました。特に重要だったのは、完璧なソリューションを追求するのではなく、早期に市場テストを開始することでした。

市場テストでは、2ヶ月という短期間で数百の顧客がInstant Analystを試用してくれました。フィードバックの収集は3つのチャネルを通じて行いました：

1. 直接電話によるフィードバック
2. システムを通じた直接的なフィードバック
3. アカウント担当者を通じたフィードバック

ユーザーからのフィードバックで特に注目すべき点は、研究レポートの処理時間に関する改善でした。従来は各レポートの読了に10〜15分を要し、特に規制変更などの情報を理解するには数日から数週間かかることもありました。Instant Analystの導入により、この時間を大幅に短縮することができました。

また、ユーザーの実際の使用パターンを観察することで、チャットボットとの対話における行動の変化も特定できました。ユーザーはより詳細で会話的なアプローチを取る傾向があり、これは当初想定していなかった発見でした。

これらの知見は、Infrastructure as Codeを活用した並行テストにより、迅速に実装に反映することができました。同じデータに対して異なる設定の Knowledge Bases を並行してデプロイし、ユーザーからのフィードバックに基づいて最適な構成を選択することができました。この迅速なフィードバックループにより、1四半期未満で52,000以上のユーザーの導入という成果を達成することができました。

6.3 RAG評価フレームワークの進化

Maynak Patel: 当初、私たちはRAGアプリケーションの評価のためにオープンソースのRAGAsフレームワークを採用しました。このフレームワークはRAGのメトリクスを評価する上で優れた機能を提供していましたが、完全なエンド・ツー・エンドのソリューションを実装する際には大きな開発オーバーヘッドが発生しました。

特に課題となったのは、RAGAs 2.0のような大規模な改訂への対応です。フレームワークが完全に刷新されると、開発チームは評価フレームワーク全体を再実装する必要が生じました。これは開発リソースの大きな負担となりました。

このような経験から、Bedrock Knowledge Basesに新しく追加されたモデル評価、RAG評価、LLMジャッジなどの機能の重要性を強く実感しています。これらの機能は、私たちが直面していた評価の課題に対する解決策を提供するものです。特に、継続的な改善プロセスにおいて、応答の妥当性評価から改善のサイクルまでを一貫して行えることは非常に重要です。

新しい評価フレームワークでは、以下の要素を統合的に評価することができます：

1. モデルの応答の正確性
2. セキュリティガイドラインとの適合性
3. コンプライアンス要件への準拠
4. 規制要件との整合性

これらの評価結果に基づいて、必要な改善を特定し、システムを進化させていくことができます。このように、評価フレームワークそのものも、私たちのRAGアプリケーションと共に進化を続けています。

7. セキュリティと運用

7.1 プライバシーとデータ保護

Maynak Patel: AIに関する議論の中で、セキュリティは常にホットトピックとなっています。私たちがBedrockを選択した主な理由の一つは、データが仮想プライベートネットワーク内で保護され、外部に流出することがないという点です。

Bedrockを使用することで、サードパーティのAPIを呼び出したり、モデルを別の場所でホストしたりする必要がなくなり、セキュリティチームが夜中に心配して連絡してくるような事態を避けることができます。データはすべてVPC内に留まり、完全に制御された環境で処理されます。

また、データのプライバシー保護については、特に25年分のSEC認証済みの研究レポートを扱う私たちのユースケースでは極めて重要です。プラットフォームに組み込まれたセキュリティ機能により、機密性の高い情報を安全に処理し、適切な権限を持つユーザーのみがアクセスできるようにしています。

このアプローチにより、エネルギー業界の規制要件やコンプライアンス要件を満たしながら、5,000以上のエネルギー顧客と300以上の金融機関のデータを安全に処理することができています。セキュリティは私たちのシステムの設計における最優先事項の一つであり、Bedrockの組み込みセキュリティ機能が、この要件を効果的に満たしてくれています。

7.2 スケーラビリティの確保

Maynak Patel: 私たちのプラットフォームでは、スケーラビリティの確保を最重要課題の一つとして取り組んできました。Infrastructure as Codeアプローチを採用することで、デモアプリケーションが本番ソリューションになった際にも、スムーズにスケールアップできる体制を整えています。

特に、私たちのシステムが処理する規模を考えると、スケーラブルなインフラストラクチャ設計は不可欠でした。現在、98%のエネルギー生産者と35,000以上のサプライヤーがプラットフォームを利用しており、単一の製品だけでも2,000億ドル以上の支出を処理しています。また、5,000以上のエネルギー顧客と300以上の金融機関が日々システムを利用しています。

負荷対策として、完全なサーバーレスアーキテクチャを採用し、AWS Step Functions、Lambda、EventBridge、SQS、SNSなどのマネージドサービスを活用しています。これにより、手動操作やポーリング型のメカニズムを排除し、完全にイベント駆動型のアーキテクチャを実現しています。

コスト最適化については、段階的なアプローチを取っています。最初から全ての機能を有効にするのではなく、必要な機能から順次導入することで、不要なコストの発生を防いでいます。また、Infrastructure as Codeを活用することで、複数の設定を並行してテストし、最も効率的な構成を選択することができます。

特に注目すべき成果として、アナリストがリサーチレポートを公開してから5分以内という短時間で、データ取り込みパイプラインを通じて処理を完了し、ベクターストアでクエリ可能な状態にできる体制を構築できました。これは、スケーラビリティの確保と効率的なリソース使用の両立を示す良い例となっています。

7.3 パフォーマンス最適化

Maynak Patel: パフォーマンスの最適化において、私たちは特にレイテンシーの削減に注力してきました。サーバーレスアーキテクチャの採用により、アナリストがレポートを公開してから5分以内という短時間で、データをベクターストアでクエリ可能な状態にすることができています。

レイテンシー削減のための重要な施策として、12月1日に発表されたストリーミングレスポンスの実装があります。これまでは基礎モデルからの応答全体が生成されるのを待つ必要がありましたが、現在では最初のトークンが生成された時点から、タイピングのような形で応答を受け取ることができるようになりました。これにより、アプリケーションのパフォーマンスと応答性が大幅に向上しました。

リソースの効率的な使用については、Infrastructure as Codeアプローチを活用し、異なる設定の並行テストを可能にしています。これにより、最適なパフォーマンスを発揮する構成を特定し、不要なリソース消費を抑制することができます。

また、3段階の検索最適化アプローチ（検索前、検索時、検索後）を実装することで、クエリの処理効率を向上させています。特に、時間的な新しさと関連性の両方を考慮したリランキング機能により、25年分のデータから最適な情報を効率的に抽出することが可能になりました。

これらの最適化により、52,000以上のユーザーを1四半期未満という短期間で導入することができ、高いパフォーマンスを維持しながらスケーラブルな運用を実現しています。

8. 今後の展望

8.1 新機能のロードマップ

Mani Khanuja: 私たちは今日、多くの新機能について発表しましたが、これはまだ始まりに過ぎません。機能の進化は継続的なプロセスであり、お客様の要件や新しい課題に応じて、さらなる改善と拡張を行っていきます。

特に、構造化データ検索の領域では、より詳細な内容を12月6日金曜日10:30から11:30に、Venetianレベル3で行われる専門セッションで共有する予定です。この機能は、データベース検索とRAGを組み合わせた革新的なアプローチであり、今後さらなる発展が期待されます。

Maynak Patel: 私たちEnverusの経験から、製品のステークホルダー、ビジネス、顧客など、すべての関係者から新しい、より複雑な要件が継続的に提起されています。これまでも様々な種類の質問の意図を処理し、異なるタイプのデータをプラットフォームに取り込むなど、新しいイノベーションが必要とされてきました。

私たちのシステムは、スケーラビリティと柔軟性を念頭に置いて設計されており、アイデアの検証からインフラストラクチャのコード化、評価に至るまで、すべての段階で自動化されたアプローチを採用しています。これにより、新しいユースケースや機能を迅速にInstant Analystに導入することができています。

今後も、マルチモーダルデータ処理、構造化データ検索、GraphRAGなどの新機能を継続的に強化し、より包括的で効率的なRAGソリューションを提供していく予定です。

8.2 コミュニティへの呼びかけ

Mani Khanuja: 私たちはみなさんへの課題を持っています。それは、まだRAGの旅を始めていない方は、ぜひ始めていただきたいということです。そして、すでに始められている方は、私たちとさらなる対話を重ねていただきたいと思います。アカウントチームに連絡を取り、RAGアプリケーションを構築し、新しい課題を私たちに提示してください。フィードバックを提供していただくことで、共にこの旅を進めていけることを願っています。

私たちはEnverusとの協力を通じて、素晴らしい新機能と問題解決策を共に生み出すことができました。同様に、皆様との協力を通じて製品を形作り、より良いものにしていきたいと考えています。

そして、来年のre:Inventでは、皆様の誰かがここに登壇し、自身の旅路と、それを他の方々と共有する経験について語ることができるかもしれません。私たちは、コミュニティの力を信じており、皆様一人一人の貢献が、このプラットフォームをより良いものにすると確信しています。

Maynak Patel: 私たちEnverusの経験から、AWSとの緊密な協力関係が非常に重要であることを学びました。私たちは2週間ごとの統合ミーティングを設け、設計や実装のアイデア、デモをAWSチームと共有し、正しい方向に進んでいるか、あるいは何か変更が必要かを検証してきました。この協力を通じて、多くの課題や機能要求をAmazonチームに提示し、それらの解決策をBedrock Knowledge Baseプラットフォームに組み込むことができました。

このような協力体制は、単なる技術的な進歩以上の価値をもたらします。それは、すべてのユーザーが恩恵を受けることができる、より良いプラットフォームの構築につながるのです。