John McDonald, alors ingénieur chez Valve et aujourd'hui programmeur là-bas après plus de 12 ans passés dans l'entreprise, a présenté cette conférence à GDC en mars 2018, en expliquant comment Valve a construit VACNet, un système d'apprentissage profond conçu pour détecter la triche dans Counter-Strike: Global Offensive. La conférence couvre la motivation derrière le projet, le pipeline de données qui l'a rendu possible, l'infrastructure nécessaire pour le faire fonctionner à grande échelle, et les principes de conception qui l'ont rendu durable face à l'adaptation adverse.

Cet article se concentre spécifiquement sur l'architecture anti-triche. Voyez-le comme une étude de cas d'apprentissage profond appliqué à un environnement en direct et adversarial, avec des leçons qui s'appliquent à tout jeu multijoueur confronté à un problème de triche.

Une remarque sur le calendrier : cette conférence date d'avant Counter-Strike 2, qui a remplacé CS:GO comme jeu en service en septembre 2023. Le cas échéant, nous préciserons comment le système a évolué depuis.

Le tapis roulant : pourquoi Valve voulait en descendre

L'anti-triche traditionnelle consiste à écrire des règles manuellement. Un ingénieur identifie une triche, rédige une détection, la déploie, puis les acteurs malveillants la contournent. Ensuite on recommence. McDonald avait un nom pour cela : « le tapis roulant du travail ». Un travail précieux, reconnaissait-il, mais un engagement sans ligne d'arrivée.

CS:GO rendait cela pire que la plupart des jeux. Environ 75–80 % de sa base de code n'avait pas changé depuis Half-Life 2, ce qui signifiait qu'une triche écrite en 2005 pour le deathmatch de Half-Life 2 fonctionnerait encore sur CS:GO avec seulement cinq à dix minutes de modifications environ. La surface d'attaque était énorme. Et chaque divulgation publique d'une technique de détection l'invalidait immédiatement. Les développeurs de triches regardaient, et la méthode cessait de fonctionner avant la fin du flux de la conférence.

McDonald a décrit ainsi la proposition faite à Valve en 2016 : des humains qui regardent des matchs peuvent dire qu'il y a de la triche. Ils détectent un schéma. L'apprentissage profond est très bon pour détecter des schémas. Si vous disposez de suffisamment d'exemples étiquetés d'entrées (données de match) et de sorties (verdicts), vous pouvez entraîner un modèle à faire la correspondance entre les deux. Les ingénieurs qui écrivent l'anti-triche traditionnelle écrivaient en fait cette correspondance à la main. L'apprentissage profond pouvait la construire automatiquement. L'échange : des données et du calcul contre du temps d'ingénierie. Chez Valve, ils manquaient perpétuellement d'ingénieurs et disposaient de beaucoup des deux.

Le déclic : vos données étiquetées existent peut-être déjà

La question centrale dans tout projet d'apprentissage profond supervisé est de savoir d'où viennent les données d'entraînement. Construire un pipeline d'étiquetage à partir de zéro est coûteux et lent. Valve avait un raccourci sous les yeux.

CS:GO faisait fonctionner depuis 2012 un système anti-triche d'évaluation par les pairs appelé Overwatch. Des joueurs de confiance se voyaient attribuer des dossiers (une démo anonymisée de huit rounds d'un joueur signalé) et devaient voter pour dire si une triche avait eu lieu. Les verdicts exigeaient une confiance d'environ 99,8 % telle que mesurée par un modèle de Naive Bayes sur les votes des jurés. En pratique, les condamnations atteignaient généralement une certitude de cinq neufs. Les jurés étaient extrêmement prudents, opérant selon un standard de « au-delà du doute raisonnable ».

Ce système fonctionnait depuis des années. Sans que personne ne l'ait explicitement conçu comme tel, il était devenu une grande base de données d'exemples d'entraînement étiquetés : des fichiers de démonstration associés à des verdicts humains. Ils avaient X et Y. Ils ne les avaient simplement pas encore utilisés.

La leçon mérite qu'on s'y arrête. Avant d'investir dans un pipeline d'étiquetage, il vaut la peine de se demander si votre jeu possède déjà quelque part un ensemble de données étiquetées que vous n'avez pas encore reconnu comme tel. Des files de modération avec des issues résolues, des signalements de joueurs avec des bannissements confirmés, des systèmes d'évaluation par les pairs. Cela peut être des données d'entraînement déguisées.

Trust Score : limiter le rayon d'impact

Avant VACNet, Valve avait construit un outil distinct pour le problème de triche : Trust Score, lancé en 2016. Il mérite sa propre section car il résout un problème différent.

Trust Score est un modèle entraîné sur la manière dont les joueurs interagissent avec CS:GO et avec la plateforme Steam au sens large, et il prédit la probabilité d'un bannissement futur. Ce score alimente le matchmaking comme signal supplémentaire, aux côtés du niveau de compétence et des préférences de carte, en regroupant ensemble les joueurs ayant des niveaux de confiance similaires.

McDonald était clair sur ce que Trust Score fait et ne fait pas : il « ne réduit pas le taux de triche », a-t-il dit. Il réduit « le rayon d'impact ». Les joueurs honnêtes rencontrent des tricheurs beaucoup moins souvent. Les acteurs malveillants soupçonnés se retrouvent dans des lobbies entre eux. Les tricheurs sont toujours dans le jeu ; ils ne sont simplement pas dans votre partie.

En tant que schéma de conception, c'est une distinction utile. Détecter et bannir les tricheurs est un levier. Limiter les personnes qu'ils peuvent affecter pendant que la détection et le bannissement se déroulent en est un autre. Ils fonctionnent indépendamment et contribuent tous deux à l'expérience joueur.

Le vrai travail, c'est l'ingénierie des données

McDonald utilisait une analogie culinaire qui est restée : l'apprentissage profond est le hachoir à viande. Vos données de jeu brutes sont la vache. Le vrai travail consiste à transformer la vache en entrées uniformes, correctement dimensionnées, que le hachoir peut traiter. C'est là que se trouve presque tout l'effort.

Il estimait la répartition à 95 % d'ingénierie des données, environ 1 % d'entraînement du modèle, et 4 % pour tout le reste. Et surtout, l'ingénierie des données est du travail d'ingénierie standard. Analyser les fichiers de relecture. Extraire les caractéristiques de chaque tir. Construire des séquences d'entrée de taille fixe et structurées de manière cohérente. Rien de tout cela ne nécessite d'expertise en apprentissage profond. Ce n'est qu'un travail de pipeline à grande échelle.

Pour VACNet en particulier, chaque unité d'entrée représentait un tir unique et contenait : l'arme utilisée, le résultat du tir (tir en pleine tête, touche ailleurs ou raté), la distance de la cible si une touche avait eu lieu, et les deltas d'angles de visée (le changement image par image de la visée verticale et horizontale depuis une demi-seconde avant le tir jusqu'à un quart de seconde après). Le modèle ingérait des séquences de 140 tirs consécutifs tirées d'une fenêtre de huit rounds et prédisait la probabilité qu'un juré condamne.

Les paramètres spécifiques (140 tirs, les fenêtres d'une demi-seconde et d'un quart de seconde) ont été choisis sans justification analytique forte. « Un peu purement arbitrairement », comme l'a dit McDonald. Le modèle se moque des valeurs exactes. Ce qui compte, c'est que la structure soit cohérente à chaque fois.

Garder les humains dans la boucle du verdict

VACNet n'a pas été construit pour bannir les joueurs. Cette distinction a façonné toute l'architecture.

Le système observe les matchs, identifie les joueurs qu'il pense tricher avec une grande confiance, et soumet ceux-ci comme dossiers à Overwatch. Des jurés humains examinent les cas et rendent un verdict. La culpabilité est toujours déterminée par des personnes. VACNet améliore la qualité de ce que ces personnes voient : les dossiers Overwatch soumis par des humains aboutissaient à des condamnations 15–30 % du temps ; les dossiers soumis par VACNet se convertissaient à 80–95 %.

Le raisonnement était délibéré. Un bannissement VAC est permanent. Il bloque l'accès à 98 % des serveurs CS:GO et marque un compte Steam d'une manière qui ne peut pas être annulée. Prendre cette décision uniquement sur une confiance automatisée, même très élevée, introduit des risques que McDonald n'était pas prêt à accepter, en particulier compte tenu du potentiel de faux positifs sur des cas limites ou des entrées nouvelles. Le modèle signale. Les humains décident.

Pour tout système de jeu où la punition est significative et irréversible, ce principe de conception tient. Le modèle est un outil de triage. Il ne remplace pas la décision finale.

La boucle d'auto-renforcement : pourquoi la divulgation ne la casse pas

Après avoir passé quarante minutes à expliquer exactement comment VACNet fonctionne à une salle de développeurs de jeux, avec une diffusion en direct en cours, McDonald a abordé la question évidente : venait-il de remettre aux développeurs de triches une feuille de route ?

Non. Et la raison est architecturale.

VACNet fonctionne en boucle continue aux côtés d'Overwatch. Il soumet des dossiers, des humains les arbitrent, et ces verdicts alimentent le prochain cycle de réentraînement. Si un développeur de triche apprend les fenêtres temporelles précises analysées par VACNet et essaie de supprimer le signal de triche pendant ces fenêtres, les jurés humains reconnaîtront toujours le comportement comme de la triche et condamneront. Le prochain entraînement intègre ces verdicts. Le modèle apprend le nouveau schéma.

Les tailles de fenêtre elles-mêmes étaient arbitraires. Les élargir nécessite de trouver la commande de réentraînement dans l'historique de votre shell et d'appuyer sur Entrée. Le modèle se réentraîne en environ six heures. Un développeur de triches qui construit un contre-modèle à partir de zéro fait face à des mois de travail et à un problème de données qu'il ne peut pas résoudre : « L'algorithme que vous choisissez en apprentissage profond n'a pas d'importance », a noté McDonald. « Ce qui compte, c'est davantage de données. » Valve disposait de beaucoup plus de données étiquetées que n'importe quel acteur externe ne pourrait en accumuler.

Cette boucle signifie aussi que le système devient plus durable avec le temps, et non l'inverse. Chaque fois qu'un développeur de triches s'adapte, il génère un nouveau comportement que les jurés évaluent. Cette évaluation devient de nouvelles données d'entraînement. Le système se renforce à chaque attaque.

Il convient de noter que l'analyse comportementale côté serveur est un paradigme parmi d'autres, et non le seul. Des outils anti-triche au niveau du code source comme GUARD de Mirror Networking adoptent une approche complémentaire : au lieu de fonctionner comme un processus séparé que les tricheurs peuvent identifier et contourner, GUARD s'intègre directement au code source du jeu et fonctionne selon une philosophie de « détection silencieuse ». Plutôt que de confronter les tricheurs suspectés avec un message de bannissement visible, il signale discrètement l'activité suspecte au serveur de jeu. Le tricheur ne sait pas qu'il a été signalé. Cette asymétrie d'information est le principe. La philosophie sous-jacente est la même que la raison de McDonald de ne pas divulguer les détections de VAC : dès qu'un développeur de triches sait ce que vous cherchez, il commence à le cacher.

Ce qui est venu après

Depuis cette conférence de 2018, VACNet a continué d'évoluer aux côtés du jeu qu'il protège. Lorsque Valve a lancé Counter-Strike 2 en septembre 2023, en remplaçant CS:GO comme titre en service, VACNet est arrivé avec lui, désormais appelé VAC Live et décrit comme la troisième génération du système.

Le changement le plus important par rapport à ce que McDonald décrivait en 2018 est la détection en temps réel. Le VACNet original signalait les joueurs pour examen par Overwatch après la fin d'un match. VAC Live peut désormais annuler une partie en cours au moment même où un tricheur est détecté. Ce passage de l'analyse par lot à l'inférence en direct est exactement la direction que McDonald identifiait en 2018 comme du « travail en cours ».

La boucle d'auto-renforcement qu'il décrivait reste au cœur du fonctionnement du système. Le tapis roulant tourne toujours. Il ne nécessite simplement plus qu'un ingénieur continue d'y marcher.

—

Cet article s'appuie sur la conférence originale de John McDonald à la GDC et la cite, publiée sur la chaîne YouTube GDC Festival of Gaming. Tous les droits sur le contenu original appartiennent à leurs propriétaires respectifs.