Vergleich relationaler Foundation-Modelle

Wir haben SAP-RPT-1-OSS mit Gradient Boosting (LightGBM, CatBoost) auf 17 tabellarischen Datensätzen verglichen, die das semantisch-numerische Spektrum abdecken: kleine/hochgradig semantische Tabellen, gemischte Geschäftsdatensätze sowie große, wenig semantische numerische Datensätze.

Unser Ziel ist es zu messen, wo die durch Vortraining erworbenen semantischen Priors eines relationalen LLM Vorteile gegenüber traditionellen Baummodellen bieten können und wo sie bei großer Skalierung oder schwach semantischen Strukturen an Grenzen stoßen.

SAP-RPT-1-OSS vs. Gradient Boosting: Benchmark-Ergebnisse

• Erfolgsquote: Stellt den durchschnittlichen normalisierten Score (0.0 bis 1.0) dar. Ein höherer Balken zeigt an, dass das Modell in dieser Kategorie konsistent näher an der bestmöglichen Leistung für die Datensätze liegt.
• 100 – 500 Zeilen (3 Datensätze):
  • Enthalten: wine (178), sonar (208), vote (435).
  • Ergebnis: SAP schneidet bei 2 von 3 Datensätzen am besten ab. Es erzielt die höchsten Scores bei wine und sonar, was darauf hindeutet, dass LLM-Priors vorteilhaft sein können, wenn nur wenig Trainingsdaten verfügbar sind. CatBoost errang jedoch einen knappen Sieg im vote-Datensatz (innerhalb von 0,1 %), was zeigt, dass Baummodelle selbst in kleinem Maßstab sehr wettbewerbsfähig bleiben.
• 501 – 1.000 Zeilen (3 Datensätze):
  • Enthalten: cylinder_bands (540), breast_cancer (569), credit_g (1.000).
  • Ergebnis: SAP schneidet bei allen 3 Datensätzen am besten ab. Bei cylinder_bands übertraf SAP LightGBM um 5,5 %, möglicherweise wegen der besseren Verarbeitung semantischer Beschreibungen industrieller Defekte; allerdings wären weitere Ablationsstudien nötig, um diesen Mechanismus zu bestätigen.
• 1.000 – 10.000 Zeilen (5 Datensätze):
  • Enthalten: titanic (1.3K), car_evaluation (1.7K), spambase (4.6K), compas (5.2K), employee_salaries (9.2K).
  • Ergebnis: SAP erzielt die besten Ergebnisse bei 4 von 5 Datensätzen und schneidet besonders gut bei textlastigen Aufgaben wie spambase und titanic ab. CatBoost übertrifft SAP jedoch deutlich bei compas um 10,4 %, was auf datensatzspezifische Eigenschaften hindeutet, die Baummodelle selbst in diesem Größenbereich begünstigen.
• 10.000+ Zeilen (6 Datensätze):
  • Enthalten: california_housing (20K), house_sales (21K), default_credit (30K), adult_income (48K), diamonds (53K), higgs_100k (98K).
  • Ergebnis: Mit zunehmendem Datenvolumen schwindet der potenzielle „Vorwissensvorteil“ des LLM. LightGBM und CatBoost erzielen bei 5 von 6 Datensätzen die besten Ergebnisse und bieten eine bessere Genauigkeit zu einem Bruchteil der Rechenkosten. Die einzige Ausnahme, california_housing, zeigt einen moderaten Vorteil von 1,7 % für SAP.

1. Benchmark-Ergebnistabelle der Datensätze

Nachfolgend finden Sie die vollständige Aufschlüsselung der Modellleistung über alle 17 Datensätze hinweg.

2. Kosten- & Effizienzanalyse

Wir haben die direkten Rechenkosten für jedes Modell auf Basis der RunPod-H200-Instanzpreise von $3,59/Stunde berechnet.

SAP-RPT-1-OSS verursacht erheblich höhere Kosten durch den Zeitaufwand für die Vorverarbeitung von Text-Embeddings und den hohen Speicheraufwand der LLM-Architektur. Im Gegensatz dazu erledigen LightGBM und CatBoost Aufgaben auf dieser Hardware nahezu sofort. Die nachstehenden Kosten spiegeln die gesamte Laufzeit (Vorverarbeitung + Training) für einen dreifachen Kreuzvalidierungslauf wider.

Durchschnittliche Kosten pro Datensatz (17 Datensatz-Durchschnitt)

Kostenaufschlüsselung nach Datensatzgröße

• Kleine Datensätze (<1K Zeilen): SAP ist relativ günstig (≈ $0,03 pro Lauf). Die hohe Erfolgsquote macht die Kosten hier vernachlässigbar.
• Große Datensätze (>20K Zeilen): SAP wird teuer.
  • Beispiel: Das Training auf adult_income (48k Zeilen) dauert insgesamt ≈$12 Minuten für 3 Durchläufe.
  • Kosten: 12 Min. x $0,06/Min. = $0,72 pro Experiment.
  • Vergleich: LightGBM erledigt dieselbe Aufgabe für $0,01.

Fazit: Auch wenn $0,22 pro Datensatz in absoluten Zahlen nicht teuer ist, ist SAP 22x teurer als die Baseline. Dieser Kostenunterschied mag für kleine, semantikreiche Datensätze gerechtfertigt sein, bei denen SAP deutliche Genauigkeitsverbesserungen zeigt (z. B. cylinder_bands mit +5,5 % Steigerung), wird aber bei großen Datensätzen schwerer zu rechtfertigen, bei denen Baummodelle gleiche oder bessere Leistung zu einem Bruchteil der Kosten erzielen.

3. Analyserahmen: Das semantische Spektrum

Um diese Ergebnisse zu interpretieren, ist es entscheidend zu verstehen, wie wir die Daten ausgewählt haben. Wir haben die Datensätze nicht zufällig gewählt, sondern einen Satz von 17 Datensätzen gezielt zusammengestellt, um das semantisch-numerische Spektrum abzudecken.

Unsere Kernhypothese war, dass SAP (auf LLM-Basis) dort glänzen würde, wo Daten sprachliche Bedeutung haben, während Baummodelle bei rein numerischen Berechnungen dominieren würden. Wir haben unsere Datensätze in drei unterschiedliche Cluster eingeteilt:

Cluster A: Hochsemantische Datensätze (6 Datensätze)

Merkmale: Die Features enthalten umfangreiche Textbeschreibungen, kategoriale Labels mit realer Bedeutung (z. B. „physician fee freeze“) oder domänenspezifische Terminologie.

• Datensätze:
  • cylinder_bands: Industrielle Druckfehler.
  • titanic: Passagiernamen und Titel.
  • vote: Abstimmungsprotokolle des Kongresses (kategorial „Ja/Nein“ zu politischen Maßnahmen).
  • breast_cancer: Medizinische Tumorbeschreibungen.
  • spambase: Worthäufigkeiten in E-Mails.
  • wine: Chemische Herkunft.

Cluster B: Gemischte Geschäftsdaten (6 Datensätze)

Merkmale: Das übliche tabellarische Format in den meisten Unternehmensdatenbanken: eine Mischung aus numerischen Werten (Gehalt, Alter) und kategorialen Zeichenfolgen (Berufsbezeichnung, Ethnie, Abteilung).

• Datensätze:
  • employee_salaries: Berufsbezeichnungen vs. Gehalt.
  • compas: Strafregister und demografische Daten (sensible Attribute).
  • adult_income: Volkszählungsdemografie.
  • credit_g: Deutsche Kreditrisikoprofile.
  • default_credit: Taiwanesische Kreditausfalldaten.
  • car_evaluation: Fahrzeugkauf-Parameter.

Cluster C: Wenig semantische/rein numerische Daten (5 Datensätze)

Merkmale: Die Features sind abstrakte Messwerte, Sensorwerte oder physikalische Koordinaten. Die Spaltennamen spielen oft keine Rolle; die mathematischen Beziehungen sind entscheidend.

• Datensätze:
  • higgs_100k: Kinematik physikalischer Teilchen.
  • diamonds: Physische Abmessungen und Preis.
  • sonar: Frequenzenergie-Reflexionen.
  • california_housing: Breiten-/Längenkoordinaten und Volkszählungsstatistiken.
  • house_sales: Immobilien in King County (überwiegend numerische Features).

4. Tiefenanalyse: Wo SAP gewinnt und wo SAP scheitert

Die Anwendung des Analyserahmens auf unsere Ergebnisse zeigt vier unterschiedliche Leistungsmuster. Die folgende Tabelle fasst genau zusammen, wo SAP überzeugt und wo es versagt.

Konzeptionelle Grundlagen relationaler Foundation-Modelle

Das Hauptziel eines relationalen Foundation-Modells besteht darin, genaue Vorhersagen zu treffen und vielfältige Aufgaben über strukturierte Tabellen hinweg auszuführen. Diese Modelle müssen verstehen, wie Informationen über verschiedene Tabellen hinweg dargestellt werden, wie Entitäten durch Beziehungen verknüpft sind und wie zeitliche Informationen die Ergebnisse beeinflussen.

Zu den wichtigsten Fähigkeiten solcher Modelle gehören:

• Schema-Generalisierung: Die Fähigkeit, sich an neue relationale Schemata anzupassen, ohne von Grund auf neu trainieren zu müssen.
• Einheitliche Eingabedarstellung: Umgang mit verschiedenen Spaltentypen wie numerischen, kategorialen und textuellen Merkmalen.
• Integration von zeitlichem und strukturellem Kontext: Erfassung von Abhängigkeiten über die Zeit und zwischen Entitäten, die durch Primär- und Fremdschlüssel verbunden sind.
• Übertragbarkeit: Ausführung prädiktiver Aufgaben auf neuen Datensätzen durch Vortraining und Zero-Shot-Lernen.

Griffin

Griffin ist einer der ersten groß angelegten Versuche, ein einheitliches relationales Foundation-Modell zu entwickeln. Es repräsentiert relationale Daten als einen zeitlichen, heterogenen Graphen, in dem jede Zeile zu einem Knoten wird und Kanten Fremdschlüsselbeziehungen entsprechen. Zu den wichtigsten Merkmalen gehören:

Einheitlicher Feature-Encoder

• Kategoriale und textuelle Features werden mit einem vortrainierten Text-Encoder kodiert, während numerische Werte einen gelernten Float-Encoder verwenden.
• Metadaten wie Tabellennamen, Spaltennamen und Kantentypen werden eingebettet, um dem Modell zu helfen, das relationale Schema zu erkennen.
• Aufgaben-Embeddings ermöglichen es einem einzelnen Modell, Regressions- und Klassifikationsaufgaben mit gemeinsamen Decodern auszuführen.

Message Passing und Attention

Griffin integriert Message-Passing-Neuronale-Netze mit einem Cross-Attention-Modul. Die Message-Passing-Komponente aggregiert Informationen innerhalb und zwischen Relationen, während Cross-Attention relevante Zellen innerhalb jeder Zeile fokussiert. Dieses Design hilft dem Modell, unterschiedliche Daten zu verarbeiten und den Kontext zwischen verbundenen Entitäten aufrechtzuerhalten.

Pre-Training und Fine-Tuning

Das Modell wird zunächst auf Einzeltabellen-Datensätzen durch eine Aufgabe zur Vervollständigung maskierter Zellen vortrainiert und anschließend für bestimmte Aufgaben auf relationalen Datenbanken fine-tuned. Experimente mit großen relationalen Benchmarks zeigen, dass Griffin herkömmliche GNN-Baselines und Einzeltabellenmodelle sowohl bei der Genauigkeit als auch bei der Effizienz des Transferlernens übertrifft.

Abbildung 1: Diagramm, das Griffin-Model-Framework zeigt.¹

Relational Transformer

Während Griffin auf Graph-Aggregation fokussiert, wendet der Relational Transformer (RT) Transformer-Architekturen direkt auf relationale Datenbanken an. Er behandelt jede Zelle als Token, das um seinen Wert, Spaltennamen und Tabellennamen angereichert ist.

Eingabedarstellung

Jedes Token kombiniert:

• Ein Werte-Embedding, das von seinem Datentyp abhängt (numerisch, Text oder Datum/Uhrzeit).
• Ein Schema-Embedding wird aus dem Tabellen- und Spaltentext generiert.
• Ein Masken-Token wird verwendet, wenn der Wert während des Pre-Trainings verborgen ist.

Diese Struktur ermöglicht es RT, relationale Datenbanken mit unterschiedlichen Schemata zu verarbeiten und gleichzeitig ein konsistentes Eingabeformat beizubehalten.

Relational Attention

RT führt einen relationalen Attention-Mechanismus ein, der auf Zellebene arbeitet. Er umfasst:

• Spalten-Attention zum Lernen von Werteverteilungen innerhalb von Spalten.
• Feature-Attention zum Kombinieren von Attributen innerhalb derselben Zeile oder verknüpfter übergeordneter Zeilen.
• Nachbar-Attention zum Aggregieren von Informationen aus verbundenen untergeordneten Zeilen.

Together, diese Attention-Schichten bilden einen relationalen Graph-Transformer, der Abhängigkeiten über Zeilen, Spalten und Tabellen hinweg modelliert.

Training und Transferergebnisse

RT wird auf relationalen Datenbanken aus RelBench vortrainiert. In Experimenten erreichte das vortrainierte Modell bis zu 94 % der Leistung vollständig überwachter Modelle in Zero-Shot-Szenarien. Außerdem lernte es während des Fine-Tunings schneller und benötigte weniger Trainingsschritte, um eine hohe Genauigkeit zu erreichen.²

Dieser Ansatz deutet darauf hin, dass relationale Datenbanken übertragbare Muster über Domänen hinweg teilen und dass die Tokenisierung auf Zellebene eine praktische Grundlage für prädiktive Aufgaben auf strukturierten Daten bietet.

RelBench

RelBench wurde entwickelt, um relationales Deep Learning voranzubringen, das sich auf End-to-End-Lernen aus Daten konzentriert, die über mehrere verbundene Tabellen in relationalen Datenbanken verteilt sind.

Da relationale Datenbanken in Industrie und Wissenschaft das dominierende Datenmanagementsystem bleiben, bietet RelBench ein standardisiertes und reproduzierbares Framework für die Bewertung von Modellen, die direkt auf relationalen Strukturen arbeiten, statt auf manuelles Feature-Flattening angewiesen zu sein.

Frühere Versionen von RelBench führten 11 relationale Datenbanken ein, die Domänen wie Gesundheitswesen, soziale Netzwerke, E-Commerce und Sport abdecken, mit 70 prädiktiven Aufgaben, die sowohl anspruchsvoll als auch domänenrelevant sind.³

Im Januar 2026 wurde RelBench v2 veröffentlicht und um vier neue Datenbanken (SALT, RateBeer, arXiv und MIMIC-IV) sowie 40 zusätzliche prädiktive Aufgaben erweitert, darunter eine neue Klasse von Autocomplete-Aufgaben, mit denen die Fähigkeit eines Modells bewertet wird, vorhandene Spalten in einer relationalen Datenbank vorherzusagen.

Die Veröffentlichung erweiterte außerdem den Datenzugriff durch CTU-Integration und ermöglicht über ReDeLEx den Zugriff auf mehr als 70 relationale Datensätze; fügte direkte SQL-Datenbankanbindung hinzu; und integrierte sieben Datensätze aus dem 4DBInfer-Repository im RelBench-Format.

Über Datensätze und Aufgaben hinaus bietet RelBench eine quelloffene Referenzimplementierung für relationales Deep Learning auf Basis von Graph Neural Networks, die PyTorch Geometric für die Graphenkonstruktion und PyTorch Frame für die tabellarische Modellierung nutzt, zusammen mit einer öffentlichen Bestenliste zur Fortschrittsverfolgung.

Die v2-Version führte außerdem mehrere Verbesserungen bei Benutzerfreundlichkeit und Leistung ein, darunter optionale zeitlich zensierte Labels, Unterstützung der NDCG-Metrik bei der Linkvorhersage, schnellere Generierung von Satz-Embeddings und konfigurierbares Cache-Management.⁴

VIEIRA

VIEIRA verfolgt einen anderen Ansatz, indem es sich auf die Programmierung mit Foundation-Modellen konzentriert, statt eine einzelne Predictive Engine zu bauen. Es erweitert den probabilistischen Logik-Compiler SCALLOP um eine deklarative Sprache, die große Sprachmodelle, Bildmodelle und andere vortrainierte Komponenten als Fremdprädikate integriert.⁵

Relationales Paradigma

In VIEIRA werden Foundation-Modelle als zustandslose Funktionen mit relationalen Ein- und Ausgaben behandelt. Dadurch lassen sich Modelle wie GPT, CLIP oder SAM nach logischen Regeln zusammensetzen. Zum Beispiel:

• Ein Programm kann GPT verwenden, um Wissen aus Text zu extrahieren und als strukturierte Relationen zu speichern.
• CLIP kann Bilder klassifizieren und mit textuellen Labels in einer Tabelle verknüpfen.

Anwendungen

Das Framework unterstützt:

• Datums- und Mathematikschlussfolgerungen mit GPT.
• Verwandtschaftsschlussfolgerungen mithilfe von Textextraktion und logischer Inferenz.
• Fragebeantwortung, die Retrieval und Schlussfolgern kombiniert.
• Visuelle Fragebeantwortung und Bildbearbeitung durch multimodale Komposition.

Durch die Vereinheitlichung von symbolischer Logik und neuronaler Inferenz ermöglicht VIEIRA Datenanalysten und Entwicklern, interpretierbare Systeme zu bauen, die vortrainierte Foundation-Modelle nutzen, um prädiktive Abfragen über strukturierte Daten und Bilder zu beantworten.

Verpassen Sie nicht unsere Benchmarks und datengestützten Erkenntnisse. Die Schaltfläche öffnet Google; die Auswahl von AIMultiple bestätigt, dass Sie AIMultiple häufiger in den Google-Suchergebnissen sehen möchten.

Als bevorzugte Quelle hinzufügen

Fallstudien

SAP Hana Cloud

SAP HANA Cloud ist ein cloud-nativer, vollständig verwalteter Database-as-a-Service, der als einheitliche Datengrundlage für Unternehmensanwendungen dienen soll, die Transaktionen, Analysen und KI kombinieren. Statt nur als relationale Einzweckdatenbank zu dienen, ist SAP HANA Cloud als Multi-Model-Plattform positioniert, mit der Unternehmen „intelligente Datenanwendungen“ auf Basis operativer Geschäftsdaten erstellen können.

SAP HANA Cloud kombiniert In-Memory-Verarbeitung mit plattenbasiertem Speicher und Data-Lake-Integration, um unterschiedliche Leistungs- und Kostenanforderungen zu unterstützen. Dieses flexible Design unterstützt Echtzeit-Workloads und skaliert dynamisch, wenn Datenmengen und Nutzung schwanken.

Ein entscheidendes Differenzierungsmerkmal ist die native Multi-Model-Engine, die relationale, JSON-/Dokument-, Graph-, Geodaten- und Vektordaten in einer einzigen Datenbank unterstützt. Dadurch können Anwendungen SQL-Abfragen, Graphbeziehungen und Vektorähnlichkeitssuche kombinieren, ohne Daten zwischen getrennten Systemen verschieben zu müssen, was die Architektur vereinfacht und die Latenz reduziert.

Als Teil der SAP Business Technology Platform integriert sich SAP HANA Cloud direkt mit SAP- und Nicht-SAP-Datenquellen, einschließlich Live-Zugriff ohne Replikation, und bietet standardmäßig Sicherheit, Verfügbarkeit und Compliance auf Unternehmensniveau.

Insgesamt ist SAP HANA Cloud eine relational-zentrierte, KI-native Datenplattform, in der die relationale Datenbank als Fundament für Analysen, Multi-Model-Daten und Unternehmens-KI-Anwendungen dient.

Abbildung 2: Bild, das Hanas einheitliche Datenbank und
Multi-Model-Datenverarbeitung zeigt.⁶

SAPs sap-rpt-1

sap-rpt-1 führt ein einziges relationales Foundation-Modell ein, das ein breites Spektrum prädiktiver Aufgaben durch In-Context-Lernen ausführt. Statt für jeden Anwendungsfall ein neues Modell neu zu trainieren, geben Nutzer einige Beispiele ihres Zielmusters an, etwa „Kunden, die pünktlich gezahlt haben“ und „Kunden, die verspätet gezahlt haben“. Das Modell erkennt dann das Muster und erstellt sofort genaue Vorhersagen für neue Daten.

Das Modell ist mit einem zweidimensionalen Aufmerksamkeitsmechanismus konzipiert, der Beziehungen über Zeilen und Spalten hinweg erfasst und gleichzeitig Metadaten wie Tabellen- und Spaltennamen in Vektor-Embeddings einbettet. Dieses Design ermöglicht es, die Semantik relationaler Schemata und die zeitlichen Informationen in Geschäftstabellen zu verstehen.

Der Ansatz von SAP bringt Datenanalysten und Business-Anwendern mehrere Vorteile:

• Ein einziges Modell, das über mehrere Tabellen und Domänen hinweg funktioniert.
• Keine Notwendigkeit für wiederholtes Fine-Tuning oder individuelle Entwicklung.
• Zugang zu prädiktiven Erkenntnissen in Minuten statt Wochen.
• Integration mit bestehenden Data Warehouses und SAP-Systemen.

Durch die Einbettung von sap-rpt-1 in das SAP-Ökosystem können Fachexperten direkt mit ihren eigenen Daten interagieren und Vorhersagen über intuitive Oberflächen erhalten. Das Ergebnis ist ein schnellerer Weg von strukturierten Daten zu umsetzbaren Entscheidungen ohne manuelles Feature-Engineering.

Abbildung 3: Fehlerreduktionsfaktor von sap-rpt-1-large gegenüber Narrow-KI-Baselines über SAP-Domänen hinweg.

Ende 2025 bestätigte SAP, dass SAP-RPT-1 über den Generative-KI-Hub in SAP KI Foundation (SAP KI Core) verfügbar ist.

Das Modell wird in zwei Produktionsvarianten angeboten:

• SAP-RPT-1-small, optimiert für Vorhersagen mit niedriger Latenz und hohem Durchsatz,
• SAP-RPT-1-large, konzipiert für höchste Vorhersagegenauigkeit.

Diese Veröffentlichung formalisiert die Rolle von SAP-RPT-1 als bereitstellbares Foundation-Modell innerhalb des Enterprise-KI-Stacks von SAP und nicht nur als reine Forschungskomponente.

Darüber hinaus bietet SAP den SAP-RPT Playground an, eine No-Code-Umgebung im Web, in der Nutzer In-Context-Lernen mit eigenen oder von SAP bereitgestellten Beispieldaten testen können.

SAP-ABAP-1

SAP-ABAP-1 ist ein Foundation-Modell, das KI-basierte Produktivitätsanwendungsfälle für SAP-Kunden und -Partner unterstützen soll.

Es ist über den Generative-KI-Hub von SAP verfügbar und wurde mit mehr als 250 Millionen Zeilen ABAP-Code, 30 Millionen Zeilen CDS-Code und umfangreicher technischer Dokumentation trainiert. Das Modell ist darauf optimiert, ABAP-Code zu verstehen und zu erklären, Best Practices aufzuzeigen und Zugang zu aktuellem SAP-Entwicklungswissen zu bieten.

SAP bietet kostenlos Testzugang zu SAP-ABAP-1 über den Generative-KI-Hub an; weitere Funktionen sind für die Veröffentlichung im Jahr 2026 geplant.⁷

Kumo.AIs KumoRFM: ein relationaler Graph-Transformer für Predictive Analytics

Kumo.KI, gegründet von Stanford-Professor Jure Leskovec, hat KumoRFM entwickelt, ein relationales Foundation-Modell, das einen relationalen Graph-Transformer zur Analyse relationaler Datenbanken und Data Warehouses verwendet. Es stellt relationale Daten als zeitlichen, heterogenen Graphen dar, in dem jede Entität ein Knoten ist und Primär- und Fremdschlüssel Kanten zwischen Tabellen bilden.

Dieser graphbasierte Ansatz ermöglicht es KumoRFM, gleichzeitig aus mehreren Tabellen zu lernen und sich an neue relationale Schemata anzupassen. Das Modell wird auf vielfältigen Datenquellen vortrainiert und kann auf neue Datensätze generalisieren, ohne für jede prädiktive Aufgabe separate Modelle zu erstellen.

KumoRFM kann je nach Fachkenntnis über verschiedene Schnittstellen genutzt werden:

• PQL (Predictive Query Language): Eine spezialisierte Abfragesprache zur Definition prädiktiver Abfragen auf strukturierten Daten.
• Natürlichsprachliche Schnittstelle: Für nicht-technische Nutzer werden natürlichsprachliche Eingaben automatisch in PQL-Abfragen übersetzt.
• Python SDK: Ermöglicht Entwicklern, das Modell in KI-Pipelines und -Anwendungen im Unternehmen zu integrieren.

Die KumoRFM-Architektur sampelt die Datenbank dynamisch, um Kontext-Teilgraphen und Vorhersage-Teilgraphen zu erstellen. Diese Teilgraphen werden vom relationalen Graph-Transformer verarbeitet, der Abhängigkeiten und zeitliche Informationen über verbundene Entitäten hinweg erfasst. Durch In-Context-Lernen liefert das Modell genaue Vorhersagen und kann seinen Schlussfolgerungsprozess erklären.

Kumo bietet zwei Bereitstellungsoptionen, die für Unternehmensumgebungen geeignet sind:

• SaaS-Plattform: Ein cloudbasierter Dienst auf Basis von Apache Spark für einfachen Zugriff und einfache Skalierung
• Data-Warehouse-nativ: Ermöglicht Unternehmen, ihre eigenen Daten in Snowflake oder Databricks zu nutzen, ohne sie aus ihrer sicheren Umgebung herauszubewegen

Im Gegensatz zu herkömmlichen Knowledge Graphs, die eine manuelle Schemadefinition erfordern, konstruiert KumoRFM seinen relationalen Graphen automatisch aus strukturierten Quellen. Dadurch eignet es sich gut für E-Commerce, Finanzen und Gesundheitswesen, wo Beziehungen, zeitliche Muster und sich verändernder Kontext für zuverlässige Vorhersagen entscheidend sind.

Zu den wichtigsten Fähigkeiten von KumoRFM gehören:

• Flexibilität über verschiedene Tabellen und Schemastrukturen hinweg.
• Kompatibilität mit einer Vielzahl von Spaltentypen und benutzerdefinierten Identifikatoren.
• Anpassung an spezifische Aufgaben zur Inference-Zeit.
• Hohe Genauigkeit und Interpretierbarkeit bei prädiktiven Aufgaben.

Abbildung 4: Die Abbildung zeigt, wie Relational Foundation Models (RFMs) über mehrere Domänen wie E-Commerce, Finanzen und Gesundheitswesen hinweg funktionieren, um Vorhersagen zu treffen, Erklärungen zu liefern und Ergebnisse zu bewerten.⁸

Benchmark-Methodik

Benchmark-Setup & Umgebung

Um faire Vergleiche zwischen CPU-gebundenen Bäumen und GPU-beschleunigten Modellen zu gewährleisten, haben wir eine leistungsstarke Umgebung genutzt, die beide effizient verarbeiten kann.

• Hardware: RunPod-Instanz mit einer NVIDIA H200 140GB GPU.
• Software: Python 3.12 mit festgeschriebenen Bibliotheken für Reproduzierbarkeit:
  • scikit-learn 1.5.2, lightgbm 4.5.0, catboost 1.2.7
  • torch 2.5.1, pandas 2.2.3, numpy 2.1.3
  • sap-rpt-oss (Quelle: Offizielles GitHub)
• Reproduzierbarkeit: random_state=42 wurde konsistent über alle Splits, Initialisierungen und Modelle hinweg verwendet.

Datensätze: Das semantische Spektrum

Wir haben die Modelle anhand von 17 überwachten Lerndatensätzen aus OpenML und Scikit-Learn evaluiert. Statt einer zufälligen Auswahl haben wir diese Suite gezielt zusammengestellt, um das „semantisch-numerische Spektrum“ abzudecken und die Hypothese zu testen, dass LLMs dort überlegen sind, wo Features sprachliche Bedeutung statt reiner Statistiken haben.

Die Bestandsaufnahme:

• Klein & semantisch (<1K Zeilen):
  • wine (178), sonar (208), vote (435), cylinder_bands (540), breast_cancer (569).
• Mittel/gemischt (1K – 10K Zeilen):
  • credit_g (1K), titanic (1.3K), car_evaluation (1.7K), spambase (4.6K), compas (5.2K), employee_salaries (9.2K).
• Groß/numerisch (10K+ Zeilen):
  • california_housing (20K), house_sales (21K), default_credit (30K), adult_income (48K), diamonds (53K), higgs (auf 100K gesampelt).

Abgedeckte Aufgaben:

• 11 binäre Klassifikationsaufgaben
• 2 Mehrklassen-Klassifikationsaufgaben
• 4 Regressionsaufgaben

Modellkonfigurationen & Vorverarbeitung

Wir strebten einen realistischen „Praktikervergleich“ an und verwendeten starke Standardeinstellungen statt einer erschöpfenden Hyperparameter-Optimierung.

LightGBM & CatBoost

Um einen fairen Vergleich mit dem rechenintensiven SAP-Modell zu gewährleisten, haben wir die robusten Standard-Schätzer erhöht.

• LightGBM: n_estimators=500, learning_rate=0.05, num_leaves=31. Läuft auf CPU (n_jobs=-1).
• CatBoost: iterations=500, learning_rate=0.05, depth=6. Läuft auf GPU (task_type=”GPU”).
• Vorverarbeitung: Einfaches Label-Encoding für kategoriale Variablen; keine Skalierung für numerische Variablen; Median-/Modus-Imputation für fehlende Werte.

SAP-RPT-1-OSS

Wir haben SAP so konfiguriert, dass Leistung und Kosten auf der Grundlage unserer vorläufigen Konfigurationsexperimente ausgewogen sind.

• Konfiguration: max_context_size=4096, bagging=4.
• Hinweis:
  • Kontext: Tests mit adult_income zeigten, dass eine Erhöhung des Kontexts von 4096 auf 8192 die Laufzeit verdreifachte (4 Min. auf 12 Min.) bei vernachlässigbarem Genauigkeitsgewinn (0.917 vs. 0.917 ROC-AUC).
  • Bagging: Eine Erhöhung des Bagging von 4 auf 8 (SAPs Standardeinstellung, die im Artikel verwendet wird⁹) brachte abnehmende Erträge.
• Vorverarbeitung: Keine. Der rohe pandas-DataFrame wird direkt übergeben. Das Modell kodiert mithilfe von Text-Embeddings (sentence-transformers/all-MiniLM-L6-v2).

Evaluierungsprotokoll

Kreuzvalidierungsstrategie

Wir verwendeten eine 3-fache Kreuzvalidierung mit Shuffling.

• Wir reduzierten die standardmäßige 5-fache auf eine 3-fache Kreuzvalidierung, um den langsamen Inference-Zeiten von SAP Rechnung zu tragen (40 % Zeitersparnis), während die statistische Validität erhalten blieb.
• Aufteilung: StratifiedKFold für die Klassifikation; Standard-K-Fold für die Regression.

Metriken & Diagnostik

Wir gingen über die einfache Genauigkeit hinaus, um eine ganzheitliche Sicht auf die Modellleistung zu erfassen:

• Primäre Ranking-Metriken: ROC-AUC (binär), Balanced Accuracy (Mehrklassen), R² (Regression).
• Sekundäre Diagnostik: Wir erfassten den Matthews-Korrelationskoeffizienten (MCC) und den Log Loss, um sicherzustellen, dass Siege nicht auf Klassenungleichgewichte zurückzuführen waren, sowie MAPE zur Kalibrierung von Regressionsfehlern.
• Kostenberechnung: Basierend auf der gesamten Laufzeit (Vorverarbeitung + Training + Inference) auf der RunPod-H200-Instanz ($3,59/Std.).

Statistische Signifikanz

Wir wendeten einen Wilcoxon-Vorzeichenrangtest (p<0.05) auf paarweise Modellvergleiche an, um festzustellen, ob Leistungsunterschiede statistisch signifikant oder zufälliges Rauschen waren.

Limitationen & interne Validität

Wir weisen ausdrücklich auf die folgenden Einschränkungen in unserer Methodik hin:

1. Standardisierte Konfigurationen vs. Tuning: Wir nutzten feste, starke Standardkonfigurationen für alle Modelle, statt eine erschöpfende Hyperparameter-Optimierung durchzuführen (z. B. verschachtelte CV oder Optuna-Sweeps). Dies gewährleistet zwar eine konsistente Baseline, aber es ist erwähnenswert, dass Baummodelle durch datensatzspezifisches Tuning oft Leistungssteigerungen erzielen, was die Abstände im „Competitive“-Cluster verringern könnte.
2. Grenzen des Datenumfangs: Unsere Analyse konzentrierte sich auf Datensätze unter 100k Zeilen, um typische mittelgroße Unternehmensszenarien zu simulieren. Wir beobachteten, dass der Vorteil des LLMs mit zunehmendem Datenvolumen abnahm, haben die Tests jedoch nicht auf Millionenzeilen-Skalen ausgeweitet, wo Inference-Latenz und -Kosten wahrscheinlich die primären Einschränkungen darstellen würden.
3. Einheitlichkeit der Infrastruktur: Um eine konsistente Testumgebung zu gewährleisten, führten wir alle Modelle auf derselben NVIDIA-H200-Hardware aus. LightGBM und CatBoost sind stark für handelsübliche CPUs optimiert; daher wäre der Kostenunterschied in einer Produktionsumgebung, die ausschließlich Baummodellen gewidmet ist, wahrscheinlich größer.
4. Generalisierung über Semantik hinaus: Unsere Hypothese des „semantischen Spektrums“ sagte viele Ergebnisse erfolgreich voraus, aber die starke Leistung des LLMs bei abstrakten Datensätzen wie sonar und california_housing deutet auf Fähigkeiten hin, die über das linguistische Verständnis hinausgehen. Dies weist darauf hin, dass das Modell möglicherweise auch hochdimensionale Regularisierungsmuster nutzt, ein Phänomen, das weitere Untersuchungen über den Rahmen dieser ersten Studie hinaus rechtfertigt.

Zitieren Sie diesen Benchmark

Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.

@misc{ermut2026,
  author = {Ermut, Sıla and Sarı, Ekrem},
  title  = {{Vergleich relationaler Foundation-Modelle}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/relational-foundation-model}},
  note   = {AIMultiple. Abgerufen am 15. September 2026}
}

Änderungsprotokoll

2 Aktualisierungen

2026

1. 4. Feb

   SAP HANA Cloud wurde dem Abschnitt Fallstudien hinzugefügt.

2. 21. Jan

   Der Abschnitt „Grundlagenmodelle für relationale und strukturierte Daten“ wurde entfernt.

Referenzlinks

1.

Griffin: Towards a Graph-Centric Relational Database Foundation Model

2.

RELATIONAL TRANSFORMER: TOWARD ZERO-SHOT FOUNDATION MODELS FOR RELATIONAL DATA

3.

RELBENCH: A Benchmark for Deep Learning on Relational Databases

4.

GitHub - stanford-star/relbench: RelBench: Relational Deep Learning Benchmark · GitHub

5.

Relational Programming with Foundation Models

6.

SAP HANA Cloud

7.

SAP Business AI: Release Highlights Q4 2025 | SAP News Center

SAP

8.

Kumo.AI trains foundation model for relational databases

blocksandfiles

9.

[2506.10707] ConTextTab: A Semantics-Aware Tabular In-Context Learner

Sıla Ermut

Branchenanalystin

Folgen auf

Sıla Ermut ist Branchenanalystin bei AIMultiple und befasst sich mit KI-Modellen, KI-Infrastruktur, KI-Governance und KI-Anwendungen für Unternehmen. Ihre Forschung konzentriert sich hauptsächlich auf den Einsatz von KI in Marketing, Gesundheitswesen, Lieferketten und Nachhaltigkeit.
Zuvor arbeitete sie als Personalvermittlerin in Projektmanagement- und Beratungsunternehmen. Sıla hat einen Master of Science in Sozialpsychologie und einen Bachelor of Arts in Internationalen Beziehungen.

Vollständiges Profil anzeigen

Recherchiert von

Ekrem Sarı

KI-Forscher

Folgen auf

Ekrem ist KI-Forscher und Datenwissenschaftler bei AIMultiple. Er entwirft und führt praxisnahe Benchmarks für KI- und LLM-Systeme durch.

Vollständiges Profil anzeigen

Seien Sie der Erste, der kommentiert

Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.

Name

E-Mail-Adresse

Kommentar

0/450

Kommentar posten