LLMにタスクを委任すると文書が破損する理由
最近の研究により、LLMに文書編集などのタスクを委任すると、モデルが対話中に静かに文書を破損することが明らかになりました。DELEGATE-52ベンチマークで19モデルをテストした結果、最先端モデルでも20回のインタラクション後に25%のコンテンツが破損し、弱いモデルでは50%に達することがわかりました。原因は、エラーの蓄積、弱いモデルの削除傾向と強いモデルの幻覚、コンテキスト過負荷、およびドメイン親和性の欠如です。エージェンティックAIツールはこの問題をほとんど解決しません。
我々は新しいAI時代に入りつつあり、対話はタスクの委任へと変わっています。ユーザーは単に質問に答えるAIとチャットするだけでなく、ソースコードの編集からプロフェッショナルなテキストのフォーマット、さらには会計帳簿の管理まで、長期的なタスクを委任するようになっています。そのため、AIシステムが複数のインタラクションにわたって文書などのファイルの整合性を維持することへの信頼はかつてないほど高まっています。
しかし、最近の研究で問題が明らかになりました。大規模言語モデル(LLM)にタスクを委任すると、渡した文書を静かに破損する可能性があるのです。この問題を理解するために、研究者たちは「DELEGATE-52」という厳格な評価フレームワークを構築しました。このベンチマークは、法的テキストからPythonコーディング、音楽記譜法、結晶学に至るまで、52の専門領域にわたります。
著者らは、「ラウンドトリップ」アプローチに基づくスマートシミュレーション法を用いて、19種類のLLMをテストしました。AIに特定の編集を実行させ、その後編集を元に戻す正確な逆指示を与えるというものです。理想的なシナリオでは、モデルは元の文書を完全にそのまま返すはずです。現実は異なりました。Gemini Pro、Claude Opus、GPT-5のような最もスマートなモデルでも、20回のインタラクション後に元の文書内容の25%を破損する能力があり、弱いモデルでは50%に近づきました。
研究者たちは文書破損のいくつかの理由を明らかにしました。まず、エラーが累積します。従来の「電話ゲーム」のように、LLMの小さなエラーが静かに蓄積され、重大なものになります。単一の編集は局所的なエラーを追加するかもしれませんが、複雑な編集の連続は長期的に問題を雪だるま式に大きくし、文書の大幅な劣化を引き起こします。
次に、弱いモデルは削除し、スマートなモデルは幻覚を見ます。研究では、異なるタイプのモデルの失敗の仕方に顕著なシフトがあることが強調されました。弱いモデルは削除を引き起こす傾向があり、偶発的にコンテンツを落とし、複数のインタラクション後に文書全体の明らかな縮小により問題が顕著になります。しかし、フロンティアLLMでは、根本的な問題は削除ではなく破損です。文書の全体的な「見た目と感触」を維持し、単語数さえほぼそのまま保ちますが、黙ってタイプミスをしたり、修正したり、事実情報をもっともらしいが偽の情報に置き換えたりします。皮肉なことに:モデルが賢いほど、その破損行動を検出するのが難しくなります。最終出力は一見するとまだ正当に見えるからです。
第三に、コンテキストの過負荷と注意散漫な添付ファイル:多くのコンテキスト情報や過剰な添付文書がある混乱した状態では、モデルは情報を構造的に維持するのに苦労します。文書サイズが大きくなるか、プロンプトコンテキストに「注意散漫ファイル」が多く含まれると、劣化の深刻さと影響は急上昇し、正確な詳細を把握できなくなり、予測ロジックに基づいてギャップを埋めます。モデルはもはやソーステキストに従わず、推測する方が簡単だと判断します。
最後に、ドメインの親和性も重要です。委任ベースのタスクにおいて、すべてのファイルが同じ程度に劣化するわけではありません。研究によれば、LLMはPythonソースコードのような高度に構造化されたプログラム領域では良好に機能します。純粋な自然言語タスクやニッチな空間フォーマットに押し出されると、ファイルを完全に保つために必要な厳密な内部論理の感覚をすぐに失います。
LLMにエージェンティックツール(コード実行やファイルの直接読み書きなど)を付与してアップグレードしても、委任に基づく文書破損と劣化の問題は消えません。実際、エージェンティックアドオンは、LLMの基礎にあるトランスフォーマーアーキテクチャの中核で発生する問題を防ぐためにほとんど何もしません。長期的なAIタスクをどのように検証すべきか再考する必要があります。それまでは、LLMを完全に教師なしの文書エディタとして使用することは、高リスクの賭けのままです。