Das Wissen ist da — nur nicht in der KI
Ein Anlagenbauer mit 120 Mitarbeitern hat ueber zwei Jahrzehnte einen beachtlichen Wissensschatz angesammelt: Wartungshandbuecher, Projektdokumentationen, interne Richtlinien, tausende beantwortete Support-Tickets. Als das Unternehmen einen KI-Assistenten fuer den Kundendienst testet, folgt die Ernuechterung prompt. Auf die Frage nach dem Wartungsintervall der eigenen Baureihe antwortet das Modell wortreich, plausibel — und falsch. Kein Wunder: Das Sprachmodell wurde auf oeffentlich verfuegbaren Texten trainiert. Die Interna des Anlagenbauers hat es nie gesehen, und was nach dem Trainingszeitpunkt passiert ist, kennt es ebenfalls nicht. Schlimmer noch: Statt Unwissen einzugestehen, erfinden Modelle in solchen Luecken gern ueberzeugend klingende Antworten — das bekannte Halluzinationsproblem.
Die naheliegende Frage lautet also: Wie bekommt man das eigene Wissen in die KI? Die Antwort, die sich in der Praxis durchgesetzt hat, heisst Retrieval Augmented Generation, kurz RAG — auf Deutsch etwa: durch Abruf angereicherte Generierung. Die Idee ist ueberraschend einfach: Man trainiert das Modell nicht um, sondern gibt ihm zur Antwortzeit genau die Dokumentpassagen mit, die zur Frage passen. Das Modell muss die Fakten dann nicht mehr wissen, sondern nur noch lesen und formulieren. Wie das technisch funktioniert und worauf es beim Aufbau ankommt, ist Thema dieses Beitrags.
Warum nicht einfach alles in den Prompt?
Der erste Reflex liegt nahe: Wenn das Modell die Dokumente lesen soll, warum nicht einfach alle Dokumente in jede Anfrage packen? Moderne Modelle verarbeiten schliesslich beeindruckend grosse Kontextfenster. Drei Gruende sprechen dagegen.
Erstens die schiere Menge: Das Kontextfenster eines Modells ist begrenzt, und die gesammelte Dokumentation eines Unternehmens ueberschreitet diese Grenze in aller Regel um ein Vielfaches. Zweitens die Kosten: Abgerechnet wird pro Token, und wer bei jeder einzelnen Frage hunderte Seiten mitschickt, bezahlt hunderte Seiten — bei jeder Frage aufs Neue, dazu mit spuerbar laengeren Antwortzeiten. Drittens, und das wird oft unterschaetzt, die Qualitaet: Modelle werden nachweislich schlechter darin, die relevante Information zu finden, wenn sie in einem Ozean aus irrelevantem Text schwimmt. Eine praezise Frage mit den fuenf wirklich passenden Absaetzen liefert bessere Antworten als dieselbe Frage mit fuenfhundert Seiten Beifang.
Die Kunst besteht also darin, zu jeder Frage automatisch die passenden Passagen zu finden. Genau dieser Abruf-Schritt — das Retrieval — ist das Herzstueck von RAG.
Embeddings: Bedeutung als Zahlenreihe
Klassische Volltextsuche findet Dokumente, die dieselben Woerter enthalten wie die Suchanfrage. Das reicht nicht, wenn der Kunde nach der "Maschine, die staendig piept" fragt, waehrend im Handbuch von "akustischem Warnsignal" die Rede ist. Gebraucht wird eine Suche nach Bedeutung, nicht nach Buchstaben — und dafuer gibt es Embeddings.
Ein Embedding-Modell verwandelt einen Text in einen Vektor: eine lange Reihe von Zahlen, oft mehrere hundert oder tausend Dimensionen, die die Bedeutung des Textes in einem mathematischen Raum verortet. Das Entscheidende an dieser Darstellung: Texte mit aehnlicher Bedeutung landen an benachbarten Punkten dieses Raums, auch wenn sie voellig unterschiedliche Woerter verwenden. "Akustisches Warnsignal" und "die Maschine piept" liegen dicht beieinander; das Kuchenrezept liegt weit entfernt. Aehnlichkeit laesst sich damit berechnen — ueblicherweise ueber den Winkel zwischen zwei Vektoren, die sogenannte Kosinus-Aehnlichkeit.
Fuer die Speicherung und Durchsuchung dieser Vektoren gibt es spezialisierte Systeme: Vektor-Datenbanken. Sie beherrschen die Kernoperation der semantischen Suche — nimm den Vektor der Frage und finde blitzschnell die Vektoren mit dem geringsten Abstand, selbst unter Millionen Eintraegen. Der Markt reicht von spezialisierten Produkten bis zu Erweiterungen etablierter Datenbanken wie PostgreSQL mit pgvector; fuer viele Mittelstandsprojekte ist Letzteres voellig ausreichend und haelt die Systemlandschaft schlank.
Bei der Wahl des Embedding-Modells lohnt ein zweiter Blick, gerade fuer deutschsprachige Inhalte: Nicht jedes Modell wurde gleichermassen auf mehrsprachigen Texten trainiert, und ein Modell, das englische Bedeutungen fein aufloest, kann bei deutschen Fachbegriffen deutlich schwaecher abschneiden. Ein Praxistest mit eigenen Dokumenten sagt hier mehr als jedes Ranking. Und eine technische Regel ist unverhandelbar: Fuer die Indexierung der Dokumente und fuer die spaeteren Suchanfragen muss dasselbe Embedding-Modell verwendet werden — Vektoren verschiedener Modelle leben in verschiedenen Raeumen und sind schlicht nicht vergleichbar. Ein Wechsel des Modells bedeutet deshalb immer, den gesamten Bestand neu zu indexieren.
Chunking, Hybrid Search und Reranking: die Qualitaetsstellschrauben
Bevor Dokumente in die Vektor-Datenbank wandern, muessen sie zerlegt werden — das sogenannte Chunking. Ein komplettes Handbuch als ein einziger Vektor waere viel zu grob: Der Vektor wuerde die Bedeutung von hundert Themen zu einem nichtssagenden Durchschnitt verschmieren. Ein einzelner Satz als Chunk waere zu fein, weil ihm der Zusammenhang fehlt. In der Praxis haben sich Abschnitte von einigen hundert Token bewaehrt, idealerweise entlang der natuerlichen Dokumentstruktur — Kapitel, Abschnitte, Absaetze — statt stur nach Zeichenzahl. Ueblich ist zudem eine Ueberlappung benachbarter Chunks um einen kleinen Anteil, damit Informationen, die genau auf einer Schnittgrenze liegen, nicht verloren gehen. Ein Satz, der am Ende von Chunk drei beginnt und in Chunk vier endet, bleibt durch die Ueberlappung in mindestens einem der beiden vollstaendig erhalten.
Die reine Vektorsuche hat allerdings eine Schwaeche, die in Unternehmensdaten haeufig zuschlaegt: exakte Bezeichner. Artikelnummern, Fehlercodes, Produktnamen wie "XR-4400" tragen kaum semantische Bedeutung — genau hier glaenzt die klassische Stichwortsuche, typischerweise mit dem bewaehrten Ranking-Verfahren BM25. Die Loesung ist kein Entweder-oder, sondern die Hybrid Search: Beide Suchverfahren laufen parallel, ihre Ergebnisse werden zu einer gemeinsamen Rangliste verschmolzen. Die Vektorsuche faengt die Umschreibungen und Synonyme, die Stichwortsuche die exakten Codes und Namen.
Eine weitere Stufe hebt die Qualitaet noch einmal deutlich: das Reranking. Die erste Suchrunde ist auf Geschwindigkeit optimiert und liefert vielleicht die besten dreissig Kandidaten. Ein Reranker — ein spezialisiertes Modell, das Frage und Textpassage gemeinsam liest und deren Passung deutlich genauer bewertet — sortiert diese Kandidaten anschliessend neu, sodass nur die wirklich besten fuenf bis zehn Passagen an das Sprachmodell gehen. Dieses zweistufige Vorgehen, grob suchen und fein nachsortieren, ist einer der wirksamsten Hebel, wenn ein RAG-System zwar irgendwas findet, aber zu oft das Falsche.
Der typische Aufbau: Chat mit den eigenen Dokumenten
Setzt man die Bausteine zusammen, ergibt sich der klassische Aufbau eines "Chat mit deinen Dokumenten"-Systems. Er besteht aus zwei getrennten Prozessen.
Der erste laeuft im Hintergrund: die Aufbereitung. Dokumente werden aus ihren Quellen eingesammelt — Dateiablage, Wiki, Ticketsystem —, von Formatballast befreit, in Chunks zerlegt, per Embedding-Modell in Vektoren verwandelt und zusammen mit Metadaten wie Quelle, Datum und Zugriffsrechten in der Vektor-Datenbank abgelegt. Dieser Prozess muss wiederholbar sein, denn Dokumentation veraendert sich; ein RAG-System ist nur so aktuell wie sein letzter Indexlauf.
Der zweite Prozess laeuft bei jeder Frage: Die Nutzerfrage wird mit demselben Embedding-Modell in einen Vektor verwandelt, die Hybrid Search liefert Kandidaten, das Reranking sortiert sie, und die besten Passagen werden zusammen mit der Frage in den Prompt des Sprachmodells gesetzt — mit einer klaren Anweisung: Beantworte die Frage ausschliesslich auf Basis der beigefuegten Auszuege, nenne die Quellen, und wenn die Auszuege die Antwort nicht hergeben, sag das offen. Gerade dieser letzte Halbsatz unterscheidet ein vertrauenswuerdiges System von einem gefaehrlichen: Ein gutes RAG-System antwortet auf manche Fragen mit einem ehrlichen "dazu finde ich in den Unterlagen nichts", statt zu fabulieren. Die Quellenangaben wiederum machen jede Antwort nachpruefbar — beim Anlagenbauer aus dem Eingangsbeispiel klickt der Servicemitarbeiter direkt in das zitierte Handbuchkapitel und verifiziert die Angabe in Sekunden.
Zwei Punkte verdienen im Unternehmenskontext besondere Aufmerksamkeit. Zugriffsrechte: Wenn nicht jeder Mitarbeiter jedes Dokument sehen darf, muss das Retrieval die Berechtigungen des Fragenden respektieren und gesperrte Chunks herausfiltern, bevor sie im Prompt landen — nicht erst danach. Und Evaluierung: Ein kleines, gepflegtes Set aus echten Fragen mit bekannten Soll-Antworten macht messbar, ob eine Aenderung an Chunking, Suche oder Prompt das System besser oder schlechter macht. Ohne diese Messlatte wird jede Optimierung zum Stochern im Nebel.
RAG oder Fine-Tuning?
Regelmaessig taucht die Frage auf, ob man das Modell nicht besser gleich auf die eigenen Daten nachtrainieren sollte — das sogenannte Fine-Tuning. Die beiden Ansaetze loesen jedoch unterschiedliche Probleme. Fine-Tuning veraendert das Verhalten eines Modells: Stil, Tonalitaet, das Befolgen spezieller Formate, die Sicherheit in einer Fachdomaene. Als Wissensspeicher taugt es dagegen schlecht: Neues Wissen einzutrainieren ist teuer, muss bei jeder Aenderung wiederholt werden, laesst sich nicht mit Quellen belegen und schuetzt nicht zuverlaessig vor Halluzinationen. Fuer aktuelles, sich aenderndes Firmenwissen ist RAG fast immer die richtige Wahl: Ein neues Dokument ist nach dem naechsten Indexlauf verfuegbar, ein veraltetes verschwindet, und jede Antwort traegt ihre Belege bei sich. In manchen Projekten ergaenzen sich beide — ein leicht nachtrainiertes Modell fuer Ton und Fachsprache, RAG fuer die Fakten —, aber die Reihenfolge ist klar: erst RAG sauber aufbauen, Fine-Tuning nur bei nachgewiesenem Bedarf.
Fazit: Klein starten, ehrlich messen
RAG ist der pragmatische Weg, Sprachmodelle mit dem Wissen zu verbinden, das sie nie gelernt haben: Embeddings machen Bedeutung durchsuchbar, die Vektor-Datenbank findet die passenden Passagen, Chunking, Hybrid Search und Reranking bestimmen die Qualitaet des Gefundenen, und das Sprachmodell formuliert daraus eine belegte Antwort. Kein Schritt davon ist Magie — aber jeder ist eine Stellschraube, an der ein System gewinnt oder verliert.
Drei naechste Schritte fuer den Einstieg: Waehlen Sie einen eng umrissenen Wissensbereich mit hohem Frageaufkommen — etwa die Produktdokumentation fuer den Support — statt gleich das ganze Unternehmenswissen anzugehen. Stellen Sie zwanzig echte Fragen aus dem Alltag zusammen und halten Sie fest, wo die richtigen Antworten stehen; das wird Ihre Messlatte. Und bauen Sie damit einen kleinen Piloten, den die kuenftigen Nutzer zwei Wochen lang ehrlich testen, bevor ueber den Ausbau entschieden wird. FJ Design unterstuetzt Unternehmen beim Aufbau solcher RAG-Systeme — von der Datenaufbereitung bis zum produktiven Betrieb.