ハクソク

世界を動かす技術を、日本語で。

LLMに委任すると文書が破損する

11時間前原文(arxiv.org)

概要

  • Large Language Models（LLMs） による知識労働の変革可能性
  • 委任作業 における信頼性の重要性
  • DELEGATE-52 ベンチマークによるLLMの性能評価
  • 長期作業での 文書劣化 の深刻さ
  • 現行LLMの 信頼性課題 の明確化

LLMによる委任作業と信頼性の課題

  • LLMs は知識労働を変革する可能性を持つAI技術
  • 委任作業（delegated work） は、LLMに業務を任せる新たなインタラクションパラダイム
  • 委任には、 LLMがタスクを正確に実行し、文書に誤りを持ち込まない という信頼が不可欠
  • DELEGATE-52 は52の専門分野（プログラミング、結晶学、音楽記譜など）にわたる長期文書編集タスクをシミュレートするベンチマーク
  • 19種類のLLMを用いた大規模実験を実施

DELEGATE-52ベンチマークの主な発見

  • 最先端モデル（ Gemini 3.1 Pro, Claude 4.6 Opus, GPT 5.4）でも、長期作業の末に 平均25%の文書内容が破損
  • 他のモデルではさらに深刻な劣化が観察
  • エージェント的ツール利用 （agentic tool use）はDELEGATE-52の性能向上に寄与せず
  • 文書サイズ、 インタラクションの長さ、 気を散らすファイルの存在 が劣化の深刻化要因
  • LLMは まばらだが重大な誤り を静かに文書へ導入し、やがて累積的な破損につながる

現行LLMの限界と今後の課題

  • 現在のLLMは 信頼できる代理人 としては不十分
  • 長期的な作業や複雑な文書編集では 重大なエラー が発生しやすい
  • 人間とAIの協働 における品質保証や監督の重要性
  • 今後は エラー検出・修正能力 や 信頼性向上 への技術開発が求められる

Hackerたちの意見

ここの評価方法がすごく良かった。可逆的なステップのチェーンを通じてテストすることで、忠実度を測るって感じ。最先端のモデルでも、コンピュータに優しいタスクでエラーが蓄積されるのが印象的だった。Pythonでの結果がPython特有の評価の影響だけじゃなくて、他の一般的なプログラミング言語にも適用できるのか、またトレーニングプロセスの何か特別な要因が関係しているのか、知りたいな。

うん、前から言ってるけど、AIでテキストを加工すると、どんどん劣化していくよね。毎回やるごとにどんどんひどくなる。「意味の切除」っていうのが俺のお気に入りの表現なんだ： https://www.theregister.com/software/2026/02/16/semantic-abl...

└

「毎回やるごとに」って、同じセッション内のことを言ってるの？それとも毎回新しいセッション（コンテキストウィンドウ）でのこと？

└

俺はそれを「ミーンウィットの逆戻り」って呼んでる。

最近読んだLLMに関する中で、一番衝撃が少なかったことだね。要するに、JPEGのあのミームみたいなもので、JPEGとして保存するたびに少しずつ品質が劣化して、最後には全然わからなくなるって感じ。ただLLMの場合、出発点は意図なんだ。LLMが一回通るたびに意図が劣化していく。例えば、正確な科学論文の場合、ちょっとしたニュアンスや精度が言い換えのたびに失われていく。LLMはミーンリバージョンの機械で、トレーニングから「外れた」コンテキストや作業負荷に対しては、どんどん均質な抽象的な平衡に引き寄せられる傾向があるんだ。

└

同僚がLLMを「クソ」レイヤーって言ってた。完全に否定してるわけじゃないけど、LLMに何かを通すたびに出てくるものが期待したり欲しいものとは限らないって強調してた。まるでパブで数杯飲んだ後に、どこかで見たことを話してる人みたいな感じ。正確なこともあるけど、そうじゃないリスクもかなりある。だから、例えば、LLMを使ってAPIからデータを集めてレポートを作るのはやめた方がいい。決定論的なデータを「クソ」レイヤーに通すことになるから、出てくるものを信頼できなくなる。むしろ、LLMを使って決定論的なデータから決定論的な出力を生成するコードを書く手助けをさせる方がいいよ。共働者がLLMを使ってAPIからの決定論的なデータを要約してるのを見たけど、正確なこともあれば、全然外れてることもあった。見てるものによっては、致命的なリスクがあるかもしれないね。

└

LLMがやったのと同じタスクを人間がやると、文書がさらに劣化するってことだよ。LLMが25%劣化するなら、人間は同じ手法を使ったら80%ぐらい劣化すると思う。単一のパスの話ね。実際のところ、人間は論文のように編集しないし、Claudeみたいなコーディングエージェントも同じ。考えてみて：論文全体を取り込んで、一回のターゲット編集でその論文を吐き出すなんてことはしないよね…コーディングエージェントも同じ。あと、よく考えてみて。25%の劣化率は業界では受け入れられない。ソフトウェア開発を支配しているAIの変化は、もし25%の劣化があったら実際には存在しないよ…それは多すぎる。

└

この結果が本当に面白くて関連性があるのは、コーディングエージェントが大きなソースファイルを複数の小さなファイルに分割する時だね。Opus + Claude Codeは、人間がやるようなコピー＆ペースト操作ではなく、長いソースコードのセクションを記憶から各新しいファイルに再現しようとする。ファイルを移動するのはちょっと簡単だね。LLMは時々ファイルを記憶から再現しようとするけど、「git mv」を使ってコンパイラエラーを直すように指示すれば、ほとんどの場合うまくいくよ。普通の編集は、合理的なモデルやツールのセットアップで一般的にうまくいく。Qwen3.6 27Bでも大丈夫だし、インプレース編集の場合は「git diff」を見てサプライズを確認できるよ。

└

これを示す子供のゲームもあるよね： https://en.wikipedia.org/wiki/Telephone_game

└

LLMは人類が作った最も精巧な推測マシンだよ。それが使う目的によって、役に立つこともあれば無駄になることもある。それだけのこと。すべてをこのレンズで見ると、すべてが理解できる - 特に推論や創造性の根底にある理解がないってことがね。ブースターが何を言おうと、気にしないよ。

└

昨日、スレッドでこのことについて話してたんだ。だから、LLM生成だけのブログは好きじゃない。どんなに良いと思っても、あなたが自分のコピーのようなものを良いと考えても、私は気にしない。もし退屈なLLMの返答が欲しいなら、自分でプロンプトを出すよ。人間が生成したコンテンツだと思って読んでるブログを読んで、誰かにプロンプトの結果を読ませようとされるのは、うんざりだ。あなたのブログを読みに来たのに、あなたが書くつもりもないなら、なんでブログを書いてるの？

└

LLMを使ってコーディングしていると、これを実感することがある。結構注意して速く進めているつもりでも、後で小さなコードの一部をじっくり見て「うわ、やばい」と思うことがある。そしたら、数時間かけて全体を見直して、思った通りにいかなかった部分や、曖昧だったところ、LLMの「脳の虫」が出てきたところを丁寧に修正しなきゃいけない。品質は自分にとってすごく大事なんだけど、正確に言うとこの「繰り返し圧縮」の問題が心配なんだ。コードベースがきれいで、最新のメンタルモデルがあれば、LLMはすぐに機能を作る手助けをしてくれるけど、LLMがコードベースを汚していくと、過去のミスや誤解が重なって、どんどん失敗する可能性が高くなる。だから、またLLMを使う前に、正しい状態に「復元」しなきゃ安心できないんだよね。

└

さらに、意図をある種の順序付けられた状態と考え、時間が経つにつれてLLMがエントロピーを導入し、最終的に自由連想に似たものになると考えることはできるだろうか？

ツールの使用に関する彼らの結果には疑問を持ってる。長いコンテンツをLLMで往復させると、劣化するのは当然だよね。頻繁にLLMを使ってる人は、そんなことしないって知ってるし。彼らはツールの使用が役立たなかったって言ってて驚いたけど…でも彼らはこうも言ってる：> 「これをテストするために、ファイルの読み書きやコード実行ツールを持つ基本的なエージェントハーネス（Yao et al., 2022）を実装しました（付録M）。これは最適化された最先端のエージェントシステムではありません。将来の研究では、より洗練されたハーネスを探ることができるでしょう。」そう、彼らの基本的なハーネスはread_file()とwrite_file()だけで、結局は一手間加えた往復に過ぎない！現代のコーディングエージェントハーネスは、ファイル編集のためのツールのデザインにかなりの労力をかけてる。今のお気に入りの例は、ここで説明されている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エンジニアやプロンプトエンジニアがこのテストでハーネス自体を改良すれば、もっと良い結果が得られる自信があるよ。

└

人々は結果をできるだけネガティブに解釈したがるのは、自分の職業やアイデンティティに対する脅威だから。特にHNのことを言ってる。実際のところ、ドキュメントを読んでからその内容を再現する形で編集したいなら…人間は25%の劣化よりも悪くなるよ。人間が0%の劣化を達成することは可能だけど、そのためには何百回もドキュメントを読み込む必要があって、それを「記憶」と呼ぶ。LLMでの同等のプロセスはトレーニングと呼ばれる。ドキュメントをLLMにトレーニングすれば、記憶した人間の編集と同等の結果が得られるんだ。でも、上記は関係ない。要するに、LLMには人間と似た部分がある。LLMが人間と同じようにドキュメントを編集するためには、ハーネスを設計する必要がある：検索して外科的に編集すること。すべてのコーディングエージェントはこの方法で編集するから、この論文はあまり関係ないね。

└

リソースの制約や単純にするための方法論が理解できないせいで、残念ながらこれらの論文は価値がない。

「モデルは『千の傷による死』が原因で失敗しているわけではない（つまり、多くの小さなエラー）。代わりに、いくつかのラウンドではほぼ完璧な再構築を維持し、数回のラウンドで重大な失敗を経験し、通常は1回の往復で10〜30ポイントを失う。」 > 「弱いモデルの劣化は主にコンテンツの削除に起因し、最先端モデルの劣化はコンテンツの破損に起因する。」これ、ほとんどみんな知ってたことだと思う。だからこそ、ハーネスや温度なんかで調整してるんだよね。

問題は、LLMにやりすぎの仕事をさせてることだと思う。LLMをできるだけ薄いレイヤーとして使って、自然言語の意図を決定論的なプロセスに変換するエージェントを設計することを目指すべきだね。LLMへの往復をできるだけ最小限に抑えるように。

LLMの編集は決定論的な出力を生み出すために行うべきだね。つまり、LLMはdiffを生成し、ユーザーはそのdiffを受け入れるべき。長い文書を編集する時に、そのような可視性なしにLLMに編集を頼むのは悪いパターンだと思う。文章もコードも同じだよ。

LLMの面白いところは、彼らの失敗が人間の失敗とすごく似ていることだと思う。これが「何を意味するのか」はよくわからないけど、理論的にはLLMの失敗を修正できるのに、人間の場合はずっと難しいってのが興味深い。人を教育したり洗脳したりするには、一生かかるし、それでもややこしくて予測不可能で失敗しやすい—LLMと同じようにね。

普段、エージェントには文書作成は最後の「レンダリング」段階として扱うように言ってる。LLMは散発的な知識をまとめるのが得意だから、知識は組み合わせ可能なアイデアや事実として保存するのが好きなんだ。実際にうまくいっているのは、エージェントにディレクトリを与えて、見つけた事実や発見のために独立したマークダウンファイルを作るように指示すること。各ファイルには検索しやすいようにフロントマターをつける。これで「研究して最終文書形式で逐次保存する」というタスクを「文書に役立つかもしれない事実や発見を研究する」と「文書を組み立てる」というより一貫したタスクに分けられる。部分的な緩和策だけど、これで人間が作業しているかのように、発見をより柔軟に再利用できると思う。

あなたの文脈がいつも短いことを願っています。