← Réflexions et guides

Guide

Entretenir les consignes partagées pour l’IA : vérifier les modifications et conserver les versions

Un accord pratique pour entretenir les consignes partagées : objectif, cas d’essai, modifications, validation et retour à une version antérieure.

Par Dr. Sven JungmannDate de référence rétrospective: · Publié: · Vérifié:
Une pièce remplaçable est épinglée sur un patron réutilisable.

L’essentiel

  • Évaluez une modification de formulation par rapport au comportement attendu.
  • Une version vérifiée comprend la consigne, son environnement, les exemples et une personne responsable joignable.
  • Une ancienne version du texte ne peut pas rétablir entièrement le comportement d’un modèle remplacé depuis.

Une consigne partagée pour l’IA peut évoluer rapidement. Une personne ajoute une formulation, une collègue retire un paragraphe et une nouvelle version du modèle devient disponible. Chaque modification peut sembler raisonnable. Quelques semaines plus tard, il reste pourtant difficile d’expliquer pourquoi une même tâche produit des résultats différents. Pour moi, entretenir une consigne commence donc par une question simple : quelle version a produit quel comportement, dans quelles conditions ?

Ce guide concerne des consignes destinées à des tâches organisationnelles délimitées. Son exemple est fictif : une entreprise de technologies médicales utilise un modèle de consigne pour rédiger une liste interne d’actions à partir de notes de réunion autorisées. Les informations personnelles ou confidentielles ne peuvent être traitées que dans l’environnement effectivement autorisé à cette fin. Une consigne bien rédigée n’élargit pas cette autorisation. La démarche décrite ici n’autorise pas non plus son utilisation pour des décisions concernant un patient en particulier.

Pourquoi vérifier une amélioration de formulation

Dans leur article de 2024, Sclar et ses collègues ont notamment étudié 53 tâches de classification et de choix multiple avec des modèles de langage de cette période. Des changements de présentation censés préserver le sens pouvaient modifier sensiblement l’exactitude mesurée ; les présentations favorables se transféraient peu d’un modèle à l’autre. Ces expériences n’établissent aucun taux d’erreur pour les applications cliniques actuelles. Elles justifient une question plus précise : le comportement souhaité résiste-t-il à une modification ? [1]

Le profil volontaire du NIST consacré à l’IA générative, publié en juillet 2024, mentionne parmi les mesures possibles des versions traçables et la vérification des instructions d’utilisation. Il n’évalue aucune collection particulière de consignes en entreprise. L’accord d’entretien qui suit est ma propre proposition pour appliquer ces idées à une consigne partagée avec un effort raisonnable. [2]

Définir d’abord le travail demandé

Dans l’exemple, la consigne doit rassembler les actions décidées, les responsabilités explicitement attribuées et les échéances présentes dans les notes de réunion. Elle doit signaler les questions ouvertes. Une suggestion émise pendant la discussion doit conserver son caractère provisoire. Si personne n’a accepté une action, sa responsabilité reste à attribuer. On obtient ainsi une tâche vérifiable, qui permet d’évaluer une modification.

Six indications brèves accompagnent la consigne : usage autorisé, données d’entrée appropriées, usages exclus, personne responsable, environnement vérifié et version actuelle. L’environnement comprend le modèle, l’application et les fonctions complémentaires disponibles, dans la mesure où ces informations sont accessibles. La date de vérification y figure également. Si le fournisseur ne révèle pas la version précise du modèle, cette incertitude est consignée. Un numéro de version inventé serait inutile lors d’une recherche ultérieure des causes d’un problème.

L’entretien exige une personne joignable qui assume la responsabilité du contenu. Dans cet exemple, la personne chargée de la coordination des projets peut vérifier que les décisions restent distinctes des éléments discutés. Une collègue technique peut gérer la mise à disposition. Dans une petite entreprise, une même personne peut exercer les deux fonctions. Il doit néanmoins rester possible d’identifier qui valide une version modifiée pour un usage partagé.

Constituer une petite collection de cas d’essai

Je commencerais par quelques comptes rendus fictifs dont le traitement attendu est clairement décrit. Le premier contient des actions explicites. Le deuxième propose une échéance qui n’a pas été approuvée. Le troisième attribue des responsabilités contradictoires à deux personnes. Le quatrième contient une correction ultérieure d’une décision antérieure. Le cinquième fournit une entrée vide ou incomplète. Ce nombre constitue un point de départ organisationnel, sans prétendre être un minimum établi scientifiquement.

Définissez le traitement attendu avant l’essai. Pour l’échéance proposée, le critère peut être de la signaler comme une suggestion et de ne pas la présenter comme une date convenue. Pour la correction, le résultat doit montrer quelle affirmation a été remplacée. Un jugement fondé sur l’élégance du style masquerait ces différences. La préservation du sens, la visibilité de l’incertitude et une attribution exploitable comptent davantage pour cette tâche.

Réservez certains cas pour une vérification ultérieure. Sinon, une consigne risque d’être améliorée à répétition sur les mêmes exemples jusqu’à en reproduire surtout les particularités. Demandez aussi à différentes personnes d’essayer les instructions de saisie. Si l’emploi d’informations réelles est envisagé pour les essais, leur utilisation et leur conservation doivent être autorisées séparément. Des contenus fictifs suffisent pour ce premier exercice d’entretien.

Traiter une modification comme une hypothèse vérifiable

Supposons que la liste d’actions soit trop longue. Une collègue propose de réduire chaque action à une phrase. La note de modification pourrait préciser que la nouvelle version doit diminuer les répétitions tout en préservant les réserves et les responsabilités non attribuées. Elle définit ainsi l’amélioration recherchée et la propriété que le raccourcissement pourrait compromettre.

Soumettez aux versions ancienne et nouvelle les mêmes exemples autorisés, dans des conditions aussi proches que possible. Plusieurs exécutions peuvent aider à vérifier si une différence observée se reproduit. Leur nombre dépend de l’importance et de la variabilité de la tâche ; quelques réponses satisfaisantes n’apportent aucune garantie générale de fiabilité. Une note brève doit consigner les écarts observés et la décision sur la nécessité d’approfondir la vérification.

Dans l’exemple fictif, le raccourcissement fait disparaître la réserve indiquant qu’une échéance doit encore être convenue. Cette version doit donc être retravaillée. Conservez la note de modification pour permettre à la personne suivante de comprendre la tentative. Une modification rejetée enrichit les connaissances de l’organisation sur la consigne. Elle peut expliquer pourquoi une formulation apparemment lourde était nécessaire.

Relier validation, retour en arrière et poursuite de l’utilisation

Attribuez à la version diffusée un identifiant distinct et une référence à celle qui la précède. Toute personne qui copie une consigne doit pouvoir retrouver la version partagée actuelle. Une courte indication des versions remplacées aide à interpréter les anciennes copies. Si plusieurs variantes sont nécessaires en parallèle, chacune doit préciser son objectif. Une adaptation non signalée pour un service complique les comparaisons ultérieures.

Préparez également le retour à la version précédente. Celui-ci comprend sa consigne et son environnement connu, dans la mesure où cet environnement reste disponible. Si le fournisseur a remplacé le modèle sous-jacent, un ancien texte ne peut pas rétablir entièrement son comportement précédent. Une nouvelle évaluation ou une procédure manuelle convenue devient alors nécessaire. La version conservée reste utile comme base de comparaison.

Une nouvelle version du modèle, des données d’entrée modifiées ou un malentendu récurrent peuvent déclencher une vérification supplémentaire. Une révision planifiée complète ces déclencheurs. L’organisation en choisit la fréquence selon l’usage et les conséquences d’une erreur. Un aperçu occasionnel et une liste d’actions traitée chaque jour en aval méritent des niveaux d’attention différents.

Ce qu’une collection entretenue rend visible

Une collection utile répond aux mêmes questions pratiques pour chaque consigne. À quoi sert-elle ? Quelles données d’entrée ont été vérifiées ? Quelles difficultés sont connues ? Qui reçoit les observations ? Quelle version est partagée ? Ces indications aident les collègues à choisir une consigne adaptée et à repérer un usage inapproprié avant de poursuivre.

Pour la prochaine réunion interne, je choisirais une consigne souvent copiée et je reconstituerais sa modification la plus récente. Si personne ne peut expliquer pourquoi un paragraphe a été ajouté, voilà un point de départ utile pour l’entretien. Le résultat attendu est une version compréhensible et vérifiable, avec une personne responsable joignable. Sa valeur tient à la possibilité, pour l’organisation, de faire évoluer délibérément sa façon de travailler.

Sources et lectures complémentaires

  1. Sclar et ses collègues : la sensibilité à la présentation des consignesICLR / University of Washington

    La version présentée à la conférence examine notamment 53 tâches de choix et de classification avec des modèles de cette période. Elle ne teste aucune application clinique.

  2. NIST : versions et essais des instructions d’utilisationNIST

    Le profil volontaire de juillet 2024 traite de versions traçables et de la vérification des instructions d’utilisation. L’accord d’entretien proposé pour l’organisation est une déduction originale.

Perspective et intérêts

Cet article a été élaboré avec l’aide de l’IA. Les exemples organisationnels sont fictifs. Les propositions pratiques sont des déductions originales tirées des sources dans les limites indiquées.

Je suis le fondateur et dirigeant d’aiomics et j’ai un intérêt économique dans l’adoption responsable de l’IA en médecine.

Poursuivre la lecture

Quelles questions souhaitez-vous aborder lors de votre événement ?

Présentez-moi votre public, l’occasion et la date envisagée. Nous pourrons construire une conférence autour des questions qui comptent pour vous.

Proposer une conférence