Il predittore di home run di Google Cloud al MLB All-Star Game 2025

Cosa fa davvero il sistema al Truist Park

Google Cloud ha costruito, insieme all'unità Statcast della MLB, uno strumento che stima dove potrebbe atterrare tra gli spalti un potenziale home run durante l'All-Star Game. Quando un giocatore va in battuta, il modello prevede il settore più probabile in cui atterrerebbe la palla in caso di home run.

La previsione si basa su dati storici relativi a tutta la rosa dell'All-Star: statistiche classiche come la media battuta e la percentuale di home run, più dati sulla direzione delle battute negli stadi nel corso della storia. Anche il meteo entra in gioco — la fonte cita direzione del vento e temperatura tra gli input.

In una demo pre-partita, il modello ha stabilito che un home run di Shohei Ohtani sarebbe atterrato con più probabilità tra i settori 152-154. Questo output specifico mostra che il sistema produce un intervallo di posti concreto, non solo un punteggio di probabilità.

Due modelli per due compiti diversi

La scelta progettuale interessante qui è la suddivisione dei compiti. Un modello predittivo si occupa della stima della traiettoria e sceglie un settore. Solo dopo, la pipeline passa il testimone a Gemini 2.5 Pro, che genera qualche decina di messaggi candidati per il megaschermo, i tabelloni e gli schermi delle aree comuni.

È una divisione del lavoro sensata. Al modello generativo non si chiede di prevedere la fisica; gli si chiede di scrivere un testo una volta scelto il settore. Google attribuisce a Vertex AI il merito dell'orchestrazione, e nota che la versione per i cartelloni ha restituito i messaggi in pochi secondi.

L'uomo nel processo non è un dettaglio marginale

La fonte è chiara: durante la partita, un team di revisori umani avrebbe selezionato il messaggio preferito e modificato il linguaggio per lunghezza, scelta delle parole o impaginazione prima che apparisse in tutto lo stadio. Google descrive questa prassi in modo esplicito.

Se ciò accadeva durante la partita, un team di revisori umani selezionava l'opzione preferita, apportando rapidamente eventuali modifiche al linguaggio se necessario, sia per la lunghezza, la scelta delle parole o l'impaginazione.Montana Labs

Quel passaggio di revisione conta perché il testo generato finisce sugli schermi dello stadio davanti a un pubblico dal vivo. Il modello produce delle opzioni; una persona prende la decisione finale. È un promemoria del fatto che generare qualche decina di candidati costa poco, e che il valore del sistema sta in parte nel fornire ai revisori una rosa di scelte rapide.

La variante per i cartelloni rivela l'ingegneria più complessa

Prima della partita, lo stesso motore alimentava cartelloni mobili in giro per Atlanta con messaggi specifici per località — ad esempio, una frase su una palla colpita da Ronald Acuña Jr. viaggiata a 121 miglia orarie, messa a confronto con la velocità media del traffico in città.

Google descrive la versione per i cartelloni come più complessa di quella per lo stadio: si è estesa oltre gli home run fino al lancio e ad altre statistiche, e ha dovuto integrare dati su posizione e traffico insieme al meteo. Sono gli input aggiuntivi, non la novità dell'idea, il punto su cui si è concentrato il lavoro di orchestrazione.

Cosa insegna una demo da stadio sulle pipeline agentiche

Spogliata del fascino dell'evento, questa è una pipeline in due fasi: un modello di dominio che restringe una previsione, un modello generativo che produce opzioni testuali limitate, e un controllo umano prima che qualcosa venga pubblicato. Google la inquadra come IA agentica, accanto a esempi come Gemini che chiama un ristorante o clienti bancari che costruiscono agenti di ricerca.

La lezione pratica è che le parti più impegnative erano l'idraulica dei dati e la latenza — combinare statistiche storiche con ordini di battuta in tempo reale, meteo e traffico, per poi restituire i messaggi in pochi secondi. L'implicazione specifica per i team che costruiscono sistemi simili: la scelta del modello è la decisione facile, mentre definire un compito di generazione ben delimitato a valle di un predittore affidabile, e mantenere un passaggio di revisione umana nel percorso, è ciò che rende l'output utilizzabile in un contesto live.