Multimodelltabellen: Eine Tabelle für Dateien, Embeddings sowie hybride Suche für Agenten.

Seit Jahren entwickelt sich die betreffende Datenbank zu einem einzigen, integrierten System, das verteiltes Transaktionsverarbeitung für kritische Arbeitslasten, HTAP, mehrmodellbasierte Daten sowie hybride Suchfunktionen umfasst. Sein Lakebase-Produkt signalisiert eine weitere Veränderung in der Schwerpunktsetzung. Die Frage lautet nicht mehr nur, was die Datenbank verarbeiten kann, sondern wer sie bedient. Früher wurden Datenbanken für Entwickler, DBAs und Anwendungen entwickelt. Der Anbieter argumentiert, dass sie in der KI-Ära auch eine neue Art von Nutzer bedienen müssen – nämlich Agenten.

Nach dieser Definition ist eine „KI-Datenbank“ nicht einfach nur eine, die Bilder, PDFs oder Vektoren speichern kann. Es handelt sich dabei um eine Datenbank, die darauf ausgelegt ist, Agenten vollständigen, aktuellem und zuverlässigen Kontext zur Verfügung zu stellen, damit sie daraus ableiten und handeln können – wobei Embeddings, Rohdateien sowie hybride Suchfunktionen aus derselben Quelle stammen. Der Rest beschreibt die Multimodell-Tabelle-Funktion in Lakebase sowie das Problem, das damit gelöst werden soll. Dies sind die Angaben des Anbieters – überprüfen Sie sie daher anhand Ihrer eigenen Arbeitslast.

Das Datenproblem der Agenten

Stellen Sie sich eine Entscheidung eines Agenten vor. Möglicherweise benötigt er gleichzeitig ein strukturiertes Benutzerprofil, eine Textzusammenfassung des Gesprächs, das ursprüngliche PDF aus einer Wissensdatenbank, semantische Ergebnisse aus der Vektorabrufung sowie den aktuellen Zustand des Unternehmens.

Heutzutage befinden sich diese fünf Elemente in der Regel in fünf Systemen: Objektspeicher, Suchmaschine, Vektordatenbank, Unternehmensdatenbank und Offline-Lager. Es gibt weder gemeinsame Transaktionen noch konsistente Snapshots noch eine gemeinsame Abstammungslinie.

Falls ein PDF aktualisiert wird, während seine Verknüpfung weiterhin auf die alte Version verweist, antwortet der Agent zuversichtlich, aber falsch – und niemand bemerkt es. Es geht dabei nicht darum, mehr Datentypen zu speichern, sondern um Probleme in der Governance. Sobald multimodale Daten auf dem kritischen Weg liegen, muss jemand die Versionskonsistenz, Vollständigkeit der Berechnungen, Nachvollziehbarkeit und Vertrauenswürdigkeit gewährleisten. In vielen Teams ist das jemand, der die Pipelines besitzt, jeden Quartal debuggt und neu schreibt.

Die Multimodell-Tabelle ist Lakesbase’s Lösung. Sie ist die zentrale Datenverwaltungsfunktion des Produkts und verarbeitet Bilder, Audio, Video, PDFs, Web-Snapshots, Vektoren, JSON sowie strukturierte Spalten als eigenständige Datenbankobjekte. Sie befinden sich in einem System, das Transaktionen, Konsistenz, hohe Verfügbarkeit, hybride Suchfunktionen, analytische Berechnungen sowie Online-Verfügbarkeit bietet.

Warum Agenten ein anderes Datenmodell benötigen

Die Objekte, mit denen Agenten arbeiten, sind von Natur aus multimodell. Zu den Eingaben gehören natürliche Sprache, Bilder, PDFs, Webseiten, Tabellen sowie Geschäftskontexte. Während des Betriebs stützt sich der Agent auf Benutzermerkmale, Wissensbasen, RAG-Ergebnisse, strukturierte Geschäftsdaten, semantische Profile sowie Ergebnisse interner Modelle.

Daraus ergeben sich vier Veränderungen:

1. Unstrukturierte Daten rücken in den Mittelpunkt. Sie sind nicht mehr nur Anhänge in der Objektspeicherung, sondern werden zu wichtigen Eingabedaten für Entscheidungen.
2. Der Zugriff erfolgt mittels hybrider Suche. Eine einzige Anfrage kann strukturierte Filter, Volltextsuche, Vektorabruf sowie analytische Aggregationen kombinieren.
3. Die Anforderungen an Echtzeitfunktionen steigen. Automatisierte Prozesse laufen rund um die Uhr, wodurch tägliche Berichte nicht mehr ausreichen.
4. Funktionen werden dynamisch erzeugt. Viele Felder werden nicht direkt eingegeben; Modelle extrahieren sie asynchron aus Rohdaten.

Die praktische Frage ist, wie Rohdaten verschiedener Modelle, strukturierte Felder, abgeleitete Eigenschaften sowie asynchrone Ergebnisse in einer einzigen Datenbank vereint werden können, sodass sie gemeinsam für Online-Transaktionen, Analysen und hybride Suchfunktionen genutzt werden können, ohne Konsistenz oder Übersichtlichkeit zu verlieren. Das ist das Designproblem, das die Multimodell-Tabelle lösen soll.

Kernfunktionen

Ein Ort für Multimodell-Objekte

Multimodell-Tabellen stellen diese Objekte unter die eigene Transaktions- und Versionskontrolle der Datenbank. Große Objekte wie Bilder, Audio-Dateien, Videos, PDFs und Web-Snapshots können auf verschiedene Weise gespeichert werden. Wo die Bytes physisch gespeichert sind, ist weniger wichtig als das, was die Datenbank bezüglich ihnen verspricht: eine nicht veränderliche ID, einen Zugriffspfad, eine Versionsnummer, einen Sichtbarkeitsstatus sowie einen definierten Transaktionsumfang.

Dies dient dazu zu gewährleisten, dass ein Rohobjekt sowie seine abgeleiteten Eigenschaften wie Zusammenfassungen, Labels, Embeddings und Risikowerte stets zur gleichen Datenversion gehören. Der Fehler, bei dem ein Objekt aktualisiert wird, seine Eigenschaften aber weiterhin den alten Inhalt beschreiben, sollte nicht auftreten.

Dynamische Eigenschaftsspalten

Multimodale Daten sind reichhaltig, und ein einzelnes Rohobjekt kann eine endlose Anzahl von Eigenschaften hervorbringen: semantische, strukturelle, qualitätsbezogene sowie unternehmensspezifische. Aus Texten lassen sich Themen, Zusammenfassungen, Embeddings, Sicherheitslabels, die Sprache sowie eine Qualitätsbewertung gewinnen. Aus Bildern ergeben sich OCR-Ergebnisse, Tags, Risikobewertungen und unternehmensbezogene Attribute. Jedes neue Modell fügt weitere hinzu.

Im Rahmen eines klassischen Schemas bedeutet jede neue Eigenschaft eine Änderung im DDL. Jede solche Änderung führt zu einer Invalidation des Caches, zu einer Vergrößerung der Schreibbelastung sowie zu zusätzlichem Druck bei der Hintergrundkompression, wodurch die Arbeitsgeschwindigkeit bei der Erstellung neuer Eigenschaften auf die Geschwindigkeit der Tabellensperren beschränkt wird.

Multimodell-Tabellen nutzen ein leichtgewichtiges Mechanismus für dynamische Spalten. Das Hinzufügen neuer Funktionen erfordert keine Änderung des Schemas, Abfragen bleiben SQL-kompatibel, die analytische Optimierung bleibt wirksam und die hybride Suche nutzt weiterhin Indizes. Es handelt sich dabei nicht um einen Rückzug zu Schlüssel-Wert-Speichern, die zwar flexibel sind, aber keinerlei Unterstützung für SQL-Analysen oder Suchoptimierungen bieten. Das Design bewusst einen Kompromiss zwischen optimierbarer Struktur und dynamischer Erweiterbarkeit und versucht, beides zu bewahren.

Asynchrone, nahezu Echtzeit-Berechnungen

Viele Spalten werden überhaupt nicht von Benutzern erstellt. Berechnungsaufgaben erzeugen sie, darunter Embeddings, Zusammenfassungen, OCR-Ergebnisse, Qualitätsbewertungen, Volltext-Indizes und Vektor-Indizes, unter Verwendung eingebauter Modellfunktionen, Hintergrundaufgaben oder externer Pipelines.

Die Modellinferenz dauert in der Regel Hunderte von Millisekunden bis Sekunden – das ist zu langsam, um eine Online-Schreiboperation zu blockieren. Deshalb wartet die Tabelle nicht:

1. Erst werden Rohdaten gespeichert, um die Latenz bei Online-Schreibvorgängen beizubehalten.
2. Hintergrundaufgaben starten die Extraktion von Eigenschaften, den Aufbau von Indizes sowie das Nachfüllen gemäß der Abstammungslinie.
3. Abgeleitete Werte erscheinen innerhalb eines nahezu Echtzeit-Fensters.
4. Lesevorgänge erhalten stets ein einheitliches Snapshot.

Die Begründung dafür ist, dass eine strenge Synchronisierung jeder abgeleiteten Spalte unpraktisch und unnötig ist. Ein kontrollierbares Gleichgewicht zwischen Latenz, Durchsatz, Speichereffizienz und Konsistenz ist das richtige Ziel. Die Berechnungsaufgaben erzeugen die Werte, und die Tabelle sorgt dafür, dass sie steuerbar, suchbar, analysierbar und konsistent lesbar sind.

Konsistenz von Spaltengruppen

Asynchrone Berechnungen führen zu einem Sichtbarkeitsproblem. Sobald eine Zeile vorhanden ist, können Feature A, Feature B, die Embeddings, die Volltextindizes sowie die Qualitätslabels zu unterschiedlichen Zeitpunkten fertiggestellt werden – durch verschiedene Aufgaben und Modelle. Wenn eine Abfrage feststellt, dass B bereits abgeschlossen ist, während A noch aussteht, liefert sie ohne jegliche Warnung falsche Ergebnisse.

Die Konsistenz der Spaltengruppen wird in der Speicherschicht geregelt. Eine Geschäftsspaltengruppe wird erst dann zu einem neuen, sichtbaren Snapshot, nachdem alle damit verbundenen abgeleiteten Spalten fertiggestellt wurden. Abfragen sowie hybride Suchfunktionen lesen einen konsistenten Snapshot und stoßen niemals auf unvollendete Daten.

Trennter Speicher und Rechenbereich, mit Hot- und Cold-Daten zusammen

Die Datenmenge aus mehreren Modellen wächst bei Dokumenten, Bildern, Videos, Vektoren sowie abgeleiteten Merkmalen unbegrenzt, weshalb es im großen Maßstab nicht praktikabel ist, all diese Daten stets schnell zugänglich zu halten. Diese Systeme basieren auf einer dezentralen Architektur mit gemeinsam genutztem Speicher und betrachten „heiße“ und „kalte“ Daten als einen kontinuierlichen Bereich:

• Neue Daten, beispielsweise die der letzten 90 Tage, werden im SSD-Cache gespeichert, damit der Zugriff weiterhin schnell bleibt.
• Ältere Daten, etwa solche, die älter als 90 Tage sind, werden auf günstigerem gemeinsam genutztem Speicher abgelegt, bleiben aber weiterhin über dieselbe Schnittstelle abfragbar, suchbar und analysierbar.

Man muss nicht zwischen Systemen wechseln, um auf kalte Daten zuzugreifen, oder eine Online-Datenbank, Objektspeicher sowie einen Offline-Speicher kombinieren, um eine einzige Frage zu beantworten. Es gibt eine einzige Ansicht, eine einzige Abfrageschnittstelle sowie ein einheitliches Verwaltungssystem.

Abstammung und ein einheitliches Katalogsystem

Welcher Textabschnitt stammt von dieser Einbettung? Welches Prüfmodell hat diese Sicherheitskennzeichnung zugewiesen? Welche Version des PDFs beschreibt diese Zusammenfassung?

Lineage und das einheitliche Katalogsystem bilden das Rückgrat der Metadaten. Sie erfassen, wie Rohobjekte, strukturierte Felder, dynamische Merkmalsspalten, Modelltätigkeiten, Versionen und Berechtigungen miteinander verbunden sind. Die Metadaten unterstützen drei Aspekte:

1. Auslösung. Hintergrundaufgaben zur Extraktion, Indexerstellung und Nachfüllung starten automatisch über Lineage.
2. Vollständigkeit. Bevor die Sichtbarkeit weitergegeben wird, prüft das System, ob eine Spaltengruppe oder ein Snapshot vollständig berechnet wurde.
3. Recherchierbarkeit. Wenn ein Agent eine Antwort gibt, kann man diese auf die Dokumente, Bilder, Datensätze und abgeleiteten Merkmale zurückverfolgen, die er verwendet hat.

Eine Zugriffsstufe für Transaktionen, Analytik und Suchfunktionen

Eine Multimodell-Tabelle wird als gemeinsame Grundlage für drei Arbeitslasten an denselben Daten beschrieben:

• Online-Transaktionen, d.h. Geschäftsaktivitäten mit ACID-Garantien und hoher Verfügbarkeit;
• Analysen, d.h. umfangreiche Scans, Aggregationen, Filter, Verknüpfungen sowie Analyse von Merkmalen;
• Hybride Suche, d.h. strukturierte Filter in Kombination mit Volltextsuche, Vektorabruf, Tag-Filtern sowie Geschäfts-Ranking.

Der Zugriff durch Agenten ist von Natur aus mehrstufig. Eine Anfrage kann zunächst nach strukturierten Bedingungen filtern, anschließend Beschreibungen als Volltext durchsuchen, danach ähnlichen Inhalt über Vektorabruf finden und schließlich nach Tags, Qualität, Aktualität sowie Berechtigungen ranken. Kein einzelner spezialisierter Motor deckt alle vier Schritte ab.

Der zentrale Kompromiss besteht zwischen nahezu Echtzeit-Verarbeitung und starker Synchronisation. Suchfunktionen und Analysen benötigen keine abgeleiteten Eigenschaften, um innerhalb der Schreibtransaktion abgeschlossen zu werden, doch diese Eigenschaften müssen innerhalb eines kurzen, begrenzten Zeitraums sichtbar werden und aus einem konsistenten Snapshot abgerufen werden können. So kann eine einzige Tabelle Online-Schreibvorgänge, hybride Suchfunktionen sowie Analysen unterstützen, ohne die Kosten für das Beibehalten von drei zusammengefügten Kopien entstehen zu lassen.

Was es ersetzt

Bei heutigen Agentenprojekten wird argumentiert, dass es einen Stack aus Objektspeicher, Suchmaschine, Vektordatenbank, Geschäftsdatenbank sowie Offline-Lager ersetzt. Der alte Kompromiss zwischen breiter Multimodell-Unterstützung und datenbankgerechter Verwaltung soll damit verschwinden.

Warum es wichtig ist

Die eigentliche Frage ist nicht, ob eine KI-Datenbank Bilder, PDFs oder Vektoren speichern kann. Vielmehr geht es darum, was sich ändert, wenn Agenten zu erstklassigen Nutzern der Datenbank werden.

Falls die Antwort lautet, es gibt ein weiteres isoliertes System pro Datentyp, dann gibt es mehr zu schützen, mehr Pipelines, die gestört werden können, sowie mehr stillen Verfall. Wenn die Antwort eine einzige, gemanagte Tabelle ist, in der jede Modality ein erstklassiges Objekt darstellt, erhält man eine echte Datenbasis anstelle eines aus Pipelines bestehenden Gerüsts.

Multimodell-Tabellen bringen strukturierte Daten, unstrukturierte Daten, aus KI abgeleitete Merkmale sowie Geschäftssemantiken unter ein einziges System für Transaktionen, Governance und Berechnungen. Datenbanken dienen dazu, Daten zu vereinigen. Im Zeitalter der KI müssen sie Daten, Semantiken sowie die Prozesse, die sie erzeugen, vereinigen – und diese Funktion ist der erste Schritt von Lakebase in diese Richtung.

Bewertung

Multimodell-Tabellen werden als Teil von Lakebase bereitgestellt. Um sie an die Last Ihres eigenen Agenten anzupassen, listen Sie die Datenarten auf, die Sie verwalten müssen, das Szenario des Agenten, das Sie entwickeln, sowie alle Leistungs- oder Governance-Anforderungen auf. Modellieren Sie anschließend eine Multimodell-Tabelle und vergleichen Sie sie mit der Technologie, die sie ersetzen würde. Der entscheidende Test ist, ob der Agent keine falschen Antworten mehr liefert.