De la date de lancement aux métriques : comment évaluer les progrès réels de l’IA

Le piège de la chronologie

Un modèle qui vient d’être annoncé n’est pas forcément meilleur pour la tâche qui vous importe. La date de lancement ordonne les événements, mais ne mesure pas les capacités. Le nombre de paramètres, la longueur maximale du contexte ou le nom d’une architecture ne suffisent pas davantage : ces données décrivent certains aspects du système, sans prouver qu’il accomplit mieux une tâche précise.

La bonne question n’est pas « quel modèle est sorti après les autres ? », mais « qu’est-ce qui a changé, dans quelles conditions cela a-t-il été mesuré et quelles conséquences cela a-t-il pour mon usage ? ». Pour y répondre, il faut comparer les tâches, les configurations, les données d’évaluation, les coûts et les modes de défaillance. Si ces informations manquent, la conclusion rigoureuse n’est ni d’affirmer ni d’écarter une amélioration, mais de reconnaître que les éléments disponibles ne suffisent pas.

L’évaluation peut aussi devoir aller au-delà de la précision. L’article de Funcas consacré aux métriques de l’IA souligne que les performances techniques ne rendent pas compte, à elles seules, de dimensions telles que les biais, la durabilité ou l’impact social. De son côté, l’AESIA présente des guides pratiques portant notamment sur la précision, la robustesse, la gestion des risques et la gouvernance des données pour les systèmes relevant du champ d’application du règlement européen sur l’IA. Ces cadres sont complémentaires : aucun ne remplace une comparaison expérimentale entre deux versions d’un modèle.

Trois dimensions pour évaluer les changements

La première dimension est l’efficacité de l’inférence : combien coûte la production d’une réponse d’une qualité donnée, avec quelle latence et quelles exigences opérationnelles. Le coût par token est un élément de l’analyse, pas une conclusion à lui seul. Il faut aussi tenir compte de la taille des requêtes, de la mise en cache, de la concurrence, du matériel, de la disponibilité et du coût de correction des réponses erronées. Un gain de qualité peut entraîner un coût d’exploitation qui ne convient pas à toutes les applications.

La deuxième dimension est la robustesse sur des tâches définies. Une moyenne globale peut masquer des baisses de performance pour certaines langues, certains formats, certains groupes d’utilisateurs ou des cas rares. Il convient de consigner les résultats par sous-ensemble, la dispersion entre les exécutions lorsqu’il existe une part d’aléatoire, ainsi que les échecs sur les cas limites. En production, un système généralement fiable mais sujet à une défaillance grave dans une situation prévisible peut être moins utile qu’un autre, légèrement moins performant en moyenne mais plus stable.

La troisième dimension concerne le changement technique et ses effets observés. Une architecture dense, une architecture à experts ou un mécanisme hybride peuvent modifier l’utilisation du calcul, la capacité de mise à l’échelle et les besoins de service. Toutefois, connaître l’architecture ne permet pas de déduire automatiquement les performances ou l’efficacité. Il faut mesurer le système dans son ensemble avec des charges et des conditions comparables, et distinguer le nombre total de paramètres des paramètres actifs lorsque la documentation les différencie.

Architecture, contexte et benchmarks : ce que les exemples permettent réellement de conclure

Les architectures à mélange d’experts, ou MoE, sont souvent présentées comme un moyen de n’activer qu’une partie des composants pour chaque entrée. Cette description peut aider à formuler une hypothèse sur le calcul nécessaire par requête, mais elle ne prouve pas qu’un modèle MoE soit automatiquement moins coûteux ou meilleur qu’un modèle dense. La comparaison dépend de détails liés à l’entraînement, au routage, au matériel et au service, ainsi que de la qualité obtenue sur les tâches évaluées. Les sources vérifiées disponibles pour cet article ne contiennent pas de résultats comparatifs qui permettraient d’affirmer que les MoE apportent un gain général.

Une fenêtre de contexte plus grande est également une capacité potentielle, pas une garantie de rétention parfaite. Pour l’évaluer, il faut tester des tâches longues et préciser où se trouve l’information pertinente, quelle quantité de texte est fournie et ce qui constitue une réponse correcte. Un résultat obtenu sur un test synthétique ne suffit pas pour conclure que le modèle conserve les mêmes performances avec des documents réels, des consignes complexes ou du contenu réparti tout au long d’une conversation.

Les benchmarks peuvent devenir moins discriminants lorsque de nombreux modèles obtiennent des résultats similaires, mais il ne faut pas parler de « stagnation » sans disposer de données comparables et documentées. Il faut connaître le jeu d’évaluation, sa version, le protocole de notation et l’éventuelle exposition préalable de ses exemples. Les sources fournies ne présentent ni séries de résultats entre plusieurs versions ni éléments démontrant une contamination des benchmarks. Ces possibilités doivent donc être traitées comme des questions d’audit, et non comme des conclusions de cet article.

Protocole d’audit d’une annonce de nouveau modèle

Commencez par transformer la promesse en hypothèse vérifiable. « Il est plus intelligent » ne définit pas un test. En revanche, « il réduit les omissions lors de l’extraction de dates dans des contrats, sans dépasser un seuil convenu de coût par requête » permet de concevoir une évaluation. Avant de tester le modèle, fixez les tâches prioritaires, leur méthode de notation et le niveau d’erreur acceptable.

Vérifiez ensuite que la comparaison est valable. Utilisez des entrées équivalentes, documentez la configuration des modèles et répétez les tests lorsque les résultats peuvent varier. Notez le fournisseur ou la version, la date d’accès, les paramètres de génération, les outils activés, les limites de sortie et les conditions de service. Si les résultats proviennent d’évaluations différentes, ne les présentez pas comme une comparaison directe sans justifier leur équivalence.

Enfin, examinez la reproductibilité et les risques liés à l’évaluation. Demandez si le code, les données de test et les instructions nécessaires pour répéter l’expérience sont disponibles ; ne supposez pas que les données d’entraînement sont publiques. Recherchez d’éventuels chevauchements entre les exemples d’évaluation et les documents utilisés pour entraîner ou ajuster le système. Si aucune information ne permet de le vérifier, indiquez cette limite au lieu d’affirmer qu’une contamination a eu lieu.

De l’évaluation technique à la décision d’investissement

Un audit utile ne se termine pas par un classement des modèles. Il transforme les éléments disponibles en décision : adopter, tester à petite échelle, attendre de nouvelles informations ou améliorer le système existant. Si la nouvelle capacité répond à un véritable point de blocage et que son coût total reste acceptable, un essai contrôlé peut se justifier. Si le gain ne se retrouve pas sur les tâches propres à l’organisation ou s’il augmente un risque important, mieux vaut privilégier les optimisations, les mesures de contrôle ou une autre solution.

Pour les usages qui peuvent avoir des conséquences importantes, le cadre doit inclure des dimensions qui ne se résument pas à un score de benchmark. Funcas souligne qu’il faut aussi considérer des questions comme les biais, la durabilité et l’impact social. L’AESIA décrit, pour sa part, des guides non contraignants destinés à accompagner la mise en œuvre du règlement européen sur l’IA ; ils comprennent notamment des ressources sur la gestion des risques, la gouvernance des données, la précision et la robustesse des systèmes relevant de son champ d’application. L’applicabilité dépend du système et de son contexte : ces guides ne doivent pas être présentés comme une obligation universelle applicable à tout outil.

La décision finale doit être proportionnée aux éléments disponibles et au niveau de risque. Une annonce peut justifier d’examiner une nouvelle capacité, mais pas de la considérer comme démontrée. Tant qu’une évaluation comparable, aussi reproductible que possible et représentative de l’usage prévu n’a pas été menée, la conclusion la plus rigoureuse consiste à maintenir l’incertitude. La date de lancement retrouve alors sa juste place : c’est une donnée chronologique, pas un indicateur autonome de progrès.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.