Ein Instandhalter sucht im Firmenlaufwerk nach „Vorschub bleibt stehen“. Die Volltextsuche findet nichts, weil im Handbuch der Fehlercode E42 steht und der Begriff Vorschub dort nicht vorkommt. Derselbe Mitarbeiter fragt einen Chat-Assistenten, der auf einem öffentlichen Modell läuft, und erhält eine plausible, aber erfundene Vorgehensweise mit einem Sicherheitshinweis, den es in dieser Form nicht gibt. Beide Systeme haben dasselbe Problem: Es fehlt der Weg von der Frage zur richtigen Textstelle im eigenen Bestand.
Retrieval-Augmented Generation, kurz RAG, ist der Versuch, diesen Weg technisch zu bauen. Der Ansatz ist heute Standard, aber die Qualität entscheidet sich nicht am Modell, sondern an der Aufbereitung der Dokumente und an der Suche davor.
Was RAG technisch tut
Ein RAG-System besteht aus mehreren Stufen, die unabhängig voneinander geprüft werden müssen:
- Zerlegen: Dokumente werden in Abschnitte von wenigen hundert Wörtern geteilt, oft als Chunks bezeichnet.
- Vektorisieren: Jeder Abschnitt wird in einen Zahlenvektor umgerechnet, der seine Bedeutung annähernd abbildet.
- Suchen: Zur Frage werden die ähnlichsten Abschnitte gesucht, üblicherweise die besten fünf bis zwanzig.
- Neu bewerten: Ein Reranker sortiert diese Treffer nach tatsächlicher Relevanz für die Frage.
- Antworten: Nur die ausgewählten Textstellen gehen zusammen mit der Frage an das Sprachmodell, das daraus eine Antwort mit Quellenverweis formuliert.
Wichtig ist die Reihenfolge: Das Modell sieht nicht die Firma, sondern einen kleinen, vorher ausgewählten Ausschnitt. Ist dieser Ausschnitt falsch, hilft das beste Modell nicht. Grundlagen zu dieser Architektur haben wir unter interne Wissensdatenbank beschrieben; hier geht es um die Details, an denen RAG-Projekte scheitern.
Warum Zerlegung und Metadaten entscheiden
Die Zerlegung ist der unterschätzteste Schritt. Ein Abschnitt, der mitten in einer Tabelle endet, verliert seinen Bezug. Eine Arbeitsanweisung, die über zwanzig Seiten läuft, ergibt Abschnitte, die einzeln missverständlich sind. Bewährt hat sich, an der Dokumentstruktur zu trennen: Überschriften, nummerierte Schritte, Tabellenzeilen und Bildunterschriften.
Dazu kommen Metadaten, die später filterbar sein müssen: Dokumenttyp, Produktgruppe, Maschinentyp, Version, Gültigkeitsdatum, Eigentümer und Schutzklasse. Ohne diese Angaben kann die Suche nicht eingrenzen und liefert Antworten aus dem falschen Anlagenbereich.
Für die Größe der Abschnitte gibt es keinen allgemein richtigen Wert. Zu kleine Abschnitte verlieren den Zusammenhang: Der Satz „vor dem Öffnen drucklos schalten“ ist allein nicht verständlich. Zu große Abschnitte enthalten viel Text, der mit der Frage nichts zu tun hat, und verdrängen die eigentlich passende Stelle. Ein brauchbarer Ausgangspunkt sind einige hundert Wörter mit Überlappung zwischen benachbarten Abschnitten; die endgültige Wahl ergibt sich aus Tests mit echten Fragen.
Ein zweites Thema ist die Textextraktion. Gescannte Lieferscheine, Zeichnungen als PDF und Tabellen in Graustufen liefern ohne Texterkennung keinen verwertbaren Inhalt. Wer hier spart, indexiert leere Seiten und wundert sich über fehlende Treffer.
Bei technischen Unterlagen kommen zwei Sonderfälle hinzu. Tabellen verlieren ihre Zuordnung, wenn die Kopfzeile im vorherigen Abschnitt bleibt; dann werden Zeilen dem falschen Feld zugeordnet. Zeichnungen und Schaltpläne enthalten kaum Fließtext, dafür Stücklisten und Positionsnummern, die häufig nur als Bild vorliegen. Solche Inhalte brauchen eine eigene Erkennung oder bleiben bewusst außen vor. Beides ist besser, als sie stillschweigend als leere Seite zu indexieren.
Hybride Suche statt nur Vektoren
Reine Vektorsuche ist stark bei umgangssprachlichen Fragen und schwach bei exakten Zeichenfolgen. In der Technik sind exakte Zeichenfolgen aber häufig der Kern: Artikelnummern, Fehlercodes, Normen wie DIN EN ISO 9001, Bestellnummern, Chargen. Ein Vektormodell verwechselt solche Zeichenketten leicht.
Deshalb kombiniert man in der Praxis zwei Verfahren: eine klassische Stichwortsuche, die exakte Begriffe zuverlässig findet, und die Vektorsuche für inhaltliche Nähe. Die Ergebnisse werden zusammengeführt und anschließend neu sortiert. Diese hybride Suche ist aufwendiger einzurichten, liefert aber bei Fachfragen deutlich stabilere Treffer als ein einzelnes Verfahren.
Vor der Suche lohnt eine Umformulierung der Frage. Umgangssprache und Fachsprache fallen im Betrieb auseinander: Gefragt wird nach „Steuerung hängt“, im Dokument steht „SPS-Fehler“. Ein Sprachmodell kann die Frage in mehrere Suchvarianten übersetzen und Abkürzungen auflösen. Diese Umformulierung gehört ins Protokoll, sonst lässt sich ein schlechtes Suchergebnis später nicht erklären.
Der Reranker ist der zweite Filter. Ein Vektorvergleich arbeitet grob, weil er Bedeutung über den gesamten Abschnitt mittelt. Ein Reranker bewertet jeden Kandidaten einzeln gegen die konkrete Frage und sortiert die Reihenfolge neu. In der Praxis verbessert das die Qualität der obersten Treffer häufig stärker als ein Wechsel des Sprachmodells. Wer an einer einzigen Stelle in die Suchqualität investieren möchte, investiert hier.
Ergänzend helfen harte Filter. Produktgruppe, Maschinentyp und Gültigkeitsdatum lassen sich vor der Ähnlichkeitssuche anwenden und schließen ganze Dokumentbestände aus, die inhaltlich ähnlich, aber sachlich falsch sind. Ein Assistent für eine Anlage sollte Antworten aus dem Handbuch einer anderen Baureihe gar nicht erst als Kandidaten sehen.
Rechte, Aktualität und Löschung
Ein Suchindex ist eine zweite Datenhaltung und muss dieselben Regeln einhalten wie das Quellsystem. Zwei Fehler sind typisch. Erstens: Alle Dokumente landen in einer gemeinsamen Sammlung, und die Rechte werden erst in der Oberfläche geprüft. Das ist zu spät, denn der Index selbst ist dann ein offener Bestand. Zweitens: Gelöschte oder ersetzte Dokumente bleiben im Index. Eine zurückgezogene Freigabe taucht dann weiter als gleichwertige Quelle auf.
Sauber ist eine Rechteprüfung gegen das Identitätsmanagement bei jeder Anfrage, kombiniert mit einer Pipeline, die Änderungen und Löschungen übernimmt. Wer den Betrieb lokal plant, findet die betrieblichen Anforderungen dazu unter On-Premise-KI für vertrauliche Unternehmensdaten.
Bewertung mit echten Fragen
RAG lässt sich nicht mit drei Beispielen abnehmen. Notwendig ist ein Fragensatz aus dem Alltag, der vor dem Start fachlich beantwortet wird. Dann wird getrennt gemessen: Findet die Suche das richtige Dokument? Steht die Antwort in den gefundenen Abschnitten? Und formuliert das Modell sie korrekt? Ein System, das den richtigen Ordner findet und trotzdem falsch antwortet, hat ein anderes Problem als eines, das den Ordner nicht findet.
Sinnvolle Kennzahlen sind die Trefferquote unter den ersten Treffern, der Anteil der Antworten mit korrekter Quelle, der Anteil ausdrücklich unbeantworteter Fragen und die Zahl veralteter Aussagen. Wichtig ist die letzte Gruppe: Ein Assistent, der fehlende Informationen benennt, ist brauchbarer als einer, der Lücken überbrückt.
Fazit: Eigene Dokumente durchsuchbar zu machen ist zuerst Dokumentenpflege und Suchtechnik, erst danach eine Frage des Sprachmodells. Wer Zerlegung, Metadaten, hybride Suche und Rechte sauber baut und mit echten Fragen prüft, bekommt eine belastbare Wissensdatenbank. Wer nur ein Modell auf einen Dateiordner setzt, bekommt eine überzeugende Fehlerquelle. Die Verbindung zu den führenden Systemen beschreibt der Beitrag KI mit Firmendaten verbinden.