Praxis

Warum Nachprompten den Restfehler selten beseitigt

Du hast einen Versuch. Geht er schief, helfen weitere Korrekturrunden leider selten.

27. September 20264 Min. LesezeitPromptingSelbstkorrekturBest-of-N

Wenn du einem der leistungsfähigsten KI-Sprachmodelle – etwa ChatGPT, Claude oder Gemini – ein komplexes Problem beschreibst und daraus einen Algorithmus entwickeln lässt, ist das erste Ergebnis oft beeindruckend.

Ein gewisser Restfehler bleibt. Trotzdem wirkt die Lösung so vielversprechend, dass der nächste Schritt naheliegt: Du bittest das Modell, hier und da noch etwas zu korrigieren.

Genau dann beginnt das Problem.

Absprung aus dem Hubschrauber – ein Versuch, keine Korrekturrunde.
Absprung aus dem Hubschrauber – ein Versuch, keine Korrekturrunde.

Mit jeder weiteren Korrekturrunde wird der Algorithmus häufig nicht schärfer, sondern unschärfer. Studien zu mehrstufigen Gesprächen zeigen, dass Sprachmodelle nach einer falschen Abzweigung oft nicht mehr zuverlässig auf den richtigen Weg zurückfinden.1 Ohne präzisen Evaluator können sie zudem nur eingeschränkt beurteilen, ob eine Überarbeitung tatsächlich besser ist – oft verschlechtert die Selbstkorrektur das Gesamtergebnis sogar.2

Hinzu kommt: Jede neue Anweisung verlängert und verkompliziert den Kontext. Sprachmodelle verarbeiten lange Kontexte nicht gleichmäßig zuverlässig.3 Mit zunehmender Kontextlänge kann ihre Leistung selbst bei einfachen Aufgaben unvorhersehbar nachlassen.4 So kann eine lokale Korrektur gelingen, während an anderer Stelle eine bereits erfüllte Anforderung aus dem Blick gerät. Der Fehler wird dann eher verschoben als reduziert.

Warum nicht einfach einen Evaluator bauen?

Ein unabhängiger Evaluator könnte erkennen, ob eine neue Version tatsächlich besser ist. In der Praxis ist es jedoch oft aufwendiger, einen guten Evaluator zu entwickeln als den Algorithmus selbst. Er braucht belastbare Testfälle, klare Bewertungskriterien und eine Gewichtung der Fehler.

Für ernsthafte Anwendungen führt daran trotzdem kein Weg vorbei. Häufig entsteht der Evaluator deshalb parallel zum Algorithmus: zunächst nicht, um jede frühe Iteration zu steuern, sondern um sicherzustellen, dass spätere Änderungen keine neuen Fehler einführen.

Warum bleibt dieses Problem bestehen, obwohl die Modelle immer leistungsfähiger werden?

Weil ein Sprachmodell von sich aus keinen unabhängigen Maßstab für die Korrektheit deiner konkreten Lösung besitzt. Es erzeugt eine plausible Antwort. Ob diese Antwort alle Anforderungen erfüllt, kann es ohne externe Prüfung nicht verlässlich feststellen.

Wie habe ich das Problem für mich gelöst?

1. Neu starten statt reparieren

Es klingt ernüchternd, ist aber häufig die effizienteste Lösung: Ich starte noch einmal von vorn – mit einem verbesserten Prompt und einem frischen Kontext.1

Meine Erkenntnisse aus dem ersten Versuch fließen in den neuen Prompt ein. Die Reparaturgeschichte selbst bleibt draußen. Auf diese Weise erhält das Modell eine klarere Aufgabenbeschreibung, ohne die Widersprüche und Nebenwege der vorangegangenen Korrekturrunden mitzuschleppen.

Bei einem guten Prompt ist der verbleibende Restfehler oft akzeptabel.

2. Das Problem zerlegen

Wenn ein Neustart nicht ausreicht, zerlege ich das Gesamtproblem in kleinere Teilprobleme mit klar definierten Schnittstellen. Jedes Teilproblem lasse ich in einem eigenen, isolierten Kontext lösen.

Auch dabei bleibt ein Restfehler. Er ist jedoch meist kleiner, weil das Modell weniger Anforderungen gleichzeitig berücksichtigen muss.

Kurz gesagt

Prompting ist die günstigste Optimierungsstufe.
Neustart, Zerlegung und Best-of-N bilden die nächste Stufe.
Evaluatoren lohnen sich, wenn die zusätzliche Zuverlässigkeit ihren Entwicklungsaufwand rechtfertigt.

3. Präzisionskritische Teile selbst entwickeln

Wenn auch die Zerlegung nicht genügt, entwickle ich die Teile selbst, die besonders hohe Präzision erfordern.

Dabei lasse ich mich vom Sprachmodell beraten. Die Entscheidungen treffe ich aber selbst.

4. Best-of-N

Eine vierte Methode habe ich bisher nicht eingesetzt, weil sie mir zu teuer war. Für Unternehmen mit einem größeren KI-Budget kann sie dennoch attraktiv sein: Mehrere Versionen des Algorithmus werden unabhängig voneinander erzeugt und anschließend mit denselben Tests verglichen. Verwendet wird die Variante, die an den kritischen Stellen am besten abschneidet.

Das ist rechenintensiver, reduziert aber die Abhängigkeit von einem einzigen Versuch.

Welche Strategien nutzt ihr, wenn ein KI-Entwurf fast richtig ist – aber eben nur fast?

Quellen

Fußnoten

  1. Philippe Laban, Hiroaki Hayashi, Yingbo Zhou, Jennifer Neville: „LLMs Get Lost in Multi-Turn Conversation“. arXiv:2505.06120, Mai 2025. ↩ ↩2

  2. Jie Huang, Xinyun Chen, Swaroop Mishra, Huaixiu Steven Zheng, Adams Wei Yu, Xinying Song, Denny Zhou: „Large Language Models Cannot Self-Correct Reasoning Yet“. ICLR 2024; arXiv:2310.01798. ↩

  3. Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, Percy Liang: „Lost in the Middle: How Language Models Use Long Contexts“. Transactions of the Association for Computational Linguistics, Band 12, 2024. ↩

  4. Kelly Hong, Anton Troynikov, Jeff Huber: „Context Rot: How Increasing Input Tokens Impacts LLM Performance“. Chroma Technical Report, Juli 2025. ↩

0 Kommentare

Diskussion

Teile deine Sicht – dein Kommentar erscheint sofort für alle Leser:innen.

Kommentare werden geladen …

Warum Nachprompten den Restfehler selten beseitigt – OSOS/Omega Blog | OSOS/Omega