Özgür Işık Damar
Daten & Künstliche Intelligenz

Relationales ML2026

RealPath

Beantwortet Prognosefragen aus verknüpften Tabellen – auf Leakage getestet und erklärt.

Open Source · MIT · v0.1.0 Alpha · GNN-Backend experimentell

Quellcode auf GitHubZu den Build-Notizen
realpath · streamlit demo

Belege

Churn-ROC-AUC auf der synthetischen Beispiel-DB
0,749
examples/quickstart.ipynb
geänderte Features nach Löschen künftiger Zeilen
0
tests/test_leakage.py
Datenbanken mit identischem Churn-ROC-AUC
3
docs/BENCHMARKS.md
unterstützte Sprachen für Freitext-Fragen
EN · TR
realpath/nlp.py

Jede Zahl stammt aus einer Datei im Repository – der Pfad steht darunter.

Das Problem

Geschäftsdaten liegen in verknüpften Tabellen wie Kunden, Transaktionen und Retouren, gängige Modelle lernen aber aus einer einzigen flachen Tabelle. Sie in eine Tabelle zu überführen heißt: Joins und Aggregationen von Hand, für jede neue Frage aufs Neue. Und schon ein Aggregat, das über den Prognosezeitpunkt hinausreicht, lässt die Antwort in die Features sickern – nicht als Fehler, sondern als Score, der zu gut aussieht.

Der Ansatz

RealPath liest das Schema selbst: Schlüssel und Zeitspalten werden aus Namen, Typen und Eindeutigkeit abgeleitet, und der Compiler für PQL, die eigene Abfragesprache für Prognosen, findet den Join-Pfad von der Entität zur Zieltabelle allein. Jede Aufgabe erhält einen Stichtag: Die Deep Feature Synthesis von Featuretools aggregiert nur Zeilen bis zu diesem Zeitpunkt, die Labels stammen aus dem Zeitfenster der Abfrage (alle eingebauten Vorlagen legen es hinter den Stichtag; ein rückwärtsgewandtes Fenster weist der Compiler noch nicht ab), und ein an einem Stichtag trainiertes LightGBM-Modell wird an einem späteren am tatsächlich Eingetretenen gemessen. Ein Test löscht jede Zeile nach dem Stichtag, erzeugt die Features neu und schlägt fehl, sobald sich auch nur eines ändert; die Erklärungen übersetzen dieselben Feature-Namen zurück in Tabellen und Aggregationen. Fragen in natürlicher Sprache gehen an Claude, wenn Anthropic-SDK und API-Schlüssel vorhanden sind, und das erzeugte PQL muss sich parsen lassen, bevor es läuft; sonst decken Offline-Vorlagen Churn, Nachfrage und Retourenrisiko ab.

Was gebaut ist

  1. Tabellenübergreifende Features: Churn-ROC-AUC 0,749 statt 0,704 mit reinen Kundenspalten (Beispiel-DB)
  2. Schlüssel und Zeitspalten werden erkannt – Retourenrisiko je Kunde (zwei Joins) braucht kein SQL
  3. Mit SHAP nennt jede „Why?“-Karte Join-Pfad, Aggregation und Wert der stärksten Beiträge einer Vorhersage
  4. PQL eines Sprachmodells läuft erst, wenn es sich parsen lässt; ohne API-Schlüssel bleiben Fragen lokal

Architektur

RealPath — Die Pipeline laut Repo-Diagramm: Schema-Erkennung, PQL-Compiler und stichtagssicherer Zeitsplit speisen DFS-Features, LightGBM und Join-Pfad-Erklärungen; RelBench/GNN bleibt optional.
Die Pipeline laut Repo-Diagramm: Schema-Erkennung, PQL-Compiler und stichtagssicherer Zeitsplit speisen DFS-Features, LightGBM und Join-Pfad-Erklärungen; RelBench/GNN bleibt optional.

Die englische Frage „which customers will churn in the next 30 days?“ trifft die Offline-Churn-Vorlage (festes 30-Tage-Fenster) und erreicht auf der synthetischen Beispiel-DB ROC-AUC 0,7492.

1 / 4
// Build-NotizenZukunft löschen, Features diffen: „kein Leakage“ als Test statt als SloganRealPaths Leakage-Versprechen ist ein pytest: alles nach dem Anker löschen, neu bauen, diffen. Was der Test fand, als ich den Cutoff kaputt machte – und zwei Lecks, die er noch übersieht.Zu den Build-Notizen

Weitere Builds aus 2026