Alignment Forum propose 4 étapes : la nouvelle génération d'IA seulement après la vérification de l'actuelle

Un post court mais révélateur est paru sur l'AI Alignment Forum. Il décrit le standard minimal de rythme de développement de l'IA que l'industrie pourrait adopter si elle s'accorde non pas sur une pause complète, mais seulement sur un ralentissement. La thèse tient en une phrase : un laboratoire n'a pas le droit d'entraîner la génération de modèles suivante en termes de capacités tant qu'il n'a pas résolu tous les problèmes d'alignement notables de l'actuelle. L'auteur construit un processus en quatre étapes et le présente comme un minimum, pas comme une condition suffisante.

Logique de la proposition

L'analogie vient de l'aviation. On ne lance pas un avion volant à Mach 3 tant qu'on ne comprend pas pourquoi l'appareil se désintègre à Mach 2. Pour toute autre technologie dangereuse, personne n'accepterait de « hausser les épaules et d'avancer ». Dans une note de bas de page, l'auteur concède que la cause des accidents à Mach 2 pourrait cesser d'être un problème à Mach 3, mais que partir de ce principe serait de la folie.

Il souligne par ailleurs que la formule convient aussi bien aux optimistes qu'aux pessimistes sur l'alignement « prosaïque », c'est-à-dire l'amélioration des méthodes actuelles. Les premiers comptent sur un ralentissement modéré pour traiter les problèmes à chaque génération. Les seconds s'attendent à ce que l'exigence débouche sur une longue pause, qui laisserait le temps de chercher des approches radicalement nouvelles.

Les quatre étapes du cycle

• Audit pendant l'entraînement. Plusieurs organisations indépendantes spécialisées dans l'alignement vérifient et soumettent le nouveau modèle à du red-teaming sur de multiples checkpoints, avec un accès complet aux données et les meilleurs outils disponibles. Les problèmes sont pris au sérieux même en l'absence de métrique, lorsque quelque chose est simplement « qualitativement anormal », et même lorsqu'on ne peut pas démontrer de façon fiable la présence d'une bonne propriété. Les problèmes précoces ne bloquent pas nécessairement le processus, mais il faut un argumentaire de sûreté convaincant expliquant pourquoi les phases tardives de l'entraînement les élimineront.
• Lancement limité. Le modèle n'est accessible qu'à un groupe d'utilisateurs de confiance, pour des tâches qui n'influent ni sur l'entraînement ni sur le monitoring. Les organisations surveillent l'apparition de nouveaux problèmes.
• Déploiement à grande échelle, interne ou externe. Il n'est autorisé qu'après une période substantielle de lancement limité sans incident.
• Génération suivante. L'entraînement ne démarre qu'après une exploitation prolongée sans problème notable.

Si un problème sérieux survient à la deuxième ou à la troisième étape, le schéma est strict : le modèle est retiré, une analyse de la cause première est menée et l'on établit pourquoi le problème n'a pas été détecté pendant l'entraînement. On cherche ensuite à soigner la maladie, non le symptôme, on entraîne le modèle suivant de la même génération et on reprend depuis le début.

Un détail important figure dans une note de bas de page : des « performances meilleures que celles des modèles précédents » ne sont pas considérées comme un critère adéquat. Si, après le lancement, un utilisateur signale un comportement étrange mais inquiétant, qui n'avait pas été repéré auparavant, il s'agit d'une défaillance critique à la fois du modèle et du processus.

Ce que la proposition laisse de côté

L'auteur reconnaît lui-même que sa proposition est heuristique et non un règlement précis. Il nomme quatre trous évidents :

• comment définir une « génération de modèles » au sein d'un même laboratoire et entre laboratoires différents ;
• que faire si la correction d'un problème d'alignement augmente aussi sensiblement les capacités ;
• comment formaliser et contrôler l'accord si l'on ne peut pas s'appuyer uniquement sur des métriques définies à l'avance ;
• où placer le seuil de gravité à partir duquel le modèle est arrêté, alors que le laboratoire aura intérêt à surévaluer ce seuil.

Ce sont les principaux points de défaillance. Tant qu'il n'existe pas de définition commune de la génération, n'importe quel modèle peut être présenté comme une « version intermédiaire ». Et lorsque le laboratoire fixe lui-même le seuil de gravité, le processus se réduit à de l'autocertification.

Enseignement pratique

La proposition n'a aucune force juridique et reste pour l'instant un post sur une plateforme spécialisée. Mais elle fournit un modèle utile de questions à poser aux laboratoires. Disposez-vous d'auditeurs externes ayant accès aux données d'entraînement ?

Combien de temps dure le lancement limité et qu'est-ce qui compte comme un incident ? Qu'adviendra-t-il exactement du calendrier de sortie si un problème est découvert après le lancement ? Les régulateurs et les clients en entreprise peuvent dès maintenant intégrer ces questions dans leurs exigences envers les fournisseurs, sans attendre un accord à l'échelle de l'industrie.

Pour les laboratoires eux-mêmes, c'est un repère à partir duquel un observateur extérieur jugera le sérieux avec lequel ils prennent leurs propres déclarations sur la sécurité.