Modelli, assunzioni e misspecification

Una regressione sembra spiegare bene le vendite medie, ma sbaglia sistematicamente weekend, promozioni e clienti nuovi. Il modello non è “falso” in senso banale: sta rispondendo a una domanda più stretta di quella che il business gli sta chiedendo. Modelli, assunzioni e misspecification serve a riconoscere questo scarto.

Una scena da cui partire

Leggi la lezione come audit delle assunzioni. Ogni modello semplifica la realtà: il punto professionale è sapere quale semplificazione è accettabile, quale produce bias e quale rende inutilizzabile la conclusione.

• Contesto: Quale assunzione del modello è più fragile nel caso reale?
• Metodo: Quale residuo o errore sistematico rivela misspecification?
• Applicazione: Come comunicheresti il limite del modello prima della decisione?

L’Architettura Nascosta di Ogni Modello: Le Assunzioni Fondamentali

Ogni modello, da una semplice regressione lineare a una complessa rete neurale profonda, è una rappresentazione stilizzata della realtà. Questa stilizzazione avviene attraverso un insieme di assunzioni, spesso implicite, che costituiscono la sua architettura logica. Ignorarle significa costruire un grattacielo su fondamenta di sabbia. Analizziamo le più comuni e insidiose. Per i modelli lineari, come la regressione OLS (Ordinary Least Squares), le quattro assunzioni canoniche (note con l’acronimo BLUE: Best Linear Unbiased Estimator) sono un punto di partenza imprescindibile. La linearità postula che la relazione tra le variabili indipendenti e la variabile dipendente sia, appunto, lineare. Se tentiamo di modellare la crescita delle vendite di un prodotto, che tipicamente segue una curva a S (lenta all’inizio, rapida nella fase di adozione, piatta alla maturità), con una retta, il nostro modello sarà sistematicamente errato in ogni fase del ciclo di vita. L’indipendenza degli errori (o assenza di autocorrelazione) richiede che il residuo di un’osservazione non sia correlato a quello di un’altra. Questa assunzione è quasi sempre violata nei dati di serie temporali: le vendite di oggi sono quasi certamente correlate a quelle di ieri. Ignorare questa dipendenza porta a stimare intervalli di confidenza troppo ottimistici, facendoci credere di avere una precisione che non possediamo. L’omoschedasticità, o costanza della varianza degli errori, assume che la dispersione dei residui sia uniforme lungo tutto il range dei valori predetti. In finanza, questo è raramente vero: la volatilità dei rendimenti azionari tende a raggrupparsi in periodi di alta e bassa turbolenza (eteroschedasticità), un fenomeno che un modello omoschedastico non può catturare. Infine, la normalità degli errori è necessaria per l’inferenza statistica classica (t-test, F-test). Eventi rari e di grande impatto (cigni neri) creano code pesanti nella distribuzione degli errori, invalidando i p-value calcolati sotto l’assunzione di normalità.

Passando al machine learning, le assunzioni cambiano forma ma non sostanza. La più pervasiva è l’assunzione IID (Independent and Identically Distributed). Si assume che i dati usati per l’addestramento, la validazione e il test provengano dalla stessa distribuzione di probabilità e che ogni campione sia indipendente dagli altri. Nel mondo reale, questo è un lusso. Un modello di raccomandazione per un e-commerce addestrato sui dati di novembre (periodo Black Friday) performerà male a febbraio, perché la distribuzione del comportamento d’acquisto è drasticamente diversa (“non-identically distributed”). Un modello di churn che non tiene conto dell’influenza sociale tra utenti (un utente che abbandona la piattaforma influenza i suoi amici) viola l’assunzione di indipendenza. Strettamente legata è l’assunzione di stazionarietà: il processo che genera i dati non cambia nel tempo. Le preferenze dei consumatori, le strategie dei competitor, le condizioni macroeconomiche sono tutto fuorché stazionarie. Un modello addestrato prima del 2020 non poteva prevedere l’esplosione della domanda per le attrezzature da home office. Il fallimento nel riconoscere e modellare esplicitamente queste dinamiche è la causa principale del model drift o concept drift, dove un modello un tempo accurato degrada silenziosamente fino a diventare inutile.

La Diagnosi della Misspecification: Riconoscere i Sintomi Prima del Danno

Un modello mal specificato, ovvero un modello le cui assunzioni sono violate in modo significativo, non sempre fallisce in modo plateale. Spesso, manifesta una serie di sintomi che, se ignorati, portano a decisioni errate. Il primo e più classico segnale di allarme è la discrepanza tra metriche di fit e performance predittiva. Un valore di R² del 95% su un training set può sembrare eccellente, ma se l’errore quadratico medio (RMSE) su un test set inedito è tre volte superiore, siamo di fronte a un caso da manuale di overfitting. Il modello non ha appreso il segnale sottostante, ma ha memorizzato il rumore specifico del campione di addestramento. Ha imparato a memoria le risposte del test precedente, ma non ha capito la materia. Questo accade quando la complessità del modello (ad esempio, un polinomio di grado elevato o un albero di decisione troppo profondo) è eccessiva rispetto alla quantità di segnale presente nei dati.

Un secondo sintomo, più sottile, è l’instabilità dei coefficienti. In un modello di regressione multipla, se l’aggiunta o la rimozione di una piccola frazione di dati (magari il 5%) causa oscillazioni violente nei coefficienti stimati, o addirittura un cambio di segno, è probabile la presenza di multicollinearità. Questo accade quando due o più variabili indipendenti sono fortemente correlate tra loro. Ad esempio, in un modello che predice il reddito, le variabili “anni di istruzione” e “livello del titolo di studio” sono altamente ridondanti. Il modello non riesce a discernere l’effetto unico di ciascuna, e le stime diventano inaffidabili, come cercare di capire il contributo individuale di due persone che spingono un’auto sempre insieme e con la stessa forza. Strumenti come il Variance Inflation Factor (VIF) sono essenziali per diagnosticare questo problema prima che inquini l’interpretazione del modello.

Un’analisi visuale dei residui è forse lo strumento diagnostico più potente. I residui (la differenza tra i valori osservati e i valori predetti dal modello) dovrebbero apparire come rumore bianco: casuali, senza pattern, con media zero e varianza costante. Se, plottando i residui contro i valori predetti, emerge una forma a imbuto (aumentano al crescere del valore predetto), l’assunzione di omoschedasticità è violata. Se, in una serie temporale, i residui mostrano una ciclicità evidente, significa che il modello non ha catturato la stagionalità o il ciclo economico presente nei dati. Questi pattern non sono errori casuali; sono segnale che il modello ha lasciato sul tavolo.

Infine, il sintomo più critico per qualsiasi modello in produzione è la divergenza tra performance offline e online. Un modello di propensity-to-buy può mostrare un lift del 30% in fase di backtesting (offline), ma quando viene implementato in un A/B test (online) il suo impatto sull’effettivo tasso di conversione è nullo o addirittura negativo. Questo può accadere per innumerevoli ragioni legate a violazioni di assunzioni: il backtest non ha simulato correttamente la latenza del sistema reale, i dati di training erano “inquinati” da conoscenza del futuro (data leakage), o il comportamento degli utenti cambia quando interagiscono con il nuovo modello. La validazione offline è un’ipotesi, il test online è la tesi. Una divergenza significativa tra le due è un segnale inequivocabile che una o più assunzioni chiave sul funzionamento del sistema reale sono sbagliate.

Caso Studio: Netflix e la Sfida della Non-Stazionarietà dei Gusti

Netflix ha costruito un impero da 250 miliardi di dollari su una premessa apparentemente semplice: raccomandare il contenuto giusto all’utente giusto al momento giusto. Il suo sistema di raccomandazione, evolutosi enormemente dal famoso “Netflix Prize” del 2009, è un esempio magistrale di come affrontare il problema della non-stazionarietà. L’assunzione fondamentale di qualsiasi motore di raccomandazione è che le preferenze passate di un utente siano un buon predittore delle sue preferenze future. Ma i gusti delle persone non sono statici. Evolvono lentamente nel tempo (un utente potrebbe sviluppare un interesse per i documentari dopo aver visto solo film d’azione per anni) e possono cambiare bruscamente a causa di eventi esterni. La pandemia di COVID-19, ad esempio, ha causato un’impennata globale nella visione di film su pandemie (come “Contagion”) e serie TV confortanti (come “The Office”), un pattern che nessun modello addestrato su dati pre-2020 avrebbe potuto prevedere.

Come gestisce Netflix questa violazione cronica dell’assunzione di stazionarietà? Attraverso un approccio multi-livello. Primo, i loro modelli incorporano il decadimento temporale (time decay). Una valutazione o una visione di cinque anni fa pesa molto meno di una di ieri nel calcolo delle affinità. Questo permette al modello di adattarsi gradualmente all’evoluzione dei gusti dell’utente. Secondo, Netflix non si affida a un singolo algoritmo monolitico, ma a un ensemble di modelli specializzati. C’è un modello per la “similarità” tra titoli, uno per la personalizzazione della home page (“Because you watched…”), uno per le tendenze globali e locali (“Top 10 in Italy Today”). Questo approccio diversificato mitiga il rischio: se un modello basato sulla cronologia a lungo termine fallisce nel catturare un nuovo interesse, un modello basato sulle tendenze recenti o sul contesto attuale (es. l’ora del giorno, il dispositivo usato) può compensare.

Terzo, e forse più importante, Netflix investe massicciamente nell’esplorazione attiva tramite algoritmi di tipo multi-armed bandit, in particolare i contextual bandits. Invece di mostrare sempre e solo ciò che il modello predice con alta confidenza che piacerà all’utente (sfruttamento), il sistema riserva una piccola parte delle impressioni per testare raccomandazioni più audaci (esplorazione). Se un utente che guarda solo fantascienza viene esposto a un thriller acclamato dalla critica e lo guarda fino alla fine, il sistema riceve un segnale potente che i suoi gusti si stanno espandendo. Questo feedback continuo permette al modello di aggiornarsi e non rimanere intrappolato in “bolle di filtro” obsolete. Il risultato di questa gestione sofisticata della non-stazionarietà è tangibile. Si stima che il sistema di raccomandazione di Netflix influenzi l’80% delle ore di visione sulla piattaforma e che il suo continuo miglioramento abbia contribuito a ridurre il churn rate di diversi punti percentuali nel corso degli anni, un impatto che vale miliardi di dollari di lifetime value dei clienti.

Caso Studio: Stripe Radar e la Lotta alla Multicollinearità nelle Frodi

Stripe, la piattaforma di pagamenti che nel 2023 ha processato oltre 1 trilione di dollari in transazioni, opera in un ambiente ad altissimo rischio: le frodi online. Il suo prodotto di punta per la prevenzione delle frodi, Radar, utilizza il machine learning per analizzare ogni singola transazione in tempo reale e bloccare quelle sospette. Una delle sfide tecniche più complesse nella modellazione delle frodi è la multicollinearità, ovvero l’alta correlazione tra le variabili predittive. Immaginiamo di costruire un modello per prevedere la probabilità che una transazione sia fraudolenta. Potremmo usare feature come: importo_transazione, paese_carta, paese_IP, ora_transazione, numero_tentativi_falliti_ultime_24h, prodotto_acquistato_è_digitale. Molte di queste variabili sono intrinsecamente correlate. Ad esempio, le transazioni fraudolente hanno spesso un importo elevato e provengono da combinazioni di IP e carte di paesi ad alto rischio. L’ora della transazione (es. le 3 del mattino) potrebbe essere correlata al numero di tentativi falliti.

Se Stripe utilizzasse un modello lineare semplice come una regressione logistica, la multicollinearità renderebbe i coefficienti del modello estremamente instabili e difficili da interpretare. Il modello potrebbe assegnare un peso negativo a importo_transazione solo perché il suo effetto è già catturato da altre variabili correlate, portando a conclusioni illogiche e a una performance subottimale. Per superare questo problema, Stripe Radar si affida a modelli intrinsecamente più robusti alla multicollinearità, come gli ensemble basati su alberi decisionali (es. Gradient Boosting Machines come XGBoost o LightGBM). Questi modelli funzionano partizionando lo spazio delle feature in modo sequenziale. Ad ogni passo, l’algoritmo seleziona la feature che meglio divide i dati, rendendolo meno sensibile alla ridondanza informativa. Se paese_carta e paese_IP sono quasi identici, l’algoritmo potrebbe usare prevalentemente una delle due, neutralizzando di fatto l’effetto della multicollinearità.

Inoltre, una parte cruciale del loro approccio è un sofisticato processo di feature engineering. Invece di inserire nel modello decine di variabili grezze e correlate, gli ingegneri di Stripe creano feature aggregate e di interazione che catturano segnali più puliti. Ad esempio, invece di usare paese_carta e paese_IP separatamente, potrebbero creare una feature binaria paese_carta_diverso_da_paese_IP. Oppure, potrebbero calcolare la “reputazione storica” di un indirizzo IP, di un’email o di un identificativo del dispositivo, aggregando migliaia di transazioni passate. Queste feature di livello superiore sono spesso meno correlate tra loro e contengono un segnale predittivo molto più forte. Grazie a questo approccio, che combina modelli robusti e un’ingegneria del dato intelligente per gestire le assunzioni violate, Stripe Radar è in grado di bloccare centinaia di milioni di dollari di frodi ogni anno per i suoi clienti, mantenendo al contempo un tasso di falsi positivi estremamente basso, un risultato che ha permesso all’azienda di aumentare la revenue dei propri utenti di una media del 7% grazie alla riduzione delle transazioni legittime bloccate erroneamente.

Dalla Teoria alla Pratica: Validazione e Monitoraggio Robusto

La consapevolezza delle assunzioni di un modello è il primo passo, ma la disciplina nel validarlo e monitorarlo è ciò che separa i team di data science di successo da quelli che causano disastri come quello di Zillow. Un processo di validazione robusto va ben oltre la semplice divisione dei dati in training e test. La cross-validation, in particolare le sue varianti più complesse, è essenziale. Per dati non temporali, la k-fold cross-validation è uno standard. Ma per le serie temporali, utilizzare una k-fold casuale è un errore metodologico grave, perché permette al modello di “vedere il futuro” per predire il passato. In questi casi, sono necessarie strategie come la time-series split (o walk-forward validation), in cui il training set è costituito da dati fino al tempo t e il test set da dati dal tempo t+1 in poi, simulando realisticamente lo scenario di produzione.

Una volta che il modello è in produzione, il lavoro è appena iniziato. È necessario implementare un sistema di monitoraggio continuo per rilevare il model drift. Questo si manifesta in due forme: data drift e concept drift. Il data drift (o feature drift) si verifica quando la distribuzione statistica delle variabili di input cambia. Ad esempio, il reddito medio dei nuovi clienti di una fintech potrebbe aumentare a seguito di una nuova campagna di marketing. Questo non significa che la relazione tra reddito e churn sia cambiata, ma il modello ora opera su una porzione di dati che non aveva visto in addestramento. Il concept drift è più profondo: è la relazione stessa tra input e output a cambiare. Ad esempio, una nuova regolamentazione potrebbe rendere un certo tipo di transazione, prima legittima, ora illegale, cambiando la definizione stessa di “frode”.

Per rilevare il data drift, si usano test statistici che confrontano la distribuzione di ogni feature nel training set con la distribuzione della stessa feature nei dati di produzione correnti. Il test di Kolmogorov-Smirnov (per variabili continue) o il Chi-quadrato (per variabili categoriche) sono strumenti comuni. Quando la statistica del test supera una certa soglia, scatta un allarme.

Ecco un esempio pratico in Python per implementare un rilevatore di drift usando il test di Kolmogorov-Smirnov a 2 campioni dalla libreria scipy.

Controllo	Domanda da fare	Decisione
Distribuzione training	Come si comportava la variabile quando il modello e stato stimato?	Definisce la baseline
Distribuzione produzione	La stessa variabile oggi ha forma, media o coda diverse?	Individua drift operativo
Test statistico	La differenza e compatibile con rumore o segnala cambiamento reale?	Decide se allertare il team
Soglia di azione	Quanto deve essere forte il segnale prima di intervenire?	Evita allarmi continui
Messaggio finale	Quale feature e cambiata, quanto, e con quale impatto potenziale?	Trasforma il controllo tecnico in governance

Un controllo di drift ben scritto non deve impressionare con codice: deve dire quando una relazione stimata non è più affidabile per decidere. Questo codice fornisce un meccanismo semplice ma efficace per automatizzare il monitoraggio del data drift, un pilastro fondamentale per la manutenzione di qualsiasi sistema di machine learning in un ambiente dinamico.

Laboratorio Pratico: Messa in Discussione delle Assunzioni

Per consolidare questi concetti, affrontiamo alcuni esercizi pratici. L’obiettivo non è trovare la soluzione “giusta”, ma sviluppare un’abitudine al pensiero critico sulle fondamenta dei nostri modelli.

Esercizio 1: Analisi dei Residui di un Modello Imperfetto Immagina di lavorare per una catena di caffetterie e di aver costruito un modello di regressione lineare semplice per prevedere le vendite giornaliere (sales) basandoti solo sulla temperatura media di quel giorno (temperature). Dopo aver fittato il modello, ottieni i residui. Plottando i residui contro i giorni della settimana (da Lunedì a Domenica), noti che i residui sono sistematicamente negativi il Sabato e la Domenica, e positivi durante la settimana.

1. Quale assunzione del modello di regressione lineare è chiaramente violata da questo pattern?
2. Cosa ti suggerisce questo pattern riguardo alla relazione tra giorni della settimana e vendite?
3. Come modificheresti il modello per risolvere questo problema di misspecification? (Suggerimento: pensa a come includere una variabile categorica nel modello).

Esercizio 2: Simulare e Rilevare il Data Drift Utilizzando la funzione Python detect_data_drift fornita in precedenza e le librerie numpy e pandas, completa i seguenti passaggi:

1. Crea un DataFrame df_training con una colonna user_age contenente 1000 campioni da una distribuzione normale con media 35 e deviazione standard 8.
2. Crea un secondo DataFrame df_production_no_drift con 500 campioni dalla stessa identica distribuzione. Esegui la funzione di rilevamento drift. Qual è il risultato atteso per il p_value e is_drift_detected?
3. Crea un terzo DataFrame df_production_with_drift dove la distribuzione dell’età è cambiata: ora i nuovi utenti sono più giovani. Genera 500 campioni da una distribuzione normale con media 28 e deviazione standard 10. Esegui nuovamente la funzione di rilevamento drift confrontando df_training con df_production_with_drift. Spiega il risultato ottenuto.

Esercizio 3: Critica di un Modello di Business Sei il nuovo Data Scientist di “FitPal”, un’app di fitness che offre piani di abbonamento. Il team precedente ha costruito un modello di classificazione (basato

Laboratorio ed esercizi

Metti in pratica quanto appreso con esercizi a difficoltà crescente. Lavora su un dataset reale — se non hai accesso al tuo data warehouse aziendale, usa dataset pubblici come Google Analytics Sample su BigQuery o il dataset E-Commerce di Kaggle.

Esercizio 1 — Implementazione base. Riproduci la query o il modello descritto nella lezione, adattandolo al tuo dataset. Verifica che i risultati siano coerenti con le metriche attese: se il totale non quadra con una query di controllo, c’è un problema di grain.

Esercizio 2 — Estensione. Aggiungi una dimensione di analisi non coperta nella lezione: segmenta per paese, per device, per fascia oraria o per coorte. Dove emergono pattern inattesi? Cosa implicano per le decisioni operative?

Esercizio 3 — Automazione. Trasforma la query in una vista o in un modello dbt con test di integrità (unique, not_null) e documenta le colonne. Se il tuo stack lo permette, configura un alert che notifichi quando la metrica esce da 2 deviazioni standard dalla media mobile.

Problema reale

Nel lavoro su fondamenti filosofici dell’analisi dati, Modelli, assunzioni e misspecification serve a risolvere un problema concreto: capire quando un dato sostiene davvero una decisione e quando invece nasconde assunzioni, bias, causalità fragile o una domanda formulata male. La domanda non è se il concetto sia interessante in astratto, ma quale decisione migliora quando lo applichi con dati affidabili e con una soglia di errore esplicita.

Questa lezione va studiata come uno strumento operativo: entro la fine devi saper Comprendere il problema analitico e il contesto decisionale; Applicare esempi, metriche e controlli a casi reali. Se non riesci a collegare il concetto a una scelta reale, la conoscenza resta decorativa e non diventa competenza.

Modello concettuale

flowchart LR
    A["Osservazione"]
    B["Assunzione"]
    C["Modello"]
    D["Evidenza"]
    E["Decisione"]
    A --> B
    B --> C
    C --> D
    D --> E

Il modello mentale e sequenziale: prima si formula la domanda, poi si traduce in unità osservabili, quindi si valuta la qualità del dato e solo alla fine si decide. Saltare un passaggio produce analisi eleganti ma fragili.

Passaggio	Domanda guida	Output atteso
Framing	Quale decisione deve cambiare?	Una scelta concreta, non una curiosità
Misura	Quale segnale rappresenta il fenomeno?	Metrica, fonte e granularità
Confronto	Rispetto a quale baseline interpreto il risultato?	Benchmark o controfattuale plausibile
Azione	Che cosa faccio se il segnale supera la soglia?	Decisione, owner e prossimo controllo

Formalizzazione rigorosa

Formalizza Modelli, assunzioni e misspecification come una relazione tra quattro elementi: unità di analisi, segnale, baseline e decisione. Nel contesto di questa lezione l’unità principale e osservazione, ipotesi, variabile, meccanismo causale o criterio di evidenza. Il segnale da osservare deve essere collegato a forza dell evidenza, coerenza causale, robustezza delle assunzioni e costo dell errore decisionale, mentre la baseline deve essere scelta tra spiegazione alternativa, controfattuale, gruppo comparabile o scenario senza intervento.

Una formulazione robusta segue questa logica:

Elemento	Definizione operativa per questa lezione
Unità	osservazione, ipotesi, variabile, meccanismo causale o criterio di evidenza
Segnale	forza dell evidenza, coerenza causale, robustezza delle assunzioni e costo dell errore decisionale
Baseline	spiegazione alternativa, controfattuale, gruppo comparabile o scenario senza intervento
Decisione	accettare, rifiutare o riformulare una spiegazione prima di usarla in un contesto aziendale
Rischio	Confondere correlazione, qualità del dato e causalità decisionale

La regola pratica e semplice: una misura e utile solo se riduce l’incertezza su una decisione specifica. Se non cambia una scelta, e documentazione; se cambia una scelta senza controlli, e rischio.

Esempio o caso studio

Un comitato interpreta una crescita di retention come prova che una nuova iniziativa abbia funzionato. La lezione costringe a distinguere osservazione, spiegazione, assunzione e decisione prima di trasformare il dato in azione.

Applicando Modelli, assunzioni e misspecification, il team costruisce una lettura in tre colonne: cosa sappiamo, cosa assumiamo e quale decisione prendiamo. Questo formato impedisce di presentare un numero come se fosse una conclusione autosufficiente.

Evidenza	Interpretazione prudente	Decisione conseguente
Segnale positivo ma non isolato	Il fenomeno esiste, ma la causa e ancora incerta	Cercare baseline o holdout
Segmento con risposta diversa	L’effetto medio nasconde eterogeneita	Analizzare coorti o sottogruppi
Costo operativo crescente	Il risultato va valutato sul margine	Applicare soglie economiche

Lab / esercizio

Livello base

Prendi una decisione reale collegata a Modelli, assunzioni e misspecification e scrivi in cinque righe: obiettivo, metrica primaria, baseline, rischio principale e azione prevista. Non usare più di una metrica primaria.

Livello intermedio

Costruisci una tabella con almeno tre segmenti o scenari. Per ciascuno indica segnale, possibile spiegazione alternativa e controllo necessario prima di decidere.

Livello research-grade

Disegna un piano di validazione: ipotesi, dati necessari, criterio di esclusione, soglia decisionale e controllo post-decisione. Specifica anche che cosa ti farebbe cambiare idea.

Dataset e materiali consigliati

Usa case study decisionali, metriche prodotto, risultati di esperimenti, DAG semplici, report analitici e serie storiche simulate. Se non hai dati reali, crea un dataset sintetico con 200-500 righe e almeno una colonna temporale, una colonna segmento, una metrica di outcome e una variabile di esposizione.

Errore tipico da evitare

L’errore più frequente e trattare Modelli, assunzioni e misspecification come una definizione da ricordare invece che come un protocollo decisionale. In pratica succede quando si presenta una metrica senza baseline, un grafico senza ipotesi, o una raccomandazione senza costo dell’errore.

Un controllo utile è chiedersi: “se questo risultato fosse falso o instabile, quale decisione sbaglierei?”. Se la risposta non è chiara, la lezione non è ancora stata applicata davvero.

Quiz o checkpoint

1. Qual è la decisione concreta che questa lezione dovrebbe migliorare?
2. Quale baseline rende interpretabile il risultato?
3. Quale assunzione, se sbagliata, cambierebbe la conclusione?
4. Quale controllo minimo useresti prima di presentare la raccomandazione?

Riepilogo operativo

Modelli, assunzioni e misspecification e una competenza utile quando collega concetto, dato e decisione. Studiala partendo da un problema reale, formalizza il segnale, cerca una baseline credibile, costruisci un esempio e chiudi con un controllo pratico. Categoria: Fondamenti. Difficoltà: advanced. Tempo stimato: 18 min.