Confronto tra modelli di fondazione relazionali

Abbiamo confrontato SAP-RPT-1-OSS con il gradient boosting (LightGBM, CatBoost) su 17 dataset tabulari che coprono lo spettro semantico-numerico, tabelle piccole/ad alta semantica, dataset aziendali misti e grandi dataset numerici a bassa semantica.

Il nostro obiettivo è misurare dove i priori semantici pre-addestrati di un LLM relazionale possono offrire vantaggi rispetto ai modelli ad albero tradizionali e dove invece incontrano difficoltà in condizioni di scala o struttura a bassa semantica.

SAP-RPT-1-OSS vs. Gradient Boosting: Risultati del benchmark

• Tasso di successo: rappresenta il punteggio medio normalizzato (da 0.0 a 1.0). Una barra più alta indica che il modello è costantemente più vicino alla migliore prestazione possibile per i dataset di quella categoria.
• 100 – 500 righe (3 dataset):
  • Inclusi: wine (178), sonar (208), vote (435).
  • Risultato: SAP ottiene i migliori risultati su 2 dei 3 dataset. Raggiunge i punteggi più alti su wine e sonar, suggerendo che i priori di LLM possono essere utili quando i dati di addestramento sono scarsi. Tuttavia, CatBoost ha ottenuto una vittoria di misura sul dataset vote (entro 0,1%), indicando che i modelli ad albero rimangono altamente competitivi anche su piccola scala.
• 501 – 1.000 righe (3 dataset):
  • Inclusi: cylinder_bands (540), breast_cancer (569), credit_g (1.000).
  • Risultato: SAP ottiene i migliori risultati su tutti e 3 i dataset. Su cylinder_bands, SAP ha superato LightGBM con un margine del 5,5%, potenzialmente grazie a una migliore gestione delle descrizioni semantiche dei difetti industriali, sebbene sarebbero necessari ulteriori studi di ablazione per confermare questo meccanismo.
• 1.000 – 10.000 righe (5 dataset):
  • Inclusi: titanic (1.3K), car_evaluation (1.7K), spambase (4.6K), compas (5.2K), employee_salaries (9.2K).
  • Risultato: SAP ottiene i migliori risultati su 4 dei 5 dataset, con prestazioni particolarmente buone su attività ricche di testo come spambase e titanic. Tuttavia, CatBoost supera significativamente SAP su compas di 10,4%, indicando caratteristiche specifiche del dataset che favoriscono i modelli ad albero anche in questo intervallo di dimensioni.
• 10.000+ righe (6 dataset):
  • Inclusi: california_housing (20K), house_sales (21K), default_credit (30K), adult_income (48K), diamonds (53K), higgs_100k (98K).
  • Risultato: Man mano che il volume di dati cresce, il potenziale vantaggio di «conoscenza pregressa» del LLM diminuisce. LightGBM e CatBoost ottengono i migliori risultati su 5 dataset su 6, offrendo una migliore accuratezza a una frazione del costo computazionale. L'unica eccezione, california_housing, mostra un modesto vantaggio del 1,7% per SAP.

1. Tabella dei dataset dei risultati del benchmark

Di seguito è riportata la ripartizione completa delle prestazioni del modello su tutti i 17 dataset.

2. Analisi dei costi ed efficienza

Abbiamo calcolato il costo computazionale diretto per ciascun modello in base al prezzo dell'istanza RunPod H200 di $3,59/ora.

SAP-RPT-1-OSS comporta costi significativamente più elevati a causa del tempo richiesto per la pre-elaborazione degli embedding testuali e del pesante sovraccarico di memoria dell'architettura del LLM. Al contrario, LightGBM e CatBoost completano le attività quasi istantaneamente su questo hardware. I costi seguenti riflettono il tempo totale di esecuzione (pre-elaborazione + addestramento) per una validazione incrociata a 3 pieghe.

Costo medio per dataset (media di 17 dataset)

Ripartizione dei costi per dimensione del dataset

• Dataset piccoli (<1K righe): SAP è relativamente economico (≈ $0,03 per esecuzione). L'alto tasso di successo in questo caso rende il costo trascurabile.
• Dataset grandi (>20K righe): SAP diventa costoso.
  • Esempio: l'addestramento su adult_income (48k righe) richiede ≈$12 minuti totali per 3 pieghe.
  • Costo: 12 minuti X $0,06/min = $0,72 per esperimento.
  • Confronto: LightGBM completa la stessa attività per $0,01.

Conclusione: Sebbene $0,22 per dataset non sia costoso in termini assoluti, SAP è 22x più costoso del riferimento. Questo differenziale di costo può essere giustificato per dataset piccoli e ricchi di semantica dove SAP mostra miglioramenti di accuratezza significativi (ad esempio cylinder_bands con un miglioramento del +5,5%), ma diventa più difficile da giustificare per dataset grandi dove i modelli ad albero raggiungono prestazioni uguali o migliori a una frazione del costo.

3. Quadro di analisi: lo spettro semantico

Per interpretare questi risultati, è fondamentale capire come abbiamo selezionato i dati. Non abbiamo scelto i dataset in modo casuale; abbiamo curato una suite di 17 dataset appositamente selezionati per coprire lo spettro semantico-numerico.

La nostra ipotesi centrale era che SAP (essendo basato su LLM) eccellesse dove i dati hanno significato linguistico, mentre i modelli ad albero dominassero nel calcolo numerico puro. Abbiamo suddiviso i nostri dataset in tre cluster distinti:

Cluster A: dataset ad alta semantica (6 dataset)

Caratteristiche: le caratteristiche contengono ricche descrizioni testuali, etichette categoriche con significato reale (ad esempio, «congelamento delle tariffe mediche»), o terminologia specifica del dominio.

• Dataset:
  • cylinder_bands: Difetti di stampa industriale.
  • titanic: Nomi e titoli dei passeggeri.
  • vote: Registrazioni di votazione congressuale (categoriche “Sì/No” sulle politiche).
  • breast_cancer: Descrizioni mediche dei tumori.
  • spambase: Frequenze delle parole nelle e-mail.
  • wine: Origini chimiche.

Cluster B: dati aziendali misti (6 dataset)

Caratteristiche: il formato tabulare standard presente nella maggior parte dei database aziendali, un mix di valori numerici (stipendio, età) e stringhe categoriche (titolo professionale, etnia, reparto).

• Dataset:
  • employee_salaries: Titoli professionali vs. stipendio.
  • compas: Storia criminale e dati demografici (attributi sensibili).
  • adult_income: Dati demografici del censimento.
  • credit_g: Profili di rischio di credito tedeschi.
  • default_credit: Dati sulle inadempienze creditizie di Taiwan.
  • car_evaluation: Parametri di acquisto di veicoli.

Cluster C: dati a bassa semantica/puramente numerici (5 dataset)

Caratteristiche: le caratteristiche sono misurazioni astratte, letture di sensori o coordinate fisiche. Spesso i nomi delle colonne non contano; contano le relazioni matematiche.

• Dataset:
  • higgs_100k: Cinematica delle particelle fisiche.
  • diamonds: Dimensioni fisiche e prezzo.
  • sonar: Rimbalzi di energia di frequenza.
  • california_housing: Coordinate Lat/Long e statistiche del censimento.
  • house_sales: Immobili della contea di King (caratteristiche prevalentemente numeriche).

4. Analisi approfondita: dove SAP vince e dove fallisce

Applicare il quadro di analisi ai nostri risultati rivela quattro distinti schemi di prestazione. La tabella seguente riassume esattamente dove SAP eccelle e dove invece fallisce.

Fondamenti concettuali dei modelli di fondazione relazionali

L'obiettivo principale di un modello di fondazione relazionale è effettuare previsioni accurate ed eseguire compiti diversi su tabelle strutturate. Questi modelli devono comprendere come le informazioni sono rappresentate tra diverse tabelle, come le entità sono collegate attraverso relazioni e come le informazioni temporali influenzano i risultati.

Le capacità chiave di tali modelli includono:

• Generalizzazione dello schema: la capacità di adattarsi a nuovi schemi relazionali senza riaddestramento da zero.
• Rappresentazione unificata dell'input: gestione di diversi tipi di colonne come caratteristiche numeriche, categoriche e testuali.
• Integrazione del contesto temporale e strutturale: cattura delle dipendenze nel tempo e tra entità collegate da chiavi primarie ed esterne.
• Trasferibilità: esecuzione di compiti predittivi su nuovi dataset tramite pre-addestramento e apprendimento zero-shot.

Griffin

Griffin è uno dei primi tentativi su larga scala di costruire un modello di fondazione relazionale unificato. Rappresenta i dati relazionali come un grafo temporale ed eterogeneo, in cui ogni riga diventa un nodo e gli archi corrispondono a relazioni di chiave esterna. Le caratteristiche principali includono:

Encoder unificato delle caratteristiche

• Le caratteristiche categoriche e testuali vengono codificate con un encoder testuale pre-addestrato, mentre i valori numerici utilizzano un encoder float appreso.
• I metadati come i nomi delle tabelle, i nomi delle colonne e i tipi di arco vengono incorporati per aiutare il modello a riconoscere lo schema relazionale.
• Gli embedding delle attività consentono a un singolo modello di eseguire compiti di regressione e classificazione con decoder condivisi.

Passaggio di messaggi e attenzione

Griffin integra reti neurali con passaggio di messaggi e un modulo di attenzione incrociata. Il componente di passaggio dei messaggi aggrega le informazioni all'interno e tra le relazioni, mentre l'attenzione incrociata si concentra sulle celle rilevanti all'interno di ciascuna riga. Questo design aiuta il modello a gestire dati eterogenei e a mantenere il contesto tra entità connesse.

Pre-addestramento e fine-tuning

Il modello viene pre-addestrato su dataset a tabella singola tramite un compito di completamento di celle mascherate e poi fine-tuned su database relazionali per compiti specifici. Esperimenti su ampi benchmark relazionali mostrano che Griffin supera i modelli GNN tradizionali e i modelli a tabella singola sia in accuratezza sia in efficienza di transfer learning.

Figura 1: Grafico che mostra il Framework del modello Griffin.¹

Transformer relazionale

Mentre Griffin si concentra sull'aggregazione su grafo, il Relational Transformer (RT) applica architetture transformer direttamente ai database relazionali. Tratta ogni cella come un token arricchito con il suo valore, il nome della colonna e il nome della tabella.

Rappresentazione dell'input

Ogni token combina:

• Un embedding del valore che dipende dal suo tipo di dato (numerico, testuale o datetime).
• Un embedding dello schema viene generato dal testo della tabella e delle colonne.
• Un token di maschera viene utilizzato quando il valore è nascosto durante il pre-addestramento.

Questa struttura consente a RT di elaborare database relazionali con schemi diversi mantenendo un formato di input coerente.

Attenzione relazionale

RT introduce un meccanismo di attenzione relazionale che opera a livello di cella. Include:

• Attenzione di colonna per apprendere le distribuzioni dei valori all'interno delle colonne.
• Attenzione delle caratteristiche per combinare attributi nella stessa riga o nelle righe padre collegate.
• Attenzione dei vicini per aggregare informazioni dalle righe figlie connesse.

Together, questi livelli di attenzione formano un grafo transformer relazionale che modella le dipendenze tra righe, colonne e tabelle.

Risultati di addestramento e trasferimento

RT è pre-addestrato su database relazionali di RelBench. Negli esperimenti, il modello pre-addestrato ha raggiunto fino al 94% delle prestazioni dei modelli completamente supervisionati in contesti zero-shot. Ha anche appreso più rapidamente durante il fine-tuning, richiedendo meno passaggi di addestramento per raggiungere un'elevata accuratezza.²

Questo approccio suggerisce che i database relazionali condividono schemi trasferibili tra domini e che la tokenizzazione a livello di cella fornisce una base pratica per compiti predittivi su dati strutturati.

RelBench

RelBench è progettato per far avanzare il relational deep learning, che si concentra sull'apprendimento end-to-end da dati distribuiti su più tabelle correlate nei database relazionali.

Poiché i database relazionali rimangono il sistema di gestione dei dati dominante nell'industria e nella scienza, RelBench fornisce un framework standardizzato e riproducibile per valutare i modelli che operano direttamente su strutture relazionali invece di affidarsi all'appiattimento manuale delle caratteristiche.

Le versioni precedenti di RelBench hanno introdotto 11 database relazionali che coprono domini come sanità, reti sociali, e-commerce e sport, con 70 compiti predittivi progettati per essere sia sfidanti sia rilevanti per il dominio.³

Nel gennaio 2026 è stata rilasciata RelBench v2, che aggiunge quattro nuovi database (SALT, RateBeer, arXiv e MIMIC-IV) e 40 compiti predittivi aggiuntivi, tra cui una nuova classe di attività di Autocompletamento che valuta la capacità di un modello di prevedere le colonne esistenti all'interno di un database relazionale.

Il rilascio ha inoltre ampliato l'accesso ai dati tramite l'integrazione CTU, consentendo l'accesso a più di 70 dataset relazionali via ReDeLEx; ha aggiunto la connettività diretta ai database SQL; e ha incorporato sette dataset dal repository 4DBInfer in formato RelBench.

Oltre a dataset e compiti, RelBench fornisce un'implementazione di riferimento open source per il relational deep learning basato su reti neurali a grafo, utilizzando PyTorch Geometric per la costruzione dei grafi e PyTorch Frame per la modellazione tabulare, insieme a una classifica pubblica per monitorare i progressi.

Il rilascio della v2 ha inoltre introdotto molteplici miglioramenti di usabilità e prestazioni, tra cui etichette opzionali censurate nel tempo, supporto per la metrica NDCG nella previsione dei collegamenti, generazione più rapida di embedding di frasi e gestione configurabile della cache.⁴

VIEIRA

VIEIRA adotta un approccio diverso concentrandosi sulla programmazione con modelli di fondazione piuttosto che sulla costruzione di un singolo motore predittivo. Estende il compilatore di logica probabilistica SCALLOP con un linguaggio dichiarativo che integra modelli linguistici di grandi dimensioni, modelli di visione e altri componenti pre-addestrati come predicati esterni.⁵

Paradigma relazionale

In VIEIRA, i modelli di fondazione sono trattati come funzioni senza stato con input e output relazionali. Ciò consente di comporre modelli come GPT, CLIP o SAM secondo regole logiche. Ad esempio:

• Un programma può usare GPT per estrarre conoscenza dal testo e memorizzarla come relazioni strutturate.
• CLIP può classificare le immagini e collegarle a etichette testuali in una tabella.

Applicazioni

Il framework supporta:

• Ragionamento su date e matematica usando GPT.
• Ragionamento di parentela usando estrazione di testo e inferenza logica.
• Risposta a domande che combina recupero e ragionamento.
• Risposta a domande visive e modifica di immagini tramite composizione multimodale.

Unificando la logica simbolica e l'inferenza neurale, VIEIRA consente agli analisti di dati e agli sviluppatori di costruire sistemi interpretabili che utilizzano modelli di fondazione pre-addestrati per rispondere a interrogazioni predittive su dati strutturati e immagini.

Non perderti i nostri benchmark e approfondimenti basati sui dati. Il pulsante apre Google; selezionare AIMultiple conferma che desideri vedere AIMultiple più spesso nei risultati di ricerca di Google.

Aggiungi come fonte preferita

Casi di studio

SAP Hana Cloud

SAP HANA Cloud è un database-as-a-service cloud-native completamente gestito, progettato per fungere da base dati unificata per applicazioni aziendali che combinano transazioni, analisi e IA. Piuttosto che servire come database relazionale monouso, SAP HANA Cloud si posiziona come piattaforma multi-modello che consente alle organizzazioni di costruire «applicazioni dati intelligenti» sopra i dati aziendali operativi.

SAP HANA Cloud combina l'elaborazione in memoria con l'archiviazione su disco e l'integrazione con data lake per supportare diversi requisiti di prestazioni e costi. Questo design flessibile supporta carichi di lavoro in tempo reale e scala dinamicamente al variare dei volumi di dati e dell'utilizzo.

Un elemento chiave di differenziazione è il suo motore multi-modello nativo, che supporta dati relazionali, JSON/documentali, a grafo, spaziali e vettoriali all'interno di un singolo database. Ciò consente alle applicazioni di combinare query SQL, relazioni a grafo e ricerca di similarità vettoriale senza spostare i dati tra sistemi separati, semplificando così l'architettura e riducendo la latenza.

Come parte della SAP Business Technology Platform, SAP HANA Cloud si integra direttamente con origini dati SAP e non SAP, incluso l'accesso live senza replica, e fornisce sicurezza, disponibilità e conformità di livello aziendale per impostazione predefinita.

Nel complesso, SAP HANA Cloud è una piattaforma dati incentrata sul relazionale e nativa per l'IA, in cui il database relazionale funge da livello fondamentale per analisi, dati multi-modello e applicazioni IA aziendali.

Figura 2: Immagine che mostra il database unificato di HANA e
l'elaborazione dati multi-modello.⁶

sap-rpt-1 di SAP

sap-rpt-1 introduce un singolo modello di fondazione relazionale che esegue un'ampia gamma di compiti predittivi tramite apprendimento in-context. Invece di riaddestrare un nuovo modello per ogni caso d'uso, gli utenti forniscono alcuni esempi del loro schema target, come «clienti che hanno pagato puntualmente» e «clienti che hanno pagato in ritardo». Il modello riconosce quindi lo schema e produce immediatamente previsioni accurate per i nuovi dati.

Il modello è progettato con un meccanismo di attenzione bidimensionale che cattura le relazioni tra righe e colonne, incorporando inoltre metadati come i nomi di tabelle e colonne in embedding vettoriali. Questo design gli consente di comprendere la semantica degli schemi relazionali e le informazioni temporali all'interno delle tabelle aziendali.

L'approccio di SAP offre diversi vantaggi per analisti di dati e utenti aziendali:

• Un unico modello che funziona su più tabelle e domini.
• Nessuna necessità di fine-tuning ripetuto o sviluppo personalizzato.
• Accesso a insight predittivi in minuti anziché settimane.
• Integrazione con data warehouse esistenti e sistemi SAP.

Integrando sap-rpt-1 nell'ecosistema SAP, gli esperti aziendali possono interagire direttamente con i propri dati e ricevere previsioni tramite interfacce intuitive. Il risultato è un percorso più rapido dai dati strutturati alle decisioni operative senza ingegnerizzazione manuale delle caratteristiche.

Figura 3: Fattore di riduzione dell'errore di sap-rpt-1-large rispetto alle baseline narrow-IA nei domini SAP.

A fine 2025, SAP ha confermato che SAP-RPT-1 è disponibile tramite l'hub di IA generativa in SAP IA Foundation (SAP IA Core).

Il modello è offerto in due varianti di produzione:

• SAP-RPT-1-small, ottimizzato per previsioni a bassa latenza e alta produttività,
• SAP-RPT-1-large, progettato per dare priorità all'accuratezza predittiva.

Questo rilascio formalizza il ruolo di SAP-RPT-1 come modello di fondazione distribuibile all'interno dello stack IA aziendale di SAP, piuttosto che come capacità solo di ricerca.

Inoltre, SAP offre SAP-RPT Playground, un ambiente no-code basato sul web in cui gli utenti possono testare l'apprendimento in-context utilizzando i propri dati campione o quelli forniti da SAP.

SAP-ABAP-1

SAP-ABAP-1 è un modello di fondazione progettato per supportare casi d'uso di produttività degli sviluppatori basati su IA per clienti e partner SAP.

È disponibile tramite l'hub di IA generativa di SAP ed è addestrato su più di 250 milioni di righe di codice ABAP, 30 milioni di righe di codice CDS e un'ampia documentazione tecnica. Il modello è ottimizzato per comprendere e spiegare il codice ABAP, far emergere le best practice e fornire accesso a conoscenze di sviluppo SAP aggiornate.

SAP offre un accesso di prova gratuito a SAP-ABAP-1 tramite l'hub di IA generativa, con funzionalità aggiuntive previste per il rilascio nel 2026.⁷

KumoRFM di Kumo.IA: un transformer a grafo relazionale per l'analisi predittiva

Kumo.IA, fondata dal professore di Stanford Jure Leskovec, ha creato KumoRFM, un modello di fondazione relazionale che utilizza un transformer a grafo relazionale per analizzare database relazionali e data warehouse. Rappresenta i dati relazionali come un grafo temporale ed eterogeneo, in cui ogni entità è un nodo e le chiavi primarie ed esterne formano archi tra le tabelle.

Questo approccio basato su grafo consente a KumoRFM di apprendere da più tabelle contemporaneamente e di adattarsi a nuovi schemi relazionali. Il modello è pre-addestrato su diverse origini dati e può generalizzare a nuovi dataset senza costruire modelli separati per ogni compito predittivo.

KumoRFM può essere utilizzato tramite diverse interfacce a seconda dell'esperienza dell'utente:

• PQL (Predictive Query Language): un linguaggio di query specializzato per definire query predittive su dati strutturati.
• Interfaccia in linguaggio naturale: per utenti non tecnici, gli input in linguaggio naturale vengono automaticamente tradotti in query PQL.
• Python SDK: consente agli sviluppatori di integrare il modello in pipeline e applicazioni IA aziendali.

L'architettura di KumoRFM campiona dinamicamente il database per creare sottografi di contesto e sottografi di previsione. Questi sottografi vengono elaborati dal transformer a grafo relazionale, che cattura dipendenze e informazioni temporali tra entità correlate. Tramite l'apprendimento in-context, il modello fornisce previsioni accurate e può spiegare il proprio processo di ragionamento.

Kumo offre due opzioni di distribuzione adatte agli ambienti aziendali:

• Piattaforma SaaS: un servizio basato su cloud costruito su Apache Spark per un accesso semplice e scalabilità.
• Data warehouse nativo: consente alle organizzazioni di utilizzare i propri dati in Snowflake o Databricks senza spostarli al di fuori del loro ambiente sicuro.

A differenza dei tradizionali knowledge graph che richiedono la definizione manuale dello schema, KumoRFM costruisce automaticamente il suo grafo relazionale da fonti strutturate. Ciò lo rende particolarmente adatto per e-commerce, finanza e sanità, dove relazioni, schemi temporali e contesto in evoluzione sono essenziali per previsioni affidabili.

Le capacità chiave di KumoRFM includono:

• Flessibilità tra diverse tabelle e strutture di schema.
• Compatibilità con una varietà di tipi di colonne e identificatori personalizzati.
• Adattamento a compiti specifici durante l'inferenza.
• Elevata accuratezza e interpretabilità nei compiti predittivi.

Figura 4: L'immagine mostra come funzionano i Relational Foundation Models (RFM) in più domini, come e-commerce, finanza e sanità, per effettuare previsioni, fornire spiegazioni e valutare i risultati.⁸

Metodologia del benchmark

Configurazione e ambiente del benchmark

Per garantire confronti equi tra alberi vincolati alla CPU e modelli accelerati da GPU, abbiamo utilizzato un ambiente ad alte prestazioni in grado di gestire entrambi in modo efficiente.

• Hardware: istanza RunPod con un NVIDIA H200 140GB GPU.
• Software: Python 3.12 con librerie bloccate per la riproducibilità:
  • 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 (Fonte: GitHub ufficiale)
• Riproducibilità: random_state=42 è stato utilizzato in modo coerente in tutte le suddivisioni, inizializzazioni e modelli.

Dataset: lo spettro semantico

Abbiamo valutato i modelli su 17 dataset di apprendimento supervisionato provenienti da OpenML e Scikit-Learn. Invece di una selezione casuale, abbiamo curato questa suite per coprire lo «spettro semantico-numerico», verificando l'ipotesi che i LLM eccellano dove le caratteristiche contengono significato linguistico piuttosto che statistiche grezze.

L'inventario:

• Piccoli e semantici (<1K righe):
  • wine (178), sonar (208), vote (435), cylinder_bands (540), breast_cancer (569).
• Medi/misti (1K – 10K righe):
  • credit_g (1K), titanic (1.3K), car_evaluation (1.7K), spambase (4.6K), compas (5.2K), employee_salaries (9.2K).
• Grandi/numerici (10K+ righe):
  • california_housing (20K), house_sales (21K), default_credit (30K), adult_income (48K), diamonds (53K), higgs (campionato a 100K).

Compiti coperti:

• 11 compiti di classificazione binaria
• 2 compiti di classificazione multiclasse
• 4 compiti di regressione

Configurazioni dei modelli e pre-elaborazione

Abbiamo puntato a un «confronto realistico da professionisti», utilizzando impostazioni predefinite robuste piuttosto che un'estesa ottimizzazione degli iperparametri.

LightGBM e CatBoost

Per garantire un confronto equo con il modello SAP computazionalmente pesante, abbiamo aumentato i robusti stimatori predefiniti.

• LightGBM: n_estimators=500, learning_rate=0.05, num_leaves=31. Esegue su CPU (n_jobs=-1).
• CatBoost: iterations=500, learning_rate=0.05, depth=6. Esegue su GPU (task_type=”GPU”).
• Pre-elaborazione: semplice codifica label per le variabili categoriche; nessuna scalatura per i numerici; imputazione mediana/modale per i valori mancanti.

SAP-RPT-1-OSS

Abbiamo configurato SAP per bilanciare prestazioni e costi sulla base dei nostri esperimenti preliminari di configurazione.

• Configurazione: max_context_size=4096, bagging=4.
• Nota:
  • Contesto: i test su adult_income hanno mostrato che aumentare il contesto da 4096 a 8192 triplicava il tempo di esecuzione (da 4 min a 12 min) per un guadagno di accuratezza trascurabile (0.917 vs 0.917 ROC-AUC).
  • Bagging: aumentare il bagging da 4 a 8 (impostazione predefinita SAP utilizzata nell'articolo⁹) ha offerto rendimenti decrescenti.
• Pre-elaborazione: Nessuna. Il DataFrame pandas grezzo viene passato direttamente. Il modello codifica utilizzando embedding testuali (sentence-transformers/all-MiniLM-L6-v2).

Protocollo di valutazione

Strategia di validazione incrociata

Abbiamo utilizzato una validazione incrociata a 3 pieghe con mescolamento.

• Abbiamo ridotto lo standard da 5 pieghe a 3 pieghe per adattarci ai tempi di inferenza lenti di SAP (40% di risparmio di tempo) mantenendo la validità statistica.
• Suddivisione: StratifiedKFold per la classificazione; K-Fold standard per la regressione.

Metriche e diagnostica

Siamo andati oltre la semplice accuratezza per cogliere una visione olistica delle prestazioni del modello:

• Metriche di ranking primarie: ROC-AUC (Binaria), Balanced Accuracy (Multiclasse), R² (Regressione).
• Diagnostica secondaria: abbiamo monitorato il coefficiente di correlazione di Matthews (MCC) e la log loss per garantire che le vittorie non fossero artefatti dello squilibrio di classe, e il MAPE per la calibrazione dell'errore di regressione.
• Calcolo dei costi: basato sul tempo totale di esecuzione (pre-elaborazione + addestramento + inferenza) sull'istanza RunPod H200 ($3,59/ora).

Significatività statistica

Abbiamo applicato un test dei ranghi con segno di Wilcoxon (p<0.05) ai confronti a coppie tra modelli per determinare se le differenze di prestazione fossero statisticamente significative o rumore casuale.

Limitazioni e validità interna

Riconosciamo esplicitamente i seguenti vincoli nella nostra metodologia:

1. Configurazioni standardizzate vs tuning: abbiamo utilizzato configurazioni predefinite fisse e robuste per tutti i modelli piuttosto che eseguire un'ottimizzazione esaustiva degli iperparametri (ad esempio, CV annidata o sweep Optuna). Sebbene ciò garantisca una baseline coerente, vale la pena notare che i modelli ad albero spesso ottengono miglioramenti delle prestazioni con un tuning specifico per dataset, il che potrebbe ridurre i margini nel cluster «Competitivo».
2. Limiti di scala dei dati: la nostra analisi si è concentrata su dataset sotto le 100k righe per simulare scenari aziendali tipici di medie dimensioni. Abbiamo osservato che il vantaggio del LLM diminuisce all'aumentare del volume di dati, ma non abbiamo esteso i test a scale di milioni di righe dove latenza di inferenza e costo diventerebbero probabilmente i vincoli principali.
3. Uniformità dell'infrastruttura: per mantenere un ambiente di test coerente, abbiamo eseguito tutti i modelli sullo stesso hardware NVIDIA H200. LightGBM e CatBoost sono altamente ottimizzati per le CPUs commodity; pertanto, in un ambiente di produzione dedicato esclusivamente ai modelli ad albero, il differenziale di costo sarebbe probabilmente più ampio.
4. Generalizzazione oltre la semantica: la nostra ipotesi «Spettro Semantico» ha previsto con successo molti esiti, ma la forte prestazione del LLM su dataset astratti come sonar e california_housing suggerisce capacità che vanno oltre la comprensione linguistica. Ciò indica che il modello potrebbe anche sfruttare schemi di regolarizzazione ad alta dimensionalità, un fenomeno che merita ulteriori indagini al di fuori dell'ambito di questo studio iniziale.

Cita questo benchmark

Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.

@misc{ermut2026,
  author = {Ermut, Sıla and Sarı, Ekrem},
  title  = {{Confronto tra modelli di fondazione relazionali}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/relational-foundation-model}},
  note   = {AIMultiple. Consultato il 15 settembre 2026}
}

Registro delle modifiche

2 aggiornamenti

2026

1. 4 feb

   Aggiunto SAP HANA Cloud alla sezione Case study.

2. 21 gen

   Rimossa la sezione "Modelli fondamentali per dati relazionali e strutturati".

Collegamenti di riferimento

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

Analista di settore

Segui

Sıla Ermut è un'analista di settore presso AIMultiple e si occupa di modelli di IA, infrastrutture di IA, governance dell'IA e applicazioni aziendali dell'IA. La sua ricerca si concentra principalmente sull'uso dell'IA nel marketing, nella sanità, nelle catene di approvvigionamento e nella sostenibilità.
In precedenza ha lavorato come reclutatrice in società di project management e consulenza. Sıla ha conseguito un Master of Science in Psicologia Sociale e un Bachelor of Arts in Relazioni Internazionali.

Visualizza il profilo completo

Ricercato da

Ekrem Sarı

Ricercatore IA

Segui

Ekrem è un Ricercatore IA e Data Scientist presso AIMultiple. Progetta ed esegue benchmark pratici per sistemi di IA e LLM.

Visualizza il profilo completo

Sii il primo a commentare

Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.

Nome

Indirizzo e-mail

Commento

0/450

Pubblica un commento