LLM-Agenten verlieren Genauigkeit bei der Suche in Tool-Outputs

TL;DR

• Moderne KI-Agent-Harnesses speichern lange Tool-Ausgaben in Dateien und zwingen Modelle, diese zu durchsuchen, was zu erheblichen Genauigkeitsverlusten führt [^1].
• Tests mit geochemischen Simulationen der USGS zeigten, dass Retrieval-Schritte Extraktionsfehler verursachen, selbst wenn die Berechnungsergebnisse perfekt deterministisch sind [^1] [^2].

Hintergrund

Große Sprachmodelle führen zunehmend externe Tools, Softwareanwendungen und Code-Skripte aus, um fachspezifische Aufgaben zu lösen. Wenn Tools massive Berichte mit zehntausenden Zeilen generieren, können Entwickler von Agent-Harnesses die gesamte Ausgabe nicht direkt in ein Kontextfenster packen, ohne Token-Limits zu überschreiten oder hohe Kosten zu verursachen. Um diese Einschränkung zu umgehen, schreiben Agent-Frameworks Tool-Antworten auf die Festplatte und weisen das Modell an, diese Dateien iterativ zu prüfen oder zu greppen. Obwohl diese Architektur den Token-Verbrauch kontrolliert, verlagert sie die Abhängigkeit des Systems vom direkten Lesen auf mehrstufige Retrieval-Operationen.

Was passiert ist

Forschende untersuchten, wie sich die Speicherung in externen Dateien auf die Genauigkeit von Sprachmodell-Agenten auswirkt, die komplexe wissenschaftliche Simulationen ausführen [^1]. Das Forschungsteam testete Agent-Frameworks mit PHREEQC, einem deterministischen geochemischen Simulationsprogramm des United States Geological Survey (USGS) [^2]. PHREEQC berechnet chemische Reaktionen, Flüssigkeitstransport und Gleichgewichtsmodelle für hydrogeologische Projekte und erzeugt häufig Textberichte mit mehr als 800.000 Zeichen [^1] [^2].

Da PHREEQC vollständig deterministisch ist, führen identische Eingabeparameter immer zu identischen numerischen Ergebnissen [^2]. Diese physikalische Konsistenz ermöglichte es den Forschenden, genau zu isolieren, an welchen Stellen KI-Agenten bei mehrstufigen Problemlösungsläufen scheiterten [^1]. Die Studie verglich zwei wesentliche Betriebsmodi: die Standardausführung mit vollständigem Kontext, bei der das Modell den gesamten Ausgabetext sieht, und das harness-gesteuerte Dateisuchen, bei dem der Agent Zeilenlese- oder Suchbefehle nutzt, um relevante Abschnitte der auf der Festplatte gespeicherten Ausgabe zu extrahieren [^1].

Die Ergebnisse zeigten einen deutlichen Rückgang der Genauigkeit der Endaufgabe, wenn sich Agenten auf Datei-Retrieval-Tools verließen, um Simulationsausgaben zu prüfen [^1]. Obwohl der zugrunde liegende Simulator jedes Mal korrekte Werte berechnete, gelang es den Agenten häufig nicht, genau die Datenfelder abzurufen, die für nachgelagerte Berechnungen erforderlich waren [^1]. Die Fehlermodi fielen hauptsächlich in drei Kategorien: unvollständige Suchparameter, teilweise Zeilenextraktion und die Fehlinterpretation von Tabellenköpfen beim Betrachten isolierter Textfragmente ohne Kontext [^1].

Darüber hinaus entdeckten die Forschenden, dass iteratives Retrieval zu sich aufsummierenden Fehlerschleifen führte [^1]. Wenn ein Agent eine suboptimal gestellte Suchanfrage absetzte, um eine Logdatei zu lesen, beschädigte das unvollständige Ergebnis seinen internen Plan. Anstatt seine Suchparameter zu verfeinern, behandelte der Agent die unvollständige Ausgabe oft als absolute Wahrheit. Dies führte zu fehlerhaften Berechnungen, obwohl er Sekunden zuvor exakt die fehlerfreie Simulationsdatei generiert hatte [^1].

Warum es wichtig ist

Da Softwareentwickler autonome Agenten für die Unternehmensautomatisierung einsetzen, ist das Auslagern großer Datenmengen auf externe Speicher zu einer gängigen Architekturpraxis geworden. Frameworks implementieren häufig Dateisystem-Tools oder lokale Suchindizes, um die Anzahl der Prompt-Tokens niedrig zu halten. Diese Studie beweist jedoch, dass das Einsparen von Platz im Kontextfenster mit versteckten Genauigkeitseinbußen einhergeht. Wenn Softwarearchitekturen die direkte Wahrnehmung des Modells durch zwischengeschaltete Retrieval-Schritte ersetzen, wird der Retrieval-Mechanismus selbst zur primären Fehlerquelle des Systems.

Das Kernproblem liegt im grundlegenden Unterschied zwischen Datenverarbeitung und Daten-Retrieval. Während fundamentale Sprachmodelle starke Denkfähigkeiten über Text zeigen, der direkt in ihrem Prompt-Kontext vorhanden ist, bleibt ihre Fähigkeit zur Konstruktion präziser Suchanfragen über rohe Textdateien unvollkommen. Erstreckt sich eine Ausgabedatei über Tausende strukturierter Datenzeilen, führt ein kleiner Syntaxfehler in einem Dateisuchbefehl dazu, dass das Modell kritische Datenpunkte übersieht. Der Agent setzt dann seine Argumentationskette mit beschädigtem Kontext fort, ohne zu erkennen, dass seine Informationslücke auf eine fehlerhafte Suchanfrage und nicht auf eine fehlerhafte Berechnung zurückzuführen ist.

Diese Realität stellt Entwickler von KI-Agenten-Workflows vor einen kritischen Zielkonflikt. Das bloße Erhöhen der Kontextlängen oder Senken der Ausführungskosten durch Auslagern roher Tool-Ausgaben in Vektorspeicher oder Dateisysteme garantiert keine zuverlässige Leistung. Für hochrelevante Bereiche wie Ingenieurwesen, Finanzprüfung und wissenschaftliche Simulation müssen Softwareteams strukturierte Output-Parser entwickeln, anstatt sich darauf zu verlassen, dass LLMs rohe Logdateien greppen. Das Umwandeln großer Ausgaben in strukturierte JSON-Zusammenfassungen oder spezialisierte Datenbankschemata vor der Übergabe an einen Agenten bietet eine weit höhere Zuverlässigkeit, als vom Agenten zu erwarten, rohe Dateien autonom abzufragen.

Ein Beispiel aus der Praxis

Nimm an, ein Umweltberater nutzt einen KI-Agenten, um Wasserqualitätssimulationen für zwanzig städtische Brunnen durchzuführen. Der Agent ruft das PHREEQC-Tool der USGS auf, das für jeden Brunnen eine chemische Analysedatei mit 800.000 Zeichen erzeugt. Um Kosten bei API-Tokens zu sparen, speichert das Agent-Harness diese Dateien in einem lokalen Ordner und stellt dem Agenten einen Dateisuchbefehl zur Verfügung.

Wird der Agent aufgefordert zu ermitteln, welcher Brunnen die sicheren Blei-Grenzwerte überschreitet, sucht er nach "lead concentration". Im Simulationsbericht wird das Element jedoch unter seiner chemischen Abkürzung "Pb" in einem tief verschachtelten Tabellenkopf geführt. Die Suche des Agenten liefert null Ergebnisse. Anstatt seine Suchanfrage anzupassen, um chemische Symbole zu prüfen, nimmt der Agent an, dass kein Blei nachgewiesen wurde, und meldet fälschlicherweise, dass alle zwanzig Brunnen die Sicherheitsstandards erfüllen. Die Simulation enthielt die korrekte Antwort, aber der Datei-Retrieval-Schritt führte zu einem vollständigen Systemausfall.

Passende Produkte

Wir empfehlen dieses Buch, weil es erklärt, wie sich Retrieval, Indizierung und Daten-Pipelines auf die Software-Zuverlässigkeit in komplexen Systemen auswirken.