Vergleiche relationale 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, hochsemantische Tabellen, gemischte Geschäftsdatensätze und große, niedrigsemantische numerische Datensätze.

Unser Ziel ist es zu messen, wo die vortrainierten semantischen Prioren eines relationalen LLM Vorteile gegenüber traditionellen Baummodellen bieten können und wo sie bei großem Umfang oder niedrigsemantischer Struktur auf Schwierigkeiten 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 bei Datensätzen dieser Kategorie konstant näher an der bestmöglichen Leistung liegt.
• 100 – 500 Zeilen (3 Datensätze):
  • Enthalten: wine (178), sonar (208), vote (435).
  • Ergebnis: SAP liefert die besten Ergebnisse bei 2 von 3 Datensätzen. Es erzielt die höchsten Scores bei wine und sonar, was darauf hindeutet, dass LLM-Prioren bei knappen Trainingsdaten vorteilhaft sein könnten. Allerdings sicherte sich CatBoost einen knappen Sieg beim vote-Datensatz (innerhalb von 0,1 %), was zeigt, dass Baummodelle selbst bei kleinen Datengrößen äußerst wettbewerbsfähig bleiben.
• 501 – 1.000 Zeilen (3 Datensätze):
  • Enthalten: cylinder_bands (540), breast_cancer (569), credit_g (1.000).
  • Ergebnis: SAP liefert bei allen 3 Datensätzen die besten Ergebnisse. Bei cylinder_bands übertraf SAP LightGBM mit einem Vorsprung von 5,5 %, möglicherweise aufgrund der besseren Verarbeitung semantischer Beschreibungen industrieller Defekte, obwohl weitere Ablationsstudien erforderlich wären, 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, wobei es besonders gut bei textlastigen Aufgaben wie spambase und titanic abschneidet. Allerdings übertrifft CatBoost SAP bei compas deutlich mit 10,4 %, was auf datensatzspezifische Merkmale hinweist, die in diesem Größenbereich Baummodelle 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 Vorteil des LLM durch Vorwissen. LightGBM und CatBoost erzielen die besten Ergebnisse bei 5 von 6 Datensätzen und bieten eine bessere Genauigkeit bei einem Bruchteil des Rechenaufwands. Die einzige Ausnahme, california_housing, zeigt einen bescheidenen Vorteil von 1,7 % für SAP.

1. Benchmark-Ergebnisse – Datensatztabelle

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

2. Kosten- & Effizienzanalyse

Wir berechneten die direkten Rechenkosten für jedes Modell basierend auf dem Preis der RunPod H200-Instanz von 3,59 $/Stunde.

SAP-RPT-1-OSS verursacht aufgrund der Zeit für die Text-Embedding-Vorverarbeitung und des hohen Speicheraufwands der LLM-Architektur erheblich höhere Kosten. Im Gegensatz dazu erledigen LightGBM und CatBoost Aufgaben auf dieser Hardware nahezu sofort. Die nachstehenden Kosten geben die gesamte Laufzeit (Vorverarbeitung + Training) für einen 3-fach-Kreuzvalidierungslauf wieder.

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 hier macht die Kosten vernachlässigbar.
• Große Datensätze (>20K Zeilen): SAP wird teuer.
  • Beispiel: Training auf adult_income (48k Zeilen) dauert insgesamt ≈12 Minuten für 3 Faltungen.
  • Kosten: 12 Min. × 0,06 $/Min. = 0,72 $ pro Experiment.
  • Vergleich: LightGBM erledigt dieselbe Aufgabe für 0,01 $.

Fazit: Obwohl 0,22 $ pro Datensatz in absoluten Zahlen nicht teuer sind, ist SAP 22x teurer als die Basis. Dieser Kostenunterschied mag bei kleinen, semantikreichen Datensätzen gerechtfertigt sein, wo SAP sinnvolle Genauigkeitsverbesserungen zeigt (z. B. cylinder_bands mit +5,5 % Steigerung), wird jedoch bei großen Datensätzen, bei denen Baummodelle eine gleich gute oder bessere Leistung zu einem Bruchteil der Kosten erzielen, schwerer zu rechtfertigen.

3. Analyse-Rahmen: Das semantische Spektrum

Um diese Ergebnisse zu interpretieren, ist es entscheidend zu verstehen, wie wir die Daten ausgewählt haben. Wir haben keine Datensätze zufällig ausgewählt; wir haben eine Suite von 17 Datensätzen zusammengestellt, die speziell ausgewählt wurden, um das semantisch-numerische Spektrum abzudecken.

Unsere Kernhypothese war, dass SAP (da es auf LLM-Basis arbeitet) dort brillieren würde, wo Daten linguistische Bedeutung haben, während Baummodelle bei rein numerischer Berechnung dominieren würden. Wir kategorisierten unsere Datensätze in drei unterschiedliche Cluster:

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

Merkmale: Die Features enthalten reichhaltige Textbeschreibungen, kategoriale Labels mit Bedeutung in der realen Welt (z. B. „physician fee freeze“) oder domänenspezifische Terminologie.

• Datensätze:
  • cylinder_bands: Industrielle Druckdefekte.
  • titanic: Passagiernamen und -titel.
  • vote: Kongressabstimmungsdaten (kategorisch „Ja/Nein“ zu Richtlinien).
  • breast_cancer: Medizinische Tumorbeschreibungen.
  • spambase: E-Mail-Worthäufigkeiten.
  • wine: Chemische Ursprünge.

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

Merkmale: Das übliche tabellarische Format, das in den meisten Unternehmensdatenbanken zu finden ist, eine Mischung aus numerischen Werten (Gehalt, Alter) und kategorialen Zeichenketten (Jobtitel, Rasse, Abteilung).

• Datensätze:
  • employee_salaries: Jobtitel vs. Gehalt.
  • compas: Kriminelle Vergangenheit und Demografie (sensible Attribute).
  • adult_income: Volkszählungs-Demografie.
  • credit_g: Deutsche Kreditrisikoprofile.
  • default_credit: Taiwanische Kreditausfalldaten.
  • car_evaluation: Fahrzeugkaufparameter.

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

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

• Datensätze:
  • higgs_100k: Physik-Teilchenkinematik.
  • diamonds: Physikalische Abmessungen und Preis.
  • sonar: Frequenz-Energie-Reflexionen.
  • california_housing: Breiten-/Längengrad-Koordinaten und Volkszählungsstatistiken.
  • house_sales: King County Immobilien (hauptsächlich numerische Merkmale).

4. Tiefgang: Wo SAP gewinnt und versagt

Die Anwendung des Analyse-Rahmens auf unsere Ergebnisse zeigt vier unterschiedliche Leistungsmuster. Die folgende Tabelle fasst genau zusammen, wo SAP brilliert und wo es zusammenbricht.

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 Ergebnisse beeinflussen.

Zu den Schlüsselfähigkeiten solcher Modelle gehören:

• Schemageneralisierung: Die Fähigkeit, sich ohne erneutes Training von Grund auf an neue relationale Schemata anzupassen.
• 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 verknüpft sind.
• Übertragbarkeit: Durchführung von Vorhersageaufgaben 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 stellt relationale Daten als temporalen, heterogenen Graphen dar, wobei jede Zeile zu einem Knoten wird und Kanten Fremdschlüsselbeziehungen entsprechen. Zu den Hauptmerkmalen gehören:

Einheitlicher Merkmalskodierer

• Kategoriale und textuelle Merkmale 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.
• Aufgabeneinbettungen ermöglichen es einem einzigen Modell, Regressions- und Klassifikationsaufgaben mit gemeinsamen Dekodern durchzuführen.

Nachrichtenaustausch und Aufmerksamkeit

Griffin integriert neuronale Netze für den Nachrichtenaustausch mit einem Cross-Attention-Modul. Die Nachrichtenaustausch-Komponente aggregiert Informationen innerhalb und zwischen Relationen, während Cross-Attention sich auf relevante Zellen innerhalb jeder Zeile konzentriert. Dieses Design hilft dem Modell, vielfältige Daten zu verarbeiten und den Kontext zwischen verbundenen Entitäten aufrechtzuerhalten.

Vortraining und Feinabstimmung

Das Modell wird auf Einzeltabellen-Datensätzen mittels einer Masked-Cell-Vervollständigungsaufgabe vortrainiert und dann feinabgestimmt auf relationalen Datenbanken für spezifische Aufgaben. Experimente mit großen relationalen Benchmarks zeigen, dass Griffin traditionelle GNN-Baselines und Einzeltabellenmodelle sowohl in Genauigkeit als auch in der Transferlerneffizienz übertrifft.

Abbildung 1: Diagramm des Griffin-Modell-Frameworks.¹

Relational Transformer

Während Griffin sich auf Graphaggregation konzentriert, wendet der Relational Transformer (RT) Transformer-Architekturen direkt auf relationale Datenbanken an. Er behandelt jede Zelle als Token, angereichert mit ihrem Wert, Spaltennamen und Tabellennamen.

Eingabedarstellung

Jeder Token kombiniert:

• Eine Werteinbettung, die von seinem Datentyp abhängt (numerisch, Text oder Datum/Uhrzeit).
• Eine Schemaeinbettung, die aus dem Tabellen- und Spaltentext generiert wird.
• Ein Maskentoken wird verwendet, wenn der Wert während des Vortrainings ausgeblendet ist.

Diese Struktur ermöglicht es RT, relationale Datenbanken mit unterschiedlichen Schemata zu verarbeiten, während ein konsistentes Eingabeformat beibehalten wird.

Relationale Aufmerksamkeit

RT führt einen relationalen Aufmerksamkeitsmechanismus ein, der auf Zellenebene arbeitet. Er umfasst:

• Spaltenaufmerksamkeit zum Erlernen von Werteverteilungen innerhalb von Spalten.
• Merkmalaufmerksamkeit zum Kombinieren von Attributen innerhalb derselben Zeile oder verknüpfter übergeordneter Zeilen.
• Nachbaraufmerksamkeit zum Aggregieren von Informationen aus verbundenen untergeordneten Zeilen.

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

Trainings- und Transferergebnisse

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

Dieser Ansatz legt nahe, dass relationale Datenbanken übertragbare Muster über Domänen hinweg teilen und dass die Tokenisierung auf Zellenebene eine praktische Grundlage für Vorhersageaufgaben auf strukturierten Daten bietet.

RelBench

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

Da relationale Datenbanken das dominierende Datenmanagementsystem in Industrie und Wissenschaft bleiben, bietet RelBench ein standardisiertes und reproduzierbares Framework zur Bewertung von Modellen, die direkt auf relationalen Strukturen arbeiten, anstatt sich auf manuelle Merkmalsabflachung zu verlassen.

Frühere Versionen von RelBench führten 11 relationale Datenbanken ein, die Bereiche wie Gesundheitswesen, soziale Netzwerke, E-Commerce und Sport abdecken, mit 70 Vorhersageaufgaben, die sowohl herausfordernd als auch domänenrelevant sind.³

Im Januar 2026 wurde RelBench v2 veröffentlicht und fügte vier neue Datenbanken (SALT, RateBeer, arXiv und MIMIC-IV) sowie 40 zusätzliche Vorhersageaufgaben hinzu, einschließlich einer neuen Klasse von Autovervollständigungsaufgaben, die Fähigkeit eines Modells bewerten, vorhandene Spalten innerhalb einer relationalen Datenbank vorherzusagen.

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

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

Die Version v2 führte auch mehrere Verbesserungen der Benutzerfreundlichkeit und Leistung ein, einschließlich optionaler zeitlich zensierter Labels, Unterstützung der NDCG-Metrik bei der Linkvorhersage, schnellerer Satz-Embedding-Generierung und konfigurierbarem Cache-Management.⁴

VIEIRA

VIEIRA verfolgt einen anderen Ansatz, indem es sich auf die Programmierung mit Foundation-Modellen konzentriert, anstatt eine einzige prädiktive Engine zu entwickeln. Es erweitert den probabilistischen Logik-Compiler SCALLOP um eine deklarative Sprache, die Large Language Models, Vision-Modelle und andere vortrainierte Komponenten als Fremdprädikate integriert.⁵

Relationales Paradigma

In VIEIRA werden Foundation-Modelle als zustandslose Funktionen mit relationalen Ein- und Ausgaben behandelt. Dies ermöglicht die Kombination von Modellen wie GPT, CLIP oder SAM gemäß logischer Regeln. 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:

• Daten- und Mathematikschlussfolgerungen mit GPT.
• Verwandtschaftsschlussfolgerungen durch Textextraktion und logische Inferenz.
• Fragenbeantwortung, die Retrieval und Reasoning kombiniert.
• Visuelle Fragenbeantwortung und Bildbearbeitung durch multimodale Komposition.

Durch die Vereinheitlichung von symbolischer Logik und neuronaler Inferenz ermöglicht VIEIRA Datenanalysten und Entwicklern, interpretierbare Systeme zu erstellen, 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 eine cloud-native, vollständig verwaltete Database-as-a-Service, die als einheitliche Datengrundlage für Unternehmensanwendungen konzipiert ist, die Transaktionen, Analysen und KI kombinieren. Anstatt als zweckgebundene relationale Datenbank zu dienen, positioniert sich SAP HANA Cloud als Multi-Model-Plattform, die es Organisationen ermöglicht, „intelligente Datenanwendungen“ auf der Grundlage operativer Geschäftsdaten zu entwickeln.

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

Ein wesentliches Unterscheidungsmerkmal ist die native Multi-Model-Engine, die relationale, JSON/Dokumenten-, Graph-, räumliche und Vektordaten in einer einzigen Datenbank unterstützt. Dies ermöglicht es Anwendungen, SQL-Abfragen, Graphbeziehungen und Vektorähnlichkeitssuche zu kombinieren, ohne Daten zwischen separaten Systemen zu verschieben, wodurch die Architektur vereinfacht und die Latenz reduziert wird.

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, bei der die relationale Datenbank als grundlegende Schicht für Analysen, Multi-Model-Daten und KI-Anwendungen im Unternehmen dient.

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

SAPs sap-rpt-1

sap-rpt-1 führt ein einzelnes relationales Foundation-Modell ein, das eine breite Palette von Vorhersageaufgaben durch In-Context-Lernen ausführt. Anstatt für jeden Anwendungsfall ein neues Modell zu trainieren, geben Benutzer einige Beispiele ihres Zielmusters an, z. B. „Kunden, die pünktlich gezahlt haben“ und „Kunden, die zu spät gezahlt haben“. Das Modell erkennt dann das Muster und liefert sofort genaue Vorhersagen für neue Daten.

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

Der Ansatz von SAP bietet mehrere Vorteile für Datenanalysten und Geschäftsanwender:

• Ein einziges Modell, das über mehrere Tabellen und Domänen hinweg funktioniert.
• Keine Notwendigkeit für wiederholte Feinabstimmung oder kundenspezifische Entwicklung.
• Zugang zu Vorhersageeinblicken in Minuten statt in Wochen.
• Integration mit bestehenden Data Warehouses und SAP-Systemen.

Durch die Einbettung von sap-rpt-1 in das SAP-Ökosystem können Geschäftsexperten direkt mit ihren eigenen Daten interagieren und Vorhersagen über intuitive Schnittstellen 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 schmalen KI-Baselines in SAP-Domänen.

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 niedrige Latenz und hohen Durchsatz bei Vorhersagen,
• SAP-RPT-1-large, ausgelegt auf prädiktive Genauigkeit.

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

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

SAP-ABAP-1

SAP-ABAP-1 ist ein Foundation-Modell, das entwickelt wurde, um KI-gestützte Produktivitätsanwendungsfälle für Entwickler für SAP-Kunden und -Partner zu unterstützen.

Es ist über SAPs Generative KI Hub 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 optimiert, um ABAP-Code zu verstehen und zu erklären, Best Practices aufzuzeigen und Zugang zu aktuellem SAP-Entwicklungswissen zu bieten.

SAP bietet kostenlosen Testzugang zu SAP-ABAP-1 über den Generative KI Hub, mit weiteren Funktionen, die für 2026 geplant sind.⁷

Kumo.AIs KumoRFM: Ein relationaler Graph-Transformer für prädiktive Analytik

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

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

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

• PQL (Predictive Query Language): Eine spezialisierte Abfragesprache zur Definition von Vorhersageabfragen auf strukturierten Daten.
• Natürlichsprachliche Schnittstelle: Für nicht-technische Benutzer werden natürlichsprachliche Eingaben automatisch in PQL-Abfragen übersetzt.
• Python SDK: Ermöglicht Entwicklern die Integration des Modells in KI-Pipelines und -Anwendungen im Unternehmen.

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

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

• SaaS-Plattform: Ein cloudbasierter Dienst, der auf Apache Spark aufbaut, für einfachen Zugang und Skalierung
• Data-Warehouse-nativ: Ermöglicht Organisationen, ihre eigenen Daten in Snowflake oder Databricks zu nutzen, ohne sie aus ihrer sicheren Umgebung zu verschieben

Im Gegensatz zu traditionellen Wissensgraphen, die eine manuelle Schemadefinition erfordern, konstruiert KumoRFM seinen relationalen Graphen automatisch aus strukturierten Quellen. Dies macht es gut geeignet für E-Commerce, Finanzen und Gesundheitswesen, wo Beziehungen, zeitliche Muster und sich entwickelnder Kontext für zuverlässige Vorhersagen unerlässlich sind.

Zu den Schlüsselfähigkeiten von KumoRFM gehören:

• Flexibilität über verschiedene Tabellen und Schemastrukturen hinweg.
• Kompatibilität mit einer Vielzahl von Spaltentypen und benutzerdefinierten Bezeichnern.
• Anpassung an spezifische Aufgaben während der Inferenzzeit.
• Hohe Genauigkeit und Interpretierbarkeit bei Vorhersageaufgaben.

Abbildung 4: Das Bild zeigt, wie Relational Foundation Models (RFMs) in verschiedenen Bereichen wie E-Commerce, Finanzen und Gesundheitswesen funktionieren, um Vorhersagen zu treffen, Erklärungen zu liefern und Ergebnisse zu bewerten.⁸

Benchmark-Methodik

Benchmark-Aufbau & Umgebung

Um faire Vergleiche zwischen CPU-gebundenen Bäumen und GPU-beschleunigten Modellen zu gewährleisten, verwendeten wir eine leistungsstarke Umgebung, die beides effizient bewältigen kann.

• Hardware: RunPod-Instanz mit einer NVIDIA H200 140GB GPU.
• Software: Python 3.12 mit festgelegten 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 Aufteilungen, Initialisierungen und Modelle hinweg verwendet.

Datensätze: Das semantische Spektrum

Wir bewerteten die Modelle anhand von 17 überwachten Lerndatensätzen, die von OpenML und Scikit-Learn stammen. Anstelle einer zufälligen Auswahl haben wir diese Suite zusammengestellt, um das „semantisch-numerische Spektrum“ abzudecken und die Hypothese zu testen, dass LLMs dort brillieren, wo Merkmale linguistische Bedeutung statt reiner Statistik enthalten.

Das Inventar:

• 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“ mit starken Standardeinstellungen an, anstatt erschöpfende Hyperparameter-Optimierung durchzuführen.

LightGBM & CatBoost

Um einen fairen Vergleich mit dem rechenintensiven SAP-Modell zu gewährleisten, haben wir die robusten Standard-Estimatorwerte 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; keine Skalierung für Numerische; 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) ohne nennenswerten 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 mittels Text-Embeddings (sentence-transformers/all-MiniLM-L6-v2).

Evaluierungsprotokoll

Kreuzvalidierungsstrategie

Wir verwendeten 3-fache Kreuzvalidierung mit Mischen.

• Wir reduzierten die übliche 5-fache auf 3-fache, um SAPs langsame Inferenzzeiten zu berücksichtigen (40 % Zeitersparnis), während die statistische Validität erhalten blieb.
• Aufteilung: StratifiedKFold für Klassifikation; Standard-K-Fold für 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), Balancierte Genauigkeit (Mehrklassen), R² (Regression).
• Sekundäre Diagnostik: Wir verfolgten den Matthews-Korrelationskoeffizienten (MCC) und den Log-Loss, um sicherzustellen, dass Siege nicht Artefakte von Klassenungleichgewichten waren, sowie den MAPE für die Kalibrierung des Regressionsfehlers.
• Kostenberechnung: Basierend auf der gesamten Laufzeit (Vorverarbeitung + Training + Inferenz) auf der RunPod H200-Instanz (3,59 $/Std.).

Statistische Signifikanz

Wir wendeten einen Wilcoxon-Vorzeichen-Rang-Test (p<0,05) auf paarweise Modellvergleiche an, um festzustellen, ob Leistungsunterschiede statistisch signifikant oder zufälliges Rauschen waren.

Einschränkungen & interne Validität

Wir erkennen ausdrücklich die folgenden Einschränkungen unserer Methodik an:

1. Standardisierte Konfigurationen vs. Optimierung: Wir verwendeten feste, starke Standardkonfigurationen für alle Modelle, anstatt eine erschöpfende Hyperparameter-Optimierung (z. B. verschachtelte CV oder Optuna-Sweeps) durchzuführen. Dies gewährleistet zwar eine konsistente Basislinie, es ist jedoch anzumerken, dass Baummodelle oft Leistungssteigerungen durch datensatzspezifische Optimierung erfahren, was die Abstände im „wettbewerbsfähigen“ Cluster verringern könnte.
2. Datengrößen-Grenzen: Unsere Analyse konzentrierte sich auf Datensätze mit weniger als 100k Zeilen, um typische mittelgroße Unternehmensszenarien zu simulieren. Wir beobachteten, wie der Vorteil des LLM mit zunehmendem Datenvolumen schwand, haben jedoch nicht auf Millionen-Zeilen-Skalen getestet, bei denen Inferenzlatenz und -kosten wahrscheinlich die Hauptbeschränkungen wären.
3. Einheitliche Infrastruktur: Um eine konsistente Testumgebung zu gewährleisten, führten wir alle Modelle auf derselben NVIDIA H200-Hardware aus. LightGBM und CatBoost sind hochoptimiert für handelsübliche CPUs; daher wäre in einer Produktionsumgebung, die ausschließlich Baummodellen gewidmet ist, der Kostenunterschied wahrscheinlich größer.
4. Verallgemeinerung über Semantik hinaus: Unsere Hypothese des „semantischen Spektrums“ sagte viele Ergebnisse erfolgreich voraus, aber die starke Leistung des LLM bei abstrakten Datensätzen wie sonar und california_housing deutet auf Fähigkeiten hin, die über das linguistische Verständnis hinausgehen. Dies deutet darauf hin, dass das Modell möglicherweise auch hochdimensionale Regularisierungsmuster nutzt, ein Phänomen, das weitere Untersuchungen über den Umfang dieser ersten Studie hinaus rechtfertigt.

Diese Forschung zitieren

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  = {{Vergleiche relationale Foundation-Modelle}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/relational-foundation-model}},
  note   = {AIMultiple. Abgerufen am 4. August 2026}
}

Referenzlinks

1.

https://arxiv.org/pdf/2505.05568

2.

https://arxiv.org/pdf/2510.06377

3.

https://arxiv.org/pdf/2407.20060

4.

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

5.

https://arxiv.org/pdf/2412.14515

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 eine Branchenanalystin bei AIMultiple und deckt KI-Modelle, KI-Infrastruktur, KI-Governance und Unternehmensanwendungen von KI ab. Ihre Forschung konzentriert sich überwiegend auf den Einsatz von KI in Marketing, Gesundheitswesen, Lieferketten und Nachhaltigkeit. Zuvor war sie als Recruiterin in Projektmanagement- und Beratungsunternehmen tätig. Sıla hat einen Master of Science in Sozialpsychologie und einen Bachelor of Arts in Internationale Beziehungen.

Vollständiges Profil anzeigen

Recherchiert von

Ekrem Sarı

KI-Forscher

Folgen auf

Ekrem ist KI-Forscher und Datenanalyst 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