Localizing and Correcting Errors for LLM-based Planners

Die vorgestellte Arbeit stellt eine Methode namens L-ICL vor, die durch gezielte, schrittweise Korrekturen von Verstößen gegen Domänenbeschränkungen die Fähigkeit von LLMs zur Planung in symbolischen Umgebungen signifikant verbessert.

Das Wesentliche

Stellen Sie sich vor, Sie geben einem sehr klugen, aber manchmal etwas chaotischen Assistenten eine Aufgabe: Er soll durch ein Labyrinth laufen und dabei die Wände beachten.

Das Problem ist: Dieser Assistent (ein sogenanntes Large Language Model oder LLM) ist extrem gut darin, Mathematik zu lösen oder Code zu schreiben. Aber wenn es darum geht, logische Pläne zu erstellen – wie „Geh nicht durch die Wand" oder „Heb den Kasten nicht auf, wenn deine Hand schon voll ist" – dann stolpert er oft. Er plant einen Weg, der physikalisch unmöglich ist, als würde er durch Mauern laufen oder Dinge tun, die gegen die Regeln verstoßen.

Die Forscher in diesem Papier haben eine Lösung gefunden, die sie L-ICL nennen. Hier ist die Erklärung, wie das funktioniert, ganz einfach und mit ein paar Bildern im Kopf:

1. Das Problem: Der Assistent lernt aus ganzen Geschichten, nicht aus Fehlern

Bisher haben Leute versucht, dem Assistenten zu helfen, indem sie ihm ganze Lösungswege als Beispiel zeigten.

• Die alte Methode (wie ein Kochbuch): „Hier ist ein Rezept für einen perfekten Kuchen. Schau dir an, wie ich ihn backe."
• Das Problem: Der Assistent sieht den perfekten Kuchen am Ende, aber er versteht nicht genau, warum er den Ofen bei 180 Grad und nicht bei 200 Grad lassen muss. Wenn er dann selbst backt, stellt er den Ofen auf 200 Grad und verbrennt den Kuchen. Er hat die Regel nicht wirklich verstanden, nur das Ergebnis gesehen.

2. Die Lösung: L-ICL ist wie ein „Fehler-Feedback-System"

Die Forscher sagen: „Lass uns nicht ganze Geschichten zeigen. Zeig uns genau den Moment, in dem er einen Fehler macht, und korrigiere nur diesen einen Schritt."

Stellen Sie sich L-ICL wie einen strengen, aber hilfsbereiten Trainer vor, der neben dem Assistenten steht:

1. Der Versuch: Der Assistent versucht, einen Plan zu machen.
2. Der Fehler: Er sagt: „Ich gehe jetzt nach Osten."
3. Die Korrektur (Der Clou): Der Trainer schreit nicht: „Nein, das ganze Rezept ist falsch!" Sondern er sagt: „Moment! Schau her: Wenn du an Position (3,4) nach Osten gehst, triffst du auf eine Wand. Hier ist die korrekte Regel: Von (3,4) aus kannst du nur nach Norden oder Süden gehen."
4. Das Lernen: Der Assistent merkt sich diese eine kleine Regel für diesen einen Fall.

3. Warum ist das so effektiv? (Die Analogie des „Einzel-Tests")

In der Softwareentwicklung gibt es etwas, das man Unit Testing (Einzeltests) nennt. Man testet nicht das ganze Programm auf einmal, sondern prüft jede kleine Funktion einzeln, ob sie funktioniert.

• Die alten Methoden waren wie ein End-to-End-Test: „Das Programm läuft am Ende durch." (Aber wo genau hat es geklemmt? Weiß man nicht.)
• L-ICL ist wie Unit Testing: Es prüft jeden einzelnen Schritt. „Funktioniert der Befehl 'nach Osten gehen' an dieser Stelle?" Wenn nein -> sofort korrigieren.

Das ist viel effizienter. Der Assistent braucht viel weniger Informationen, um zu lernen. In den Experimenten hat L-ICL mit nur 2.000 Zeichen an Text (ein paar kleine Korrekturbeispiele) besser funktioniert als andere Methoden, die 20.000 Zeichen (ganze Lösungswege) brauchten.

4. Was passiert am Ende?

Nachdem der Assistent so 30 bis 60 dieser kleinen Korrekturen gesehen hat, passiert Magie:

• Er lernt nicht nur, dass er nicht durch Wände laufen darf.
• Er lernt das Prinzip: „Wenn ich an einer Wand stehe, darf ich nicht in die Wand gehen."
• Er kann dieses Wissen dann auf völlig neue Labyrinthe übertragen, die er noch nie gesehen hat.

Zusammenfassung in einem Satz

Statt dem KI-Assistenten eine ganze Geschichte vorzulesen, damit er sie nachahmt, zeigen wir ihm genau die Stelle, an der er stolpert, und geben ihm eine winzige, klare Regel, wie er es richtig macht. So wird er aus einem chaotischen Träumer zu einem zuverlässigen Planer, der die Regeln der Welt (wie Wände und Schwerkraft) endlich ernst nimmt.

Das Ergebnis: Auf einem einfachen 8x8-Raster (wie ein kleines Schachbrett) schaffte es der Assistent von 0 % Erfolg (ohne Hilfe) auf 89 % Erfolg (mit nur 60 kleinen Korrekturen). Das ist ein riesiger Sprung!

Technische Zusammenfassung

1. Problemstellung

Große Sprachmodelle (LLMs) zeigen zwar beeindruckende Fähigkeiten im mathematischen und programmierbezogenen Reasoning, versagen jedoch häufig bei symbolischen klassischen Planungsaufgaben (z. B. Navigation in Gitterwelten, Sokoban, BlocksWorld).

• Hauptursache: LLMs generieren Pläne, die häufig Domänenbeschränkungen verletzen (z. B. durch Wände laufen, Objekte bewegen, die blockiert sind), selbst wenn diese Regeln explizit in den Anweisungen stehen.
• Limitierung bestehender Ansätze: Herkömmliche Methoden wie In-Context Learning (ICL) mit vollständigen Lösungstrajektorien oder Retrieval-Augmented Generation (RAG) sind ineffizient. Sie zeigen dem Modell, dass eine Lösung funktioniert, aber nicht, warum einzelne Schritte gültig sind. Dies führt dazu, dass das Modell die zugrunde liegenden Constraints (Einschränkungen) nicht korrekt ableitet.
• Beobachtung: Selbst mit 20.000 Zeichen an Kontext (vollständige Trajektorien) erreichen Baseline-Methoden auf einfachen 8x8-Gitterwelten nur eine Erfolgsrate von ca. 9 %.

2. Methodik: Localized In-Context Learning (L-ICL)

Die Autoren schlagen L-ICL vor, eine Methode, die Fehler lokalisiert und durch gezielte, minimale Korrekturen behebt, anstatt ganze Lösungswege vorzugeben.

Kernkonzept

Statt vollständiger Beispiele werden dem Prompt lokalisierte Eingabe-Ausgabe-Paare hinzugefügt, die spezifisch für den ersten fehlerhaften Schritt in einer Planungssequenz sind.

Der Prozess (Iterativ)

1. Strukturierung (PTP): Das Modell nutzt das Program Trace Prompting (PTP)-Framework. Das Problem wird als teilweise spezifiziertes Programm dargestellt, bei dem der LLM das Verhalten von Subroutinen (z. B. get_applicable_actions) inferieren muss, basierend auf Dokumentation und Beispielen.
2. Fehleridentifikation: Für ein Trainingsproblem generiert das Modell einen „Trace" (Ablauf). Ein Oracle (ein symbolischer Simulator oder Verifizierer) prüft diesen Trace Schritt für Schritt.
3. Lokalisierung: Der erste Schritt, der gegen eine Domänenregel verstößt (z. B. ein ungültiger Move), wird identifiziert.
4. Korrektur-Generierung: Das Oracle liefert die korrekte Ausgabe für diesen spezifischen Eingabewert.
5. Prompt-Augmentierung: Diese Korrektur wird als minimales Beispiel (im Stil von Python-Doctests) in die Dokumentation der entsprechenden Subroutine eingefügt.
6. Iteration: Dieser Prozess wird über viele Trainingsbeispiele hinweg wiederholt. Die Prompt-Dokumentation wird so mit einer wachsenden Bibliothek an gezielten Korrekturen „gehärtet".

Vorteile gegenüber anderen Methoden

• Effizienz: L-ICL benötigt deutlich weniger Kontext (ca. 2.000 Zeichen für gezielte Korrekturen) als RAG-ICL (20.000 Zeichen für Trajektorien), erzielt aber bessere Ergebnisse.
• Trainings- vs. Inferenzphase: Das Oracle wird nur während des Trainings benötigt. Zur Inferenzzeit benötigt L-ICL nur einen einzigen Durchlauf ohne externe Tools (im Gegensatz zu ReAct mit Oracle-Feedback, das bei jedem Schritt verifizieren muss).

3. Wichtige Beiträge

1. Diagnose von Constraint-Verletzungen: Die Autoren quantifizieren präzise, dass die Verletzung von Domänenregeln die dominierende Fehlerart bei LLM-Planern ist, selbst bei einfachen Aufgaben.
2. Einführung von L-ICL: Eine neue Methode, die Planungsgültigkeit durch lokalisierte, fehlergetriebene Korrekturen verbessert. Sie zeigt, dass gezielte Beispiele vollständigen Trajektorien überlegen sind, selbst wenn diese 10-mal mehr Kontext verbrauchen.
3. Umfassende Evaluation: Die Methode wurde über mehrere Domänen (8x8 Gitter, 10x10 Labyrinthe, Sokoban, BlocksWorld) und vier verschiedene LLM-Architekturen (DeepSeek V3/V3.1, Claude Haiku/Sonnet) evaluiert.
4. Open Source: Die Veröffentlichung des Benchmark-Sets und des Codes zur Förderung weiterer Forschung.

4. Ergebnisse

Die Experimente zeigen dramatische Verbesserungen:

• 8x8 Gitterwelt:
  • Zero-Shot: 0 % Erfolg.
  • Beste Baseline (Self-Consistency): 45 % Erfolg.
  • L-ICL (mit 60 Beispielen): 89 % Erfolg.
  • L-ICL erreicht mit nur 60 Trainingsbeispielen eine Validitätsrate von 89 %, während die beste Baseline bei 59 % liegt.
• Komplexere Domänen:
  • In Sokoban und BlocksWorld verbessert L-ICL die Erfolgsraten signifikant, obwohl hier eine Lücke zwischen „gültigen Plänen" (Valid) und „erfolgreichen Plänen" (Success) bleibt. Dies deutet darauf hin, dass L-ICL die Einhaltung von Regeln (Physik) meistert, aber strategisches Langzeit-Reasoning (Vermeidung von Sackgassen) weiterhin eine Herausforderung bleibt.
• Sample-Effizienz: L-ICL erreicht seinen Leistungspeak typischerweise mit nur 30–60 Trainingsbeispielen.
• Generalisierung:
  • Die Methode funktioniert über verschiedene Architekturen hinweg.
  • Out-of-Distribution: Auf größere Labyrinthe (15x15), die während des Trainings nicht gesehen wurden, überträgt sich das Gelernte signifikant (Erfolgsrate steigt von 9 % auf 49 %), da die Modelle allgemeine Constraints (z. B. „Wände blockieren") und nicht nur spezifische Positionen lernen.
• Visualisierung: L-ICL funktioniert auch ohne ASCII-Gitterdarstellung, obwohl diese das frühe Lernen beschleunigt. Das Modell lernt die Struktur rein aus den Korrekturen.

5. Bedeutung und Fazit

Das Paper liefert eine wichtige Einsicht für die Zuverlässigkeit von LLMs in der Planung:

• Struktur vor Menge: Die Art der Demonstration ist wichtiger als die Menge. Lokale Korrekturen (analog zu Unit-Tests in der Softwareentwicklung) sind effektiver als End-to-End-Tests (vollständige Lösungen), da sie explizit machen, warum ein Schritt gültig ist.
• Prozedurale Härtung: L-ICL fungiert als eine Schicht zur „prozeduralen Härtung". Es stellt sicher, dass die grundlegenden Aktionen physikalisch korrekt sind, was eine solide Basis für höheres strategisches Reasoning bildet.
• Praktische Implikation: Anstatt alle Regeln manuell und exhaustiv im Prompt zu spezifizieren, können Entwickler L-ICL nutzen, um das Modell durch fehlergetriebene Korrekturen die Regeln selbstständig ableiten zu lassen.

Zusammenfassend beweist L-ICL, dass LLMs durch gezieltes, lokales Lernen von Fehlern in der Lage sind, komplexe Domänenbeschränkungen zu internalisieren und damit Planungsprobleme zu lösen, bei denen sie zuvor systematisch versagten.