GraphRAG vs 文脈内学習 ICL

9,704 文字

AIコミュニティの皆さん、今日はグラフRAGの最適化と文脈内学習について話していきましょう。私たちは最新技術の構築を目指しており、スーパーグラフRAGへと進化させ、文脈内学習を改善して、より優れたパフォーマンスのLLMを実現したいと考えています。最新技術について見ていきましょう。
まず初めに、文脈内学習とRAGについて説明します。どちらもナレッジグラフを活用できるという素晴らしい特徴があります。AIを初めて学ぶ方のために説明すると、RAGは非常にシンプルです。RAGは「検索拡張生成」(Retrieval Augmented Generation)の略です。
検索機能では、トランスフォーマーエンコーダーを使用して数学的なベクトル空間を構築し、そこに事前学習されたテキストの内容を意味的な埋め込み、つまりベクトル埋め込みとしてマッピングします。申し訳ありません、ミスがありました。
そして拡張部分では、検索機能から得られた関連情報でユーザーのクエリを拡張し、拡張されたプロンプトをLLMに入力します。これが全てです。
文脈内学習については、このビジュアライゼーションで、RAGとの関係性がよくわかります。ユーザーからクエリが入力され、現在のAIエージェントの時代では、エージェントが人間のクエリに基づいて関連情報を提供します。プロンプトの最適化とエージェントが、これら全ての関連情報を提供します。
もちろん、これらのエージェントの中核となるのは、特別に訓練された専用のLLMです。例えば、文章トランスフォーマー構造を持つLLMを使用して、ドメイン固有の事前学習データで独自のベクトル空間を構築できます。私は7本の動画で、無料で独自のベクトル空間を構築する方法を紹介しています。
これらは似ているように見えるかもしれません。このビジュアルの単純さに注目してください。ここでは単にグラフ情報を追加しています。ナレッジグラフ構造を追加し、文脈内学習の中で活用できます。AIエージェントがナレッジグラフ上で動作し、そこから人間のクエリを解決するための関連情報を提供します。
LLMには完全なプロンプトが提供されますが、検索機能でエンコードされたグラフ情報を使用することもできます。注意が必要なのは、RAGシステムの検索部分が複雑になればなるほど、元のRAG生成の性能とは関係のない外部の複雑さにコストを支払うことになるということです。
インデックス作成や再インデックス作成、メイン検索機能、ドメイン固有の検索機能、再検索機能など、主要なLLMの外部で情報を見つけるための複雑さが増していき、拡張に必要な正しい情報を得るのが非常に複雑になります。
そして、これが今日の本当のパワーハウスです。文脈内学習のためのLLMやエージェントを最適化する方法を見ていきます。文脈内学習がここにあり、機能的には非常に似ています。
ビデオチュートリアルについて質問があるかもしれません。まず左側の文脈内学習から始めましょう。この仕組みを理解するためのビデオチュートリアルがあります。「あなたの新しいナレッジグラフエージェント、特に医療AIエージェント向け」というタイトルで、ハーバード大学が考案・発表したナレッジグラフ方法論を使って、医療LLMとどのように対話するかを紹介しています。ビデオにはすべてのリンクが含まれています。
ナレッジグラフとシステム最適化について説明したビデオチュートリアルが必要な場合は、数週間前のこの動画を見てください。ナレッジグラフ駆動のRAGシステムについて一緒に取り組み、4つの方法と新しい方法を紹介しています。この動画では、追加の訓練を必要としない同様のグラフRAG方法論を探求しました。単純にナレッジグラフベースのRAGシム、グラフRAGを使用します。
ナレッジグラフから知識、情報、より深いデータ構造を追加したい場合は、両方のアプローチが可能です。一般的なビデオチュートリアルが必要な場合は問題ありません。ここでは、ナレッジグラフに大規模言語モデルを追加する方法を正確に示しています。
バークレー大学による新しいGI方法論を使用します。スタンフォード対MITの競合する方法論があり、好きな方を選べます。もちろん、マルチエージェントシステムも構築します。この動画では7つのエージェントとナレッジグラフ、そしてアジェンテグラフと呼ばれる方法論を紹介しています。
ナレッジグラフ適応推論を使用して、グラフ知識多様体上でエージェントシステムを計画するか、単にグラフ上でデコードすることができます。MITが考案したDogと呼ばれる方法論で、大規模言語モデルをナレッジグラフで強化します。選択できる方法論が多くあります。
素晴らしい文献も紹介したいと思います。まずはグラフRAGに注目しましょう。これは2024年12月31日に発表された最新の論文で、「グラフを用いた検索拡張生成」というタイトルです。ミシガン州立大学、オレゴン大学、Adobe、Amazon、Meta、Snapによる包括的で最新のグラフRAG方法論の調査です。7日前に発表されたばかりなので、必要な情報がすべて含まれています。
最後の行にGitHubリポジトリがあり、例えばここにあるような内容を見つけることができます。ナレッジグラフのさまざまな方法論に特化したい場合は、そこにアクセスすれば論文とコードがあります。オープンソースの場合はコードも利用でき、GitHubをクローンして新しい方法論を実行できます。
素晴らしいですね。しかし、これは知識だけではありません。この素晴らしいリポジトリ、graph-ragをスクロールダウンすると、グラフのテーブルがあり、論文とコード、論文とコードがあります。交通ネットワーク、科学ネットワーク、生物学的グラフなど、さまざまな方法論があります。
深く掘り下げてみましたが、グラフRAGを始めたい場合や、特定のドメインや複雑さに特化させたい場合、あるいは新しいグラフR方法論を試してみたい場合に、コード付きで80以上のバージョンが用意されています。
彼らは賢明な分類を行い、グラフRには一般的に5つの主要コンポーネント構造があると述べています。クエリプロセッサ、グラフデータソース、検索機能自体、オーガナイザー、ジェネレーターです。シンプルですが強力な表現で、グラフRAGの世界全体をすぐに把握できます。
2025年も情報検索は引き続き活発な研究分野になると思います。2025年1月3日に発表された大学の興味深いアイデアを見てください。生物医学ナレッジグラフに関する研究で、マルチモーダルな対照的表現学習を行っています。
グラフはもはやAIで使用する最も重要なツールの1つではないと言う人もいますが、そうではありません。グラフは非常に重要です。特に生物医学ナレッジグラフでは、医療分野で多くの研究が行われています。事前学習モデルとデータが必要な場合は、GitHubリポジトリがあります。
生物医学のような特定のドメインを対象としたナレッジグラフと、マルチモーダルデータに対するAIエージェントの統合は、依然としてホットで現在進行形の研究トピックです。グラフが重要な理由は、この論文を見るとよくわかります。
生物医学ナレッジグラフ、属性情報、そして事前学習言語モデルがあります。BERTモデル、文章トランスフォーマーを覚えていますね。現在は新しいBERT、モダンBERTがあります。これについての動画もあります。
属性埋め込みがあり、従来の対照学習があり、そして何年も前からあるナレッジグラフ埋め込みのリンク予測を行います。私のチャンネルには5〜7本の関連動画があります。入力として不完全なグラフ、関係グラフ畳み込みネットワークエンコーダーがあり、出力は予測された接続を持つ完全なグラフです。分子レベルでの予測です。
したがって、私はグラフが埋め込みやエージェントと共に非常に重要だと考えています。パワーハウスになるでしょう。では、文脈内学習とグラフの非常にシンプルな表現に戻りましょう。
2日前の投稿で説明しましたが、1年前は文脈内学習が人間によって事前に決められた静的な例を使用し、RAGが事実に基づく文書、記事、データベースエントリーのみを扱うと考えられていました。しかし、1年後の今、ダイナミックなAIエージェントの存在により、これはもはや当てはまりません。
しかし、例えばGPT-4や3oに質問すると、まだ古い知識が返ってきます。興味深いことに、大規模なLLMの中には2023年末や2024年半ばで知識がカットオフされているものがあるため、AIシステム自体がこのことを知らず、古い情報を参照しています。
素晴らしいですね。でも、もう一歩進んで改善を目指しましょう。グラフRAGを紹介しましたが、さらに進めていきましょう。エージェントが拡張プロンプトのために関連情報を提供する完全な文脈内学習システムがあり、これをLLMに入力します。
検索機能があり、できれば商用のベクトルストアに費用を払うのではなく、シンプルな専門家モデル、シンプルなトランスフォーマーエンコーダーを使って、ドメイン固有の知識のための独自のベクトル空間を無料で構築することをお勧めします。
しかし、システム全体のパフォーマンス、出力のパフォーマンスはどうでしょうか。これがシステムだとして、結果を見せてください。どちらのシステムが優れているでしょうか。
しかし、本当の問題は文脈内学習がRAGシステムより優れているかどうかではありません。本当の問題は、このLLMの品質、訓練、最適化がどれほど良いか、そしてどのように改善できるかということです。
これは非常に簡単です。両方に同じユーザーリクエストと同じ関連情報を与えます。検索機能やエージェントのパフォーマンスに関する問題のある外部要因を排除します。クエリと関連情報から始めて、どのLLMが最高のパフォーマンスを発揮するかをテストします。
つまり、最初のステップを無視します。定義されたユーザーリクエスト（クエリ）と、クエリを解決するための完全な文書（関連情報）があり、32,000トークンの最大長で実行します。
これは重要です。前回の動画で200万トークンの長いコンテキスト長について話したとき、多くの方からAnthropicは128kトークンしかないという返信がありました。これは一般的な反応だと思います。Google以外は数百万トークンのモデルを持っていないので、分割する必要があります。
このテストは32kトークンのコンテキスト長で行われました。つまり、現代のほとんどのLLMがこのテスト範囲に入ります。また、これは公平な条件での評価です。長文の応答を必要とするように設定されています。単純な即答ではなく、より複雑な推論構造を出力することを求めています。
提供されたコンテキスト文書（関連情報）に完全に基づいた長文の応答が必要です。LLMはクエリと関連情報を受け取り、32,000トークンの中から関連情報を見つけなければなりません。そして、クエリを解決できる情報を見つける必要があります。クエリに役立たない情報を見つけても失格になります。
実際の結果、実際の回答がLLMから得られることを求めています。これは公平なテストだと思います。2025年1月7日にGoogleが発表した事実根拠点リーダーボードがあります。これは私が今日1月7日に記録している、まさに私が説明したことです。
長いコンテキストを32kトークンに制限し、この範囲内で「長文」と呼ばれる応答を要求します。Googleは誰もがテストできる新しいリーダーボードを提供しており、好みのLLMで実行して、Kaggleで公開されているものと比較できます。事実リーダーボードと呼ばれています。
クエリのドメイン分布とタスク分布を示すと、事実根拠付けリーダーボードには金融ドメイン、インターネット・テクノロジードメイン、法律分野、そして支配的なセクターである医療分野、小売または製品固有のトピックが11%含まれています。
タスクについては、どのタスクカテゴリでLLMが輝くかがすぐにわかるように分類されています。概念比較、説明効果、事実分析、検索と要約、事実検索タスク、テキストの要約と簡略化、要約とフォーマットなど、様々なタスクがあります。テストデータセットとテストクエリで公平な分布だと思います。
ここに最初の結果があります。もちろん、判定モデルがこれを判定しており、画面上でピンク色に見えるのが判定モデルです。GoogleはGeminiを使用し、OpenAIのGPT-4 Omni、AnthropicのClaude 3.5 Sonnetでオープンでブラインドなテストを行いました。
これらを全て合わせた平均で、これが現在1日目の段階で、Googleによって事前に入力されています。ランク1から9を見ると、Gemini 2.0 FL実験版、Claude 3.5 Sonnet、GPT-4 Omni、GPT-4、Mini OpenAI o1、Mini OpenAI previewとなっています。特定のAI判定者による特定の投票があり、平均値が示されています。
今日のKaggleのリーダーボード（1日目のスクリーンショット）を見ると、先ほど示したようにGemini 2.0 Flashからo1 Miniまでとなっています。特定のLLMを持っている場合は、そこでテストを実行できます。私も2つのモデルについてテストを実行しますが、結果はKaggleには公開しないかもしれません。しかし、少なくとも文脈内学習、RAGのパフォーマンス、さらにはグラフRAGのパフォーマンスに関して、モデルがどれほど優れているかがわかります。
本当に興味がある方向けに、オタク専用の内容ですが、1月6日、つまり私にとっては昨日、Google DeepMindが「長文脈言語モデルによる文脈内学習の再検討」を発表しました。Googleは長文脈言語モデルをリードしているので、当然ここから出てきました。LCLMという略語を見たら何を意味するかわかりますね。
彼らはこれをテストし、文脈内学習のパフォーマンスが、従来のサンプル選択方法（タスクに特化した少数の短い例を慎重に作成する）にまだ敏感かどうかという重要な疑問を投げかけています。
上級者向けではありませんが、彼らが何をしているかを正確に見てみましょう。例の数とシステムのパフォーマンスがあり、これを異なるタスクで実行しています。平均要約タスク、平均翻訳タスク、平均推論タスク、平均分類タスクについて、4つのトピックのパフォーマンスが示されています。
これは興味深いです。要約は異なる効果があり、翻訳も、推論はそれほどでもありませんが、分類も見てください。何かが起こっていることは明らかです。しかし、これは明確なデータですが、実際のノイズのあるデータについてはどうでしょうか？
Googleはこれも考慮に入れています。x軸にノイズ比があり、要約、翻訳、推論、分類のパフォーマンスが示されています。オレンジ色がアーカイブ、緑色が政府の報告です。
理論物理学や有機化学、数学など、非常に専門的な科学用語を使用する場合でも、40%のノイズを追加しても比較的良好なパフォーマンスを維持できます。システムはノイズと実際の科学情報を区別できるようです。
より一般的な政府の報告構造、つまり社会のより広い要素を対象とする場合、要約タスクにおいて完全に異なる挙動を示します。推論も非常に興味深く、緑の線とオレンジの線を見ると、いつどのように適用するかを探求し理解する必要のある本質的な違いがあります。
しかし、一般的にまとめると、私たちは核心的な転換点にあり、ICLサンプル選択手順の焦点から、より広範なコンテキスト活用へと移行しています。
私の言葉で言えば、古いパラダイムでは、古い言語モデルと制限されたコンテキストウィンドウ（例えば8K）により、文脈内学習内で提供する特定の例を最適化することに重点が置かれていました。少数の適切な例を選ぶことが、文脈内学習のパフォーマンスにとって重要だと考えられていました。
新しいパラダイムでは、200万トークン、600万-800万トークン長の長文脈言語モデルにより、このような巨大なコンテキストウィンドウが生まれ、状況が変化しました。この特定の研究（プレプリントを深く読むことをお勧めします、特定のトピックについて本当に興味深い内容です）によると、十分な容量がある場合、慎重に選択された例はランダムな例と比べて大きな利点を提供しないとしています。
主な課題は、文脈内学習のために最適に設計された少数の短い例を見つけることではなく、例えば最初の500例を与えられた場合に、拡張されたコンテキスト空間を効果的に活用することです。
これは興味深いことです。少数の美しい例を持つことが無効になったわけではありませんが、1つのプロンプトで500の文脈内学習例を提供できる機会があれば、多様なトピックをカバーし、複雑さの幅広い範囲をカバーできます。
これら500の例の1つ1つが究極の経験のために完璧に設計され、完璧に作られている必要はありません。別のAIによって合成的に生成することもできます。重要なのは、慎重に選択された1、2、3、4、5の例ではなく、4、5、600、2000の例を配置し、完全なコンテキスト空間を活用することです。
どのようなクロスドメイン、インタードメイン、クレイジーなアプリケーションでも、そのためのスペースがあります。問題は、500の例を使用して「クレイジー」に行った場合、結果が良くなるのか、LLMのパフォーマンスに利点があるのかということです。
ここからは私の個人的なまとめです。もはやGoogleからではなく、私の考察であり、RAGシステムの拡張プロンプト、CAシステム、RAG検索機能から返される結果の最適化、そして文脈内学習にどのように影響し、反映されるかについてです。
私は何か異なることをすると思います。なぜなら、これはモデルがプロンプト内で十分な量の多様な例を示されたときに十分に学習することを意味し、複雑な選択と事前選択が不要になるからです。
私にとっての意味は、SCセットアップを単純化できるということです。基本的なランダムサンプリング方法論や戦略で十分です。多様な例のセットを確保するだけで、完璧な設定に特別な注意を払う必要はありません。
これは理にかなっています。高品質のRAG検索リクエストでは、ベクトル空間内でクエリ埋め込みに最も近い2,000の参照を検索します。これは商用のRAG検索機能を使用する場合、支払わなければならない膨大な量の検索データ、検索トークンです。
しかし、彼らは、RAG検索機能の後に異なるインデックス作成と複数のLLMがこの2,000の例をさらに最適化するため、これが必要だと言います。20個だけをサンプリングした場合、その20個の中から関連情報を見つけることができないことを検索機能は知っているからです。
文脈内学習からの影響、拡張からの影響を考えると、これは理にかなっています。十分な量の多様な例を提供すれば、それらが最高品質である必要はないというのは興味深いことです。
第二に、タスクに利用可能な実際の例が限られている場合、コンテキストウィンドウが十分に活用されない可能性があります。Googleは、最高の複雑さレベルを持つ必要がないため、合成例でプロンプトを拡張することを提案しています。
訓練データを増やすことができます。この拡張方法論は、Googleのテストで、より多くの関連情報でコンテキストウィンドウを埋めることにより、大幅なパフォーマンス向上につながりました。
つまり、フューショット文脈内学習のための例が50個しかない場合、LLMに「これが私の50個の例です、意味的に、構造的に、形式的に非常に近い別の50個の例を合成的に生成してください」と依頼できます。
最高レベルに設計されたプロンプトを目指す必要がないことを覚えておいてください。Googleの結果は大幅なパフォーマンス向上を示しています。ドメインの訓練データが不足している場合は、別のLLMによるデータ拡張を使用して、LCLMの大きなコンテキストをより多く埋めることができます。
ただし、収穫逓減の点には注意が必要です。200万トークンまで埋めることは意味がありません。より多くのコンテキストは一般的にパフォーマンスの向上につながりますが、プラトーがあり、最終的にはコンテキスト長がモデルの200万トークン制限に近づくにつれて、システムのパフォーマンスは低下します。
200万トークンまでの絶対的な極限に行く必要はありませんが、10万、20万トークンで十分かもしれません。100万トークンが必要かもしれません。しかし、収穫逓減があることを忘れないでください。さらに10万トークンを追加しても、パフォーマンスはわずかにしか向上しないかもしれません。
ポイント4は、LCLMは特に非常に特定の高度に専門化されたドメイン知識やナレッジグラフにおいて、ノイズのある例に対する優れた耐性を示します。ただし、ノイズの割合が比較的低い場合に限ります。
しかし、より一般的なテキストを扱う必要がある場合は、特定のタスク、特定のドメイン、特定のモデルには特定のしきい値があることを忘れないでください。しきい値を超えてデータが非常にノイズの多いものになると、LLMは理解できず、パフォーマンスは低下します。
最後のポイント5は、本当にこれに従うかどうかわかりませんが、自分でテストする必要がありますが、Googleによると、ICL入力コンテキスト内の例の順序は、LLMの応答のパフォーマンスに大きな影響を与えないとしています。
事前学習では、事前学習のフェーズ、データの順序が重要であることを学びましたが、今Googleは、文脈内学習において、特にGoogleモデルの特定の訓練ルーチンなどにおいて、フューショットの例の順序は大きな影響を与えないと言っています。
これは素晴らしいことです。私は最初に比較的シンプルな例から始め、例を提供する中で徐々に複雑さを増していきました。文脈内学習プロンプトの例の構築で、本当にシンプルなところから始めて、徐々により複雑になっていきました。
しかし今、Googleはこれは必要ないと言っています。もしこのことについて既に知っている方がいれば、フィードバックをいただけると嬉しいです。
今日はこれで終わりです。今週の最新技術について非常に簡単にまとめると、グラフRAG、スーパーグラフRAGがあり、グラフRAGの70-80の異なる実装についての論文とコードが利用可能です。
特に拡張の観点から見ると、RAGシステムが文脈内学習と非常に似ていること、相互に接続されていることを理解できます。RAGシステムで唯一重要な要素は、商用の検索機能システムと商用のベクトルストアに対して、独自のベクトルストアとベクトル埋め込みを構築する知識がない場合、極端なコストがかかる可能性があることです。
しかし、これは非常に簡単だと思います。今までに多くの可能性を示してきました。小規模なスタートアップや個人開発者であっても、商用検索モデルに時として法外な価格を支払う必要はありません。
以上で今日の内容は終わりです。楽しんでいただけたと思います。新しいアイデアや新しい文献を得られたかもしれません。もし購読していただけるなら、次の動画でお会いできることを楽しみにしています。