Claude Sonnet 4.5 en sciences de la vie : ce que ses résultats démontrent et comment les revalider

Ce que signifie dépasser une référence humaine dans un test circonscrit

Un score de benchmark répond à une question délimitée : comment un modèle s’est-il comporté sur un ensemble donné, pour une tâche, avec des instructions et dans des conditions précises ? Il ne répond pas automatiquement à une question beaucoup plus large : le modèle peut-il lire correctement les protocoles d’un laboratoire, interpréter ses données et contribuer de façon fiable à des conclusions scientifiques ? Pour décider si Claude Sonnet 4.5 peut aider dans un véritable flux de travail, il faut distinguer ces deux affirmations.

La fiche de sécurité de Claude Sonnet 4.5 publie des résultats sur plusieurs tâches de LAB-Bench, notamment Protocol QA, FigQA, SeqQA et Cloning, ainsi qu’une référence humaine. Dans le graphique consacré à Protocol QA, Sonnet 4.5 obtient un score de 0,833 avec k=10, contre 0,741 pour Sonnet 4. Ces chiffres proviennent des résultats publiés par Anthropic ; ils ne constituent pas une validation indépendante de la performance du modèle sur n’importe quel document ou dans n’importe quel laboratoire.

Ainsi, dépasser une référence humaine dans une évaluation précise ne signifie ni que le modèle est globalement meilleur que les chercheurs, ni qu’il répond correctement à chaque question, ni que ses réponses peuvent être converties en instructions expérimentales sans vérification. L’interprétation dépend des questions posées, de la méthode de notation et de la composition du groupe humain de comparaison. Les informations disponibles ne suffisent pas à transposer ce résultat à d’autres documents, équipes ou décisions.

Identifier précisément le modèle évalué

« Claude Sonnet 4.5 » désigne une famille ou une version commerciale, mais une évaluation reproductible doit consigner l’identifiant auquel la requête a été adressée. La documentation d’Anthropic distingue les identifiants datés des alias et indique que le snapshot de Sonnet 4.5 porte l’identifiant claude-sonnet-4-5-20250929. Enregistrer cet identifiant, ainsi que la date et la configuration du test, réduit l’ambiguïté lors des comparaisons.

Cette précaution vaut également lorsqu’on compare des modèles ultérieurs. La source officielle fournie au sujet de Sonnet 5 annonce ce modèle, mais n’établit pas qu’il a été évalué sur les mêmes tâches de LAB-Bench ou de BixBench, avec le même protocole et le même ensemble que Sonnet 4.5. La documentation fournie ne permet pas non plus d’affirmer qu’il existe une comparaison équivalente pour Sonnet 4.6. La sortie d’une version plus récente ne prouve pas à elle seule une amélioration sur ces tâches.

Pour être utile, une comparaison doit porter sur la tâche et les conditions, et non se limiter aux noms des modèles. Si l’ensemble de questions, le nombre d’exemples présentés au modèle, les outils disponibles ou la méthode de notation changent, les écarts observés peuvent tenir à ces variations autant qu’à la version du modèle.

Trois benchmarks, trois types d’éléments de preuve

LAB-Bench est un ensemble de tâches conçu pour mesurer des capacités de modèles de langage liées à la recherche en biologie. L’article d’origine décrit des questions à choix multiples et une comparaison avec des chercheurs experts. Sa portée est celle des tâches incluses dans le benchmark : il ne s’agit ni d’une observation directe du travail en laboratoire ni d’une évaluation de toutes les étapes d’un projet de recherche.

Au sein de LAB-Bench, Protocol QA porte sur des questions relatives aux protocoles. Le résultat publié pour Sonnet 4.5 apporte des éléments sur ses performances pour cette tâche, dans les conditions décrites par l’évaluation. Il ne démontre pas que le modèle peut exécuter un protocole, repérer toutes ses ambiguïtés ou adapter correctement une instruction aux réactifs, aux instruments et aux procédures locales. Comprendre une question documentaire et mener une opération expérimentale sont deux compétences distinctes.

LAB-Bench comprend également des tâches liées à la lecture de figures, aux séquences et au clonage. La présence de résultats dans ces catégories dans la fiche de sécurité élargit le panorama de l’évaluation, mais ne rend pas leurs scores interchangeables : chaque tâche met à l’épreuve des capacités et des formats différents. Un bon résultat à des questions sur les protocoles ne permet pas de déduire automatiquement une performance équivalente en interprétation de figures.

BixBench porte sur la biologie computationnelle au moyen de questions ouvertes qui nécessitent des parcours analytiques en plusieurs étapes. L’article d’origine décrit des évaluations initiales avec GPT-4o et Claude 3.5 Sonnet, et non avec Claude Sonnet 4.5. BixBench permet donc d’illustrer une catégorie d’évaluation de l’analyse computationnelle, mais les résultats initiaux cités ne sont pas des résultats de Sonnet 4.5 et ne doivent pas être présentés comme tels.

Le dépôt de BixBench décrit un harness et une configuration permettant de lancer des évaluations qui incluent l’analyse de notebooks et l’exécution de code. Cette structure permet d’envisager une reproduction contrôlée du benchmark, mais ne dispense pas de vérifier quelle version, quels outils et quelles conditions ont été employés lors de chaque expérience. Pour LAB-Bench, le dépôt des auteurs documente les formats et les scripts d’évaluation, et signale que le matériel public ne comprend pas l’ensemble complet. Cette limite compte si l’objectif est de reproduire exactement un score publié.

Pourquoi ne pas combiner les scores de Protocol QA sans vérification

Les éléments disponibles comprennent un résultat de Protocol QA dans la fiche de sécurité de Sonnet 4.5 : 0,833 pour Sonnet 4.5 avec k=10 et 0,741 pour Sonnet 4. La proposition éditoriale relève que certaines publications d’Anthropic affichent des scores différents pour des tâches nommées Protocol QA. Cependant, les sources fournies ne documentent pas suffisamment ces écarts pour déterminer si les chiffres proviennent du même ensemble, de partitions différentes, de prompts distincts ou d’autres changements méthodologiques.

Le fait que deux mesures portent le même nom ne garantit pas qu’elles soient équivalentes. Avant de les présenter comme une progression ou une contradiction, il faudrait vérifier la version exacte du modèle, le corpus évalué, le format des questions, les exemples inclus dans le prompt, la disponibilité d’outils, la règle de notation et le traitement des réponses partielles. Il faudrait également préciser ce que signifie k=10 dans le graphique et comment les réponses ont été agrégées, si l’on souhaite interpréter ce paramètre avec précision.

La comparaison avec des humains exige un audit similaire. La fiche de sécurité montre une référence humaine, mais les documents décrits ici ne donnent pas assez de détails pour caractériser avec assurance la population, le nombre de participants, leur expérience ou les instructions reçues. Sans ces informations, il serait imprudent de présenter cette référence comme une norme universelle de performance experte.

La conclusion appropriée n’est pas que les résultats sont incompatibles ni que l’un des chiffres est erroné : c’est que les informations disponibles ne permettent pas de trancher leur comparabilité. Une présentation rigoureuse indique chaque chiffre dans son contexte et explicite l’incertitude, plutôt que de calculer une tendance ou de fusionner des scores.

Du benchmark au laboratoire : le chaînon manquant

Un benchmark peut évaluer si une réponse correspond à une clé de correction. Un laboratoire doit, lui, savoir si cette réponse est juste au regard de sa documentation en vigueur et du contexte de la question. Les protocoles peuvent comporter des variantes locales, des noms internes, des notes de révision ou des conditions pertinentes absentes du matériel de référence d’un test public. La capacité à répondre à des questions générales ne vérifie pas que le modèle a repéré et appliqué la bonne version du document.

En outre, répondre à propos d’un protocole ne revient pas à l’exécuter. L’exécution dépend des personnes, des appareils, des échantillons, des matériaux et des contrôles ; rien de tout cela n’est démontré par un score obtenu à des questions-réponses. De même, produire une interprétation plausible d’une figure ne prouve ni que cette interprétation est valide ni que la conclusion scientifique résiste à l’examen de l’ensemble des données.

Les outils ajoutent une autre dimension. Dans une tâche d’analyse computationnelle, la capacité à produire ou à exécuter du code peut influer sur le résultat ; dans une tâche documentaire, le modèle peut n’avoir répondu qu’à partir du prompt. Pour attribuer une différence à une version du modèle, la comparaison doit maintenir les outils constants et indiquer quand ils ont été utilisés. Les sources disponibles décrivent certains aspects de l’évaluation des benchmarks, mais ne suffisent pas à reconstituer toutes les conditions de chaque score publié.

Pour ces raisons, un résultat favorable peut justifier l’évaluation d’un usage circonscrit — par exemple, repérer une réponse candidate dans la documentation et préparer un brouillon à vérifier — mais ne vaut ni autorisation de remplacer le contrôle des spécialistes ni démonstration de validité scientifique.

Concevoir une validation rétrospective utile

Un test interne n’a pas besoin d’automatiser des expériences ni d’exposer des informations sensibles pour évaluer la compréhension documentaire. Il peut s’appuyer sur un corpus autorisé et figé : des documents que l’équipe est habilitée à utiliser, une version identifiable de chaque fichier et un relevé des éléments accessibles au moment de la réponse. Le gel du corpus évite que des modifications ultérieures des documents changent l’interprétation des résultats.

Des spécialistes connaissant les documents devraient rédiger et relire des questions représentatives, ainsi que des réponses de référence vérifiées à partir des sources. Il est utile d’inclure des questions dont la réponse est explicite, d’autres qui exigent de rapprocher plusieurs passages, et enfin des questions impossibles à résoudre avec les documents disponibles. Cette dernière catégorie permet de vérifier si le système reconnaît les limites des éléments de preuve, plutôt que de combler les lacunes par une réponse plausible.

Chaque réponse doit être évaluée au moyen d’une grille avant de comparer les modèles. Cette grille peut distinguer l’exactitude du contenu, l’appui fourni par la source, l’identification de la version pertinente, les omissions importantes et les affirmations non étayées. Les réponses devraient être examinées par des personnes qui ne fondent pas leur jugement sur la marque ou la version du modèle ; les désaccords entre évaluateurs devraient être consignés et résolus à l’aide de critères définis à l’avance.

Pour comparer Sonnet 4.5 à des versions ultérieures, il faut utiliser les mêmes questions, documents, instructions, outils et règles de notation. L’identifiant exact de chaque modèle doit être consigné. Si une plateforme ne permet pas de figer une version ou un paramètre, cette limite fait partie du résultat et ne doit pas être dissimulée. Des répétitions permettent aussi de vérifier la stabilité des réponses ; leur nombre doit être choisi en fonction du coût et du risque de l’usage prévu, et non déduit des sources publiques.

Le test doit rester rétrospectif et se limiter à la compréhension de documents pouvant être vérifiés. Il n’est pas nécessaire de demander au modèle de concevoir, modifier ou exécuter des expériences pour savoir s’il sait retrouver une information, interpréter un texte ou reconnaître qu’une question n’a pas de réponse dans le corpus. Si les figures ou des résultats analytiques sont évalués, l’équipe doit disposer de références vérifiées et distinguer ces résultats des scores obtenus sur des questions relatives aux protocoles.

Classer les erreurs qui comptent

Un taux global de réussite peut masquer des défaillances de gravité différente. Dans la lecture de protocoles, une omission peut faire disparaître une condition importante ; une inversion de l’ordre des étapes peut changer le sens d’une instruction ; une confusion d’unités peut donner à une réponse une apparence de précision alors qu’elle est fausse. L’équipe devrait consigner ces cas séparément, sans supposer que toutes les réponses incorrectes présentent le même risque.

Pour les questions portant sur des figures, il convient de distinguer la description d’un élément visible de l’attribution d’une relation qui n’est pas montrée, puis de la formulation d’une explication causale. Dans les tâches computationnelles, il faut différencier une analyse reproductible d’une conclusion qui ne découle pas des données. Il faut aussi signaler les références qui n’étayent pas la réponse, les renvois à la mauvaise section et l’assurance injustifiée face à une information absente.

L’évaluation de sécurité éditoriale doit rester dans le domaine documentaire : vérifier si le modèle restitue fidèlement le contenu autorisé et indique les incertitudes. Il n’est pas nécessaire d’inclure des instructions expérimentales sensibles ni de demander des actions étrangères à la tâche de lecture. Le but est de déterminer si le système peut servir d’aide soumise à vérification, et non de transformer le test interne en validation de procédures.

Usage circonscrit et conclusion

Si une évaluation interne favorable confirme que Sonnet 4.5 repère les informations et les restitue avec un appui vérifiable, l’équipe peut envisager de le tester comme assistant de lecture ou comme générateur de brouillons soumis à examen. La réponse finale reste soumise au processus de vérification adopté par le laboratoire. Le score public, à lui seul, ne justifie pas l’utilisation d’une sortie comme instruction expérimentale ni son emploi pour arrêter une interprétation scientifique.

La comparaison avec des successeurs doit prendre la forme d’un nouveau test contrôlé. La documentation fournie permet d’identifier Sonnet 4.5 et mentionne l’annonce officielle de Sonnet 5, mais ne donne pas de résultats équivalents pour ce dernier sur Protocol QA, LAB-Bench ou BixBench. Elle ne permet pas non plus d’établir une comparaison contrôlée avec Sonnet 4.6. Il est donc impossible d’en déduire, à partir de ces sources, quel modèle ultérieur obtient les meilleurs résultats sur les mêmes tâches.

La conclusion vérifiable est plus limitée, mais utile : Anthropic publie des résultats favorables de Sonnet 4.5 pour des tâches précises de LAB-Bench, dont Protocol QA, tandis que BixBench évalue une autre catégorie de travail et que les résultats initiaux cités ne portent pas sur Sonnet 4.5. Ces données justifient de formuler une hypothèse d’utilité pour la lecture et l’analyse, pas d’affirmer une fiabilité dans un laboratoire réel. Les éléments manquants doivent être recueillis au moyen de documents autorisés, de questions relues par des spécialistes, de références traçables et de comparaisons conduites dans des conditions équivalentes.

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.