Open WebUI、コンテキスト圧縮の制限を明確化　巨大な単一ターンの応答で会話がコンテキストウィンドウを超える可能性

Open WebUIは10月20日の技術議論で、自動コンテキスト圧縮の限界を明らかにした。会話が設定したtokenしきい値を超えても、要約が必ず生成されるとは限らない。報告者によると、ツールを多用するエージェントタスクでは、大量の出力が単一のassistantメッセージに保存されることがあり、メッセージ数は少ない一方で、実際の内容はすでにモデルのコンテキストウィンドウを超えている会話が生じる。プロジェクトメンバーは報告を機能要望として分類し直し、現在の動作はドキュメントの説明どおりだと述べた。議論とプロジェクト側の回答

報告では、2つの判定が問題として挙げられた。メッセージが3件以下の場合は圧縮がスキップされる。また、直近の内容を残すための切り分け位置は、各メッセージのtoken数ではなく、メッセージ数に基づいて選ばれる。そのため、長い会話で要約が実行されても、保持された1件の巨大なツール応答によって、次のリクエストが上限を超える可能性がある。報告者は、実際の0.12.0環境でこの状況を確認し、モデル呼び出しを必要としない再現手順も提示した。ただし、これらの観察結果をすべてのバージョンに共通する影響と混同すべきではない。報告の詳細

バージョンによる違いが重要だ。プロジェクトメンバーによると、0.12.1以降はネイティブのツールループでもツールターンの間にコンテキストを確認して圧縮するため、ツール履歴全体が蓄積して巨大な応答になる状況を軽減できる。一方、すでに上限を超えた古いメッセージには、別の制約がある。要約リクエスト自体に、要約対象の全文を収める必要があるため、手動で実行する/compactも失敗する場合がある。メンバーは、影響を受けたユーザーに対し、最初のメッセージを編集して再送信し、巨大な応答を含まない新しいブランチを作るか、新しい会話を開始するよう勧めた。対処方法

公式ドキュメントには、圧縮はデフォルトで無効であり、ターン開始時に適切なユーザーメッセージを切り分け位置として見つける必要があると明記されている。見つからない場合は、履歴全体が送信される。そのため、エンジニアリングチームはしきい値を要約開始の条件として扱い、最終的なリクエストサイズを別途検証すべきだ。特に、単一ターンで大量のツール出力が生じる負荷をテストする必要がある。入力上限を確実に守るには、filter Functionを使って切り詰めるポリシーを実装するよう、ドキュメントは勧めている。コンテキスト管理ドキュメント

コミュニティはtoken数に応じて切り分け位置を調整する修正を提案したが、そのPRはクローズされ、マージされていないため、正式な修正とは見なせない。今後は、プロジェクトがこの種の切り分け方式を採用するか、また既存の巨大なメッセージに対して、より直接的な復旧手段が用意されるかが注目点となる。修正提案