Konzeptkarte

SAP-RPT-1 / SAP-RPT-1.5 — Relationales Foundation Model

Stand 2026-07-24T15:00:00Z

Redaktion: Cédric-Olivier Mâry, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist SAP-RPT-1 / SAP-RPT-1.5 — Relationales Foundation Model?

SAP-RPT-1/1.5 sind Foundation Models im Forschungsstadium, die direkt auf relationaler Tabellenstruktur trainiert werden, nicht auf serialisiertem Text — speziell um zu verstehen, dass eine Spalte wie KUNNR ein Fremdschlüssel in KNA1 ist, was LLMs, die Tabellen als CSV/JSON behandeln, vollständig übersehen.

SAP-RPT-1 und sein Nachfolger SAP-RPT-1.5 sind Foundation Models von SAP Research, die gezielt für unternehmensinterne Tabellen- und relationale Daten entwickelt wurden — nicht für Text. Die Prämisse kehrt die Logik um, die Large Language Models für so viele Aufgaben nützlich gemacht hat: Sprachmodelle werden auf riesigen Korpora natürlichsprachlichen Texts vortrainiert, sodass die statistischen Regelmäßigkeiten von Grammatik, Diskurs und faktischer Assoziation zu wiederverwendbaren Priors für nahezu jede nachgelagerte Sprachaufgabe werden. Ein relationales Foundation Model wendet dieselbe Idee auf ein anderes Substrat an — Sammlungen von Unternehmensdatenbanktabellen —, in der Wette, dass die strukturellen Regelmäßigkeiten relationaler Daten (Fremdschlüsselbeziehungen, Kardinalitätsmuster, zeitliche Reihenfolge von Transaktionsdatensätzen, die Art, wie eine Kopftabelle mit ihren Positionszeilen zusammenhängt) reichhaltig genug sind, um dieselbe Art von Transfer Learning zu tragen.

Welches Problem hier tatsächlich gelöst wird

Die meisten heutigen Versuche, KI auf Unternehmenstabellen anzuwenden, laufen über ein Large Language Model, dem eine serialisierte Version der Daten vorgelegt wird — ein CSV-Extrakt, eine Markdown-Tabelle oder ein JSON-Dump, der dem Modell als Teil des Prompts übergeben wird. Dieser Ansatz funktioniert bei kleinen, gut beschrifteten Tabellen einigermaßen, verwirft aber nahezu alles, was relationale Daten relational macht. Ein Sprachmodell, das einen serialisierten Extrakt aus dem Kundenstamm und dem Verkaufsauftragskopf liest, hat kein inhärentes Verständnis dafür, dass die Kundennummer in einer Tabelle ein Fremdschlüssel zum Primärschlüssel der anderen ist, oder dass ein Buchungsdatumsfeld bestimmt, welche Positionszeilen zur selben Buchungsperiode gehören. Es muss all das jedes einzelne Mal aus Oberflächenmustern im Prompt neu ableiten — mit realen Token-Kosten und ohne Garantie auf Korrektheit.

Warum es zählt

Die genannten Zielaufgaben sind konkret und unternehmensrelevant: Anomalieerkennung bei Finanzpositionszeilen, Auflösung doppelter Kundenstammsätze, Klassifikation von Datenqualitätsproblemen, Imputation fehlender Werte und Inferenz des Spaltentyps.
Die Kernbeschränkung, die es adressiert, ist gut dokumentiert: Die LLM-Serialisierung von Tabellen (CSV/Markdown/JSON) verliert Join-Beziehungen und Schlüsselsemantik, die RPT nativ lernen soll.
Ehrlicher Reifegrad-Hinweis: Stand Mitte 2025 handelt es sich ausdrücklich um Forschungsartefakte, nicht um produktionsreife Lösungen — die Kundenerwartungen entsprechend setzen.

Kernpunkte

SAP-RPT-1 / SAP-RPT-1.5 — Relationales Foundation Model ist erst dann beherrscht, wenn es eine konkret benannte Käuferentscheidung verändert.
Beginnen Sie mit dem semantischen Vertrag und dem Kontrollmodell, bevor Sie das Werkzeug vorführen.
Nutzen Sie aktuelle Signale von SAP, Analysten, Studien, dem Knowledge Graph und Nachrichten als Beleg, nicht als Dekoration.
Trennen Sie verifizierte Fakten von richtungsweisenden Trends und modellierten Annahmen.
Legen Sie Owner, Metrik, Schwellenwert, Support-Pfad und Rollback fest, bevor skaliert wird.
Messen Sie bei KI-Anwendungsfällen Zuverlässigkeit, Kosten, Latenz, Sicherheit und menschliche Validierung.
Hinterlassen Sie ein wiederverwendbares Betriebs-Asset: Memo, Checkliste, Kontrolltabelle und Ausnahmeprotokoll.
Eine erstklassige Antwort ist kurz, macht Kompromisse explizit und ist in einem Lenkungsausschuss verteidigungsfähig.

Begriffe auf dieser Seite

Decision owner: Die verantwortliche Person, die den Kompromiss akzeptiert und die nächste Maßnahme finanziert.
Semantic contract: Die gemeinsame Definition von Geschäftsbegriffen, Kennzahlen, Entitäten und Zugriffsregeln, die von Tools und Teams verwendet wird.
Control plane: Die Schicht, die Policy, Zugriff, Lineage, Monitoring und Eskalation über das Betriebsmodell hinweg durchsetzt.
Evidence grade: Eine Kennzeichnung, die verifizierten Fakt, richtungsweisendes Signal, modellierte Annahme und Feldbeobachtung voneinander trennt.
Adoption metric: Das messbare Verhalten, das belegt, dass das Konzept die tatsächliche Arbeit nach dem Go-Live verändert hat.
Agent reliability: Die Konsistenz, Kosten, Sicherheit und Policy-Konformität eines Agenten über wiederholte Läufe hinweg.
Decision owner: Die verantwortliche Person, die den Kompromiss akzeptiert und die nächste Maßnahme finanziert.
Semantic contract: Die gemeinsame Definition von Geschäftsbegriffen, Kennzahlen, Entitäten und Zugriffsregeln, die von Tools und Teams verwendet wird.

Quellen

Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.

In der App öffnen →