LLMs beschädigen Dokumente, wenn man ihnen Aufgaben delegiert

 (arxiv.org)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • DELEGATE-52 ist ein Benchmark, der bewertet, wie originalgetreu Dokumente in delegierten Workflows erhalten bleiben, bei denen Nutzer einem LLM umfangreiche Dokumentenbearbeitungsaufgaben übertragen
  • Dieser Benchmark behandelt Aufgaben, die in 52 Fachbereichen tiefgehende Dokumentbearbeitung erfordern, darunter Coding, Crystallography und Musiknotation; die Beispielsimulation besteht aus der Delegation von 20 aufeinanderfolgenden Aufgaben
  • In Experimenten mit 19 LLMs beschädigen selbst Frontier-Modelle wie Gemini 3.1 Pro, Claude 4.6 Opus und GPT 5.4 am Ende langer Workflows im Durchschnitt 25% des Dokumentinhalts
  • Dokumentbeschädigung zeigt sich als seltene, aber schwerwiegende Fehler; die Verschlechterung nimmt mit Dokumentgröße, Interaktionslänge und einer größeren Zahl störender Dateien zu, und auch der Einsatz agentischer Tools verbessert die Leistung nicht
  • Aktuelle LLMs sind als verlässliche Stellvertreter für delegierte Dokumentbearbeitung kaum geeignet; microsoft/DELEGATE52 und datasets/microsoft/DELEGATE52 wurden als Materialien zu DELEGATE-52 veröffentlicht

Fehlermuster bei delegierter Bearbeitung

  • Delegierte Arbeit setzt Vertrauen voraus: Nutzer übertragen eine Aufgabe an ein LLM und gehen davon aus, dass es sie ausführt, ohne Fehler in das Dokument einzubringen
  • Groß angelegte Experimente mit 19 LLMs zeigen, dass aktuelle Modelle Dokumente im Delegationsprozess verschlechtern
  • Andere Modelle scheitern noch deutlich stärker als Frontier-Modelle
  • Dokumentbeschädigung akkumuliert sich über lange Interaktionen hinweg und ruiniert Dokumente schleichend

Als Beispiele gezeigte Dokumentveränderungen

  • Im Bereich Graph Diagrams wird das Dokument Linux Kernel Architecture bei Gemini 3.1 Pro im Vergleich zum Original nach 4 Durchläufen mit 79%, nach 10 mit 49%, nach 14 mit 48% und nach 20 mit 48% ausgewiesen
  • Im Bereich Textile Patterns wird das Dokument 12-Shaft Twill Diamond bei Claude 4.6 Opus im Vergleich zum Original nach 4 Durchläufen mit 100%, nach 10 mit 40%, nach 14 mit 27% und nach 20 mit 34% ausgewiesen
  • Im Bereich 3D Objects wird das Dokument ActionBoy Palm Tree bei GPT-5.2 im Vergleich zum Original nach 4 Durchläufen mit 100%, nach 10 mit 31%, nach 14 mit 15% und nach 20 mit 6% ausgewiesen

Veröffentlichtes Material

  • microsoft/DELEGATE52
  • datasets/microsoft/DELEGATE52

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Hacker-News-Kommentare

  • Beim Tool-Use bin ich skeptisch

    Es ist nicht überraschend, dass lange Inhalte beschädigt werden, wenn man sie mehrfach durch ein LLM hin- und herschickt. Wer LLMs häufig nutzt, weiß bereits, dass man das nicht tun sollte.

    Im Paper hat mich überrascht, dass Tool-Use nicht geholfen hat, gleichzeitig wird aber offengelegt, dass nur ein „grundlegendes Agent-Harness“ implementiert wurde und kein modernes, optimiertes System.

    Das tatsächliche Harness besteht nur aus read_file() und write_file(), also eher einfach ein zusätzlicher Schritt in der Roundtrip-Verarbeitung. Moderne Coding-Agent-Harnesses stecken viel Arbeit in das Design von Datei-Bearbeitungstools, zum Beispiel gibt es das Claude-Bündel an Editierwerkzeugen: https://platform.claude.com/docs/en/agents-and-tools/tool-us...

    Die Befehle str_replace und insert sind entscheidend, um riskante Bearbeitungen zu vermeiden, bei denen die gesamte Datei neu geschrieben wird.

    Immerhin wird ein run_python()-Tool bereitgestellt, daher ist es möglich, dass bessere Modelle damit String-Ersetzungen ausgeführt haben. Ich würde gern sehen, ob der System-Prompt zu Python-basierter Manipulation geraten hat oder eher dazu, Dateien zu lesen und erneut zu schreiben.

    Den Harness-Code findet man hier: https://github.com/microsoft/delegate52/blob/main/model_agen...

    Das relevante Prompt-Fragment besagt, man könne „sich auf die Weise nähern, die man für am effektivsten hält, ob programmatisch oder durch direktes Schreiben in Dateien“.

    Wie bei solchen Papers oft der Fall, spiegeln die Ergebnisse eher das Harness-Design der Autoren wider als das Modell selbst. Ob erfahrener AI Engineer oder Prompt Engineer: Ich denke, durch iterative Verbesserung des Harnesses selbst könnte man in diesem Test bessere Resultate erzielen.

    • Dem stimme ich größtenteils zu, mit Ausnahme von „Wer LLMs häufig nutzt, weiß bereits, dass man das nicht tun sollte“

      Gerade jetzt, wo die Einführung von LLMs in Organisationen und Teams breit vorangetrieben wird, gibt es viele Menschen, vielleicht sogar die Mehrheit, die täglich LLMs nutzen, aber noch nie Zugang zu etwas Technischem wie einem Harness hatten.

      Für diese Menschen ist das hier beschriebene Verhalten ein großes Problem.

    • Leicht verwandt, aber ich würde gern ein Harness sehen, das ed als Standard-Tool zum Bearbeiten/Lesen von Dateien verwendet. Die Hälfte des Bash, das Claude ausführt, sieht ohnehin wie sed aus; wenn ed zustandsbehaftet wäre, könnte das hilfreich sein.

      Was tun, wenn ein kompletter Editor zu viel Bandbreite^H Token frisst? Einfach den Standardeditor ed verwenden.

    • Das ist eher ein Fall, in dem LLM-Arbeit etwas als Strohmann dargestellt wird.

      Bei Bearbeitungsaufgaben sollten nur programmatische Editierbefehle erlaubt sein, und der Text selbst sollte nicht durch das LLM laufen. Das LLM sollte den Text analysieren und dann Befehle ausgeben, die entsprechend dem Feedback das Ziel erreichen.

    • Auf HN gibt es eine Tendenz, Ergebnisse möglichst negativ zu interpretieren, weil sie als Bedrohung für den eigenen Beruf und die eigene Identität empfunden werden.

      Tatsächlich könnte ein Mensch bei einer Bearbeitung, bei der er ein Dokument liest, Änderungen aufnimmt und dann das komplette Dokument erneut wiedergibt, sogar schlechter abschneiden als mit 25 % Degradation. Ein Mensch kann zwar auch 0 % Degradation erreichen, aber dafür müsste er das Dokument hunderte Male eingeben und auswendig lernen. Das LLM-Äquivalent dazu ist Training, und wenn man das Dokument in das LLM eintrainiert, kann es in diesem Fall einer Bearbeitung durch jemanden entsprechen, der es auswendig gelernt hat.

      Aber das ist nicht der Kernpunkt. LLMs ähneln Menschen in gewisser Hinsicht, also sollte man Harnesses so entwerfen, dass LLMs wie Menschen mit Suche und chirurgischen Änderungen editieren. Alle Coding-Agenten editieren so, deshalb ist dieses Paper nicht besonders relevant.

    • Ob wegen Ressourcenbeschränkungen oder zur Vereinfachung: Solche Papers verlieren leider durch schwer nachvollziehbare Methodik an Wert.

  • Wie ich schon lange sage: Wenn man irgendeinen Text mit AI überpinselt, sinkt die Qualität, und bei Wiederholung kumuliert sich das.

    Der Begriff dafür, der mir am besten gefällt, ist „semantic ablation“: https://www.theregister.com/software/2026/02/16/semantic-abl...

    • Ich nenne das seit jeher Regression zur durchschnittlichen Intelligenz.
    • Ich frage mich, ob „bei Wiederholung“ bedeutet, innerhalb derselben Session zu wiederholen, oder jedes Mal in einer neuen Session bzw. einem neuen Kontextfenster.

  • Der Kern ist: „Delegation erfordert Vertrauen. Man muss erwarten können, dass ein LLM keine Fehler in Dokumente einbringt und die Arbeit korrekt ausführt.“ Genau deshalb funktionieren Harnesses und Prompt-Rituale, die dutzende Markdown-Dateien schreiben, nicht so, wie sie beworben werden. Im Grunde ist das fast schon Pseudowissenschaft unter dem Namen Agent Engineering.

    Agent Engineering ist letztlich fast dasselbe wie sogenanntes Prompt Engineering, nur dass die Prompts jetzt über dutzende Markdown-Dateien und Verzeichnisse verstreut sind.

  • Das ist das am wenigsten überraschende, was ich in letzter Zeit über LLMs gelesen habe.

    LLMs sind ähnlich wie das JPEG-Meme. Jedes Mal, wenn man als JPEG speichert, sinkt die Qualität ein wenig, bis das Ergebnis am Ende nicht mehr erkennbar ist.

    Bei LLMs ist der Ausgangspunkt allerdings die Intention. Mit jedem Durchlauf durch ein LLM degradiert die Intention, und bei präzisen wissenschaftlichen Arbeiten gehen beim erneuten Formulieren nach und nach subtile Nuancen und Genauigkeit verloren.

    LLMs sind Maschinen zur Regression zum Mittelwert. Je weiter der aktuelle Kontext oder die aktuelle Arbeitslast außerhalb des Trainingsbereichs liegt, desto stärker neigen sie dazu, alles in einen homogeneren abstrakten Gleichgewichtszustand zu ziehen.

    • Beim Coden mit LLMs habe ich das definitiv erlebt. Nach einem schnellen Schub an Feature-Arbeit dachte ich, ich wäre ziemlich vorsichtig gewesen, und wenn ich mir später kleine Code-Stellen im Detail ansehe, denke ich oft: „Mein Gott“.

      Danach muss ich stundenlang noch einmal alles durchgehen und sorgfältig korrigieren, was nicht so geworden ist, wie ich wollte, wo ich unklar war oder wo seltsame LLM-Gewohnheiten durchgeschlagen haben.

      Codequalität an sich ist wichtig, aber genau dieses Problem der iterativen Kompression macht mir Sorgen. Wenn die Codebasis sauber ist und mein mentales Modell aktuell, kann das LLM bei Feature-Arbeit schnell helfen und die Codebasis trotzdem in einem brauchbaren Zustand hinterlassen. Aber sobald das LLM anfängt, die Codebasis zu verschmutzen, sammeln sich alte Fehler oder Missverständnisse an, und es wird immer wahrscheinlicher, dass noch mehr schiefgeht. Deshalb fühle ich mich erst sicher, wenn ich sie vor dem nächsten Einsatz des LLM wieder in den richtigen Zustand „zurückgesetzt“ habe.

    • Wirklich interessant und relevant wird dieses Ergebnis dann, wenn Coding-Agenten große Quelldateien in viele kleinere Dateien aufteilen. Opus und Claude Code verwenden dann nicht Operationen wie Copy/Paste, wie ein Mensch es tun würde, sondern versuchen, lange Quellcodeabschnitte aus dem Gedächtnis zu rezitieren und in neue Dateien zu schreiben.

      Dateien zu verschieben ist etwas einfacher. LLMs versuchen gelegentlich trotzdem, Dateien aus dem Gedächtnis neu wiederzugeben, aber wenn man git mv verwendet und anschließend Compilerfehler beheben lässt, klappt das meistens gut.

      Normale Bearbeitungen funktionieren dagegen mit einem vernünftigen Modell und einer vernünftigen Tool-Konfiguration in der Regel gut. Selbst Qwen3.6 27B schafft das ordentlich. Änderungen direkt an Ort und Stelle kann man außerdem mit git diff auf unerwartete Änderungen prüfen.

    • Dafür gibt es sogar ein Kinderspiel: https://en.wikipedia.org/wiki/Telephone_game

    • Ein Kollege nennt LLMs die „Bullshit-Schicht“. Das ist nicht komplett abwertend gemeint, sondern soll betonen, dass das Ergebnis auf der anderen Seite jedes Mal anders sein kann, als man es erwartet oder will, wenn man etwas durch ein LLM schickt.

      Es ist ein bisschen so, als würde dir jemand in einer Bar nach ein paar Drinks Informationen aus dem Internet weitererzählen, die er irgendwo gelesen hat. Es könnte stimmen, aber das Risiko, dass es nicht stimmt, ist ziemlich hoch.

      Zum Beispiel sollte man kein LLM verwenden, um per API Daten zu sammeln und daraus Berichte zu erstellen. Dann schickt man kritische Daten durch die Bullshit-Schicht und kann dem Ergebnis nicht vertrauen. Besser ist es, das LLM dazu zu nutzen, Code zu schreiben, der aus kritischen Daten kritische Ausgaben erzeugt.

      Ich habe auch schon erlebt, wie Kollegen kritische Daten aus APIs von einem LLM zusammenfassen ließen und Berichte bekamen, die ebenso oft komplett danebenlagen wie richtig waren. Je nachdem, was man betrachtet, kann das katastrophale Risiken bergen.

    • Das habe ich bei der Bearbeitung meines Lebenslaufs erlebt. Das LLM entfernt alle Elemente aus meinem Lebenslauf, die mich von der Masse durchschnittlicher Junior Engineers mit durchschnittlicher Erfahrung unterscheiden. Alles Besondere, Einzigartige oder Abweichende wird am Ende durch generische Formulierungen ersetzt.

      Ich habe das Ergebnis natürlich nicht verwendet, aber es war extrem frustrierend, dass das LLM immer wieder behauptete, es sei besser als das Original.

      Viel nützlicher war das LLM bei sehr kleinen Einheiten, etwa bei Änderungsvorschlägen für einen einzelnen Satz oder vielleicht drei Sätze.

  • Das Problem ist, dass wir LLMs zu viel Arbeit geben. Agenten sollten so entworfen werden, dass sie LLMs als möglichst dünne Schicht verwenden, um natürlichsprachliche Intention in einen deterministischen Prozess zu übersetzen, und die Zahl der LLM-Roundtrips so gering wie möglich halten.

    • Wer versucht, auch nur etwas Komplexeres zu tun, merkt schnell, dass das stimmt. Wenn man eine Pipeline baut, die Vorverarbeitungsflüsse, semantische Zielauswahl und minimale Kontextaufrufe mit der LLM-API kombiniert, erhält man eine leistungsfähige Automatisierungsstufe.

      In Kombination mit separaten Validierungsschritten wird aus dem LLM ein nützliches Werkzeug statt eines Spielzeugs.

    • Es ist überhaupt erst dann ein automatisierter Prozess, wenn kein Mensch mehr in so einer iterativen Schleife steckt.

  • Ich weise Agenten normalerweise an, Dokumentenerstellung nur als letzten Rendering-Schritt zu behandeln. LLMs sind sehr gut darin, verstreutes Wissen zusammenzutragen und zu verweben, daher speichere ich Wissen lieber in Form kombinierbarer Ideen und Fakten.

    Was sich in der Praxis gut bewährt hat, ist, dem Agenten ein Verzeichnis zu geben und ihn für jede gefundene Tatsache oder Entdeckung eine eigenständige Markdown-Datei anlegen zu lassen. Jede Datei bekommt vorne Metadaten, damit sie leicht durchsuchbar ist.

    So wird der Großteil der Arbeit von einem verhedderten „Recherche und Speicherung im finalen Dokumentformat“ getrennt in die kohärenteren Aufgaben „Tatsachen und Erkenntnisse recherchieren, die dem Dokument helfen“ und „das Dokument zusammenbauen“.

    Das ist keine vollständige Lösung, aber wie bei menschlicher Arbeit verbessert es die Wiederverwendbarkeit der Erkenntnisse.

  • Gilt das nicht auch für Menschen? Deshalb sieht man bei Kindern im „Stille-Post“-Spiel ja, wie Nachrichten beschädigt werden. Die Lösung ist, eine einzige Quelle der Wahrheit bereitzustellen.

  • Ich entwickle Tools, um genau gegen diese Art von Degradation anzukämpfen: https://github.com/JigSpec/JigSpec

  • Die Evaluationsmethode hier hat mir wirklich gefallen. Getestet wird die Treue, indem man eine Kette reversibler Schritte hin- und zurücklaufen lässt.

    Beeindruckend fand ich, dass selbst Frontier-Modelle Fehler akkumulieren, obwohl die Aufgabe oberflächlich wie etwas wirkt, das Computer leicht handhaben sollten.

    Ich frage mich, ob die stärkeren Ergebnisse in Python nur ein Artefakt einer Python-spezifischen Evaluation sind oder ob sich das auch auf andere gängige General-Purpose-Sprachen überträgt, und ob das an bestimmten Aspekten des Trainingsprozesses liegt.

  • Dass Modelle nicht vor allem an unzähligen kleinen Fehlern, also an „tausend Schnitten“, scheitern, wussten wir im Grunde schon. In manchen Runden rekonstruieren sie fast perfekt, dann gibt es einzelne Runden mit katastrophalem Versagen, in denen sie auf einmal 10 bis 30 Punkte oder mehr verlieren.

    Ebenso gilt: Die Degradation schwächerer Modelle kommt vor allem durch das Löschen von Inhalten, während die Degradation von Frontier-Modellen eher durch Inhaltsverfälschung entsteht. Deshalb drehen wir ja ständig an Dingen wie Harness und Temperatur.