Retrieval Augmented Generation gilt als der Weg, ein Sprachmodell auf die eigenen Dokumente zu setzen. In der Praxis liefern viele dieser Systeme unvollständige oder falsche Antworten. Die Ursache liegt häufig bereits im Dokumentenbestand: fehlende Textlayer, fehlerhafte Erkennung, zerstörte Layoutstrukturen, unzureichende Metadaten und uneinheitliche Benennungen. Daneben entscheiden auch Embedding-Modell, Suchverfahren, Reranking und Systemkonfiguration über die Qualität. Dieser Beitrag erklärt die Begriffe und konzentriert sich auf sechs typische Probleme auf der Datenseite.
Drei Schritte, von denen der erste über die Qualität der Antwort entscheidet.
Ein Sprachmodell weiß nichts über Ihr Unternehmen. Retrieval Augmented Generation, kurz RAG, schließt diese Lücke, indem vor jeder Antwort im eigenen Bestand gesucht wird und die gefundenen Ausschnitte dem Modell als Grundlage übergeben werden.
Dokumente werden vor der Indexierung in Abschnitte zerlegt. Dieser Schritt heißt Chunking. Er ist notwendig, weil ein ganzer Geschäftsbericht als ein Block weder in den Kontext des Modells passt noch präzise durchsuchbar wäre.
Die meisten Verfahren zerlegen nach Zeichenzahl mit etwas Überlappung. Bei Fließtext funktioniert das ordentlich. Bei allem anderen nicht.
Eine Tabelle verliert beim Zerlegen ihre Kopfzeile: Der Abschnitt enthält dann die Zahlenreihe, aber nicht mehr die Angabe, welche Spalte welches Geschäftsjahr ist. Mehrspaltige Seiten werden vom Extraktionswerkzeug zeilenweise gelesen, sodass sich der Text zweier Spalten ineinander verschränkt. Fußnoten landen mitten im Satz. Überschriften werden vom zugehörigen Abschnitt getrennt, womit die Einordnung verloren geht.
Das Ergebnis sind Abschnitte, die einzeln betrachtet sinnlos sind. Sie werden trotzdem indexiert, gefunden und dem Modell übergeben, das daraus etwas formuliert.
Jeder Abschnitt wird in eine Zahlenfolge übersetzt, die seine Bedeutung abbildet. Diese Zahlenfolgen heißen Embeddings und werden in einer Vektordatenbank, englisch vector database, abgelegt.
Eine Anfrage wird auf demselben Weg in eine Zahlenfolge übersetzt. Das System sucht dann die Abschnitte, deren Werte am nächsten liegen. Deshalb findet ein RAG-System auch Dokumente, in denen das gesuchte Wort gar nicht vorkommt, solange der Inhalt passt.
Unterschiedliche Benennungen erzeugen unterschiedliche Vektoren, die ein gutes Embedding-Modell nahe beieinander ablegt. Genau das ist der Zweck des Verfahrens. Verlässlich gelingt diese Zuordnung aber nicht immer: bei domänenspezifischen, mehrdeutigen oder seltenen Fachbegriffen liegen die Vektoren teils weiter auseinander, als der Sache nach gerechtfertigt wäre. Terminologielisten, Metadaten, Query Expansion und ein für das Fachgebiet geeignetes Embedding-Modell verbessern hier die Trefferqualität. Wie wir das an einem konkreten Bestand umsetzen, steht auf der Seite zur Datenaufbereitung für KI-Systeme.
Deutsche Unternehmensarchive sind fast nie einsprachig. Verträge auf Englisch, Protokolle auf Deutsch, Berichte in mehreren Fassungen, dazwischen Korrespondenz, die von Absatz zu Absatz wechselt. In international tätigen Häusern kommen Französisch, Spanisch oder Niederländisch hinzu.
Wie zuverlässig die Suche über Sprachgrenzen hinweg funktioniert, hängt wesentlich vom eingesetzten Embedding-Modell und vom Fachgebiet ab. Multilinguale Modelle sind ausdrücklich dafür gebaut, in mehreren Sprachen zu suchen. An Treffergenauigkeit verlieren sie dennoch, sobald seltene Fachbegriffe, uneinheitliche Terminologie oder sprachlich gemischte Dokumente ins Spiel kommen. Genau das ist bei Unternehmensarchiven der Normalfall. Dieselbe Terminologiearbeit liegt unserem englischen Fachlektorat für Geschäfts- und Nachhaltigkeitsberichte zugrunde.
Wer einen mehrsprachigen Bestand indexiert, ohne die Terminologie der beteiligten Sprachen aufeinander abzubilden, riskiert Lücken zwischen den sprachlichen Teilbeständen.
Eine reine Vektorsuche kann Beziehungen aus mehreren Textstellen zusammensetzen, erreicht dabei aber schnell Grenzen. Das gilt besonders für Fragen, die mehrere Beziehungsschritte erfordern, und für solche, die Informationen über viele Dokumente hinweg zusammenführen.
Ein Knowledge Graph bildet Entitäten und ihre Verbindungen ausdrücklich ab: dieses Projekt gehört zu diesem Kunden, wurde von dieser Person kalkuliert, basiert auf diesem Angebot, führte zu diesem Vertrag. GraphRAG kombiniert solche Strukturen mit textbasierter Suche und kann zusätzlich Hierarchien oder Zusammenfassungen des Gesamtbestands nutzen, um auch übergreifende Fragen zu beantworten.
Für den Aufbau eines solchen Graphen braucht es genau das, woran die meisten Bestände scheitern: saubere Metadaten und einheitliche Benennungen. Ein Kunde, der in den Akten unter vier Schreibweisen geführt wird, ergibt vier Knoten statt eines.
Die Datenschutzkonferenz der deutschen Aufsichtsbehörden hat eine Orientierungshilfe zu RAG-Systemen veröffentlicht. Sie ist die derzeit maßgebliche deutsche Verwaltungsauffassung zu diesem Thema und für jeden lesenswert, der ein solches System plant.
Drei Punkte daraus sind für die Aufbereitung unmittelbar relevant. Erstens gelten Datenaufbereitung, Erzeugung der Embeddings und Speicherung in der Vektordatenbank jeweils als eigene Verarbeitungsschritte, die eine eigene Rechtsgrundlage benötigen. Der Aufbau eines Index ist damit selbst eine datenschutzrechtlich relevante Handlung, nicht bloß eine technische Vorbereitung.
Zweitens gibt es keine pauschale Freigabe: Jeder Anwendungsfall ist gesondert zu bewerten. Drittens sind personenbezogene Daten, die für den verfolgten Zweck nicht erforderlich sind, zu entfernen. Das folgt aus dem Grundsatz der Datenminimierung nach Artikel 5 Absatz 1 Buchstabe c DSGVO.
Damit ist die Schwärzung vor der Indexierung keine Empfehlung, sondern die Umsetzung einer Rechtspflicht. Die Orientierungshilfe hält außerdem fest, dass die Verlässlichkeit eines RAG-Systems wesentlich von Qualität, Aktualität und Vollständigkeit der Referenzdokumente sowie von einer korrekten Datenaufbereitung abhängt, und nennt dabei ausdrücklich Chunking und das Entfernen irrelevanter Inhalte.
Für Hochrisiko-KI-Systeme, die mit Daten trainiert werden, stellt Artikel 10 der Verordnung (EU) 2024/1689 Anforderungen an die Daten-Governance, im englischen Text data governance. Sie betreffen ausdrücklich Trainings-, Validierungs- und Testdatensätze.
Verlangt werden unter anderem Angaben zu Datenherkunft und Aufbereitung, zur Eignung, zu möglichen Verzerrungen und zu erkennbaren Datenlücken. Diese Anforderungen lassen sich nicht ohne Weiteres auf jeden RAG-Dokumentenbestand übertragen, denn ein Abrufbestand ist kein Trainingsdatensatz. Für Betreiber eines Hochrisiko-KI-Systems kann zusätzlich Artikel 26 Absatz 4 relevant sein: Soweit sie die Eingabedaten kontrollieren, müssen diese für den vorgesehenen Zweck relevant und hinreichend repräsentativ sein. Ob ein System als Hochrisiko-System gilt, ist im Einzelfall zu prüfen.
Unabhängig von dieser Einstufung gilt: Durch die Indexierung darf die bestehende Berechtigungsstruktur nicht verloren gehen. Dokumentbezogene Zugriffsrechte müssen auch bei der Suche und bei der Zusammenstellung des Modellkontexts durchgesetzt werden. Andernfalls können Inhalte über eine Anfrage sichtbar werden, obwohl die anfragende Person keinen Zugriff auf das Ausgangsdokument hat. Wo personenbezogene Angaben für den Zweck nicht erforderlich sind, gehören sie vor die Indexierung entfernt, anonymisiert oder angemessen pseudonymisiert. Der englische Begriff dafür lautet PII redaction.
Weder abschließend noch in jedem Fall die Hauptursache, aber in fast jedem Bestand treten mehrere davon gleichzeitig auf. Welche, lässt sich an einer Stichprobe feststellen, bevor Aufwand in eine Aufbereitung fließt.
Begriffe, die in der Praxis regelmäßig verwechselt werden.
RAG steht für Retrieval Augmented Generation. Das System sucht vor jeder Antwort passende Ausschnitte aus einem eigenen Dokumentenbestand und übergibt sie dem Sprachmodell als Grundlage. Dadurch kann das Modell auf Inhalte antworten, die nicht Teil seines Trainings waren. Die Antwortqualität hängt unmittelbar davon ab, ob die richtigen Ausschnitte gefunden werden.
Chunking bezeichnet das Zerlegen von Dokumenten in kleinere Abschnitte vor der Indexierung. Die meisten Verfahren teilen nach Zeichenzahl mit einer Überlappung. Bei Fließtext funktioniert das gut, bei Tabellen, mehrspaltigen Layouts und Formularen entstehen Abschnitte, die ohne ihren Kontext nicht mehr verständlich sind, etwa eine Zahlenreihe ohne die zugehörige Kopfzeile.
Embeddings sind Zahlenfolgen, die die Bedeutung eines Textabschnitts abbilden. Sie werden in einer Vektordatenbank abgelegt. Eine Anfrage wird auf demselben Weg umgerechnet, und das System sucht die Abschnitte mit dem geringsten Abstand. Deshalb findet ein RAG-System auch Dokumente, in denen das gesuchte Wort selbst nicht vorkommt.
Beim Fine-Tuning wird das Modell selbst mit zusätzlichen Daten weitertrainiert. Bei RAG bleibt das Modell unverändert und bekommt die benötigten Informationen zur Laufzeit übergeben. Für veränderliche Unternehmensdokumente ist RAG häufig praktikabler: Neue Dokumente können nach Extraktion und Indexierung verfügbar gemacht und veraltete Inhalte gezielt entfernt werden. Bleiben die Herkunftsmetadaten erhalten und gibt das System Quellen aus, lassen sich Antworten zudem auf ihre Belege zurückführen. Fine-Tuning eignet sich eher zur Anpassung von Verhalten, Stil, Terminologie oder Ausgabeformaten als zur Pflege eines laufend veränderten Faktenbestands.
Ein Knowledge Graph bildet Entitäten und deren Beziehungen ab, etwa Projekte, Kunden, Personen und Verträge samt ihrer Verbindungen untereinander. Eine reine Vektorsuche findet ähnliche Textstellen, kennt aber keine Beziehungen. Sobald Fragen nach Zusammenhängen gestellt werden, etwa welche Projekte zu einem Kunden gehören und wer daran beteiligt war, stößt reine Ähnlichkeitssuche an ihre Grenzen. Die Kombination aus beidem wird als GraphRAG bezeichnet.
Texterkennung ist notwendig, aber nicht hinreichend. Sie erzeugt Text, wo vorher nur ein Bild war. Sie ordnet ihn nicht, erkennt keine Tabellenstruktur, vergibt keine Metadaten und vereinheitlicht keine Benennungen. Hinzu kommt: Selbst eine scheinbar hohe Erkennungsquote kann problematisch sein. Bei 92 Prozent Wortgenauigkeit wären statistisch acht von hundert Wörtern fehlerhaft. Besonders folgenreich sind Fehler bei Eigennamen, Dokumentnummern, Beträgen und Datumsangaben, weil gerade diese später als Such- und Filterkriterien dienen.
Wie zuverlässig die Suche über Sprachgrenzen hinweg funktioniert, hängt vom eingesetzten Embedding-Modell und vom Fachgebiet ab. Multilinguale Modelle sind dafür gebaut, verlieren aber an Treffergenauigkeit, sobald seltene Fachbegriffe oder uneinheitliche Terminologie ins Spiel kommen. Sachanlagen etwa erscheinen je nach Rechnungslegungsstandard als property, plant and equipment, als tangible fixed assets oder verkürzt als fixed assets: überschneidend, aber nicht in jedem Kontext austauschbar. Abhilfe schaffen die Sprache als Metadatum sowie mehrsprachige Begriffslisten, gegen die das System auflösen kann.
Wir prüfen eine Stichprobe Ihres Bestands und sagen Ihnen, welche dieser Probleme tatsächlich vorliegen, bevor Aufwand in eine Aufbereitung fließt.
Datenaufbereitung für KI-Systeme