Dokumente vor RAG reinigen

Ein Dokument für Retrieval-Augmented Generation (RAG) zu reinigen heißt, alles zu entfernen, was nicht Inhalt ist — die Kopfzeilen, Fußzeilen, Seitenzahlen und wiederholten Standardtexte, die ein PDF auf jeder Seite trägt — bevor der übrige Text in Chunks geteilt, eingebettet und in einem Vektorindex gespeichert wird. Es ist der unglamouröseste Schritt einer RAG-Pipeline und der, der still entscheidet, ob die Abfrage funktioniert: Ein Index, der aus ungereinigtem Text gebaut ist, speichert dasselbe Beiwerk hunderte Male und ruft es ab, als wäre es Wissen. Dieser Artikel erklärt, warum Beiwerk Einbettungen vergiftet, wie Chunking wirklich funktioniert, warum Deduplizierung vor das Einbetten gehört, was man entfernen und was man behalten sollte, und wie man bewertet, ob die Reinigung geholfen hat. Um die Reinigung selbst zu machen, nutzen Sie den Dokumentenreiniger und lesen Sie Ihre eigenen Ergebnisse neben diesem Leitfaden.

Warum Seitenbeiwerk Einbettungen vergiftet

Ein Einbettungsmodell verwandelt einen Textchunk in einen Vektor, der erfassen soll, wovon der Chunk handelt. Füttern Sie es mit einem Chunk, der zur Hälfte aus Berichtstitel, Vertraulichkeitsfußzeile und Seitenzahl besteht, und der Vektor erfasst auch das getreu — was bedeutet, dass jeder Chunk in einem langen Dokument auf dasselbe Beiwerk zudriftet und Chunks, die im Vektorraum weit auseinanderliegen sollten, künstlich nahe enden, weil sie eine Kopfzeile teilen. Die Abfrage tut dann genau das, worum man sie gebeten hat: Gefragt nach dem Abschnitt über die Rückerstattungsrichtlinie, gibt sie fünf Chunks zurück, deren stärkstes gemeinsames Signal der Firmenname in der Kopfzeile ist. Niemand hat einen Modellierungsfehler gemacht. Der Index wurde mit Rauschen in voller Stärke bestückt, das sich auf jeder Seite wiederholt, und Rauschen, das sich wiederholt, ist für ein System, das Ähnlichkeit zählt, von Signal nicht zu unterscheiden.

Der Schaden ist schlimmer als Verdünnung. Beiwerk-Chunks können die Abfrage glatt gewinnen: Eine Frage, die wie die Fußzeile formuliert ist — über Vertraulichkeit, Dokumentenkontrolle oder Versionierung — trifft den Fußzeilen-Chunk, der zweihundertmal eingebettet wurde, besser als den einen Absatz, der sie wirklich beantwortet. Seitenzahlen erzeugen einen subtileren Fehler, indem sie dem Modell beibringen, dass nackte Zahlen Inhalt sind, sodass ein Chunk, der auf „42“ endet, zurückzitiert werden kann, als bedeutete die Zahl etwas. Und jeder Beiwerk-Chunk belegt einen Platz in einer endlichen Top-k-Ergebnismenge und drängt einen wirklich relevanten Chunk aus dem Kontext, den das Modell erhält. Reinigung ist daher kein kosmetisches Aufräumen; sie entfernt einen systematischen Konkurrenten Ihres eigenen Inhalts in Ihrem eigenen Index.

Chunking-Grundlagen: Größe, Überlappung und Grenzen

Chunking ist die Entscheidung, welche Einheit eingebettet wird, und sie hat drei Regler. Die Größe tauscht Fokus gegen Kontext: Kleine Chunks, ein paar hundert Zeichen, betten eine Idee scharf ein und rufen präzise ab, können aber ohne den Satz ankommen, der der Idee ihre Bedingungen gibt; große Chunks, mehrere tausend Zeichen, tragen ihren Kontext mit sich, vermischen aber mehrere Ideen zu einem Durchschnittsvektor, sodass keine von ihnen stark abruft. Die meisten Dokumentkorpora landen irgendwo in der Mitte — ungefähr 500 bis 1.000 Zeichen sind eine vernünftige Startregion — und die richtige Antwort entscheidet sich daran, Ihre eigenen Fragen an Ihren eigenen Dokumenten zu testen, nicht daran, eine Zahl aus einem Framework-Standard zu kopieren. Die LangChain-Dokumentation zu Textsplittern ist eine gute Karte der Splitterfamilien, von Zeichen- und rekursiven Splittern bis zu strukturbewussten.

Die Überlappung ist eine Versicherung gegen den zweiten Regler, die Grenzen. Ein Splitter, der alle 800 Zeichen schneidet, egal welche Struktur, wird irgendwann eine Definition halbieren, und keine Hälfte ruft gut ab oder liest sich gut. An Grenzen zu teilen — zuerst Absätze, dann Sätze, dann Leerzeichen, wie rekursive Splitter es tun — hält Einheiten die meiste Zeit ganz, und eine bescheidene Überlappung von zehn bis zwanzig Prozent wiederholt den Rand eines Chunks am Anfang des nächsten, sodass ein Schnitt, der trotzdem geschieht, seinen Kontext nicht verwaist. Die Hierarchie in der LlamaIndex-Dokumentation zu Node-Parsern macht denselben Punkt von der Lader-Seite: Parsen Sie in Knoten, die das Dokument respektieren, und teilen Sie dann. Aber nichts davon rettet Beiwerk: Die Überlappung wiederholt die Kopfzeile getreu auch in den nächsten Chunk, weshalb die Reinigung vor dem Chunking kommt, nie danach.

Deduplizieren Sie vor dem Einbetten

Duplikate sind der zweite systematische Schadstoff, und sie kommen in zwei Arten. Die erste ist die Duplizierung ganzer Dokumente: dasselbe PDF zweimal unter verschiedenen Dateinamen indexiert, die alte Version neben der neuen liegengelassen, der E-Mail-Anhang neben der Kopie auf dem gemeinsamen Laufwerk gespeichert. Die zweite ist im Dokument selbst: der Haftungsausschluss auf der Titelseite und wieder im Anhang, die Zusammenfassung, die am Kopf jedes Kapitels wiederholt wird, die Tabelle, die in den Haupttext und in den Anhang eingefügt wurde. Beide Arten haben dieselbe Wirkung auf die Abfrage — duplizierter Text wird wiederholt eingebettet, also wird er wiederholt abgerufen und füllt die Top-k mit Kopien einer Passage, während andere Passagen nie auftauchen — und dieselbe Wirkung auf die Kosten, weil Sie für das Einbetten und Speichern jeder Kopie zahlen.

Deduplizierung ist vor dem Einbetten am billigsten, wenn sie noch ein Zeichenfolgenvergleich ist. Exakte Duplikate fallen der Normalisierung zum Opfer: Leerraum kollabieren, das Seitenbeiwerk ignorieren, das Sie schon entfernt haben, das Ergebnis hashen und eine Kopie behalten. Nahe Duplikate — derselbe Absatz mit geändertem Datum oder umnummerierter Überschrift — brauchen einen Ähnlichkeitsdurchlauf, aber selbst ein grober fängt den Standardtext, der den meisten Schaden anrichtet. Zwei Vorsichten halten die Deduplizierung ehrlich. Erstens: Behalten Sie das erste Vorkommen und notieren Sie, wo die Kopien waren; eine Warnung, die in zwei Kapiteln wiederholt wird, kann eine absichtliche Sicherheitsvorrichtung sein, und sie ganz aus dem Datensatz zu entfernen ist eine andere Entscheidung, als sie aus dem Index zu entfernen. Zweitens: Deduplizieren Sie nach der Reinigung, nicht davor: Zwei Seiten, die sich nur durch ihre Seitenzahl unterscheiden, sind Duplikate von Inhalt, der in verschiedenes Beiwerk gewickelt ist, und nur der gereinigte Text enthüllt das.

Was man entfernen und was man behalten sollte

Entfernen Sie, was sich wiederholt, ohne zu informieren: laufende Köpfe und Füße, Seitenzahlen, Wasserzeichen, Vertraulichkeitsbanner, generierte „Gedruckt am“-Zeilen und die Navigationskrumen, die ein Web-zu-PDF-Export auf jede Seite stempelt. Behalten Sie, was strukturiert: echte Überschriften, weil sie das stärkste Chunk-Grenzensignal sind, das Sie haben, und oft in die Chunk-Metadaten gehören; Bildunterschriften, weil eine Unterschrift häufig der einzige Text ist, der sagt, was die Abbildung zeigt; Tabelleninhalt, sorgfältig behandelt, weil eine entkleidete Tabelle die Zeilen- und Spaltenköpfe verliert, die ihren Zahlen Bedeutung geben; und Listen, deren Elemente natürliche Einheiten sind. Der Grenzfall ist das Inhaltsverzeichnis. Als Chunks sind Verzeichniszeilen Beiwerk — eine Liste von Titeln und Seitenzahlen, die vage zu jeder Anfrage passt und keine beantwortet —, aber als Metadaten ist dieselbe Verzeichnisseite eine Karte des Dokuments. Entfernen Sie sie aus dem eingebetteten Text, behalten Sie sie in Ihren Notizen über den Korpus.

Dasselbe Urteil gilt im Dokumentenreiniger selbst: Beiwerk und Seitenzahlen sind standardmäßig angehakt, weil sie fast immer sicher zu entfernen sind, während doppelte Absätze nie standardmäßig angehakt sind, weil Wiederholung manchmal der Sinn ist. Auch Extraktions-Ehrlichkeit zählt hier. Ein PDF ist ein strukturiertes Format — die ISO-PDF-Norm, ISO 32000, definiert Seiten als Inhaltsströme von Zeichen- und Textoperationen, nicht als fließenden Text —, sodass jeder Extraktor die Lesereihenfolge nur annähert und ein gescanntes PDF überhaupt keine Textschicht hat, bis OCR ihm eine gibt. Wenn Ihre Quelldokumente auch aus anderen Gründen zählen, behandelt der Begleitartikel über Ihre PDFs als Teil der Barrierefreiheit Ihrer Website die getaggte Struktur, die sowohl Screenreadern als auch Extraktoren hilft.

Die Abfrage nach der Reinigung bewerten

Reinigung ist eine Hypothese — die Abfrage wird sich verbessern — und Hypothesen über Suchqualität sind mit beschämend wenig Maschinerie testbar. Stellen Sie zwanzig bis fünfzig echte Fragen zusammen, die Ihre Nutzer wirklich stellen, mit der Passage, die jede beantworten sollte, von Hand notiert. Führen Sie sie gegen den ungereinigten Index und den gereinigten Index aus, mit demselben Retriever, denselben Chunk-Einstellungen und derselben Top-k, und vergleichen Sie zwei Dinge: wie oft die richtige Passage überhaupt in den Ergebnissen erscheint und wie hoch sie steht, wenn sie erscheint. Dieses Paar — Recall und Rang — ist die Anzeigetafel. Wenn die Reinigung wirkt, hören Beiwerk-Chunks auf, in Ergebnissen zu erscheinen, die richtigen Passagen steigen auf, und die Fragen, die früher scheiterten, weil eine Fußzeile die Antwort überragte, beginnen zu bestehen.

Lesen Sie dann die Fehler, weil die Zahlen allein Ihnen schmeicheln werden. Ein gereinigter Index kann Recall gewinnen und dabei eine Frage verlieren, deren Antwort wirklich in einer wiederholten Zusammenfassung lebte, die Sie wegdedupliziert haben, oder in einer Kopfzeile, die den Produktnamen trug, den jeder Chunk brauchte. Diese Verluste sind Information: Sie sagen Ihnen, jenes Element als Metadaten zu behalten oder den Dokumenttitel absichtlich jedem Chunk voranzustellen, statt ihn versehentlich zweihundertmal einzubetten. Führen Sie die Bewertung erneut aus, wann immer sich Korpus, Splitter oder Einbettungsmodell ändern, und halten Sie die Fragenmenge versioniert neben dem Index. RAG-Qualität ist keine Starteigenschaft; sie ist eine Wartungseigenschaft, und eine kleine feste Testmenge ist das, was „es fühlt sich besser an“ in etwas Verteidigbares verwandelt.

Quellen und weiterführende Lektüre

Häufige Fragen

Wie sehr verbessert die Reinigung die Abfrage wirklich?

Es hängt davon ab, wie beiwerk-schwer Ihre Dokumente sind, und das ist messbar: Zählen Sie die Zeilen, die sich über Seiten wiederholen, bevor Sie reinigen, und testen Sie eine feste Menge echter Fragen gegen den Index vorher und nachher. Lange Berichte mit starken Kopfzeilen gewinnen am meisten, weil Beiwerk einen Zehntel oder mehr jedes Chunks belegen kann; kurze, saubere Dokumente gewinnen vielleicht wenig. Die ehrliche Methode ist die Vorher-nachher-Bewertung im letzten Abschnitt, kein versprochener Prozentsatz.

Soll ich vor oder nach dem Chunking reinigen?

Immer davor. Ein ungereinigtes Dokument zu chunken bettet das Beiwerk in jeden Chunk ein, überlappt es in den nächsten und streut Seitenzahlen durch den Index, wo kein späterer Schritt sie zuverlässig entfernen kann. Reinigen Sie zuerst den extrahierten Text und chunken Sie dann das Ergebnis — der Dokumentenreiniger erzeugt gereinigten Text und fertige JSONL-Chunks in dieser Reihenfolge aus genau diesem Grund.

Mit welcher Chunk-Größe und Überlappung soll ich starten?

Starten Sie bei ungefähr 800 Zeichen mit Teilung an Absatzgrenzen und einer bescheidenen Überlappung, und stimmen Sie dann gegen Ihre eigene Fragenmenge ab. Kleinere Chunks rufen präziser ab, tragen aber weniger Kontext; größere tun das Gegenteil. Framework-Leitfäden wie die in den Quellen verlinkte LangChain-Dokumentation zu Textsplittern beschreiben die Splitterfamilien, aber die richtigen Zahlen für Ihren Korpus kommen aus der Bewertung, nicht aus einem Standard.