Réglages réels de Michel, tels qu'ils sont dans le code| Bibliothèque | LightGBM, développée par Microsoft |
|---|
| Objectif d'optimisation | binary — une probabilité de victoire par partant |
|---|
| Métrique suivie | AUC |
|---|
| Structure | 500 arbres, 63 feuilles au maximum, 20 partants minimum par feuille |
|---|
| Pas d'apprentissage | 0,05 |
|---|
| Échantillonnage | 80 % des variables et 80 % des lignes à chaque arbre |
|---|
| Déséquilibre | corrigé par pondération — il y a environ un gagnant pour dix perdants |
|---|
| Matériel | carte graphique si CUDA répond, repli automatique sur le processeur |
|---|
Le gradient boosting empile des arbres de décision peu profonds : chacun corrige les erreurs de la somme des précédents. Ici, chaque arbre pose des questions du type « la cote est-elle sous 6 ? », « le driver a-t-il plus de 12 % de victoires ? », et affine un score qui se termine en probabilité entre 0 et 1.
Le problème n'est pas dans le modèle, il est dans l'objectif. Optimiser `binary`, c'est apprendre à bien répondre « ce cheval gagne-t-il ? ». Ce n'est pas la même question que « ce cheval est-il payé plus cher que ce qu'il vaut ? ». Un modèle parfaitement calibré sur la première question perd exactement le prélèvement de l'opérateur sur la seconde. C'est l'essentiel de ce qui sépare Michel de la rentabilité.
Ce que les dix ont en commun
Tous apprennent sur le même corpus : 147 095 courses et 1 824 611 partants depuis 2015, décrits par 38 variables — cote de référence, forme récente lue dans la musique, taux de réussite du jockey et de l'entraîneur, allocation, distance, corde, poids, déferrage, âge, sexe, jours depuis la dernière sortie, et le reste.
Le jeu d'entraînement complet — 1,8 million de partants sur 38 variables — occupe environ 550 Mo une fois chargé en mémoire, avant l'empreinte des structures de calcul. C'est ce qui fixe le besoin réel : de la RAM, pas de la puissance brute.
L'entraînement tente d'abord la carte graphique (CUDA) et bascule seul sur le processeur si elle n'est pas disponible : le modèle obtenu est le même, seul le temps de calcul change. Les fichiers produits sont légers — de 1 à 4,6 Mo selon le modèle — et tiennent tous dans un dossier de quelques dizaines de mégaoctets.
La prédiction quotidienne, elle, ne demande aucun matériel particulier : charger les dix modèles et noter toutes les courses d'une journée prend quelques secondes sur un processeur ordinaire. Le coût du projet est dans la donnée et son historique, pas dans le calcul.
Les prédictions et les résultats vivent dans une base Postgres ; les campagnes d'évaluation sont rejouées dans un fichier analytique local de 347 Mo, sur disque SSD — la validation glissante relit des millions de lignes par passe et le débit disque devient le facteur limitant bien avant le processeur.
Ce que nous ne publions pas : la recette exacte d'entraînement et le détail de la construction des variables. Au pari mutuel, une sélection suivie par trop de monde fait s'effondrer sa propre cote — la preuve du sérieux est dans le journal des paris, pas dans la recette.