LLMは委任されると文書を損なう

 (arxiv.org)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • DELEGATE-52 は、ユーザーが長文の文書編集作業を LLM に任せる委任型ワークフローにおいて、文書がどれだけ忠実に維持されるかを評価するベンチマーク
  • このベンチマークは、コーディング、結晶学、楽譜表記など 52の専門領域 にわたり、深い文書編集を必要とする作業を扱い、例示シミュレーションは 20の連続作業 の委任で構成される
  • 19の LLM 実験では、Gemini 3.1 Pro、Claude 4.6 Opus、GPT 5.4 のようなフロンティアモデルであっても、長いワークフローの終了時には平均して文書内容の 25% を損なう
  • 文書の損傷はまれだが深刻なエラーとして現れ、文書サイズ、相互作用の長さ、妨害ファイルが増えるほど劣化が大きくなり、エージェント型ツールの使用でも性能は改善しない
  • 現在の LLM は、委任型の文書編集において信頼できる代理人と見なすのは難しく、microsoft/DELEGATE52 と datasets/microsoft/DELEGATE52 が DELEGATE-52 関連資料として公開されている

委任型編集の失敗パターン

  • 委任型の業務は、ユーザーが作業を LLM に任せ、LLM が文書に誤りを入れずに作業を遂行するという 信頼 を前提とする
  • 19の LLM を対象とした大規模実験で、現在のモデルは委任の過程で文書を劣化させる
  • 他のモデルはフロンティアモデルよりもさらに深刻に失敗する
  • 文書の損傷は長い相互作用のあいだに蓄積し、文書を静かに壊していく

例として示された文書の変化

  • Graph Diagrams 領域の Linux Kernel Architecture 文書は、Gemini 3.1 Pro で原本比 4回後 79%、10回後 49%、14回後 48%、20回後 48% と示される
  • Textile Patterns 領域の 12-Shaft Twill Diamond 文書は、Claude 4.6 Opus で原本比 4回後 100%、10回後 40%、14回後 27%、20回後 34% と示される
  • 3D Objects 領域の ActionBoy Palm Tree 文書は、GPT-5.2 で原本比 4回後 100%、10回後 31%、14回後 15%、20回後 6% と示される

公開資料

  • microsoft/DELEGATE52
  • datasets/microsoft/DELEGATE52

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsの意見

  • ツール使用の結果については懐疑的

    長い内容をLLMに往復で通せば損傷するのは驚くことではない。LLMを頻繁に使う人たちは、そうしてはいけないことをすでに知っている。

    論文でツール使用が役に立たなかったとされていたのは意外だったが、同時に「基本的なエージェントハーネス」を実装しただけで、最新式に最適化されたシステムではないとも明記している。

    実際のハーネスは read_file() と write_file() しかなく、単に 往復処理に1段階追加しただけ に近い。最近のコーディングエージェントのハーネスはファイル編集ツールの設計にかなり力を入れていて、たとえばClaudeの編集ツール群がある: https://platform.claude.com/docs/en/agents-and-tools/tool-us...

    str_replace と insert コマンドは、ファイル全体を書き直す危険な編集を避けるうえで重要だ。

    少なくとも run_python() ツールは提供されているので、より良いモデルならこれを使って文字列置換を実行した可能性はある。システムプロンプトがPythonベースの操作を推奨していたのか、それともファイルを読んで書き戻すよう誘導していたのかを見てみたい。

    ハーネスのコードはここで見つけた: https://github.com/microsoft/delegate52/blob/main/model_agen...

    関連するプロンプト断片には、「プログラミング方式であれ直接ファイルを書く方式であれ、最も効果的だと思う方法で取り組んでよい」とある。

    こうした論文はよくあることだが、結果はモデル自体よりも、論文著者が使った ハーネス設計 をより強く反映している。経験のあるAIエンジニアでもプロンプトエンジニアでも、ハーネス自体を反復的に改善すれば、このテストでより良い結果を出せると思う。

    • ほとんど同意するが、「LLMを頻繁に使う人たちは、そうしてはいけないことをすでに知っている」という部分だけは例外だ。

      今は組織やチーム全体にLLM導入の波が押し寄せていて、毎日LLMを使っていても ハーネス のような技術的なものには触れたことすらない人が多く、むしろ多数派かもしれない。

      そういう人たちにとって、ここで述べられている挙動は大きな問題だ。

    • 少し関連する話だが、ed を基本のファイル編集/読み取りツールとして使うハーネスを見てみたい。Claudeが実行するbashの半分はどうせ sed のようなものに見えるし、ed に状態が保持されるなら役立ちそうだ。

      フル機能のエディタが帯域幅^Hトークンを食いすぎるときはどうする？ 標準エディタの ed を使えばいい。

    • これはLLMの作業をやや藁人形化した例に近い。

      編集作業では プログラム的な編集コマンド だけを許可すべきで、テキスト自体をLLMに通してはいけない。LLMはテキストを解析し、フィードバックに基づいて目的を達成するためのコマンドを出力すべきだ。

    • HNでは結果をできるだけ否定的に解釈しようとする傾向がある。自分の仕事やアイデンティティへの脅威だと感じているからだ。

      実際、文書を読んだ後に修正を反映して文書全体を言い直す形で編集するなら、人間でも25%劣化より悪い結果を出しうる。人間が0%劣化を達成することも可能ではあるが、その状態は文書を何百回も入力されて 暗記 して初めて実現する。LLMでこれに相当するのは学習であり、文書をLLMに学習させれば、このケースでは暗記した人間の編集と同等になりうる。

      ただし上の話は本質ではない。LLMは人間に似た点があるのだから、人間が文書を編集するのと同じように、検索と外科的修正で編集するようハーネスを設計すべきだ。すべてのコーディングエージェントはそうやって編集しているので、この論文はあまり関連性がない。

    • リソース制約のためであれ単純化のためであれ、理解しがたい方法論のせいで、こういう論文は残念ながら価値が下がる。

  • 以前から言っているが、どんなテキストでも AIで上塗り すると品質は落ち、それを繰り返すほど累積する。

    これを呼ぶ言葉としては「意味的アブレーション（semantic ablation）」がいちばん気に入っている: https://www.theregister.com/software/2026/02/16/semantic-abl...

    • 私はこれを 平均知能への回帰 と呼んできた。
    • 「繰り返すほど」というのが同じセッション内で繰り返す意味なのか、それとも毎回新しいセッションや新しいコンテキストウィンドウで行う意味なのか気になる。

  • 「委任には信頼が必要だ。LLMが文書に誤りを入れず、作業を忠実にこなすと期待できなければならない」という話だが、まさにこれが、数十個のMarkdownファイルで書かれたハーネスやプロンプト儀式が宣伝どおりには機能しない理由だ。実質的には エージェントエンジニアリング という名の疑似科学に近い。

    エージェントエンジニアリングも結局はいわゆるプロンプトエンジニアリングとほとんど同じで、ただプロンプトが今では数十個のMarkdownファイルやディレクトリに散らばっているだけだ。

  • 最近読んだLLM関連の話の中で、いちばん驚きが少ない内容だった。

    LLMはJPEGミームに近い。JPEGで保存するたびに画質が少しずつ落ち、最後には見分けがつかなくなるのと同じように動く。

    ただしLLMでの出発点は 意図 だ。LLMを1回通すごとに意図が劣化し、精密な科学論文のような場合には、言い換えの過程で微妙なニュアンスや精度が少しずつ失われる。

    LLMは平均への回帰マシンだ。現在扱っているコンテキストや作業負荷が学習範囲から外れるほど、それをますます均質で抽象的な平衡状態へ引き寄せようとする傾向が強くなる。

    • LLMでコーディングしていると確かにそれを経験する。機能実装を一気に片づけた後、自分ではかなり慎重だったつもりでも、後で小さなコード片を詳しく見ると「うわっ」と思う瞬間がよくある。

      その後で何時間もかけて全体を見直し、思いどおりになっていない部分、自分の指示が曖昧だった部分、LLMの妙な癖が発動した部分を注意深く直さなければならない。

      コード品質そのものも重要だが、まさにこの 反復圧縮 の問題が気がかりだ。コードベースがきれいで、自分の頭の中のモデルが最新なら、LLMは機能実装を素早く助けつつ、コードベースをまずまずの状態に保てる。しかしLLMがコードベースを汚し始めると、過去のミスや誤解が蓄積し、ますます多くを間違える可能性が高くなる。だからLLMを再び使う前に、正しい状態へ「復元」しておきたくなる。

    • この結果が本当に興味深く関連があるのは、コーディングエージェントが大きなソースファイルを複数の小さなファイルへ分割するときだ。OpusやClaude Codeは、人間のようにコピー＆ペーストの操作を使う代わりに、長いソースコード区間を記憶から暗唱して新しいファイル群に入れようとする。

      ファイル移動は少し簡単だ。LLMがたまにファイルを記憶から言い直そうとすることはあるが、git mv を使ってコンパイラエラーを直せと言えば、たいていはうまくやる。

      一方で通常の編集は、まともなモデルとツール構成があればたいてい問題なく動く。Qwen3.6 27B でもこの程度は大丈夫だ。インプレース修正なら git diff で想定外の変更を確認することもできる。

    • これを示す子どもの遊びもある: https://en.wikipedia.org/wiki/Telephone_game

    • 同僚はLLMを「でたらめレイヤー」と表現している。完全なけなし言葉ではなく、何かをLLMに通すたびに、反対側から出てくる結果が期待や希望と違う可能性があることを強調する表現だ。

      酒場で何杯か飲んだ人が、どこかで見たというオンライン情報を伝えてくるのに似ている。合っているかもしれないが、違うリスクもかなり高い。

      たとえばAPIを呼んでデータを集め、レポートを作るのにLLMを使うべきではない。決定的なデータを でたらめレイヤー に通すことになり、結果を信頼できないからだ。代わりにLLMは、決定的なデータから決定的な出力を作るコードを書くために使うほうがよい。

      同僚たちがAPIから来た決定的データをLLMに要約させて、レポートが当たるときと同じくらい大きく外れるのも見てきた。何を見ているかによっては破滅的なリスクになりうる。

    • 履歴書の編集でこれを経験した。LLMは、私の履歴書を平均的な経験しかないジュニアエンジニアのダミーと区別してくれる要素をすべて取り除いてしまう。特別なもの、独特なもの、違いを生むものは、結局すべて一般的な文句に置き換えられる。

      もちろんその出力は使わなかったが、LLMがそれでも元のものより良いと主張し続けるのは本当にうんざりした。

      LLMは履歴書全体の方向性を決めるよりも、ごく小さな塊、たとえば1文や3文程度の修正提案をもらうときのほうがはるかに有用だった。

  • 問題は、私たちがLLMにあまりに多くの仕事をさせていることだ。エージェントは、自然言語の意図を 決定的なプロセス に変換するできるだけ薄い層としてLLMを使うよう設計すべきで、LLMの往復は可能な限り減らすべきだ。

    • 少しでも複雑なことをやろうとする人なら、これが明らかになる。前処理フロー、意味ベースの対象指定、最小限のコンテキスト呼び出しをLLM APIと組み合わせるパイプラインを作れば、強力な自動化ステップが得られる。

      これを別個の検証ステップと組み合わせれば、LLMはおもちゃから有用なツールへ変わる。

    • 人間もその程度の反復工程に入っていないときに初めて自動化されたプロセスと言える。

  • ふつうはエージェントに、文書作成は最後の レンダリング段階 としてのみ扱うよう指示する。LLMは散在した知識を集めてつなぎ合わせるのが非常に得意なので、知識は組み合わせ可能なアイデアや事実の形で保存するほうを好む。

    実際にうまくいった方法は、エージェントにディレクトリを渡し、見つけた事実や発見ごとに独立したMarkdownファイルを作らせることだ。各ファイルには検索しやすいよう先頭メタデータを入れさせる。

    こうすると、作業の大半が「最終文書形式で調査と保存を繰り返す」という絡み合った形から、「文書に役立つ事実や発見を調査する」と「文書を組み立てる」という、より凝集した作業へ分離される。

    完全な解決策ではないが、人間が作業するときと同じように発見物の再利用性が高くなる。

  • これは人間にも当てはまるのでは？ 子どもたちが「伝言ゲーム」をしてメッセージがどう損なわれるかを見るのもそのためだ。解決策は 単一の信頼できる情報源 を提供することだ。

  • こうした種類の劣化と戦うためのツールを作っている: https://github.com/JigSpec/JigSpec

  • ここの評価方法は本当に気に入った。可逆的な段階の連鎖を往復させながら 忠実度 を試すやり方だ。

    見た目にはコンピュータが扱いやすそうな作業でも、最先端モデルがエラーを蓄積する点が印象的だった。

    Pythonでより強い結果が出たのが、Python特化評価の産物にすぎないのか、他の一般的な汎用言語にも当てはまるのか、そして学習過程の特定要素によるものなのかが気になる。

  • モデルが無数の小さなエラー、いわゆる「千の切り傷」で失敗しているわけではない点は、すでに大体わかっていた。あるラウンドではほぼ完璧に再構成するのに、いくつかのラウンドでは一度に10〜30点以上失う 致命的失敗 が起きる。

    弱いモデルの劣化は主に内容の削除から来ており、最先端モデルの劣化は内容の損傷から来ているという点も同じだ。だからこそ、私たちはハーネスや温度のようなものをあれこれ調整している。