AI Engineer · Data & ML
Costruisco sistemi che trovano ciò che si somiglia, e misuro se hanno ragione.
Informatica di formazione, AI applicata di mestiere. Il filo conduttore sono dati da abbinare, recuperare o prevedere, e la domanda su come si fa a sapere che la risposta è giusta.
Mag 2021
Max Mara Fashion Group · Reggio Emilia
Una web app in Flask per monitorare come si distribuisce il tempo tra i progetti aziendali: schema relazionale, logica di business e KPI di efficienza.
Set 2022
Università di Modena e Reggio Emilia
Scienze e Tecnologie Informatiche, conclusa a luglio 2025.
Mar 2025
OT Consulting · Reggio Emilia
Un sistema predittivo sul potenziale di successo di nuovi progetti di business: modello scikit-learn, uno strato LLM che scrive report leggibili, servito con FastAPI. Il tempo di analisi è passato da ore a minuti.
Giu 2025 →
OT Consulting · Reggio Emilia
Servizi backend in Python e API REST per clienti enterprise, funzionalità full-stack in Vue.js, SQLAlchemy e MySQL, ML e AI integrati nei progetti, e la migrazione di un'applicazione legacy su Google Cloud.
Dic 2026
Università di Modena e Reggio Emilia
Curriculum Data Engineering & Analytics, iniziata a settembre 2025. Laurea prevista a dicembre 2026.
Sei progetti, ognuno con la sua valutazione e i suoi limiti messi per iscritto. I numeri vengono dai repository, non dalla memoria.
Un sistema di domande e risposte sull'AI Act, costruito su una norma cambiata dopo il cutoff del modello. Così il valore del retrieval si può contare, invece di darlo per scontato.
Una pipeline di ML clinico end-to-end e un esperimento per capire se il protocollo di validazione conta quanto il modello. Non è così, e il risultato negativo è la cosa più utile che il progetto ha prodotto.
Una pipeline di computer vision per il calcio, dalla detection al tracking, dall'assegnazione delle squadre alla calibrazione del campo fino alla vista dall'alto, con ogni fase misurata su una ground truth annotata a mano.
Un progetto universitario di data integration. Quando i codici clinici sono "quasi giusti", il confronto esatto perde colonne che stanno chiaramente insieme. Una similarità costruita sulla gerarchia SNOMED le ritrova.
Il digital twin di un parcheggio. Una webcam sopra un plastico di carta aggiorna in tempo reale lo stato di ogni posto, e sopra ci sono un bot Telegram, una sbarra comandata dal GPS e una federazione B2B.
Perché i dipendenti se ne vanno? Feature engineering sui log dei badge, sei classificatori a confronto e SHAP per trasformare il modello in azioni per l'HR.
Una visualizzazione animata di una pipeline RAG, dalla query ai chunk, dai punteggi al reranking fino alla risposta, con backend live e una modalità replay per ripercorrere un'esecuzione passo per passo.
Link alla demo in arrivo
Progetto universitario · Schema matching e data integration
Gli ospedali registrano le stesse informazioni in database diversi, con nomi di colonna diversi. Per unirli bisogna prima capire quale colonna dell'uno corrisponde a quale dell'altro: è lo schema matching. Un modo comune per farlo è guardare i valori: se due colonne contengono le stesse cose, probabilmente significano la stessa cosa.
Con i dati clinici è più difficile. Le diagnosi sono codici presi da enormi vocabolari medici, e gli errori di codifica reali raramente sono casuali. Qualcuno registra "insufficienza renale cronica, stadio 5" quando era stadio 4: un concetto vicino, non un refuso. Per un confronto esatto quei due codici sono diversi quanto "malattia renale" e "frattura del braccio".
Il progetto tratta il vocabolario per quello che è, una gerarchia: due codici sono simili se sono vicini nell'albero. Ho costruito un modo per generare errori realistici "di prossimità" su dati OMOP-CDM e un matcher che confronta i valori per significato e non per grafia, e ho misurato entrambi contro il confronto esatto sul framework di benchmark Valentine.
Come affronto un problema di dati o di ML. Non sono regole lette da qualche parte: ognuna viene da un errore che ho fatto o scovato nei miei progetti.
Scelgo la metrica in base alla decisione che deve supportare, prima di toccare un modello. Con l'11% di positivi l'accuracy premia il non fare nulla: nel progetto sulle riammissioni la metrica è l'AUC-PR e la soglia viene dal costo atteso.
I bug costosi non fanno crashare niente. Un "None" che vuol dire "esame non richiesto", pazienti che non possono essere riammessi, un parser che restituisce in silenzio 114 unità invece di 586. Li cerco prima di addestrare qualsiasi cosa.
Una baseline semplice dice quanto vale la parte furba. Nel progetto RAG ha mostrato che retrieval e accuratezza finale non vanno di pari passo, cosa che altrimenti mi sarebbe sfuggita.
Confronti appaiati, intervalli di confidenza, soglie calibrate su dati separati. Se un disegno non può rispondere alla domanda, si cambia il disegno. È così che "il protocollo conta" è diventata un'ipotesi rifiutata.
Ogni progetto finisce con ciò che non sa fare. Chi legge un MOTA negativo merita la spiegazione nello stesso punto del numero.
Uso Claude Code ogni giorno come compagno di programmazione: per leggere codice che non conosco, impostare le parti noiose, scrivere test e mettere alla prova il mio ragionamento. Le decisioni restano mie: cosa costruire, cosa misurare, quando qualcosa non torna.
In pratica vuol dire modifiche piccole e rilette invece di grandi blocchi generati, chiedere esplicitamente i casi in cui le cose si rompono e verificare i numeri sulla fonte invece di fidarmi di un riassunto. Anche questo sito è nato così, con ogni cifra controllata sui repository.
Quello che uso nei miei progetti e al lavoro.
Disponibile per parlare di ruoli in AI engineering e data/ML, collaborazioni di ricerca o un progetto su cui ti serve un secondo parere.