エージェントのコンテキストをどう管理する？RAG、LLM Wiki、GraphRAG

子どもの頃のことを、今でもはっきり覚えています。10歳か11歳くらいで、ポンタ・デルガダに住んでいた頃、ヒストリーチャンネルやディスカバリーのドキュメンタリーを見たくて、わくわくしながら家に帰っていました。毎日、例外なく、頭の中には何千という細かな情報が入ってきました。「へえ、古代ギリシャの神殿には、硬貨を入れると聖水が出てくる機械があったんだ！」。何年も何年もかけて身についたその習慣は、今も続いています。この約36年間で、科学、歴史、哲学などを分かりやすく伝えるドキュメンタリーや動画を、何万本も見てきたはずです。そして、当たり前といえば当たり前ですが、聞いたこと、見たこと、読んだことの99.9%は、頭のどこにも残っていません。

残った事実もあります。ギリシャの機械の話のように面白かったから、書き留めて後から読み返したから、深く理解して自分の一般知識の一部になったから、別の印象的な記憶と結びついているから、あるいは単に、まだ記憶が新しいからです。

ここから、興味深い類比を考えることができます。ただし、同じものだと言うわけではありません。基盤モデル（大量の多様なデータで学習し、さまざまなタスクに適応できるAIモデル）も、あらゆる情報を常に手元に置いているわけではありません。ただし、学習中に獲得した知識と、その時点のコンテキストは区別する必要があります。後者は、ある一回の呼び出しに対してモデルが受け取る情報のことです。

学習中、モデルは人間が一生かけても消費できない量のデータに触れます。その内容の一部が、モデルの基礎知識の集合に取り込まれます。そして人間と同じように、モデルもフェイクニュースや誤った考えを取り込むことがあります。

日常的な利用では、モデルはこの基礎知識と、さまざまなコンテキストの情報源を組み合わせます。たとえば、私がAIエージェントにメールの振り分けと優先順位付けを自動化してほしいと考えたとします。エージェントが使うのは、自分が持つ基礎知識、私が与えた手順の知識（指示）、そしてメール自体のデータ（そのタスクに固有の知識）です。しかし、ここでこの技術の大きな制約の一つにぶつかります。モデルのコンテキストウィンドウには限りがあるのです。最先端のモデルには、100万トークン程度のウィンドウを持つものもあります。英語の文章についての大まかな平均として、1トークンは約4文字に相当します。つまり100万トークンは、英語原文の『指輪物語』全3巻の文章の、およそ1.5倍に当たります。

ここでは、基盤モデル（FM）を使って判断し、ツールを利用するプログラムをエージェントと定義します。情報を受け取って判断する必要があるたびに、エージェントはモデルを呼び出します。その呼び出しに含まれない情報は、以前の呼び出しに登場していても、コンテキストとして利用できません。業界では、この制約に対処する方法が発展してきました。エージェントに必要なコンテキストを、必要なときに渡すための実践を、ここではコンテキスト管理の技術と呼びます。基本的な考え方の一つが、progressive disclosure of information、つまり情報の段階的な開示です。時間の流れに沿ってコンテキストを渡しながら、エージェントが必要な情報を取りに行けるツールも用意します。

比較的新しい分野なので、どんな場面にも通用する万能の解決策はありません。業界でよく使われる経験的な方法はいくつかあり、その中でも特に広く使われているのがRetrieval-Augmented Generation（RAG）です。この技術では通常、固定サイズ、意味的な文脈、文書の階層などの基準に従って、文書を複数の断片に分けます。それらの断片は、しばしば埋め込み（embeddings）と呼ばれる数値表現に変換されます。¹必要になると、エージェントはその情報を検索し、タスクに関連すると判断された断片を受け取り、それを使って回答を生成します。一般的には、語彙検索（特定の語を探す）、意味検索（タスクの要求と意味が近い断片を探す）、またはハイブリッド検索（両方）を使えます。非常に長い文書から特定の情報を見つけたい場合には、とても有効です。典型例は、500ページの契約書から関連情報を取り出すことです。ただし、エージェントが適切な検索を組み立てても、タスクへの回答に必要なすべての断片を受け取れるとは限らず、コンテキストが不完全になることがあります。それでも、産業界でも学術界でもこの技術は盛んに議論されており、私が見てきた実装事例のほぼすべてで使われていました。

ただ、方法はそれだけではありません。生成AIの世界で特によく名前が挙がる人物の一人、アンドレイ・カルパシーは、LLM Wikiを提案しました。²このアプローチでは、特定の書式を持つ単なるテキストファイルであるMarkdownファイル（.md）を使い、索引と、情報源から知識をまとめた相互にリンクするページを維持します。エージェントは必要に応じて、関連するページを全文読むことができます。新しい物の取扱説明書を開き、目次を見ながら自分に関係のある項目だけを読むのと同じです。一貫性があり、維持や手作業での調整もしやすいので、いくつかの用途ではこれが私の好みのアプローチになっています。ただし複雑な用途では、たとえば新版の文書の埋め込みを生成して索引を更新する場合よりも、維持の負担が大きくなることがあります。LLM Wikiを維持するために、情報を蒸留するパイプラインを作ることもできます。ここでいう蒸留とは、情報密度を保ちながら文章量を減らすことです。実際、それがカルパシーの提案です。しかし私の経験では、モデルによるこの情報の蒸留はまだかなり不確かで、元の情報の細かなニュアンスや、文書全体の目的を見落とすことがよくあります。そして、内容を吟味して維持する労力は、すぐに大きくなります。

最後に、文章も長くなってきましたし、ここまで読んでくれた人の気力をくじきたくはないので、GraphRAG、つまりGraph Retrieval-Augmented Generationについて簡単に触れたいと思います。まずグラフとは何かから始めましょう。頂点（ノード）の集合が、辺（つながり）で結ばれた数学的、あるいは計算機上の構造です……ここで一息。簡単に言えば、下の例のように、情報とデータ間の関係を表現する方法です。分かりやすい例がソーシャルネットワークです。複数の人の名前が互いにつながっていても、そのつながりには方向があります。JoaquinaがManuelをフォローし、ManuelがRamiroをフォローし、RamiroがJoaquinaをフォローする、という具合です。これはManuelがJoaquinaをフォローすることも、JoaquinaがRamiroをフォローすることも意味しません。人がノードで、つながりがフォロー関係です。情報には方向を持たせることができ、関係は明示されます。

AからBへの矢印は「AがBをフォローする」という意味です。逆方向の関係は暗黙には含まれません。

GraphRAGは、エンティティ（概念、物、人物）とその間の関係を持つ知識グラフを使い、問い合わせ可能なネットワークを作ります。エージェントはそれらの関係をたどりながら、タスクを完了するための情報を探しやすくなります。見つかった情報はコンテキストとしてモデルに渡され、回答の生成に使われます。この能力は、複数の文書にまたがる情報を結びつける必要がある場合に、特に役立つことがあります。他のアプローチと同じく、情報と関係を吟味し、整備する必要があります。特に、エージェントが自律的にそれらを作る場合は重要です。たとえば関係が間違っていたり、不完全だったり、古くなっていたりすると、エージェントは重要な情報を取りこぼしたり、すでに意味を失ったつながりを根拠に答えたりしかねません。私もこのアプローチを使った結果、ネットワークが複雑になりすぎて、自分もエージェントも（Sr. Alfredoにご挨拶）何が入っているのか分からなくなったことがあります。

この三つのアプローチは、互いに排他的なものではありません。比較的複雑で、成熟した取り組み方をする企業の導入プロジェクトなら、場合によっては三つすべてを使うこともあり得ます。WikiをRAGで検索できますし、GraphRAG自体も、検索で得た情報を使って生成を支援する方法です。いつどれを使うかについて、私の頭の中の整理をまとめると、次のようになります。

ただし、コンテキスト管理の話はここで終わりではありません。これは、このテーマを扱う連載の最初の記事にすぎません。今後は、caching、compaction、context pruning、そしてサブエージェントによるコンテキストの分離について話す予定です。また近いうちに。