Confronto tra modelli di fondamenti relazionali
Abbiamo confrontato le prestazioni di SAP-RPT-1-OSS con quelle di algoritmi di gradient boosting (LightGBM, CatBoost) su 17 dataset tabellari che coprono l'intero spettro semantico-numerico, tabelle piccole/ad alta semantica, dataset aziendali misti e dataset numerici di grandi dimensioni a bassa semantica.
Il nostro obiettivo è misurare in quali casi le conoscenze semantiche pre-addestrate di un modello lineare relazionale (LLM) possono offrire vantaggi rispetto ai modelli ad albero tradizionali e in quali casi, al contrario, presentano delle criticità in presenza di grandi quantità di dati o di una struttura semantica limitata.
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 alle migliori prestazioni possibili per i set di dati in quella categoria.
- 100 – 500 righe (3 set di dati):
- Incluso: vino (178), sonar (208), voto (435).
- Risultato: SAP ottiene le migliori prestazioni su 2 dei 3 dataset. Raggiunge i punteggi più alti su wine e sonar, suggerendo che i prior LLM possono essere vantaggiosi quando i dati di addestramento sono scarsi. Tuttavia, CatBoost si è assicurato una vittoria di misura sul dataset vote (entro lo 0,1%), indicando che i modelli ad albero rimangono altamente competitivi anche su piccola scala.
- 501 – 1.000 righe (3 set di dati):
- Incluso: fasce cilindriche (540), cancro al seno (569), crediti g (1.000).
- Risultato: SAP ottiene le migliori prestazioni su tutti e 3 i set di dati. 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 set di dati):
- Incluso: 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 elevate su attività ad alto contenuto testuale 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 set di dati):
- Incluso: california_housing (20K), house_sales (21K), default_credit (30K), adult_income (48K), diamonds (53K), higgs_100k (98K).
- Risultato: all'aumentare del volume dei dati, il potenziale vantaggio derivante dalla "conoscenza pregressa" del modello LLM diminuisce. LightGBM e CatBoost ottengono i risultati migliori su 5 set di dati su 6, offrendo una maggiore precisione a una frazione del costo computazionale. L'unica eccezione, california_housing, mostra solo un modesto vantaggio dell'1,7% per SAP.
1. Tabella dei set di dati dei risultati del benchmark
Di seguito è riportata l'analisi completa delle prestazioni del modello su tutti i 17 set di dati.
2. Analisi dei costi e dell'efficienza
Abbiamo calcolato il costo computazionale diretto per ciascun modello basandoci sul prezzo dell'istanza RunPod H200 , pari a 3,59 dollari all'ora .
SAP-RPT-1-OSS comporta costi significativamente più elevati a causa del tempo necessario per la preelaborazione dell'incorporamento del testo e dell'elevato overhead di memoria dell'architettura LLM. Al contrario, LightGBM e CatBoost completano le attività quasi istantaneamente su questo hardware. I costi riportati di seguito riflettono il tempo totale di esecuzione (preelaborazione + addestramento) per un'esecuzione di convalida incrociata a 3 fold.
Costo medio per set di dati (media per 17 set di dati)
Ripartizione dei costi in base alla dimensione del set di dati
- Set di dati di piccole dimensioni (<1000 righe): SAP è relativamente economico (circa 0,03 dollari per esecuzione). L'elevato tasso di successo in questo caso rende il costo trascurabile.
- Set di dati di grandi dimensioni (>20.000 righe): SAP diventa costoso.
- Esempio: l'addestramento sul dataset adult_income (48.000 righe) richiede circa 12 minuti in totale per 3 fold.
- Costo: 12 minuti x 0,06 $/minuto = 0,72 $ per esperimento.
- Confronto: LightGBM completa la stessa attività per $0,01 .
Conclusione: Sebbene 0,22 dollari per dataset non siano un costo elevato in termini assoluti, SAP è 22 volte più costoso del metodo di riferimento. Questa differenza di costo può essere giustificata per dataset di piccole dimensioni e ricchi di informazioni semantiche, dove SAP mostra miglioramenti significativi in termini di accuratezza (ad esempio, cylinder_bands con un incremento del +5,5%), ma diventa più difficile da giustificare per dataset di grandi dimensioni, 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 comprendere come abbiamo selezionato i dati. Non abbiamo scelto i dataset a caso; abbiamo creato una serie di 17 dataset selezionati specificamente per coprire l' intero spettro semantico-numerico .
La nostra ipotesi principale era che SAP (essendo basato su LLM) avrebbe eccelso laddove i dati hanno un significato linguistico, mentre i modelli ad albero avrebbero dominato nei calcoli numerici grezzi. Abbiamo categorizzato i nostri set di dati in tre cluster distinti:
Cluster A: Dataset ad alta semantica (6 dataset)
Caratteristiche: Le funzionalità contengono descrizioni testuali dettagliate, etichette categoriali con significato concreto (ad esempio, "blocco delle tariffe mediche") o terminologia specifica del settore.
- Insiemi di dati:
- Fasce cilindriche: Difetti di stampa industriale.
- Titanic: nomi e titoli dei passeggeri.
- Votazione: Registri di voto del Congresso (risposte categoriche "Sì/No" sulle politiche).
- cancro_al_seno: Descrizioni mediche dei tumori.
- spambase: Frequenza delle parole nelle email.
- vino: origini chimiche.
Gruppo B: Dati aziendali misti (6 set di dati)
Caratteristiche: Il formato tabellare standard presente nella maggior parte dei database aziendali, un mix di valori numerici (stipendio, età) e stringhe categoriali (qualifica professionale, etnia, reparto).
- Insiemi di dati:
- stipendi dei dipendenti: Qualifiche professionali vs. stipendio.
- Compas: Precedenti penali e dati demografici (Attributi sensibili).
- reddito_adulto: Dati demografici del censimento.
- credit_g: Profili di rischio di credito tedeschi.
- default_credit: Dati di default del credito di Taiwan.
- valutazione_auto: parametri per l'acquisto di un veicolo.
Cluster C: Dati numerici/a bassa semantica (5 set di dati)
Caratteristiche: Le caratteristiche sono misurazioni astratte, letture di sensori o coordinate fisiche. I nomi delle colonne spesso non sono importanti; contano solo le relazioni matematiche.
- Insiemi di dati:
- higgs_100k: Cinematica delle particelle in fisica.
- Diamanti: dimensioni fisiche e prezzo.
- sonar: Rimbalzi di energia in frequenza.
- California Housing: coordinate di latitudine/longitudine e statistiche del censimento.
- vendite_di_case: Immobili nella contea di King (principalmente dati numerici).
4. Analisi approfondita: i punti di forza e di debolezza di SAP
Applicando il framework di analisi ai nostri risultati, emergono quattro modelli di performance distinti. La tabella seguente riassume esattamente dove SAP eccelle e dove incontra delle difficoltà.
Fondamenti concettuali dei modelli di fondazione relazionale
L'obiettivo principale di un modello relazionale è quello di effettuare previsioni accurate ed eseguire diverse attività su tabelle strutturate. Questi modelli devono comprendere come le informazioni sono rappresentate nelle diverse tabelle, come le entità sono collegate tramite relazioni e come le informazioni temporali influenzano i risultati.
Le principali funzionalità di tali modelli includono:
- Generalizzazione dello schema: la capacità di adattarsi a nuovi schemi relazionali senza dover riqualificare il sistema da zero.
- Rappresentazione unificata dei dati di input: gestione di diversi tipi di colonne, come quelle numeriche, categoriche e testuali.
- Integrazione del contesto temporale e strutturale: individuazione delle dipendenze nel tempo e tra entità collegate da chiavi primarie e chiavi esterne.
- Trasferibilità: Esecuzione di attività predittive su nuovi set di dati tramite pre-addestramento e apprendimento zero-shot.
Grifone
Griffin è uno dei primi tentativi su larga scala di costruire un modello relazionale unificato. Rappresenta i dati relazionali come un grafo temporale ed eterogeneo, in cui ogni riga diventa un nodo e gli archi corrispondono alle relazioni di chiave esterna. Le caratteristiche principali includono:
Codificatore di funzionalità unificato
- Le caratteristiche categoriali e testuali vengono codificate con un codificatore di testo pre-addestrato, mentre i valori numerici utilizzano un codificatore di virgola mobile appreso.
- I dati Meta, come i nomi delle tabelle, i nomi delle colonne e i tipi di archi, sono incorporati per aiutare il modello a riconoscere lo schema relazionale.
- Gli embedding di attività consentono a un singolo modello di eseguire attività di regressione e classificazione con decodificatori condivisi.
Passaggio di messaggi e attenzione
Griffin integra reti neurali a passaggio di messaggi con un modulo di attenzione incrociata. Il componente di passaggio di messaggi aggrega le informazioni all'interno e tra le relazioni, mentre l'attenzione incrociata si concentra sulle celle rilevanti all'interno di ciascuna riga. Questa architettura aiuta il modello a gestire dati eterogenei e a mantenere il contesto tra le entità connesse.
Pre-allenamento e messa a punto
Il modello viene pre-addestrato su dataset a tabella singola tramite un'attività di completamento di celle mascherate e successivamente ottimizzato su database relazionali per attività specifiche. Gli esperimenti su grandi benchmark relazionali dimostrano che Griffin supera i modelli GNN tradizionali e i modelli a tabella singola sia in termini di accuratezza che di efficienza del trasferimento di apprendimento.
Figura 1: Grafico che illustra il modello Griffin. 1
Trasformatore relazionale
Mentre Griffin si concentra sull'aggregazione di grafi, il Relational Transformer (RT) applica le architetture dei trasformatori 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'incorporazione di valori che dipende dal suo tipo di dato (numerico, testuale o data/ora).
- Viene generato uno schema di incorporamento a partire dal testo della tabella e delle colonne.
- Un token di maschera viene utilizzato quando il valore è nascosto durante la fase di pre-addestramento.
Questa struttura consente a RT di elaborare database relazionali con schemi diversi, mantenendo al contempo un formato di input coerente.
Attenzione relazionale
RT introduce un meccanismo di attenzione relazionale che opera a livello cellulare. Esso comprende:
- Attenzione alle colonne per apprendere le distribuzioni dei valori all'interno delle colonne.
- Attenzione alle funzionalità per la combinazione di attributi all'interno della stessa riga o di righe padre collegate.
- Attenzione dei vicini per aggregare le informazioni dalle righe figlie connesse.
Insieme, questi livelli di attenzione formano un trasformatore di grafi relazionali che modella le dipendenze tra righe, colonne e tabelle.
Risultati di formazione 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 inoltre appreso più velocemente durante la fase di fine-tuning, richiedendo un minor numero di passaggi di addestramento per raggiungere un'elevata precisione. 2
Questo approccio suggerisce che i database relazionali condividono modelli trasferibili tra diversi domini e che la tokenizzazione a livello di cella fornisce una base pratica per le attività predittive su dati strutturati.
RelBench
RelBench è progettato per far progredire il deep learning 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 dei dati dominante nell'industria e nella scienza, RelBench fornisce un framework standardizzato e riproducibile per la valutazione di modelli che operano direttamente su strutture relazionali anziché basarsi sull'appiattimento manuale delle caratteristiche.
Le prime versioni di RelBench hanno introdotto 11 database relazionali che abbracciano settori come la sanità, i social network , l'e-commerce e lo sport, con 70 attività predittive progettate per essere al contempo impegnative e pertinenti al settore. 3
Nel gennaio 2026 è stata rilasciata la versione 2 di RelBench, che ha aggiunto quattro nuovi database (SALT, RateBeer, arXiv e MIMIC-IV) e 40 attività predittive aggiuntive, tra cui una nuova classe di attività di completamento automatico che valutano la capacità di un modello di prevedere le colonne esistenti all'interno di un database relazionale.
La release ha inoltre ampliato l'accesso ai dati tramite l'integrazione con CTU, consentendo l'accesso a oltre 70 dataset relazionali tramite ReDeLEx; ha aggiunto la connettività diretta ai database SQL; e ha incorporato sette dataset dal repository 4DBInfer in formato RelBench.
Oltre ai dataset e ai task, RelBench fornisce un'implementazione di riferimento open-source per il deep learning relazionale basato su reti neurali a grafo, utilizzando PyTorch Geometric per la costruzione del grafo e PyTorch Frame per la modellazione tabellare , insieme a una classifica pubblica per monitorare i progressi.
La versione 2 ha inoltre introdotto numerosi miglioramenti in termini di usabilità e prestazioni, tra cui etichette con censura temporale opzionali, supporto per la metrica NDCG nella predizione dei collegamenti, generazione più rapida degli embedding delle frasi e gestione della cache configurabile. 4
VIEIRA
VIEIRA adotta un approccio diverso, concentrandosi sulla programmazione con modelli di base piuttosto che sulla creazione 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 . 5
Paradigma relazionale
In VIEIRA, i modelli di base 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 informazioni da un testo e memorizzarle come relazioni strutturate.
- CLIP è in grado di classificare le immagini e di collegarle a etichette testuali in una tabella.
Applicazioni
Il framework supporta:
- Ragionamento matematico e relativo alle date utilizzando GPT.
- Ragionamento di parentela tramite estrazione di testo e inferenza logica.
- Risposta a domande che combina recupero di informazioni e ragionamento.
- Risposta visiva a domande e modifica di immagini tramite composizione multimodale.
Unificando la logica simbolica e l'inferenza neurale, VIEIRA consente ad analisti di dati e sviluppatori di creare sistemi interpretabili che utilizzano modelli di base pre-addestrati per rispondere a query predittive su dati e immagini strutturati.
Casi di studio
SAP Hana Cloud
SAP HANA Cloud è un database-as-a-service nativo del cloud e completamente gestito, progettato per fungere da base dati unificata per applicazioni aziendali che combinano transazioni, analisi e intelligenza artificiale. Anziché essere un database relazionale monouso, SAP HANA Cloud si posiziona come una piattaforma multi-modello che consente alle organizzazioni di creare "applicazioni dati intelligenti" a partire dai dati aziendali operativi.
SAP HANA Cloud combina l'elaborazione in memoria con l'archiviazione su disco e l'integrazione con il data lake per soddisfare diverse esigenze in termini di prestazioni e costi. Questa architettura flessibile supporta carichi di lavoro in tempo reale, scalando dinamicamente in base alle fluttuazioni dei volumi di dati e dell'utilizzo.
Un elemento distintivo fondamentale è il suo motore multi-modello nativo, che supporta dati relazionali, JSON/documenti, grafici, spaziali e vettoriali all'interno di un unico database. Ciò consente alle applicazioni di combinare query SQL, relazioni tra grafi e ricerche di similarità vettoriali senza dover spostare i dati tra sistemi separati, semplificando così l'architettura e riducendo la latenza.
Nell'ambito della SAP Business Technology Platform, SAP HANA Cloud si integra direttamente con fonti di dati SAP e non SAP, consentendo l'accesso in tempo reale senza replica, e offre di default sicurezza, disponibilità e conformità di livello enterprise.
Nel complesso, SAP HANA Cloud è una piattaforma dati incentrata sulle relazioni e nativa per l'intelligenza artificiale, in cui il database relazionale funge da livello fondamentale per l'analisi, i dati multi-modello e le applicazioni di intelligenza artificiale aziendali.
Figura 2: Immagine che mostra il database unificato di Hana e
elaborazione dati multimodello. 6
SAP sap-rpt-1
sap-rpt-1 introduce un singolo modello relazionale di base che esegue un'ampia gamma di attività predittive attraverso l'apprendimento contestuale. Invece di riaddestrare un nuovo modello per ogni caso d'uso, gli utenti forniscono alcuni esempi del modello desiderato, come "clienti che hanno pagato puntualmente" e "clienti che hanno pagato in ritardo". Il modello riconosce quindi il modello 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 metadati, come i nomi di tabelle e colonne, in vettori di embedding. Questa progettazione gli consente di comprendere la semantica degli schemi relazionali e le informazioni temporali all'interno delle tabelle aziendali.
L'approccio di SAP offre numerosi vantaggi sia per gli analisti di dati che per gli utenti aziendali:
- Un unico modello che funziona su più tabelle e domini.
- Non è necessario effettuare ripetute regolazioni o sviluppare soluzioni personalizzate.
- Accesso a informazioni predittive in pochi minuti anziché in settimane.
- Integrazione con i data warehouse e i sistemi SAP esistenti.
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 la necessità di ricorrere all'ingegneria manuale delle funzionalità.
Figura 3: Fattore di riduzione dell'errore delle baseline sap-rpt-1-large rispetto a narrow-AI nei diversi domini SAP.
Alla fine del 2025, SAP ha confermato che SAP-RPT-1 è generalmente disponibile tramite l'hub di intelligenza artificiale generativa in SAP AI Foundation (SAP AI Core).
Il modello è offerto in due varianti di produzione:
- SAP-RPT-1-small, ottimizzato per previsioni a bassa latenza e ad alta velocità di elaborazione,
- SAP-RPT-1-large, progettato per dare priorità all'accuratezza predittiva.
Questa release formalizza il ruolo di SAP-RPT-1 come modello di base implementabile all'interno della suite di intelligenza artificiale aziendale di SAP, anziché come funzionalità destinata esclusivamente alla ricerca.
Inoltre, SAP offre SAP-RPT Playground, un ambiente web senza codice in cui gli utenti possono testare l'apprendimento contestuale utilizzando i propri dati di esempio o quelli forniti da SAP.
SAP-ABAP-1
SAP-ABAP-1 è un modello di base progettato per supportare casi d'uso di produttività degli sviluppatori basati sull'intelligenza artificiale per clienti e partner SAP.
È disponibile tramite l'hub di intelligenza artificiale generativa di SAP ed è stato addestrato su oltre 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, individuare le migliori pratiche e fornire accesso a conoscenze di sviluppo SAP aggiornate.
SAP offre un accesso di prova gratuito a SAP-ABAP-1 tramite l'hub di intelligenza artificiale generativa, con funzionalità aggiuntive previste per il rilascio nel 2026. 7
KumoRFM di Kumo.AI: un trasformatore di grafi relazionali per l'analisi predittiva.
Kumo.AI, fondata dal professore di Stanford Jure Leskovec, ha creato KumoRFM, un modello relazionale di base che utilizza un trasformatore di grafi relazionali 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 e esterne formano gli archi tra le tabelle.
Questo approccio basato sui grafi 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 set di dati senza dover creare modelli separati per ogni attività predittiva.
KumoRFM può essere utilizzato tramite diverse interfacce a seconda del livello di competenza dell'utente:
- PQL (Predictive Query Language): un linguaggio di interrogazione specializzato per la definizione di query predittive su dati strutturati.
- Interfaccia in linguaggio naturale: per gli utenti non tecnici, gli input in linguaggio naturale vengono tradotti automaticamente in query PQL.
- SDK Python: consente agli sviluppatori di integrare il modello nelle pipeline e nelle applicazioni di intelligenza artificiale aziendali.
L'architettura KumoRFM campiona dinamicamente il database per creare sottografi di contesto e sottografi di previsione. Questi sottografi vengono elaborati dal trasformatore di grafi relazionali, che cattura le dipendenze e le informazioni temporali tra le entità correlate. Attraverso l'apprendimento contestuale, il modello fornisce previsioni accurate ed è in grado di spiegare il proprio processo di ragionamento.
Kumo offre due opzioni di implementazione adatte agli ambienti aziendali:
- Piattaforma SaaS: un servizio basato sul cloud costruito su Apache Spark per un facile accesso e scalabilità
- Data warehouse nativo: consente alle organizzazioni di utilizzare i propri dati in Snowflake o Databricks senza spostarli al di fuori del proprio ambiente sicuro.
A differenza dei tradizionali grafi di conoscenza che richiedono la definizione manuale dello schema, KumoRFM costruisce automaticamente il suo grafo relazionale a partire da fonti strutturate. Questo lo rende particolarmente adatto a settori come l'e-commerce, la finanza e la sanità , dove relazioni, modelli temporali e contesto in continua evoluzione sono essenziali per previsioni affidabili.
Le principali funzionalità di KumoRFM includono:
- Flessibilità tra diverse tabelle e strutture di schema.
- Compatibilità con diversi tipi di colonna e identificatori personalizzati.
- Adattamento a compiti specifici durante la fase di inferenza.
- Elevata accuratezza e interpretabilità nelle attività predittive.
Figura 4: L'immagine mostra come i modelli relazionali di base (RFM) funzionano in diversi ambiti, come l'e-commerce, la finanza e la sanità, per fare previsioni, fornire spiegazioni e valutare i risultati. 8
Metodologia di benchmarking
Configurazione e ambiente del benchmark
Per garantire confronti equi tra gli alberi di decisione basati sulla CPU e i modelli accelerati dalla GPU, abbiamo utilizzato un ambiente ad alte prestazioni in grado di gestirli entrambi in modo efficiente.
- Hardware: istanza RunPod con GPU H200 da 140 GB (modello NVIDIA) .
- Software: Python 3.12 con librerie bloccate per garantire 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.
Insiemi di dati: 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 in modo da coprire lo "spettro semantico-numerico", testando l'ipotesi che i modelli lineari linguistici (LLM) eccellano laddove le caratteristiche contengono significato linguistico piuttosto che semplici statistiche grezze.
L'inventario:
- Piccolo e semantico (<1K righe):
- vino (178), sonar (208), voto (435), fasce cilindriche (540), cancro al seno (569).
- Medio/misto (da 1.000 a 10.000 righe):
- credit_g (1K), titanic (1.3K), car_evaluation (1.7K), spambase (4.6K), compas (5.2K), employee_salaries (9.2K).
- Grandi/numerici (oltre 10.000 righe):
- california_housing (20K), house_sales (21K), default_credit (30K), adult_income (48K), diamonds (53K), higgs (campionato a 100K).
Compiti trattati:
- 11 Compiti di classificazione binaria
- 2 Compiti di classificazione multiclasse
- 4 compiti di regressione
Configurazioni del modello e preelaborazione
Abbiamo puntato a un confronto realistico "dal punto di vista pratico", utilizzando impostazioni predefinite robuste piuttosto che un'ottimizzazione esaustiva degli iperparametri.
LightGBM e CatBoost
Per garantire un confronto equo con il modello SAP, che richiede un'elevata potenza di calcolo, abbiamo aumentato il numero di stimatori predefiniti robusti.
- LightGBM: n_estimatori=500, tasso_di_apprendimento=0,05, num_foglie=31. Esegue su CPU (n_lavori=-1).
- CatBoost: iterazioni=500, tasso di apprendimento=0,05, profondità=6. Eseguito su GPU (tipo di attività="GPU").
- Pre-elaborazione: Codifica semplice delle etichette per le variabili categoriche; nessuna scalatura per le variabili numeriche; imputazione dei valori mancanti tramite mediana/moda.
SAP-RPT-1-OSS
Abbiamo configurato SAP per bilanciare prestazioni e costi sulla base dei nostri esperimenti di configurazione preliminari.
- Configurazione: max_context_size=4096, bagging=4.
- Nota:
- Contesto: I test su adult_income hanno dimostrato che l'aumento del contesto da 4096 a 8192 ha triplicato il tempo di esecuzione (da 4 min a 12 min) con un guadagno di accuratezza trascurabile (0,917 vs 0,917 ROC-AUC).
- Insacchettamento: aumento dell'insacchettamento da 4 a 8 (impostazione predefinita di SAP utilizzata nell'articolo) 9 ) offrivano rendimenti decrescenti.
- Preelaborazione: Nessuna. Il DataFrame pandas grezzo viene passato direttamente. Il modello codifica utilizzando gli embedding di testo (sentence-transformers/all-MiniLM-L6-v2).
Protocollo di valutazione
Strategia di convalida incrociata
Abbiamo utilizzato la convalida incrociata a 3 fold con rimescolamento.
- Abbiamo ridotto il fattore di moltiplicazione standard da 5 a 3 per adattarci ai tempi di inferenza lenti di SAP (risparmio di tempo del 40%) mantenendo la validità statistica.
- Suddivisione: K-Fold stratificato per la classificazione; K-Fold standard per la regressione.
Metriche e diagnostica
Siamo andati oltre la semplice accuratezza per ottenere una visione olistica delle prestazioni del modello:
- Metriche di classificazione principali: ROC-AUC (binaria), accuratezza bilanciata (multiclasse), R² (regressione).
- Diagnostica secondaria: abbiamo monitorato il coefficiente di correlazione di Matthews (MCC) e la perdita logaritmica per assicurarci che le vittorie non fossero artefatti dovuti allo squilibrio delle classi, 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 di Wilcoxon per ranghi con segno (p<0,05) ai confronti a coppie tra i modelli per determinare se le differenze di prestazione fossero statisticamente significative o dovute a rumore casuale.
Limitazioni e validità interna
Nella nostra metodologia riconosciamo esplicitamente i seguenti limiti:
- Configurazioni standardizzate vs. ottimizzazione: abbiamo utilizzato configurazioni predefinite fisse e robuste per tutti i modelli, anziché eseguire un'ottimizzazione esaustiva degli iperparametri (ad esempio, CV annidata o Optuna sweep). Sebbene ciò garantisca una base di riferimento coerente, è importante notare che i modelli ad albero spesso mostrano miglioramenti delle prestazioni con un'ottimizzazione specifica per il dataset, il che potrebbe ridurre i margini nel cluster "Competitivo".
- Limiti di scala dei dati: la nostra analisi si è concentrata su set di dati con meno di 100.000 righe per simulare scenari tipici di aziende di medie dimensioni. Abbiamo osservato che il vantaggio del modello LLM diminuiva con l'aumentare del volume dei dati, ma non abbiamo esteso i test a set di dati con milioni di righe, dove la latenza e il costo dell'inferenza sarebbero probabilmente diventati i principali fattori limitanti.
- Uniformità dell'infrastruttura: per mantenere un ambiente di test coerente, abbiamo eseguito tutti i modelli sullo stesso hardware H200 NVIDIA. LightGBM e CatBoost sono altamente ottimizzati per CPU standard; pertanto, in un ambiente di produzione dedicato esclusivamente ai modelli Tree, la differenza di costo sarebbe probabilmente maggiore.
- Generalizzazione oltre la semantica: la nostra ipotesi "Spettro semantico" ha previsto con successo molti risultati, ma le ottime prestazioni del modello LLM su dataset astratti come sonar e california_housing suggeriscono 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 là dello scopo di questo studio iniziale.
Collegamenti di riferimento
Sii il primo a commentare
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori.