この動画では、AI分野で注目を集めている「コンテキストエンジニアリング」という概念について詳しく解説している。ShopifyのCEOであるTobyの投稿をきっかけに話題となったこの用語は、LLMが課題を解決できるよう適切なコンテキストを提供する技術を指す。動画では従来のプロンプトエンジニアリングとの違い、コンテキスト汚染や注意散漫などの失敗パターン、そしてRAGやコンテキスト隔離といった解決策について体系的に説明している。
コンテキストエンジニアリングという新しい概念
さて、まず最初にこのことを言わせてください。AI業界は非常に古いアイデアに新しい名前を付けることが大好きです。そして今回の流行語はコンテキストエンジニアリングです。
これはすべて、ShopifyのCEOであるTobyのこのツイートまたは投稿から始まりました。彼はこう言っています。「プロンプトエンジニアリングよりもコンテキストエンジニアリングという用語が本当に気に入っています。これはLLMによって課題がもっともらしく解決できるよう、課題に対するすべてのコンテキストを提供する技術です」
そして多くの人が彼に同意しています。Andre Karpattyからのツイートをご紹介しましょう。「コンテキストエンジニアリングに+1。コンテキストエンジニアリングとは、次のステップに向けて適切な情報でコンテキストウィンドウを埋める繊細な技術と科学です」
専門家たちの定義と見解
コンテキストエンジニアリングが何を意味し、どのようにコンテキストを管理できるかについて説明していきます。他にもいくつかの見解があります。
Ankerはこう言っています。「モデルがより強力になるにつれて、私はコンテキストエンジニアリングへの取り組みに焦点を当てるようになりました。これは適切な情報を適切な形式でLLMに提供する課題です」
以前の動画で取り上げた別の定義もあります。プロンプトエンジニアリングは、チャットボット向けに理想的な形式でタスクを書く努力に必要な用語として作られました。ただし、チャットボットの部分だけには同意しません。コンテキストエンジニアリングはこの次のレベルです。これは動的システムでこれを自動的に行うことについてです。
個人的には、プロンプトエンジニアリングが実際にこれらすべてのアイデアをカバーしていると思います。プロンプトエンジニアリングは単一の指示セットを書くことだけではありません。それを動的に設定することができますし、私たちはかなり長い間これを行ってきました。しかし、コンテキストエンジニアリングという別の用語があり、このパターンはかなり長い間見られていると思います。
これは検索拡張生成で起こったことで、これは本質的に情報検索です。私たちは何十年もの間これを行ってきました。
LangChainによるコンテキストエンジニアリングの定義
LangChainからの興味深い記事があります。長いコンテキストがどのように失敗するかについての別の興味深い記事も取り上げます。これは、コンテキストを無関係な情報で埋めているさまざまなシナリオと、それらを軽減する方法について話しているため、はるかに関連性が高いと思います。
この記事はコンテキストエンジニアリングのケースを作ろうとしています。LangChainによると、コンテキストエンジニアリングは、LLMが課題をもっともらしく達成できるよう、適切な情報とツールを適切な形式で提供する動的システムを構築することで、焦点はコンテキストエンジニアリングがユーザーの指示だけでなくシステムに関するものであることです。
システムが動的である理由は、エージェントのニーズに基づいて、動的にコンテキストを提供し、コンテキストを変更できるからです。その動的コンテキストが適切な情報を提供し、適切なツールセットが必要になります。適切なツールセットと情報を伝えるためには、それらの指示を伝える適切な形式が必要で、これがプロンプトエンジニアリングで行ってきたことです。
しかし、最も重要な部分は課題をもっともらしく達成できるかということだと思います。これは非常に重要だと思います。これらのLLMの上にエージェント的システムや任意のシステムを構築する際は、基盤となるモデルを見て、このモデルに適切なコンテキストを提供したとしても、モデルが実際にこの課題を達成できるかどうかを把握する必要があります。
プロンプトエンジニアリングとの違い
まず、LangChainチームが考えるコンテキストエンジニアリングとプロンプトエンジニアリングの違いを見てみましょう。彼らはプロンプトエンジニアリングをコンテキストエンジニアリングのサブセットとして提示しようとしています。
ここで彼らは「すべてのコンテキストがあったとしても、プロンプト内でそれをどのように組み立てるかは依然として絶対に重要です」と言っています。
違いは、単一の入力データセットでうまく動作するようにプロンプトを設計するのではなく、動的データのセットを取得して適切にフォーマットすることです。つまり、動的に変化するデータと動的に変化するツールセットに対するプロンプトエンジニアリングの拡張にすぎません。
コンテキスト管理の重要性
コンテキストエンジニアリングに関する多くの異なる記事が出てくるでしょうが、主なアイデアは適切な時に最も関連性の高い情報をエージェントやモデルに提供したいということです。
モデルのコンテキストに無関係な情報を詰め込むと、モデルのパフォーマンスが低下します。
コンテキストエンジニアリングの必要性を理解するためには、モデルのコンテキストウィンドウで発生する可能性のある失敗ケースを理解することが非常に重要だと思います。モデルのコンテキストに間違った情報を提供しているいくつかのシナリオを見てみましょう。
コンテキストの失敗パターン
この記事は独立コンサルタントのDrewからのもので、長いコンテキストLLMがあったとしても、モデルのコンテキストに物事を詰め込んでLLMがすべての問題を解決できることを祈るだけではいけない理由について、非常に興味深いアイデアを提示しています。
コンテキスト汚染
最初はコンテキスト汚染で、これは幻覚やその他のエラーが繰り返し参照されるコンテキストに入り込むときに起こります。
この用語自体は、Gemini 2.5の背後にあるDeepMindチームによって作られ、技術レポートで提示されています。彼らは、ポケモンをプレイしているときに、Geminiエージェントが時々プレイ中に幻覚を起こすと言っています。これが起こる理由は、エージェントの目標に対する幻覚や誤情報があるからです。
例えば、マルチターン会話があり、単一のターンで幻覚がある場合、モデルがその目標について幻覚を起こすと、会話全体に伝播し、モデルがこの幻覚された目標に焦点を当て始める可能性があります。これはエージェントからの非合理的な行動につながります。これらは特にエージェントを構築している場合、非常に興味深いアイデアだと思います。
コンテキスト注意散漫
2番目のアイデアはコンテキスト注意散漫についてです。これは、コンテキストが非常に長くなり、モデルがコンテキストに過度に焦点を当て、トレーニング中に学んだことを軽視するときに起こります。
単一のエージェントを使用している場合、またはコンテキストを共有するマルチエージェントシステムでも、エージェントはマルチターン会話を通じて特定のアクションを取ります。エージェントは反復的なアクションによって注意を散らされ、問題を解決するための新しいアイデアを考え出すのではなく、それらのアクションに焦点を当て始める可能性があることがわかります。
例えば、Gemini Proチームは、このエージェント的設定で、コンテキストが100,000トークンを大幅に超えて成長すると、エージェントが新しい計画を合成するのではなく、その膨大な履歴からの反復的なアクションを好む傾向を示したと述べました。
おそらくCursorのようなコーディングエージェントでこれを見たことがあるでしょう。時々彼らはエラーやバグに行き詰まり、解決策を見つけることができず、そのような状況では新しいセッションを作成する必要があります。
警戒すべきことは、この注意散漫の上限が小さなオープンウェイトモデルではるかに低いことです。例えば、Databrickの研究では、LLaMA 3.1 405Bでは約32,000トークン付近でモデルの正確性が低下し始め、小さなモデルではさらに早く低下することがわかりました。コンテキストに反復的なアクションを持ちたくないことを認識する必要があります。
コンテキスト混乱
次はコンテキスト混乱です。これは、コンテキスト内の余分なコンテンツがモデルによって低品質な応答を生成するために使用されるときです。これは、多数の異なるツールとツールの説明があるエージェントで特に重要です。
いくつかの研究があり、その1つでは、複数のツールが提供された場合、すべてのモデルのパフォーマンスが悪化することがわかりました。別の研究では、提供された関数のいずれも関連しない設計シナリオでは、モデルの出力が関数呼び出しなしであることを期待していましたが、それらがコンテキストにあるため、すべてのモデルが時々全く関連のないツールを呼び出すことがあり、これは小さなモデルで特に悪化します。
コンテキストにツールの説明を詰め込み、ユーザーのリクエストがどのツールにも関連していない場合でも、小さなモデルは実際にユーザーのプロンプトやクエリに焦点を当てるのではなく、ランダムなツールを選んでそれを使おうとする傾向があります。
エージェントに配置できるツールの数にも制限があるようです。私は個人的に10から15に制限することをお勧めします。これは業界の方々との会話に基づいています。しかし、ここで彼らはこの研究を参照しています。彼らはLLaMA 3.1 8億の量子化モデルに46のツールを提供し、実際にすべてのクエリで失敗しました。
46ではなく19のツールに減らしたとき、いくつかの呼び出しで成功しました。
コンテキスト衝突
最後はコンテキスト衝突です。これは、コンテキスト内の他の情報と衝突する新しい情報とツールをコンテキストに蓄積するときに起こります。これはコンテキスト混乱のより問題のあるバージョンです。
ここでの悪いコンテキストは無関係ではありません。プロンプト内の他の情報と直接衝突します。これは実際に、異なるモデルをどのようにプロンプトするかについても対処しています。推論モデルのプロンプトは非推論モデルのプロンプトとは大きく異なるという記事を見たことがあるでしょう。
解決策とベストプラクティス
例えば、ここではo3やo1タイプのモデルをどのようにプロンプトするかの提案された構造です。目標、返り値の形式、警告、そしてコンテキスト自体があります。
MicrosoftとSalesforceのチームが行った研究では、すべてのコンテキストを一度に提供することと、つまり会話の最初にすべてをダンプすることと、同じコンテキストを複数の異なるターンで提供することの違いを示しています。
このマルチターンの断片化された指示はLLMにとって悪いアイデアであることがわかります。理由は、複数のターンで段階的により多くのコンテキストを追加していくと、一部の情報が以前の情報と矛盾するように見える可能性があるからです。
ここで彼らは「断片化されたプロンプトは平均39%の低下で劇的に悪い結果をもたらした」と言っており、チームは様々なモデルでテストしました。
o3が最悪で、98%から64%に低下しました。
実践的な解決策
コンテキストを埋めることのすべての問題について話しましたが、今度は適切な時に適切な情報を確保し、エージェントやLLMのコンテキストに動的にフィードできるいくつかの解決策を見てみましょう。
RAG（検索拡張生成）
最初は古き良きRAGまたは検索拡張生成です。これは、LMがより良い応答を生成するのを助けるために、関連する情報を選択的に追加する行為です。
これは検索を超えて役立ちます。例えば、50のツールにアクセスできるエージェントがある場合、ユーザーのクエリとツールの説明に基づいてランク付けし、ユーザーのクエリに関連する小さなサブセットを選択的に選ぶことができ、それがエージェントのコンテキストに入れられます。
50のツールではなく、そのステップでエージェントは10のツールだけを見ることになり、それらのツールを適切に使用することで、おそらくはるかに良い応答を生成できます。
コンテキスト隔離
2番目のアイデアはコンテキスト隔離についてで、これは1つまたは複数のLLMによって別々に使用される専用スレッドでコンテキストを隔離する行為です。これはマルチエージェントシステムのアイデアと結びついており、OpenAIによって提案されたマルチエージェントシステムでのハンドオフのアイデアと結びついています。
グローバルな共有コンテキストではなく、独自のコンテキストを持つ特化されたエージェントを構築します。
コンテキスト剪定
次に彼らはコンテキスト剪定を提案しており、これはコンテキストから無関係またはその他の不要な情報を除去する行為です。RAGシステムを構築した場合、再ランキングはこれの本当に良い例で、最初に1000のチャンクを検索し、次にLLMに入るコンテキストをさらに削減するセカンダリ再ランキングステップがあります。
Provenenceと呼ばれる特化されたモデルがあり、これは2025年1月に発表されたものだと思います。非常に興味深いようですね。基本的に、ユーザーのクエリを見て無関係なコンテキストを除去し、その簡潔なコンテキストをモデルやエージェントに提示します。
コンテキスト要約
コンテキストを管理する次のアイデアはコンテキスト要約です。これは蓄積されたコンテキストを凝縮された要約に煮詰める行為です。チャットモデルでこれを見たことがあります。ChatGPTはこれを行いますし、一部のRAG実装でもこれを行いたいでしょう。
例えば、コンテキストウィンドウの終わりに近づいている場合、発生した以前の会話の一部を要約したいでしょう。そうすることで、LLMが焦点を当てる最も関連性の高い情報を保持できます。
興味深いことに、そのポケモンの例に戻ると、Geminiモデルには100万のコンテキストウィンドウがあり、場合によっては1000万のコンテキストウィンドウまで行けると言われているようですが、100,000トークンの作業メモリがあるようで、その後コンテキスト注意散漫が見られ始めます。
しかし、コンテキスト要約は簡単ではありません。関連情報のみを要約していることを確認する必要があり、そうでなければコンテキスト混乱と注意散漫を引き起こすからです。
コンテキストオフロード
最後のアイデアは、何らかのコンテキストオフロードメカニズムを使用することで、これはLLMのコンテキストの外に情報を保存する行為で、通常はデータを保存・管理するツールを介して行います。短期および長期記憶システムを作成できる可能性があります。
まとめ
この動画では、コンテキストエンジニアリング、コンテキストの管理方法に関連するいくつかのアイデアを見ました。コンテキストエンジニアリングの実践的な例についてさらにコンテンツを作成していきます。
個人的には、これは以前に見たことのある古いアイデアの単なるリラベリングだと思いますが、コメント欄であなたの考えを聞かせてください。とにかく、この動画が役に立ったことを願っています。ご視聴ありがとうございました。いつものように、次回お会いしましょう。
コメント