Kontaktieren Sie uns
Keine Ergebnisse gefunden.

Vergleich relationaler Fundamentmodelle

Sıla Ermut
Sıla Ermut
aktualisiert am Apr 15, 2026
Siehe unsere ethischen Normen

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 vorab trainierten semantischen Priors eines relationalen LLM Vorteile gegenüber traditionellen Baummodellen bieten können und wo sie bei Skalierung oder niedrigsemantischer Struktur an ihre Grenzen stoßen.

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

Loading Chart
  • Erfolgsquote: Stellt den durchschnittlichen normalisierten Wert (0,0 bis 1,0) dar. Ein höherer Wert bedeutet, dass das Modell für Datensätze dieser Kategorie konstant näher an der bestmöglichen Leistung liegt.
  • 100 – 500 Zeilen (3 Datensätze):
    • Enthalten: Wein (178), Sonar (208), Abstimmung (435).
    • Ergebnis: SAP erzielt auf 2 von 3 Datensätzen die besten Ergebnisse. Die höchsten Punktzahlen werden bei den Datensätzen „Wein“ und „Sonar“ erreicht, was darauf hindeutet, dass LLM-Priorverteilungen bei wenigen Trainingsdaten von Vorteil sein können. CatBoost konnte sich jedoch auf dem Datensatz „Wahl“ knapp durchsetzen (innerhalb von 0,1 %), was zeigt, dass Entscheidungsbaummodelle auch bei kleinen Datenmengen sehr wettbewerbsfähig bleiben.
  • 501 – 1.000 Zeilen (3 Datensätze):
    • Enthalten: cylinder_bands (540), breast_cancer (569), credit_g (1.000).
    • Ergebnis: SAP erzielt auf allen drei Datensätzen die besten Ergebnisse. Bei cylinder_bands übertraf SAP LightGBM um 5,5 %, möglicherweise aufgrund einer besseren Verarbeitung semantischer Beschreibungen von Industriefehlern. Um diesen Mechanismus zu bestätigen, wären jedoch weitere Ablationsstudien erforderlich.
  • 1.000 – 10.000 Zeilen (5 Datensätze):
    • Enthalten sind: titanic (1,3K), car_evaluation (1,7K), spambase (4,6K), compas (5,2K), employee_salaries (9,2K).
    • Ergebnis: SAP erzielt bei 4 von 5 Datensätzen die besten Ergebnisse und schneidet insbesondere bei textintensiven Aufgaben wie Spambase und Titanic sehr gut ab. CatBoost übertrifft SAP jedoch bei Compas um 10,4 %, was auf datensatzspezifische Eigenschaften hindeutet, die Baummodelle selbst in diesem Größenbereich begünstigen.
  • Mehr als 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 verringert sich der potenzielle Vorteil des LLM-Modells durch Vorwissen. LightGBM und CatBoost erzielen bei 5 von 6 Datensätzen die besten Ergebnisse und bieten eine höhere Genauigkeit bei einem Bruchteil des Rechenaufwands. Die einzige Ausnahme, california_housing, zeigt lediglich einen geringen Vorteil von 1,7 % für SAP.

1. Tabelle der Benchmark-Ergebnisse

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

2. Kosten- und Effizienzanalyse

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

SAP-RPT-1-OSS verursacht deutlich höhere Kosten aufgrund des Zeitaufwands für die Vorverarbeitung der Text-Embeddings und des hohen Speicherbedarfs der LLM-Architektur. Im Gegensatz dazu erledigen LightGBM und CatBoost Aufgaben auf dieser Hardware nahezu sofort. Die folgenden Kosten beziehen sich auf die gesamte Laufzeit (Vorverarbeitung + Training) für einen 3-fachen Kreuzvalidierungslauf.

Durchschnittliche Kosten pro Datensatz (17 Datensätze Durchschnitt)

Kostenaufschlüsselung nach Datensatzgröße

  • Kleine Datensätze (<1.000 Zeilen): SAP ist relativ günstig (≈ 0,03 $ pro Durchlauf). Die hohe Erfolgsquote macht die Kosten hier vernachlässigbar.
  • Große Datensätze (>20.000 Zeilen): SAP wird teuer.
    • Beispiel: Das Training mit adult_income (48k Zeilen) dauert insgesamt ≈$12 Minuten für 3 Faltungen.
    • Kosten: 12 Minuten x 0,06 $/Minute = 0,72 $ pro Experiment.
    • Vergleich: LightGBM erledigt die gleiche Aufgabe für 0,01 $ .

Fazit: Obwohl 0,22 $ pro Datensatz absolut gesehen nicht viel erscheinen, ist SAP 22-mal teurer als die Vergleichsmethode. Dieser Kostenunterschied lässt sich bei kleinen, semantisch reichhaltigen Datensätzen rechtfertigen, bei denen SAP deutliche Genauigkeitsverbesserungen erzielt (z. B. Cylinder-Bänder mit +5,5 % Lift). Bei großen Datensätzen, bei denen Baummodelle eine gleichwertige oder sogar bessere Leistung zu einem Bruchteil der Kosten erreichen, ist die Rechtfertigung jedoch schwieriger.

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 ausgewählt; wir haben eine Reihe von 17 Datensätzen zusammengestellt, die speziell so ausgewählt wurden, dass sie das semantisch-numerische Spektrum abdecken.

Unsere zentrale Hypothese war, dass SAP (da es auf LLM basiert) dort seine Stärken ausspielen würde, wo Daten eine linguistische Bedeutung haben, während Baummodelle bei rein numerischen Berechnungen dominieren würden. Wir haben unsere Datensätze in drei verschiedene Cluster unterteilt:

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

Merkmale: Die Features enthalten Rich-Text-Beschreibungen, kategorische Bezeichnungen mit realweltlicher Bedeutung (z. B. „Arzthonorarstopp“) oder domänenspezifische Terminologie.

  • Datensätze:
    • cylinder_bands: Industrielle Druckfehler.
    • Titanic: Namen und Titel der Passagiere.
    • Abstimmung: Abstimmungsprotokolle des Kongresses (kategorische „Ja/Nein“-Abstimmungen zu politischen Maßnahmen).
    • Brustkrebs: Medizinische Tumorbeschreibungen.
    • Spambase: Häufigkeit von E-Mail-Wörtern.
    • Wein: Chemische Ursprünge.

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

Merkmale: Das in den meisten Unternehmensdatenbanken übliche Tabellenformat, eine Mischung aus numerischen Werten (Gehalt, Alter) und Kategorien (Berufsbezeichnung, ethnische Zugehörigkeit, Abteilung).

  • Datensätze:
    • Mitarbeitergehälter: Berufsbezeichnungen vs. Gehalt.
    • compas: Vorstrafenregister und demografische Daten (sensible Merkmale).
    • Einkommen von Erwachsenen: Demografiedaten der Volkszählung.
    • credit_g: Deutsche Kreditrisikoprofile.
    • default_credit: Standardkreditdaten für Taiwan.
    • Fahrzeugbewertung: Parameter für den Fahrzeugkauf.

Cluster C: Daten mit geringem semantischem/rein numerischem Inhalt (5 Datensätze)

Merkmale: Bei den Merkmalen handelt es sich um abstrakte Messwerte, Sensorwerte oder physikalische Koordinaten. Die Spaltennamen sind oft irrelevant; entscheidend sind nur die mathematischen Beziehungen.

  • Datensätze:
    • higgs_100k: Physikalische Teilchenkinematik.
    • Diamanten: Physikalische Abmessungen und Preis.
    • Sonar: Frequenzenergie wird reflektiert.
    • california_housing: Breiten-/Längenkoordinaten und Volkszählungsstatistiken.
    • Hausverkäufe: Immobilien im King County (hauptsächlich numerische Merkmale).

4. Detailanalyse: Wo SAP punktet und wo es scheitert

Die Anwendung des Analysemodells auf unsere Ergebnisse zeigt vier unterschiedliche Leistungsmuster. Die folgende Tabelle fasst genau zusammen, wo SAP seine Stärken ausspielt und wo es Schwächen aufweist.

Konzeptionelle Grundlagen relationaler Fundamentmodelle

Das Hauptziel eines relationalen Basismodells ist es, präzise Vorhersagen zu treffen und vielfältige Aufgaben auf strukturierten Tabellen auszuführen. Diese Modelle müssen verstehen, wie Informationen in verschiedenen Tabellen dargestellt werden, wie Entitäten durch Beziehungen verknüpft sind und wie zeitliche Informationen die Ergebnisse beeinflussen.

Zu den wichtigsten Funktionen solcher Modelle gehören:

  • Schemageneralisierung: Die Fähigkeit, sich an neue relationale Schemata anzupassen, ohne von Grund auf neu trainiert werden zu müssen.
  • Einheitliche Eingabedarstellung: Verarbeitung verschiedener Spaltentypen wie numerische, kategoriale und textuelle Merkmale.
  • Integration des zeitlichen und strukturellen Kontextes: 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-Learning.

Greif

Griffin ist einer der ersten groß angelegten Versuche, ein einheitliches relationales Grundlagenmodell zu entwickeln. Es repräsentiert relationale Daten als temporalen, heterogenen Graphen, wobei jede Zeile einem Knoten und die Kanten Fremdschlüsselbeziehungen entsprechen. Zu den wichtigsten Merkmalen gehören:

Einheitlicher Feature-Encoder

  • Kategorische und Textmerkmale werden mit einem vorab trainierten Textcodierer codiert, während numerische Werte einen gelernten Gleitkomma-Codierer verwenden.
  • MetaDaten wie Tabellennamen, Spaltennamen und Kantentypen werden eingebettet, um dem Modell zu helfen, das relationale Schema zu erkennen.
  • Aufgabeneinbettungen ermöglichen es einem einzelnen Modell, Regressions- und Klassifizierungsaufgaben mit gemeinsam genutzten Decodern durchzuführen.

Nachrichtenübermittlung und Aufmerksamkeit

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 die relevanten Zellen innerhalb jeder Zeile fokussiert. Dieses Design hilft dem Modell, diverse Daten zu verarbeiten und den Kontext zwischen verbundenen Entitäten aufrechtzuerhalten.

Vortraining und Feinabstimmung

Das Modell wird anhand von Einzeltabellen-Datensätzen mittels einer Maskierungszellenergänzungsaufgabe vortrainiert und anschließend für spezifische Aufgaben auf relationalen Datenbanken feinabgestimmt . Experimente mit großen relationalen Benchmarks zeigen, dass Griffin herkömmliche GNN-Baselines und Einzeltabellenmodelle sowohl hinsichtlich Genauigkeit als auch Transferlerneffizienz übertrifft.

Abbildung 1: Graph zur Veranschaulichung des Griffin-Modellrahmens. 1

Relationaler Transformator

Während Griffin sich auf die 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 Werteeinbettung, die von ihrem Datentyp (numerisch, Text oder Datum/Uhrzeit) abhängt.
  • Aus dem Tabellen- und Spaltentext wird ein Schema-Embedding generiert.
  • Ein Maskentoken wird verwendet, wenn der Wert während des Vortrainings verborgen wird.

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

Beziehungsorientierte Aufmerksamkeit

RT führt einen relationalen Aufmerksamkeitsmechanismus ein, der auf Zellebene operiert. Er umfasst:

  • Spaltenaufmerksamkeit für das Erlernen von Wertverteilungen innerhalb von Spalten.
  • Besonderes Augenmerk liegt auf der Kombination von Attributen innerhalb derselben Zeile oder verknüpfter übergeordneter Zeilen.
  • Nachbaraufmerksamkeit zur Aggregation von Informationen aus verbundenen Kindzeilen.

Zusammen bilden diese Aufmerksamkeitsebenen einen relationalen Graphtransformator, der Abhängigkeiten über Zeilen, Spalten und Tabellen hinweg modelliert.

Trainings- und Transferergebnisse

RT wurde mit relationalen Datenbanken von RelBench vortrainiert. In Experimenten erreichte das vortrainierte Modell in Zero-Shot-Situationen bis zu 94 % der Leistung vollständig überwachter Modelle. Es lernte zudem beim Feintuning schneller und benötigte weniger Trainingsschritte, um eine hohe Genauigkeit zu erzielen. 2

Dieser Ansatz legt nahe, dass relationale Datenbanken domänenübergreifend übertragbare Muster aufweisen und dass die Tokenisierung auf Zellenebene eine praktische Grundlage für Vorhersageaufgaben mit strukturierten Daten bietet.

RelBench

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

Da relationale Datenbanken nach wie vor das dominierende Datenmanagementsystem in Industrie und Wissenschaft darstellen, bietet RelBench einen standardisierten und reproduzierbaren Rahmen für die Bewertung von Modellen, die direkt auf relationalen Strukturen arbeiten, anstatt auf manuelle Merkmalsglättung angewiesen zu sein.

In früheren Versionen von RelBench wurden 11 relationale Datenbanken aus Bereichen wie Gesundheitswesen, soziale Netzwerke , E-Commerce und Sport eingeführt, mit 70 Vorhersageaufgaben, die sowohl anspruchsvoll als auch domänenrelevant sein sollten. 3

Im Januar 2026 wurde RelBench v2 veröffentlicht, das vier neue Datenbanken (SALT, RateBeer, arXiv und MIMIC-IV) und 40 zusätzliche Vorhersageaufgaben hinzufügt, darunter eine neue Klasse von Autocomplete-Aufgaben, die die Fähigkeit eines Modells bewerten, vorhandene Spalten innerhalb einer relationalen Datenbank vorherzusagen.

Mit dieser Version wurde auch der Datenzugriff durch die CTU-Integration erweitert, wodurch der Zugriff auf mehr als 70 relationale Datensätze über ReDeLEx ermöglicht wird; es wurde eine direkte SQL-Datenbankanbindung hinzugefügt; und sieben Datensätze aus dem 4DBInfer-Repository wurden im RelBench-Format integriert.

Über Datensätze und Aufgaben hinaus bietet RelBench eine Open-Source-Referenzimplementierung für relationales Deep Learning auf Basis von Graph-Neuronalen Netzen, wobei PyTorch Geometric für die Graphkonstruktion und PyTorch Frame für die tabellarische Modellierung verwendet werden, sowie eine öffentliche Rangliste zur Verfolgung des Fortschritts.

Mit der Version v2 wurden außerdem zahlreiche Verbesserungen in Bezug auf Benutzerfreundlichkeit und Leistung eingeführt, darunter optionale zeitlich zensierte Labels, Unterstützung für die NDCG-Metrik bei der Linkvorhersage, schnellere Generierung von Satz-Einbettungen und konfigurierbares Cache-Management. 4

VIEIRA

VIEIRA verfolgt einen anderen Ansatz, indem es sich auf die Programmierung mit Basismodellen konzentriert, anstatt eine einzige Vorhersage-Engine zu entwickeln. Es erweitert den probabilistischen Logik-Compiler SCALLOP um eine deklarative Sprache, die große Sprachmodelle , Bildverarbeitungsmodelle und andere vortrainierte Komponenten als externe Prädikate integriert. 5

Relationales Paradigma

In VIEIRA werden Basismodelle als zustandslose Funktionen mit relationalen Ein- und Ausgaben behandelt. Dies ermöglicht die Komposition von Modellen wie GPT, CLIP oder SAM nach logischen Regeln. Zum Beispiel:

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

Anwendungen

Das Framework unterstützt:

  • Datums- und mathematisches Denken mithilfe des GPT.
  • Verwandtschaftsschlüsse mittels Textextraktion und logischer Schlussfolgerung.
  • Fragebeantwortung, die Abruf und logisches Denken kombiniert.
  • Visuelle Fragebeantwortung und Bildbearbeitung durch multimodale Komposition.

Durch die Vereinigung von symbolischer Logik und neuronaler Inferenz ermöglicht VIEIRA Datenanalysten und Entwicklern den Aufbau interpretierbarer Systeme, die vortrainierte Basismodelle nutzen, um Vorhersageanfragen über strukturierte Daten und Bilder zu beantworten.

Fallstudien

SAP HANA Cloud

SAP HANA Cloud ist eine Cloud-native, vollständig verwaltete Datenbank-als-Service-Lösung, die als einheitliche Datengrundlage für Unternehmensanwendungen dient, welche Transaktionen, Analysen und KI kombinieren. Anstatt als rein relationale Datenbank zu fungieren, positioniert sich SAP HANA Cloud als Multi-Modell-Plattform, die es Unternehmen ermöglicht, auf Basis operativer Geschäftsdaten intelligente Datenanwendungen zu entwickeln.

SAP HANA Cloud kombiniert In-Memory-Verarbeitung mit festplattenbasierter Speicherung und Data-Lake-Integration, um unterschiedliche Leistungs- und Kostenanforderungen zu erfüllen. Dieses flexible Design unterstützt Echtzeit-Workloads und skaliert dynamisch mit schwankenden Datenmengen und Nutzungsintensitäten.

Ein wesentliches Unterscheidungsmerkmal ist die integrierte Multi-Modell-Engine, die relationale, JSON-/Dokument-, Graph-, Geodaten und Vektordaten in einer einzigen Datenbank unterstützt. Dadurch können Anwendungen SQL-Abfragen, Graphbeziehungen und Vektorähnlichkeitssuchen kombinieren, ohne Daten zwischen verschiedenen Systemen verschieben zu müssen. Dies vereinfacht die Architektur und reduziert die Latenz.

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 Unternehmensebene.

Insgesamt ist SAP HANA Cloud eine relational orientierte, KI-native Datenplattform, bei der die relationale Datenbank als Grundlage für Analysen, Multi-Modell-Daten und KI-Anwendungen für Unternehmen dient.

Abbildung 2: Bild, das Hanas einheitliche Datenbank zeigt und
Multimodell-Datenverarbeitung. 6

SAPs sap-rpt-1

sap-rpt-1 stellt ein einziges relationales Basismodell vor, das durch kontextbezogenes Lernen eine Vielzahl von Vorhersageaufgaben durchführt. Anstatt für jeden Anwendungsfall ein neues Modell zu trainieren, geben Benutzer einige Beispiele ihres Zielmusters an, etwa „Kunden, die pünktlich bezahlt haben“ und „Kunden, die verspätet bezahlt haben“. Das Modell erkennt dann das Muster und liefert umgehend präzise Vorhersagen für neue Daten.

Das Modell verwendet einen zweidimensionalen Aufmerksamkeitsmechanismus, der Beziehungen zwischen Zeilen und Spalten erfasst und gleichzeitig Metadaten wie Tabellen- und Spaltennamen in Vektoreinbettungen einbettet. Dadurch versteht es die Semantik relationaler Schemata und die zeitlichen Informationen in Geschäftstabellen.

Der Ansatz von SAP bietet Datenanalysten und Geschäftsanwendern mehrere Vorteile:

  • Ein einziges Modell, das über mehrere Tabellen und Domänen hinweg funktioniert.
  • Wiederholte Feinabstimmungen oder individuelle Entwicklungen sind nicht erforderlich.
  • Zugriff auf vorausschauende Erkenntnisse in Minuten statt Wochen.
  • Integration mit bestehenden Data-Warehouse- und SAP-Systemen.

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

Abbildung 3: Fehlerreduktionsfaktor von sap-rpt-1-large im Vergleich zu narrow-AI-Baselines über verschiedene SAP-Domänen hinweg.

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

Das Modell wird in zwei Produktionsvarianten angeboten:

  • SAP-RPT-1-small, optimiert für Vorhersagen mit geringer Latenz und hohem Durchsatz,
  • SAP-RPT-1-large wurde entwickelt, um die Vorhersagegenauigkeit zu priorisieren.

Mit dieser Version wird die Rolle von SAP-RPT-1 formalisiert: Es handelt sich um ein einsetzbares Basismodell innerhalb des KI-Unternehmens-Stacks von SAP und nicht mehr nur um eine Forschungsfunktion.

Darüber hinaus bietet SAP den SAP-RPT Playground an, eine webbasierte Umgebung ohne Programmierung, in der Benutzer kontextbezogenes Lernen mit eigenen oder von SAP bereitgestellten Beispieldaten testen können.

SAP-ABAP-1

SAP-ABAP-1 ist ein Basismodell, das zur Unterstützung von Anwendungsfällen für KI-basierte Entwicklerproduktivität für SAP-Kunden und -Partner entwickelt wurde.

Es ist über SAPs KI-Hub für generative Anwendungen verfügbar und wurde mit über 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 Zugriff auf aktuelles SAP-Entwicklungswissen zu ermöglichen.

SAP bietet über den Generative AI Hub einen kostenlosen Testzugang zu SAP-ABAP-1 an; zusätzliche Funktionen sind für 2026 geplant. 7

KumoRFM von Kumo.AI: ein relationaler Graph-Transformator für prädiktive Analysen

Kumo.AI, gegründet vom Stanford-Professor Jure Leskovec, entwickelte KumoRFM, ein relationales Grundlagenmodell, das mithilfe eines relationalen Graph-Transformators relationale Datenbanken und Data Warehouses analysiert. Es repräsentiert relationale Daten als temporalen, heterogenen Graphen, in dem jede Entität einen Knoten darstellt und Primär- sowie Fremdschlüssel Kanten zwischen Tabellen bilden.

Dieser graphenbasierte Ansatz ermöglicht es KumoRFM, gleichzeitig aus mehreren Tabellen zu lernen und sich an neue relationale Schemata anzupassen. Das Modell ist mit verschiedenen Datenquellen vortrainiert und kann auf neue Datensätze generalisieren, ohne dass für jede Vorhersageaufgabe separate Modelle erstellt werden müssen.

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

  • PQL (Predictive Query Language): Eine spezielle Abfragesprache zur Definition von Vorhersageabfragen auf strukturierten Daten.
  • Schnittstelle in natürlicher Sprache: Für Anwender ohne technische Vorkenntnisse werden Eingaben in natürlicher Sprache automatisch in PQL-Abfragen übersetzt.
  • Python SDK: Ermöglicht Entwicklern die Integration des Modells in KI-Pipelines und -Anwendungen von Unternehmen.

Die KumoRFM-Architektur greift dynamisch auf die Datenbank zu, um Kontext- und Vorhersage-Subgraphen zu erstellen. Diese Subgraphen werden vom relationalen Graph-Transformator verarbeitet, der Abhängigkeiten und zeitliche Informationen zwischen verwandten Entitäten erfasst. Durch kontextbezogenes Lernen liefert das Modell präzise Vorhersagen und kann seinen Denkprozess erläutern.

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

  • SaaS-Plattform: Ein Cloud-basierter Dienst, der auf Apache Spark aufbaut und einfachen Zugriff sowie Skalierbarkeit ermöglicht.
  • Data-Warehouse-nativ: Ermöglicht es Organisationen, ihre eigenen Daten in Snowflake oder Databricks zu verwenden, ohne sie aus ihrer sicheren Umgebung zu verschieben.

Im Gegensatz zu herkömmlichen Wissensgraphen, die eine manuelle Schemadefinition erfordern, erstellt KumoRFM seinen relationalen Graphen automatisch aus strukturierten Quellen. Dadurch eignet es sich besonders für E-Commerce, Finanzen und Gesundheitswesen , wo Beziehungen, zeitliche Muster und sich verändernde Kontexte für zuverlässige Vorhersagen unerlässlich sind.

Zu den wichtigsten Funktionen von KumoRFM gehören:

  • Flexibilität hinsichtlich verschiedener Tabellen und Schemastrukturen.
  • Kompatibilität mit einer Vielzahl von Spaltentypen und benutzerdefinierten Kennungen.
  • 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. 8

Benchmark-Methodik

Benchmark-Setup und -Umgebung

Um faire Vergleiche zwischen CPU-gebundenen Bäumen und GPU-beschleunigten Modellen zu gewährleisten, nutzten wir eine Hochleistungsumgebung, die beide effizient verarbeiten konnte.

  • Hardware: RunPod- Instanz mit einer NVIDIA H200 140GB GPU .
  • Software: Python 3.12 mit festgelegten Bibliotheken zur Gewährleistung der 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 bei allen Aufteilungen, Initialisierungen und Modellen konsistent verwendet.

Datensätze: Das semantische Spektrum

Wir evaluierten die Modelle anhand von 17 Datensätzen für überwachtes Lernen aus OpenML und Scikit-Learn. Anstatt die Datensätze zufällig auszuwählen, stellten wir diese so zusammen, dass sie das gesamte semantisch-numerische Spektrum abdecken. Damit testeten wir die Hypothese, dass LLMs dort besonders gut funktionieren, wo Merkmale linguistische Bedeutung und nicht nur reine statistische Daten enthalten.

Das Inventar:

  • Klein und semantisch (<1K Zeilen):
    • Wein (178), Sonar (208), Abstimmung (435), Zylinderbänder (540), Brustkrebs (569).
  • Mittel/gemischt (1.000 – 10.000 Reihen):
    • credit_g (1K), titanic (1,3K), car_evaluation (1,7K), spambase (4,6K), compas (5,2K), employee_salaries (9,2K).
  • Groß/numerisch (10.000+ Zeilen):
    • california_housing (20K), house_sales (21K), default_credit (30K), adult_income (48K), diamonds (53K), higgs (sampled to 100K).

Abgedeckte Aufgaben:

  • 11 Aufgaben zur binären Klassifizierung
  • 2 Multiklassen-Klassifizierungsaufgaben
  • 4 Regressionsaufgaben

Modellkonfigurationen & Vorverarbeitung

Wir strebten einen realistischen „Praktikervergleich“ an, indem wir starke Standardeinstellungen anstelle einer umfassenden Hyperparameteroptimierung verwendeten.

LightGBM & CatBoost

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

  • LightGBM: n_estimators=500, learning_rate=0.05, num_leaves=31. Läuft auf der CPU (n_jobs=-1).
  • CatBoost: Iterationen=500, Lernrate=0,05, Tiefe=6. Läuft auf der GPU (task_type=”GPU”).
  • Vorverarbeitung: Einfache Label-Kodierung für kategoriale Daten; keine Skalierung für numerische Daten; Imputation fehlender Werte durch Median/Modus.

SAP-RPT-1-OSS

Basierend auf unseren vorläufigen Konfigurationsexperimenten haben wir SAP so konfiguriert, dass ein ausgewogenes Verhältnis zwischen Leistung und Kosten erreicht wird.

  • Konfiguration: max_context_size=4096, bagging=4.
  • Notiz:
    • Kontext: Tests mit adult_income zeigten, dass eine Erhöhung des Kontextes von 4096 auf 8192 die Laufzeit verdreifachte (4 min auf 12 min) bei vernachlässigbarem Genauigkeitsgewinn (0,917 vs. 0,917 ROC-AUC).
    • Bagging: Erhöhung des Bagging-Werts von 4 auf 8 (SAP-Standardeinstellung, die im Artikel verwendet wird). 9 ) boten 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 3-fache Kreuzvalidierung mit Shuffling.

  • Wir reduzierten den üblichen Faktor von 5 auf 3, um den langsamen Inferenzzeiten von SAP Rechnung zu tragen (40 % Zeitersparnis) und gleichzeitig die statistische Validität zu erhalten.
  • Aufteilung: StratifiedKFold für die Klassifizierung; Standard K-Fold für die Regression.

Kennzahlen und Diagnostik

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

  • Primäre Ranking-Metriken: ROC-AUC (Binär), Balanced Accuracy (Multiklassen), R² (Regression).
  • Sekundäre Diagnostik: Wir haben den Matthews-Korrelationskoeffizienten (MCC) und den Log-Loss verfolgt, um sicherzustellen, dass die Siege nicht auf ein Klassenungleichgewicht zurückzuführen sind, sowie den MAPE zur Kalibrierung des Regressionsfehlers.
  • Kostenberechnung: Basierend auf der gesamten Laufzeit (Vorverarbeitung + Training + Inferenz) auf der RunPod H200-Instanz (3,59 $/Std.).

Statistische Signifikanz

Wir haben einen Wilcoxon-Vorzeichenrangtest (p<0,05) auf paarweise Modellvergleiche angewendet, um festzustellen, ob Leistungsunterschiede statistisch signifikant oder zufälliges Rauschen waren.

Einschränkungen und interne Validität

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

  1. Standardisierte Konfigurationen vs. Optimierung: Wir verwendeten für alle Modelle feste, robuste Standardkonfigurationen, anstatt eine umfassende Hyperparameteroptimierung durchzuführen (z. B. verschachtelte Kreuzvalidierung oder Optuna-Sweeps). Dies gewährleistet zwar eine konsistente Ausgangsbasis, jedoch ist anzumerken, dass Baummodelle häufig Leistungssteigerungen durch datensatzspezifische Optimierung erzielen, was die Unterschiede im „Wettbewerbsfähigen“ Cluster verringern könnte.
  2. Grenzen der Datenskalierung: Unsere Analyse konzentrierte sich auf Datensätze mit weniger als 100.000 Zeilen, um typische Szenarien mittelständischer Unternehmen zu simulieren. Wir beobachteten, dass der Vorteil des LLM mit zunehmendem Datenvolumen abnahm, haben die Tests jedoch nicht auf Datensätze mit Millionen von Zeilen ausgeweitet, da hier die Latenz und die Kosten der Inferenz wahrscheinlich die Hauptbeschränkungen darstellen würden.
  3. Einheitliche Infrastruktur: Um eine konsistente Testumgebung zu gewährleisten, wurden alle Modelle auf derselben H200-Hardware (NVIDIA) ausgeführt. LightGBM und CatBoost sind hochgradig für Standard-CPUs optimiert; daher wären die Kostenunterschiede in einer Produktionsumgebung, die ausschließlich für Tree-Modelle vorgesehen ist, wahrscheinlich größer.
  4. Generalisierung über die Semantik hinaus: Unsere Hypothese des „Semantischen Spektrums“ sagte viele Ergebnisse erfolgreich voraus, doch 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 lässt vermuten, dass das Modell auch hochdimensionale Regularisierungsmuster nutzt – ein Phänomen, das über den Rahmen dieser ersten Studie hinaus weitere Untersuchungen erfordert.
Sıla Ermut
Sıla Ermut
Branchenanalyst
Sıla Ermut ist Branchenanalystin bei AIMultiple und spezialisiert auf E-Mail-Marketing und Vertriebsvideos. Zuvor war sie als Personalberaterin in Projektmanagement- und Beratungsunternehmen tätig. 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ı
Ekrem Sarı
KI-Forscher
Ekrem ist KI-Forscher bei AIMultiple und konzentriert sich auf intelligente Automatisierung, GPUs, KI-Agenten und RAG-Frameworks.
Vollständiges Profil anzeigen

Seien Sie der Erste, der kommentiert

Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich.

0/450