Die meiste Arbeit zu LLM-Halluzinationen zielt auf das Modell: bessere Trainingsdaten, verbesserte Architekturen, eingeschränktes Decoding. All das ist wichtig, setzt aber still voraus, dass der Prompt eine feste Eingabe ist, an der sich nichts ändern lässt.
Diese Annahme ist falsch. Jede LLM-Ausgabe hat zwei Akteure: das Modell und den Nutzer. Der Prompt ist die einzige Eingabefläche, die der Nutzer vollständig kontrolliert, und er hat einen realen Einfluss darauf, ob das Modell am Ende etwas erfindet. Das war der Ausgangspunkt meiner Bachelorarbeit an der TUM, Echo, und genau das bedeutet "Shift-Left" in diesem Kontext: das Risiko vor der Generierung erkennen, nicht danach.
Zwei Arten von Risiko, die sich im Prompt verstecken
Das Erste, was Echo brauchte, war ein Vokabular. Betrachtet man Prompts, die zuverlässig Halluzinationen erzeugen, fallen die Probleme in zwei klar unterscheidbare Kategorien:
Prompt Risk liegt auf Token-Ebene: mehrdeutige Formulierungen, vage Bezüge, Präsuppositionen, die unbelegte Behauptungen einschleusen. Das klassische Beispiel ist eine Frage, die nebenbei etwas Falsches behauptet ("Warum hat X im Jahr 2021 Y übernommen?") und das Modell dazu einlädt, darauf aufzubauen.
Meta Risk ist struktureller Natur: Multi-Hop-Fragen, die mehrere Schlussfolgerungen aneinanderreihen, Scope-Überladung, bei der ein einziger Prompt fünf Ergebnisse verlangt, Constraints, die sich still widersprechen. Keines davon ist auf Wortebene falsch. Der Prompt ist nur so geformt, dass er das Modell über das hinausdrängt, was es zuverlässig beantworten kann.
Die Unterscheidung ist wichtig, weil sich die Lösungen unterscheiden. Prompt Risk behebt man, indem man Tokens klärt. Meta Risk behebt man, indem man die Anfrage umstrukturiert oder aufteilt.
Eine Zahl daraus machen
Eine Taxonomie ist nützlich, aber "dieser Prompt fühlt sich riskant an" skaliert nicht. Deshalb führt Echo die Prompt Risk Density (PRD) ein: einen gewichteten Score über die Risikokategorien hinweg, normalisiert nach Prompt-Komplexität, der das Halluzinationspotenzial quantifiziert, noch bevor überhaupt generiert wird.
Die Normalisierung ist der entscheidende Teil. Ein langer, detaillierter Prompt enthält naturgemäß mehr markierbare Textstellen als ein kurzer; entscheidend ist die Dichte des Risikos im Verhältnis dazu, wie viel der Prompt zu leisten versucht, nicht die reine Anzahl.
Die Pipeline
Echo setzt das als Multi-Agenten-Pipeline mit vier Rollen um: einen Analyzer, der Risiken erkennt und klassifiziert, einen Initiator und einen Conversation-Agenten, die die iterative Verfeinerung mit dem Nutzer vorantreiben, sowie einen Preparator, der den verbesserten Prompt zusammensetzt. Die Ausgaben sind strukturiertes XML, und die UI stellt das Risiko farblich codiert direkt im Prompt-Text dar, sodass genau erkennbar ist, welche Textstellen das Problem sind, statt eines generischen "Ihr Prompt ist unklar".
Human-in-the-loop war eine bewusste Entscheidung. Vollautomatisches Umschreiben verändert oft genug, was der Nutzer eigentlich meinte, um gefährlich zu sein; die Verfeinerungsschleife belässt die Kontrolle über die Absicht beim Nutzer, während das System die Risikoerkennung übernimmt.
Was ich daraus mitgenommen habe
Zwei Dinge sind mir über die Arbeit selbst hinaus im Gedächtnis geblieben.
Erstens: Risiko vor der Generierung zu erkennen ist günstiger, als schlechte Ausgaben im Nachhinein zu korrigieren. Post-hoc-Verifikation einer halluzinierten Antwort bedeutet, dass die Generierung bereits bezahlt ist und nun noch ein zweites System nötig ist, um sie zu prüfen. Die promptseitige Analyse läuft auf einer viel kleineren Eingabe, bevor der Schaden entsteht.
Zweitens: Bessere Prompts verkleinern den Abstand zwischen Modellklassen. In der Evaluation der Arbeit halfen verfeinerte Prompts kleineren Open-Source-Modellen, einen Teil des Abstands zu teuren Closed-Source-Modellen aufzuholen. Für risikoreiche Domänen wie Recht, Gesundheitswesen und Finanzen, wo Deployment-Beschränkungen die größten Modelle ohnehin oft ausschließen, ist das ein praktisches Ergebnis, kein rein akademisches.
Die Arbeit, der Quellcode und eine Demo finden sich auf der Forschungsseite. Wenn Sie an LLM-Zuverlässigkeit arbeiten und sich austauschen möchten, nehmen Sie gerne Kontakt auf.