Reasoning Summaries の実装原理：それは Agent ワークフローでどのように機能するのか

本格的なデバッグから始めましょう

先週、マルチステップのエージェントをデバッグしていた際、3番目のステップで突然「さっき何を言ったか覚えていません」と応答することに気づきました。ログを確認すると、LLMへのすべての呼び出しで完全な会話履歴が得られますが、トークンの制約によりモデルは最後の数ラウンドのみを読み込みます。さらに悪いことに、その間の重要な推論ステップが途切れ、エージェントはただランダムに推測しかできません。

このシナリオこそが、推論要約が解決しようとする核心的な問題です。すなわち、完全な歴史が文脈ウィンドウに完全に収まらないときに、最も価値のある推論情報をどう保持するかということです。

論理要約とは一体何でしょうか?

論理要約は単なる会話の要約ではありません。これは、エージェントの内部推論プロセスの構造化された圧縮結果の集合であり、通常は以下を含みます。

推論チェーンのキーノード(例:中間仮定、検証結果、分岐決定)
各ノードの信頼度または優先度マーカー
外部ツール呼び出しの結果(検索リターン、コード実行出力など)

通常の要約とは異なり、情報の整合性よりも「論理的な進行」を維持することに重点を置いています。例えば、財務担当者が財務報告書を分析する際、「ステップ1でキャッシュフローがマイナスの場合、その後の評価モデルが割引率を調整する必要がある」と覚えておくべきで、「レポートにマイナスキャッシュフローが言及されている」とは言及されません。前者は推論であり、後者は事実です。

デスクトップには比較メモが置かれており、要約圧縮とスライディングウィンドウの二つの方法の利点と欠点を示した比較表が記載されています。

エージェントのワークフローで具体的に何を解決するのでしょうか?

エージェントのワークフローは循環構造を持つ傾向があります。状態を観察する -> 行動を計画 ->実行 -> ステータス更新。これら4つの段階では、推論要約は主に「更新状態」フェーズを担当し、現在の推論結果を圧縮し、次のラウンドのためにメモリに統合します。

具体的には、3つの実用的な工学的問題を解決します。

コンテキストウィンドウオーバーフロー:複数回のやり取りの後、履歴はモデルの最大トークン制限を簡単に超えてしまいます。要約は複数の会話を簡潔な論理の要約にまとめ、最も重要な意思決定原則を保持します。
推論の崩壊:モデルは長時間の会話で早期結論を失いがちです。推論チェーンの要約を明示的に維持することで、コンテキストウィンドウが更新されても、エージェントは要約に基づいて推論を続けることができます。
デバッグの困難:エージェントの挙動が異常な場合、ログ全体を見るのは苦痛です。要約は、不良箇所を迅速に見つけるための明確な主要な理由を提供します。

失敗しやすい最も難しい場所

私が関わったプロジェクトでは、最も一般的な故障は過圧縮です。

チームは「最大圧縮率」戦略を採用し、各ラウンドのアウトプットを一文に凝縮します。その結果、エージェントは元の目標を見失い、最初のラウンドでデータベースAを確認し、2ラウンド目にデータ不足を見つけてデータベースBに切り替え、3ラウンド目ではAを諦めた理由を忘れて再度確認に戻ったのです。

もう一つの高周波エラーは圧縮タイミングエラーです。一部の機器はLLM呼び出しの直後に圧縮を選択し、その結果圧縮自体が多くの推論予算を消費し、頻繁な圧縮操作がメインロジックを中断します。より合理的な方法は、コンテキストが70%の容量に達する直前まで圧縮をトリガーするか、ツールコール後など、各重要な転換点で一度ずつ圧縮することです。

もう一つ見落としがちな点:圧縮された要約はネガティブな情報や条件付き制約を失う可能性があります。例えば、元の理由は「売上が増加すれば生産を増やす」というものでしたが、要約では「生産量を増やす」だけが残る場合があり、条件が満たされない場合にエージェントが誤った行動を取ることもあります。圧縮プロセスが条件構造を保持していることを確実にすることが不可欠です。

今こそ実行の時です—最初のステップは何でしょうか?

最初のステップはコードを書くことではなく、エージェントが覚えておくべきことを定義することです。

現在責任を持つエージェントのための推論メモリテンプレートを作成します。例えば、コードレビューエージェントには以下のようなものが必要になる場合があります:

現在のレビュー中のコードファイルおよび行番号の範囲
発見されたバグとその深刻さ
まだチェックされていないモジュールの一覧
既存の結論(例:メモリリークの発見とキャッシュ戦略の調整が必要)

ステップ2:適切な実施方法を選択します。現在、主流の解決策には以下が含まれます:

LLMを使った自然言語要約生成:シンプルですが、要約の質はプロンプト設計に依存し、詳細が失われる可能性があります。より単純なタスクを持つエージェントに適しています。
構造化レコード:辞書やデータクラスに決定木を格納し、ノード値を毎回更新します。正確な圧縮は可能ですが、あらかじめ定義されたスキーマが必要です。固定論理の作業に適しています。
ハイブリッドソリューション:構造化されたキーフィールドと自然言語の要約の両方を維持し、後者はLLMが文脈を理解するために、前者は正確な検索に使用されます。

ステップ3:エージェントループに統合する。状態更新の各ステップの後、圧縮閾値に達しているか確認します。もし達成済みなら、要約関数を呼び出し、履歴の一部を要約に置き換え、デバッグのために要約を「圧縮されたコンテンツ」としてマークします。

失敗時のバックアッププラン

推論要約が効果的でない場合(例えば、要約後にエージェント推論の質が大幅に低下する場合)、次の2つの選択肢に戻すことができます。

スライディングウィンドウ戦略:文脈にこだわらず、最新のNラウンドの完全な記録には固定サイズのウィンドウを使用し、初期の歴史は捨てる。単一セッションのQ&Aのように、歴史的関連性の低いタスクに適しています。
検索強化メモリ:各推論ラウンドはベクトルとして符号化されベクトルデータベースに保存され、エージェントは推論前にTop-K関連履歴を取得します。数日間にわたるプロジェクトレビューなど、長期的な作業に適しています。

もちろん、これら2つの選択肢は最低限の保証に過ぎません。チームのリソースに余裕があれば、専用の要約モデルを微調整することもできますが、それは長い道のりです。

概要

推論要約はエージェント工学において避けられない要素です。正しく行えば、ロングチェーン推論の安定性を大幅に向上させることができます。間違えると、さらに隠れたバグが増えてしまいます。重要なのは「完全で美しい」要約を追求することではなく、戦略的に論理的なリードを保存することです。