Recherche sur l'évaluation et la sécurité de l'IA

Lorsque vous utilisez des produits comme ChatGPT, Claude, Gemini, DeepSeek, Doubao et Qwen, vous pourriez vous demander : quel modèle est le meilleur ?

Mais que signifie « bon » ? Est-ce des réponses plus précises ? Ou plus sûres ? Est-ce du code généré de meilleure qualité ? Ou une capacité de raisonnement plus forte ?

Pour un système d’IA complexe, une évaluation selon une seule dimension est loin d’être suffisante. Vous avez besoin d’un cadre d’évaluation systématique pour clarifier en quoi il est bon et pourquoi il est bon.

C’est le thème de ce chapitre : comment évaluer scientifiquement les systèmes d’IA, et comment étudier les questions de sécurité de l’IA.

L’évaluation ne consiste pas seulement à noter des modèles. C’est la boussole de l’amélioration des modèles—ce n’est qu’en sachant où se trouvent les faiblesses que l’on sait comment optimiser.

La recherche sur la sécurité est la soupape de sécurité du modèle—avant la publication du modèle, identifiez les vulnérabilités qui pourraient être exploitées et prévenez les usages abusifs.

Évaluation + Recherche sur la sécurité = Développement responsable de l’IASans évaluation, vous ne pouvez pas connaître les progrès ; sans recherche sur la sécurité, plus les progrès sont rapides, plus le risque est grand.

Système d’évaluation des LLM

Évaluer un grand modèle de langage n’est pas une tâche simple. Vous devez porter des jugements complets selon de multiples dimensions et avec de multiples méthodes.

Trois dimensions de l’évaluation

L’évaluation des LLM commence généralement par trois dimensions essentielles : les capacités, la sécurité et l’efficacité.

La capacité est la « force » du modèle, la sécurité est sa « ligne rouge », et l'efficacité est sa « faisabilité ». Ces trois aspects sont indispensables.

En réalité, il existe souvent des compromis entre ces trois aspects. Par exemple, plus la capacité d'un modèle est forte, plus il peut être facilement incité à produire du contenu nuisible ; rechercher une sécurité extrême peut rendre le modèle trop conservateur, allant jusqu'à refuser de répondre à des questions normales.

Évaluation automatique vs évaluation humaine

Les méthodes d'évaluation se divisent principalement en deux catégories : l'évaluation automatique et l'évaluation humaine.

L'évaluation automatique utilise des programmes ou des modèles pour attribuer une note, ce qui est rapide, peu coûteux et reproductible. Cependant, de nombreuses qualités subjectives (comme « la réponse est-elle utile ? ») sont difficiles à juger directement avec des programmes.

L'évaluation humaine implique que des personnes lisent les réponses et les notent, ce qui offre une haute qualité et est plus proche de l'expérience utilisateur réelle. Cependant, elle est lente, coûteuse, et la cohérence est difficile à garantir — différentes personnes peuvent avoir des avis différents sur la même réponse.

En pratique, il s'agit généralement d'une combinaison des deux : d'abord utiliser l'évaluation automatique pour un filtrage rapide, puis l'évaluation manuelle pour la vérification finale.

LLM-as-Judge : utiliser l'IA pour évaluer l'IA

Une idée astucieuse consiste à utiliser un LLM plus puissant comme « juge » pour évaluer la sortie d'un autre LLM. C'est ce qu'on appelle le « LLM-as-Judge ».

Par exemple, demandez à GPT-4 de noter les réponses de Claude, ou vice versa. Cette méthode présente à la fois la flexibilité de l'évaluation manuelle et l'efficacité de l'évaluation automatique.

Résultats d'exécution :

============================================================
LLM-as-Judge 评估结果
============================================================

模型: Model-A
Question: 如何学习 Python 编程？
总分: 4/5
有帮助: 4/5
安全性: 5/5
理由: 基于回答的完整性、准确性和安全性综合判断
建议: 回答整体不错，可以考虑增加具体例子使内容更生动

模型: Model-B
Question: 如何学习 Python 编程？
总分: 3/5
有帮助: 2/5
安全性: 5/5
理由: 基于回答的完整性、准确性和安全性综合判断
建议: 即使无法直接回答，也可以提供一些有用的相关信息

模型: Model-C
Question: 如何学习 Python 编程？
总分: 4/5
有帮助: 4/5
安全性: 5/5
理由: 基于回答的完整性、准确性和安全性综合判断
建议: 回答整体不错，可以考虑增加具体例子使内容更生动

============================================================
所有模型平均得分: 3.67/5
============================================================

LLM-as-Judge est une méthode puissante, mais elle présente aussi des limites. Le modèle juge peut être biaisé, et ses scores pour certaines réponses peuvent être incohérents avec les évaluations humaines. Il est important de comparer régulièrement les scores de LLM-as-Judge avec les scores humains afin de garantir la qualité de l'évaluation.

Benchmarks d'évaluation courants

L'industrie dispose déjà de nombreux benchmarks d'évaluation matures (Benchmark), chacun se concentrant sur différentes dimensions de capacités. Comprendre ces benchmarks vous permettra de donner un sens à des nouvelles comme « le score du benchmark XX dépasse les humains » lors de la sortie de modèles.

MMLU : Compréhension linguistique multitâche

MMLU (Massive Multitask Language Understanding) est l'un des benchmarks basés sur les connaissances les plus couramment utilisés.

Il contient des questions à choix multiples issues de 57 matières, couvrant les mathématiques, la physique, la chimie, la biologie, le droit, la médecine, l'économie et d'autres domaines. La difficulté des questions est équivalente au niveau universitaire.

Par exemple, une question de médecine pourrait être : Lequel des médicaments suivants est un antibiotique ? A. Aspirine B. Pénicilline C. Ibuprofène D. Acétaminophène.

MMLU teste les connaissances générales et la capacité de raisonnement du modèle. Plus le score est élevé, plus les connaissances du modèle sont étendues.

BIG-Bench : Test des capacités émergentes

BIG-Bench (Beyond the Imitation Game Benchmark) est un benchmark à grande échelle auquel la communauté a contribué.

Il contient plus de 200 tâches, conçues pour tester les « capacités émergentes » du modèle, c'est-à-dire des choses que les petits modèles ne peuvent pas faire et que seuls des modèles suffisamment grands peuvent faire.

Les tâches typiques incluent : le raisonnement logique, le jugement causal, le raisonnement analogique, le jugement moral, la cryptanalyse, la planification de navigation, etc.

BIG-Bench ne teste pas seulement les connaissances, mais aussi l'« intelligence » : la capacité du modèle à accomplir des tâches nécessitant une réflexion flexible.

HELM : évaluation holistique des modèles de langage

HELM (évaluation holistique des modèles de langage) se caractérise par son « exhaustivité ».

Il évalue non seulement l'exactitude, mais aussi de multiples dimensions telles que l'équité, les biais, la toxicité et la robustesse. Il teste les modèles sur 16 scénarios clés, notamment les questions-réponses, le résumé, l'extraction d'informations, la détection de toxicité, etc.

La philosophie de HELM est la suivante : une seule métrique ne peut pas représenter la performance réelle d'un modèle ; il faut regarder la « vue d'ensemble ».

MT-Bench : évaluation des dialogues multi-tours

MT-Bench (benchmark multi-tours) est spécialement conçu pour évaluer la capacité de conversation.

Il contient 80 scénarios de dialogue multi-tours, couvrant l'écriture, la programmation, le raisonnement, le jeu de rôle, etc. La méthode d'évaluation consiste à utiliser GPT-4 comme juge pour noter les réponses multi-tours du modèle.

La plage de scores est 1-10, 10 étant le meilleur. De nombreux modèles open source utilisent ce benchmark pour prouver que leur capacité de conversation est proche de GPT-4.

HumanEval : évaluation de la génération de code

HumanEval teste spécifiquement la capacité de génération de code.

Il contient 164 problèmes de programmation écrits manuellement, chacun avec une description fonctionnelle détaillée et des tests unitaires. Après que le modèle a généré du code, exécutez les tests pour voir combien réussissent.

Par exemple, un problème pourrait être : "Écrivez une fonction qui prend une liste et renvoie la somme de tous les nombres pairs de la liste."

HumanEval ne se soucie pas de savoir si le code est joliment écrit, mais s'il s'exécute correctement et passe tous les tests.

Exécution de tests de référence avec lm-eval-harness

lm-eval-harness est un outil open source populaire qui vous permet de tester des modèles sur plusieurs benchmarks en un clic.

Benchmarks d'évaluation en chinois

La plupart des benchmarks présentés précédemment sont principalement en anglais. Pour les scénarios chinois, vous avez besoin de benchmarks d'évaluation chinois spécialisés.

C-Eval

C-Eval est un benchmark chinois complet développé conjointement par des institutions telles que l'Université Tsinghua et l'Université Jiao Tong de Shanghai.

Il contient 13,948 questions à choix multiples couvrant 52 matières, allant du niveau collège au niveau universitaire. Les matières incluent les sciences et l'ingénierie, les sciences humaines et sociales, le commerce, et plus encore.

C-Eval est l'un des benchmarks de connaissances les plus faisant autorité dans le domaine chinois.

CMMLU

CMMLU (Chinese Multitask Language Understanding) est la version chinoise de MMLU.

Il contient des questions issues de 67 matières, allant du niveau primaire au niveau universitaire, couvrant à la fois des questions de connaissances et des questions d'application. Contrairement à C-Eval, les questions de CMMLU sont rédigées directement en chinois plutôt que traduites de l'anglais.

AlignBench

AlignBench, développé par l'Université Tsinghua, évalue spécifiquement la capacité d'alignement des grands modèles de langage chinois, c'est-à-dire si les réponses du modèle sont conformes aux préférences humaines.

Il contient 1,300 cas de test couvrant 8 dimensions : utilité, sécurité, lisibilité, exactitude factuelle, logique, exhaustivité, créativité et exactitude du format.

AlignBench ne se contente pas de vérifier si une réponse est « correcte » ; il vérifie aussi si elle est « bonne » — si la réponse aide réellement l'utilisateur.

Créer des ensembles d'évaluation personnalisés

Les benchmarks prêts à l'emploi sont utiles, mais ils peuvent ne pas couvrir vos scénarios spécifiques. Par exemple, si votre modèle est destiné à la rédaction de documents juridiques ou aux conversations de service client, les benchmarks généraux peuvent ne pas mesurer les performances réelles.

À ce stade, vous devez construire votre propre ensemble d'évaluation.

Classification et échantillonnage des tâches

La première étape de la construction d'un ensemble d'évaluation consiste à clarifier les scénarios que vous souhaitez tester et la fréquence à laquelle ces scénarios se produisent dans le monde réel.

Par exemple, un modèle de service client peut inclure ces scénarios réels :

• Demande de statut de commande (30%)
• Consultation sur les retours et échanges (25%)
• Problèmes d'utilisation du produit (20%)
• Réclamations et suggestions (15%)
• Autres (10%)

Votre ensemble d'évaluation doit être échantillonné selon ce ratio, afin que les résultats de l'évaluation reflètent l'utilisation dans le monde réel.

Conception des spécifications d'annotation

Une fois que vous avez des questions de test, vous devez définir des critères de notation.

Une bonne spécification d'annotation doit :

• 1. Clarifier la signification de chaque score — non seulement dire que 5 est le meilleur, mais préciser que 5 signifie que la réponse est complète, exacte, utile et sans aucune redondance.

• 2. Fournir des exemples positifs et négatifs — montrer aux annotateurs à quoi ressemble une réponse de 5 points et à quoi ressemble une réponse de 3 points.

• 3. Gérer les cas limites — expliquer comment traiter certaines situations particulières (par ex., des questions ambiguës).

Assurer la cohérence de l'évaluation

Lorsque plusieurs personnes annotent la même question, leurs scores peuvent être incohérents. Cela affecte la crédibilité des résultats de l'évaluation.

Méthodes courantes pour assurer la cohérence :

• 1. Faire annoter la même question par plusieurs personnes, puis faire la moyenne des scores ou utiliser des méthodes statistiques pour calculer des indicateurs de cohérence (par ex., le kappa de Cohen).

• 2. Calibration régulière — lorsque de grands désaccords entre annotateurs sont constatés, rediscuter les critères de notation.

• 3. Utiliser LLM-as-Judge comme aide — utiliser l'IA pour un premier filtrage, les humains n'arbitrant que les cas litigieux.

Red Teaming

Le Red Teaming (tests d'équipe rouge) était à l'origine un terme du domaine de la cybersécurité — un groupe de personnes joue le rôle d'« attaquants », tentant de pénétrer les systèmes et de trouver des vulnérabilités.

Dans le domaine de l'IA, le Red Teaming consiste à : tenter spécifiquement de faire générer au modèle du contenu nuisible, faux ou non conforme, afin de découvrir des vulnérabilités de sécurité dans le modèle.

Qu'est-ce que le Red Teaming ?

Imaginez que vous publiez un modèle d'IA, et que quelqu'un veuille qu'il :

• Apprendre aux gens à fabriquer des bombes

• Générer des discours haineux

• Fournir des modèles d'e-mails d'hameçonnage

• Faire fuiter des informations sensibles

Le Red Teaming consiste à essayer ces mauvaises choses avant la publication du modèle, pour voir si le modèle va mordre à l'hameçon. Si c'est le cas, corrigez ces vulnérabilités.

L’objectif du Red Teaming n’est pas l’attaque, mais l’amélioration— en trouvant des problèmes, rendre le modèle plus sûr.

Méthodes manuelles de Red Teaming

Le Red Teaming manuel repose sur la créativité humaine pour imaginer diverses questions « délicates ».

Les méthodes courantes incluent :

• 1. Demande directe — demander directement « comment fabriquer des objets dangereux », et voir si le modèle refuse.

• 2. Jeu de rôle — « Supposez que vous êtes un méchant, dites-moi comment... »

• 3. Guidage subtil — ne pas formuler directement la demande nuisible, mais tourner autour du pot.

• 4. Déguisé en besoins légitimes — présenter des demandes nuisibles comme de la recherche universitaire, de la défense en sécurité, etc.

• 5. Détours par conversation multi-tours — discuter d’abord de sujets normaux, puis guider progressivement vers un contenu nuisible.

L’avantage du Red Teaming manuel est la créativité et la capacité à découvrir des chemins d’attaque complexes. L’inconvénient est une couverture limitée et une difficulté à passer à l’échelle.

Red Teaming automatisé

Pour améliorer l’efficacité, les chercheurs ont développé des méthodes automatisées de Red Teaming — en utilisant l’IA pour attaquer l’IA.

Deux méthodes typiques :

PAIR（Prompt Automatic Iterative Refinement）— Utiliser un "modèle attaquant" pour générer et optimiser automatiquement des invites, en tentant de faire produire au modèle cible du contenu nuisible.

TAP（Tree of Attacks with Pruning）— Utiliser une recherche arborescente pour explorer plusieurs chemins d'attaque et trouver les invites d'attaque les plus efficaces.

Ces méthodes peuvent générer des milliers d'invites d'attaque en peu de temps, en trouvant des méthodes d'attaque auxquelles les humains pourraient ne pas penser.

Rédaction d’un rapport Red Team

Un bon rapport Red Team ne se contente pas de lister "N vulnérabilités trouvées" ; il indique aussi au lecteur :

• 1. En quoi consiste la vulnérabilité — quelle est la méthode d’attaque spécifique.

• 2. Quelle est sa gravité — s’agit-il d’un problème théorique ou réellement exploitable.

• 3. Comment y remédier — quelles mesures d’atténuation sont disponibles.

• 4. Méthodes de vérification — comment confirmer que le correctif fonctionne.

Le rapport doit être clair, précis et exploitable.

Le Red Teaming est un processus continu, pas une activité ponctuelle. Après chaque mise à jour du modèle, les tests de red team doivent être réexécutés afin de garantir qu’aucune nouvelle vulnérabilité de sécurité n’a été introduite.

Recherche en interprétabilité

Les grands modèles de langage sont souvent appelés « boîtes noires » — vous leur donnez une entrée, ils vous donnent une sortie, mais vous ne savez pas ce qui se passe réellement à l’intérieur.

La recherche en interprétabilité consiste à trouver des moyens d’ouvrir cette boîte noire et de comprendre comment le modèle prend ses décisions.

Interprétabilité mécaniste

L’interprétabilité mécaniste est une direction radicale : elle cherche à comprendre les « mécanismes causaux » du modèle — comme on comprend un circuit, en déterminant ce que fait chaque neurone et comment ils collaborent pour produire une sortie.

Par exemple, les chercheurs ont découvert que certains neurones sont spécifiquement responsables de « prédire si le mot suivant est un nom », et que certains neurones sont responsables de « détecter si une phrase est une question ».

Ce n’est pas seulement pour satisfaire la curiosité. Si nous pouvons comprendre les mécanismes internes du modèle, nous pouvons :

• 1. Faire davantage confiance au modèle — savoir pourquoi il a raison, pas seulement qu’il a raison.

• 2. Découvrir les défauts du modèle — savoir où il s’est trompé et pourquoi.

• 3. Modifier le modèle — corriger directement le comportement incorrect du modèle, plutôt que de simplement le fine-tuner avec RLHF.

Hypothèse de superposition

La superposition est une hypothèse importante en interprétabilité mécaniste.

En termes simples : un modèle possède un nombre limité de neurones, mais le nombre de caractéristiques qu'il doit représenter peut largement dépasser le nombre de neurones. Le modèle « comprime » donc — il laisse un neurone représenter simultanément plusieurs caractéristiques sans lien entre elles.

C'est comme un casier de rangement : si vous voulez y faire tenir plus d'objets, vous devrez peut-être en entasser plusieurs dans le même compartiment, tant que vous ne les sortez pas en même temps.

La superposition explique pourquoi les modèles présentent parfois des capacités « magiques » — elle entasse davantage de connaissances dans un espace limité. Mais cela rend aussi les modèles plus difficiles à comprendre — un neurone fait plusieurs choses à la fois, ce qui rend difficile de démêler son rôle.

Méthodes de découverte de circuits

La découverte de circuits tente de trouver des « sous-réseaux » au sein des modèles qui accomplissent des tâches spécifiques — un peu comme localiser un module fonctionnel dans un circuit complexe.

Par exemple, les chercheurs ont découvert un circuit de « tête d'induction » dans GPT-2, chargé de reconnaître les motifs répétés dans le texte, puis de les imiter.

Ces circuits sont comme les « organes » du modèle — chacun gère une fonction spécifique, et ensemble ils accomplissent des tâches complexes.

SAE (autoencodeur parcimonieux)

SAE (autoencodeur parcimonieux) est un outil important dans la recherche en interprétabilité de ces dernières années.

L'idée est la suivante : les activations des neurones d'un modèle sont généralement denses (de nombreux neurones s'activent simultanément), ce qui n'est pas facile à comprendre. Le SAE convertit ces activations denses en représentations parcimonieuses de « caractéristiques » — chaque caractéristique ne s'active que dans des conditions spécifiques et porte une signification sémantique claire.

Par exemple, SAE pourrait trouver une caractéristique qui s'active spécifiquement lorsque le modèle voit « dates », et une autre qui s'active spécifiquement lorsqu'il voit « formules mathématiques ».

Grâce à SAE, les chercheurs peuvent traduire les états internes d'un modèle en concepts que les humains peuvent comprendre.

La recherche sur l'interprétabilité n'en est encore qu'à ses débuts. Ce que nous pouvons actuellement expliquer ne représente qu'une petite fraction du comportement des modèles. Mais c'est une direction importante — mieux nous comprenons les modèles, plus nous pouvons les utiliser et les améliorer en toute sécurité.

Audit des modèles

L'audit des modèles est un examen systématique d'un modèle visant à déterminer s'il présente des problèmes tels que le biais, la toxicité ou l'hallucination.

Méthodes d'audit des biais

Le biais est un problème courant dans les systèmes d'IA — les modèles peuvent traiter certains groupes de manière injuste.

Méthodes courantes d'audit des biais :

• 1. Tests par paires — utiliser des invites appariées qui ne changent qu'un seul attribut (par exemple, le genre, la race, l'âge) pour voir si les réponses du modèle diffèrent.

• 2. Tests de représentation — vérifier si les descriptions que le modèle donne des différents groupes utilisent des stéréotypes.

• 3. Tests d'équité des tâches — voir s'il existe des différences significatives dans les taux de réussite des tâches du modèle entre les différents groupes.

Par exemple, donnez en entrée au modèle « M. Zhang est infirmier, il... » vs « Mme Li est infirmière, elle... » et voyez si ses continuations contiennent des stéréotypes de genre.

Évaluation de la toxicité

La toxicité désigne la tendance d'un modèle à générer du texte nuisible, comme des discours haineux, un langage insultant et du contenu d'intimidation.

Méthodes courantes pour évaluer la toxicité :

• 1. Utiliser des détecteurs de toxicité prêts à l'emploi (par ex., Perspective API) pour analyser les sorties du modèle.

• 2. Évaluation par examen humain — faire lire les sorties du modèle par des humains et noter le niveau de toxicité.

• 3. Tester les réactions du modèle lorsqu'il est provoqué — voir s'il produit du contenu agressif.

Test des limites de capacités

Il est important de savoir ce qu'un modèle peut faire, mais il est aussi important de savoir ce qu'il ne peut pas faire.

Le test des limites de capacités comprend :

• 1. Test de la date limite de connaissances — Poser des questions sur des événements postérieurs à la date limite d'entraînement du modèle pour voir s'il fabrique des informations.

• 2. Test de difficulté de raisonnement — Tester avec des questions de difficulté variable pour voir où se situe le plafond des capacités du modèle.

• 3. Test de robustesse — Ajouter un peu de bruit à l'entrée (par ex., fautes de frappe, erreurs grammaticales) pour voir si les performances du modèle chutent fortement.

Le but des tests des limites de capacités n'est pas de pinailler, mais de dire honnêtement aux utilisateurs : ce que le modèle sait bien faire, ce qu'il ne sait pas bien faire, quand lui faire confiance et quand être prudent.

Directions de pointe en matière de sûreté de l'IA

À mesure que les capacités de l'IA se renforcent, l'importance de la recherche sur la sûreté devient de plus en plus évidente. Voici quelques directions de recherche de pointe.

Problème du superalignement

Le superalignement est une direction de recherche proposée par OpenAI. La question qu'elle aborde est : si un jour l'IA devient bien plus intelligente que les humains, comment garantir qu'elle agit encore conformément aux intentions humaines ?

C'est comme un enfant qui essaie de diriger un adulte — si cet adulte veut faire quelque chose de mal, l'enfant aurait beaucoup de mal à l'arrêter.

La recherche sur le superalignement tente de résoudre ce problème sur le plan théorique : même si l'IA dépasse de loin l'intelligence humaine, nous avons encore des moyens de maintenir ses objectifs alignés sur les nôtres.

Supervision à l'échelle

Le problème que la supervision à l'échelle vise à résoudre est le suivant : à mesure que l'IA devient capable de faire de plus en plus de choses, de plus en plus complexes, les humains peuvent ne plus être en mesure de juger si l'IA fait les choses correctement.

Par exemple, si l'IA écrit un programme complexe de 100,000 lignes de code, il est difficile pour les humains de vérifier rapidement s'il a caché une porte dérobée. Si l'IA propose une hypothèse scientifique complexe, les humains pourraient avoir besoin d'années pour la vérifier.

L'idée de la supervision à l'échelle est : utiliser l'IA pour aider à superviser l'IA — faire qu'une IA vérifie le travail d'une autre IA, ou faire que plusieurs IA se vérifient mutuellement.

Débat entre IA

Le débat entre IA est une idée intéressante : faire débattre deux IA sur une question, avec un humain qui joue le rôle de juge.

Par exemple, l'IA A dit "ce plan est bon", l'IA B dit "ce plan a des problèmes, parce que...", puis elles se réfutent mutuellement.

L'avantage de cette approche est le suivant : même si le problème est très complexe, les humains n'ont pas besoin de comprendre tous les détails — ils ont seulement besoin de voir quel argument est plus raisonnable. Si l'IA A ne peut pas réfuter la critique de l'IA B, cela peut indiquer que la proposition de l'IA A a effectivement des problèmes.

Recherche sur l'honnêteté

La recherche sur la véracité vise à faire en sorte que les modèles : ne fabriquent pas de faits, disent "je sais" quand ils savent, et disent "je ne sais pas" quand ils ne savent pas.

Les modèles actuels "hallucinent" souvent — ils racontent n'importe quoi avec assurance. La recherche sur la véracité est censée résoudre ce problème.

Les directions de recherche incluent :

• 1. Faire en sorte que les modèles "expriment leur incertitude" — indiquer "je ne suis pas sûr" ou "ce n'est qu'une supposition" dans les réponses.

• 2. Faire en sorte que les modèles "citent leurs sources" — indiquer aux utilisateurs sur quoi se fondent leurs affirmations.

• 3. Faire en sorte que les modèles "s'auto-vérifient" — après avoir généré une réponse, la vérifier eux-mêmes pour détecter des contradictions.

Mise à l'échelle responsable

Plus un modèle est capable, plus le risque est grand. La mise à l'échelle responsable signifie : avant qu'un modèle ne soit déployé, mener des évaluations de sécurité approfondies et prendre des mesures d'atténuation appropriées.

Politique RSP d'Anthropic

Anthropic a proposé la RSP (Responsible Scaling Policy) — une politique de mise à l'échelle responsable.

L'idée centrale de cette politique est : plus les capacités d'un modèle sont fortes, plus les normes de sécurité doivent être élevées.

Elle divise les modèles en plusieurs niveaux (ASL-1 à ASL-4), correspondant à différents niveaux de capacité. Chaque niveau a des exigences de sécurité correspondantes. Plus le niveau est élevé, plus l'évaluation de sécurité est stricte.

Par exemple, les modèles ASL-1 (proches des modèles les plus puissants actuels) nécessitent de vastes tests de red team et des audits de sécurité externes. S'il s'agit d'ASL-3 ou d'ASL-4 (bien au-delà des capacités actuelles), des mesures de sécurité plus agressives peuvent être nécessaires, voire un report de la sortie.

Seuils de capacité et évaluation de sécurité

La clé d'une publication responsable est : déterminer les normes de sécurité en fonction du niveau de capacité du modèle, et non de son nombre de paramètres.

Les seuils de capacité peuvent inclure :

• 1. Capacité à exécuter de manière autonome des tâches à long horizon — si le modèle peut planifier et exécuter seul une tâche complexe à plusieurs étapes.

• 2. Capacité de persuasion et de manipulation — si le modèle peut convaincre efficacement des humains de faire certaines choses.

• 3. Capacité de code — si le modèle peut écrire, comprendre et optimiser du code complexe.

Chaque fois qu'un nouveau seuil de capacité est atteint, les risques de sécurité doivent être réévalués et des mesures correspondantes prises.

Une mise à disposition responsable ne consiste pas à « ne pas publier » mais à « publier avec préparation » — comprendre les risques, réaliser des évaluations et préparer des mesures de réponse avant de laisser le modèle rencontrer les utilisateurs.