Confronto dei modelli fondazionali 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 possano offrire vantaggi rispetto ai modelli ad albero tradizionali e dove affrontino sfide in termini 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 in quella categoria.
• Da 100 a 500 righe (3 Dataset):
  • Inclusi: wine (178), sonar (208), vote (435).
  • Risultato: SAP ottiene le migliori prestazioni su 2 dei 3 dataset. Raggiunge i punteggi più alti su wine e sonar, suggerendo che i priori del LLM possano essere vantaggiosi quando i dati di addestramento sono scarsi. Tuttavia, CatBoost ha ottenuto una vittoria di misura sul dataset vote (entro lo 0.1%), indicando che i modelli ad albero rimangono altamente competitivi anche su piccola scala.
• Da 501 a 1.000 righe (3 Dataset):
  • Inclusi: cylinder_bands (540), breast_cancer (569), credit_g (1.000).
  • Risultato: SAP ottiene le migliori prestazioni 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.
• Da 1.000 a 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 compiti ricchi di testo come spambase e titanic. Tuttavia, CatBoost supera significativamente SAP su compas del 10.4%, indicando caratteristiche specifiche del dataset che favoriscono i modelli ad albero anche in questo intervallo di dimensioni.
• Oltre 10.000 righe (6 Dataset):
  • Inclusi: california_housing (20K), house_sales (21K), default_credit (30K), adult_income (48K), diamonds (53K), higgs_100k (98K).
  • Risultato: Con l'aumentare del volume di dati, il potenziale vantaggio di "conoscenza pregressa" del LLM diminuisce. LightGBM e CatBoost ottengono i migliori risultati su 5 dei 6 dataset, offrendo una migliore accuratezza a una frazione del costo computazionale. L'unica eccezione, california_housing, mostra un modesto vantaggio dell'1.7% per SAP.

1. Tabella dei dataset dei risultati del benchmark

Di seguito 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 overhead di memoria dell'architettura LLM. Al contrario, LightGBM e CatBoost completano i compiti quasi istantaneamente su questo hardware. I costi seguenti riflettono il tempo totale di esecuzione (pre-elaborazione + addestramento) per un'esecuzione di convalida incrociata a 3 fold.

Costo medio per dataset (Media su 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.
• Grandi Dataset (>20K righe): SAP diventa costoso.
  • Esempio: L'addestramento su adult_income (48k righe) richiede circa 12 minuti totali per 3 fold.
  • Costo: 12 min X $0.06/min = $0.72 per esperimento.
  • Confronto: LightGBM completa lo stesso compito 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 significativi dell'accuratezza (es., cylinder_bands con un incremento del +5.5%), ma diventa più difficile da giustificare per grandi dataset 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 a caso; abbiamo curato una suite di 17 dataset specificamente scelti per coprire lo Spettro Semantico-Numerico.

La nostra ipotesi principale era che SAP (essendo basato su LLM) avrebbe eccelso dove i dati hanno un significato linguistico, mentre i modelli ad Albero avrebbero dominato nel calcolo numerico puro. Abbiamo categorizzato i nostri dataset in tre cluster distinti:

Cluster A: Dataset ad alta semantica (6 dataset)

Caratteristiche: Le feature contengono descrizioni testuali ricche, etichette categoriche con significato nel mondo reale (es., "congelamento parcella medica"), o terminologia specifica del dominio.

• Dataset:
  • cylinder_bands: Difetti di stampa industriale.
  • titanic: Nomi e titoli dei passeggeri.
  • vote: Registri di voto congressuali (Categorico "Sì/No" sulle politiche).
  • breast_cancer: Descrizioni mediche dei tumori.
  • spambase: Frequenze delle parole nelle email.
  • 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 (ruolo lavorativo, etnia, dipartimento).

• Dataset:
  • employee_salaries: Ruoli lavorativi vs. stipendio.
  • compas: Storia criminale e dati demografici (Attributi sensibili).
  • adult_income: Dati demografici del censimento.
  • credit_g: Profili di rischio creditizio tedeschi.
  • default_credit: Dati di default creditizio di Taiwan.
  • car_evaluation: Parametri di acquisto di veicoli.

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

Caratteristiche: Le feature sono misurazioni astratte, letture di sensori o coordinate fisiche. I nomi delle colonne spesso 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: Immobiliare della Contea di King (feature per lo più numeriche).

4. Analisi approfondita: Dove SAP vince vs. fallisce

Applicando il quadro di analisi ai nostri risultati emergono quattro modelli di prestazione distinti. La tabella seguente riassume esattamente dove SAP eccelle e dove invece incontra difficoltà.

Fondamenti concettuali dei modelli fondazionali relazionali

L'obiettivo principale di un modello fondazionale relazionale è fare previsioni accurate ed eseguire compiti diversi su tabelle strutturate. Questi modelli devono capire come le informazioni sono rappresentate tra diverse tabelle, come le entità sono collegate tramite 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 degli input: Gestire diversi tipi di colonna come feature numeriche, categoriche e testuali.
• Integrazione del contesto temporale e strutturale: Catturare le dipendenze nel tempo e tra entità collegate da chiavi primarie ed esterne.
• Trasferibilità: Eseguire compiti predittivi su nuovi dataset attraverso il pre-addestramento e l'apprendimento zero-shot.

Griffin

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

Codificatore unificato di feature

• Le feature categoriche e testuali sono codificate con un codificatore di testo pre-addestrato, mentre i valori numerici utilizzano un codificatore float appreso.
• Metadati come nomi delle tabelle, nomi delle colonne e tipi di arco sono incorporati per aiutare il modello a riconoscere lo schema relazionale.
• Gli embedding dei compiti consentono a un singolo modello di eseguire compiti di regressione e classificazione con decoder condivisi.

Passaggio di messaggi e attenzione

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

Pre-addestramento e messa a punto

Il modello è pre-addestrato su dataset a tabella singola tramite un compito di completamento di celle mascherate e poi messo a punto su database relazionali per compiti specifici. Gli esperimenti su grandi benchmark relazionali mostrano che Griffin supera le baseline GNN tradizionali e i modelli a tabella singola sia in accuratezza che in efficienza di apprendimento per trasferimento.

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

Relational Transformer

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

Rappresentazione dell'input

Ogni token combina:

• Un embedding del valore che dipende dal suo tipo di dato (numerico, testo o datetime).
• Un embedding dello schema generato dal testo della tabella e della colonna.
• Un token 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 di feature per combinare attributi all'interno della stessa riga o righe padre collegate.
• Attenzione di vicinato per aggregare informazioni da righe figlie connesse.

Together, questi strati 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 impostazioni zero-shot. Ha anche appreso più velocemente durante la messa a punto, richiedendo meno passaggi di addestramento per raggiungere un'elevata accuratezza.²

Questo approccio suggerisce che i database relazionali condividono modelli 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 progredire l'apprendimento profondo relazionale, che si concentra sull'apprendimento end-to-end da dati distribuiti su più tabelle correlate in database relazionali.

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

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 che rilevanti per il dominio.³

A gennaio 2026, è stato rilasciato RelBench v2, aggiungendo quattro nuovi database (SALT, RateBeer, arXiv e MIMIC-IV) e 40 compiti predittivi aggiuntivi, inclusa una nuova classe di compiti di Completamento Automatico che valutano la capacità di un modello di prevedere colonne esistenti all'interno di un database relazionale.

Il rilascio ha anche 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 a database SQL; e ha incorporato sette dataset dal repository 4DBInfer nel formato RelBench.

Oltre ai dataset e ai compiti, RelBench fornisce un'implementazione di riferimento open-source per l'apprendimento profondo relazionale basata su reti neurali a grafo, utilizzando PyTorch Geometric per la costruzione del grafo e PyTorch Frame per la modellazione tabulare, insieme a una classifica pubblica per monitorare i progressi.

Il rilascio v2 ha anche introdotto molteplici miglioramenti di usabilità e prestazioni, incluse etichette opzionali censurate nel tempo, supporto per la metrica NDCG nella predizione dei link, generazione più rapida di sentence-embedding e gestione configurabile della cache.⁴

VIEIRA

VIEIRA adotta un approccio diverso concentrandosi sulla programmazione con modelli fondazionali piuttosto che sulla costruzione di un singolo motore predittivo. Estende il compilatore logico probabilistico SCALLOP con un linguaggio dichiarativo che integra grandi modelli linguistici, modelli visivi e altri componenti pre-addestrati come predicati esteri.⁵

Paradigma relazionale

In VIEIRA, i modelli fondazionali 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ò utilizzare GPT per estrarre conoscenza dal testo e memorizzarla come relazioni strutturate.
• CLIP può classificare immagini e collegarle a etichette testuali in una tabella.

Applicazioni

Il framework supporta:

• Ragionamento su date e matematica utilizzando GPT.
• Ragionamento di parentela utilizzando l'estrazione di testo e l'inferenza logica.
• Risposta a domande che combina recupero e ragionamento.
• Risposta a domande visive e modifica delle immagini attraverso la composizione multimodale.

Unificando la logica simbolica e l'inferenza neurale, VIEIRA consente ad analisti di dati e sviluppatori di costruire sistemi interpretabili che utilizzano modelli fondazionali 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 a scopo singolo, SAP HANA Cloud si posiziona come una piattaforma multi-modello che consente alle organizzazioni di costruire "applicazioni dati intelligenti" sopra i dati aziendali operativi.

SAP HANA Cloud combina l'elaborazione in-memory con l'archiviazione su disco e l'integrazione del data lake per supportare diversi requisiti di prestazioni e costi. Questo design flessibile supporta carichi di lavoro in tempo reale scalando 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/documento, grafo, spaziali e vettoriali all'interno di un unico database. Ciò consente alle applicazioni di combinare interrogazioni 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 fonti dati SAP e non-SAP, incluso l'accesso live senza replica, e fornisce sicurezza, disponibilità e conformità di livello enterprise per impostazione predefinita.

Nel complesso, SAP HANA Cloud è una piattaforma dati incentrata sul relazionale e nativamente IA in cui il database relazionale funge da strato fondazionale 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

sap-rpt-1 introduce un singolo modello fondazionale relazionale che esegue un'ampia gamma di compiti predittivi attraverso l'apprendimento in-contesto. 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 al contempo i metadati, come i nomi delle tabelle e delle 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 porta diversi vantaggi per gli analisti di dati e gli utenti aziendali:

• Un singolo modello che funziona su più tabelle e domini.
• Nessuna necessità di ripetute messe a punto o sviluppo personalizzato.
• Accesso a insight predittivi in minuti anziché settimane.
• Integrazione con i data warehouse esistenti e i sistemi SAP.

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

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 alto throughput,
• SAP-RPT-1-large, progettato per dare priorità all'accuratezza predittiva.

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

Inoltre, SAP offre il SAP-RPT Playground, un ambiente web no-code dove gli utenti possono testare l'apprendimento in-contesto utilizzando i propri dati o dati campione forniti da SAP.

SAP-ABAP-1

SAP-ABAP-1 è un modello fondazionale 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 migliori pratiche e fornire accesso a conoscenze aggiornate sullo sviluppo SAP.

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

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

Kumo.IA, fondata dal professore di Stanford Jure Leskovec, ha creato KumoRFM, un modello fondazionale relazionale che utilizza un trasformatore a grafo relazionale per analizzare database relazionali e data warehouse. Rappresenta i dati relazionali come un grafo temporale ed eterogeneo, dove 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 simultaneamente da più tabelle e di adattarsi a nuovi schemi relazionali. Il modello è pre-addestrato su diverse fonti di dati e può generalizzare a nuovi dataset senza costruire modelli separati per ogni compito predittivo.

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

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

L'architettura KumoRFM campiona dinamicamente il database per creare sottografi di contesto e sottografi di previsione. Questi sottografi sono elaborati dal trasformatore a grafo relazionale, che cattura le dipendenze e le informazioni temporali tra entità correlate. Attraverso l'apprendimento in-contesto, il modello fornisce previsioni accurate e può spiegare il suo 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 facile accesso e scalabilità
• Nativo del data warehouse: Consente alle organizzazioni di utilizzare i propri dati in Snowflake o Databricks senza spostarli al di fuori del loro ambiente sicuro

A differenza dei knowledge graph tradizionali che richiedono la definizione manuale dello schema, KumoRFM costruisce automaticamente il suo grafo relazionale da fonti strutturate. Questo lo rende adatto per l'eCommerce, la finanza e la sanità, dove relazioni, modelli 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 colonna e identificatori personalizzati.
• Adattamento a compiti specifici durante il tempo di inferenza.
• Alta accuratezza e interpretabilità nei compiti predittivi.

Figura 4: L'immagine mostra come i Modelli Fondazionali Relazionali (RFM) funzionano in più domini, come eCommerce, finanza e sanità, per fare 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 una 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 coerentemente 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. Piuttosto che una selezione casuale, abbiamo curato questa suite per coprire lo "Spettro Semantico-Numerico" testando l'ipotesi che gli LLM eccellano dove le feature 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 (da 1K a 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 mirato a un "confronto pratico" realistico, utilizzando impostazioni predefinite robuste piuttosto che un'estesa ottimizzazione degli iperparametri.

LightGBM & CatBoost

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

• 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: Codifica Label Encoding semplice per le categoriche; nessun ridimensionamento per le numeriche; imputazione mediana/modale per i valori mancanti.

SAP-RPT-1-OSS

Abbiamo configurato SAP per bilanciare prestazioni e costi in base ai nostri esperimenti di configurazione preliminari.

• 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 runtime (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 di SAP utilizzata nell'articolo⁹ ) offriva 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 convalida incrociata

Abbiamo utilizzato la Convalida Incrociata a 3-Fold con mescolamento.

• Abbiamo ridotto lo standard 5-fold a 3-fold per adattarci ai lenti tempi di inferenza di SAP (risparmio di tempo del 40%) 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 catturare una visione olistica delle prestazioni del modello:

• Metriche di ranking primarie: ROC-AUC (Binaria), Accuratezza Bilanciata (Multiclasse), R² (Regressione).
• Diagnostica secondaria: Abbiamo monitorato il coefficiente di correlazione di Matthews (MCC) e la perdita logaritmica 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 di 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. ottimizzazione: Abbiamo utilizzato configurazioni predefinite fisse e robuste per tutti i modelli invece di eseguire un'ottimizzazione esaustiva degli iperparametri (es., CV annidato o sweep Optuna). Sebbene ciò garantisca una baseline coerente, vale la pena notare che i modelli ad Albero spesso vedono guadagni di prestazioni con un'ottimizzazione specifica 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 diminuiva con l'aumentare del volume di dati, ma non abbiamo esteso i test a scale di milioni di righe dove la latenza di inferenza e il 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 CPU 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 dello "Spettro Semantico" ha previsto con successo molti risultati, 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 modelli di regolarizzazione ad alta dimensionalità, un fenomeno che merita ulteriori indagini oltre lo scopo di questo studio iniziale.

Cita questa ricerca

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 dei modelli fondazionali relazionali}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/relational-foundation-model}},
  note   = {AIMultiple. Consultato il 4 Agosto 2026}
}

Collegamenti di riferimento

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

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 recruiter in società di project management e consulenza. Sıla possiede un Master of Science in Psicologia Sociale e un Bachelor of Arts in Relazioni Internazionali.

Visualizza il profilo completo

Ricercato da

Ekrem Sarı

Ricercatore AI

Segui

Ekrem è Ricercatore AI e analista di dati presso AIMultiple. Progetta ed esegue benchmark pratici per sistemi di AI 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