Comment Databricks aide les équipes de baseball à prendre l'avantage grâce aux données et à l'IA

Le baseball évolue rapidement, défini par de petits moments : un lancer, une confrontation, une décision. Cette histoire montre comment un vestiaire moderne utilise Databricks pour transformer des données de lancer haute fidélité en décisions qui aident à gagner des matchs.

Jour de match, 14h00

Réunion des frappeurs avec Genie et Unity Catalog

Les frappeurs entrent dans la salle vidéo. L'entraîneur ne veut pas d'un imprimé de 30 pages ; il veut un plan clair pour le lanceur partant de ce soir.

Plus tôt dans la journée, l'analyste s'est assis à son ordinateur portable et a ouvert Genie, au-dessus de Unity Catalog, où vivent les tables Statcast et celles dérivées de l'équipe avec des schémas, des autorisations et une lignée cohérents. Il a demandé :

« Pour le lanceur partant de ce soir, montrez le mix et les emplacements des premiers lancers à nos frappeurs droitiers et gauchers au cours des deux dernières saisons. Mettez en évidence les tendances lorsque des coureurs sont sur les bases. »

Genie a compilé la réponse à partir de tables Delta gouvernées dans Unity Catalog. Dans le cadre de ce travail, l'analyste a également enregistré un ensemble de fonctions SQL Unity Catalog qui encapsulent les requêtes clés, telles que les tendances par compte, main et état du coureur de base, afin qu'il puisse les réutiliser dans la planification future et dans les agents automatisés.

L'analyste a exporté les résultats dans un simple document d'une page que le personnel pouvait imprimer ou inclure dans les classeurs des frappeurs. Les points clés étaient :

• Droitiers : cutters et quatre-coutures fréquents en début de compte, surtout lorsque les bases sont vides.
• Gauchers : plus de changements de vitesse et de sinkers lorsqu'il y a un coureur au deuxième but.
• Deux prises : le slider bas et à l'extérieur apparaît dans la plupart des retraits importants.

L'entraîneur de frappeurs entre dans la réunion avec trois points de discussion clairs. Au moment où les joueurs se dirigent vers la séance d'entraînement au bâton, les deux premières rotations ne sont pas des suppositions ; elles sont ancrées dans une vision partagée de la façon dont le lanceur partant de ce soir lance réellement.

Préparation du bullpen avant la série

Scripting des changements de lanceurs avec Agent Framework et Model Serving

Le personnel sait qu'il y aura un moment dans la plupart des matchs où le lanceur partant sera proche de 100 lancers et que le cœur de l'ordre arrivera. Le choix entre un lanceur de sinker et un droitier axé sur le slider semblera être une décision instinctive sur le moment, mais le travail se fait plus tôt.

Dans le vestiaire avant la série, l'analyste utilise un Multi-Agent Supervisor, construit avec Agent Bricks et déployé sur Model Serving, pour simuler les situations que le personnel juge importantes : le cœur de l'ordre en sixième manche, le bas du tiers en septième, les groupes majoritairement gauchers en fin de match.

Pour chaque décision, l'agent :

1. Résout les noms des frappeurs pertinents en ID à l'aide d'une fonction de recherche dans Unity Catalog.
2. Appelle les fonctions SQL UC qui calculent les résultats des types de lancers et des emplacements par compte, main et état du coureur de base.
3. Compare l'arsenal de chaque releveur à ce groupe de frappeurs et explique quels profils fonctionnent le mieux et pourquoi, en langage de baseball simple.

L'analyste transforme cela en une courte carte de bullpen. Par exemple :

• « Si ces trois frappeurs sont dus et que le lanceur partant fatigue, le droitier axé sur le slider est favorisé ; voici comment son mix a fonctionné dans des situations similaires. »
• « Si le bas du tiers est dû, le profil de balle au sol du lanceur de sinker gagne plus souvent ; voici les preuves. »

Le personnel imprime la carte et l'examine ensemble. Lorsque la situation réelle de la sixième manche apparaît pendant le match, personne ne se connecte à Databricks. L'entraîneur des lanceurs suit un arbre de décision que le personnel a déjà testé sous pression avec l'agent des heures auparavant.

Offensive en fin de match

Planification des décisions de coup sûr de remplacement avec le même agent et les mêmes outils

Les choix de coup sûr de remplacement en huitième manche sont répétés de la même manière.

Dans le cadre de la préparation d'avant-match, l'analyste demande à l'agent Databricks :

« Pour les releveurs probables en fin de match que nous verrons dans cette série, classez nos frappeurs de banc par résultat attendu, et expliquez quand chacun est la meilleure option. »

L'agent appelle les mêmes fonctions UC et tables Delta dans Unity Catalog pour :

• Combiner le schéma d'utilisation de chaque releveur avec les résultats de chaque frappeur de banc par type de lancer, emplacement et compte.
• Simuler des scénarios probables de fin de match, tels que des coureurs en première et deuxième, un retrait, face à un releveur droitier qui utilise beaucoup de cutters.
• Produire des conseils simples, tels que : « Contre le releveur X, le frappeur A a un meilleur profil avec des coureurs sur les buts, tandis que le frappeur B convient mieux dans les situations de bases vides lorsqu'il utilise des sinkers. »

L'analyste intègre ces recommandations dans la carte de match du manager ou dans une petite grille de coup sûr de remplacement d'une page qui peut être examinée à l'avance. Une fois le match commencé, la carte devient le point de référence. Le manager choisit parmi des options qu'il a déjà examinées, les données étant distillées dans un format qui respecte les règles de la ligue concernant les appareils dans le dugout.

Jour de voyage

Scouting avancé avec Vector Search et Unity Catalog

Pendant le jour de repos entre les séries, l'analyste passe des tactiques de match unique à ce qui s'en vient. Deux lanceurs partants à venir ont peu d'historique direct contre la formation.

De retour dans Genie, il demande :

« Trouvez les lanceurs dont les arsenaux et les profils de mouvement sont les plus similaires à nos lanceurs partants à venir, puis montrez comment notre formation s'est comportée contre ces lanceurs comparables. »

Ici, Genie confie une partie du travail à Databricks Vector Search. Les plongements de lanceurs et de frappeurs, stockés dans Unity Catalog à partir de traitements antérieurs, sont indexés afin que le système puisse trouver des « lanceurs similaires » sans deviner à l'œil.

Le flux de travail est le suivant :

1. Genie analyse le mix de lancers et le mouvement des nouveaux partants à partir des tables Unity Catalog.
2. Vector Search trouve des lanceurs avec des profils de lancer similaires.
3. Les fonctions SQL UC calculent les résultats de la formation contre ces lanceurs comparables.
4. Genie résume les tendances dans un rapport de scouting que l'entraîneur de frappeurs peut utiliser.

Lorsque l'historique Statcast en confrontation directe est limité, cette combinaison de Vector Search et de Genie donne au personnel un moyen de dire : « Voici comment nous avons frappé les lanceurs qui ressemblent à ceci », et de l'intégrer dans le plan de la série. Ces informations sont ensuite exportées dans le rapport d'avance, prêtes pour la prochaine réunion sur la route.

Jour de bureau des cadres

GM et analystes avec Genie, Lakehouse et Lakebase

Les saisons gagnantes ne se construisent pas sur un seul match. Le GM et les analystes utilisent la même plateforme pour prendre des décisions concernant la valeur, l'adéquation et le risque.

Dans Genie, ils explorent des questions telles que :

« Montrez comment le profil de notre lanceur partant numéro trois se compare aux meilleures formations de notre division par compte et main. D'où vient sa valeur et où sommes-nous exposés ? »

« Pour les frappeurs gauchers dans la ligue, identifiez les joueurs dont les forces correspondent à la façon dont notre division est lancée en fin de match. »

Ces questions sont répondues directement à partir du lakehouse dans Unity Catalog. Les données au niveau du lancer, les plongements et les caractéristiques dérivées sont tous gouvernés en un seul endroit. Genie les transforme en réponses en langage naturel, mais sous le capot, la logique reste des fonctions SQL UC réutilisables.

Pendant ce temps, l'application des opérations de baseball que les entraîneurs, les recruteurs et le bureau des cadres utilisent est alimentée par Lakebase Postgres. C'est dans cette application que :

• Les recruteurs saisissent des rapports sur les cibles commerciales potentielles.
• Les entraîneurs étiquettent les décisions de haut niveau, telles que « Utilisation du slider en premier en sixième manche contre le cœur de l'ordre », après le match.
• Le GM enregistre les décisions finales sur les échanges, les prolongations et les mouvements de roster.

Étant donné que Lakebase Postgres fait partie de la plateforme Databricks, l'état de l'application est maintenu à proximité des données sources :

• Les écritures de l'application (rapports, étiquettes, décisions) vont dans Lakebase Postgres et sont immédiatement disponibles pour les analystes et les agents qui y ont accès.
• Les tâches planifiées ou les pipelines publient des tranches sélectionnées de tables Unity Catalog dans Lakebase Postgres, de sorte que l'interface utilisateur de l'application dispose toujours des dernières statistiques et caractéristiques sans exportations manuelles de CSV.

Le résultat est une mémoire partagée. Ce qui s'est passé, pourquoi cela s'est passé et comment cela a été justifié sont stockés en un seul endroit, avec des horodatages et l'identité de l'utilisateur.

Pourquoi cela fait gagner des matchs

• Des paris plus intelligents sur le roster : les mouvements de joueurs s'alignent sur la façon dont la ligue lance, en particulier dans la division et en octobre.
• Des apparitions au bâton de meilleure qualité : les frappeurs savent ce qu'un lanceur lance réellement à ce moment-là, pas ce qu'il lance en général.
• Des confrontations de bullpen plus claires : les meilleures situations de chaque releveur sont évidentes en quelques secondes, réduisant les conjectures sous la pression du chronomètre.
• Moins de lancers gaspillés dans les situations critiques : connaître le lancer décisif par frappeur et par compte réduit les comptes longs et les passes gratuites.
• De meilleurs résultats sur le premier lancer : les plans d'attaque qui inversent les choix attendus créent un contact précoce aux conditions de l'équipe.

Tout cela n'a d'importance que si les chiffres sont corrects. En exécutant ces agents et applications sur un lac de données unique et gouverné au lieu d'outils disparates, les clubs peuvent constater que la logique correspond au travail qu'ils effectuent déjà et s'y fier dans les moments clés. Lorsque les données indiquent un affrontement ou un mouvement spécifique, cela ressemble à une extension du plan de jeu, pas à une boîte noire.

En savoir plus sur Databricks Sports, ou demander une démo pour voir comment votre organisation peut générer des informations concurrentielles.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original