Google DeepMind teste des benchmarks d’IA en double aveugle pour résoudre les problèmes de confiance liés à l’évaluation

Les scores des benchmarks d’IA sont de plus en plus difficiles à interpréter lorsque les développeurs de modèles ont pu voir les invites d’évaluation ou lorsque des données de test peuvent entrer dans les pipelines d’entraînement. Google DeepMind teste désormais une évaluation en double aveugle, protégée cryptographiquement, conçue pour empêcher les deux parties de ce processus d’accéder aux informations sensibles de l’autre.

Le pilote, mené avec le Singapore AI Safety Institute et d’autres partenaires, utilise un modèle de la gamme Gemini Flash Lite face à des benchmarks confidentiels. Google affirme que cette approche vise à empêcher la contamination des benchmarks tout en permettant à des évaluateurs indépendants de tester un modèle propriétaire sans en recevoir les poids.

Le projet est important parce que les résultats des benchmarks influencent le choix des modèles, les affirmations de recherche, les décisions d’achat et la supervision de la sécurité. Mais les éléments disponibles couvrent actuellement la méthode d’évaluation, et non un nouveau résultat de performance du modèle. Il n’existe ni score rapporté ni évaluation indépendante montrant si le système améliore la précision mesurée.

Ce que Google teste

Selon le reportage de The Decoder, Google DeepMind utilise Confidential Space de Google Cloud pour créer un environnement protégé pour le pilote. L’installation est conçue pour garder les invites de test externes cachées à Google tout en empêchant les évaluateurs d’inspecter les poids du modèle Gemini.

L’idée centrale est un échange en double aveugle. Une organisation d’évaluation fournit des questions ou des tâches sans les exposer au fournisseur du modèle. Le fournisseur met le modèle à disposition pour les tests sans transférer les poids sous-jacents. Des contrôles cryptographiques vérifient ensuite que les composants convenus s’exécutent dans l’environnement prévu.

Google décrit cela comme la première évaluation en double aveugle d’un modèle d’IA frontière propriétaire, mais cette caractérisation relève d’une affirmation de l’entreprise relayée par The Decoder et non d’un constat sectoriel établi de manière indépendante. Le modèle pilote est Gemini Flash Lite, mais la source disponible ne précise ni la version, ni les tâches du benchmark, ni la taille du test, ni les résultats finaux.

La base technique est Confidential Space, qui fait partie du portefeuille de calcul confidentiel de Google. En principe, le calcul confidentiel peut utiliser des protections matérielles et l’attestation pour limiter ce que les opérateurs peuvent voir à l’intérieur d’une charge de travail protégée. Dans ce cas, l’objectif est de créer une séparation vérifiable entre le modèle et les données d’évaluation.

Pourquoi la contamination des benchmarks est importante

Un benchmark est le plus utile lorsque ses questions sont nouvelles pour le système testé. Si des invites ou des réponses ont figuré dans les données d’entraînement, ou si un modèle a été ajusté spécifiquement pour le test, un score élevé peut refléter une exposition antérieure plutôt qu’une capacité générale de raisonnement ou de réalisation de tâches.

Ce problème est généralement appelé contamination des benchmarks. Il peut survenir accidentellement via des jeux de données publics, un entraînement à l’échelle du web ou des tests internes répétés. Il peut aussi devenir une préoccupation stratégique lorsqu’un benchmark est largement discuté et que les développeurs de modèles ont le temps de s’y optimiser.

Le processus d’évaluation lui-même crée un autre risque. Les organisations externes peuvent hésiter à fournir des invites sensibles à une société de modèles, car cela pourrait exposer des données propriétaires, des informations gouvernementales ou du matériel de test de cybersécurité. Les développeurs de modèles, de leur côté, ne souhaitent généralement pas remettre des poids qui représentent une propriété intellectuelle précieuse.

The Decoder a décrit des garde-fous conventionnels tels que les accords de zéro journalisation et les restrictions contractuelles, mais Google soutient que la protection cryptographique ajoute une couche technique plus robuste. Le système proposé n’élimine pas la nécessité de faire confiance aux logiciels, au matériel et aux procédures opérationnelles. Il vise plutôt à réduire la quantité de confiance placée en un seul participant.

Preuves, affirmations et limites restantes

Les affirmations les plus fortes dans la couverture disponible proviennent de la description du pilote par Google DeepMind. Google dit que sa méthode peut garder les questions de test à l’abri du fournisseur et les poids du modèle à l’abri de l’évaluateur, tout en aidant à empêcher un modèle d’utiliser des questions confidentielles pour optimiser un test spécifique.

Il s’agit d’objectifs de conception, et non de résultats vérifiés de manière indépendante dans le matériau disponible pour ce reportage. The Decoder indique que Google a publié des détails méthodologiques et des résultats dans un rapport technique, mais les éléments fournis n’incluent ni les conclusions de ce rapport ni un audit externe de l’implémentation.

L’utilisation de Gemini Flash Lite limite également ce que l’on peut en déduire. Elle peut montrer que le dispositif d’évaluation fonctionne avec un modèle propriétaire, mais elle n’établit pas que chaque modèle frontière, type de benchmark ou environnement de déploiement peut utiliser le même processus à un coût et à une vitesse raisonnables.

Plusieurs questions pratiques restent ouvertes. Les sources n’indiquent pas combien de temps durent les exécutions d’évaluation, quelle surcharge de calcul Confidential Space introduit, comment les échecs sont gérés ni comment les évaluateurs vérifient que le modèle testé est exactement celui prévu. Elles n’expliquent pas non plus comment la méthode traite les fuites de données avant ou après l’exécution protégée.

Implications pour les créateurs d’IA et les entreprises

Pour les chercheurs en IA, un flux de travail en double aveugle réussi pourrait faciliter la conduite d’évaluations indépendantes sans imposer un choix entre des données de test sensibles et des poids propriétaires. Cela serait particulièrement pertinent pour les évaluations de cybersécurité, les tests gouvernementaux et d’autres évaluations impliquant des informations restreintes.

Pour les fournisseurs de modèles, l’approche pourrait offrir un moyen d’obtenir des résultats externes crédibles tout en limitant l’exposition de leurs systèmes. Elle pourrait aussi réduire les litiges sur la question de savoir si un fournisseur a vu les invites de test avant une évaluation. Cependant, les contrôles cryptographiques ne garantissent pas à eux seuls qu’un benchmark mesure une capacité utile, évite une mauvaise conception des tâches ou prédit les performances en production.

Les acheteurs d’entreprise pourraient en bénéficier si les organisations d’évaluation commencent à publier des résultats de tests protégés plus comparables entre fournisseurs. Une équipe achats pourrait accorder davantage de poids à des évaluations administrées indépendamment qu’à des scores générés par un développeur de modèles à l’aide de procédures non divulguées.

La question commerciale est de savoir si la méthode devient praticable au-delà d’un pilote. L’exécution sécurisée, l’attestation, la reproductibilité et l’accès pour audit peuvent ajouter une complexité opérationnelle. Les petits groupes de recherche peuvent ne pas disposer de l’infrastructure ou du financement nécessaire pour exécuter le même processus, ce qui pourrait concentrer les évaluations de haute confiance entre grands fournisseurs de cloud et de modèles.

Ce qu’il faut surveiller ensuite

Le prochain signal important est le niveau de détail du rapport technique. Les développeurs et évaluateurs devraient chercher une description de l’architecture cryptographique, du processus d’attestation, de la politique de journalisation, des vérifications d’identité du modèle et des modes d’échec.

La reproduction indépendante comptera plus que l’annonce elle-même. Des éléments provenant du Singapore AI Safety Institute ou d’autres organisations participantes pourraient clarifier si la procédure empêche en pratique l’accès du fournisseur aux invites et si l’évaluateur peut confirmer que les poids du modèle restent protégés.

Des résultats issus d’autres familles de modèles et de benchmarks plus sensibles montreront également si la méthode constitue une norme générale d’évaluation ou une démonstration à périmètre restreint. Le coût, la latence et les exigences d’accès détermineront si elle peut être utilisée de manière routinière plutôt que seulement pour des tests très médiatisés.

Point de vue Creati.ai

Le pilote de Google DeepMind s’attaque à une faiblesse réelle du benchmarking de l’IA : les participants doivent souvent se faire confiance pour ne pas inspecter, conserver ou optimiser à partir de matériel d’évaluation sensible. Déplacer une partie de cette confiance vers des contrôles techniques vérifiables est une direction utile, en particulier pour les évaluations de sécurité et gouvernementales.

Mais l’annonce doit être lue comme une expérience d’infrastructure d’évaluation, et non comme la preuve que les scores des benchmarks sont désormais fiables. La valeur de l’approche dépendra d’audits indépendants, de protocoles transparents et de preuves que les tests protégés améliorent la qualité des décisions prises par les chercheurs, les entreprises et les régulateurs.