博士

やあ、ロボ子。今日はLLMのコンテキストエンジニアリングについて話すのじゃ。

ロボ子

博士、コンテキストエンジニアリングですか。なんだか難しそうですね。

博士

難しくないぞ！LLMは会話を追記型で処理するから、コンテキストがどんどん増えて、性能が落ちることがあるんじゃ。まるで部屋が散らかっていくみたいなものじゃな。

ロボ子

なるほど。それで、どうすればいいんですか？

博士

そこで登場するのが、RAG（Retrieval Augmented Generation）じゃ！必要な時に必要なコンテキストを動的に見つけてロードするんじゃ。まるで優秀な秘書がいるみたいじゃな。

ロボ子

RAGですね。他に方法はありますか？

博士

Subagentsという手もあるぞ。専門的な指示とツールをカプセル化して、メインスレッドを汚染しないようにするんじゃ。それぞれのタスクに特化した小さなエージェントをたくさん作るイメージじゃな。

ロボ子

ふむふむ。それから、`get_*`ツールというのもあるんですね。

博士

そうじゃ！モデルが関連情報をツール呼び出しで要求するんじゃ。必要な情報をピンポイントで取りに行く感じじゃな。

ロボ子

なるほど。でも、もっと面白い解決策があるみたいですね。HATEOASをLLMに応用する、と。

博士

よくぞ聞いてくれた！HATEOASは、人間がリンクをたどるように、LLMもリンクを介して情報を探索する仕組みじゃ。エージェントがハイパーリンクのコンテキストと関連性を解析・ナビゲートするんじゃ。

ロボ子

リンクベースのコンテキストシステムですか。具体的にはどうすれば？

博士

URIリストを引数として受け取るツールと、少なくとも1つのURIをコンテキストに取り込むエントリーポイントが必要じゃ。これだけで、LLMはリンクを辿って必要な情報を集められるようになるんじゃ。

ロボ子

リンクの利点は何ですか？

博士

実装が簡単で、モデルは直感的にリンクの辿り方を理解するぞ。それに、会話の流れのどこでも指定できるし、トークン効率も高いんじゃ。必要な情報へのオンデマンドアクセスを提供できるのが大きいな。

ロボ子

ツール効率も高いんですね。単一のツールで様々なデータ型に対応できる、と。

博士

そうじゃ！ジャストインタイムコンテキストを提供し、コンテキストの劣化や最近傍バイアスを軽減できるんじゃ。まるで新鮮な情報だけを食べるグルメみたいなものじゃな。

ロボ子

MCP (Model Context Protocol) Resourcesの活用も重要なんですね。

博士

その通り！サーバーがURIを登録し、クライアントがオンデマンドでコンテンツを読み取るんじゃ。MCP対応エージェントは、URIを受け取り、MCPサーバーとWeb URLから集約する`read_resources`ツールを公開すべきじゃ。

ロボ子

Firebase MCP Serverでの実装例もあるんですね。

博士

そうじゃ。Firebase MCP ServerにMCP Resourcesのサポートを追加して、Firebase MCP Serverからリソースを読み取る`read_resources` MCPツールを作成するんじゃ。Firebaseの設定を段階的に案内するMCPプロンプトも作ると良いぞ。

ロボ子

ハイパーリンクは効率的な情報探索メカニズムであり、エージェントに不可欠なんですね。

博士

その通り！複数の`get_*`や`list_*`ツールを構築する代わりに、ハイパーリンクの活用を検討する価値は大いにあるぞ。…ところでロボ子、今日はリンクを辿って私の秘密のクッキーの隠し場所を見つけてみてくれんかの？

ロボ子

博士、それはコンテキストエンジニアリングとは関係ないですよね？