LangChain、LLM の信頼性向上に「コンテキストエンジニアリング」の重要性を指摘

ヘッダー画像：Dex Horthy on Twitter より。

コンテキストエンジニアリングとは、LLM がタスクを合理的に遂行できるよう、適切な情報とツールを正しい形式で提供するための動的システムを構築する営みです。

エージェントが信頼性を持って動作しない場合の根本原因は、往々にして適切なコンテキストや指示、ツールがモデルに正しく伝えられていないことにあります。

LLM を活用したアプリケーションは、単一のプロンプトから、より複雑で動的なエージェントシステムへと進化を遂げています。その結果、コンテキストエンジニアリングは AI エンジニアが習得すべき最も重要なスキルとなりつつあります。

コンテキストエンジニアリングとは何か？

コンテキストエンジニアリングとは、LLM がタスクを合理的に遂行できるよう、適切な情報とツールを正しい形式で提供するための動的システムを構築する営みです。

これは私が好む定義ですが、Tobi Lutke、Ankur Goyal、そして Walden Yan による最近の議論を踏まえたものです。詳しく見ていきましょう。

コンテキストエンジニアリングはシステムである

複雑なエージェントは、複数の情報源からコンテキストを取得することが一般的です。その情報源には、アプリケーションの開発者やユーザー、過去のやり取り、ツール呼び出しの結果、あるいは外部データなどが含まれます。これら多様な要素を統合するには、高度に複雑なシステムが必要です。

このシステムは動的である

これらのコンテキストの多くは動的に変化します。したがって、最終的なプロンプトを構築するロジックもまた動的でなければなりません。単なる静的なプロンプトでは不十分です。

適切な情報が必要だ

エージェント型システムがうまく機能しない理由としてよく挙げられるのが、「必要なコンテキストが不足している」ケースです。LLM（大規模言語モデル）に心を読む能力はありません。正しい情報を提供して初めて、期待通りの結果が得られます。「ゴミを入れればゴミが出る」という原則は、ここでも厳然と成り立ちます。

適切なツールが必要だ

LLM が入力情報だけでタスクを完遂できる場合ばかりとは限りません。そのような状況で LLM に能力を発揮させるには、適切なツールを提供する必要があります。これには、追加情報の検索やアクションの実行など、多様な機能が含まれます。正しい情報を提供することと同様に、LLM にとって適切なツールを用意することも極めて重要です。

形式も重要だ

人間と対話する際と同じく、LLM とのコミュニケーション方法も結果に大きく影響します。短くても具体的なエラーメッセージは、巨大な JSON ブロックよりもはるかに効果的です。この原則はツールの設計にも当てはまります。ツールへの入力パラメータがどうあるかは、LLM がそれらを正しく利用できるかどうかを決定する上で極めて重要です。

実際にタスクを達成可能か？

これは、コンテキストエンジニアリングについて考える際に非常に重要な質問です。この問いは、大規模言語モデル（LLM）が読み取り能力を持たないことを再認識させます。成功させるためには、適切な設定が必要です。

また、失敗の原因を特定する手助けにもなります。それは、必要な情報やツールを提供しなかったことが原因で失敗しているのか、それとも正しい情報は持っていたものの、処理にミスがあったのかです。これらの失敗モードには、それぞれ異なる解決策が存在します。

コンテキストエンジニアリングが重要な理由

エージェントシステムが失敗する主な理由は、LLM が誤った判断を下すことにあります。第一原理から考えれば、LLM が失敗する理由は主に二つあります。

• 基盤となるモデル自体の性能不足
• 適切なコンテキストが提供されず、良質な出力が得られなかったこと

モデルが向上するにつれて、特に後者の理由によるミスが増えています。モデルに渡されるコンテキストが悪い原因としては、以下のようなものが考えられます。

• 必要な情報が欠落している：LLM は読み取り能力を持たないため、適切なコンテキストを与えなければ、その存在自体を認識できません。
• コンテキストの形式が不適切である：人間と同様に、コミュニケーションは重要です。モデルにデータを渡す際のフォーマットは、その反応に確実に影響を与えます。

コンテキストエンジニアリングとプロンプトエンジニアリングの違い

「プロンプト」から「コンテキスト」へ、なぜシフトするのか？

初期の段階では、開発者はより良い回答を引き出すためにプロンプトを巧妙に表現することに注力していました。しかし、アプリケーションが複雑化するにつれて、魔法のような言葉遣いよりも、AI に対して完全で構造化されたコンテキストを提供することの方がはるかに重要であることが明らかになってきています。

また、私はプロンプトエンジニアリングはコンテキストエンジニアリングの一部であると主張したいです。どんなに優れたコンテキストを用意しても、それをプロンプト内でどのように組み立てるかという点は依然として極めて重要です。違いは、単一の入力データセットに対してうまく機能するようにプロンプトを設計するのではなく、動的なデータセットを受け取り、それを適切にフォーマットできるように設計するという点にあります。

さらに強調したいのは、コンテキストの重要な要素には、LLM がどのように振る舞うべきかを示すコアとなる指示が含まれることが多いという点です。これは従来、プロンプトエンジニアリングの主要部分とみなされてきました。「エージェントがどのように行動すべきか」を明確かつ詳細に指示することは、コンテキストエンジニアリングなのか、それともプロンプトエンジニアリングなのか？私はそれは両方の要素を含むものだと考えます。

コンテキストエンジニアリングの具体例

良いコンテキストエンジニアリングの基本的な例としては以下のようなものが挙げられます：

ツール使用：エージェントが外部情報へのアクセスを必要とする場合、その情報を取得できるツールを用意します。ツールから返された情報は、LLM が最も理解しやすい形式で整形されます。

短期記憶：会話が長期間続く場合、会話の要約を作成し、それを将来の処理に活用します。

長期記憶：ユーザーが過去の会話で好みを表明した場合、その情報を取得して利用できるようにします。

プロンプトエンジニアリング：エージェントの振る舞いに関する指示を、プロンプト内で明確に列挙します。

検索（Retrieval）：LLM を呼び出す前に、必要な情報を動的に取得し、プロンプトに挿入します。

LangGraph が実現するコンテキストエンジニアリング

LangGraph LangGraph を開発した際、最も制御性の高いエージェントフレームワークとなることを目指しました。これにより、コンテキストエンジニアリングを完璧にサポートすることが可能になります。

LangGraph では、すべての要素を完全に制御できます。どのステップを実行するかはあなたが決定し、LLM に入力される内容を正確に指定できます。出力の保存場所も自分でコントロール可能です。すべてを自在に操れるのです。

これにより、あらゆるコンテキストエンジニアリングを実現できます。他の多くのエージェントフレームワークが重視する「エージェントの抽象化」には、コンテキストエンジニアリングを制限するという欠点があります。例えば、LLM に入力される内容を正確に変更できない場合や、事前に実行されるステップを変更できない場合があります。

補足：Dex Horthy 氏の「12 Factor Agents」は非常に読み応えのある記事です。そこで言及されている多くのポイントが、コンテキストエンジニアリング（プロンプトの所有権を持つ、コンテキスト構築の主体となるなど）に関わっています。この記事のヘッダー画像も Dex 氏から提供いただいたものです。私たちは、この分野で何が重要かを伝える彼のスタイルを大変気に入っています。

コンテキストエンジニアリングにおける LangSmith の役割

LangSmith は、LLM アプリケーション向けの観測性と評価を提供するソリューションです。その主要な機能の一つが、エージェント呼び出しのトレース機能です。「コンテキストエンジニアリング」という用語は、LangSmith を構築した当時には存在しませんでしたが、このトレース機能が解決する課題を的確に表しています。

LangSmith を使えば、エージェント内で実行されるすべてのステップを確認できます。これにより、LLM に送信されたデータを収集するためにどのステップが実行されたかを把握可能です。

また、LLM への入力と出力を正確に表示することもできます。これによって、LLM に実際に何が渡され、データがどのようにフォーマットされていたかを明確に確認できます。その結果、タスクに必要な関連情報がすべて含まれているかどうかのデバッグが可能になります。さらに、LLM がアクセスできるツールの情報も含まれるため、現在のタスクを支援するために適切なツールが与えられているかどうかも検証できます。

コミュニケーションこそがすべてである

数ヶ月前、私は「コミュニケーションこそがすべてである」というブログ記事を書きました。その核心は、大規模言語モデル（LLM）への指示出しが難しく、かつ十分に評価されていない点にあります。多くのエージェントの誤動作は、このコミュニケーションの問題に起因しています。これらの課題の多くは、「コンテキストエンジニアリング」に関係しています。

コンテキストエンジニアリングという概念自体は新しいものではありません。エージェント開発者は過去1〜2年の間、すでに実践してきました。しかし、これはますます重要になるスキルを的確に表す新たな用語です。私たちは今後、このトピックについてさらに詳しく記事を書き、共有していく予定です。私たちが構築したツール（LangGraph や LangSmith など）は、コンテキストエンジニアリングを可能にするために最適化されており、この分野への注目が高まることを心から楽しみにしています。