Deduplikation und Datenbereinigung für AI im Jahr 2026

Ein Unternehmen verbindet drei Systeme: Confluence, SharePoint und eine alte FAQ-Datenbank in Excel. Nach der ersten RAG-Indizierung antwortet das System unkonkret oder zitiert widersprüchliche Verfahren. Es liegt kein Fehler im Modell oder in der Qdrant-Konfiguration vor. Das Problem tritt früher auf: Dieselben Dokumente erscheinen mehrmals im Index, in leicht unterschiedlichen Versionen, und jede Version konkurriert um denselben Platz in den Suchergebnissen.

Deduplikation und Datenbereinigung sind Arbeiten, die vor der Indizierung stattfinden, nicht danach. Wenn sie übersprungen werden, treten die Symptome schrittweise auf: Der Assistent antwortet inkonsistent, die Token-Kosten steigen, und die Qualitätsmetriken verbessern sich trotz Prompt-Tuning nicht.

RAG funktioniert nach dem Ranking-Prinzip: Das System ruft die Fragmente ab, die semantisch am besten zur Anfrage passen, und gibt sie dem Modell als Kontext. Wenn im Index fünf Versionen desselben Verfahrens vorhanden sind, gelangen drei davon in den Kontext, anstatt drei verschiedener, sich ergänzender Dokumente. Das Modell erhält weniger Informationen, als es aus einem sauberen Korpus erhalten könnte.

Duplikate verursachen auch konkrete Kosten. Jedes Fragment belegt Token im Kontextfenster. Bei Limits von 8.000 oder 128.000 Token sind sich wiederholende Inhalte verschwendeter Platz, für den Sie bezahlen oder der begrenzt, was das Modell gleichzeitig analysieren kann.

Der dritte Effekt ist Widersprüchlichkeit. Die Version eines Verfahrens aus dem Jahr 2022 und die Version aus dem Jahr 2024 können denselben Schritt unterschiedlich beschreiben. Das Modell weiß nicht, welche aktuell ist, und zitiert beide oder wählt willkürlich aus. Von außen sieht das wie eine „Halluzination“ aus, aber die Ursache liegt in der Wissensbasis, nicht im Modell.

Bei Cashcrown beobachten wir, dass in Projekten, in denen Kunden mit ungeordneten Korpora kommen, ein erheblicher Teil der Vorbereitungsarbeit genau auf die Deduplikation entfällt, nicht auf die Modellkonfiguration. Wir können keine genauen Zahlen nennen, wie sehr sich die Antwortqualität verbessert, da dies vom Zustand der jeweiligen Daten abhängt. Sie wissen, dass es ein Problem gibt, wenn die Metriken für Faithfulness und Relevance trotz Änderungen an den Prompts nicht steigen.

Es gibt keine einzelne Methode, die alle Arten von Duplikaten erkennt. In der Praxis werden drei Ebenen nacheinander eingesetzt, da jede nachfolgende Ebene rechenintensiver ist.

Ebene 1: Exakte Übereinstimmung (exact match). Es wird der Hash SHA-256 oder MD5 des gesamten Dokuments oder seines Fragments nach der Normalisierung (Kleinschreibung, Entfernen von Leerzeichen) berechnet. Wenn zwei Dateien denselben Hash haben, wird eine ohne weitere Analyse verworfen. Dies ist die schnellste Ebene, mit null LLM-Kosten. Sie eignet sich für Dateien, die zwischen Ordnern kopiert oder durch zwei Integrationen gleichzeitig synchronisiert werden.

Ebene 2: Fuzzy-Matching (fuzzy match). Algorithmen wie die Levenshtein-Distanz, Jaccard-Ähnlichkeit auf N-Grammen oder MinHash erkennen Dokumente, die sich geringfügig unterscheiden: ein Absatz hinzugefügt, ein Tippfehler korrigiert, Formatierung geändert. Die Ähnlichkeitsschwelle wird empirisch festgelegt, typischerweise deutet ein Jaccard-Wert über 0,85-0,90 auf einen Duplikat-Kandidaten hin. Die Entscheidung über Zusammenführung oder Verwerfung bleibt zur Bestätigung durch einen Menschen.

Ebene 3: Semantische Erkennung (embedding-based). Sie generieren Embeddings für jedes Fragment und messen die Kosinus-Ähnlichkeit. Fragmente mit einer Ähnlichkeit über einem Schwellenwert (typischerweise 0,92-0,95, kalibriert an einem Goldstandard-Testset) sind Kandidaten zur Zusammenführung. Diese Ebene erfasst Fälle, in denen zwei Dokumente dasselbe anders ausdrücken: geänderte Terminologie, andere Übersetzung, umgeschriebenes Verfahren mit derselben Bedeutung. Details zur Vektorähnlichkeit im Artikel semantische Suche und Embeddings im Unternehmen.

Jede höhere Ebene erfordert eine teurere Überprüfung. Daher ist die Reihenfolge sinnvoll: Zuerst filtern Sie mit dem, was günstig ist, und wenden Semantik nur dort an, wo die beiden vorherigen Ebenen keine klare Antwort liefern.

Deduplikation ohne vorherige Normalisierung erzeugt falsche Unterscheidungen. Dasselbe Dokument, einmal als PROCEDURA_v3_final.docx und einmal als procedura v3 final.docx gespeichert, hat unterschiedliche Hashes. Die Textnormalisierung entfernt diese scheinbaren Unterschiede vor dem Vergleich.

Die Normalisierung sollte deterministisch und für Audit-Zwecke umkehrbar sein: Sie überschreiben nicht die Originale, sondern schreiben in eine separate Pipeline, die Daten für die Indizierung vorbereitet. Die Originale bleiben in der Quelle unverändert.

Ein nahes Duplikat (near-duplicate) ist ein schwierigeres Problem als ein identisches Duplikat, da es weniger sichtbar ist. Zwei Fragmente eines Verfahrensdokuments, die sich in einem Absatz über einen Sonderfall unterscheiden, können wie Duplikate aussehen, sind aber komplementär.

Bei der semantischen Suche stören nahe Duplikate das Ranking auf spezifische Weise: Fragment A und seine fast identische Kopie B verstärken sich gegenseitig in den Ergebnissen, da die Suchmaschine annimmt, dass das Thema „gut repräsentiert“ ist. Andere, weniger wiederholte Inhalte fallen im Ranking, obwohl sie nützlicher sein könnten.

Praktischer Ansatz für nahe Duplikate im RAG-Korpus:

• Gruppieren Sie Kandidaten nach semantischer Ähnlichkeit (Cluster aus Embeddings).
• Für jede Gruppe: Behalten Sie die Version mit dem neuesten Änderungsdatum oder dem vollständigsten Inhalt.
• Ältere Versionen werden ins Archiv verschoben, nicht in den aktiven Index.
• Versionen, deren Beziehung unklar ist (z. B. unterscheiden sie sich in einem wichtigen technischen Detail), werden zur manuellen Überprüfung markiert.

Die semantische Schwelle für nahe Duplikate wird normalerweise niedriger gesetzt als für identische, da Sie konservativ sein möchten: Es ist besser, einen Kandidaten zur Überprüfung zu markieren, als zwei Dokumente automatisch zusammenzuführen, die sich als wichtig unterschiedlich herausstellen.

Die Datenbereinigung für AI umfasst nicht nur Deduplikation. Parallel muss die Erkennung und Verarbeitung von personenbezogenen Daten (PII) in jedem Dokument vor der Indizierung erfolgen.

Typische Arten von PII in Unternehmenskorpora: Namen und Nachnamen von Kunden, E-Mail-Adressen, Telefonnummern, PESEL- und NIP-Nummern, Wohnadressen, Bestellnummern mit Personenbezug, Sitzungs-IDs. Alle unterliegen der RODO und erfordern eine rechtliche Grundlage für die Verarbeitung, Minimierung sowie die Handhabung des Rechts auf Löschung.

In der Praxis gibt es drei Wege:

Maskierung vor der Indizierung. PII wird durch Token ersetzt ([EMAIL_1], [PESEL_1]) noch in der Pipeline zur Datenaufbereitung, vor der Generierung von Embeddings. In den Index gelangt der Text mit Token, nicht mit den echten Werten. Eine detaillierte Architektur der Maskierung im Artikel Anonymisierung und Maskierung von PII vor AI.

Ausschluss des Dokuments aus dem Index. Wenn ein Dokument PII enthält, die für seinen Sinn essenziell sind und nicht anonymisiert werden können, ohne den Wert zu verlieren (z. B. Transkription eines Kundengesprächs), gelangt es nicht in den Hauptindex. Es kann in eine dedizierte Sammlung mit Zugriffskontrolle und strenger rechtlicher Grundlage aufgenommen werden.

Datenextraktion und statistische Anonymisierung. Für Dokumente, die der Analyse dienen (Berichte, Umfragen), können Aggregate statt Einzeldaten extrahiert werden. Das Modell arbeitet dann mit Statistiken, nicht mit personenbezogenen Daten.

Tools zur automatischen PII-Erkennung in polnischen Texten: Microsoft Presidio (mit NER-Modell für Polnisch), spaCy mit dem Modell pl_core_news_lg, Regex-Regeln für PESEL/NIP/Telefon-Muster. Keines davon bietet 100 % Recall bei rohen Unternehmensdaten, insbesondere bei Eigennamen, die wie allgemeiner Text aussehen. Daher ist die automatische PII-Erkennung der erste Schritt, nicht der einzige, besonders bei sensiblen personenbezogenen Daten (Art. 9 RODO).

Mehr zur Vorbereitung von Daten unter Berücksichtigung von RODO und AI Act im Artikel wie man Unternehmensdaten für AI vorbereitet.

Automatisierung beschleunigt Deduplikation und Bereinigung, aber sie eliminiert nicht die Notwendigkeit menschlicher Entscheidungen. Es gibt mehrere Punkte, an denen automatisches Handeln unzulässig oder zu riskant ist.

Zusammenführung von Kundendatensätzen im CRM. Ein Fuzzy-Matching-Algorithmus kann feststellen, dass „Jan Kowalski, ul. Lipowa 5“ und „Jan Kowalski, ul. Lipowa 5a“ wahrscheinlich dieselbe Person sind. Wahrscheinlich, nicht sicher. Die Zusammenführung der Bestellhistorie, Kontakte und Angebote zweier verschiedener Kunden mit ähnlichen Daten ist ein Fehler mit realen geschäftlichen und rechtlichen Konsequenzen (RODO verlangt Genauigkeit der Daten). Die Automatisierung schlägt Kandidaten zur Zusammenführung vor, der Mensch bestätigt oder lehnt jeden Fall ab.

Löschen von Dokumentversionen. Eine ältere Version eines Verfahrens kann als Nachweis im Falle eines Audits oder einer Reklamation benötigt werden. Das automatische Löschen einer „älteren Duplikatversion“ kann Material entfernen, das das Unternehmen aufbewahren muss. Archivieren Sie, statt zu löschen, und überlassen Sie die Entscheidung über die physische Löschung einer Person, die den rechtlichen Kontext des Dokuments kennt.

Sensible Daten nach AI Act. Bei Dokumenten in Hochrisikobereichen (HR, Kreditbewertung, Rekrutierungssysteme) erfordert jede Änderung im Trainingsdatensatz oder indizierten Daten eine Dokumentation und Genehmigung durch einen Menschen, gemäß den Anforderungen von Art. 10 AI Act (Datenqualität und -management). Automatische Deduplikation ohne Audit-Trail ist hier nicht konform.

Grenze der semantischen Sicherheit. Wenn zwei Fragmente eine Vektorähnlichkeit zwischen 0,85 und 0,92 aufweisen (Grauzone), ist das semantische Modell nicht sicher genug, um selbstständig zu entscheiden. Solche Paare gelangen in eine manuelle Überprüfungswarteschlange. Diese Schwelle wird einmal an einem Goldstandard-Beispielset vor dem Start der Pipeline kalibriert.

Das Muster, das wir anwenden: Automatisierung schlägt vor, die Entscheidungsliste geht an die für die jeweilige Datenbank verantwortliche Person, die Entscheidung wird mit Datum und Begründung protokolliert. Mehr zum Management von Entscheidungen über Datensätze im Artikel Daten-Governance für AI.

Normalisierung entfernt scheinbare Unterschiede in der Darstellung desselben Textes: Änderung der Groß-/Kleinschreibung, Leerzeichen, Unicode-Kodierung diakritischer Zeichen. Deduplikation erkennt und behandelt tatsächliche Inhaltswiederholungen auf drei Ebenen: identisch, fuzzy und semantisch. Ohne Normalisierung kann dasselbe Dokument in zwei Kodierungen nicht als Duplikat durch den Hash erkannt werden, daher ist Normalisierung immer der erste Schritt.

Der Schwellenwert wird empirisch kalibriert: Bereiten Sie 100-200 Dokumentenpaare mit manueller Kennzeichnung „Duplikat / kein Duplikat“ vor, führen Sie das Embedding-Modell aus und messen Sie Precision und Recall bei verschiedenen Werten. Ein typischer Startpunkt ist eine Kosinus-Ähnlichkeit von 0,92-0,95 für kurze Fragmente, niedriger für längere Dokumente. Wählen Sie einen Schwellenwert, der falsche Zusammenführungen minimiert, da die Zusammenführung zweier unterschiedlicher Datensätze schwieriger rückgängig zu machen ist als das Belassen eines Kandidaten zur manuellen Überprüfung.

Bei kleinen, homogenen Datenbanken (einige hundert Dokumente aus einer Quelle) sind Duplikate selten und der Einfluss auf die Qualität gering. Bei Datenbanken mit mehr als einigen tausend Dokumenten aus mehreren Systemen (CRM, SharePoint, Confluence, E-Mails) treten Duplikate fast immer auf, da dieselben Informationen an vielen Stellen zirkulieren. Ein Zeichen dafür, dass Deduplikation benötigt wird: Identische Testfragen erhalten bei aufeinanderfolgenden Ausführungen unterschiedliche Antworten, oder der Assistent zitiert widersprüchliche Verfahren in derselben Antwort.

Ein Löschungsantrag betrifft alle Stellen mit den Daten der Person, einschließlich des Vektorindex. Fragmente, die auf Dokumenten mit PII dieser Person basieren, müssen gelöscht werden. Die Deduplikations-Pipeline sollte eine Herkunftskarte speichern: welches Fragment aus welchem Quelldokument stammt. Ohne diese ist eine vollständige Löschung nicht möglich. Wenn Fragmente mit anderen Dokumenten zusammengeführt wurden, erfordert die zusammengefügte Version eine manuelle Überprüfung vor der Löschung.

Die Zeit hängt vor allem vom Zustand der Eingangsdaten und der Anzahl der Quellen ab. Bei einem strukturierten System (z. B. Confluence mit einigen hundert Seiten) dauert eine gründliche und fuzzy Deduplikation plus Normalisierung ein bis drei Tage, mit Stunden für die manuelle Überprüfung von Kandidaten. Bei drei oder mehr Systemen mit mehrjähriger Historie, uneinheitlicher Terminologie und Duplikaten zwischen den Systemen dauert die Arbeit ein bis drei Wochen, wobei ein realer Teil für Entscheidungen aufgewendet wird, die geschäftlichen Kontext erfordern, nicht nur technischen. Einen detaillierten Plan für die Phasen der Vorbereitung von Unternehmensdaten für AI beschreiben wir in einem separaten Artikel auf diesem Blog.