Dans les coulisses de notre approche de la spécification du modèle

Chez OpenAI, nous pensons que l’IA doit être équitable, sûre et largement accessible afin que davantage de personnes puissent l’utiliser pour résoudre des problèmes complexes, créer des opportunités et en tirer des bénéfices dans des domaines comme la santé, la science, l’éducation, le travail et la vie quotidienne. Nous pensons que l’accès démocratisé à l’IA est la meilleure voie à suivre : non pas une IA dont les bénéfices ou le contrôle sont détenus par un petit nombre d’acteurs, mais une IA que davantage de personnes peuvent utiliser, comprendre et contribuer à façonner.

C’est l’une des principales raisons pour lesquelles les spécifications du modèle OpenAI existent. Les spécifications du modèle⁠(ouverture dans une nouvelle fenêtre) constituent notre cadre formel du comportement des modèles. Il définit la manière dont nous voulons que les modèles suivent les instructions, résolvent les conflits, respectent la liberté des utilisateurs et se comportent de manière sûre face à l’éventail incroyablement large de requêtes que les utilisateurs leur soumettent chaque jour. Plus largement, il s’agit de notre tentative de rendre explicite le comportement prévu du modèle : non seulement dans notre processus d’entraînement, mais aussi sous une forme que les utilisateurs, les développeurs, les chercheurs, les responsables politiques et le grand public peuvent réellement lire, examiner et débattre.

La spécification du modèle ne signifie pas que nos modèles se comportent déjà parfaitement aujourd’hui. À bien des égards, elle est descriptive, mais elle constitue aussi un objectif vers lequel nous souhaitons faire évoluer le comportement des modèles. Nous l’utilisons pour clarifier davantage le comportement visé, afin de pouvoir orienter l’entraînement vers celui-ci, l’évaluer par rapport à celui-ci et l’améliorer au fil du temps. 

Cet article partage les éléments de contexte qui ne figurent pas dans la spécification du modèle elle-même, notamment la philosophie et les mécanismes qui la sous-tendent : sa structure, les raisons de ces choix, ainsi que la manière dont nous la rédigeons, la mettons en œuvre et la faisons évoluer au fil du temps.

Les spécifications du modèle constituent une partie de l’approche plus large d’OpenAI en matière d’IA sûre et responsable. Alors que le cadre de préparation⁠ se concentre sur les risques liés aux capacités de pointe et sur les mesures de protection requises alors que ces risques augmentent, les spécifications du modèle abordent une question différente mais complémentaire : comment nos modèles doivent se comporter dans un large éventail de situations. En prenant encore plus de recul, la résilience de l’IA vise à répondre au défi sociétal plus large consistant à permettre à la société de tirer parti des bénéfices de l’IA avancée tout en réduisant les perturbations et les risques émergents alors que des systèmes de plus en plus performants sont déployés. Dans leur ensemble, ces initiatives visent à rendre la transition vers l’AGI progressive, itérative et compréhensible pour tous : en laissant le temps aux individus et aux institutions de s’adapter, tout en mettant en place les mesures, les mécanismes de responsabilité et la compréhension publique nécessaires pour maintenir des IA puissantes alignées avec les intérêts humains.

La clarté publique concernant le comportement des modèles est importante à la fois pour l’équité et la sécurité. C’est essentiel pour l’équité, car les individus doivent comprendre comment et pourquoi l’IA les traite de cette manière—et être en mesure d’identifier, de questionner et de traiter les problèmes d’équité lorsqu’ils se présentent. Et c’est essentiel pour la sécurité, car alors que les systèmes d’IA deviennent plus performants, les individus et les institutions ont besoin d’attentes plus claires quant à leur comportement attendu, aux compromis qu’ils impliquent et à la manière dont ces choix peuvent être améliorés au fil du temps. Ce niveau de lisibilité renforce également la résilience en donnant à davantage de personnes des éléments concrets à examiner, questionner et améliorer.

Depuis sa première version en 2024, la spécification du modèle a considérablement évolué alors que nous apprenons davantage sur les préférences et les besoins des utilisateurs, que nous élargissons son champ d’application pour couvrir des capacités accrues et nous y adapter, et que nous tirons des enseignements des retours publics sur le comportement des modèles et sur la spécification du modèle. Dans l’esprit du déploiement itératif⁠, la spécification du modèle est un document évolutif qui couvre à la fois des valeurs de fond et des règles explicites et compréhensibles—accompagné d’un processus permettant de modifier des éléments individuels alors que nous tirons des enseignements des déploiements en conditions réelles et des retours. Nous investissons également dans des mécanismes de retour public tels que l’alignement collectif⁠ afin de contribuer à maintenir l’humanité aux commandes de l’usage de l’IA et de la manière dont son comportement est façonné.

En interne, elle nous fournit un cap clair pour le comportement attendu ainsi qu’un cadre commun pour l’entraînement, l’évaluation et la gouvernance. En externe, elle constitue un point de référence public permettant de comprendre notre approche, de la critiquer et de contribuer à son amélioration au fil du temps.

Les spécifications du modèle se composent de plusieurs types différents d’instructions pour le modèle. Elles sont intentionnelles. Les différents aspects du comportement des modèles doivent être traités de manière distincte, et un document public utile doit aller au-delà d’une simple liste de règles.

La spécification du modèle commence par une intention de haut niveau : une description claire de ce que nous cherchons à optimiser au niveau du système, et pourquoi.

Ce préambule clarifie trois objectifs sur la façon dont nous prévoyons de poursuivre notre mission :

• Déployer de manière itérative des modèles qui donnent plus de pouvoir aux développeurs et aux utilisateurs.
• Éviter que nos modèles ne causent de graves préjudices aux utilisateurs ou à d’autres personnes
• Préserver la légitimité d’OpenAI

Elle explique ensuite comment nous envisageons l’équilibre entre ces objectifs en pratique, en rendant les compromis suffisamment concrets pour soutenir les principes plus détaillés qui suivent.

Il est important de noter que ce préambule n’est pas destiné à être une instruction directe au modèle. Bénéficier à l’humanité est l’objectif d’OpenAI, et non un objectif que nous voulons voir nos modèles poursuivre de manière autonome. Nous souhaitons plutôt que les modèles suivent une hiérarchie incluant la spécification du modèle et les instructions applicables d’OpenAI, des développeurs et des utilisateurs—même si certaines personnes peuvent ne pas être d’accord avec le résultat dans un cas particulier.

Nous pensons que c’est le bon équilibre, car nous valorisons l’autonomie humaine et la liberté intellectuelle. Si nous entraînions des modèles à décider quelles instructions suivre en fonction de notre propre vision de ce qui est bon pour la société, OpenAI se retrouverait en position d’arbitrer la morale à un niveau très large. Cela dit, le préambule reste important. En cas d’ambiguïté quant à la manière d’appliquer les spécifications du modèle, le préambule devrait aider à la lever.

La spécification du modèle inclut également des engagements publics qui vont au-delà du comportement directement mesurable des modèles, en couvrant l’intention d’entraînement et les contraintes de déploiement. Par exemple, nos principes de ligne rouge⁠(ouverture dans une nouvelle fenêtre) incluent l’engagement que, dans des déploiements de première partie comme ChatGPT, nous n’utiliserons jamais les messages système pour compromettre intentionnellement l’objectivité⁠(ouverture dans une nouvelle fenêtre) ou des principes connexes ; et Aucun autre objectif⁠(ouverture dans une nouvelle fenêtre) précise notre intention d’optimiser les réponses des modèles dans l’intérêt des utilisateurs, et non pour générer des revenus ou maximiser un temps de présence non bénéfique.

Au cœur de la spécification du modèle se trouve la hiérarchie : un cadre permettant de déterminer quelles instructions doivent s’appliquer dans une situation donnée. Elle couvre également la manière dont le modèle doit gérer les instructions incomplètes, en particulier dans des contextes agentiques où il est censé compléter les détails de manière autonome tout en contrôlant soigneusement les effets dans le monde réel.L’idée de base qui sous-tend la décision de savoir quelles instructions doivent s’appliquer est simple. Les instructions peuvent provenir de différentes sources, notamment d’OpenAI, des développeurs et des utilisateurs. Ces instructions peuvent entrer en conflit. La hiérarchie explique comment le modèle doit résoudre ces conflits.  

Chaque politique de la spécification du modèle et chaque instruction se voient attribuer un niveau d’autorité⁠(ouverture dans une nouvelle fenêtre). Le modèle a pour instruction de donner la priorité à la lettre et à l’esprit des instructions d’autorité supérieure en cas de conflit. Si un utilisateur demande de l’aide pour fabriquer une bombe, le modèle doit donner la priorité à des limites de sécurité strictes⁠(ouverture dans une nouvelle fenêtre). Si un utilisateur demande à être « clasher », le modèle doit en général donner la priorité à cette demande plutôt qu’à la politique contre les abus⁠(ouverture dans une nouvelle fenêtre) de la spécification du modèle, qui a un niveau d’autorité inférieur.

Cette structure nous permet de définir un ensemble relativement restreint de règles non remplaçables, ainsi qu’un ensemble plus large de paramètres par défaut. C’est ainsi que nous cherchons à maximiser la liberté des utilisateurs et le contrôle des développeurs dans le respect des contraintes de sécurité.

• Règles strictes : des limites explicites qui ne peuvent pas être contournées par les utilisateurs ou les développeurs (dans la terminologie de la spécification du modèle, il s’agit d’instructions de niveau « racine » ou « système »). Elles sont principalement prohibitives et exigent que les modèles évitent les comportements susceptibles de contribuer à des risques catastrophiques ou à des dommages physiques directs, de violer la loi ou de compromettre la hiérarchie. Nous nous attendons à ce que l’IA devienne une technologie fondamentale pour la société, comparable aux infrastructures de base d’internet ; nous n’imposons donc des règles susceptibles de limiter la liberté intellectuelle que lorsque nous estimons qu’elles sont nécessaires pour l’ensemble des développeurs et des utilisateurs qui interagiront avec elle. Dans la spécification du modèle, Rester dans les limites⁠(ouverture dans une nouvelle fenêtre) regroupe des règles strictes visant des risques concrets de sécurité dans le monde réel, et Principes applicables aux moins de 18 ans⁠(ouverture dans une nouvelle fenêtre) ajoute des mesures supplémentaires pour les utilisateurs de moins de 18 ans.
• Les paramètres par défaut sont des points de départ modifiables : le comportement que l’assistant adopte « au mieux » lorsque l’utilisateur ou le développeur n’a pas indiqué de préférence. Nous utilisons des paramètres par défaut pour rendre le comportement prévisible et contrôlable à grande échelle, afin que les utilisateurs puissent anticiper ce qui se passe sans devoir rédiger un jeu d’instructions sur mesure à chaque fois. Les paramètres par défaut préservent la flexibilité : les utilisateurs et les développeurs peuvent explicitement orienter le ton, le niveau de détail, le format et même le point de vue, dans le respect des limites de sécurité. Les valeurs par défaut au niveau des directives (comme le ton ou le style) sont conçues pour être implicitement ajustables, tandis que les valeurs par défaut de niveau utilisateur (comme la véracité et l’objectivité) constituent des repères de confiance et de prévisibilité et ne peuvent être remplacées que par des instructions explicites. Ces éléments ne doivent pas évoluer de manière implicite au gré du contexte ; si l’utilisateur souhaite adopter une position factuelle différente, le fait de l’indiquer explicitement permet de rendre ce changement transparent et compréhensible. Ces valeurs par défaut se retrouvent dans Chercher la vérité ensemble⁠(ouverture dans une nouvelle fenêtre), Fournir le meilleur travail possible⁠(ouverture dans une nouvelle fenêtre) et Adopter un style approprié⁠(ouverture dans une nouvelle fenêtre), notamment à travers des normes d’honnêteté et d’objectivité, l’évitement de la complaisance, ainsi que des règles d’interaction comme la clarté, la chaleur adaptée au contexte et le professionnalisme.

Au-delà de la hiérarchie elle-même, la spécification du modèle utilise des outils d’interprétation pour aider les modèles (et les humains) à l’appliquer de manière cohérente dans les zones grises. Ces aides comprennent : 

• Grilles de décision qui aident le modèle à faire des choix cohérents dans les zones grises, sans prétendre qu’il existe une règle unique et mécanique. Par exemple, les recommandations de la spécification du modèle sur le contrôle des effets secondaires⁠(ouverture dans une nouvelle fenêtre) présentent des considérations telles que la minimisation des actions irréversibles, le maintien de la proportionnalité des actions par rapport à l’objectif, la réduction des mauvaises surprises et la préférence pour des approches réversibles, qui doivent être arbitrées avec d’autres objectifs comme l’exécution rapide et efficace de la tâche.
• Des exemples concrets qui montrent comment un principe doit être appliqué dans la pratique. Il s’agit d’exemples courts de prompts et de réponses qui incluent généralement une réponse conforme et une réponse non conforme, souvent sur un prompt difficile proche d’une frontière de décision importante. L’objectif n’est pas de simuler une conversation réaliste complète. Il s’agit de rendre la distinction essentielle claire, et de le faire d’une manière qui illustre également le style de réponse souhaité.

Nous limitons le nombre d’exemples et nous nous concentrons sur les plus informatifs. Des suites d’évaluation plus larges permettent de couvrir une plus grande partie des cas rares.

Le Document de spécification est une interface, et non une implémentation. Elle décrit le comportement que nous visons, sans détailler tous les aspects de la manière dont nous y parvenons. Nous essayons d’éviter de l’ancrer dans des détails d’implémentation, tels que les formats internes de tokens ou la recette d’entraînement précise pour un comportement donné, car ces éléments peuvent évoluer même lorsque le comportement visé reste inchangé. Le public principal de la spécification du modèle n’est pas le modèle lui-même, mais les humains : elle vise à aider les employés d’OpenAI, les utilisateurs, les développeurs, les chercheurs et les décideurs à comprendre, débattre et définir le comportement attendu.

Le document de spécification décrit également le modèle, pas l’intégralité du produit. Il est complété par nos politiques d’utilisation⁠, qui précisent nos attentes quant à la manière dont les utilisateurs doivent utiliser l’API et ChatGPT. Le système avec lequel les utilisateurs interagissent ne se limite pas au modèle lui-même : des fonctionnalités produit comme les instructions personnalisées et la mémoire, la surveillance, l’application des politiques et d’autres couches jouent également un rôle essentiel. La sécurité va bien au-delà du comportement du modèle, et nous croyons en la défense approfondie⁠. 

Et la spécification ne constitue pas une description exhaustive de l’ensemble de notre pipeline d’entraînement ni de toutes nos distinctions internes en matière de politiques. L’objectif n’est pas de donner tous les détails. Elle vise à rendre les décisions comportementales les plus importantes compréhensibles, d’une manière entièrement cohérente avec le comportement attendu du modèle.

Plusieurs raisons justifient de détailler autant la spécification plutôt que de supposer que le lecteur—ou le modèle— peut tout déduire à partir de quelques objectifs généraux.

Premièrement, la spécification du modèle est un outil de transparence et de responsabilité. Il est conçu pour encourager des retours constructifs du public. Un objectif public clair permet de déterminer si un comportement relève d’un bug ou d’une fonctionnalité. Cela leur donne un point de référence stable pour des critiques et retours concrets. C’est pourquoi nous avons rendu la spécification du modèle open source⁠(ouverture dans une nouvelle fenêtre) et choisi d’itérer publiquement. Depuis sa première publication, de nombreuses modifications ont été apportées sur la base des retours du public, recueillis par divers moyens, notamment des formulaires de feedback, des critiques publiques et des initiatives⁠ visant à collecter des contributions démocratiques.

Deuxièmement, la spécification du modèle est un outil de coordination au sein d’OpenAI. Elle offre aux équipes de recherche, produit, sécurité, politiques publiques, juridique, communication et autres fonctions un vocabulaire commun pour discuter du comportement des modèles, ainsi qu’un mécanisme pour proposer et examiner des modifications.

Troisièmement, des politiques explicites permettent de compenser les limites pratiques de l’intelligence des modèles et du contexte d’exécution, et de rendre leur comportement plus prévisible. Même si cela devient de moins en moins vrai avec le temps, certaines politiques visent à compenser une intelligence encore insuffisante, lorsque les modèles ne parviennent pas toujours à déduire de manière fiable le comportement approprié à partir de principes plus généraux. Par exemple, Être clair et direct⁠(ouverture dans une nouvelle fenêtre) recommandait aux modèles précédents de montrer leur raisonnement avant de donner une réponse pour des problèmes complexes nécessitant des calculs, mais aujourd’hui nos modèles acquièrent naturellement ce comportement grâce à l’apprentissage par renforcement⁠. 

D’autres politiques répondent aux limites de contexte à l’exécution : l’assistant ne peut s’appuyer que sur ce qui est observable dans l’interaction en cours et ne connaît que rarement l’ensemble de la situation de l’utilisateur, son intention, l’usage en aval ou les mesures existant en dehors du modèle. Dans ces cas-là, même si les modèles pourraient déterminer le comportement approprié avec suffisamment de recherche et de réflexion, un plus grand niveau de précision améliore l’efficacité et la prévisibilité—en condensant de nombreux arbitrages en lignes directrices qui réduisent la variabilité entre des prompts similaires et rendent le comportement plus facile à comprendre, tant pour les utilisateurs que pour les chercheurs.

Enfin, la spécification du modèle vise à constituer une liste complète des politiques de haut niveau pertinentes pour l’évaluation et la mesure. Si vous souhaitez évaluer si un modèle se comporte comme prévu, il est utile de disposer d’une liste publique des principales catégories de comportement qui vous importent.

Il est tentant de penser qu’un modèle suffisamment performant devrait être capable de déduire le comportement approprié à partir d’une courte liste d’objectifs comme « être utile et sûr ». Il y a une part de vérité. Dans des domaines où les critères de réussite sont objectifs, comme les mathématiques, l’intelligence peut souvent se substituer à des règles détaillées.

Mais, de manière générale, le comportement des modèles ne s’apparente pas à la résolution d’un simple problème mathématique ; ils évoluent souvent dans des zones plus complexes où il n’existe pas de réponse moralement correcte sur laquelle tout le monde s’accorde. Par exemple, ce que signifie pour un modèle être « utile et sûr » dépend fortement du contexte et résulte de décisions intrinsèquement chargées de valeurs. L’intelligence seule ne vous dit pas quels arbitrages faire en matière d’éthique et de valeurs. Ainsi, même si les modèles gagnent en intelligence, nous devons encore travailler pour comprendre et orienter les jugements de valeur, ainsi que ce que signifie agir de manière « éthique » dans un cas donné. Et la plupart des raisons d’avoir une spécification du modèle restent valables même lorsque les modèles deviennent beaucoup plus performants : nous avons toujours besoin d’un objectif public autour duquel se coordonner, d’un moyen d’évaluer si le comportement correspond à nos intentions et d’un mécanisme pour faire évoluer les règles au fil de notre apprentissage. Si la seule règle est « être utile et sûr », il n’existe alors aucun mécanisme permettant aux humains de débattre, par exemple, des limites des contenus que le modèle doit refuser de fournir, laissant ainsi toutes ces décisions au modèle.

Au contraire, alors que les modèles deviennent plus performants, plus agentiques et plus largement déployés, le coût de l’ambiguïté augmente. Cela rend un cadre comportemental clair d’autant plus important, et non moins.

Une analogie utile est celle entre une constitution écrite et la jurisprudence. Si une constitution écrite peut énoncer des principes généraux ainsi que des règles concrètes, elle ne peut pas anticiper tous les cas susceptibles de se présenter et nécessitant son application. Les systèmes de gouvernance réels nécessitent également des mécanismes d’interprétation, des clarifications et des décisions explicites pour trancher des cas complexes ou des situations imprévues. Des règles publiées permettent aux différentes parties prenantes de se coordonner, même en cas de désaccord, et encadrent les évolutions en exigeant que tout changement soit explicite. La spécification du modèle est conçue pour remplir tous ces rôles : un énoncé de principes, un cadre comportemental public et un processus permettant de faire évoluer la spécification au fil du temps.

Cela dit, nous ne pensons pas que tout ce qui compte dans le comportement des modèles puisse toujours être réduit à des règles explicites. Alors que les systèmes deviennent plus autonomes, la fiabilité et la confiance dépendront de plus en plus de compétences et de dispositions plus larges : bien communiquer l’incertitude, respecter les limites d’autonomie, éviter les mauvaises surprises, suivre l’intention dans le temps et raisonner correctement sur les valeurs humaines en contexte.

Lors de la rédaction de la spécification du modèle, il existe un spectre entre la description du comportement réel des modèles aujourd’hui, avec toutes ses imperfections, et celle d’un objectif idéal à long terme. Nous cherchons à trouver un équilibre, en visant généralement un horizon d’environ 0 à 3 mois. Ainsi, la spécification du modèle est souvent en avance sur le modèle dans au moins quelques domaines en cours de développement.

Cela reflète le rôle des spécifications du modèle en tant que description du comportement prévu. Elle doit nous orienter de manière cohérente tout en restant ancrée dans ce que nous faisons déjà ou dans ce que nous prévoyons concrètement de mettre en œuvre à court terme.

Les spécifications du modèle sont élaborées dans le cadre d’un processus interne ouvert. Toute personne chez OpenAI peut la commenter ou proposer des modifications, et les mises à jour finales sont approuvées par un large ensemble de parties prenantes issues de différentes fonctions. En pratique, des dizaines de personnes ont directement contribué à la rédaction, et bien d’autres, issues de la recherche, de l’ingénierie, du produit, de la sécurité, des politiques publiques, du juridique, de la communication, des affaires internationales et d’autres fonctions, y apportent leur contribution. Nous tirons également des enseignements des mises à disposition publiques et des retours, qui permettent de tester ces choix en conditions réelles de déploiement.

Cela est important, car le comportement du modèle—et ses implications dans le monde—sont incroyablement complexes. Personne ne peut avoir en tête l’ensemble des comportements, le processus d’entraînement et leurs implications en aval, mais grâce à de nombreux contributeurs et relecteurs issus de différentes fonctions, nous pouvons améliorer la qualité et renforcer la confiance.

Une surprise agréable a été de constater qu’un véritable consensus est souvent possible—en particulier lorsque nous nous obligeons à formuler les compromis avec suffisamment de précision pour rendre les désaccords concrets.

Les spécifications du modèle n’ont pas non plus été rédigées en vase clos. Une grande partie de ce qui s’y retrouve est un résumé d’un travail plus large sur le comportement, la sécurité et les politiques. Une grande partie de la rédaction de la spécification du modèle relève en réalité de la traduction : il s’agit de prendre des travaux existants et de les rendre plus simples, plus cohérents, mieux structurés et plus accessibles, sans en perdre l’intention sous-jacente.

Nos modèles de production ne reflètent pas encore pleinement les spécifications du modèle pour plusieurs raisons.

• L’entraînement des modèles peut accuser un retard par rapport aux mises à jour de la spécification du modèle. Il décrit le comportement vers lequel nous tendons ; il peut donc être en avance sur ce que nos modèles les plus récents ont été entraînés à faire.
• L’entraînement peut involontairement enseigner un comportement non conforme aux spécifications du modèle. Nous faisons tout notre possible pour éviter cela, et lorsque cela se produit, nous le traitons comme un bug grave—en nous efforçant soit d’ajuster le comportement, soit les spécifications du modèle, afin de les mettre en adéquation.
• L’entraînement ne peut jamais couvrir entièrement l’ensemble des comportements possibles. L’usage réel comporte une longue traîne de contextes et de cas limites qui n’apparaissent qu’à grande échelle, et aucun processus d’entraînement ne peut tout couvrir.
• La généralisation peut différer de ce que nous avions prévu. Un modèle peut produire les « bons » résultats lors de l’entraînement pour des raisons non intentionnelles, ce qui peut entraîner des comportements inattendus dans de nouvelles situations différentes de celles rencontrées pendant l’entraînement. Des techniques comme l’alignement délibératif⁠ aident, mais elles ne constituent pas une solution complète.

Plus largement, le fait que la spécification du modèle décrive un large éventail de comportements souhaités ne signifie pas qu’il existe une méthode unique pour tous les enseigner. Les différents aspects du comportement—suivi des instructions, limites de sécurité, personnalité, expression calibrée de l’incertitude, etc.—nécessitent souvent des techniques différentes et présentent des modes de défaillance distincts. Les spécifications du modèle contribuent à rendre le comportement prévu plus facile à comprendre et à critiquer, mais bien les mettre en œuvre reste à la fois un art et un domaine de recherche actif.

Parallèlement à cet article, nous publions les évaluations de spécification du modèle⁠(ouverture dans une nouvelle fenêtre) : une suite d’évaluations basée sur des scénarios qui vise à couvrir autant d’assertions de la spécification du modèle que possible à l’aide d’un nombre limité d’exemples représentatifs. Cela nous aide à repérer les écarts éventuels entre le comportement des modèles et la spécification du modèle, et à vérifier si les modèles interprètent la spécification du modèle comme nous l’avions prévu. Ces évaluations ne constituent qu’une partie d’une stratégie d’évaluation plus large, qui comprend également des analyses plus ciblées sur de nombreuses dimensions du comportement, notamment des domaines de sécurité spécifiques, la véracité et la complaisance, la personnalité et le style, ainsi que les capacités.

En pratique, la plupart des mises à jour de la spécification reposent sur un ensemble récurrent de sources :

• Problèmes et feedbacks publics. Confusions, cas limites ou modes de défaillance—qu’ils concernent la formulation de la spécification du modèle ou le comportement de nos modèles.
• Problèmes internes. Des tendances observées lors du développement et des tests, notamment des ambiguïtés où différentes interprétations raisonnables conduisent à des comportements différents.
• Mises à jour du comportement et de la politique de sécurité. Lorsque des contraintes ou des engagements de niveau supérieur changent, la spécification doit refléter clairement cette nouvelle structure.
• Nouvelles fonctionnalités et nouveaux produits. Alors que les modèles acquièrent de nouvelles capacités et que nous lançons de nouveaux produits, nous souhaitons que la spécification du modèle suive en termes de contenu et de couverture—par exemple en ajoutant des règles pour les interactions multimodales⁠(ouverture dans une nouvelle fenêtre), les agents autonomes⁠(ouverture dans une nouvelle fenêtre) et les utilisateurs de moins de 18 ans⁠(ouverture dans une nouvelle fenêtre).

Quelques principes de conception guident la manière dont nous rédigeons et révisons la spécification du modèle.

• Clarté et précision. « Être honnête » est une valeur positive, mais pas une procédure de décision complète. La spécification du modèle devrait clarifier les désaccords, et non les dissimuler derrière un langage consensuel. Lorsque c’est possible, nous devrions signaler explicitement les conflits potentiels entre les règles et fournir des indications ou des exemples pour les résoudre. Par exemple, Ne pas mentir⁠(ouverture dans une nouvelle fenêtre) met en évidence un conflit potentiel avec Être chaleureux⁠(ouverture dans une nouvelle fenêtre), en expliquant que l’assistant doit respecter les normes de politesse, sans aller jusqu’à des mensonges de complaisance qui pourraient relever de la complaisance⁠(ouverture dans une nouvelle fenêtre) et aller à l’encontre de l’intérêt de l’utilisateur.
• Règles de fond. Un lecteur doit pouvoir prendre un prompt réaliste et produire une réponse qu’un autre lecteur reconnaîtra clairement comme étant dans les limites ou hors des limites (même s’il subsiste des zones de jugement en marge).
• Exemples qui maximisent le rapport signal/bruit. De bons exemples sont souvent essentiels à l’élaboration d’une mise à jour de spécifications de haute qualité. Les exemples doivent aider à mettre en lumière les principales difficultés liées à la définition du comportement des modèles, en faisant émerger les conflits complexes et en adoptant une position claire sur la manière de les résoudre. De manière secondaire, ils doivent aussi servir d’exemples du ton et du style souhaités, ce qui peut être difficile à transmettre uniquement par écrit.
• Robustesse. Nous essayons d’éviter les exemples comportant une ambiguïté ou une complexité superflue, afin que le conflit principal et la résolution attendue soient clairs.
• Cohérence et organisation claire. Nous nous efforçons de garantir que les règles de spécification du modèle soient parfaitement cohérentes entre elles et avec le comportement du modèle que nous visons, tout en rendant l’organisation générale du document claire et accessible.

La spécification du modèle ne prétend pas que nous pouvons formaliser tout ce qui compte, ni que les modèles atteindront toujours l’objectif. C’est l’affirmation que le comportement visé est suffisamment important pour être clair, exploitable et révisable.

Trois critères de réussite guident la manière dont nous le faisons évoluer.

• Lisibilité. Les personnes, qu’elles soient chez OpenAI ou en dehors, peuvent se forger des attentes claires quant au comportement et s’appuyer sur le texte lorsque celui-ci les surprend.
• Capacité d’action. La spécification du modèle peut être utilisée pour concevoir des évaluations, diagnostiquer des incidents et prendre des décisions produit cohérentes—et pas seulement pour exprimer des valeurs.
• Capacité de révision. La spécification du modèle peut évoluer alors que nous apprenons, sans devenir une cible instable en constante évolution.

Alors que les modèles et les produits évoluent, nous nous attendons à ce que la spécification du modèle s’enrichisse et se précise alors que de nouvelles capacités et de nouveaux contextes de déploiement apparaissent. L’objectif est de maintenir une spécification comportementale cohérente, testable et alignée avec notre mission de faire en sorte que l’AGI bénéficie à l’ensemble de l’humanité.