Manus 氏の洞察に満ちた記事「AI エージェントのコンテキスト エンジニアリング: Manus の構築から学んだこと」を読むことは、非常にやりがいがあり、刺激的でした。 @ManusAI AIエージェントの速度低下、知能低下、コスト増加といった問題を、モデル自体を変更することなく、モデルに入力されるコンテキスト情報構造を大幅に最適化することで解決するにはどうすればよいでしょうか?基本的には「LLMを中心としたオペレーティングシステム」を構築することであり、その点については以下に概説します。 パフォーマンスの最適化: データベースと同様に「KV キャッシュ」を保護します。 問題点: エージェントは基本的にリクエストごとに多くの繰り返し計算を実行するため、実行速度が遅く、コストがかかります。 技術的考察:大規模モデルの推論中は、一時的なKVキャッシュが生成されます。入力プロンプトの最初の部分が変更されていない場合、このキャッシュを再利用することで推論速度が10倍以上向上します。 Manus の解決策: 「プレフィックス凍結」戦略。 システムプロンプトの先頭に、動的に変化する情報(秒単位の正確なタイムスタンプなど)を挿入しないでください。先頭の1文字でも変更すると、KVキャッシュ全体が無効になり、システムは最初から計算をやり直すことになります。 これは、キャッシュヒット率を最大化するためにコードを書くときに、「静的定数」を先頭に、「動的変数」を最後に置くのと似ています。 状態管理: 大規模モデルの「健忘症」との戦い 問題点: タスク チェーンが長くなると、モデルは「途中で迷子」になりやすくなり、最初の目標や特定の中間状態を忘れてしまいます。 技術的考察:Transformerアーキテクチャは、長いテキストの冒頭と末尾に最も強い注意を払いますが、中間部分への注意は最も弱いです。中間部分にタスク履歴を単純に積み重ねると、モデルが特定の部分を「見逃す」可能性が高くなります。 マヌスに対する解決策は、「明示的な状態の朗読」です。 これは単にログに記録するだけではありません。各出力の最後に、モデルに現在の Todo リストと現在の状態を再生成するように強制します。 これは、Transformer の注意メカニズムを活用します。つまり、最も重要な状態情報をモデルの視線の最新ポイントに強制的に移動します。これは、各推論の前に「注意のキャリブレーション」を実行することと同じです。 エラー処理:「エラーメッセージ」をトレーニングデータとして扱います。問題点:従来のソフトウェアでは、エラーが発生すると通常はエラーをキャッチして再試行しますが、エージェントの場合、エラーログが削除されると、モデルはエラーが発生したことを認識できず、同じエラーを繰り返す可能性があります。 技術的洞察:大規模モデルはコンテキスト学習能力を備えています。「正しいやり方」を学習できるだけでなく、「間違ったやり方」からも学習できます。 Manus の解決策: 「負のサンプル」のコンテキストを保持します。 • エージェント実行ツールが失敗した場合、エラースタック全体が保存されます。モデルは「パスA -> 失敗」を認識し、内部確率分布によって次回の推論におけるパスAの重みを自動的に低減します。 これは実行時強化学習の一種です。モデルをトレーニングする必要はありません。「失敗例」を環境に置いておくだけで、モデルは自ら代替経路を見つける方法を学習します。 サンプル設計: モデルが「自動補完モード」に入るのを防ぐ 問題点: モデルに完璧すぎる、均一すぎる Few-Shot 形式を適用すると、モデルが愚かなものになってしまいます。 技術的洞察:大規模なモデルは、本質的に「パターンをコピーする」傾向が強いです。入力がすべて繰り返しの形式になっていると、その形式を機械的にコピーしてしまい、コンテンツのロジックについて考えることをやめる傾向があります。 マヌスの解決策: 「構造エントロピー」(ノイズ) を導入する。 • 過去のインタラクション記録が同一に見えるのを避けてください。コンテキストを構築する際には、意図的に異質で不完全な記録をいくつか残してください。 この微妙な「混沌感」はモデルの機械的な慣性を破壊し、単にテキストを補完するのではなく、回答を生成するために毎回現在のコンテンツを真に「理解」することを強制します。 原文を読む
スレッドを読み込み中
X から元のツイートを取得し、読みやすいビューを準備しています。
通常は数秒で完了しますので、お待ちください。
