LangChainコミュニティが要約検証の不備を報告、空の応答でエージェントが作業コンテキストを失う可能性

LangChainの会話圧縮機能で、新たな境界ケースが報告された。10月20日に投稿された報告によると、SummarizationMiddlewareは空の要約を受け取ってもメッセージの置き換えを実行する可能性があり、エージェントは重要な情報が欠けたコンテキストで処理を続けることになる。報告された環境はlangchain 1.4.6、langchain-core 1.6.12。現在もIssueはオープンしており、すべてのバージョンに影響すると断定することはできない。コミュニティ報告

このミドルウェアは、長時間の会話を支援するために設計されている。設定したしきい値に達すると、古いメッセージをテキスト要約に圧縮し、直近の内容を保持する。公式ドキュメントでは、トークン数、メッセージ数、コンテキスト比率などのトリガー条件が説明されており、keepは保持する直近の内容量を制御する。そのため、古い情報を保存する役割は要約自体が担っており、単なる任意の補足テキストではない。公式ドキュメント

報告者は、常に空文字列を返す固定のモックモデルを使い、トリガーしきい値を6メッセージ、保持数を2メッセージに設定した。サンプルでは、まずエージェントにファイルを読ませてコードを記憶させ、その後、別のファイルを読むよう指示する。出力に残るのは要約ヘッダーと末尾のツール操作だけで、それ以前のコードと最新のユーザー指示は保持されず、エラーも発生しなかった。これは検証可能な最小ケースであり、実際のモデルサービスでの発生率を示す統計ではない。再現コードと出力

技術的なポイントは、モデル呼び出しの成功と、要約内容の有効性との間に検証の段階が欠けていることだ。報告の分析によると、該当する処理経路ではテキストを取得して前後の空白を除去した後、空の結果を拒否せずに履歴の置き換えへ進む。参加者は、削除メッセージを作成する前に例外を投げる案と、同期・非同期・カスタム要約器で共通の検査を行う案を提示した。別案として、その回の圧縮をスキップする方法もあるが、その場合はコンテキストが増え続けるというトレードオフがある。現時点では、いずれも修正提案にとどまる。技術的な議論

エンジニアリングチームにとって、この事例は圧縮処理に独立した成功条件が必要であることを示している。上記の仕組みから考えると、検証では空の要約が返ったときに元の状態が保持されるかを確認し、圧縮後もユーザー指示とツールの結果をたどれるかをテストする必要がある。今後は、メンテナーがどのような失敗処理を採用するか、また修正が各実行経路を網羅するかが注目点となる。現時点の証拠から、永続データベース内の完全な会話が永久に削除されたと結論づけることはできない。