Wie Metadata Lakes Next-Gen-KI/ML-Anwendungen unterstützen
Da sich KI-Technologien wie große Sprachmodelle (LLMs) und Retrieval Augmented Generation (RAG) weiterentwickeln, wächst die Nachfrage nach flexibler und effizienter Dateninfrastruktur. Unternehmen suchen nach Datenarchitekturen, die diese neuen Tools unterstützen können, während sie technische Schulden minimieren und nahtlose Skalierbarkeit ermöglichen.
Metadata Lakes entwickeln sich in dieser Hinsicht zu einer wichtigen Lösung. Sie sind zentralisierte Repositories, die Metadaten aus verschiedenen Quellen in einem Unternehmen speichern und einen einheitlichen Ansatz für das Datenmanagement bieten. Metadaten liefern Kontext und Verständnis der gespeicherten Daten, einschließlich Datenquelle, Qualität, Herkunft, Eigentümerschaft, Inhalt, Struktur und Kontext.
Lisa N. Cao, Product Manager bei Datastrato, hielt kürzlich einen Vortrag beim von Zilliz veranstalteten Unstructured Data Meetup, in dem sie die entscheidende Rolle von Metadata Lakes in der KI/ML-Entwicklung der nächsten Generation erläuterte. Gestützt auf ihre Erfahrung als Data Engineer teilte Lisa Einblicke dazu, wie Metadata Lakes das Datenmanagement optimieren und sich in verschiedene Technologien wie Vektordatenbanken, Deep-Learning-Modelle und LLMs in KI-gesteuerten Umgebungen integrieren lassen.
Lisa spricht beim Unstructured Data Meetup im Juni in Palo Alto
Dieser Blog fasst Lisas wichtigste Punkte zusammen und untersucht die Herausforderungen bei der Bereitstellung von RAG-Pipelines in der Produktion. Doch zunächst führen wir kurz in RAG und die Herausforderungen bei der RAG-Entwicklung und -Bereitstellung ein.
Kurze Einführung in RAG (Retrieval Augmented Generation)
RAG, oder Retrieval-Augmented Generation, ist ein fortschrittliches Framework, das LLM-Antworten verbessert, indem es Retrieval- und generative Module kombiniert. Das Retrieval-Modul umfasst eine Vektordatenbank wie Milvus oder Zilliz Cloud (das vollständig verwaltete Milvus) und ein Embedding-Modell, und das generative Modul ist in der Regel ein LLM wie ChatGPT.
Abbildung 1 Wie RAG funktioniert
Abbildung 1: Wie RAG funktioniert
Wenn der Benutzer eine Anfrage in eine RAG-Anwendung eingibt, extrahiert die Vektordatenbank im Retrieval-Modul die relevantesten Dokumente aus dem großen Textkorpus. Diese abgerufenen Dokumente werden als „Top-Kandidaten“ bezeichnet und dem LLM als Kontext der Benutzeranfrage zugeführt, um eine genauere Antwort zu generieren. RAG ist besonders nützlich in Anwendungen wie Frage-Antwort-Systemen, Chatbots und Wissensmanagementsystemen.
Aktuelle Herausforderungen in der RAG-Entwicklung
In letzter Zeit wurden viele fortschrittliche Techniken in die RAG-Pipeline eingeführt, um Genauigkeit und Leistung zu verbessern, darunter ausgefeilte Retrieval-Methoden auf Basis von Re-Ranking und rekursivem Retrieval sowie Embedding- und LLM-basierte Fine-Tuning-Techniken. Darüber hinaus wurden agentische Frameworks für Routing und Abfrageplanung eingeführt, um die Fähigkeiten von RAG zu erweitern.
Diese Fortschritte bringen jedoch auch neue Komplexitäten mit sich. Lisa erörterte mehrere Herausforderungen, mit denen viele KI-Teams konfrontiert sind, wenn sie RAG entwickeln und in die Produktion überführen:
Geringe Beobachtbarkeit: Die Überwachung der Geschwindigkeit der Dokumentenaufnahme und von Änderungen der Datenverteilung innerhalb von RAG-Pipelines ist herausfordernd. Da die Vektordatenbank in einer RAG-Anwendung häufig Milliarden von Dokumenten speichert, wird die Nachverfolgung von Datenänderungen und Aktualisierungen für das Wissensmanagement schwierig.
Lifecycle-Management: Effektive Versionskontrolle und Lifecycle-Management sind entscheidend, um Datenänderungen und Aktualisierungen nachzuverfolgen. Teams benötigen robuste Tools, um die Datenherkunft transparent und auditierbar nachzuverfolgen und Compliance sicherzustellen.
Latenz und Optimierung: Während fortgeschrittenes Fine-Tuning und rekursive Suche die Genauigkeit der generierten Ausgaben verbessern können, können sie auch die Antwortzeiten erhöhen, was zu höherer Latenz und geringerer Nutzerzufriedenheit führt.
Kontextbezogene Antworten auf Abfragen: Komplexe Benutzerabfragen können für LLMs schwierig genau zu interpretieren sein, was zu Antworten führt, denen Kontext oder Nuance fehlt.
Datenschutz: KI-Governance ist eine weitere Herausforderung, insbesondere wenn es darum geht, Maskierung oder Verschlüsselung zu Daten hinzuzufügen, die im Training verwendet werden.
Mechanismus für kontinuierliches Lernen: Lisa betonte, wie wichtig es ist, RAG-Anwendungen mit aktuellen Daten auf dem neuesten Stand zu halten. „Es gibt einen riesigen Unterschied zwischen Modellen, die auf kontinuierlich aktualisierte Daten zugreifen, und solchen, die auf veralteten Daten basieren“, merkte sie an. Die Implementierung eines Mechanismus für kontinuierliches Lernen kann jedoch technisch herausfordernd sein.
Vendor Lock-In: Eine starke Abhängigkeit von einem einzigen Cloud-Service-Provider für Pipeline-Anforderungen kann zu Vendor Lock-In führen, wodurch der Wechsel zu einem anderen Ökosystem schwierig und kostspielig wird.
Eines der zugrunde liegenden Probleme, die zu diesen Herausforderungen beitragen, ist die Existenz von Datensilos in Organisationen.
Datensilos in Organisationen: Ein wichtiger Faktor für RAG-Herausforderungen
Datensilos sind ein häufiges Problem in Organisationen, in denen Daten aufgrund struktureller oder technologischer Barrieren nicht ohne Weiteres über verschiedene Teams oder Abteilungen hinweg zugänglich sind. Diese Silos können auf operativer Ebene, zwischen verschiedenen Teams oder aufgrund der Komplexität der verwendeten Tools und Anwendungen bestehen.
Abbildung 2- Datensilos beeinträchtigen die Effizienz in Organisationen
Abbildung 2: Datensilos beeinträchtigen die Effizienz in Organisationen
Lisa hob das allgegenwärtige Problem der Datensilos hervor und merkte an: „Jedes Unternehmen versucht, diese Frage zu beantworten: ‚Wie schaffen wir operative Konsistenz in unseren Daten über die gesamte Organisation hinweg?‘“ Dies ist besonders herausfordernd, wenn Teams weltweit verteilt sind und mit unterschiedlichen Datenspeichern arbeiten.
Es gibt auch Silos zwischen verschiedenen Teams. Beispielsweise verwenden BI-Analysten und Data Engineers häufig unterschiedliche Tools und verfügen möglicherweise nicht über eine effektive Kommunikation. Manche Teams besitzen möglicherweise nicht das Programmierwissen oder die technischen Fähigkeiten, um auf verfügbare Daten zuzugreifen und sie zu verarbeiten. Beispielsweise könnten DevOps-Engineers Schwierigkeiten haben, die Codebasis von ML-Engineers zu verstehen.
Datensilos wirken sich direkt auf die Fähigkeit aus, effektive RAG-Pipelines aufzubauen und zu pflegen, da sie den nahtlosen Datenfluss innerhalb einer Organisation verhindern. Dieser Mangel an Integration kann zu fragmentierten Datenquellen, Inkonsistenzen in der Datennutzung und letztlich zu Herausforderungen bei der Bereitstellung von RAG-Systemen führen, die auf umfassende und aktuelle Daten angewiesen sind.
Metadata Lakes: Die Lücke für einheitliches Datenmanagement schließen
Um die oben genannten RAG-Herausforderungen zu bewältigen, benötigen Unternehmen Datenarchitekturlösungen, um Daten in der gesamten Organisation zu vereinheitlichen, zu standardisieren und zu operationalisieren. Metadata Lakes bieten eine flexible Architektur zum Speichern und Verwalten von Metadaten—Informationen über Quelle, Struktur, Format, Nutzung, Herkunft und mehr.
Was ist ein Metadata Lake?
Ein Metadaten-Lake, oder Data-Lake-Metadatenmanagement, ist ein zentrales Repository, das Metadaten aus verschiedenen Quellen in einer Organisation speichert. Metadaten sind die beschreibenden Informationen, die Kontext und Verständnis für die Daten im Data Lake bereitstellen. Sie umfassen in der Regel Details wie Datenquelle, Qualität, Herkunft, Eigentümerschaft, Inhalt, Struktur und Kontext.
Figure 3- A unified metadata management .png
Abbildung 3: Ein einheitliches Metadatenmanagement
Im Gegensatz zu einem traditionellen Data Lake, der Rohdaten speichert, konzentriert sich ein Metadaten-Lake auf die Verwaltung, Organisation und Zugänglichmachung der Metadaten, die mit Datenbeständen über verschiedene Systeme, Datenbanken und Anwendungen hinweg verbunden sind.
Figure 4- Comparing different data architecture designs
Abbildung 4: Vergleich verschiedener Datenarchitektur-Designs
Vorteile von Metadaten-Lakes
Verbesserte Auffindbarkeit von Daten: Metadaten-Lakes dienen als zentrale Kataloge, speichern alle Metadaten und erleichtern es Teams und Benutzern, Datenbestände in der gesamten Organisation zu entdecken.
Aktive Metadaten: Diese Lakes ermöglichen aktive Metadaten, die Aktionen auslösen und sich in orchestrierte Pipelines integrieren lassen, Aufgaben automatisieren und den Bedarf an manuellen Eingriffen reduzieren.
Eingebettete Metadaten: Metadaten können in verschiedene Anwendungen eingebettet werden, was eine nahtlose Integration und Interaktion im gesamten Datenökosystem erleichtert.
Verbesserte KI-Governance: Die Zentralisierung des Metadatenmanagements erleichtert die Implementierung konsistenter Governance-Richtlinien und stellt Compliance und Datenqualität sicher. Metadaten-Lakes unterstützen außerdem eine detaillierte Nachverfolgung der Datenherkunft, Zugriffskontrollen und Audit-Funktionen.
Umfassende Nutzung von Metadaten: Einheitliches Metadatenmanagement ermöglicht eine umfassendere Nutzung von Metadaten, etwa Anreicherung, Datenmaskierung und Klassifizierung, wodurch Datenqualität, Sicherheit und Nutzbarkeit verbessert werden.
Insgesamt vereinfachen und automatisieren Metadaten-Lakes das Management des Datenlebenszyklus, erleichtern die Zusammenarbeit zwischen technischen Teams und helfen dabei, Datensilos zu beseitigen, die die RAG-Entwicklung behindern.
Demo: Aufbau von Metadaten-Lakes mit Gravitino
Lisa berichtete von ihrer Erfahrung bei der Arbeit an einem Open-Source-Projekt, in dem ein Metadaten-Lake mit Gravitino entwickelt wurde. Das Projekt zielte darauf ab, einen Datenkatalog zu erstellen, der mehrere Cloud-Service-Anbieter unterstützt, darunter AWS, Azure und GCP. Er ermöglicht es Benutzern, verschiedene Datenquellen im Metadaten-Lake zu registrieren, wie S3-Buckets, die Milvus vector database, HiMetastores und andere Datenspeicher. Gravitino bietet außerdem Zugriffskontrollen und Werkzeuge zur Nachverfolgung der Datenherkunft sowie zur Unterstützung von Audits.
Figure 5- The metadata lake architecture built with Gravitino
Abbildung 5: Die mit Gravitino aufgebaute Metadaten-Lake-Architektur
Die Architektur nutzt REST APIs, um Metadaten für verschiedene Anwendungen bereitzustellen. Die Verbindungsebenen konvertieren alle Daten in ein gemeinsames Schema, bevor sie im Metadaten-Lake gespeichert werden. Gravitino unterstützt sowohl tabellarische als auch nicht-tabellarische Datenformate und ermöglicht tagbasiertes Masking, um Datensicherheit zu gewährleisten.
KI-Teams können außerdem Wissensgraphen und vector stores innerhalb des Metadatenmanagement-Frameworks integrieren und so einen einheitlichen Katalog erstellen. Aufgrund der föderierten Natur des Katalogs können Abfragen auf Metadaten zugreifen, ohne die Quelldaten zu verschieben. Join-Operationen erfolgen entweder im Arbeitsspeicher oder an definierten Orten, wodurch die Leistung optimiert und die Datenintegrität in verteilten Umgebungen gewahrt wird.
Fazit
Metadaten-Lakes entwickeln sich zu KI-Katalogen, die Metadaten verwalten und sich in KI- und ML-Workflows integrieren. Diese Lakes können bei der RAG-Entwicklung, der Modellregistrierung, der KI-Governance und der Implementierung fortschrittlicher Analysen unterstützen. Durch die Bereitstellung einer einheitlichen Ebene für Datenoperationen ermöglichen Metadaten-Lakes Teams, die Beobachtbarkeit in der Metadatenanalyse aufrechtzuerhalten, reibungslose Übergänge zwischen verschiedenen Cloud-Umgebungen und Datenquellen wie der Milvus-Vektordatenbank sicherzustellen und Governance-Frameworks nahtlos einzuhalten. Mit dem Fortschritt von KI-Technologien werden Metadaten-Lakes eine Schlüsselrolle bei der Unterstützung von KI/ML-Anwendungen der nächsten Generation spielen.
Weitere Ressourcen
Fendy FengFendy Feng is the Technical Marketing Writer at Zilliz. She has extensive experience developing and enhancing the impact of open-source projects in various global markets by producing high-quality, tailored content. Before joining Zilliz, Fendy worked as a Content Strategist at PingCAP, a fast-growing E-Series startup renowned for its open-source distributed SQL database.
ShriVarsheni R
Weiterlesen
Notion's Vector Search Is Excellent. Their Next Problem Is Harder.
Notion solved vector search scaling in two years. The next bottleneck — offline context engineering, unified data, and the real-time/offline gap — is harder.
Why I’m Against Claude Code’s Grep-Only Retrieval? It Just Burns Too Many Tokens
Learn how vector-based code retrieval cuts Claude Code token consumption by 40%. Open-source solution with easy MCP integration. Try claude-context today.
The Real Bottlenecks in Autonomous Driving — And How AI Infrastructure Can Solve Them
Autonomous driving faces a data bottleneck. Learn how AI-native vector databases like Zilliz solve scale, cost, and insight challenges across AV pipelines.