From Programs to Predictions: A Scalable, Multilingual Platform for Automated Evaluation of Machine-Learning Olympiads

Imaginez que vous soyez à une compétition culinaire massive et à enjeux élevés, mais qu'au lieu de présenter un plat fini pour être goûté, les candidats vous envoient une fiche de recette secrète contenant une liste de saveurs prédites. Dans l'ancien temps, les concours d'informatique étaient comme une dégustation stricte : vous soumettiez un programme, le juge l'exécutait, et si la sortie ne correspondait pas exactement à la clé de réponse, vous échouiez. Mais dans ce nouveau monde des « Olympiades de Machine Learning », les règles ont changé. Les juges ne se soucient pas de savoir si le code s'exécute parfaitement ; ils se soucient de savoir si les prédictions sont assez proches de la vérité, en utilisant des règles de notation étranges et personnalisées qui changent pour chaque problème.

Voici MLCompete, une plateforme numérique conçue pour gérer ce défi de saveurs chaotique et à haute vitesse. C'est l'arbitre officiel de l'Olympiade Nationale d'IA de Roumanie, et il fait quelque chose que presque aucun autre système ne fait : il permet à des milliers d'étudiants de concourir, de soumettre leurs « prédictions de saveurs » et d'être évalués instantanément, même lorsque les règles de notation sont aussi uniques que des flocons de neige.

Le Grand Changement : Passer de l'Exécution de Code à la Notation de Suppositions

L'article soutient que vous ne pouvez pas simplement prendre un vieux juge informatique et le détourner. C'est comme essayer d'utiliser un chronomètre pour mesurer le goût d'une soupe. Les anciens systèmes attendent qu'un programme finisse de s'exécuter et recrache une réponse. MLCompete, cependant, réalise que dans les concours d'IA, le plus gros du travail se fait avant la soumission. Les étudiants entraînent leurs modèles ailleurs (ou sur la plateforme), puis téléchargent un fichier rempli de prédictions. Le rôle de la plateforme est de prendre ce fichier, de le comparer à une « clé de réponse » cachée (vérité de terrain ou ground truth), et de calculer un score en utilisant une métrique qui peut être spécifique à ce problème précis.

Les auteurs excluent explicitement l'idée qu'il s'agisse simplement d'une « version plus grande » d'un concours de programmation standard. Ils affirment que l'infrastructure doit être fondamentalement différente car ce qui est livré n'est pas un programme, mais un ensemble de prédictions, et que la notation n'est pas « juste ou faux », mais une échelle glissante de la qualité de la supposition.

Comment cela fonctionne : La Chaîne de Montage

Voyez MLCompete comme une ligne de production automatisée et ultra-efficace.

1. Le Dépôt : Lorsque un étudiant télécharge son fichier de prédiction, le système ne le fait pas attendre. C'est comme un service de courrier intelligent qui tamponne instantanément votre colis avec la mention « Reçu » et dit : « Nous nous en occupons dans un instant ». C'est la partie asynchrone. L'étudiant peut aller jouer à un jeu pendant que le vrai travail se déroule en arrière-plan.
2. La File d'Attente : La soumission est déposée dans une file d'attente numérique (une file de messages). C'est l'ingrédient secret. Cela signifie que si 1 000 étudiants soumettent au même instant, le système ne plante pas ; il les aligne simplement.
3. L'Équipe de Notation : Une équipe de travailleurs invisibles (appelés « évaluateurs ») saisit le fichier suivant dans la file, exécute le script de notation spécifique (qui peut être une formule mathématique standard ou un script personnalisé écrit par l'auteur du problème), et calcule le score.
4. Le Résultat : Une fois le score prêt, le système le renvoie sur l'écran de l'étudiant en quasi temps réel.

L'article montre que cette configuration est incroyablement rapide. Sur une fenêtre de 15 jours, le système a géré plus de 8,1 millions de requêtes. Le backend (le cerveau de l'opération) était si rapide que 95 % du temps, il répondait en moins de 255 millisecondes. C'est plus rapide qu'un clin d'œil.

Le Tableau de Bord à « Deux Phases »

Voici une partie délicate que l'article explique avec une astuce ingénieuse pour empêcher la triche. Imaginez un classement qui vous montre comment vous vous en sortez en ce moment, mais qui ne repose que sur une petite tranche publique des questions de test. Cela maintient l'engagement des étudiants. Mais le vrai classement final est basé sur une tranche de questions secrètes et privées que personne n'a vues.

La plateforme calcule les deux scores en une seule opération. Cela empêche les étudiants de « manipuler le système » en soumettant des milliers de fois pour voir laquelle des soumissions touche accidentellement les réponses secrètes. Pour gagner, un étudiant doit explicitement choisir ses deux meilleures soumissions avant la date limite. Le système prend ensuite la meilleure de ces deux soumissions sur le classement secret. Cela force les étudiants à faire confiance à leur meilleur travail plutôt qu'à spammer le système.

La « Salle de Sécurité » pour le Code

Parfois, les étudiants doivent exécuter leur propre code directement sur les supercalculateurs de la plateforme pour générer leurs prédictions. Cela est dangereux car vous ne voulez pas que le code buggé d'un étudiant vole des données ou fasse planter tout le système.

L'article décrit un modèle de sécurité de « défense en profondeur ». Pour l'étape la plus avancée (le Camp de Sélection de l'Équipe Nationale), les étudiants ont accès à de puissants GPU NVIDIA H200. Mais voici la magie : la plateforme utilise une technologie appelée MIG (Multi-Instance GPU) pour découper un énorme GPU en cinq morceaux plus petits et isolés. Chaque étudiant reçoit sa propre petite tranche de mémoire et de puissance de calcul. C'est comme donner à chaque candidat sa propre cabine privée et insonorisée dans une immense bibliothèque. Même si le code d'un étudiant devient incontrôlable, il ne peut pas toucher aux données des autres ni au reste de l'ordinateur.

Pour s'assurer qu'ils ne trichent pas en cherchant des réponses en ligne, la plateforme utilise un « proxy de liste blanche ». C'est comme un bibliothécaire strict qui ne vous laisse lire que des livres issus d'une liste pré-approuvée. Pendant le concours, les étudiants ne peuvent communiquer qu'avec la plateforme, leur fournisseur d'identité et l'environnement de codage Jupyter. Internet, les hubs de modèles publics et les sites web aléatoires sont complètement bloqués.

Les Chiffres : Quel est le Résultat ?

Les auteurs n'ont pas seulement construit cela ; ils l'ont testé dans le feu d'une véritable compétition nationale.

• Fiabilité : Le système était opérationnel de manière presque parfaite. Le taux d'erreur du serveur était d'un infime 0,007 %. Cela signifie que sur 10 000 requêtes, environ 7 ont échoué.
• Coût : Ils ont géré tout cela sur un seul serveur informatique modeste (un « nœud K3s de commodité ») pour le trafic quotidien régulier. C'est comme gérer un immense parc d'attractions avec un seul guichet qui n'ouvre de nouvelles fenêtres que lorsque la foule s'agrandit.
• Le Pic : Pendant le Camp de Sélection de l'Équipe Nationale, le trafic a bondi de 3 à 6 fois par rapport à la normale. Le système a absorbé ce pic sans ralentir ni planter, grâce à sa capacité à ajouter automatiquement plus de « travailleurs » lorsque la file s'allongeait.
• Scalabilité (Évolutivité) : Les auteurs ont effectué des simulations (des modèles informatiques, pas des tests réels) pour voir ce qui se passerait si des centaines d'étudiants soumettaient en même temps. Ils ont découvert qu'avec un groupe de seulement 10 travailleurs, le système pouvait gérer jusqu'à 5 soumissions par seconde avec un temps d'attente quasi nul. Si la file devenait plus longue, le système ajoutait simplement plus de travailleurs automatiquement.

Ce qu'il n'est pas

L'article prend soin de préciser ce qu'il n'a pas encore prouvé. Les auteurs admettent que leurs données réelles ne couvrent que la fenêtre de 15 jours, qui incluait un pic de concours « modeste » mais a manqué les grandes étapes du « printemps » où des centaines d'étudiens concourent. Ainsi, bien que le système ait parfaitement géré le pic du camp de sélection de l'équipe, les auteurs suggèrent (plutôt que de prouver) qu'il pourrait passer à l'échelle supérieure pour les événements les plus vastes. Ils notent également que bien qu'ils aient une sécurité solide, ils travaillent encore sur un « sandboxing » (bac à sable) au niveau du noyau (kernel-level) pour rendre l'exécution du code absolument inviolable face aux hackers les plus déterminés.

La Conclusion

MLCompete prouve que l'on peut construire une plateforme massive, multilingue, sécurisée et peu coûteuse pour les concours d'IA en traitant les prédictions comme du courrier et la notation comme une ligne de montage d'usine. Ce n'est pas une baguette magique qui résout tous les problèmes d'IA, mais c'est un plan de travail concret et fonctionnel qui permet aux étudiants de se concentrer sur l'apprentissage et la compétition, plutôt que de s'inquiéter de savoir si l'ordinateur va planter. Comme le conclut l'article, l'architecture fonctionne, et les données le confirment, offrant une nouvelle façon de gérer l'avenir de l'éducation en IA.