Retrieval Augmented Generation, kurz RAG, verbindet die Leistungsfähigkeit von Sprachmodellen mit dem spezifischen Wissen eines Unternehmens. Der Ansatz ermöglicht es, interne Dokumente und Daten gezielt in Antworten einzubeziehen, ohne die Hoheit über die eigenen Informationen zu verlieren. Damit wird RAG zunehmend als Schlüsseltechnologie gesehen, um Sprachmodelle sicher und datensouverän einzusetzen. In der Praxis zeigt sich jedoch schnell, dass eine einfache Vektorsuche in Kombination mit einem LLM nicht ausreicht, um wirklich konsistente und qualitativ hochwertige Ergebnisse zu erzielen. Um das Potenzial von RAG voll auszuschöpfen, sind zusätzliche Methoden und Optimierungen notwendig.

Um die Qualität einer RAG Anwendung zu verbessern, reicht es nicht, nur an einer einzelnen Stelle im Prozess anzusetzen. Optimierungen können in verschiedenen Phasen erfolgen, angefangen bei der Aufbereitung der Daten über die Art und Weise, wie Dokumente in Chunks zerlegt und eingebettet werden, bis hin zur Auswahl und Bewertung der relevanten Informationen für die Antwortgenerierung. Eine klare Unterscheidung dieser Kategorien hilft, gezielt die passenden Maßnahmen einzusetzen und Schwachstellen systematisch zu adressieren. Darauf aufbauend lassen sich verschiedene Ansätze nutzen, um RAG Systeme gezielt zu optimieren.

Kategorien für Optimierungen im RAG Prozess

Dokumentenaufbereitung
Bevor Dokumente in ein RAG System gelangen, müssen sie zuverlässig aufbereitet werden. Dazu gehört die Extraktion von Text aus verschiedenen Formaten wie PDF, Word, PowerPoint oder E Mail. Ebenso wichtig ist es, irrelevante Inhalte wie Kopf und Fußzeilen, Navigationselemente oder wiederkehrende Boilerplate Texte zu entfernen. In dieser Phase findet auch die Normalisierung von Zeichensätzen und die Vereinheitlichung von Sprache statt. Ergänzend können Dokumente mit Metadaten wie Autor, Datum oder Dokumenttyp angereichert werden. Diese Vorarbeiten stellen sicher, dass die nachfolgenden Schritte mit sauberen und strukturierten Daten arbeiten, was die Basis für eine hohe Qualität im gesamten RAG Prozess bildet.

Chunking
Nachdem die Dokumente extrahiert und bereinigt wurden, werden sie in kleinere Abschnitte, sogenannte Chunks, zerlegt. Das Chunking entscheidet maßgeblich darüber, wie sinnvoll das Wissen später für Embeddings und Retrieval genutzt werden kann. Chunks können anhand von Zeichenlängen, Absätzen oder Überschriften gebildet werden. In anspruchsvolleren Szenarien erfolgt das Chunking semantisch, sodass Sätze oder Absätze nicht künstlich auseinandergerissen werden. Eine gewisse Überlappung der Chunks kann sinnvoll sein, um Übergänge zwischen Abschnitten nicht zu verlieren. Auch tabellarische Inhalte oder Listen werden in dieser Phase gesondert behandelt, damit ihre Struktur nicht verloren geht.

Embedding
In der Embedding Phase werden die vorbereiteten Chunks in Vektoren umgewandelt. Diese Vektoren bilden die semantische Bedeutung der Texte ab und machen sie in der Vektordatenbank durchsuchbar. Für allgemeine Anwendungsfälle kommen Modelle zum Einsatz, die auf breiten, unspezifischen Datensätzen trainiert wurden. Sie erfassen Sprache in vielen Kontexten, sind jedoch nicht auf einzelne Fachbereiche zugeschnitten. Wenn Inhalte aus hochspezialisierten Domänen verarbeitet werden sollen, kann es sinnvoll sein, die Embeddings mit einem Feintuning auf branchenspezifischen Daten nachzujustieren oder eigene Modelle zu trainieren. Auch mehrsprachige Embedding Modelle spielen eine Rolle, wenn Inhalte in unterschiedlichen Sprachen im Unternehmen vorhanden sind. Normalisierung und Qualitätskontrolle der Embeddings sind wichtig, um eine konsistente Basis für das Retrieval zu schaffen.

Vektorindexierung und Speicherung
Nach dem Embedding werden Chunks in einer Vektordatenbank abgelegt und indiziert. Die Wahl des Index und seiner Parameter beeinflusst Qualität und Latenz des Retrievals. Wichtige Entscheidungen sind HNSW oder IVF, Distanzfunktion, Parameter wie M und efSearch, Quantisierung wie PQ oder OPQ, Sharding und Replikation, inkrementelles Reindexing sowie Versionierung und Rollback fähige Indexwechsel.

Retrieval
In der Retrieval Phase werden die Embeddings für eine konkrete Nutzeranfrage durchsucht. Die Anfrage wird selbst in einen Vektor umgewandelt und mit den gespeicherten Chunks verglichen. Typischerweise entsteht dabei eine Kandidatenliste, die als Top K Treffer bezeichnet wird. Um die Qualität dieser Ergebnisse zu erhöhen, gibt es verschiedene Strategien. Dazu gehören hybride Verfahren, die Vektorsuche mit klassischer Schlüsselwortsuche kombinieren, sowie Multi Query Retrieval, bei dem eine Anfrage in mehrere Varianten umformuliert wird. Auch Metadaten können in die Gewichtung einfließen, sodass zum Beispiel aktuelle Dokumente oder bestimmte Abteilungen bevorzugt berücksichtigt werden.

Antwortgenerierung
Nachdem die besten Chunks aus der Kandidatenliste ausgewählt wurden, werden sie in den Prompt des Sprachmodells eingebettet. Die Qualität der Antwort hängt stark davon ab, wie diese Informationen in den Prompt integriert werden. Eine klare Strukturierung, die Angabe der Quellen und das Vermeiden von Redundanzen sind entscheidend. Auch das Design des Prompts selbst kann die Qualität verbessern, etwa indem das Modell angewiesen wird, präzise und faktenbasiert zu antworten.

Feedback und kontinuierliche Verbesserung
Ein RAG System ist kein statisches Produkt, sondern entwickelt sich durch Feedback und Monitoring weiter. Nutzer können bewerten, ob eine Antwort hilfreich war. Diese Rückmeldungen können genutzt werden, um die Pipeline nach und nach zu optimieren. Auch automatisierte Evaluation spielt eine Rolle, zum Beispiel durch Benchmarks oder Testfragen mit bekannten Antworten. So wird die Qualität des Systems langfristig gesichert und verbessert.

Sicherheit und Zugriff
Zugriffsrechte müssen auf Dokument und Chunk Ebene durchgesetzt werden. Dazu gehören rollen oder attributbasierte Filter schon beim Retrieval, Maskierung personenbezogener Daten vor dem Embedding, Mandantentrennung in Indizes und vollständiges Audit Logging über genutzte Quellen und Anfragen

Orchestrierung und Performance
Der Betrieb erfordert verlässliche Steuerung und Skalierung. Dazu zählen Caching von Embeddings und Suchergebnissen, Batching und asynchrone Verarbeitung, Backpressure und Zeitlimits, Retries bei Fehlern, sowie Auto Scaling und Kapazitätsplanung für Einbettung, Indexierung und Suche.

Konversationskontext und Sitzungszustand
Mehrturn Dialoge benötigen Regeln, wie Verlauf und Kontext genutzt und gespeichert werden. Dazu zählen Query Umschreibungen mit Blick auf den Verlauf, klare Grenzen zwischen Kurzzeit und Langzeit Kontext, Sitzungsbezug über mehrere Schritte und kontrolliertes Vergessen sensibler Inhalte.

Wissensmanagement und Datenlebenszyklus
Unternehmenswissen verändert sich. Ein Datenkatalog mit Datenlinie, Versionierung von Dokumenten, Gültigkeits und Verfallsdaten, Rückzug veralteter Inhalte sowie definierte Aufbewahrungs und Löschfristen sichern Aktualität, Nachvollziehbarkeit und Compliance.

Dokumentenaufbereitung

Dokumentklassifikation

Dokumentklassifikation ordnet eingehende Dateien einem oder mehreren sinnvollen Typen zu. Ziel ist es, jedem Dokument früh eine belastbare Kategorie zu geben, zum Beispiel Vertrag, Rechnung, Protokoll, Präsentation, Richtlinie oder Support Ticket. Diese Zuordnung steuert den weiteren Weg durch die Pipeline. Sie entscheidet über passende Extraktoren, geeignete Chunking Regeln, das richtige Embedding Modell, notwendige Sicherheitsstufen und spätere Filter im Retrieval. Klassifikation ist klar abzugrenzen von Text Extraktion, die nur Inhalte aus dem Format hebt. Hier geht es um den Dokumenttyp als Ganzes.

Funktionsweise. Zuerst werden Merkmale gebildet. Dazu zählen Textauszüge, Titel, Dateiname, Metadaten, einfache Layoutsignale wie Vorkommen von Tabellen oder typischen Abschnittsüberschriften sowie Domänenhinweise wie Kundennummer oder Vertragsnummer. Ein trainiertes Modell bewertet diese Merkmale und gibt pro Klasse eine Wahrscheinlichkeit zurück. Je nach Bedarf wird eine eindeutige Klasse gewählt oder eine mehrfache Zuordnung vergeben, etwa Rechnung und vertraulich. Unsichere Fälle werden mit Schwellenwerten abgefangen und gehen in eine manuelle Sichtung oder in einen erneuten Lauf mit zusätzlichen Regeln.

Ohne Dokumentklassifikation arbeiten nachfolgende Schritte blind. Rechnungen könnten wie Präsentationen behandelt werden, Tabellen gingen als Fließtext verloren und Sicherheitsregeln würden zu spät greifen. Die Folge sind unpassende Chunks, schwächere Embeddings, höhere Latenzen durch unnötige Verarbeitung und Antworten, die sich auf falsche Quellen stützen. In Audit Situationen fehlt die nachvollziehbare Begründung, warum ein Dokument auf eine bestimmte Weise verarbeitet wurde. Eine verlässliche Dokumentklassifikation ist daher ein Kernbaustein für Qualität, Sicherheit und Reproduzierbarkeit im gesamten RAG Prozess.

Text Extraktion aus verschiedenen Formaten

Text Extraktion aus verschiedenen Formaten bedeutet, Inhalte aus Quelldateien zuverlässig in eine einheitliche, maschinenlesbare Darstellung zu überführen. Im Fokus stehen das Erkennen des Dateityps und das Anwenden eines passenden Parsers, der nur das liefert, was das Format selbst hergibt. Dazu gehören Lauftext, einfache Strukturhinweise wie Absatzgrenzen und die nativen Metadaten des Dokuments. Die Extraktion erstellt keine inhaltliche Reinigung und nimmt keine Layoutbereinigung vor. Das Ergebnis dieser Phase ist ein konsistenter Textstrom mit Basisstruktur und ein Verweis auf die ursprünglichen Positionen im Dokument, damit spätere Schritte präzise zitieren können.

Ein anschauliches Beispiel ist eine E Mail im EML Format mit Anhang. Die Extraktion liest den Nachrichtentext aus dem richtigen Textteil, übernimmt Betreff und Datum als native Metadaten und speichert Anhänge getrennt, ohne den Inhalt umzuschreiben oder zu kürzen. Eine inhaltliche Bereinigung oder das Entfernen von Navigationselementen findet in dieser Phase nicht statt.

Wenn diese Maßnahme fehlt oder unsauber umgesetzt ist, entstehen Folgeschäden in allen weiteren Schritten. Leere oder beschädigte Texte führen dazu, dass wichtige Inhalte gar nicht in den Wissensbestand gelangen. Falsche Zeichenkodierung erzeugt verstümmelte Wörter, was die späteren Embeddings unbrauchbar macht. Vermischte Textteile aus unterschiedlichen Dokumentbestandteilen führen dazu, dass das Retrieval falsche Stellen für relevant hält. Ohne verlässliche Extraktion wird das System insgesamt unpräzise, schwer zitierbar und für Leser kaum nachvollziehbar.

Entfernung von Boilerplate und Fülltext

Entfernung von Boilerplate und Fülltext meint das gezielte Herausfiltern von Textteilen ohne fachlichen Mehrwert. Dazu zählen Navigation, Kopfzeilen, Fußzeilen, Cookie Hinweise, Impressum Passagen, Seitenleisten, automatische E Mail Signaturen und immer gleiche Vertraulichkeitshinweise. Diese Phase grenzt sich klar von der Text Extraktion ab, die nur Rohtext und Basisstruktur liefert. Technisch basiert die Bereinigung auf Wiedererkennung über viele Seiten und auf strukturellen Merkmalen aus HTML oder PDF Objekten. Sensible Bereiche wie Tabellen, Codeblöcke und Zitate werden durch Regeln geschützt und nicht entfernt. Ohne diese Maßnahme entstehen Embeddings auf Basis von Boilerplate und Fülltexten statt auf Basis der Kerninformationen.

OCR für gescannte Dokumente

OCR für gescannte Dokumente bedeutet, jede Quelle zu verarbeiten, in der Inhalt bzw. Text nur als Pixel vorliegt. Das umfasst gescannte PDFs, TIFF, JPEG, PNG, Faxdateien, Fotos und Screenshots sowie eingebettete Bilder in Word oder PowerPoint. Sobald ein Dokument echten auswählbaren Text enthält, kommt die Text Extraktion zum Einsatz. Bei Mischdokumenten wird zonenweise gearbeitet. Bildbereiche laufen durch OCR, Textbereiche werden extrahiert.

Der Ablauf beginnt mit der Bildvorbereitung. Schieflagen und Verzerrungen werden korrigiert, Kontrast und Schärfe angepasst und Störungen reduziert. Danach folgt die Layoutanalyse, die Textzonen, Zeilen und Wörter segmentiert und die Lesereihenfolge festlegt. Die Erkennung wandelt die Bildsegmente in Zeichenfolgen um, gesteuert durch Spracheinstellungen und passende Wörterbücher. Ergebnis sind Text und Metadaten wie Seitenzahl, Koordinaten und Vertrauenswert für jede erkannte Einheit.

Ohne diese Maßnahme bleiben Bildinhalte unsichtbar. Wichtige Passagen gelangen nicht in die Embeddings, das Retrieval findet fachlich relevante Stellen nicht und Antworten wirken lückenhaft.

Sprach und Encoding Erkennung

Sprach und Encoding Erkennung bedeutet, vor jeder weiteren Verarbeitung zuverlässig festzustellen, in welcher Sprache ein Inhalt vorliegt und in welcher Zeichenkodierung die Bytes gespeichert sind. Ziel ist es, den Eingabetext korrekt nach Unicode zu dekodieren und jedem Dokument oder Abschnitt ein belastbares Sprachkennzeichen zu geben. Diese Phase unterscheidet sich von der Text Extraktion, die nur Formate ausliest.

Tabellen und Formulare erkennen

Tabellen und Formulare erkennen bedeutet, strukturierte Inhalte in Dokumenten als solche zu identifizieren und in eine maschinenlesbare Form zu überführen, statt sie als Fließtext zu behandeln. Ziel ist es, Zeilen, Spalten, Kopfzeilen, zusammengeführte Zellen, Summenzeilen und Einheiten zuverlässig zu erkennen und bei Formularen die Beziehung zwischen Feldbezeichnung und Feldwert herzustellen. Diese Phase ist klar von der reinen Text Extraktion abgegrenzt, denn hier geht es nicht nur um Zeichen, sondern um Struktur. Technisch beginnt der Prozess mit einer Layoutanalyse, die Tabellengrenzen, Zellgitter oder Linien sowie Weißräume und Ausrichtung nutzt. Aus diesen Hinweisen entstehen Zellen mit Koordinaten, Reihenfolge und Datentypen. Für Formulare werden Schlüssel Wert Paare gebildet, bei Kästchen die Markierung erkannt und bei Auswahlfeldern der angewählte Eintrag zugeordnet. Zahlen, Währungen und Datumsangaben werden zusätzlich typisiert. Jede erkannte Zelle oder jedes Feld behält Verweise auf Seite und Position, damit spätere Antworten exakt belegt werden können.

Ohne diese Maßnahme gehen wesentliche Zusammenhänge verloren. Aus Tabellen wird unstrukturierter Fließtext, Spalten vermischen sich, Zahlen und Währungen werden in späteren Schritten falsch gedeutet und verarbeitet, d.h. Fragen nach Summen, Mengen oder bestimmten Positionen scheitern oder liefern widersprüchliche Antworten.

Named Entity Recognition (NER) für Metadaten

Named Entity Recognition für Metadaten erkennt in Texten die Erwähnungen bedeutsamer Dinge und speichert sie als strukturierte Merkmale. Dazu gehören Personen, Unternehmen, Produkte, Projekte, Vertragsnummern, Kundennummern, Orte, Beträge, Währungen, Zeitangaben sowie Verweise auf Normen oder Gesetze. Ziel ist nicht die Einteilung des gesamten Dokuments, sondern das Erfassen einzelner Nennungen pro Dokument und pro Chunk, damit eine präzise Grundlage für Suche, Filter und Zitation entsteht. Ohne NER bleiben diese Bezüge im Fließtext verborgen. Retrieval kann dann nicht nach Kunde, Projekt oder Zeitraum filtern, Reranking bewertet nur grobe Textähnlichkeit, wichtige Dokumente rutschen nach unten und die Antwortgenerierung verliert belastbare Belege. Zitate werden ungenau und Kosten sowie Latenz steigen, weil unnötig viele irrelevante Chunks geprüft werden. NER für Metadaten schafft damit die Basis für präzisere Treffer, nachvollziehbare Zitate und verlässliche Antworten.

Duplikaterkennung und Konsistenzkontrolle

Duplikaterkennung und Konsistenzkontrolle stellt sicher, dass identische und sehr ähnliche Inhalte nur einmal in den Wissensbestand gelangen und dass Versionen sowie Metadaten widerspruchsfrei sind. Zuerst werden Dokumente in eine vergleichbare Form gebracht, etwa durch Entfernen technischer Artefakte und Vereinheitlichung von Leerraum. Danach entstehen Textfingerabdrücke über Wort oder Zeichen Schingles sowie Hashverfahren wie SimHash oder MinHash. Ein Ähnlichkeitswert entscheidet, ob es sich um ein exaktes Duplikat oder um ein nahes Duplikat handelt. Für gefundene Duplikate wählt das System eine kanonische Fassung nach klaren Regeln, zum Beispiel höchste Freigabestufe, neuestes Datum, vollständigste Metadaten. Alle anderen Fassungen werden verworfen oder als Verweis auf die kanonische Quelle gespeichert. Auf Chunk Ebene lässt sich das Verfahren erneut anwenden, damit redundante Abschnitte nicht mehrfach eingebettet werden. Die Konsistenzkontrolle prüft zusätzlich Pflichtfelder und Wertebereiche pro Dokumenttyp, erkennt widersprüchliche Zahlen, Datumsangaben oder Summen und verankert Versions und Freigabeinformationen als Metadaten, damit Retrieval und Zitation später eindeutig bleiben.

Ohne diese Maßnahme wächst der Index durch redundante Inhalte, Speicherbedarf und Embedding Kosten steigen, das Retrieval zeigt doppelte oder veraltete Treffer, Reranking wird durch viele nahezu gleiche Chunks verzerrt und Antworten können widersprüchliche Angaben zitieren. In Audits fehlt die nachvollziehbare Herkunft, Nutzer verlieren Vertrauen und Korrekturen verbreiten sich nur unvollständig, weil alte Fassungen weiterhin im Umlauf sind.

Validierung und Data Quality Checks

Validierung und Data Quality Checks sichern ab, dass nur brauchbare und vollständige Inhalte in die Pipeline gelangen. Geprüft werden Struktur und Inhalt eines Dokuments sowie die dazugehörigen Metadaten. Dazu gehören Mindestlängen für Text, korrekte Zeichenkodierung, erkennbare Sprache, stimmige Seitenreihenfolge, erfolgreiche Tabellen und Formularerkennung, gültige Datums und Zahlenformate, Pflichtfelder je Dokumenttyp und ausreichend hohe Qualität bei Ergebnissen aus optischer Zeichenerkennung. Die Ergebnisse dieser Prüfungen werden als Status und Metriken gespeichert. Dokumente, die Regeln verletzen, werden in eine Quarantäne verschoben oder erneut verarbeitet. Nur geprüfte Inhalte passieren das Aufnahme Tor und sind für Chunking und Embedding freigegeben.

Ohne diese Maßnahme gelangen leere oder verfälschte Texte in den Index. Embeddings bilden dann Rauschen statt Fachinhalte ab, das Retrieval zeigt unpassende Treffer, Zitate verweisen auf falsche Stellen und Antworten verlieren Präzision. Zusätzlich steigen Kosten und Latenz, weil fehlerhafte Dokumente eingebettet und gesucht werden, und die Nachvollziehbarkeit leidet, da Mängel erst spät auffallen.

Layout Analyse und Lesereihenfolge bei PDFs und Scans

Layout Analyse und Lesereihenfolge bei PDFs und Scans beschreibt das Erkennen der visuellen Struktur eines Dokuments und die Rekonstruktion der korrekten Textreihenfolge für das spätere Lesen durch Maschinen. Ziel ist es, zusammengehörige Blöcke wie Überschriften, Absätze, Spalten, Fußnoten, Marginalien und Bildelemente zuverlässig zu identifizieren und in eine lineare Reihenfolge zu bringen, die dem menschlichen Lesen entspricht. Diese Phase ist von der optischen Zeichenerkennung getrennt. OCR wandelt Pixel in Zeichen um, die Layout Analyse ordnet diese Zeichen zu sinnvollen Blöcken und bestimmt die Reihenfolge. Sie ist auch von der Tabellen und Formularerkennung abzugrenzen, denn dort werden spezielle Strukturen zusätzlich typisiert.

Die Verarbeitung beginnt mit der Segmentierung der Seite in Text und Nichttext. Linien, Weißräume, Ausrichtung, Schriftgrößen und Abstände liefern Hinweise auf Spalten und Abschnitte. Innerhalb jedes Blocks werden Zeilen und Wörter erkannt und mit Koordinaten versehen. Regeln für Spaltensprünge, Überschriftenhierarchien und Lesepfade stellen sicher, dass der Text korrekt linearisiert wird. Verweise auf Seite und Position bleiben erhalten, damit spätere Schritte präzise zitieren können. Bei mehrseitigen Dokumenten sorgt die Analyse dafür, dass wiederkehrende Elemente wie Kopf und Fußbereiche nicht mit dem Fließtext vermischt werden und dass Fortsetzungen von Abschnitten korrekt verknüpft sind. Das Ergebnis ist ein sauberer Text mit Basisstruktur und ein Satz von Ankern, die die ursprüngliche visuelle Lage beschreiben.

Ohne diese Maßnahme entstehen typische Fehler. Spalten werden vermischt, Bildunterschriften landen mitten im Satz, Fußnoten durchbrechen den Fließtext, Zeilenumbrüche erzeugen falsche Worttrennungen und zusammengehörige Absätze werden auseinandergerissen. Embeddings repräsentieren dann ein durcheinandergeratenes Signal, das Retrieval findet irrelevante Treffer und die Antwortgenerierung kann Aussagen nicht sauber belegen, weil Quellenanker auf fehlerhafte Positionen zeigen. Latenz und Kosten steigen, da mehr Nacharbeit nötig ist und Korrekturen erst spät sichtbar werden. Eine zuverlässige Layout Analyse mit korrekter Lesereihenfolge ist daher Voraussetzung für präzises Chunking, belastbare Zitation und konsistente Antworten.

Entity Resolution auf Unternehmens IDs für Kunden, Projekte, Produkte

Entity Resolution auf Unternehmens IDs für Kunden, Projekte und Produkte bedeutet, Textnennungen eindeutig auf Stammdaten zu verknüpfen. Ziel ist, dass Müller Maschinenbau im Text nicht nur als Zeichenfolge vorkommt, sondern als verlässlicher Verweis auf die Kunden ID aus dem CRM mit bekannter Rechtsform, Standort, Zuständigkeiten und Gültigkeitszeitraum. Diese Phase unterscheidet sich von Named Entity Recognition. NER markiert die Stelle im Text als Organisation oder Produkt. Entity Resolution ordnet diese Markierung einer konkreten Unternehmens ID zu und hält die Entscheidung mit Vertrauenswert, Zeitstempel und Herkunft fest.

Die Verarbeitung beginnt mit einer Normalisierung von Namen, Schreibvarianten und Zeichen. Danach werden Kandidaten aus den Stammdatentabellen ermittelt. Dazu dienen Name, Domäne der E-Mail, Steuernummer, Artikelnummer oder Projektschlüssel. Ein Matcher bewertet die Kandidaten mit Regeln und statistischen Ähnlichkeiten. Unklare Fälle werden über Namensähnlichkeit, Adresse, Sprache, Abteilung und gemeinsame Mitnennungen aufgelöst. Ergebnis ist eine eindeutige Zuordnung oder eine gekennzeichnete Unsicherheit. Die Zuordnung wird als Metadatum pro Dokument und pro Chunk gespeichert, inklusive Version der Stammdaten, damit spätere Suchfilter, Berechtigungen und Zitate stabil funktionieren.

Ohne diese Maßnahme entstehen Doppelungen und Verwechslungen. Das Retrieval kann nicht sicher nach Kunden oder Projekten filtern, identische Firmen mit leicht anderer Schreibweise werden als verschiedene Einträge behandelt, Berechtigungen pro Kunde greifen nicht zuverlässig und Antworten zitieren falsche Vorgänge. In Audits fehlt die klare Herkunft, Korrekturen verbreiten sich unvollständig und Messwerte zu Nutzung und Qualität verzerren, weil Ereignisse nicht der richtigen Unternehmens ID zugeordnet sind. Entity Resolution ist daher die Grundlage für präzise Filter, saubere Mandantentrennung, nachvollziehbare Zitate und belastbare Auswertungen.

Taxonomie und Ontologie Abgleich mit Firmenvokabular

Taxonomie und Ontologie Abgleich mit Firmenvokabular bedeutet, die in Dokumenten verwendeten Begriffe mit einem unternehmensweit vereinbarten Begriffssystem zu verbinden. Eine Taxonomie ordnet Fachbegriffe in Klassen und Unterklassen, eine Ontologie beschreibt zusätzlich Beziehungen wie gehört zu, verursacht, gilt für oder ersetzt. Ziel ist, dass gleiche oder verwandte Sachverhalte unter einem kanonischen Begriff auffindbar sind, unabhängig von Schreibweise, Abkürzung, Sprache oder Bereichsjargon. Dieser Schritt unterscheidet sich von Named Entity Recognition, die nur Erwähnungen markiert, und von Entity Resolution, die Namen auf konkrete Stammdatensätze wie Kundennummern abbildet. Hier geht es um die Vereinheitlichung der Bedeutungsebene, damit Suche, Filter, Berechtigungen und Auswertungen über ein gemeinsames Vokabular laufen.

Praktisch läuft es so ab. Zuerst legen die Fachbereiche ein kontrolliertes Wörterverzeichnis an. Für jeden Begriff gibt es eine bevorzugte Schreibweise, erlaubte Synonyme, übliche Abkürzungen, vorhandene Übersetzungen und ausdrücklich unerwünschte Varianten. Jeder Eintrag erhält eine stabile Konzept ID. Beim Verarbeiten der Dokumente werden gefundene Begriffe mit diesem Verzeichnis abgeglichen. Pro Chunk werden Konzept ID, bevorzugter Begriff, ursprüngliche Schreibweise und Position im Text als Metadaten gespeichert. Eine Ontologie ergänzt das Ganze um Beziehungen zwischen Konzepten wie gehört zu, Teil von, ersetzt oder ist Version von. Diese Metadaten nutzt die Pipeline später. Das Retrieval kann nach Konzepten filtern und Synonyme automatisch einschließen. Reranking kann Treffer bevorzugen, die eine exakte Konzeptübereinstimmung besitzen. Die Antwortgenerierung verwendet die aktuelle Bezeichnung und kann die Beziehung nachvollziehbar machen. Wichtig ist die Abgrenzung. Die inhaltliche Bereinigung, das Chunking und das Embedding bleiben eigene Schritte. Sie laufen nach dem Abgleich und profitieren von den sauber hinterlegten Konzeptmetadaten.

Ohne diesen Abgleich entstehen systematische Lücken. Die Suche verfehlt Inhalte, weil Synonyme, Abkürzungen und Übersetzungen nicht zusammengeführt werden. Reranking ordnet nach reiner Textähnlichkeit statt nach fachlicher Gleichheit. Antworten verwenden uneinheitliche Bezeichnungen und wirken widersprüchlich. Themenfilter arbeiten unzuverlässig. Kennzahlen zu Häufigkeiten und Trends sind nicht vergleichbar, weil gleiche Sachverhalte unter verschiedenen Namen laufen. Fach und Compliance Regeln lassen sich nicht sicher durchsetzen, weil Begriffe uneinheitlich interpretiert werden. Der Abgleich mit dem Firmenvokabular schafft eine gemeinsame Bedeutungsebene, erhöht Recall und Präzision und macht Ergebnisse nachvollziehbar.

Seiten und Abschnittsanker für präzise Zitate

Seiten und Abschnittsanker für präzise Zitate stellen sicher, dass jede Aussage im System eindeutig auf eine Stelle im Ursprungsdokument zurückgeführt werden kann. Gemeint ist eine stabile Verknüpfung aus Dokumentkennung, Seiten oder Foliennummer, Abschnittsbezeichnung und optional Absatz, Zeilen oder Zeichenposition. Diese Anker entstehen unmittelbar bei Extraktion oder OCR und werden unverändert als Metadaten an Text und Chunks gespeichert. Sie unterscheiden sich von der Layout Analyse, die nur die Struktur erkennt, und von Named Entity Recognition, die Begriffe markiert. Anker liefern die Adresse, unter der eine Quelle später exakt belegt werden kann.

Technisch wird pro Seite und Abschnitt eine eindeutige Kennung erzeugt und mit Positionen verknüpft. Bei PDFs sind das Seite, Abschnittstitel und Koordinatenbereiche. Bei Präsentationen sind es Foliennummer und Platzhalterbezeichnung. Bei Webseiten sind es Adresse und Elementkennung. Diese Kennungen bleiben stabil, auch wenn der Inhalt eingebettet, in Chunks zerlegt oder in einer Vektordatenbank gespeichert wird. Antwortgenerierung und Evaluation können damit jede Aussage mit Dokument, Seite oder Folie und Abschnitt belegen. Außerdem lassen sich Updates sicher handhaben, weil alte und neue Anker verglichen und bei Bedarf migriert werden können.

Ohne diese Maßnahme fehlt der eindeutige Quellenanker und die genaue Stelle im Ursprungsdokument ist nicht mehr verifizierbar. Leser und Prüfer können die Passage nicht zuverlässig nachschlagen, Nachweise in Audit und Compliance werden schwächer und Verwechslungen zwischen unterschiedlichen Versionen oder gleichlautenden Abschnitten sind wahrscheinlicher. Bei Aktualisierungen führen Verweise ins Leere, da keine stabilen Anker zur Migration vorhanden sind. In Summe sinken Nachvollziehbarkeit und Reproduzierbarkeit, obwohl der zitierte Wortlaut unverändert bleibt.

Chunking

Strukturorientiertes Chunking

Strukturorientiertes Chunking setzt verlässliche Strukturmarkierungen aus Extraktion und Layoutanalyse voraus. Ein Chunk entspricht einer vorhandenen Einheit wie Überschriftblock, Abschnitt, Absatz, Liste, Tabelle oder Codeblock. Sehr kurze Absätze derselben Ebene können zusammengeführt werden, sehr lange Absätze dürfen innerhalb dieser Einheit an Satzgrenzen weitergeteilt werden. Schnitte über Einheiten hinweg finden nicht statt. Feste Zeichenlängen dienen höchstens als technische Obergrenze und entscheiden nicht über den Schnitt. Fehlen solche Strukturmarkierungen oder sind sie unzuverlässig, kommt diese Methode nicht zum Einsatz. In diesem Fall wird auf andere Verfahren gewechselt, zum Beispiel semantisches Chunking.

Ohne strukturorientiertes Chunking entstehen Misch Chunks, in denen Überschrift, halber Absatz und fremde Elemente zusammenfallen. Definitionen werden auseinandergerissen, Bezüge gehen verloren und das Retrieval liefert Ausschnitte ohne abgeschlossene Aussage. Die Antwortgenerierung benötigt mehr Kontext, verbraucht mehr Tokens und kann Quellen schlechter belegen. Mit sauberer Strukturorientierung bleiben Aussageeinheiten intakt, Zitate sind präzise und nachfolgende Schritte arbeiten auf einer stabilen Grundlage.

Semantisches Chunking mit NLP

Semantisches Chunking mit NLP teilt Texte entlang inhaltlicher Einheiten, nicht entlang äußerer Formate. Der Schnitt folgt dem Thema und der Aussageabsicht, auch wenn ein Dokument formal keine sauberen Abschnitte hat oder wenn vorhandene Abschnitte inhaltlich zu breit sind. Damit ergänzt es das strukturorientierte Chunking. Wo verlässliche Struktur fehlt, liefert die semantische Segmentierung präzisere Sinneinheiten.

Die Umsetzung beginnt mit einer Satzsegmentierung. NLP Verfahren analysieren anschließend den Textfluss und suchen nach thematischen Brüchen. Anzeichen für einen Wechsel sind Signalwörter, Übergänge, Kontraste oder ein deutlicher inhaltlicher Sprung. An diesen Stellen werden Chunks gebildet, sodass jede Einheit inhaltlich geschlossen bleibt. Sehr kurze Segmente können mit Nachbarn derselben Thematik zusammengeführt werden, während sehr lange Abschnitte an natürlichen Satzgrenzen geteilt werden.

Ohne semantisches Chunking entstehen Mischabschnitte, die zu viel Irrelevantes enthalten. Das Retrieval liefert unpräzise Treffer und die Antwortgenerierung muss unnötig viel Kontext verarbeiten. In der Folge sinken Genauigkeit und Effizienz, obwohl die Informationen vorhanden sind. Semantisches Chunking schafft hier klar abgegrenzte Sinneinheiten und verbessert die Qualität der Ergebnisse deutlich.

Adaptive Chunk-Größe nach Kontext

Adaptive Chunk-Größe nach Kontext bedeutet, dass Chunks nicht starr nach einer festen Länge gebildet werden, sondern flexibel an den Inhalt und die technischen Rahmenbedingungen angepasst sind. Während semantisches Chunking mit NLP die inhaltlichen Bruchstellen sucht und damit beantwortet, wo ein Schnitt gesetzt wird, konzentriert sich die adaptive Chunk-Größe darauf, wie groß ein Chunk sein sollte. Ziel ist, dass jeder Chunk eine abgeschlossene Einheit bleibt, aber weder zu klein noch zu groß ausfällt.

Feste Chunk-Größen haben den Vorteil, dass sie einfach und vorhersehbar sind. Sie stellen sicher, dass die maximale Eingabelänge der Embedding-Modelle nicht überschritten wird, und sorgen für gleichmäßige Indexgrößen in der Vektordatenbank. Allerdings schneiden sie Texte oft mitten in Absätzen oder Tabellen. Dadurch entstehen Brüche ohne semantischen Sinn, die das Retrieval unpräzise machen und die Antwortgenerierung mit unnötigem Ballast belasten.

Adaptive Chunk-Größe löst dieses Problem, indem es Dokumenteigenschaften wie Absatzlänge, Textdichte, Tabellenstrukturen und Satzgrenzen berücksichtigt. Kurze Absätze oder Listenelemente werden zusammengeführt, bis eine sinnvolle Länge erreicht ist. Sehr lange Absätze werden an logischen Stellen geteilt, bevor das Kontextfenster eines Sprachmodells gesprengt wird. Token-Grenzen dienen weiterhin als technische Obergrenze, bestimmen aber nicht mehr allein den Schnittpunkt.

Ohne adaptive Chunk-Größe entstehen Fragmente ohne Sinnzusammenhang oder übergroße Chunks, die ineffizient verarbeitet werden und die Genauigkeit mindern. Mit einem adaptiven Verfahren bleiben Einheiten intakt, die Retrievalqualität steigt und die Antwortgenerierung kann mit weniger, aber dafür relevanterem Kontext arbeiten.

Sliding Window Chunking

Sliding Window Chunking beschreibt eine Methode, bei der sich Chunks überlappen, um Übergänge zwischen Abschnitten nicht zu verlieren. Statt den Text strikt in aufeinanderfolgende Blöcke zu zerlegen, wird ein Fenster fester Länge über den Text geschoben, und der nächste Chunk beginnt nicht am Ende des vorherigen, sondern etwas früher. Dadurch enthalten die Chunks gemeinsame Passagen, die als Puffer dienen und sicherstellen, dass zusammenhängende Informationen nicht durch einen Schnitt auseinandergerissen werden.

Im Unterschied zu strukturorientiertem oder semantischem Chunking basiert Sliding Window Chunking nicht primär auf Absätzen oder Themenwechseln, sondern auf einer technischen Strategie zur Redundanzsicherung. Es wird oft zusätzlich eingesetzt, wenn der Text linear verarbeitet wird und keine klare Struktur verfügbar ist. Der Vorteil liegt darin, dass selbst bei unglücklichen Schnittstellen ein Stück Kontext doppelt vorkommt und so in einem der beiden Chunks inhaltlich vollständig bleibt.

Ohne Sliding Window Chunking gehen solche Übergänge verloren. Embeddings bilden dann nur Fragmente ab, die im Kontext isoliert wirken. Das Retrieval liefert Treffer, die zwar formal passen, aber die entscheidende Verbindung nicht enthalten. Die Antwortgenerierung arbeitet mit halben Informationen und muss schätzen oder ergänzen, was zu Ungenauigkeit führt. Sliding Window Chunking verhindert diese Brüche, indem es den Kontext bewusst doppelt vorhält.

Hierarchisches Chunking

Hierarchisches Chunking bedeutet, dass ein Dokument nicht nur auf einer Ebene in Chunks zerlegt wird, sondern gleichzeitig mehrere Granularitäten erzeugt werden. Statt ausschließlich mit Absätzen oder Abschnitten zu arbeiten, entstehen Chunks auf unterschiedlichen Ebenen der Dokumentstruktur, die miteinander verknüpft bleiben. So gibt es zum Beispiel Chunks auf Kapitel-Ebene, auf Abschnitts-Ebene und auf Absatz-Ebene. Alle Einheiten enthalten Quellenanker und Hierarchiebezüge, sodass die spätere Verarbeitung flexibel entscheiden kann, welche Granularität im Retrieval genutzt werden soll.

Der Ansatz unterscheidet sich von strukturorientiertem Chunking, das nur die offensichtliche Dokumentstruktur übernimmt, und vom semantischen Chunking, das thematische Bruchstellen sucht. Hierarchisches Chunking kombiniert beide Perspektiven und legt ein mehrschichtiges Gerüst an. Das ermöglicht es, dass Abfragen sowohl grob als auch fein beantwortet werden können.

Bsp.: Ein interner Projektbericht ist in Kapitel, Unterkapitel und nummerierte Absätze gegliedert. Beim hierarchischen Chunking wird jeder Absatz als eigener Chunk abgelegt, zusätzlich aber auch jeder Unterabschnitt und jedes Kapitel. Alle Ebenen werden durch Metadaten miteinander verknüpft. Wenn eine Anfrage eine grobe Übersicht benötigt, können die größeren Einheiten berücksichtigt werden. Für Detailfragen greift das System auf die feinen Absätze zurück.

Ohne hierarchisches Chunking muss man sich auf eine feste Granularität festlegen. Wählt man große Chunks, bleiben die Antworten unscharf und Quellenangaben ungenau. Wählt man kleine Chunks, gehen Überblick und Zusammenhang verloren. Mit einem hierarchischen Ansatz stehen beide Perspektiven bereit und die Pipeline kann je nach Abfrage die passende Ebene wählen. Dadurch steigt Präzision, Flexibilität und Nachvollziehbarkeit.

Dokumentspezifische Pipelines

Dokumentspezifische Pipelines bedeuten, dass nicht alle Dokumente mit der gleichen Standardlogik für Chunking verarbeitet werden, sondern dass je nach Dokumenttyp eigene Regeln und Verfahren bzw. Pipelines angewendet werden. Der Gedanke dahinter ist, dass ein Vertrag, ein Handbuch, eine E-Mail oder eine Tabelle völlig unterschiedliche Strukturen haben und daher auch unterschiedlich segmentiert werden müssen. Eine Pipeline kann so für jeden Typ definieren, wie Extraktion, Chunking, Anreicherung und Metadatenvergabe ablaufen.

Im Unterschied zu generischen Verfahren, die für alle Inhalte dieselbe Routine nutzen, stellen dokumentspezifische Pipelines sicher, dass die Eigenheiten eines Formats respektiert werden. Das kann zum Beispiel heißen, dass Verträge nach Paragraphen und Klauseln geschnitten werden, Handbücher nach Kapiteln und Unterkapiteln, Präsentationen nach Folien und Bullet Points, oder Tabellen nach Zeilen und Spalten. Alle Pipelines führen zu Chunks, die gleichartig eingebettet und gespeichert werden können, aber ihr Zuschnitt ist optimal auf die jeweilige Dokumentklasse abgestimmt.

Ohne dokumentspezifische Pipelines entstehen Chunks, die wichtige fachliche Strukturen nicht abbilden. Paragraphen werden zerschnitten, Tabellenzeilen verlieren ihre Spaltenbezüge, Präsentationsfolien werden in unbrauchbare Textblöcke zerlegt. Das Retrieval findet dann nur Wörter, aber nicht die fachlich relevanten Einheiten. Die Antwortgenerierung verliert Präzision und Nachvollziehbarkeit. Mit maßgeschneiderten Pipelines für die jeweiligen Dokumentarten bleibt die Struktur erhalten und das RAG-System kann sowohl juristisch präzise als auch technisch robust arbeiten.

Chunking mit Entitäten-Fokus

Chunking mit Entitäten-Fokus bedeutet, dass ein Dokument nicht nur entlang formaler Strukturen oder semantischer Abschnitte zerlegt wird, sondern gezielt an den Stellen, an denen wichtige Entitäten vorkommen. Entitäten sind zum Beispiel Personen, Unternehmen, Produkte, Projekte, Vertragsnummern, Orte, Beträge oder Zeitangaben. Die Idee ist, dass jede Entität in einem Chunk vollständig erfasst wird und ihr Kontext erhalten bleibt. So lassen sich später gezielt Suchabfragen und Filter durchführen, die direkt auf diese Entitäten zugreifen.

Der Unterschied zu anderen Verfahren liegt darin, dass hier die Entität selbst den Schnittpunkt bestimmt. Während strukturorientiertes Chunking an Absätzen orientiert ist und semantisches Chunking an Themenwechseln, sorgt das Entitäten-fokussierte Chunking dafür, dass alle Textstellen mit Bezug auf eine Entität in einem Chunk zusammengehalten oder zumindest klar markiert werden.

Ohne Chunking mit Entitäten-Fokus verteilt sich die Information zu einer Entität über mehrere unverbundene Chunks. Das Retrieval findet dann einzelne Textfragmente, aber nicht den Gesamtzusammenhang. Eine Antwort über das Projekt ORN 2025 liefert möglicherweise nur die Hälfte der Informationen oder vermischt Daten aus verschiedenen Projekten. Durch Entitäten-fokussiertes Chunking entsteht eine klare Sammlung pro Entität, die gezielt gesucht, gefiltert und korrekt in Antworten eingebunden werden kann.

Tabellen- und Listenbewusstes Chunking

Tabellen- und listenbewusstes Chunking stellt sicher, dass strukturierte Inhalte wie Tabellen oder Aufzählungen nicht in linearen Fließtext aufgelöst werden, sondern als eigenständige Chunks erhalten bleiben. Während normale Verfahren Texte in Absätze oder semantische Einheiten teilen, erkennt dieses Verfahren explizit tabellarische Strukturen, Nummerierungen und Aufzählungszeichen und bildet daraus logische Segmente. Ziel ist, dass Spalten, Zeilen oder Listenelemente ihre Bezüge behalten, damit später beim Retrieval klar bleibt, welche Information wozu gehört.

Ein wichtiger Unterschied zu rein textorientierten Verfahren liegt darin, dass hier die innere Struktur erhalten bleibt. Eine Tabelle wird nicht als langer Textblock behandelt, sondern entweder als kompletter Tabellen-Chunk gespeichert oder in einzelne Zeilen- oder Spalten-Chunks zerlegt, je nach Anwendungsfall. Bei Listen kann der gesamte Block als ein Chunk abgelegt werden, gleichzeitig aber auch jedes Listenelement als eigenständiger Chunk mit Verweis auf die übergeordnete Liste.

Ohne tabellen- und listenbewusstes Chunking verliert sich die Struktur in linearem Text. Zahlen stehen ohne Bezug nebeneinander, Listenpunkte gehen im Fließtext unter und das Retrieval erkennt Zusammenhänge nur über Wörter, nicht über die tabellarische Logik. Die Antwortgenerierung kann dann keine präzisen Belege liefern, sondern nur unscharfe Zitate aus langen Textblöcken. Mit tabellen- und listenbewusstem Chunking bleiben diese Strukturen intakt und machen Antworten deutlich präziser und nachvollziehbarer

Domaingetriebene Regeln

Domaingetriebene Regeln beim Chunking bedeuten, dass die Zerlegung von Dokumenten nicht nur nach allgemeinen Strukturen oder semantischen Einheiten erfolgt, sondern zusätzlich nach spezifischen Vorgaben, die aus dem jeweiligen Fachbereich stammen. Diese Regeln spiegeln die Arbeitsweise und Terminologie der Organisation wider und stellen sicher, dass fachlich relevante Einheiten als eigene Chunks abgebildet werden.

Der Unterschied zu generischen Verfahren liegt darin, dass hier nicht nur technische Kriterien wie Zeichenlänge oder Absatzgrenzen gelten, sondern explizite Vorgaben aus der Domäne. In einem juristischen Kontext kann das zum Beispiel heißen, dass Paragraphen und Klauseln niemals aufgespalten werden. In der Medizin könnte jede Diagnose oder jeder Befundblock ein eigener Chunk sein. In der Softwareentwicklung wiederum können Codefunktionen oder Konfigurationsblöcke als unteilbare Einheiten behandelt werden.

Ohne domaingetriebene Regeln entstehen willkürliche Schnitte innerhalb wichtiger Fachstrukturen. Eine Klausel wird auseinandergerissen, eine Diagnose verteilt sich auf mehrere Fragmente oder eine Codefunktion taucht in unzusammenhängenden Teilen auf. Das Retrieval liefert dann nur Bruchstücke, die Antwortgenerierung verliert fachlichen Zusammenhang und Nachvollziehbarkeit. Mit domaingetriebenen Regeln wird sichergestellt, dass die Zerlegung den Anforderungen des Fachgebiets folgt und fachliche Konsistenz bewahrt bleibt.

Token Budget gesteuertes Chunking abhängig vom Zielmodell

Token Budget gesteuertes Chunking abhängig vom Zielmodell bedeutet, dass die Größe der Chunks so gewählt wird, dass sie optimal zur maximalen Kontextlänge des Sprachmodells passt. Sprachmodelle können nur eine bestimmte Anzahl an Tokens gleichzeitig verarbeiten. Bei kleinen Kontextfenstern müssen Chunks deshalb sehr kompakt sein, um neben der Nutzerfrage und der geplanten Antwort in das Fenster zu passen. Bei großen Kontextfenstern dürfen Chunks größer sein, weil mehrere davon gleichzeitig berücksichtigt werden können, ohne die technischen Grenzen zu sprengen. Es geht dabei nicht darum, eine Hierarchie von großen und kleinen Chunks aufzubauen, sondern darum, die Größe jedes einzelnen Chunks an das verfügbare Tokenbudget anzupassen.

Ein Handbuch mit langen Kapiteln würde bei einem kleinen Kontextfenster in kleinere Segmente von wenigen hundert Tokens zerlegt. Bei einem großen Kontextfenster können die Segmente länger bleiben, sodass pro Chunk ein vollständiger Sinnabschnitt wie ein Konfigurationsschritt abgebildet wird. Dennoch bleibt die Granularität so fein, dass das Retrieval gezielt relevante Segmente auswählt, ohne dass ein kompletter zehnseitiger Block als unhandlicher Chunk entsteht.

Ohne diese Anpassung würden Chunks entweder abgeschnitten oder ineffizient verarbeitet. Mit einem modellbewussten Zuschnitt bleibt das Verhältnis zwischen Präzision, Effizienz und Ausnutzung der Modellkapazität erhalten.

Mehrkörnige Speicherung derselben Stelle sowohl als Abschnitt als auch als Absatz mit Verknüpfung

Mehrkörnige Speicherung derselben Stelle sowohl als Abschnitt als auch als Absatz mit Verknüpfung bedeutet, dass ein Dokument an einer Stelle in mehreren Granularitäten abgelegt wird. Ein längerer Abschnitt wird also nicht nur als ein großer Chunk gespeichert, sondern zusätzlich auch in kleinere Chunks zerlegt, etwa auf Absatzebene. Beide Varianten werden im Index verknüpft, sodass das Retrieval je nach Anfrage die passende Detailtiefe auswählen kann.

Der Unterschied zu hierarchischem Chunking ist, dass hier nicht das gesamte Dokument in vielen Ebenen aufgebaut wird, sondern gezielt einzelne Stellen doppelt oder mehrfach gespeichert werden. Es handelt sich also um eine pragmatische Ergänzung, wenn man weiß, dass ein Abschnitt sowohl im Ganzen als auch in seinen Details relevant sein kann.

Ein Beispiel ist ein juristischer Vertrag, in dem eine Haftungsklausel aus mehreren Absätzen besteht. Diese Klausel wird als ein großer Chunk gespeichert, damit sie in voller Länge abgerufen werden kann, wenn jemand nach „Haftung“ sucht. Gleichzeitig werden die einzelnen Absätze als eigene Chunks gespeichert, sodass bei einer gezielten Frage nach „Haftungsbegrenzung auf Summe X“ nicht der gesamte Block, sondern nur der passende Absatz zurückkommt. Über Metadaten bleibt klar, dass beide Varianten denselben Ursprung haben.

Ohne mehrkörnige Speicherung muss man sich für eine Granularität entscheiden. Nutzt man nur große Chunks, werden die Antworten unscharf und überladen, da das Modell zu viel Kontext bekommt. Nutzt man nur kleine Chunks, verliert man den Gesamtzusammenhang und schwächt die Nachvollziehbarkeit. Mit mehrkörniger Speicherung stehen beide Varianten parallel bereit, Retrieval und Antwortgenerierung können situationsabhängig wählen und Ergebnisse bleiben sowohl präzise als auch vollständig.

Strikte Blockgrenzen für Code, Tabellen und Formeln

Strikte Blockgrenzen für Code, Tabellen und Formeln bedeutet, dass diese speziellen Strukturen beim Chunking niemals zerschnitten werden, sondern als geschlossene Einheiten behandelt werden. Der Grund ist, dass solche Blöcke ihre Bedeutung nur in vollständiger Form entfalten. Ein halber Codeblock lässt sich nicht mehr ausführen, eine zerschnittene Tabelle verliert ihre Spaltenbezüge und eine Formel ohne alle Bestandteile ist inhaltlich wertlos.

Dieser Ansatz unterscheidet sich von Verfahren, die Texte frei nach Zeichenlänge oder Absatzgrenzen teilen. Während man im Fließtext inhaltlich weniger Schaden anrichtet, wenn eine Zerlegung mitten im Satz geschieht, führt das Zerschneiden von strukturierten Blöcken fast immer zu einem Informationsverlust. Deshalb werden für Code, Tabellen und Formeln harte Grenzen definiert, die beim Chunking respektiert werden.

Ohne diese Maßnahme entstehen unbrauchbare Fragmente. Eine Formel könnte nur die linke Seite einer Gleichung enthalten, eine Tabelle nur die Hälfte der Spalten oder ein Codeblock nur den Kopf ohne Rumpf. Das Retrieval liefert dann Treffer, die unvollständig sind, und die Antwortgenerierung muss raten, was fehlt. Strikte Blockgrenzen stellen sicher, dass komplexe Strukturen intakt bleiben und korrekt als Wissenseinheit in den RAG Prozess eingehen.

Fazit

Die Optimierung einer RAG Anwendung beginnt bei der Dokumentenaufbereitung und dem Chunking. Beide Phasen legen die Grundlage für alle weiteren Schritte wie Embedding, Indexierung, Retrieval und Antwortgenerierung. Nur wenn Texte zuverlässig extrahiert, bereinigt, inhaltlich strukturiert und sinnvoll segmentiert werden, können spätere Verfahren präzise arbeiten. Fehler oder Auslassungen in diesen frühen Phasen wirken sich auf den gesamten Prozess aus. Die Folgen reichen von ungenauen Embeddings über ineffizientes Retrieval bis hin zu schwachen oder widersprüchlichen Antworten.

Dieser Beitrag ist Teil 1 einer mehrteiligen Reihe. In den nächsten Teilen werden weitere Verfahren beschrieben, die Embedding, Vektorindexierung und Speicherung, Retrieval, Antwortgenerierung sowie Feedback und kontinuierliche Verbesserung behandeln. Ziel ist es, Schritt für Schritt zu zeigen, wie ein RAG System durch gezielte Maßnahmen robuster, präziser und nachvollziehbarer wird.

Weiter mit Teil 2.

About the Author

aaron

Administrator

Visit Website View All Posts