Aller au contenu

Pourquoi la même demande donne deux résultats

Tu écris une demande. Le résultat est excellent. Tu la réutilises le lendemain, mot pour mot, et tu obtiens quelque chose de médiocre.

Ce n’est pas une panne, et ce n’est pas toi. C’est le fonctionnement normal de l’outil. Comprendre d’où vient cette variabilité, c’est comprendre comment la supprimer.

Le tirage au sort intégré. À chaque fragment de texte produit, le programme choisit parmi plusieurs suites possibles avec une part d’aléatoire. C’est volontaire : sans ça, les textes seraient répétitifs. Deux exécutions identiques ne donneront donc jamais un texte identique. C’est irréductible, et ce n’est pas un problème, sauf si ta demande laisse trop de place à l’interprétation.

Le flou de ta demande. C’est de très loin la source la plus importante, et la seule que tu contrôles entièrement. Chaque ambiguïté dans ta formulation est un espace où l’outil doit deviner. Tu écris « fais un résumé » sans préciser la longueur : chaque exécution en choisira une différente. Tu écris « sois professionnel » : chaque exécution aura sa propre idée du professionnalisme.

La variabilité du résultat est proportionnelle au flou de la demande. Retiens cette phrase, elle gouverne tout le reste.

Le contexte accumulé. Dans une conversation qui dure, tout ce qui précède influence la suite. La même demande posée au premier message et au vingtième ne rencontre pas le même environnement. Pour comparer deux formulations, il faut donc toujours des conversations neuves. Sinon tu ne compares plus rien.

Le modèle lui-même. Les fournisseurs font évoluer leurs modèles. Une demande calibrée il y a six mois peut se comporter différemment aujourd’hui. Raison de plus pour tester ses demandes plutôt que de leur faire confiance indéfiniment.

On ne corrige pas ce qu’on n’a pas mesuré. Voici le test le plus utile de cette formation, et il prend cinq minutes.

Prends une demande que tu utilises régulièrement. Exécute-la cinq fois, dans cinq conversations neuves, avec la même entrée. Puis compare les cinq sorties sur trois critères objectifs : la longueur (en gros, le nombre de lignes ou de mots), la structure (mêmes sections, même ordre ?) et le fond (mêmes informations retenues, même conclusion ?).

Trois diagnostics possibles.

Si les longueurs et les structures varient beaucoup, ta forme n’est pas spécifiée. Si les structures sont stables mais les contenus divergent, ta tâche est ambiguë ou la matière manque. Et si tout est stable, y compris le fond, ta demande est solide : passe à autre chose.

Chaque fois que tu laisses un choix ouvert, tu ajoutes de la variance. Ferme explicitement.

« Fais un résumé » devient « résume en cinq puces de moins de 15 mots chacune ». « Sois professionnel » devient « vouvoiement, pas d’exclamation, pas de superlatif ». « Classe ces demandes » devient « attribue exactement une catégorie parmi : réclamation, devis, question, relance, hors sujet ». « Extrais les informations importantes » devient « extrais uniquement : date, montant, nom du contact, échéance ».

Les secondes versions ne sont pas plus longues par coquetterie. Chaque précision supprime une source de divergence.

Décrire un format en mots laisse toujours de l’interprétation. Montrer un exemple n’en laisse presque aucune. C’est le sujet d’une fiche entière de ce module, parce que c’est la technique la plus rentable qui existe.

Une réponse construite à partir d’un document que tu fournis varie beaucoup moins qu’une réponse construite de mémoire. Moins l’outil a besoin de combler, moins il a d’occasions de diverger.

Reprenons le tri des demandes entrantes. Version floue :

Classe cette demande client et dis-moi si c'est urgent.

Cinq exécutions donneront cinq catégories formulées différemment (« réclamation », « plainte », « mécontentement client ») et cinq échelles d’urgence différentes. Résultat inexploitable dès qu’on veut compter ou trier.

Version fermée :

Classe cette demande dans EXACTEMENT une catégorie parmi :
reclamation | devis | question | relance | hors-sujet
Attribue une urgence parmi : haute | moyenne | basse
- haute : le client est bloqué, ou une échéance légale approche
- moyenne : une réponse est attendue mais rien n'est bloqué
- basse : information, remerciement, sans échéance
Si la demande relève de deux catégories, choisis la principale et
signale-le sur une ligne « ambiguïté ».

Cette version-là donne cinq fois le même résultat. Note le dernier paragraphe : on a même fermé la porte du cas ambigu, qui est la principale source de divergence sur ce genre de tâche.

Réduire la variabilité, ce n’est pas réduire la qualité. Une demande fermée ne produit pas un texte plus pauvre : elle produit un texte dont tu as décidé les caractéristiques au lieu de les subir.

Cela dit, il existe des tâches où la variabilité est souhaitable. Chercher des idées, explorer des angles, trouver des formulations. Dans ces cas, laisse volontairement des portes ouvertes et exécute plusieurs fois. Le savoir-faire, c’est de savoir dans quel régime on est.

Fais le test des cinq exécutions sur une demande que tu utilises vraiment, et note le diagnostic.

Réécris ensuite la demande en fermant tout ce que tu avais laissé ouvert. Liste-le d’abord, tu en trouveras plus que prévu.

Puis refais cinq exécutions et compare la dispersion.

Garde les deux versions dans ton fichier « mes demandes » : elles serviront de point de comparaison tout au long de la formation.

Vérifie ta compréhension

Question : tu obtiens cinq sorties de structure identique mais dont les conclusions diffèrent. Quel levier actionner en premier ?

Réponse : pas la forme, elle est déjà stable. Le problème est ailleurs : soit la tâche est ambiguë (que faut-il conclure, exactement, et selon quels critères ?), soit la matière est insuffisante et l’outil comble les manques différemment à chaque fois. Commence par expliciter les critères de décision, puis par fournir plus de matière.

Fiche suivante : le cadrage complet, bien au-delà des quatre ingrédients.

Une formationBaxIA