DeReAct: Was nötig ist, um die Ergebnisse und den Kontrollansatz zu bestätigen

Der Vorschlag ist noch kein bestätigtes Ergebnis

DeReAct wird in diesem Artikelvorschlag als Entwurf vorgestellt, der zwei Entscheidungen bei einem KI-Agenten voneinander trennen soll: ob eine Aktion über ein Werkzeug zulässig ist und ob eine Aufgabe bereits als abgeschlossen gelten kann. Der Ansatz ist relevant, weil ein Agent mehr tun kann, als eine Antwort zu formulieren: Er kann Werkzeuge aufrufen, Informationen verändern oder Vorgänge anstoßen. Mit den verfügbaren verifizierten Quellen lässt sich jedoch weder bestätigen, dass ein DeReAct-Forschungspapier mit den beschriebenen Einzelheiten existiert, noch lassen sich Methode oder Ergebnisse überprüfen.

Diese Einschränkung betrifft den Kern der Meldung. Es liegen hier keine überprüfbaren Primärbelege vor, anhand derer sich Pass@1-Werte, untersuchte Varianten, Baselines, Versuchsspuren oder die Verfügbarkeit von Code und Prompts kontrollieren ließen. Die behaupteten Verbesserungen auf GAIA und SWE-bench Verified dürfen deshalb nicht als nachgewiesene Ergebnisse dargestellt werden. Ebenso wenig lassen sich dem System konkrete Kennzahlen, Entscheidungsmechanismen oder Garantien für den praktischen Einsatz zuschreiben.

Allgemeiner Kontext hilft dennoch, das Designproblem zu erklären. ReAct wird als Ansatz beschrieben, der Schlussfolgerungen mit Aktionen verbindet, darunter auch Aktionen über Werkzeuge. Dieser Rahmen macht nachvollziehbar, weshalb Aktionsplanung und Ausführung in einem gemeinsamen Ablauf zusammenhängen können. Er belegt jedoch weder die Existenz von DeReAct noch, dass der Ansatz die Grenzen dieses Vorgehens überwindet.

Welche Aufgaben die Architektur trennen soll

Die Beschreibung des Vorschlags weist zwei unterschiedlichen Komponenten jeweils eine Funktion zu. Der Critic soll entscheiden, ob eine vom Agenten beabsichtigte Aktion ausgeführt werden darf. Der Context Manager soll Informationen über den Aufgabenstatus zusammentragen und feststellen, ob genügend Belege vorliegen, um den Abschluss zu bestätigen. Durch diese Trennung soll verhindert werden, dass derselbe Prozess, der eine Aktion anstößt, sich zugleich selbst die Erlaubnis erteilt oder den Erfolg ohne unabhängige Prüfung erklärt.

Das ist eine nützliche konzeptionelle Unterscheidung, reicht aber nicht aus, um ein System zu bewerten. Um zu verstehen, was ein Critic tatsächlich tut, müsste man beispielsweise wissen, welche Aktionen er als sensibel einstuft, welche Regeln er anwendet, welche Informationen er erhält und wie er mit Unsicherheit umgeht. Außerdem müsste man sowohl falsche Ablehnungen messen – also gültige Aktionen, die er verhindert – als auch falsche Freigaben, bei denen er eine Aktion trotz eines Regelverstoßes zulässt. Für DeReAct liegen uns keine verifizierten Ergebnisse vor, die diese Fragen beantworten.

Auch die dem Context Manager zugeschriebene Aufgabe wirft eine weitere Frage auf: Was gilt als Beleg dafür, dass eine Aufgabe abgeschlossen ist? Eine Zusammenfassung des Gesprächs könnte Änderungen übersehen, die mit einem Werkzeug vorgenommen wurden. Umgekehrt könnte eine Antwort des Agenten den Erfolg eines Vorgangs behaupten, ohne ihn nachzuweisen. Für eine Prüfung müsste bekannt sein, welchen Status die Komponente speichert, welche externen Signale sie abfragt und wie sie Widersprüche zwischen dem Verlauf und dem Ergebnis eines Werkzeugs behandelt. Der Vorschlag zielt auf diese Trennung; die verfügbare Beschreibung bestätigt jedoch weder die Implementierung noch ihre Kriterien.

Benchmarks ersetzen nicht die Überprüfung der Veröffentlichung

Im Vorschlag werden GAIA und SWE-bench Verified als Tests genannt, in denen Verbesserungen gemessen worden sein sollen. Um einen Pass@1-Wert einordnen zu können, genügt der Name des Benchmarks nicht. Erforderlich sind auch Angaben zur Version, zu den verwendeten Modellen, den verfügbaren Werkzeugen, der Zahl der Versuche, den Ausführungsbedingungen und der Vergleichsbaseline. Ebenso wichtig ist, ob die Unterschiede konsistent sind und wie Fehler gezählt werden. Ohne bestätigte Details könnte eine einzelne Zahl nicht belegen, ob ein Ergebnis auf den Critic, den Context Manager oder eine andere Konfigurationsänderung zurückgeht.

Benchmarks prüfen klar abgegrenzte Aufgaben unter experimentellen Bedingungen. Selbst ein reproduzierbares Ergebnis in einem solchen Test würde die Leistung innerhalb dieser Umgebung beschreiben; es würde nicht automatisch belegen, dass ein Agent gegenüber Nutzern, sensiblen Daten oder mit realen Systemen verbundenen Werkzeugen sicher ist. Für Aussagen zur Sicherheit im praktischen Betrieb wären gezielte Prüfungen der Richtlinien, unzulässiger Freigaben, Manipulationsversuche und des Verhaltens bei Unsicherheit erforderlich.

Hier geht es zunächst nicht darum, ob die Verbesserungen groß oder klein sind, sondern darum, was überhaupt gemessen wurde und wo. Die verifizierten Informationen geben keine Antwort darauf, welche genauen Pass@1-Werte die einzelnen DeReAct-Varianten erreichen, welche Baselines verglichen werden oder ob das Verfahren reproduzierbar ist. Solange keine einschlägige Primärdokumentation vorliegt, sollten diese Lücken nicht mit Zahlen oder erschlossenen Einzelheiten gefüllt werden.

Kosten, verbleibende Fehler und Übertragbarkeit

Die Trennung von Entscheidungen kann die Kontrolle erleichtern, zugleich aber zusätzliche Latenz, Modellaufrufe und Fehlerquellen mit sich bringen. Ein zu strenger Critic könnte legitime Aufgaben blockieren; ein zu großzügiger könnte Aktionen durchlassen, die abgelehnt werden sollten. Ein Context Manager mit unvollständigen Informationen könnte eine Aufgabe vorschnell als erledigt einstufen. Ein übermäßig vorsichtiger Manager könnte sie dagegen offenhalten, obwohl das Ziel bereits erreicht ist. Das sind allgemeine Risiken, die gemessen werden müssten – keine nachgewiesenen Mängel von DeReAct.

Eine aussagekräftige Bewertung sollte Grenzfälle und Fehler einbeziehen, nicht nur den Anteil abgeschlossener Aufgaben. Relevant ist etwa, was geschieht, wenn ein Werkzeug einen Fehler zurückgibt, der Agent widersprüchliche Informationen erhält oder sich der Status nach einer Aktion ändert. Außerdem wäre zu prüfen, ob das System zwischen dem Anfordern eines Vorgangs und der bestätigten Ausführung dieses Vorgangs unterscheidet.

Auch die Übertragbarkeit lässt sich nicht allein aus zwei Benchmark-Namen ableiten. Eine Methode kann bei Programmieraufgaben oder beim Werkzeuggebrauch unter kontrollierten Bedingungen gut abschneiden und sich bei Geschäftsabläufen, Systemen mit anderen Berechtigungen oder personenbezogenen Informationen anders verhalten. Die AEPD weist in ihren allgemeinen Informationen zu agentischer KI darauf hin, dass solche Systeme bei der Verarbeitung personenbezogener Daten zu stärkerer Automatisierung führen können. Dieser Kontext macht die Prüfung von Grenzen und Aufsicht relevant, ist aber kein Beleg für das Design oder die Sicherheit von DeReAct.

Was für eine abschließende Überprüfung noch fehlt

Damit aus dem Vorschlag eine überprüfbare Meldung werden kann, braucht es eine zugängliche Primärquelle, die die Arbeit identifiziert und die evaluierte Version beschreibt. Anschließend müsste die Methode geprüft werden: Wie ist die Richtlinie des Critic definiert? Woher erhält er Kontext? Welche Zustände speichert der Context Manager? Und nach welchen Kriterien bestätigt er den Abschluss einer Aufgabe? Ohne diese Informationen beschreiben die Komponentennamen eine Absicht, nicht notwendigerweise das Verhalten einer Implementierung.

Für die Überprüfung der Ergebnisse braucht es mindestens vollständige Pass@1-Tabellen für jede Variante, die Konfiguration der Baselines und eine Erklärung, wie GAIA und SWE-bench Verified ausgeführt wurden. Verfügbarer Code, Prompts und Ablaufspuren würden helfen, das Experiment zu reproduzieren. Falls einzelne Materialien nicht veröffentlicht wurden, müsste ausdrücklich angegeben werden, welche Teile sich nicht reproduzieren lassen. Es wäre weder zulässig, die Verfügbarkeit solcher Materialien einfach vorauszusetzen, noch zu behaupten, die Studie biete sie nicht, ohne die Veröffentlichung geprüft zu haben.

Bis diese Dokumentation vorliegt, ist nur eine begrenzte Schlussfolgerung gerechtfertigt: Die Entkopplung der Aktionsfreigabe von der Bestätigung des Aufgabenabschlusses lässt sich als Designprinzip erläutern und bewerten. Die experimentellen Ergebnisse und etwaige Garantien von DeReAct können hier jedoch nicht bestätigt werden. Dieser Unterschied ist wichtig für alle, die Werkzeuge vergleichen oder den Einsatz von Agenten erwägen: Eine überzeugende Architektur ist weder eine unabhängige Validierung noch eine Risikobewertung für den konkreten Einsatzkontext.

Für die weitere Einordnung sollten drei Fragen auseinandergehalten werden: Was kann ein Agent tun? Welche Kontrollen greifen, bevor er handelt? Und wie wird das Ergebnis überprüft? Eine allgemeine Erklärung von ReAct hilft, die erste Frage in einen Kontext zu setzen. Ein Systemvergleich sollte die zweite untersuchen; eine Bewertung der eingesetzten Werkzeuge sollte die dritte anhand von Belegen für jedes verbundene Werkzeug prüfen. Keine dieser Perspektiven ändert den Verifizierungsstand von DeReAct: Die Primärdokumentation und die Ergebnisse müssen weiterhin bestätigt werden.

Weiter entdecken

Korrekturen und Transparenz

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