Wie machen wir es der KI schwer?
LLMs sind eine mächtige Technologie. Sie können sehr viel – machen aber auch viele Fehler und liefern immer wieder falsche Informationen.
Der Ursprung des Problems ist inzwischen hinlänglich bekannt. Sprachmodelle sind nun einmal statistische Modelle: Sie repräsentieren Sprache, nicht Fakten. Faktische Richtigkeit ist für sie nur ein Nebeneffekt statistischer Häufigkeit, ein Nebeneffekt, der durch viel manuelles Feedback mühsam zu einem Feature hochgepäppelt wird.
Dadurch sind bestimmte Aufgaben für ein Sprachmodell schwieriger als andere. Solange es um allgemeine Zusammenhänge geht, ist das Risiko überschaubar. Wenn wir zum Beispiel wissen wollen, wie eine Markteinführung typischerweise abläuft, ist es hilfreich, dass das Modell viele Fälle „aufsammelt“ und verschiedene Möglichkeiten aufzeigt. Kritisch wird es jedoch, wenn es um konkrete Tatsachen geht. Fragen wir etwa nach der Markteinführung des Waschmittels Supersoft der Firma ACME Ltd. in Frankreich im Jahr 2023, möchten wir keine Vermischung mit anderen Fällen und kein „kann“ oder „möglicherweise“ – doch genau das fällt Sprachmodellen besonders schwer. Daraus resultieren die bekannten Pannen mit erfundenen Fallbeispielen vor Gericht oder unsere tagtäglichen Probleme mit KI-gestützter Recherche.
Aber es sind nicht nur die konkrete Fragen, die ein LLM herausfordern. Auch mit differenzierte Aufgaben machen wir dem Sprachmodell das Leben schwer – und das können wir bereits unseren Anweisungen ansehen.
Typische Risikofaktoren
Hier ein paar typische Muster komplexer, differenzierter Anweisungen, die zur Häufung von Fehlern in unseren KI-Anwendungen führen:
- Risikofaktor bedingtes RAG: Retrieval Augmented Generation (RAG) hat sich als Technik etabliert, wenn wir das LLM dazu bringen wollen, sich an Fakten zu halten, vielleicht sogar an unternehmensspezifische Fakten. Jetzt kann es sein, dass in den Inhalten, auf die das Retrieval Zugriff hat, auch vertrauliche Daten enthalten sind, die nur für ausgewählte Nutzer zugänglich sein sollen, oder technische Details, die nicht in jede Zielgruppe gehören. In diesem Fall können wir das Sprachmodell zwar entsprechend anweisen, das ist aber höchst fehleranfällig: das Modell wird dazu tendieren, die Information, die ihm zur Verfügung gestellt wurde, zu kommunizieren, auch in Situationen, in denen wir das nicht möchten.
- Risikofaktor bedingte, situationsabhängige Anweisungen – Oft wollen wir das Gesprächsverhalten des Sprachmodell über Anweisungen steuern. Nehmen wir als Beispiel eine Anwendung im technischen Support. Hier ist es sinnvoll dem LLM vorzugeben „lege dich nicht zu schnell auf eine Fehlerursache fest.“ So vermeiden wir, dass die Anwendung bei der ersten Angabe eines Symptoms haltlose Diagnosen von sich gibt. Aber es gibt natürlich Ausnahmen: Z.B., wenn die Nutzer mit einem eindeutigen Fehlercode kommen. Zu erkennen, wann eine Fehlerursache offensichtlich ist, ist aber schwierig für ein LLM, oft ist eine Art Weltwissen erforderlich, über die es nicht verfügt.
Diese Art bedingte Anweisungen finden wir oft da, wo das Sprachmodell selbst die Gesprächsführung übernehmen soll,B. wenn es ein Verkaufsgespräch führen, Coaching, Training anbieten, Recruiting durchführen oder für den Nutzer Routinekommunikation erledigen, beispielsweise Buchungen vornehmen soll. In all diesen Fällen erwarten wir, dass die AI-Applikation einen Plan verfolgt, aber eben nicht stumpfsinnig. - Widersprüchliche Anweisungen,
Noch gravierender sind direkte Widersprüche. Auf Unternehmensebene gilt vielleicht: „Keine Aussagen zu internen Projekten.“ Gleichzeitig soll eine Recruiting-AI Bewerbern aber genau über diese Projekte Auskunft geben, weil sie dort vielleicht mitarbeiten sollen. Solche Konflikte lassen sich nur vermeiden, wenn man den gesamten Anweisungs-Stack im Griff hat. - Risikofaktor Implikation der Anweisungen – Nehmen wir einen Sales-Bot, der nicht über Wettbewerber sprechen soll. Die Schwierigkeit: Das Modell müsste selbst erkennen, welche Produkte Wettbewerber sind – eine Aufgabe, für die es kaum zuverlässig gerüstet ist. Geben wir dem LLM die Wettbewerber explizit vor, sind wir wieder bei einer Variante von bedingtem RAG („nutze diese Information nur um *nicht* über sie zu sprechen,“) mit dem zusätzlichen Problem, dass LLMs notorisch schwach im Umgang mit Negativ-Anweisungen sind.
- Risikofaktor limitierte Befugnisse: Auch Aufgaben mit klaren Abgrenzungen können riskant sein. Beispiel: Eine medizinische Assistenz-AI darf Termine buchen oder Befunde erklären, aber auf keinen Fall Diagnosen stellen. Diese Grenze konsequent einzuhalten ist für LLMs sehr schwierig, vor allem, weil die Nutzer sie – meist völlig unabsichtlich – immer wieder an die Grenzen ihrer Befugnisse führen werden.
Die Grenzen der Sprachmodelle
Dass diese Arten von Anweisungen problematisch sind, ist kein Wunder: Fast immer geht es hier um das, was die Linguisten Pragmatik nennen, um Verständnis für die Gesprächssituation und das, was sprachliche Äußerungen bewirken. Das liegt weit weg von den Fähigkeiten von LLMs, nicht nur bei der Generierung ihres Outputs. Das fängt schon beim Input an. Es gibt keine echte Unterscheidung zwischen den eigenen Instruktionen, der mittels RAG verfügbar gemachten Informationen Information und dem, was der Gesprächspartner, der Nutzer geäußert hat. Alles ist Teil eines Textinputs, für den dann der am besten passende Output gesucht wird.
So können Sprachmodelle auch keine klare Unterscheidung zwischen verlässlichen und unzuverlässigen Informationen vornehmen. Das macht nicht nur die Steuerung schwieriger, sondern auch anfällig für Missbrauch und gezielte Angriffe (ein eigenes Thema).
Einige dieser Risiken lassen sich in der Gestaltung der Anwendung entschärfen, andere nicht. Oft führt eine Lösung an einer Stelle zu neuen Problemen an anderer. Manche Ansätze sind nur theoretisch möglich, praktisch aber zu aufwändig oder unattraktiv, z.B. wenn der eigentliche Nutzen von LLMs dabei verloren geht – etwa wenn alle vertraulichen Informationen vorab manuell entfernt oder die Daten erst aufwendig strukturiert werden müssen, um sie selektiv freizugeben. Oder wenn wir die für eine bestimmte Situation gültigen Prompts dynamisch aus einem größeren Pool zusammenstellen und mit diesem Auswahlprozess am Ende die Intelligenz programmieren, die das Sprachmodell eigentlich mitbringen sollte.
Und manches ist schlicht nicht umsetzbar, insbesondere dort, wo strikte Grenzen der Befugnisse eingehalten werden müssen.
Bemühen reicht nicht - LLMs brauchen Hilfe
Einfach nur darauf zu hoffen, dass das Modell die Anweisungen schon befolgen wird, genügt nicht. Wir brauchen einen systematischen Umgang mit diesen Risiken. Das beginnt damit, zu erkennen, wenn Anweisungen immer wieder verletzt werden: in der Entwicklungsphase, um gezielt zu „debuggen“; während der Laufzeit, um etwa kritische Befugnis-Überschreitungen sofort aufzuspüren; und schließlich im Monitoring, um die Anwendung kontinuierlich zu verbessern.
Dabei dürfen wir uns nicht allein auf zusätzliche Sprachmodelle verlassen, die wir als überwachende Instanz einsetzen. Abgesehen von höheren Kosten und längerer Latenz würden wir uns damit nur wieder den gleichen Problemen aussetzen. Stattdessen setzen wir auf Techniken, die einen Blick in die Blackbox ermöglichen – und so transparenter machen, wie das Modell tatsächlich mit unseren Vorgaben umgeht.
Zusammenfassung
LLMs machen vor allem dort Fehler, wo Anweisungen komplex, widersprüchlich oder nur unter bestimmten Bedingungen gültig sind, wo Informationen nicht immer oder nur für bestimmte Nutzer verwendet werden dürfen. Dort wo die Anweisungen erst mit Wissen konkretisiert werden müssen („Wer ist Wettbewerber?“) und wo die Nutzer uns immer wieder an die Grenzen unserer Befugnisse führen.
Das ist nur teilweise durch besseres Prompting zu lösen und das müssen wir vor allem erst einmal merken. Wir brauchen Techniken, die LLMs monitoren, in die Blackbox schauen und uns vor ihren Fehlern warnen.
Klaus Reichenberger
Marian Rahm
Marian studied computer science in Stuttgart and Darmstadt with a focus on ML and NLP. His professional experience includes the development and evaluation of various ML systems in the automotive industry, knowledge management and the healthcare sector.
