Management statt Magie

Einleitung: Das unsichtbare Risiko

Halluzinationen – also Aussagen eines LLMs, die faktisch falsch sind – gehören zu den kritischsten Risiken beim Einsatz von generativer KI. (Zum Thema Vertrauen siehe auch meinen anderen Blogpost.)

Gerade RAG-Systeme (Retrieval Augmented Generation), die oft als Lösung gegen Halluzinationen angepriesen werden, bringen neue Fehlerquellen mit sich: Sie versprechen, Antworten auf Ihre eigenen, vertrauenswürdigen Daten zu stützen – können aber trotzdem gefährlich danebenliegen.

Die gute Nachricht: Halluzinationen sind kein Naturgesetz der Technologie. Sie sind in erster Linie ein Datenqualitäts- und Architekturproblem – und damit steuerbar.

Was sind Halluzinationen – und warum sind sie gefährlich?

Von einer Halluzination sprechen wir, wenn ein LLM Fakten generiert, die falsch sind, aber sehr selbstbewusst und überzeugend präsentiert werden. Anders als ein «normaler» Fehler sind Halluzinationen besonders heikel, weil sie:

• Plausibel klingen: Die Antwort passt scheinbar perfekt zur Frage und wirkt autoritär.
• Stilistisch korrekt sind: Formulierung, Tonalität und Format wirken professionell.
• Schwer erkennbar sind: Auch Expert*innen übersehen sie beim flüchtigen Lesen.
• Vertrauen missbrauchen: Nutzer*innen gehen davon aus, dass das System auf verifizierten Daten basiert.

Beispiele aus der Praxis gibt es zur Genüge – von erfundenen Quellen über falsche Gesetzesartikel bis zu frei ausgedachten Prozessschritten.

Wie entstehen Halluzinationen technisch?

Large Language Models (LLMs) funktionieren im Kern, indem sie das wahrscheinlichste nächste Wort basierend auf dem bisherigen Kontext vorhersagen. Das Modell ist darauf optimiert, eine Antwort zu liefern – nicht darauf, zu sagen: «Ich weiss es nicht.»

Das führt zu einem entscheidenden Problem:
Selbst wenn die zugrunde liegenden Informationen unvollständig oder gar nicht vorhanden sind, wird das Modell eine Antwort konstruieren. Genau dort entstehen Halluzinationen.

Um dem systematisch entgegenzuwirken, gibt es zwei grundlegende Strategien:

1. Kontext bereitstellen:
   Durch die Einbindung des richtigen, relevanten Kontexts (z.B. mittels RAG) erhöhen wir die Wahrscheinlichkeit, dass das Modell auf korrekte Informationen zugreift und damit die richtige Antwort erzeugt.

2. Out-of-Distribution / «Ich weiss es nicht» erkennen:
   Liegt eine Anfrage ausserhalb des Wissensbereichs, sollte das System dies erkennen und die Frage nicht beantworten, statt eine unsichere oder falsche Antwort zu erfinden.

RAG-Systeme: Versprechen und Realität

RAG-Systeme sollen genau dieses Problem adressieren. Die Idee:

1. Statt das LLM nur aus seinem «gelernten Weltwissen» antworten zu lassen,
2. sucht das System zuerst in einer (kundenspezifischen) Knowledge Base nach relevanten Informationen.
3. Basierend auf den gefundenen Dokumenten und dem Prompt formuliert das LLM dann die Antwort.

Gut gemachtes RAG kann Halluzinationen massiv reduzieren.
Schlecht gemachtes RAG fügt der Gleichung neue Fehlerquellen hinzu – und macht die Fehlersuche deutlich schwieriger.

Typische Fehlerquellen in RAG-Systemen

Problem 1: Das Retrieval versagt

Bevor das LLM überhaupt antwortet, müssen die relevanten Dokumente gefunden werden. Genau hier passieren oft die fundamentalsten Fehler:

Relevante Informationen werden nicht gefunden:

• Die Suchalgorithmen erkennen wichtige Dokumente nicht als relevant an.
• Wichtige Inhalte stecken in Tabellen, PDFs oder schlecht strukturierten Dateien und werden gar nicht oder nur teilweise erfasst.
• Der Kontext des LLMs wird mit unwichtigen Informationen geflutet und das wirklich Relevante geht unter.

Irrelevante oder veraltete Dokumente werden verwendet:

• Das System findet eine Medienmitteilung von 2019, die längst überholt ist.
• Widersprüchliche Informationen aus verschiedenen Quellen landen gleichzeitig im selben Kontext.

Domänenspezifische Besonderheiten werden nicht abgebildet:

• Embeddings repräsentieren zentrale Unterschiede der Domäne nicht.
  Beispiel: Auf einer Behörden-Website bedeutet «Anmelden» fast immer «Wohnsitz anmelden bei der Einwohnerkontrolle», nicht «zum Salsa-Kurs im Quartierzentrum anmelden».

Das Resultat: Das LLM baut auf falschem oder unvollständigem Kontext auf – und halluziniert selbstbewusst darauf los.

Problem 2: Der «Generation»-Schritt interpretiert falsch

Selbst wenn das Retrieval gut funktioniert und die richtigen Dokumente liefert, kann das LLM die Informationen noch falsch verarbeiten:

Falsche Interpretation:

• Das LLM versteht die Nuancen eines juristischen Textes nicht.
• Konditionale Aussagen («Wenn X, dann Y») werden zu absoluten Regeln.
• Ausnahmen werden ignoriert oder zu weit verallgemeinert.

Unzulässige Kombination von Informationen:

• Das LLM kombiniert Aussagen aus verschiedenen Dokumenten auf kreative, aber falsche Weise.
• Es «schliesst» von A auf B, obwohl dieser Schluss fachlich nicht zulässig ist.
• Es versucht, veraltete Informationen «intelligent» zu aktualisieren und liegt dabei daneben.

Lückenfüller aus dem Weltwissen:

• Das gefundene Dokument beantwortet die Frage nur teilweise.
• Das LLM ergänzt fehlende Teile aus seinem allgemeinen Weltwissen.
• Das Ergebnis ist eine Mischung aus verifizierten Fakten und frei Erfundenem.

Auf diesen Generationsschritt haben wir den wenigsten direkten Einfluss: Wir können nur das passende Modell wählen und den Prompt so gut wie möglich gestalten. Umso wichtiger ist alles, was davor und danach passiert.

Drei essenzielle Strategien zur Risikominimierung

Wenn Halluzinationen primär ein Architektur- und Datenqualitätsproblem sind, können wir sie auch systematisch bekämpfen. Drei Strategien sind aus unserer Erfahrung essenziell:

1. Datenqualität als Fundament

Ein RAG-System ist nur so gut wie die Daten, auf die es zugreift.
Der alte IT-Grundsatz gilt hier in Reinform: Garbage in, garbage out.

Wichtige Prinzipien:

• Quellen am tatsächlichen Bedarf ausrichten:
  Nicht alles, was im Intranet liegt, hilft bei echten Nutzer*innenfragen.
  Die Knowledge Base sollte sich an konkrete Use Cases orientieren und nicht an die Ordnerstruktur Ihrer Organisation.

• Dokumente mit zusätzlichem Kontext anreichern:
  Oft müssen Dokumente «verschnitten» (gechunked) werden, damit sie in ein LLM passen.
  Dabei geht leicht Kontext verloren, der muss explizit ergänzt werden (z.B. Metadaten, Überschriften, Gültigkeitsbereiche).

• Aktualität sicherstellen – Once Only:
  Informationen sollten, wo immer möglich, einmal zentral gepflegt werden.
  Kopien in verschiedenen Systemen machen es fast unmöglich, überall konsistent und aktuell zu bleiben.
  Für RAG-Systeme bedeutet das: klare «Single Sources of Truth», nicht fünf leicht unterschiedliche Versionen desselben Prozesses.

2. Fallback-Mechanismen und Unsicherheitslogik

Ein gutes System weiss, wann es nichts weiss und reagiert entsprechend.
Unser Grundsatz: Lieber ein konservatives „Ich kann Ihnen nicht helfen“ als eine erfundene Antwort.

In der Praxis heisst das:

• Unsicherheits-Schwellenwerte definieren:

  • Schwellen in verschiedenen Teilen des Retrievals (z.B. Vektordistanzen, Relevanzscores) festlegen.
  • Unterhalb dieser Schwellen: lieber keine Antwort, sondern ein transparenter Hinweis an die Nutzer*innen.

• Routing für kritische Themen:

  • Bestimmen, welche Themen «kritisch» sind (z.B. Steuern, Gesundheit, rechtliche Fragen – je nach Kunde unterschiedlich).
  • Für diese Themen definierte Fallbacks nutzen:
    z.B. „Ich kann Ihre Steuerbelastung nicht berechnen. Bitte nutzen Sie den offiziellen Steuerrechner.“

• Out-of-Scope klar markieren:

  • Wenn ein Thema ausserhalb des Wissensbereichs liegt, soll das System das deutlich sagen, statt mit Halbwissen zu antworten.

3. Nutzer:innen befähigen, nicht täuschen

Selbst wenn man Halluzinationen technisch minimieren könnte: Sprache bleibt mehrdeutig.
Beispiel: «Mein Hund brachte mir einen Ball. Ich kickte ihn.» – Wer oder was wurde gekickt? Sprache ist nie zu 100 % eindeutig. Ein (nicht ganz so ambivalentes) Beispiel aus der Praxis.

Das heisst: Niemals wird jede Frage zu 100 % «richtig» beantwortet werden. Deshalb gilt für uns:

a) Quellenangaben zu jeder Antwort

• Wir zeigen, aus welchen Dokumenten die Antwort stammt.
• Diese Dokumente sind direkt zugänglich und so präzise wie möglich verlinkt (Tabelle, Abschnitt, Paragraph).
• Wir machen transparent, wenn eine Antwort aus mehreren Quellen kombiniert wurde.

b) «Confidence Scores» sichtbar machen

• Wo möglich, kommunizieren wir – bisher noch relativ einfach – wie sicher das System ist.
• Langfristig möchten wir „Confidence Scores“ deutlich besser quantifizieren und darstellen.
  Bis dahin gilt: lieber einfache, ehrliche Indikatoren als falsche Präzision.

c) Ehrliche Disclaimer statt Marketing-Sprech

Die beste technische Lösung nützt nichts, wenn Nutzer*innen dem System blind vertrauen.

• Schreiben Sie klar in die UI: «Dieses System kann Fehler machen.»
• Erklären Sie, wofür das System geeignet ist und wofür nicht.
• Vermeiden Sie Marketing-Sprache, die überzogene Erwartungen weckt.
• Vermeiden Sie ebenso reines «cover your ass»-Juristendeutsch, das niemand liest.
  Ziel ist: verständliche, ehrliche Kommunikation.

Verantwortungsvolle AI ist machbar

Für mich gibt es drei zentrale Punkte:

1. Halluzinationen sind steuerbar:
   Sie sind nicht unausweichliches Schicksal, sondern Resultat von Datenqualität und Systemdesign. Beides liegt in Ihrer Hand.

2. Transparenz schlägt Perfektion:
   Sie werden Halluzinationen nie zu 100 % vermeiden.
   Aber Sie können Ihr System so gestalten, dass Nutzer*innen Fehler erkennen, einordnen und damit umgehen können.

3. Es ist auch ein Managementthema, kein reines Technikthema:
   Die wichtigsten Entscheidungen – Datenqualität, Prozesse, Verantwortlichkeiten – müssen Sie als Führungskraft treffen, nicht Ihr IT-Team allein.

Der Einsatz von RAG-Chatbots birgt Chancen und Risiken.
Wer die Risiken versteht und systematisch adressiert, kann die Chancen nutzen – verantwortungsvoll und sicher.