Warum kluge KI-Assistenten trotzdem falsche Antworten geben: ein Blick auf die Pipeline

Heutige KI-Assistenten schreiben Code, verdichten Dokumente, werten Daten aus und beantworten knifflige Fragen in Sekunden, und das in einem Ton, der echtes Wissen nahelegt. Dann behauptet einer von ihnen hin und wieder etwas schlicht Falsches. Eine erfundene Bibliotheksfunktion. Ein Zitat, das auf ein Paper verweist, das niemand geschrieben hat. Eine Erstattungsregel, die der eigenen Dokumentation des Unternehmens widerspricht. Wer einen Assistenten länger als ein paar Wochen gebaut oder genutzt hat, kennt das, und ärgerlich ist nicht der Fehler selbst. Ärgerlich ist die völlige Selbstsicherheit, mit der er daherkommt.

Das führt zu einem seltsamen Paradox.

More intelligence ≠ Perfect accuracy

Um es aufzulösen, muss man die Vorstellung aufgeben, ein Assistent sei ein einzelnes Gehirn, das einen Fakt entweder kennt oder nicht. In der Praxis ist er eine Pipeline, eine Abfolge von Stufen, von denen jede unbemerkt Fehler einschleusen kann.

User Question
      ↓
Query Understanding
      ↓
Retrieval System (RAG)
      ↓
Context Selection
      ↓
LLM Generation
      ↓
Final Answer

Ein Fehler in nur einer Stufe kann die endgültige Antwort ruinieren, selbst wenn jede andere Stufe perfekt lief. Verfolgt man die ganze Kette, sieht man, wo es schiefgeht und was sich gegen jeden einzelnen Fehler tun lässt.

Klug ist nicht dasselbe wie korrekt

Jedes Team, das ein KI-Produkt ausliefert, stößt irgendwann auf dieselbe Spannung. Das Modell ist wirklich leistungsfähig. Es hat aus riesigen Datensätzen gelernt, denkt Schritt für Schritt, schreibt funktionierende Programme und verarbeitet dichte Forschungsarbeiten. Nichts davon verspricht eine korrekte Antwort auf eine bestimmte Frage zu einem bestimmten Zeitpunkt.

Der Grund ist, dass Intelligenz und Genauigkeit verschiedene Eigenschaften sind. Ein Modell kann hervorragend plausiblen, gut gegliederten, menschlich klingenden Text erzeugen und sich dabei in einem Fakt irren. Diese Lücke erklärt Halluzinationen, Retrieval-Fehler und Kontextprobleme gleichermaßen.

Vorhersage ohne Überprüfung

Das Wichtigste zum Verinnerlichen: Ein großes Sprachmodell kennt Fakten nicht so, wie ein Mensch sie kennt. Seine Aufgabe ist, immer wieder das wahrscheinlichste nächste Token vorherzusagen, auf Grundlage von Mustern, die es im Training aufgenommen hat. Es gibt keinen internen Faktenprüfer und keine Pause, in der das Modell innehält, um nachzuprüfen. Es ist Mustervervollständigung im großen Maßstab.

Question:
Who invented XYZ technology?

AI:
Generates the most probable answer.

Problem:
Probability is not always truth.

Enthielten die Trainingsdaten starke und konsistente Muster zu einem Thema, ist die wahrscheinlichste Antwort meist richtig. Ist ein Thema obskur, mehrdeutig oder dünn in den Daten vertreten, können „wahrscheinlich“ und „wahr“ auseinanderdriften, und das Modell hat keine eingebaute Möglichkeit, das zu spüren.

Wie Halluzination aussieht

Halluzination ist das Wort für Ausgaben, die flüssig, selbstsicher und falsch sind. Es ist keine Lüge, denn das Modell ahnt nicht, dass es falsch liegt. Es vervollständigt einfach ein Muster, wenn keine fundierte Information vorliegt. Typische Formen sind:

• Gefälschte Quellen: Zitate, Paper oder Quellen, die es nicht gibt.
• Falsche Fakten: Daten, Zahlen oder Namen, die leicht oder völlig daneben liegen.
• Fehlerhafter Code: Snippets, die richtig aussehen, aber nicht kompilieren oder das Problem nicht lösen.
• Erfundene APIs: Funktionen, Parameter oder ganze Bibliotheken, die nie existiert haben.

Der übliche Ablauf ist einfach.

Missing Information
      ↓
Model Attempts Prediction
      ↓
Confident But Incorrect Output

Gefährlich macht sie die Selbstsicherheit. Ein halluzinierendes Modell schränkt selten ein und liefert die falsche Antwort mit derselben Stimme wie eine richtige.

Der Engpass Kontextfenster

Neben Lücken in den Trainingsdaten entsteht ein zweites praktisches Problem durch Kontextfenster. Ein LLM sieht nur, was sich in seinem Kontext befindet, wenn es eine Antwort erzeugt. Bei einem langen Dokument schafft es meist nur ein Teil hinein.

Large Document
      ↓
Only Selected Context
      ↓
LLM
      ↓
Answer

Wird der Absatz, der die Frage des Nutzers beantwortet, nie ausgewählt, kann das Modell ihn nicht verwenden, egal wie klug es ist. Das ist ein Problem von Retrieval und Auswahl, nicht vom Schlussfolgern, und es gehört in echten Systemen zu den häufigsten Ursachen falscher Antworten.

RAG hilft, bringt aber neue Fehlerquellen

Retrieval-Augmented Generation (RAG) setzt beim Problem an, dass eine KI deine Daten nicht kennt. Relevante Dokumente werden aus einer Wissensbasis geholt, dem Modell als Kontext übergeben, und die Antwort stützt sich auf sie. Das verbessert die Genauigkeit wirklich, beseitigt Fehler aber nicht, weil es neue Arten des Scheiterns mitbringt:

• Schlechtes Chunking. Werden Dokumente für die Speicherung zerlegt, kann sich eine Schlüsselinformation vom Kontext lösen, der ihr Bedeutung gibt. Ein Satz wie „dies gilt nur für Jahrestarife“ kann in einem anderen Chunk landen als die Regel, die er einschränkt.
• Ähnliche, aber falsche Treffer. Retrieval liefert Dokumente, die der Anfrage ähneln, und das sind nicht unbedingt die, die sie beantworten. Richtiges Thema, falsche Details.
• Veraltete Daten. Ein Vektorspeicher ist nur so aktuell wie sein letztes Update. Hat sich die Erstattungsregel letzten Monat geändert und wurden die Embeddings nicht neu erzeugt, zitiert der Assistent selbstsicher die alte Regel.
• Zu viel Kontext. Zur Sicherheit zusätzliche Dokumente zu holen, kann nach hinten losgehen. Ist der Prompt vollgestopft, geht das relevante Material im Rauschen unter, und das Modell verliert aus dem Blick, was zählt.

Ähnlichkeit ist nicht Korrektheit

Vektorsuche treibt das meiste RAG-Retrieval an. Eine Anfrage wird in ein Embedding verwandelt, und das System sucht nach Dokumenten, deren Embeddings am nächsten liegen.

User Query

"refund for yearly subscription"

        ↓

Embedding

        ↓

Similar Documents Retrieved

Darin, thematisch verwandtes Material zu finden, ist das hervorragend. Der Haken: Ähnlichkeit ist nicht gleich Korrektheit. Eine Seite über Erstattungen für Monatsabos kann im Embedding-Raum sehr nahe an einer Frage zu Erstattungen für Jahresabos liegen: gleiches allgemeines Thema, andere Antwort. Das Retrieval hat seine Aufgabe erfüllt und etwas Ähnliches gefunden, und trotzdem ist es das falsche Dokument.

Auch die Generierung kann scheitern

Ein korrekter Retrieval-Schritt ist notwendig, garantiert aber keine korrekte Antwort. Sobald die richtigen Passagen im Prompt stehen, muss das Modell sie noch richtig lesen, gewichten und eine treue Antwort formulieren, und jeder dieser Schritte hat seine eigenen Arten, danebenzugehen.

Selbst wenn das Retrieval fehlerfrei arbeitet und die richtigen Fakten im Kontext ankommen, hat der Generierungsschritt eigene Fallstricke:

• Mehrdeutige Prompts, die mehrere Lesarten zulassen.
• Widersprüchlicher Kontext, bei dem sich abgerufene Dokumente gegenseitig widersprechen.
• Fehlende Anweisungen zum Umgang mit Unsicherheit oder Konflikten.
• Grenzen des Modells, vor allem Lücken im Schlussfolgern bei langem oder unordentlichem Kontext.

So verdirbt widersprüchlicher Kontext eine ansonsten solide Pipeline:

Retrieved Data:

Document A:
Refund allowed within 30 days.

Document B:
Refund allowed within 14 days.

      ↓

AI must decide.

      ↓

Possible incorrect answer.

Das Retrieval hat nichts falsch gemacht, denn beide Dokumente waren berechtigterweise relevant. Ohne eine ausdrückliche Regel zum Auflösen von Widersprüchen, etwa das zuletzt aktualisierte Dokument zu bevorzugen oder den Konflikt zu melden, statt zu raten, muss das Modell wählen, und es kann falsch wählen.

Zuverlässigkeit gezielt konstruieren

Nichts davon macht RAG oder LLMs von Natur aus unzuverlässig. Es bedeutet, dass Zuverlässigkeit bewusst gebaut werden muss. Einige Hebel bewirken am meisten.

Besseres Retrieval:

• Hybride Suche kombiniert Schlüsselwortsuche mit Vektorsuche und erfasst exakte Begriffe wie Produktnamen, Fehlercodes und Regelnummern, die rein semantische Ähnlichkeit übersieht.
• Reranking lässt ein Modell in einem zweiten Durchgang die Ergebnisse nach tatsächlicher Relevanz für die Anfrage neu ordnen, nicht nur nach Embedding-Abstand.
• Metadatenfilter grenzen die Kandidaten über strukturierte Felder wie Datum, Dokumenttyp oder Produktstufe ein, bevor die Ähnlichkeitssuche überhaupt beginnt.

Klare Anweisungen an das Modell. Ausdrückliche Vorgaben reduzieren Halluzinationen erheblich:

Answer only using the provided context.
If the information is not available in the context, say you don't know.

Kleine Regeln wie diese ändern das Standardverhalten des Modells von „immer eine Antwort liefern“ zu „nur antworten, wenn es eine Grundlage gibt“, und genau das ist oft gewünscht.

Messung. Was nicht gemessen wird, lässt sich nicht beheben, deshalb verfolgen solide Systeme Treue (passt die Antwort zum abgerufenen Kontext?), Genauigkeit (ist sie sachlich richtig?) und Retrieval-Qualität (wurden überhaupt die richtigen Dokumente geholt?).

Feedbackschleifen. Korrekturen von Nutzern gehören zu den stärksten verfügbaren Signalen. Daumen-runter-Klicks, Korrekturprotokolle und Support-Eskalationen gehören in das Tuning des Retrievals, die Chunking-Entscheidungen und das Prompt-Design, statt in einem Log zu liegen, das niemand liest.

Nicht nach dem Ton urteilen

Support-Teams bemerken das oft als Erste: Ein Nutzer beschwert sich über eine falsche Antwort, doch das Transkript liest sich wunderbar. Politur verdeckt Fehler, weshalb ein menschlicher Blick auf ein paar Antworten ein schlechter Ersatz dafür ist, Ergebnisse über die Zeit zu verfolgen.

Viele Teams tappen in eine Falle: Ein Chatbot, der gut klingt, ist nicht unbedingt genau. Flüssige, selbstsichere, schön formatierte Antworten erzeugen ein falsches Gefühl von Zuverlässigkeit. Echte Evaluation stützt sich auf Zahlen, nicht auf Eindrücke:

• Retrieval-Genauigkeit: Werden für eine gegebene Anfrage die richtigen Dokumente gefunden?
• Antwortrelevanz: Geht die Antwort auf das Gefragte ein?
• Halluzinationsrate: Wie oft erzeugt das System Behauptungen ohne Grundlage?
• Nutzerzufriedenheit: Bekommen die Leute einen Nutzen oder nur höfliche Nicht-Antworten?

Ohne diese Kennzahlen optimieren Teams am Ende Ton und Flüssigkeit statt Korrektheit, und genau so gelangen selbstsicher falsche Assistenten in die Produktion.

Die nächste Herausforderung ist Zuverlässigkeit

Die nächste Hürde für KI ist nicht, Modelle klüger zu machen, denn die Intelligenz der Modelle hat die Fähigkeit der meisten Systeme, sie zuverlässig zu nutzen, bereits überholt. Die eigentliche Aufgabe ist, KI zuverlässiger zu machen: fundiert, überprüfbar und offen darüber, was sie nicht weiß. Kein einzelner Durchbruch liefert das. Es entsteht durch übereinandergelegte Schichten, von denen jede eine andere Fehlerquelle in der Pipeline abdeckt.

Better Models

+

Better Data

+

Better Retrieval

+

Better Evaluation

=

Reliable AI Assistants

Jede falsche Antwort, die ein Assistent gegeben hat, lässt sich auf eine Lücke in einer dieser Schichten zurückführen, nicht auf einen Mangel an Intelligenz. Herauszufinden, welche Schicht versagt hat, ist der erste Schritt zur Behebung.