KI-Engineering · Tag 3: RAG statt Halluzination

Willkommen zu Tag 3 unserer Serie KI-Engineering. In Tag 2 haben wir den richtigen Use-Case gewählt – heute geht es um das Problem, das jedes ernsthafte KI-Projekt früher oder später einholt: Das Sprachmodell erfindet Dinge. Es antwortet selbstbewusst, klingt kompetent und liegt trotzdem falsch. Genau hier setzt RAG an, kurz für Retrieval-Augmented Generation. Statt das Modell aus dem Gedächtnis raten zu lassen, geben wir ihm zur Laufzeit die richtigen Dokumente in die Hand – und lassen es nur auf Basis dieser Fakten antworten. In diesem Beitrag zeigen wir, wie RAG technisch funktioniert, warum es Halluzinationen spürbar reduziert, welche Fehler wir in echten Projekten immer wieder sehen und wann RAG die bessere Wahl ist als teures Fine-Tuning.

Warum Sprachmodelle halluzinieren

Ein großes Sprachmodell ist im Kern eine Wahrscheinlichkeitsmaschine. Es sagt das nächste Wort voraus, basierend auf Mustern aus seinen Trainingsdaten. Das ist erstaunlich mächtig – aber es hat keine Ahnung, was gerade wahr ist. Das Modell kennt deine interne Wissensdatenbank nicht, deine Preisliste von letzter Woche nicht und die Vertragsklausel deines Kunden erst recht nicht. Wenn du fragst, antwortet es trotzdem, weil es darauf trainiert wurde, hilfreich zu klingen. Diese Mischung aus fehlendem Faktenwissen und dem Zwang, immer eine Antwort zu produzieren, erzeugt Halluzinationen.

Der entscheidende Punkt: Das Problem lässt sich nicht durch bessere Prompts allein lösen. Du kannst noch so höflich bitten „erfinde nichts“ – wenn das Modell die Information schlicht nicht hat, bleibt ihm nur Raten oder Verweigern. Die eigentliche Lösung ist, dem Modell die fehlende Information zur Antwortzeit mitzuliefern. Das ist die Grundidee hinter RAG.

Die Kernidee in einem Satz

RAG bedeutet: Bevor das Modell antwortet, suchen wir in deinen eigenen Daten nach den relevantesten Textstellen und fügen sie dem Prompt als Kontext hinzu. Das Modell generiert seine Antwort dann nicht aus dem Gedächtnis, sondern aus den mitgelieferten Belegen. Aus „Was weißt du über X?“ wird „Hier sind fünf relevante Ausschnitte, beantworte X ausschließlich damit und nenne die Quelle.“ Der Unterschied in der Antwortqualität ist dramatisch.

Wie RAG technisch funktioniert – die Bausteine

Ein RAG-System besteht aus mehreren Schritten, die sauber ineinandergreifen müssen. Wenn einer davon schwächelt, leidet die ganze Kette. Gehen wir sie der Reihe nach durch.

1. Chunking – Dokumente in verdauliche Häppchen

Deine Wissensbasis besteht selten aus perfekt kurzen Absätzen. Handbücher, PDFs, Confluence-Seiten, Support-Tickets – das sind oft lange Dokumente. Ein Sprachmodell kann aber nur eine begrenzte Menge Kontext verarbeiten, und die Vektor-Suche wird ungenau, wenn ein Textblock zu viele Themen mischt. Deshalb zerlegen wir Dokumente in Chunks, also inhaltlich zusammenhängende Abschnitte von typischerweise 200 bis 500 Tokens.

Gutes Chunking respektiert die Struktur des Dokuments: Es schneidet an Überschriften, Absätzen oder Sinnabschnitten – nicht mitten im Satz. Ein bewährter Trick ist ein leichter Überlappungsbereich zwischen benachbarten Chunks, damit ein Gedanke, der über eine Grenze hinausgeht, nicht zerrissen wird. Chunking klingt banal, entscheidet aber mehr über die Qualität eines RAG-Systems als fast jeder andere Schritt.

2. Embeddings – Bedeutung als Zahlen

Jeder Chunk wird durch ein Embedding-Modell in einen Vektor umgewandelt – eine lange Liste von Zahlen, die die Bedeutung des Textes im mathematischen Raum abbildet. Texte mit ähnlicher Bedeutung liegen in diesem Raum nah beieinander, auch wenn sie ganz andere Wörter verwenden. „Wie setze ich mein Passwort zurück?“ und „Zugangsdaten erneuern“ landen dicht beisammen, obwohl sie kein einziges Wort teilen. Genau das macht die semantische Suche so viel stärker als eine reine Stichwortsuche.

3. Vektor-Suche – den richtigen Kontext finden

Alle Chunk-Vektoren speichern wir in einer Vektor-Datenbank. Kommt eine Nutzerfrage herein, wandeln wir auch sie in einen Vektor um und suchen die ähnlichsten Chunks – meist die besten drei bis zehn. Das ist der „Retrieval“-Teil von RAG. Die Qualität dieser Suche bestimmt, ob das Modell überhaupt eine Chance hat, richtig zu antworten. Findet die Suche irrelevante Chunks, bekommt das Modell falschen Kontext und produziert eine falsche Antwort, die obendrein mit Quellen belegt aussieht – das Schlimmste, was passieren kann.

In der Praxis kombinieren wir oft semantische Suche mit klassischer Stichwortsuche zu einer hybriden Suche. Semantik ist gut bei Umschreibungen, Stichwörter sind gut bei Produktnamen, Fehlercodes und Eigennamen. Zusammen decken sie mehr Fälle ab. Ein nachgelagertes Reranking sortiert die Treffer nochmals nach echter Relevanz, bevor sie ins Modell gehen.

4. Kontext-Zusammenbau und Generierung

Die gefundenen Chunks fügen wir zusammen mit der ursprünglichen Frage in einen strukturierten Prompt. Die Anweisung an das Modell lautet sinngemäß: Beantworte die Frage ausschließlich mit dem folgenden Kontext. Wenn die Antwort nicht im Kontext steht, sage das ehrlich. Genau diese letzte Regel ist Gold wert – sie gibt dem Modell die Erlaubnis, „ich weiß es nicht“ zu sagen, statt zu erfinden.

5. Zitate und Quellenangaben

Ein professionelles RAG-System liefert nicht nur eine Antwort, sondern auch die Belege dazu: Aus welchem Dokument, welchem Abschnitt stammt die Aussage? Das erfüllt zwei Zwecke. Erstens kann der Nutzer die Antwort selbst prüfen und gewinnt Vertrauen. Zweitens schaffst du dir als Betreiber eine Feedback-Schleife: Wenn Antworten falsch sind, siehst du sofort, ob die Retrieval-Stufe die falschen Quellen gezogen hat oder ob die Quelldaten selbst fehlerhaft waren. Ohne Quellenangaben debuggst du im Dunkeln.

Ein konkretes Praxisbeispiel

Nehmen wir einen Fall aus unserer Arbeit: Ein mittelständischer Maschinenbauer wollte einen internen Assistenten, der Servicetechnikern im Feld Fragen zu Wartungsprozeduren beantwortet. Die Wissensbasis: rund 1.800 PDF-Seiten technische Handbücher, teils zehn Jahre alt, teils in Tabellenform, teils mit Warnhinweisen, bei denen ein Fehler echte Sicherheitsrisiken bedeutet.

Der erste naive Versuch – die Handbücher grob in große Blöcke schneiden und einfach ins Modell schieben – lieferte gefährlichen Mist. Auf die Frage nach dem Anzugsmoment einer bestimmten Schraube antwortete das System mit einer plausibel klingenden Zahl, die aber aus dem Handbuch eines anderen Maschinentyps stammte. Genau die Art Halluzination, die im Feld jemanden verletzen kann.

Die Lösung war methodisch, nicht magisch. Wir haben erstens die Chunks an den Kapitel- und Tabellengrenzen ausgerichtet und jedem Chunk Metadaten mitgegeben: Maschinentyp, Baujahr, Kapitel. Zweitens haben wir die Suche gefiltert, sodass nur Chunks des tatsächlich ausgewählten Maschinentyps überhaupt in Frage kamen. Drittens haben wir das Modell gezwungen, jede Zahl mit einer wörtlichen Quellenangabe zu belegen – kein Beleg, keine Zahl. Viertens: Wenn die Suche keinen passenden Chunk fand, antwortete das System nicht mit einer Vermutung, sondern verwies an den menschlichen Support. Das Ergebnis war ein Assistent, dem die Techniker vertrauten, weil er ehrlich zugab, wenn er etwas nicht wusste.

Typische Fehler, die RAG-Projekte ausbremsen

Über viele Projekte hinweg wiederholen sich dieselben Stolpersteine. Wer sie kennt, spart Wochen.

Schlechte Datenqualität

RAG macht deine Daten nicht besser – es macht sie sichtbar. Wenn deine Wissensbasis widersprüchliche, veraltete oder doppelte Dokumente enthält, zieht die Suche genau diese Widersprüche und das Modell antwortet mal so, mal so. Der erste Schritt in fast jedem RAG-Projekt ist deshalb kein KI-Schritt, sondern Datenhygiene: Duplikate entfernen, veraltete Stände archivieren, eine klare Quelle der Wahrheit definieren. „Garbage in, garbage out“ gilt in RAG doppelt.

Zu große oder zu kleine Chunks

Sind die Chunks zu groß, mischen sie mehrere Themen und die Vektor-Suche wird unscharf – der Treffer enthält dann viel Rauschen um die eigentliche Information. Sind sie zu klein, fehlt dem einzelnen Chunk der Kontext, um für sich allein verständlich zu sein. Die richtige Chunk-Größe ist kein universeller Wert, sondern hängt von deinen Dokumenten ab. Sie zu finden ist Handarbeit und Messarbeit, kein RateSpiel.

Fehlende Quellenangaben

Ein RAG-System ohne Quellen ist eine Blackbox, die du nicht verbessern kannst. Du weißt nie, ob eine falsche Antwort an der Suche oder an den Daten lag. Quellenangaben sind kein optionales Extra für die Optik – sie sind dein wichtigstes Debugging- und Vertrauensinstrument. Baue sie von Anfang an ein.

Keine Auswertung, kein Fortschritt

Viele Teams bauen ein RAG-System und beurteilen es nach Gefühl. Das führt nirgends hin. Du brauchst einen kleinen, festen Satz echter Fragen mit bekannten korrekten Antworten und misst regelmäßig: Wie oft findet die Suche den richtigen Chunk? Wie oft ist die Endantwort korrekt und belegt? Erst mit diesen Zahlen wird Verbesserung planbar statt zufällig.

RAG oder Fine-Tuning – wann was?

Eine der häufigsten Fragen, die uns Kunden stellen: Sollen wir das Modell nicht einfach auf unsere Daten trainieren? Meistens lautet die ehrliche Antwort: nein, zumindest nicht zuerst. RAG und Fine-Tuning lösen unterschiedliche Probleme, und sie zu verwechseln kostet viel Geld.

RAG ist die richtige Wahl, wenn dein Wissen faktisch ist, sich häufig ändert oder Quellennachweise verlangt. Preislisten, Handbücher, Richtlinien, Produktkataloge – all das lebt und ändert sich. Bei RAG aktualisierst du einfach die Datenbank, ohne ein Modell neu zu trainieren. Neue Information ist Sekunden später verfügbar. Und du bekommst Quellenangaben gratis dazu.

Fine-Tuning ist die richtige Wahl, wenn du nicht Fakten, sondern Verhalten ändern willst: einen bestimmten Tonfall, ein festes Ausgabeformat, eine Fachsprache, ein spezielles Klassifikationsverhalten. Fine-Tuning bringt dem Modell bei, wie es antwortet, nicht was es weiß. Es ist teurer, träger bei Änderungen und liefert keine Quellen. Für aktuelles Faktenwissen ist es fast immer das falsche Werkzeug – denn nach dem Training ist das Wissen eingefroren, und die nächste Preisänderung macht es wieder falsch.

In der Praxis ist die Antwort oft „beides, in dieser Reihenfolge“: Erst RAG bauen, um an aktuelle Fakten zu kommen, und später gezielt fine-tunen, wenn Ton oder Format nicht sitzen. Aber der Startpunkt für wissensbasierte KI ist praktisch immer RAG.

So gehst du vor

Wenn du ein RAG-System aufsetzen willst, hat sich diese Reihenfolge bewährt:

• Frage zuerst den Anwendungsfall: Welche konkreten Fragen soll das System beantworten? Sammle 30 bis 50 echte Beispielfragen mit korrekten Antworten. Das ist deine Messlatte.
• Räume die Daten auf: Definiere eine Quelle der Wahrheit, entferne Duplikate und veraltete Stände. Kein KI-Schritt ist so wichtig wie dieser.
• Baue eine einfache Pipeline: Chunking, Embeddings, Vektor-Datenbank, Retrieval, Prompt mit Quellenpflicht. Fang bewusst schlicht an, ohne exotische Optimierungen.
• Miss die Retrieval-Qualität separat: Prüfe zuerst, ob die Suche den richtigen Chunk findet – bevor du die Endantwort beurteilst. Ein schwaches Retrieval kann keine gute Generierung tragen.
• Erzwinge Quellenangaben und ein ehrliches „weiß ich nicht“: Beides senkt Halluzinationen sofort und macht das System debugbar.
• Iteriere an den Zahlen entlang: Verbessere Chunking, führe hybride Suche und Reranking ein, und miss nach jeder Änderung gegen deine Beispielfragen. Optimiere nur, was du messen kannst.

Widerstehe der Versuchung, mit dem kompliziertesten Setup zu starten. Die meisten Qualitätsgewinne kommen aus sauberen Daten, gutem Chunking und ehrlichem Umgang mit Wissenslücken – nicht aus dem neuesten Vektor-Datenbank-Feature.

Fazit

RAG ist keine Zauberei, sondern solides Engineering. Der Kern ist einfach: Gib dem Sprachmodell zur Antwortzeit die richtigen Fakten aus deinen eigenen Daten und zwinge es, nur damit zu arbeiten und die Quelle zu nennen. So verwandelst du eine plausibel klingende Ratemaschine in ein System, dem Menschen vertrauen, weil es belegt, was es sagt, und zugibt, was es nicht weiß. Halluzinationen verschwinden nicht vollständig, aber sie werden selten, sichtbar und beherrschbar. Für aktuelles, sich änderndes Faktenwissen ist RAG dem Fine-Tuning fast immer überlegen – schneller aktualisierbar, günstiger und von Haus aus nachvollziehbar.

Das war Tag 3 unserer Serie KI-Engineering. In der Serien-Übersicht findest du alle bisherigen Episoden und die kommenden Themen. Wenn du wissensbasierte KI nicht als Experiment, sondern als belastbares Produkt bauen willst, unterstützen wir dich dabei – von der Datenhygiene bis zum produktiven RAG-System. Erfahre mehr über unsere KI-Engineering-Leistungen oder nimm direkt Kontakt mit uns auf, und wir schauen uns deinen konkreten Anwendungsfall gemeinsam an.