Embedding-Pipelines sind das neue ETL

Unsere Expertin erklärt, was den Unterschied macht zwischen cooler KI-Demo und wirklich verlässlicher Lösung.freedomnaruk | shutterstock.com



Ich habe schon diverse Male erlebt, dass vielversprechende KI-Prototypen nach dem Launch scheitern. Und das lag selten daran, dass das Modell schlecht gewesen wäre. Meistens beginnt das Problem schon viel früher. Nämlich dort, wo die Teams den Data Layer als nachrangig behandeln: Spezialisten verbringen Wochen damit, Prompts zu optimieren, Modelle zu testen und Evaluations-Scores zu diskutieren. Nur, um dann an einem Wochenende die Retrieval-Pipeline zusammenzuschustern und zum nächsten Projekt überzugehen. Erste Demos sehen zunächst großartig aus – allerdings liefert das System ein paar Monate später veraltete Outputs. Die Embeddings stimmen nicht mehr mit den Quelldokumenten überein und niemand versteht wirklich, was sich geändert hat. So werden anfänglich vielversprechende Prototypen im Produktivbetrieb unzuverlässig.



Solche Szenarien lassen sich vermeiden, wenn Teams frühzeitig erkennen, dass Embedding-Pipelines im Grunde ein Data-Engineering-Problem und keine völlig neue KI-Disziplin sind. Denn im Kern geht es immer noch um Extract, Load, Transform (ETL). Der Unterschied: Statt eines Data Warehouse sind Embeddings und Vektorspeicher der Zielort. Diese Sichtweise sorgt für Klarheit – und dafür, dass sich Versionierung, Datenaktualität, Lineage und Wiederholungsversuche nicht mehr „KI-spezifisch“ anfühlen. Und das sollten sie auch nicht. Es sind Dateninfrastrukturprobleme, mit deren Lösung wir uns schon seit Jahren beschäftigen.



Wozu Embedding-Pipelines?



Large Language Models (LLMs) sind bezüglich ihrer Reasoning-Fähigkeiten in einer Zeitkapsel gefangen. Sobald das Training beendet ist, wird der Wissensstand des Modells quasi „versiegelt“. In Kombination mit strikt beschränkten Kontextfenstern – also einer Obergrenze dafür, wie viel Text das Modell in einer Interaktion verarbeiten kann – wird das Problem mehr als deutlich: Auch LLMs haben Grenzen.



Bei der Suche nach einer Lösung für dieses Problem hat sich die Branche auf Retrieval Augmented Generation (RAG) geeinigt: Statt einfach alles in das Kontextfenster zu stopfen, wird ein Retrieval-Layer aufgebaut, der nur die relevantesten Informationen genau in dem Moment abruft, in dem eine Frage gestellt wird. Angetrieben wird dieser Layer von einer Vektordatenbank – und dem Prozess, der sie befüllt (Rohdokumente werden in durchsuchbare semantische Repräsentationen umgewandelt). Das ist mein Verständnis einer Embedding-Pipeline. Diese braucht jedes Team, das einen internen KI-Assistenten, ein smartes Enterprise-Search-Tool, einen Support-Agenten oder ein Q&A-System; für Dokumente entwickelt.



Die nächste (und entscheidende) Frage ist dann, wie man diese Embedding-Pipeline aufbaut: Wie einen Prototyp oder wie eine Infrastruktur?



Embedding-Pipeline meets ETL



Eine Embedding-Pipeline beinhaltet drei Stufen:




Ingestion (Datenerfassung),



Chunking (Datenzerlegung) und



Indexing (Indizierung).




Nachfolgend sehen wir uns diese Phasen genauer an – und bringen diese mit dem klassischen ETL-Prozess in Verbindung.



Ingestion als Extraction



Bei der Datenerfassung geht es darum, Rohdaten – also beispielsweise PDFs, Wiki-Seiten, Word-Dokumente, Datenbankeinträge, Transkripte – von ihrem jeweiligen Speicherort in die Pipeline zu übertragen. Das entspricht der Extract-Phase im ETL-Prozess.



Ich beobachte, dass viele Teams an dieser Stelle Abstriche machen – und zwar mehr als an anderen. Das ist dann oft der erste Point of Failure von Produktionssystemen: Ein Dokument wird aktualisiert, aber die Pipeline erfasst es nicht. Eine Datei wird gelöscht, aber ihre Chunks verbleiben im Index und liefern noch Monate später veraltete Ergebnisse. Und weil kein offensichtlicher Fehler vorliegt, reportet es auch niemand.



Die Lösung ist Change Data Capture (CDC): Dabei wird ein Manifest aller erfassten Dokumente vorgehalten, inklusive einer Content-Hash-Datei und einem Zeitstempel. Bei jedem Durchlauf werden die Quellen mit diesem Manifest abgeglichen und geänderten Daten neu eingelesen sowie nicht mehr vorhandene gelöscht. Damit behandeln Sie Ihre Inhalte so wie jede Source-Tabelle, die inkrementell synchronisiert wird.



Chunking als Transformation



Sobald sich die Dokumente in der Pipeline befinden, können Sie diese nicht mehr in einem Stück einbinden. Ein 30-seitiger technischer Bericht ist zu lang, um ihn sinnvoll als einzelnen Vektor darzustellen. Und selbst wenn das nicht der Fall wäre: Den kompletten Report als Antwort auf eine eng gefasste Frage zurückzugeben, würde das Modell in irrelevantem Kontext versinken lassen. Deshalb gibt es Chunking: Es ist der Prozess, bei dem jedes Dokument in kleinere Teile zerlegt wird. Und zwar solche, die fokussiert genug sind, um exakt eingebettet und präzise abgerufen zu werden. Das entspricht nicht nur der Transform-Phase von ETL, sondern erfordert auch dasselbe Maß an Design-Disziplin.



Der häufigste Fehler, den ich in diesem Zusammenhang beobachte, ist, die Chunk-Größe als Standardkonfigurationsoption zu behandeln statt als Produktentscheidung. Die richtige Chunk-Größe hängt vollständig von der Art der Inhalte und der Queries ab. Eine komplexe technische Dokumentation erfordert mehr Granularität als eine FAQ-Sammlung. Anders ausgedrückt: Was für einen Inhalt funktioniert, kann bei einem anderen die Retrieval-Qualität negativ beeinflussen.



Ich bevorzuge es deshalb, Chunking-Konfigurationen als versionierte Pipeline-Parameter zu behandeln und nicht als fest-codierte Logik. Wenn Sie diese verändern (und das werden Sie), müssen Sie auch das Chunking auf kontrollierte, nachvollziehbare Art und Weise neu durchführen und dabei die Abfragequalität vergleichen und eventuell zurücksetzen, falls sie sich verschlechtert. Das verstehe ich einfach als gute Transform-Layer-Hygiene.



Indexing als Load



In der Indizierungsphase wird der in Chunks unterteilte Inhalt schließlich in Vektoren umgewandelt und in einer entsprechenden Datenbank abgelegt. Anschließend stehen die Inhalte für semantische Ähnlichkeitssuchen zur Verfügung. Die Einbettung erfolgt beim Umwandlungsschritt durch ein Modell, das speziell darauf trainiert ist, Text, beziehungsweise Content in dichte numerische Darstellungen umzuwandeln, die dessen Bedeutung kodieren. Zwei Chunks, die denselben Gedanken mit unterschiedlichen Worten ausdrücken, erzeugen Vektoren, die in diesem mathematischen Raum dicht beieinander liegen. Behandeln sie hingegen unterschiedliche Themen, liegen sie weit auseinander.



Stellt ein User nun eine Frage, bettet das System diese auf die gleiche Weise ein, findet die Chunks, deren Vektoren am nächsten liegen und gibt sie als Kontext für den Reasoning-Prozess des Modells zurück. Das unterscheidet sich zwar vom Load-Prozess – aber nicht, wenn es um die Disziplin geht: In Embedding-Pipelines muss jeder Chunk im Index mit dem Namen und der Version des Embedding-Modells gekennzeichnet sein, mit der er generiert wurde. Schließlich entwickeln sich Embedding-Modelle weiter und Vektoren, die von verschiedenen Versionen erzeugt wurden, sind nicht zuverlässig miteinander vergleichbar.



Genau dieses Problem tritt auf, wenn Embedding-Modelle in der Pipeline ohne ordnungsgemäßen Migrationsplan aktualisiert werden. Am Ende werden Vektoren aus verschiedenen Generationen im selben Index miteinander vermischt – und die Suchqualität verschlechtert sich. Das Tückische dabei ist, dass sich das still und leise vollzieht – oft in Form subtil falscher Antworten. Beim Upgrade eines Embedding-Modells gehe ich deshalb genauso vor wie bei einer Schema-Migration: Ich plane explizit, ziehe es an einem Stück durch und validiere die Retrieval-Qualität anhand eines repräsentativen Query-Sets. Schließlich steht hier ebenso viel auf dem Spiel wie bei jeder grundlegenden Änderung am Datenmodell.



Pipeline-Observability ist nicht optional



Sobald eine Embedding-Pipeline in der Produktion läuft, ist die Frage nicht mehr, ob sie läuft, sondern vielmehr, ob sie das auch auf korrekte Weise tut. Das ist in diesem Fall wichtiger als bei den meisten anderen Pipelines, weil Fehler seltener auffallen: Der Index sieht einwandfrei aus, Abfragen werden fehlerfrei zurückgegeben – und dennoch liefert das System falsche Antworten. So lange, bis jemandem auffällt, dass die KI keinen Nutzwert hat.



Deshalb braucht es an dieser Stelle auch Observability-Disziplin. Sobald man Embedding-Pipelines als Produktionssysteme behandelt, denkt man nicht mehr in isolierten Schritte, sondern in Signalen. Beispielsweise wird die Anzahl der Chunks pro Dokument zu einem einfachen, aber leistungsstarken Health Check: Ein plötzlicher Rückgang ist in der Regel kein Modellproblem, sondern ein Zeichen für eine gestörte Datenerfassung oder Upstream-Parsing-Fehler.



Darüber hinaus brauchen Sie auch ein „Golden Set“ von Queries mit nachweislich korrekten Outputs. Dieses kann nach jeder Pipeline-Änderung als eine Art Datenqualitätsprüfung fungieren und Regressionen sichtbar machen, die nicht als explizite Fehler auftreten. Zusätzlich können Sie auch die Lineage tracken und so herausfinden, welche Version des Einbettungsmodells welche Chunks erzeugt hat und wann jedes Dokument zuletzt eingelesen wurde. Das ermöglicht es, Probleme bei der Abfrage auf bestimmte Änderungen zurückzuführen – anstatt einfach zu raten.



Die Datenaktualität wird schließlich zu einem Signal erster Güte. Wenn Dokumente über eine akzeptable Schwelle hinaus veralten, sollte das auch im Rahmen des Monitorings sichtbar sein – und zwar bevor die Benutzer schlechte Ergebnisse geliefert bekommen. Die Metrik, die all das zusammenführt, ist die Abfragequalität im Zeitverlauf (Retrieval Quality over Time). Diese ist wie jede andere Pipeline-SLA zu behandeln: Sie muss gemessen, getrackt und ge-„ownt“ werden. (fm)



Dieser Beitrag wurde im Rahmen des englischsprachigen Expert Contributor Network von Foundry veröffentlicht. Alle Infos zum deutschen Experten-Netzwerk finden Sie hier.