Come Databricks Aiuta le Squadre di Baseball a Ottenere un Vantaggio con Dati e AI

Il baseball si muove velocemente, definito da piccoli momenti: un lancio, un confronto, una decisione. Questa storia segue come uno spogliatoio moderno utilizza Databricks per trasformare dati di lancio ad alta fedeltà in decisioni che aiutano a vincere le partite.

Giorno della partita, ore 14:00

Riunione battitori con Genie e Unity Catalog

I battitori entrano nella sala video. L'allenatore non vuole una stampa di 30 pagine; vuole un piano chiaro per lo starter di stasera.

Prima quel giorno, l'analista si è seduto al suo laptop e ha aperto Genie, sopra Unity Catalog, dove vivono i dati Statcast e le tabelle derivate dal team con schemi, permessi e lineage coerenti. Ha chiesto:

“Per lo starter di stasera, mostra il mix e le posizioni del primo lancio ai nostri battitori destrorsi e mancini nelle ultime due stagioni. Evidenzia i trend quando ci sono corridori in base.”

Genie ha compilato la risposta dalle tabelle Delta governate in Unity Catalog. Come parte di quel lavoro, l'analista ha anche registrato un set di funzioni SQL di Unity Catalog che incapsulano le query chiave, come le tendenze per conteggio, mano e stato del corridore in base, in modo che possano riutilizzarle nella pianificazione futura e negli agenti automatizzati.

L'analista ha esportato i risultati in un semplice foglio di una pagina che lo staff poteva stampare o includere nei raccoglitori dei battitori. I punti chiave erano:

• Destrorsi: cutter alti e four-seamers presto, specialmente con basi vuote.
• Mancini: più changeup e sinker quando c'è un corridore in seconda.
• Due strike: slider basso e fuori appare nella maggior parte dei K importanti.

L'allenatore di battuta entra nella riunione con tre chiari punti di discussione. Nel momento in cui i giocatori si dirigono verso le battute di pratica, i primi due giri nell'ordine non sono congetture; sono ancorati a una visione condivisa di come lo starter di stasera lancia effettivamente.

Preparazione bullpen pre-serie

Scripting dei cambi di lancio con Agent Framework e Model Serving

Lo staff sa che ci sarà un momento nella maggior parte delle partite in cui lo starter sarà vicino ai 100 lanci e il cuore dell'ordine si avvicinerà. La scelta tra un sinkerballer e un destrorso slider-first sembrerà una decisione istintiva sul momento, ma il lavoro avviene prima.

Nello spogliatoio prima della serie, l'analista utilizza un Multi-Agent Supervisor, costruito con Agent Bricks e distribuito su Model Serving, per simulare le situazioni che interessano allo staff: cuore dell'ordine nel sesto inning, parte bassa del settimo, cluster con molti mancini negli inning avanzati.

Per ogni decisione, l'agente:

1. Risolve i nomi dei battitori pertinenti in ID utilizzando una funzione di lookup in Unity Catalog.
2. Chiama le funzioni SQL UC che calcolano gli esiti del tipo di lancio e della posizione per conteggio, mano e stato del corridore in base.
3. Confronta l'arsenale di ogni rilievo con quel gruppo di battitori e spiega quali profili funzionano meglio e perché, in un linguaggio di baseball semplice.

L'analista trasforma questo in una breve scheda bullpen. Ad esempio:

• “Se questi tre battitori devono entrare in battuta e lo starter sta stancando, il destrorso slider-first è favorito; ecco come il suo mix ha funzionato in situazioni simili.”
• “Se la parte bassa dell'ordine deve entrare in battuta, il profilo di palle a terra del sinkerballer vince più spesso; ecco le prove.”

Lo staff stampa la scheda e la esamina insieme. Quando la situazione effettiva del sesto inning si presenta durante la partita, nessuno sta accedendo a Databricks. L'allenatore di lancio sta seguendo un albero decisionale che lo staff ha già testato sotto pressione con l'agente ore prima.

Offensiva negli inning avanzati

Pianificazione delle decisioni di pinch-hit con lo stesso agente e gli stessi strumenti

Le scelte di pinch-hit nell'ottavo inning vengono provate allo stesso modo.

Come parte della preparazione pre-partita, l'analista chiede all'agente Databricks:

“Per i probabili rilievi degli inning avanzati che vedremo in questa serie, classifica i nostri battitori di panchina per esito atteso e spiega quando ciascuno è l'opzione migliore.”

L'agente chiama le stesse funzioni UC e le tabelle Delta in Unity Catalog per:

• Combinare il pattern di utilizzo di ogni rilievo con gli esiti di ogni battitore di panchina per tipo di lancio, posizione e conteggio.
• Simulare probabili scenari di fine partita, come corridori in prima e seconda, un eliminato, contro un rilievo destrorso che si affida ai cutter.
• Produrre indicazioni chiare, come: “Contro il Rilievo X, il Battitore A ha un profilo migliore con corridori in base, mentre il Battitore B è più adatto in situazioni di basi vuote quando si affida ai sinker.”

L'analista inserisce queste raccomandazioni nella scheda di gioco del manager o in una piccola griglia di pinch-hit di una pagina che può essere rivista in anticipo. Una volta iniziata la partita, la scheda diventa il punto di riferimento. Il manager sta scegliendo tra opzioni che ha già esaminato, con i dati distillati in un formato che rispetta le regole della lega sui dispositivi nella dugout.

Giorno di viaggio

Scouting avanzato con Vector Search e Unity Catalog

Nel giorno di riposo tra una serie e l'altra, l'analista passa dalle tattiche di una singola partita a ciò che verrà dopo. Due starter in arrivo hanno una storia diretta limitata contro la lineup.

Di nuovo in Genie, chiede:

“Trova lanciatori i cui arsenali e profili di movimento sono più simili ai nostri starter in arrivo, quindi mostra come la nostra lineup si è comportata contro quei lanciatori comparabili.”

Qui, Genie affida parte del lavoro a Databricks Vector Search. Embedding di lanciatori e battitori, memorizzati in Unity Catalog da elaborazioni precedenti, vengono indicizzati in modo che il sistema possa trovare “lancatori simili” senza indovinare a occhio.

Il flusso di lavoro è:

1. Genie analizza il mix di lanci e il movimento dei nuovi starter dalle tabelle di Unity Catalog.
2. Vector Search trova lanciatori con profili di lancio simili.
3. Le funzioni SQL UC calcolano gli esiti della lineup contro quei lanciatori comparabili.
4. Genie riassume i pattern in un rapporto di scouting che l'allenatore di battuta può utilizzare.

Quando la storia Statcast testa a testa è scarsa, questa combinazione di Vector Search e Genie offre allo staff un modo per dire: “Ecco come abbiamo battuto lanciatori che assomigliano a questo”, e integrarlo nel piano della serie. Queste intuizioni vengono poi esportate nel rapporto di scouting, pronte per la prossima riunione in trasferta.

Giorno front office

GM e analisti con Genie, Lakehouse e Lakebase

Le stagioni vincenti si costruiscono su più di una partita. Il GM e gli analisti utilizzano la stessa piattaforma per prendere decisioni su valore, adattamento e rischio.

In Genie, esplorano domande come:

“Mostra come il profilo del nostro terzo starter si comporta contro le migliori lineup della nostra divisione per conteggio e mano. Da dove viene il suo valore e dove siamo esposti?”

“Per i battitori mancini in tutta la lega, identifica i giocatori i cui punti di forza corrispondono a come viene lanciato nella nostra divisione negli inning avanzati.”

Queste domande trovano risposta direttamente dal lakehouse in Unity Catalog. Dati a livello di lancio, embedding e feature derivate sono tutti governati in un unico posto. Genie li trasforma in risposte in linguaggio naturale, ma sotto il cofano la logica sono ancora funzioni SQL UC riutilizzabili.

Nel frattempo, l'app delle operazioni di baseball che allenatori, scout e front office utilizzano è supportata da Lakebase Postgres. Quell'app è dove:

• Gli scout inseriscono rapporti su potenziali obiettivi di scambio.
• Gli allenatori taggano decisioni di livello superiore, come “È andato slider-first nel sesto inning contro il cuore dell'ordine”, dopo la partita.
• Il GM registra le decisioni finali su scambi, estensioni e mosse del roster.

Poiché Lakebase Postgres fa parte della piattaforma Databricks, lo stato dell'app viene mantenuto vicino ai dati sorgente:

• Le scritture dell'app (rapporti, tag, decisioni) vanno in Lakebase Postgres e sono immediatamente disponibili ad analisti e agenti che hanno accesso.
• Job o pipeline pianificati pubblicano fette curate di tabelle di Unity Catalog in Lakebase Postgres, in modo che l'interfaccia utente dell'app abbia sempre le ultime statistiche e feature senza esportazioni CSV manuali.

Il risultato è una memoria condivisa. Cosa è successo, perché è successo e come è stato giustificato sono memorizzati in un unico posto, con timestamp e identità dell'utente.

Perché questo vince partite

• Scommesse sul roster più intelligenti: le mosse dei giocatori si allineano a come viene lanciato nella lega, specialmente nella divisione e in ottobre.
• Apparizioni al piatto di qualità superiore: i battitori sanno cosa lancia effettivamente un lanciatore in quel momento, non cosa lancia in generale.
• Confronti bullpen più puliti: le migliori situazioni di ogni rilievo sono evidenti in pochi secondi, riducendo le congetture sotto pressione dell'orologio.
• Meno lanci sprecati in situazioni critiche: conoscere il lancio decisivo per battitore e conteggio riduce i conteggi lunghi e le basi su ball gratuite.
• Migliori risultati al primo lancio: i piani d'attacco che invertono le scelte previste creano contatti precoci alle condizioni della squadra.

Tutto questo ha importanza solo se i numeri sono corretti. Eseguendo questi agenti e applicazioni su un unico lakehouse governato invece di strumenti sparsi e monouso, i club possono verificare che la logica corrisponda al lavoro che già svolgono e farvi affidamento nei momenti cruciali. Quando i dati indicano un abbinamento o una mossa specifica, sembra un'estensione del piano di gioco, non una scatola nera.

Scopri di più su Databricks Sports, o richiedi una demo per vedere come la tua organizzazione può ottenere insight competitivi.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale