Datenpipelines für AI-Features: Von Rohdaten zu nutzbarem Kontext

Wenn ein AI-Feature schlechte Antworten liefert, fällt der Verdacht zuerst auf das Modell oder den Prompt. In der Praxis liegt die Ursache aber häufig eine Ebene tiefer: in der Datenpipeline, die dem Modell seinen Kontext liefert. Ein Retrieval-System kann nur finden, was sauber aufbereitet im Index liegt. Wenn dort Duplikate, veraltete Versionen und schlecht extrahierte Fragmente liegen, hilft auch das beste Modell nicht weiter.

Das Problem ist unangenehm, weil es unsichtbar bleibt. Der Prototyp funktioniert, denn er wurde mit einer handverlesenen Sammlung sauberer Dokumente gebaut. Erst wenn die echten Bestandsdaten angebunden werden, also das Dokumentenmanagement mit fünfzehn Jahren Historie, das ERP mit inkonsistenten Stammdaten und die E-Mail-Postfächer mit ihren Anhängen, zeigt sich, wie viel Arbeit zwischen Rohdaten und nutzbarem Kontext liegt.

Dieser Artikel beschreibt die Bausteine einer Datenpipeline für AI-Features: Ingestion, Normalisierung, inkrementelle Aktualisierung, Qualitätssicherung und das Monitoring des Index im Betrieb.

Ingestion: die Quellen bestimmen den Aufwand

Der erste Schritt ist die Anbindung der Bestandssysteme. Jede Quelle bringt eigene Tücken mit. Ein Dokumentenmanagementsystem liefert oft PDF-Dateien in sehr unterschiedlicher Qualität: durchsuchbare Textdokumente neben eingescannten Bildern, die erst durch Texterkennung nutzbar werden. Ein ERP-System liefert strukturierte Daten, die aber selten selbsterklärend sind: kryptische Feldnamen, historisch gewachsene Statuscodes, Referenzen auf andere Tabellen. E-Mail-Postfächer sind die schwierigste Quelle, weil dort relevante Information, Smalltalk und Signaturen ununterscheidbar nebeneinanderliegen.

Für jede Quelle braucht die Pipeline einen eigenen Konnektor, der drei Fragen beantwortet: Wie werden Inhalte gelesen, wie werden Änderungen erkannt, und welche Metadaten kommen mit. Gerade die Metadaten werden gern unterschätzt. Erstellungsdatum, Autor, Projektbezug und Zugriffsrechte entscheiden später darüber, ob das Retrieval die richtigen Dokumente findet und ob Nutzer nur sehen, was sie sehen dürfen. Wer Berechtigungen nicht schon bei der Ingestion mitführt, baut sie später mühsam nach.

Normalisierung und Deduplizierung

Nach der Ingestion liegen die Inhalte in Dutzenden Formaten vor. Die Pipeline muss daraus eine einheitliche Zwischenrepräsentation machen: Text mit Struktur, also Überschriften, Absätzen, Tabellen und Metadaten. Diese Normalisierung ist Handwerk. Tabellen aus PDF-Dateien zerfallen bei naiver Extraktion zu Zeichensalat, Kopf- und Fußzeilen wiederholen sich auf jeder Seite, und mehrspaltige Layouts bringen die Lesereihenfolge durcheinander. Es lohnt sich, die Extraktion pro Dokumenttyp zu testen, statt einem generischen Parser blind zu vertrauen.

Der zweite Schritt ist die Deduplizierung. In gewachsenen Ablagen existiert dasselbe Dokument oft mehrfach: als Entwurf, als finale Version, als E-Mail-Anhang und als Kopie im Projektordner. Landen alle Varianten im Index, konkurrieren sie im Retrieval miteinander, und das Modell bekommt widersprüchliche Fassungen desselben Inhalts als Kontext. Bewährt hat sich eine Kombination aus exakter Duplikaterkennung über Prüfsummen und Ähnlichkeitserkennung für Beinahe-Duplikate, ergänzt um eine Regel, welche Version gewinnt: meist die neueste aus dem führenden System.

Inkrementell statt Voll-Reindex

Der Prototyp indiziert alles einmal komplett, und das ist für den Anfang in Ordnung. Im Betrieb wird der Voll-Reindex aber schnell zum Problem: Er dauert Stunden, kostet bei jedem Lauf Embedding-Gebühren für den gesamten Bestand und liefert trotzdem nur einen Stand, der zwischen zwei Läufen veraltet.

Die Alternative sind inkrementelle Updates: Die Pipeline verarbeitet nur, was sich seit dem letzten Lauf geändert hat. Dafür braucht jede Quelle einen Änderungsmechanismus, etwa Zeitstempel, Versionsnummern oder Webhooks des Quellsystems. Drei Fälle müssen sauber behandelt werden:

• Neue Inhalte werden extrahiert, normalisiert und indiziert.
• Geänderte Inhalte ersetzen ihre alte Fassung vollständig, inklusive aller daraus erzeugten Chunks und Embeddings.
• Gelöschte Inhalte müssen auch aus dem Index verschwinden. Dieser Fall wird am häufigsten vergessen und führt dazu, dass das System Inhalte zitiert, die es offiziell nicht mehr gibt.

Ein periodischer Abgleich zwischen Quellsystem und Index als Sicherheitsnetz bleibt trotzdem sinnvoll, denn Änderungsereignisse gehen in der Praxis gelegentlich verloren.

Qualitätschecks gehören in die Pipeline

Datenqualität lässt sich nicht am Ende prüfen, sondern nur unterwegs. Jeder Verarbeitungsschritt sollte messbare Prüfungen haben, die fehlerhafte Inhalte aussortieren oder markieren, bevor sie den Index erreichen. Bewährte Prüfungen sind unter anderem:

• Extraktionsqualität: Ist der extrahierte Text plausibel, gemessen etwa am Verhältnis von Sonderzeichen zu Wörtern oder an einer Mindestlänge pro Seite. Gescheiterte Texterkennung fällt hier auf.
• Vollständigkeit der Metadaten: Fehlen Pflichtfelder wie Datum oder Quellsystem, wandert das Dokument in eine Klärungsliste statt in den Index.
• Chunk-Qualität: Entstehen beim Zerteilen sinnvolle Abschnitte, oder produziert die Logik winzige Fragmente und abgeschnittene Sätze.
• Berechtigungen: Trägt jeder Eintrag die Zugriffsinformationen der Quelle, damit das Retrieval sie durchsetzen kann.

Wichtig ist, dass die Pipeline bei Fehlern nicht still weiterläuft. Ein Dokument, das nicht verarbeitet werden konnte, gehört in ein Fehlerprotokoll mit Grund und Wiederholungslogik. Silent Failures in der Ingestion sind die häufigste Ursache für die Beschwerde, dass das System ein bestimmtes Dokument angeblich nicht kennt.

Veraltete Inhalte im Index erkennen

Ein Index ist kein Archiv, sondern eine Momentaufnahme des relevanten Wissens. Mit der Zeit sammeln sich Inhalte an, die formal noch korrekt im Index liegen, inhaltlich aber überholt sind: alte Preislisten, abgelöste Prozessbeschreibungen, Richtlinien in früheren Fassungen. Das Modell kann nicht wissen, dass ein Dokument überholt ist, wenn niemand es ihm sagt.

Dagegen helfen zwei Maßnahmen. Erstens ein Alters-Monitoring: Auswertungen, welche Anteile des Index seit langem nicht aktualisiert wurden, aufgeschlüsselt nach Quelle und Dokumenttyp. Das macht Pflegebedarf sichtbar und liefert den Fachabteilungen konkrete Listen statt vager Appelle. Zweitens eine Aktualitätslogik im Retrieval: Bei konkurrierenden Treffern zum selben Thema bekommt die neuere Fassung Vorrang, und Dokumente über einer definierten Altersschwelle werden je nach Anwendungsfall abgewertet oder mit Datum ausgewiesen, damit Nutzer die Einordnung sehen.

Fazit

Die Qualität eines AI-Features wird zu einem großen Teil vor dem Modell entschieden. Eine belastbare Datenpipeline bindet die Quellsysteme mit ihren Eigenheiten an, normalisiert und dedupliziert die Inhalte, aktualisiert inkrementell statt teuer neu zu indizieren, prüft Qualität in jedem Schritt und beobachtet das Altern des Index im Betrieb. Nichts davon ist spektakulär, und genau deshalb wird es oft übersprungen. Wer die Pipeline als eigenständiges Produkt mit eigenen Qualitätsmaßstäben behandelt, statt als Skript neben dem Prototyp, erspart sich später die Fehlersuche an der falschen Stelle: beim Modell, das nur wiedergibt, was man ihm vorgesetzt hat.