re:Invent 2024: AWSがAmazon Neptuneの進化を解説 - OneGraphとGraphRAG
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Deep dive into Amazon Neptune and its innovations (DAT317)
この動画では、Amazon NeptuneのディレクターBrad BebeeとPrincipal EngineerのMichael Schmidtが、グラフデータベースの革新について解説しています。Neptune 1.3.2以降のパフォーマンス改善により、クエリのレイテンシーが最大9倍削減され、スループットが最大10倍向上した点や、Property GraphとRDFの両方を組み合わせられるOneGraphの導入など、具体的な技術進化が紹介されています。また、GraphRAGという新しい手法により、複数のドキュメントにまたがる関連事実の結びつけや、マルチホップの質問への回答が可能になった点も説明されています。Amazon Bedrock Knowledge BasesによるマネージドGraphRAG機能の提供開始や、オープンソースのGraphRAGツールキットのリリースなど、最新のアップデートについても詳しく解説されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon NeptuneとGraphRAGの紹介：本セッションの概要
DAT 317へようこそ。私はAmazon NeptuneとAmazon Timestreamを担当するAWSのディレクター、Brad Bebeeです。本日は、同僚のAmazon Neptune Principal EngineerのMichael Schmidtと共に、Amazon Neptuneとそのイノベーションについて詳しくご説明させていただきます。始める前に、会場の皆様にお聞きしたいのですが、現在グラフデータベースをお使いの方は手を挙げていただけますでしょうか？Amazon Neptuneをお使いの方は？昨日のSwamiによるGraphRAGの発表の前にこのセッションに申し込まれた方は？発表の後に申し込まれた方は？どちらの方にも素晴らしい内容をご用意しています。
これから、まずグラフ分野における私たちの歩みとポジションについて少しお話しさせていただきます。その後、アプリケーションの構築とグラフアプリケーションの運用をより簡単にするために、私たちがどのようなイノベーションを行ってきたかについてお話しします。最後に、Retrieval Augmented Generation（GraphRAG）アプリケーションをグラフを使ってどのように改善できるかについてご説明します。
Amazon Neptuneの進化：グラフデータベースの革新
8年余り前、私は小さなオープンソースのグラフデータベース企業のCEOを務めており、グラフ分野でどのように大きなインパクトを与えられるか考えていました。グラフの素晴らしさは分かっていましたが、大きな影響を与える方法が見えていませんでした。私たちはAWSに加わり、 2017年のre:Inventで、Andy JassyがAmazon Neptuneのプレビューを基調講演で発表した際に、私もその場にいました。AWSによるマネージドグラフデータベースサービスとしてのNeptuneの立ち上げは、グラフ分野に大きな影響を与えました。高可用性を備えた完全マネージド型のグラフサービスを簡単に作成できるようになり、より多くのビルダーにグラフの世界が開かれたのです。
Neptuneの立ち上げは、業界内でも歓迎されました。それ以来、私たちは革新のペースを維持し続けています。 最初のServerlessグラフデータベースを立ち上げ、グローバルグラフデータベースを立ち上げ、Graph Machine Learningをサポートし、In-memoryグラフ分析をサポートしています。様々なワークロードに対応するグラフアプリケーションの構築が、かつてないほど容易で低コストになりました。
今でも私が非常に興奮するのは、毎日何千ものお客様が、何万ものNeptuneインスタンスを様々なユースケースで実行していることです。これが可能なのは、グラフが素晴らしいからです。グラフを使うと、関係性をデータモデルの第一級市民として表現できます。つまり、それらの関係性をクエリーや探索することで、新しいインサイトを見つけ出し、イノベーションを起こすアプリケーションを構築できるのです。 お客様は、セキュリティ、金融、エンターテインメント、ナレッジグラフ、Digital Twin、Customer 360など、幅広いユースケースでこれを活用しています。データ内の関係性を活用することで、これらのユースケースに効果的に対応できるのです。
グラフは、複雑な内容を分かりやすく説明する非常に効果的な方法であることが分かってきました。これは特に、Wizのようなクラウドセキュリティポスチャー管理を手がける急成長中のセキュリティ企業のお客様を見ていて実感したことです。Wizではデータ間の関係性を活用してセキュリティグラフを構築し、さらにそのグラフ表現を使って、セキュリティグラフ内のどの脆弱性に優先的に対処すべきかを顧客に示し、開発チームに説明しています。このような「説明可能性のためのグラフ」という考え方は、今後ますます注目されていくと考えています。
グラフデータベースの新機能：OneGraphとテーブル形式データの統合
私たちがこの journey を始めた当初、グラフアプリケーションの大半はOLTPスタイルのものでした。 お客様は自身のグラフモデルを理解しており、マルチビュー同時実行制御を提供する強整合性のグラフデータベースを求めていました。また、高可用性機能も必要とされており、これらの要件は今日でも変わっていません。
お客様との関わりを通じて学んだことですが、 グラフを使って実現したい機能は他にもさまざまあります。グラフ全体の構造を分析してインサイトを得るための分析プロセスを構築したいと考えています。グラフとして保存されていないデータからグラフを生成することも望んでいます。 さらには、グラフアプリケーションと他の場所に保存されているデータを組み合わせてグラフを仮想化することも求められています。前回のre:InventでAmazon Neptune Analyticsを発表して以来、オンラインのグラフと分析用グラフを連携させたいというユースケースが数多くあることが分かってきました。
私たちの戦略は、 グラフクエリ言語とデータモデルについて最も幅広い選択肢を提供し、グラフデータベース、Graph Machine Learning、グラフ分析、そして今回新たに加わったGraph RAGなど、あらゆるグラフアプリケーションの構築において最高のコストパフォーマンスを実現することです。 マネージドサービスが評価される理由の1つは、高可用性の実現と管理が非常に容易だからです。
このあたりの革新的な機能についてお話ししましょう。現在のNeptuneをご存じの方なら、Neptuneのデータベースクラスターには プライマリライターと最大15個の低レイテンシーのリードレプリカがあることをご存知でしょう。これらは3つのアベイラビリティーゾーンにまたがるマルチAZストレージサービス上に構築されています。クラスター内のソースで計画的なダウンタイム（エンジンのアップデートなど）が発生した場合、 プライマリライターからの読み書きはできなくなりますが、リーダーからの読み取りを継続することでアプリケーションの可用性を維持することができます。この機能はSurvivable Read Replicasと呼ばれています。
数年前、私たちはGlobal Databaseをローンチしました。Global Databaseは、ビジネス継続性やアプリケーションのレイテンシー最適化を必要とするお客様に、AWSリージョンのシングルプライマリクラスターと、最大5つの異なるフォロワーリーダークラスターを提供します。最近まで、クライアントアプリケーションがグローバルクラスターから読み取りを行っている際にエンジンアップデートが発生すると、 そのアップデート期間中はそのクラスターからの読み取りや書き込みができませんでした。 最新のエンジンリリース1.4.0.0から、Global Databaseはサバイバブルな読み取りレプリカをサポートするようになり、グローバルグラフデータベースクラスターの可用性を向上させることができるようになりました。
前回のre:InventでNeptune Analyticsをローンチした後、 お客様からより小規模なグラフでも始められるようにしてほしいという要望を伺いました。Neptune Analyticsのグラフは、メモリNCU（Neptune Compute Unit）でサイズが決定されますが、お客様はさらに小さなグラフでの開始を望んでいました。そこで、最小プロビジョニングサイズとして16 mNCUの提供を開始しました。 これにより、インメモリグラフ分析を始めるためのコストを、当初のローンチサイズと比べて最大87%削減することができました。また、お客様からS3や他の場所にあるグラフデータのサイズから、適切なグラフサイズを判断するのが難しいというフィードバックもいただきました。そこで、グラフの最小サイズと最大サイズを指定できるAuto-scaling機能をローンチし、システムが提供されたデータに基づいて、データに適合する最小サイズを自動的に選択できるようになりました。
また、Neptune Analyticsのお客様から、グラフの使用中にデータの追加や削除を行う際にサイズを変更したいという要望も寄せられました。
これまでは、サイズ変更時にGlobal Databaseクラスターと同様の短時間のダウンタイムが発生していましたが、今回、ダウンタイムなしでグラフのサイズを変更できる新機能をローンチしました。コンソール、SDK、またはCLIを通じてグラフのサイズを増減でき、読み取りと書き込みのクエリ操作を継続して実行することができます。
Neptuneデータベースは、強力な同時実行性とMVCCビューを提供します。その一環として、読み取りと書き込みトランザクションを処理する際にUndoログを作成します。これらのUndoログは、データベースで発生する変更や変異の記録です。通常の運用では、Undoログはバックグラウンドプロセスによって削除され、特に問題なく処理されます。しかし、特定のケースや顧客の状況において、特に書き込みワークロードの同時実行性が高い場合に、Undoログの処理が遅くなり、Undoログのキューが蓄積されることがありました。これによりクラスターのストレージスペースが増加し、場合によっては完全に回収されないことがありました。
最新のエンジンリリース1.4.0.0以降、Neptuneデータベースは自動的にこのUndoログ領域を再利用するようになり、データベースの運用と管理がより簡単になりました。 ここで、Michael Schmidtをご紹介したいと思います。彼がグラフの構築をより簡単にする方法についてご説明します。
グラフテクノロジーの多様性とNeptuneの柔軟性
皆様、こんにちは。本日はお招きいただき、ありがとうございます。これから1分ほど、グラフの構築、管理、交換、そしてクエリをより簡単にするための革新的な取り組みについてご説明させていただきます。しかし、Neptuneの説明に入る前に、まずグラフテクノロジーの全体像について簡単に概観し、その背景をご説明したいと思います。では、Bradが投げかけた質問に関連して、いくつかの質問をさせていただきます。Labelled Property Graphについて、使用経験がある、もしくは聞いたことがある方はいらっしゃいますか？RDF（Resource Description Framework）について、使用経験がある、もしくは聞いたことがある方はいらっしゃいますか？かなりの数の手が挙がりましたね。両方の経験がある方はいらっしゃいますか？
これらのグラフテクノロジースタックの違い、特徴、長所について、残りの時間をすべて使って掘り下げることもできるでしょう。しかし、ここで強調したいのは、グラフテクノロジーの世界は非常に広大で、現在進行している全てを把握するのは私でさえ難しいということです。異なるクエリ言語があり、LPGとRDFはそれぞれ異なるデータモデルを持ち、異なるシリアライゼーションフォーマットを使用します。その結果、プログラミング言語との統合やツールのエコシステムも、グラフアプリケーションの構築に使用する技術によって選択肢が変わってきます。
Neptuneでは、お客様に選択肢を提供することを常に重視してきました。Neptuneの開始時から、私たちは両方のスタックをサポートしており、お客様からは、ユースケースに最も適したスタックを選択できる柔軟性を高く評価していただいていました。また、これらの標準の中から一つを選ばなければならない、というよりも以前は選ばなければならなかった、という事実自体が、グラフアプリケーションを始める上で大きな負担になっていたということも伺っていました。なぜなら、グラフを始める際には、まずユースケースについて考え、そのユースケースをグラフの概念にどうマッピングするかを考えます。これは非常に似ていて、説明や視覚化も簡単です。しかし、そこで突然、これらの標準やさまざまなクエリ言語を調べ、アプリケーション構築に最適なものを決定しなければならない状況に直面するのです。そこで私たちは、「Labelled Property GraphかRDFか」という選択ではなく、「Labelled Property GraphとRDFの両方」というパラダイムシフトができないかと考え始めました。結局のところ、これらは単なるグラフなのです。それこそが私たちが望むものでした。
グローバルスケールでデータを管理・接続するための強力なフォーマットとしてのRDFの強みと、プログラミング言語のエコシステムとの優れた統合性からアプリケーション開発者に好まれるProperty Graphの価値を、本当に組み合わせることができたらどうでしょうか？このアイデアからOneGraphが生まれ、今年初め、Neptune Analyticsで OneGraphをローンチしました。技術的な観点から見ると、OneGraphの基本的なアイデアは、Property GraphとRDFの両方を含むメタデータモデルを設計し、そのデータをProperty Graphであるかのように Neptune Analyticsで公開することです。
実際のところ、Property GraphにロードされたデータとそのグラフにロードされたRDFデータを組み合わせて、openCypherというクエリ言語で一元的に検索できるようになっています。データモデル間のギャップを埋めるため、異なるデータ型システムや識別子の種類に対応できるよう、いくつかの拡張機能を追加しました。これにより、データモデルやテクノロジースタックを選択する必要がなくなっただけでなく、チームに柔軟性が生まれ、異なるバックグラウンドを持つメンバー全員が貢献できるようになりました。
データアーキテクトは今や、Labelled Property GraphとRDFデータを即座に組み合わせることができます。Linked Open Dataと呼ばれる、さまざまな分野で公開されている参照カタログのようなデータセットをアプリケーションに接続できるようになりました。地理情報分野やライフサイエンス分野のデータセット、さらにはゲノムやタンパク質に関するデータベースなど、RDFで自由に利用できるデータを、Property Graphデータと連携させることが可能になったのです。開発者にとっては、新しい技術を学ぶ必要なく、まるでProperty Graphであるかのようにデータを扱えることを意味します。
具体的な例を見てみましょう。旅行業界の顧客向けにサービスを提供する会社を運営していて、特にフライト計画や旅行中のサポートを行っているとします。この分野には、ビジネスを立ち上げる際に活用できる公開データセットがあります。その一つがAir Routesで、これは空港のメタデータや説明、滑走路の数、空港間のフライトルートなどの情報を含むProperty Graphデータセットです。もう一つの興味深いデータセットがWikidataで、これはWikipediaの構造化バージョンです。コミュニティによって維持されており、あらゆる分野の情報が含まれています。その中には、アプリケーションに組み込みたい空港の詳細マップへのリンクなど、空港に関する具体的な情報も含まれています。
OneGraphを使えば、これら2つのデータセットを同じグラフにロードするだけで簡単に統合できます。これらのデータセットは異なる識別子を使用し、空港を表すノードも異なります。例えば、左上のノード12とJFK空港のWikidata識別子であるWDQ8685のように、2つの異なるデータセットから来ているため、異なるノードとして存在します。しかし、これらのデータが世界的に標準化されたIATAコードを共通して使用しているため、グラフの統合力が発揮されて相互にリンクされます。ETLや処理スキーマの設計は必要ありません。2つのデータセットをロードするだけで、接続されたグラフが得られるのです。
そして、openCypherを使ってそのグラフにクエリを実行できます。以下の例は、これら2つのデータセットからの情報を組み合わせる方法を示しています。このクエリは、APノード1とAPノード2のペアを選択し、codeプロパティがP238プロパティ（IATAコードの名前）と一致するペアを探します。
異なるデータセットで同じ空港を表すノードのペアが返されます。これにより情報を組み合わせることができます。この例では、AirRoutesからメタ情報を抽出し、Wikidataから詳細な地図リンクを抽出しています。返されるのはJSONで、HTMLテーブルとしてレンダリングすると、左側にAirRoutesからの構造化された情報が、右側にはWikidataから解決された画像としてのリンクが表示されます。
Neptune Analyticsの進化：スキーマ抽出とパフォーマンス改善
OneGraphのコンセプトは、2つのグラフコミュニティと2つのグラフの世界の間のギャップを埋めるという課題だけにとどまりません。 私たちにとって重要で、今年多くのイノベーションを行ったのは、他のデータソースを簡単に組み込み、グラフと他のデータを組み合わせることができるようにすることです。これらの改善の中で最も注目すべきは、テーブル形式のデータのクエリ、インポート、エクスポートを可能にする機能です。例えば、あなたがデータジャーナリストとしてある記事に取り組んでいるとします。Panama Papersがリリースされた直後、誰かがそのデータセットをKnowledge Graphとして公開しました。そのKnowledge Graphを取得してNeptune databaseにロードし、調査することができます。しかし、データジャーナリストとして、あなたは内部情報を持っているかもしれません。データセットに記載されている組織、人物、エンティティに関する情報を含むCSVファイルを持っているかもしれません。そして、調査の過程で、これら2つのデータセットの情報を柔軟に組み合わせたいと考えるでしょう。
これが実際の仕組みです。 これはopenCypherに完全に統合されており、Neptune readという新しいコマンドがあります。Neptune readは、データをすぐにグラフに保存するわけではありません。データを保存するコマンドも別にありますが、Neptune readはクエリランタイムにデータをロードするだけです。このコマンドを呼び出すと、CSVやParquetファイルが置かれているS3の場所を指定し、row変数が返されます。そして、CSVファイルやファイルの異なるフィールドに、単にカラムヘッダーを参照することでアクセスできます。
具体的な例を見てみましょう。 航空会社の情報、フライト番号、そしてそれらのフライトの出発地と目的地を提供するParquetファイルがあるとします。Neptune readを呼び出してこのファイルを指定すると、rowが返されます。この例では、私は単に航空会社を抽出し、出発地から目的地への文字列を作成しています。結果はJSONとして返され、アプリケーションに直接組み込むことができます。ある意味で、これによってopenCypherはテーブル形式のデータを処理するためのクエリ言語となります。
しかし、これをKnowledge Graphやグラフ一般と組み合わせると本当に面白くなります。 AirRoutesグラフがロードされているとします。ここで、グラフ構造とグラフクエリを、このテーブル形式のデータのクエリと組み合わせることができます。基本的な考え方は、グラフの一部をマッチングすることです。この例では、JFK空港とLas Vegas空港の間のフライトルートを抽出しています。次に、このcallコマンドでCSVファイルを読み込みます。CSVファイルの行を、出発地と目的地がJFKとLas Vegasである行にフィルタリングし、航空会社とフライトを抽出します。その後、各航空会社のフライト番号のリストを本質的に折りたたんで収集する前処理と後処理を行います。
この連携パラダイムは、ターゲットを絞った調査を行う場合には非常に適していますが、クエリを実行するたびにCSVファイルを再読み込みする必要があります。 もう一つの方法として、そのデータをグラフに埋め込むことができます。表形式のデータに隠れている関係性を直接抽出し、グラフ内に具現化することができるのです。これも今では簡単に実現できます。ここで見ているクエリのプレフィックス部分はほぼ同じです。
ただし、単に読み込んで変換するだけでなく、標準的なOpenCypherのCREATEキーワードを使用して、グラフ内に新しいエッジを作成します。このエッジには"flight"というラベルが付けられ、CSVファイルから抽出したキャリア情報を含むcarrier注釈が付与されます。 これを実行すると、この新しいエッジがグラフ内に具現化されます。これ以降は、CSVファイルを再読み込みすることなく、クエリを実行できます。表形式のデータの中に閉じ込められている情報を取り出し、表形式のソースからの情報でグラフを簡単に拡張できるようになります。
これらすべてを総合すると、異なるグラフや異なるデータソースをインポート、エクスポート、クエリ、接続するという新機能により、新しいデータ処理ワークフローを簡単に作成できるようになります。以前にも触れられた、お客様からよく寄せられるユースケースの一つは、「Neptuneデータベースにデータを保持しており、運用データベースとしてNeptuneデータベースを使用していますが、実行してみたいグラフアルゴリズムのアイデアがあります」というものです。では、NeptuneデータベースとNeptune Analyticsをどのように組み合わせればよいのでしょうか？例えば、顧客データやマーケティングキャンペーンに関するデータをNeptuneデータベースに保存していて、実施してきたキャンペーンの中で最も影響力の大きいものを理解したいとします。その場合、PageRankアルゴリズムをデータに対して実行するのが良い方法です。なぜなら、PageRankは本質的にグラフ内のノードの相対的な重要度ランキングに関する情報を提供するアルゴリズムだからです。
マーケティングキャンペーンの重要度が高ければ、より多くの反応を引き起こし、これらのマーケティングキャンペーンノードはグラフ内でより密接に接続されているという観察結果があります。このような処理はNeptune Analyticsで実行したいところです。なぜならNeptune Analyticsは完全なインメモリシステムで、収束してノードにスコアを付けるまでに通常グラフに対して複数回のパスを必要とする、これらの計算コストの高いグラフアルゴリズムを実行するために特別に設計されているからです。この場合、計算プロセスは比較的コストがかかりますが、出力はノードスコアという非常にコンパクトな形で表現されます。
現在利用可能なすべてのインポートおよびエクスポート機能により、このパイプラインを実現するのは4つの非常にシンプルなステップで済むようになりました。ステップと言っても、実際には送信するだけのコマンドやクエリのことです。最初のステップは、NeptuneデータベースからNeptune Analyticsグラフを作成することです。そのために、create graph using import taskというコマンドを使用し、実行中のNeptuneデータベースを指定します - これによりデータベースのスナップショットが作成され、Neptune Analyticsグラフが起動します。グラフの準備ができたら、PageRankを実行します。これはシンプルなOpenCypherクエリです。この場合、PageRankアルゴリズムのmutateバージョンを使用しており、これはグラフを反復処理してノードのスコアを計算し、各ノードにスコアプロパティを付与します。
これができたら、新しいCSV Export機能を使用できます。ここでフィルターがあることにお気づきかもしれませんが、これはグラフに追加した新しいスコアプロパティのみをエクスポートしたい場合に使用します。このコマンドで単純なCSVファイルとしてエクスポートし、S3に書き込みます。最後のステップでは、そのCSVファイルをNeptuneデータベースに再度読み込みます。このプレゼンテーションを準備していた際、基本的なスクリプトの作成に約2時間かかりましたが、このサンプル例では、プロセス全体が1時間以内で完了しました。この手順を応用することで、さまざまなデータ処理パイプラインとの統合が可能になります。
openCypherクエリの最適化：低レイテンシーと高スループットの実現
これでデータ管理に関する部分は終わりです。第二部では、クエリグラフ、クエリの使いやすさ、そしてパフォーマンスの面での改善についてお話ししたいと思います。柔軟性から始めると、お客様のグラフユースケースで重要とされる新機能を多数リリースしてきました。まず最初に説明するのはSubqueriesと呼ばれる機能です。Neptune Analyticsではグラフからのスキーマ抽出のための新しいアルゴリズムが導入されました。そして、他にも多くの小規模な改善が行われています。
これらの小規模な改善には、openCypherで重複の処理、交差、複合型のソートを行うクエリをより簡単に記述できるようにするプロシージャの追加が含まれています。では、Subqueriesについて詳しく見ていきましょう。技術的な観点から言えば、SubqueriesはSQLにおける相関サブクエリに相当します。簡単に説明させていただきます。
グラフトラバーサルを行う際によく遭遇する問題として、グラフのファンアウトが大きいということがあります。グラフ内で複数のホップを行うと、訪れるノードが多くなり、指数関数的に増加していきます。例えば、友人のネットワークで各友人が平均10人の友人を持っている場合、最初のホップで10人、次に100人、そして1000人と、非常に急速に増加します。さらに、例えば100万人もの友人を持つ著名人のような、パワーノードと呼ばれるものもグラフには存在します。
このような場合、グラフトラバーサルに制限を設ける必要があります。例えば、友人のレコメンデーションを行う場合、この膨大な空間全体を探索するのではなく、最も有望な結果から探索したいと考えます。誰かと繋がる可能性のある人をレコメンドする際、その人の最も親しい友人を見て、そしてそれらの親しい友人のさらに親しい友人を見ます。これらのノードは友人としてレコメンドする候補となる可能性があります。なぜなら、親しい友人の親しい友人は、自分が知っている人や何らかの関係がある可能性が高いからです。
openCypherを使えば、まさにそれが可能になります。全ての友人の結果を見るのではなく、最も近い10人の友人だけを見るようなホップが可能になります。そして「近い」の定義は、あなた次第です。それをサブクエリの中で定義します。サブクエリでは、グラフ内のスコアに基づいて「近い」を定義したり、共有している投稿へのいいねに基づいて動的に「近い」を定義したりすることができます。私たちは、このような最も有望な要素を探索できるという一般的なパターンが、特にリアルタイムレコメンデーションを使用しているお客様のシナリオで非常に役立つことを発見しました。
次に、Neptune Analyticsのスキーマ抽出について説明したいと思います。neptune.graph.pg_schemaという新しいプロシージャが追加されました。このプロシージャは、グラフ上のパスを取り、すべてのノードを分析し、これらのノードのラベルを特定し、どのタイプのノードまたはどのラベルがどのエッジラベルを介して他のノードラベルと接続されているかを特定し、これらのエンティティのプロパティ情報を提供します。そしてこれらの情報をコンパクトなJSON形式で要約します。これは、グラフデータを外部ツールと統合する際に、ますます重要になってきています。私たちが観察した主なユースケースは、お客様がLLMを使用してopenCypherクエリを生成することを求めていたということです。LLMが適切なopenCypherクエリを書くためには、グラフの中身、つまりコンセプト、それらのコンセプト間の接続タイプ、そしてクエリ可能なプロパティを知る必要があります。
最後のトピックはパフォーマンスです。私たちは様々な領域で多くのパフォーマンス改善を行ってきましたが、非常に汎用的であるため、特に取り上げたい改善点が1つあります。これらの改善により、Neptune Databaseにおける低レイテンシーのopenCypherワークロードのパフォーマンスが最大で1桁向上しました。
この改善は、私たちが観察してきたopenCypherの一般的なユースケース、つまりクエリテンプレートを使用したグラフアプリケーションの構築に対応するものです。これらのクエリテンプレートは、基本的に特定のUIを表示するために実行するクエリです。ユーザーがWebアプリケーションを通じてグラフを操作し、そのWebインターフェースをブラウズする際、異なるグラフクエリテンプレートを送信して、グラフから関連情報を抽出してWebページを構成します。
このようなインタラクティブなユースケースでは、これらのクエリは通常、グラフの非常に特定の部分を探索するという重要な要件があります。クエリ自体はシンプルですが、良好なユーザーエクスペリエンスを実現するためには、クエリが一桁または低い二桁のミリ秒で返ってくることを保証する低レイテンシーが必要です。システムに多くのクエリがバックログとして溜まり、クエリの実行に1秒もかかるようになると、ユーザーエクスペリエンスが低下し始めます。2つ目の特徴は、ユーザー数がピークに達する高スループットの時期が頻繁にあり、これらの低レイテンシーを維持しながら、最高のスループットにスケールできる必要があるということです。
Neptune 1.3.2以降、これらのユースケースに対して大幅な改善が行われ、同じインスタンスタイプでクエリのレイテンシーが最大9倍削減され、スループットが最大10倍向上しました。これはクエリ処理においてリソースをより効果的に活用することで実現しました。その結果、多くのケースでクラスターのスケールダウンが可能となり、より少ないリソースで同じレイテンシーとスループットを達成できるため、コスト削減にもつながります。
どのように実現したのでしょうか？基本的な考え方は、このクエリテンプレートのシナリオをopenCypherのパラメータ化クエリと結びつけることです。 この機能は、openCypherのパラメータ化クエリを使用する際に自動的に利用できます。これは、パラメータを含むクエリテンプレートと、そのテンプレートに挿入する値を別々に渡すAPIです。まず、新しいクエリプランキャッシュ機能を構築しました。テンプレートを初めて見たとき、クエリエンジンは実行可能なプランを構築して結果を返すと同時に、そのプランを将来のために保存します。同じテンプレートで異なるパラメータを使用する場合、保存された実行プランを取り出し、新しいパラメータを挿入して実行するだけです。
これにより、特に非常に低レイテンシーの単純なクエリでは、openCypherクエリの実行コストの大部分を占める、繰り返しのパース処理、変換、最適化のコストを削減できます。また、openCypherを最初にリリースした際には、クエリの一部を並列実行する可能性のあるマルチスレッドのクエリエンジンを採用していましたが、これらの低レイテンシーのワークロードでは、コンテキストスイッチやスレッド間の調整のオーバーヘッドを排除し、評価と実行プロセス全体をよりスムーズにできるシングルスレッドエンジンの方が効果的であることがわかりました。
ここで具体的な数値をご紹介します。これは、グラフ分野でベンチマーキングに焦点を当てる非営利組織であるLinked Data Benchmark Councilが公開しているSocial Network Benchmarkに触発されたベンチマークの例です。このケースは、フォーラムに投稿されたメッセージから始まり、返信チェーンをたどり、メッセージの投稿とフォーラムを特定し、そのフォーラムのモデレーターに関する情報を抽出する典型的なグラフクエリです。素晴らしい点は、アクセスするデータ量が限られていることです - いくつかのホップを行いますが、グラフの非常にローカルな部分で操作するため、実行が非常に高速です。これら2つのチャートは、Neptune 1.3.2以前とNeptune 1.3.2以降の対比を示しています。オレンジの線がNeptune 1.3.2を表しています。
左側のグラフはP95（レイテンシーの指標）を示しており、同じクエリを64の並列スレッドでサーバーに送信しても、レイテンシーが常に20ミリ秒未満に保たれていることがわかります。このスループットは、このクエリテンプレートパターンで秒間4,400クエリまでほぼ線形にスケールするようになりました。一方、以前のAmazon Neptuneでは、秒間500クエリ未満が限界でした。これは一時的な改善ではありません。openCypherのすべての低レイテンシークエリで同様の効果が見られます。社内のベンチマークや、さまざまなベンチマーク、異なるタイプのクエリでも確認されています。このパラメータ化の仕組みを活用できる高速なクエリであれば、Neptuneでこれらの改善を実感していただけるはずです。
GraphRAGの可能性：ベクトル検索とグラフ検索の融合
私のパートはこれで終わりです。ここからBradに戻して、LLMがなぜ素晴らしいのかについてお話しいただきます。それでは早速、グラフとRetrieval Augmented Generation（RAG）アプリケーションをどのように組み合わせられるかについて見ていきましょう。まず考えなければならないのは、ベクトル空間での検索とグラフ空間での検索の違いです。ベクトル空間での検索では、埋め込みを取得し、非常に高次元の数学的空間で他の要素との距離を測定します。これはよくSemantic Searchと呼ばれ、意味的に関連するものを見つけるのに非常に効果的です。例えば、「Zucchini」「Summer Squash」「Courgette」といった場合、テキストマッチでは見つけられませんが、Semantic Searchなら効果的に見つけることができます。Semantic Searchはテキストや画像、その他のメディアにも有効ですが、本質的にはブラックボックスです。なぜそのマッチングが行われたのか理解するのが非常に難しく、その関連性を説明するのも困難です。
一方、グラフ検索は、グラフ内に作成された関係性を活用し、それらの関係性をたどることで関連するものを見つけます。この例では、2人の俳優がどのように関連しているかを見たい場合、その関係性を確認することができます。先ほどグラフの説明可能性について話しましたが、この2人の俳優が関連している理由は、2つの映画に共演しているからだと簡単に説明できます。そこでGraphRAG は、グラフとベクトル検索を組み合わせたRetrieval Augmented Generation（RAG）のアーキテクチャパターンの一種です。これは非常に急速に進化している分野です。その組み合わせ方については多くの人がさまざまな意見を持っていますが、本質的にグラフとベクトルの組み合わせはこのパターンを改善することができます。
私たちは効果的な活用方法について、ある見解を持っています。GraphRAGは、多くの異なるドキュメント間や、非常に大きなドキュメント内の異なる箇所に存在する関連する事実を結びつけるのに役立つと考えています。これは、マルチホップの質問や、複数のデータソースが必要な質問への回答に役立ちます。また、コンテンツのより効果的な要約の作成にも役立ちます。今週のre:Inventで出会ったお客様の例をご紹介します。彼らはメールのコンプライアンスに取り組んでおり、メールの内容を確認して、金融証券規制に違反するようなことが起きていないかを理解しようとしています。彼らが言うには、単一のメール内で違反が発生している場合は上手く検出できるのですが、1〜2ヶ月にわたる一連のメールの中で、個々のメールは違反ではないものの、全体を見ると明らかに問題があるというケースで課題を抱えていました。
そこで彼らはGraphRAGの活用を検討していました。これはまさに、GraphRAGが効果を発揮できるマルチホップの質問応答の良い例でした。
昨日、SwamiがキーノートでAmazon NeptuneのKnowledge Bases for GraphRAGがプレビュー段階に入ったことを発表しました。これは、完全マネージド型のGraphRAGソリューションとして初めてのものです。私たちが特に期待している理由の1つは、RAGユーザーやRAGアプリケーションを構築したい人が、より良い結果を得るためにグラフデータベースについて何も知る必要がないということです。標準的なBedrockのワークフロー（コンソールまたはAPI経由）でRAGアプリケーションをプロビジョニングし、単にベクトルストアとしてAmazon Neptune Analytics GraphRAGを選択するだけです。
そうすると、 Bedrockは提供されたデータから自動的にグラフを生成するRAG設定を構築します。通常、このデータはS3上に配置されており、生成されるグラフは本質的に語彙グラフとなります。一般的なRAGのワークフローでは、文書を取得し、それらを小さなチャンクに分割して、それぞれのチャンクに対して埋め込みを計算します。GraphRAGのワークフローでは、これに加えて、LLMを使用してそれらのチャンク内のエンティティとトピックの抽出も行います。そして、それらのチャンク内に存在するエンティティや事実、概念を示すグラフを構築します。
この自動構築されたグラフは、Vector検索と組み合わせて検索プロセスで使用されます。例えば、 RAGアプリケーションに質問をした際に、埋め込みによってEntity0が単なるVector検索で取得された場合、RAGアプリケーションの生成フェーズには、そのチャンクだけが取り込まれることになります。GraphRAGでは、 検索プロセスにおいてVector検索とグラフ検索を組み合わせます。つまり、意味検索からの上位結果だけでなく、グラフ走査によって関連付けられたチャンクも取得します。ここでは、事実やトピックを共有するエンティティによって関連付けられた2つの追加チャンクを取得している様子が分かります。
このグラフ走査を取り入れ、Vector検索とグラフ検索の結果をRetrieverで統合することで、生成フェーズにより多くの関連コンテンツを取り込むことができます。 これにより、複数の文書にまたがる多段階の質問に対して、より正確で包括的な回答を生成することができます。 Amazon Bedrockの完全マネージド型GraphRAG機能に加えて、re:Inventの1週間前にオープンソースのGraphRAGツールキットもリリースしました。これはAWS Labsの下でGitHubで公開されており、Apache 2ライセンスの下で提供されています。このツールキットは、Llama.index、Amazon Neptune、Amazon Bedrockを使用して同様のワークフローを実装します。また、独自のLLMや他のグラフデータベースに置き換えることも可能です。これを行った理由は、先ほど述べたように、この分野が急速に進化しているからです。私たちは顧客から学び、顧客も最良の結果を得るための実験を行っています。先ほどのメールの例を思い出してください。
その企業は、これらのメールを処理するために長年かけて構築したルールに基づいて、非常に高精度なエンティティ抽出を行っていました。彼らが興味を持っているのは、このオープンソースツールキットを活用して、LLMによるエンティティ抽出の代わりに、彼らが構築したエンティティ抽出を組み込むことです。これにより、彼らが構築したものを活用したグラフを生成することができます。これは、オープンソースで素早く実験を始めることができる方法です。
1つ目は、Amazon Bedrock Knowledge Basesによる完全マネージド型のGraphRAG機能です。Amazon Bedrockで単にRAGワークフローを作成し、Amazon Neptuneを選択するだけで、以前と同じようにBedrockを利用することができます。既存のBedrock RAGワークフローをお持ちの場合は、それらを再作成することができます。新しい文書を追加して更新すると、GraphRAGアプリケーションも簡単に更新されます。
GraphRAGについて理解を深め、様々な設定を試したり、異なるグラフアルゴリズムを検証したり、ドキュメントのチャンクを処理する新しい方法を試したりすることに興味がある方は、オープンソースのGraphRAGツールキットをぜひお試しください。どちらの場合も、GitHubでのフィードバックやプルリクエストをお待ちしております。ご清聴ありがとうございました。
本日ご紹介したイノベーションに関するトピックについて、さらに詳しく学びたい方のために、こちらにリンクをご用意しております。ぜひご活用ください。それでは、質疑応答の時間を1、2分設けたいと思います。私やMichaelに質問がございましたら、どうぞ。もし質問がない場合は、この後、私とMichaelは会場の外におりますので、個別にご質問いただければと思います。はい、前列の方どうぞ。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion