Long-Transduction: Ein kontrolliertes Diagnoseverfahren zur Messung von Abweichungen in KI-Agenten bei langfristigen Aufgaben

Das Zuverlässigkeitsproblem in agentischen Workflows

Langfristige agentische Workflows erfordern, dass Sprachmodelle wiederholte, zustandsabhängige Aktionen aufrechterhalten. Während der Kontext wächst, sich die Komplexität der Teilaufgaben ändert und neue Daten eintreffen, stellt jede dieser Situationen eine unabhängige Achse dar, entlang derer ein Agent versagen kann.

Ein illustratives Beispiel ist ein Agent, der ein langes Hauptbuch abgleicht: Er muss seinen Zustand wiederholt lesen, den richtigen Eintrag aktualisieren und die Ausrichtung über Tausende von Ausgaben hinweg beibehalten. Ein Modell kann das gesamte Hauptbuch akzeptieren, aber seinen Platz verlieren oder die Operation nicht mehr konsistent anwenden, je weiter die Generierung fortschreitet.

Der Begriff «zustandsabhängig» beschreibt hier eine Aufgabe, bei der die nächste Aktion davon abhängt, was zuvor im System geschehen ist. Der Agent muss also nicht nur eine einzelne Eingabe verarbeiten, sondern den aktuellen Stand wiederholt berücksichtigen und die jeweils passende Operation darauf anwenden. Gerade diese Wiederholung macht den Ablauf anfällig: Eine zunächst kleine Abweichung kann sich in späteren Schritten fortsetzen, wenn der Agent den Zustand nicht mehr korrekt erfasst oder eine bereits festgelegte Operation anders ausführt.

Die drei genannten Belastungen sind voneinander zu unterscheiden. Ein wachsender Kontext bedeutet, dass mehr Informationen über den bisherigen Ablauf berücksichtigt werden müssen; veränderte Teilaufgaben stellen andere unmittelbare Anforderungen; neue Daten können wiederum den Zustand verändern, auf den sich die nächste Aktion bezieht. Der Text behandelt diese Faktoren als eigenständige mögliche Fehlerquellen. Daraus folgt nicht, dass sie in jeder konkreten Aufgabe gleich stark wirken oder zwangsläufig gemeinsam auftreten.

Beim Beispiel mit dem Hauptbuch liegt die Schwierigkeit nicht allein darin, das Dokument aufzunehmen. Der Agent muss während der fortlaufenden Ausgabe die aktuelle Position und den jeweils zu bearbeitenden Eintrag im Blick behalten. Dass ein Modell den gesamten Inhalt akzeptiert, belegt deshalb noch nicht, dass es über viele aufeinanderfolgende Schritte hinweg dieselbe Operation zuverlässig auf den richtigen Datensatz anwendet. Das Beispiel veranschaulicht eine mögliche Form der Aufgabenabweichung; es ist für sich genommen kein Nachweis über die Leistung eines bestimmten Modells.

Aufbau von Long-Transduction: Kontrollierte Variablen

Long-Transduction ist ein kontrolliertes Diagnoseverfahren, das die Fähigkeit eines Modells testet, bei einer langen Generierung bei der Aufgabe zu bleiben. Der Test umfasst das kontinuierliche Lesen, Ändern und Ausgeben von Operationen, die vom Eingabekontext abhängen, wie Arithmetik, Sortierung, Variablenabfragen und Tabellentransformationen.

Die Bewertung variiert drei Schlüsselvariablen unabhängig voneinander: die lokale Aufgabenkomplexität, das Format der Eingabedaten und die Kontextlänge. Dieses Design ermöglicht es, Fehler entlang jeder Achse separat zu isolieren, anstatt eine diffuse globale Leistung zu messen.

Long-Transduction ist darauf angelegt, die Ausführung einer Aufgabe unter kontrolliert veränderten Bedingungen zu prüfen. Im Mittelpunkt steht nicht nur, ob ein Modell eine einzelne Operation beantworten kann, sondern ob es während einer längeren Folge von Ausgaben die Verbindung zwischen Eingabekontext, aktuellem Zustand und nächstem Arbeitsschritt beibehält. Die genannten Operationen reichen von arithmetischen Aufgaben und Sortierung bis zu Variablenabfragen und Tabellenumwandlungen; gemeinsam ist ihnen, dass ihre Ausführung von den vorliegenden Eingaben abhängt.

Die unabhängige Variation der drei Dimensionen soll die Interpretation eines beobachteten Fehlers erleichtern. Wird jeweils eine Variable verändert, lässt sich untersuchen, ob eine Verschlechterung mit der Kontextlänge, der Darstellung der Eingabe oder dem Schwierigkeitsgrad der lokalen Teilaufgabe zusammenhängt. Das ist eine Eigenschaft des Testdesigns, keine Garantie dafür, dass sich sämtliche Wechselwirkungen zwischen diesen Dimensionen ausschließen lassen oder dass ein isolierter Befund unverändert auf andere Aufgaben übertragbar ist.

Bei der Kontextlänge wird der betrachtete Bereich von 4K bis 128K Tokens skaliert. Die Variation des Eingabeformats betrifft die Struktur, in der Daten präsentiert werden; die lokale Komplexität betrifft die Schwierigkeit der unmittelbar auszuführenden Teilaufgabe. Diese Unterscheidung ist wichtig, weil eine fehlerhafte Ausgabe unterschiedliche Ursachen haben kann: Die Information kann im längeren Kontext schwerer zu verfolgen sein, ihre veränderte Darstellung kann die Verarbeitung erschweren oder der einzelne Arbeitsschritt kann anspruchsvoller werden. Die Tabelle benennt diese Diagnoseziele, ersetzt jedoch keine detaillierte Beschreibung der konkreten Messprotokolle.

Ergebnisse bei sieben Open-Weight-Modellen

Die Autoren bewerteten sieben Open-Weight-Modelle mit diesem Diagnoseframework. Die Ergebnisse zeigen einen Rückgang der Leistung um 62,8 % bei der Skalierung der Kontextlänge von 4K auf 128K Tokens. Diese Zahl deutet darauf hin, dass die bloße Akkumulation von Kontext ein kritischer Degradationsfaktor ist.

Darüber hinaus wurde ein Rückgang von 36,5 % bei der Variation des Eingabeformats und ein Abfall von 39,9 % bei der Erhöhung der lokalen Aufgabenkomplexität beobachtet. Zusammen stellen diese Fehler kritische Verbindlichkeiten in langfristigen agentischen Workflows dar und zeigen, dass Zuverlässigkeit nicht linear mit der Modellgröße oder der Fensterlänge skaliert.

Die berichteten Prozentwerte beschreiben Veränderungen der Leistung unter den jeweils genannten Testbedingungen: eine Abnahme um 62,8 Prozent bei der Skalierung des Kontexts von 4K auf 128K Tokens, um 36,5 Prozent bei verändertem Eingabeformat und um 39,9 Prozent bei erhöhter lokaler Aufgabenkomplexität. Sie belegen, dass die Autoren in ihrer Bewertung deutliche Einbußen entlang aller drei untersuchten Dimensionen berichten. Ohne zusätzliche Angaben zur genauen Metrik lässt sich daraus jedoch nicht sicher ableiten, wie sich jede Veränderung auf eine bestimmte Erfolgswahrscheinlichkeit oder auf eine konkrete Einsatzaufgabe übertragen würde.

Insbesondere ist eine prozentuale Abnahme der Leistung nicht automatisch mit einer gleich großen Abnahme der Genauigkeit in Prozentpunkten gleichzusetzen. Das Beispiel mit einer Ausgangsgenauigkeit von 90 Prozent ist daher als Illustration der möglichen Größenordnung gedacht, nicht als aus den berichteten Ergebnissen berechneter Messwert für ein bestimmtes Modell. Die tatsächliche Genauigkeit bei 128K Tokens kann aus dieser Beispielrechnung allein nicht bestimmt werden; dafür wären die verwendete Leistungsmetrik und die konkreten Ausgangs- und Endwerte erforderlich.

Die drei Einbußen sollten außerdem nicht zu einer einzigen Gesamtzahl addiert oder als voneinander unabhängige Risiken für jede reale Aufgabe behandelt werden. Die Abschnitte beschreiben getrennte Variationen in einem Diagnoseframework. Sie zeigen damit, an welchen Stellen die geprüften Modelle empfindlich reagierten, legen aber nicht fest, wie sich diese Effekte bei gleichzeitig verändertem Kontext, Format und Aufgabenkomplexität zueinander verhalten. Auch die berichtete Bewertung von sieben Open-Weight-Modellen erlaubt ohne nähere Angaben zu Modellauswahl, Einzelresultaten und Messverfahren keine weitergehende Verallgemeinerung auf alle Modelle dieser Art.

Die Aussage, Zuverlässigkeit skaliere nicht linear mit Modellgröße oder Kontextfenster, ist im vorliegenden Text als Schlussfolgerung aus den berichteten Ergebnissen formuliert. Die genannten Prozentwerte beziehen sich auf Veränderungen der Testbedingungen; sie liefern für sich genommen keinen direkten Vergleich zwischen Modellgrößen und belegen keine allgemeingültige Skalierungskurve. Entsprechend sollte die Schlussfolgerung als Hinweis auf mögliche Grenzen verstanden werden, nicht als vollständige quantitative Regel für die Leistung anderer Modelle.

Unterschied zwischen Diagnose und Produktionsdemonstration

Es ist entscheidend, dieses kontrollierte Diagnoseverfahren von einer Leistungsdemonstration in Produktionsumgebungen zu unterscheiden. Long-Transduction isoliert Variablen, um die Mechanik des Fehlers zu verstehen, simuliert aber nicht die vollständige Interaktion mit externen Werkzeugen, dynamischen Datenbanken oder menschlichen Nutzern.

Die Ergebnisse garantieren nicht, dass ein Modell, das in diesem Test versagt, auch in einer realen Anwendung versagt, noch dass eines, das den Test besteht, in der Produktion zuverlässig ist. Der Test ist ein Ingenieurswerkzeug zur Identifizierung spezifischer Schwachstellen, keine Zertifizierung der Eignung für den Einsatz.

Der diagnostische Charakter des Verfahrens begrenzt, was aus einem Ergebnis geschlossen werden kann. Eine kontrollierte Aufgabe kann sichtbar machen, ob ein Modell bei längerer Generierung, anderer Datendarstellung oder anspruchsvolleren Teilaufgaben an Leistung verliert. Sie bildet aber nicht automatisch sämtliche Bedingungen ab, unter denen ein Agent mit externen Werkzeugen, einer dynamischen Datenbank oder einem Menschen interagiert. Diese Umgebungen gehören ausdrücklich nicht zur vollständigen Simulation, die der Test beansprucht.

Daraus ergeben sich zwei getrennte Grenzen der Interpretation. Ein Fehler im Test beweist nicht, dass dasselbe Modell in jeder realen Anwendung scheitern wird; umgekehrt belegt ein gutes Testergebnis nicht, dass es im Einsatz zuverlässig bleibt. Der Test kann somit spezifische Schwachstellen auffindbar machen, aber weder ein allgemeines Urteil über die Eignung für den Einsatz noch eine Garantie für den Umgang mit nicht geprüften Bedingungen liefern.

Der beschriebene Ablauf beginnt mit der Festlegung einer zustandsabhängigen Operation, etwa einer kumulativen Summe. Anschließend werden Eingaben mit unterschiedlichen Kontextlängen erstellt; das Datenformat wird unter Beibehaltung der Semantik verändert, und auch die Schwierigkeit der lokalen Teilaufgabe wird angepasst. Gemessen wird die Fehlerrate für die jeweiligen Kombinationen. Entscheidend für die Aussagekraft ist, dass die Semantik beim Formatwechsel erhalten bleibt: Andernfalls könnte eine Leistungsänderung nicht eindeutig der Präsentationsform zugeschrieben werden, sondern auch auf eine veränderte Aufgabe zurückgehen.

Einschränkungen und Anforderungen für die Generalisierung

Der Preprint, veröffentlicht auf arXiv, listet in der Zusammenfassung keine spezifischen Erfolgsmetriken, vergleichenden Baselines oder die Verfügbarkeit von Code und Daten für die Replikation auf. Eine vollständige Verifizierung erfordert den Zugriff auf den Volltext des Dokuments, um die detaillierte Methodik zu bewerten.

Um die Generalisierbarkeit dieser Erkenntnisse zu bewerten, wären Ausführungsprotokolle, der Testcode und eine Validierung in Agenten mit Werkzeugen erforderlich. Die Autoren erkennen implizit an, dass diese Fehler kritisch sind, aber die Erweiterung auf reale Umgebungen mit komplexen Werkzeugen bleibt eine Hypothese, die auf empirische Verifizierung wartet.

Die im Text genannten offenen Punkte begrenzen die Nachprüfbarkeit der berichteten Resultate. In der Zusammenfassung werden keine konkreten Erfolgsmetriken oder vergleichenden Baselines spezifiziert; außerdem ist die Verfügbarkeit von Code und Daten für eine unabhängige Wiederholung nicht bestätigt. Ohne diese Informationen lässt sich nicht im Detail beurteilen, wie «bei der Aufgabe bleiben» operationalisiert wurde und ob unterschiedliche Arten von Fehlern getrennt erfasst wurden. Die Prozentangaben sind daher als berichtete Ergebnisse des Preprints zu behandeln, nicht als vollständig unabhängig überprüfte Messwerte.

Für eine Prüfung der Generalisierbarkeit wären neben dem vollständigen methodischen Text auch Ausführungsprotokolle und der Testcode relevant. Damit ließe sich nachvollziehen, welche Eingaben und Operationen verwendet, wie Fehler gezählt und welche konkreten Bedingungen miteinander verglichen wurden. Eine Validierung in Agenten mit Werkzeugen wäre zusätzlich nötig, um zu untersuchen, ob die in der kontrollierten Diagnose beobachteten Schwachstellen in solchen Abläufen ebenfalls auftreten. Der Text beschreibt diesen Schritt als erforderliche Prüfung, nicht als bereits vorliegendes Ergebnis.

Die Übertragung auf Umgebungen mit komplexen Werkzeugen bleibt ausdrücklich offen. Die im Diagnoseverfahren beobachteten Fehler können Anlass sein, diese Übertragung empirisch zu untersuchen; sie bestätigen sie jedoch nicht. Solange weder die erforderlichen Replikationsmaterialien noch eine solche Validierung bestätigt sind, ist es angemessen, die Befunde auf die beschriebenen Testbedingungen zu beziehen und weitergehende Aussagen über reale agentische Abläufe als ungeprüft zu kennzeichnen.

Der angegebene arXiv-Preprint ist die Grundlage für die im Text wiedergegebenen Prozentwerte. Eine Begutachtung durch Fachkollegen oder eine unabhängige Replikation ist nicht bestätigt. Diese Einschränkung macht die Ergebnisse nicht bedeutungslos, begrenzt aber ihren Status: Sie liefern einen berichteten diagnostischen Befund, dessen genaue Messgrundlage und Übertragbarkeit anhand der detaillierten Methodik und zusätzlicher unabhängiger Prüfungen beurteilt werden müssten.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.