自身のブログに掲載したこの短い記事で、Philipp Schmid は、コンテキストエンジニアリング が注目を集めつつある用語であり、AI の世界での議論は プロンプトエンジニアリング からこのより広い概念へと移りつつあると論じている。記事は冒頭で、これを「タスクが LLM によって妥当に解けるよう、必要なコンテキストをすべて提供する技術」とした Tobi Lutke の説明を引用し、エージェントの台頭に伴い、エージェントに与えられるコンテキストの質こそが、その成否を決める主要な要因であると述べる。彼の言葉を借りれば、エージェントの失敗のほとんどは、もはやモデルの失敗ではなくコンテキストの失敗である。
記事はまず「コンテキスト」の意味を、モデルが応答を生成する前に目にするすべてのものへと広げ、次に具体例でそれがなぜ重要なのかを示し、最後に独自の定義で締めくくる。コンテキストエンジニアリングとは「LLM がタスクを達成するのに必要なものすべてを与えるために、適切な情報とツールを、適切な形式で、適切なタイミングで提供する動的なシステムを設計・構築する分野」である。
要点
- コンテキストとは、LLM に送られる単一のプロンプトだけでなく、モデルが応答する前に目にするすべてのものである。記事は 7 つの構成要素を挙げている。指示またはシステムプロンプト、ユーザープロンプト、状態または履歴（短期記憶）、長期記憶、取得された情報（RAG）、利用可能なツール、そして構造化出力の定義である。
- 「安っぽいデモ」のエージェントと「魔法のような」エージェントの違いは、コードやフレームワークではなく、コンテキストの質にある。記事の例はスケジュール調整の依頼である。メールしか見ていないエージェントは機械的に返信するが、ユーザーのカレンダー、送信者との過去のメール、連絡先リスト、招待を送るツールを与えられたエージェントは、明日を断り、別の時間枠を提案し、招待を送ることができる。
- この捉え方では、コードの主な役割は、どう応答するかを考えることではなく、LLM を呼び出す前に LLM が必要とする情報を集めることである。
- コンテキストエンジニアリングは、文字列ではなくシステム——メインの LLM 呼び出しの前に実行されるシステムの出力——として、また、目の前のタスクのためにその場で作られる動的なものとして説明される。
- その中核的な役割は、モデルが重要な詳細を欠かないようにすること（「Garbage In, Garbage Out」）であり、知識とツールの両方を、必要かつ有用なときにだけ提供することである。
- 形式も重要である。記事は、生のデータをそのまま流し込むよりも簡潔な要約のほうが、曖昧な指示よりも明確なツールスキーマのほうが優れていると述べている。
- 記事は、信頼できるエージェントを構築することは、魔法のプロンプトやモデルの更新の問題ではなくなりつつあり、むしろコンテキストをエンジニアリングすることの問題になりつつあると結論づけ、これをビジネス上のユースケースと出力の定義を含む部門横断的な課題と呼んでいる。
背景
この記事は、深く手作業で行った調査から導いた概観として自らを位置づけており、謝辞では、このトピックに関するそれ以前のいくつかのツイートやブログ記事をインスピレーションの源として挙げている。測定結果は報告されておらず、この実践を支持する論拠は、スケジュール調整の例示と、エージェントの失敗はほとんどがコンテキストの失敗であるという著者の主張に依拠している。