AI-Essentials: Warum KI ein anderes Datenmanagement (und Storage) braucht

KI kann weder Videos sehen noch Bücher lesen oder einen Podcast hören.

Bild: KI

Immer mehr Unternehmen setzen KI ein oder planen, sie einzusetzen. Allerdings scheitern 95% der Projekte. Die Gründe sind Compliance- und regulatorische Bedenken, Sicherheitsrisiken, Implementierungs- und Wartungskosten. Aber auch strukturelle Herausforderungen wie den KI-Zugang einschränkende Datensilos sowie kulturelle Versäumnisse, wenn Mitarbeiter nicht vorbereitet und trainiert werden, spielen eine Rolle. Oft wissen Unternehmen selbst recht wenig über KI. In diesem Artikel werden die Grundlagen einer KI-gerechten Aufbereitung der Daten und die dafür notwendigen Voraussetzungen erklärt, sowie geeignete Architekturen und Lösungen vorgestellt.

Viele wissen inzwischen, was ein großes Sprachmodell oder Large Language Model (LLM) ist. Aber wer kennt MLM oder VLM? Für KI ist das ein wichtiger Unterschied. LLM wurden für die Verarbeitung menschlicher Sprache entwickelt. Bilder, Audio- und Videodateien können allerdings zu relevanten Ergebnissen beitragen. In der Medizin zum Beispiel kommt es auf die Auswertung von Bildern an. Phishing-E-Mails können leichter erkannt werden, wenn Bilder und Text analysiert werden. Kommen zusätzlich Deepfakes zum Einsatz, müssen auch Videos geprüft werden. Dann braucht es VLM oder MLM: Vision Language Model bzw. Multimodal Language Model. VLM können neben Sprache auch visuelle Inhalte verarbeiten. Mit MLM lassen sich neben Sprache und Bild- bzw. Videoinhalten auch Audio-Dateien analysieren.

Eines haben LLM, VLM und MLM jedoch gemeinsam: Keines dieser Sprachmodelle kann etwas mit nativen Dateiformaten oder un- bzw. semi-strukturierten Rohdaten in einem Data Warehouse anfangen.

Im Folgenden werden Large, Visual und Multimodal Language Modelle als xLM zusammengefasst.

Die Grundlage der Intelligenz: Daten

Daten für KI-Anwendungen müssen nicht nur gesammelt und gespeichert werden. Damit KI etwas damit anfangen kann, müssen diese Daten darüber hinaus klassifiziert, kuratiert, sortiert, angereichert, indiziert und vektorisiert werden.

Die Aufbereitung der Daten ist erfolgskritisch für KI-Projekte. Allerdings sind herkömmliche Data-Management- und Storage-Ansätze für KI nicht gut geeignet und erfordern zusätzliche Maßnahmen, Produkte und Layer.

Viele der modernen Storage- und Datenmanagement-Plattformen wurden speziell für die Anforderungen künstlicher Intelligenz konzipiert und entwickelt.

Der Kern des Problems liegt in der Art und Weise, wie KI-Modelle Informationen verarbeiten und abrufen. xLM können den Inhalt nativer Dateiformate (wie WAV, JPEG, DOCX, etc.) semantisch nicht verstehen – sie können weder Texte lesen, noch Bilder sehen, noch Audio hören. Für ein xLM müssen Inhalte in eine standardisierte, numerisch verarbeitbare Form gebracht werden, bevor sie etwas damit anfangen können.

Warum ist das so?

In Formaten wie DOCX oder PDF sind auch komplexe Layout-Informationen (Spalten, Kopf-/Fußzeilen, Tabellen, eingebettete Bilder) enthalten, die den reinen Textfluss unterbrechen. Das ist für ein Sprachmodell verwirrend. Metadaten und visuelle Elemente müssen herausgelöst und der reine Text für die weitere Verarbeitung extrahiert werden.

Formate wie JPEG, MPEG oder WAV enthalten keine direkten Sprach- oder Bildinformationen, sondern binäre Daten (Pixel, Audiowellenformen). Ein Large Language Model kann diesen Code nicht interpretieren. Bilder werden für KI mithilfe eines Vision-Modells als Text beschrieben; Audio oder Video werden mithilfe eines Speech-to-Text-Modells in Text transkribiert.

Die Ergebnisse, also die Textdaten, werden dann in sinnvolle kleine Abschnitte (Chunks oder Token) zerlegt und in Vektoren umgewandelt, die in einer Vektordatenbank, dem sogenannten Index, gespeichert werden. Dieser Prozess wird auch als Embedding bezeichnet und ist besonders wichtig für die Nutzung von Erweiterungen wie der Retrieval-Augmented Generation (RAG).

Stellt man ChatGPT eine Frage, wird diese Frage ebenfalls vektorisiert. Die Vektoren der Frage werden mit dem Index verglichen, um semantisch relevante Ergebnisse, z. B. einen Textabschnitt in einem Dokument zu finden.

Da ständig neue Daten hinzukommen oder sich bestehende Dateien ändern, muss der Index kontinuierlich aktualisiert und permanent synchronisiert werden. Das ist kritisch für die Qualität und Relevanz einer KI-Anwendung. Für Daten, die sich nur selten oder in festgelegten Intervallen ändern, wie Quartalsberichte oder Archivdokumente, kann der Index periodisch aktualisiert werden. Ändern Daten sich häufig oder kommen neue hinzu (z. B. Support-Tickets, tägliche News-Feeds, e-Commerce oder Finanztransaktionen) sollte der Index inkrementell in Echtzeit oder nahezu in Echtzeit (Near Real-Time) aktualisiert werden.

Die Notwendigkeit einer Vektor-Datenbank

Die Suche nach Ähnlichkeiten in einer Datenbank mit Millionen von Vektoren ist wesentlich schneller und effizienter als das Extrahieren und Analysieren von Inhalten aus nativen Formaten oder un- bzw. semi-strukturierten Rohdaten in einem riesigen Datenozean.

Der Prozess, Daten für KI aufzubereiten, umfasst mehrere Schritte. Die Architektur der Infrastruktur und Auswahl geeigneter Komponenten für deren Aufbau ist erfolgskritisch. Daher ist es wichtig, die Grundlagen dieses Prozesses zu verstehen.

Die einzelnen Prozessschritte sind:

Bei der Extraktion werden die Rohdaten aus ihren nativen Formaten gewonnen. Um reinen Text aus komplexen Strukturen (PDFs, DOCX, HTML, etc.) oder Audio-/Videodaten zu extrahieren, sind spezialisierte Tools wie Apache Tika oder entsprechende Cloud-Dienste erforderlich.

Der extrahierte Text wird anschließend aufbereitet. Im Zuge einer Bereinigung werden irrelevante Elemente (Kopf- und Fußzeilen, Bildbeschriftungen, HTML-Tags) entfernt und der Text normalisiert (z. B. Behebung von Formatierungsfehlern).

Der aufbereitete Text muss dann in kleine, bedeutungsvolle Segmente (Chunks) zerlegt werden. Die Größe ist entscheidend. Sind die Chunks zu groß, enthält man zu viele irrelevante Informationen. Sind sie zu klein, verliert die KI den notwendigen Kontext. Überlappungsbereiche (Overlap) zwischen den Chunks stellen sicher, dass keine semantischen Zusammenhänge verloren gehen.

Jeder Chunk wird mithilfe eines Embedding-Modells in einen hochdimensionalen numerischen Vektor umgewandelt. Ein Vektor enthält die (kodierte) semantische Bedeutung des Textabschnitts.

Abschließend werden die generierten Vektoren zusammen mit ihren Metadaten (z. B. ursprüngliche Dokument-ID, Erstellungsdatum) in einer Vektor-Datenbank (dem Index) gespeichert.

Innerhalb der KI-Pipeline ist die Vektorisierung ein Schritt im ELT/ETL-Prozess. Sowohl ELT als auch ETL sind Datenintegrationsmethoden, unterscheiden sich jedoch in der Reihenfolge der einzelnen Schritte: Extrahieren (E), Transformieren (T), Laden (L).

Bei ETL werden die Daten aus den Quellen extrahiert und vor dem Laden in das Zielsystem transformiert und bereinigt.

Bei ELT werden die Daten direkt in das Zielsystem geladen. Die Transformation erfolgt anschließend im Zielsystem.

Compliance vs. Performance

ETL eignet sich für kleinere Datensätze und für Umgebungen, in denen die Einhaltung strenger Vorschriften wichtig ist (z. B. Finanzwesen oder Gesundheitswesen). ETL bietet eine granulare Kontrolle über die Datenverarbeitung und -qualität. So können z. B. vertrauliche Informationen entfernt oder anonymisiert werden. Der Nachteil ist eine höhere Latenz und die Notwendigkeit eines dedizierten Transformationsservers, was zusätzliche Kosten verursachen kann.

ELT ist eine gängige Methode in Public-Cloud-Architekturen. Die Verarbeitungsleistung und Skalierbarkeit des Zielsystems macht ELT zur bevorzugten Methode für große Datenmengen.

Die Rohdaten (Daten in ihrem ursprünglichen, unveränderten Zustand, genau so, wie sie aus dem Quellsystem extrahiert wurden) können leichter für spätere Analysen und die Verwendung mit verschiedenen Schemata (Schema-on-read Ansatz) aufbewahrt werden – was jedoch gleichzeitig ein Risiko ist.

Rohdaten können sensible Informationen enthalten und Compliance-Anforderungen verletzen, wenn sie unkontrolliert geladen werden. ELT im Onprem-Betrieb erfordert ein leistungsfähiges Zielsystem für die Transformation, was wiederum die Investitions- und Gesamtbetriebskosten nach oben treibt.

Die Wahl hängt letztendlich von den spezifischen Anforderungen des Projekts, der Datenmenge und den Compliance-Vorgaben ab.

ELT wird gern für das Training von xLM genutzt. KI-Modelle, insbesondere für Deep Learning, benötigen oft riesige Mengen an Rohdaten, um Muster zu erkennen. Beim ELT-Ansatz sind Daten schnell und vollständig für verschiedene Setups und Modelle verfügbar. Da die Rohdaten erhalten bleiben, können sie zusätzlich für andere Business-Intelligence- und Analysezwecke genutzt werden.

Das Vorhalten der Daten im nativen Format bewahrt zudem alle ursprünglichen Details und Nuancen, die für das Training komplexer KI-Modelle wertvoll sein können. Bei ETL können durch die vorzeitige Standardisierung nützliche Informationen verloren gehen.

In bestimmten Szenarien, besonders wenn es um sensible Daten geht, die strengen Vorschriften wie der DSGVO unterliegen, sollte ETL bevorzugt werden.

Die Rolle der Datenmanagement- und Storage-Plattform

Moderne Analyse-Tools und ML-Frameworks (wie TensorFlow, PyTorch, Spark) sind darauf ausgelegt, direkt auf Daten in verteilten Dateisystemen zuzugreifen. Sie verfügen über Konnektoren und Bibliotheken, um die verschiedenen nativen Formate zu lesen und die notwendigen Transformationen on-the-fly durchzuführen.

Es gibt Storage- und Datenbanksysteme, mit denen die Vektorisierung direkt in der Datenbank oder dem Speichersystem durchgeführt wird. Das Gros der Hersteller, die die Eignung ihres Storage für KI betonen, meinen meist jedoch nur die Geschwindigkeit für Datenzugriffe. Eine Ausnahme ist VAST Data.

Während sich die meisten Anbieter von Storage für KI (z. B. Quantum, NetApp oder Weka) auf die auf die hochperformante Bereitstellung von Daten für KI-Workflows konzentrieren, bieten die Storage-Systeme von VAST Data eine integrierte einheitliche Datenbank für strukturierte und unstrukturierte Daten. Die VAST DataBase ermöglicht, Vektoren und Rohdaten gemeinsam in der Datenbank zu speichern. So können Vektoren ohne externe Orchestrierungs-Tools oder Transformations-Server für die Suche und Abfrage generiert und verwaltet werden.

Die In-Memory Computing Platform Hazelcast ist ein Beispiel eines dedizierten Transformationsservers bzw. -dienstes. In der Hazelcast-Platform sind In-Memory-Datenspeicherung, verteilte Berechnung und Vektorsuche kombiniert. Über Python-Clients können Entwickler unstrukturierte Daten (z. B. Bilder) konsumieren, Embeddings berechnen (mittels externer Modelle, aber innerhalb der Hazelcast-Pipeline) und als Vektoren in einer Vector-Collection-Datenstruktur speichern.

Spezialisierte Vektordatenbanken wie Chroma, Weaviate, Qdrant, Milvus sind von Grund auf für die effiziente Speicherung und Suche nach Vektoren konzipiert und bieten integrierte Embedding-Funktionen.

Aber auch traditionelle relationale oder NoSQL-Datenbanken können Vektorfunktionen integrieren, um den RAG-Workflow zu unterstützen. Als Beispiele seien hier PostgreSQL mit pgvector, Google Cloud AlloyDB, Amazon S3 Vector, SAP HANA Cloud und Elasticsearch genannt.

Externe Orchestrierungstools wie Hammerspace oder Komprise können Daten über verschiedene Standorte sowohl On-Premise als auch in Multi-Clouds zu einem einzigen, globalen Namespace vereinen. Sie leisten einen wichtigen Beitrag zur Klassifizierung von Daten oder bei der Metadatenverwaltung und können KI-Workflows beschleunigen.

KI benötigt eine saubere Metadatenverwaltung. Metadaten (z. B. Dokumenten-ID, Autor, Erstellungsdatum, letzte Änderung) sind entscheidend für die Verwaltung des Indexes (Löschen/Ersetzen alter Chunks). Sie helfen der KI auch, die Relevanz von Suchergebnissen zu filtern und zu priorisieren oder einem Nutzer die Quelle der generierten Antwort anzuzeigen.

Klassifikation ist auch für relevantere Schlussfolgerungen (Inference) entscheidend. Vektoren werden anhand ihrer Klassifikation gebildet. Eng zusammengehörende Daten bekommen auch eng beieinander liegende Vektoren.

Plattformen wie Komprise oder Ctera bieten erhöhte Sicherheitsfunktionen zum Schutz sensibler Daten.

Wie so vieles hängt natürlich auch die Wahl der Plattformen von den spezifischen Anforderungen des Projekts, den zu verarbeitenden Datenmengen und Compliance-Vorgaben ab. Statt allerdings nur nach Storage-Produkten im klassischen Sinne (Dateiserver) zu suchen, sind es vielmehr Datenbank- und Datenplattform-Lösungen, die den Datenpipeline-Prozess vereinfachen.