Prompt engineering, mesuré : ce qui change la sortie

Avant les mesures, un fait qui explique discrètement la moitié de ce qui suit.

Le modèle n’a pas de mémoire. Entre deux appels, il ne conserve rien — ni votre dernière question, ni sa propre dernière réponse, ni le fichier que vous avez joint, ni le fait que vous l’ayez déjà demandé deux fois. Chaque appel démarre depuis une machine vide, et la seule chose que cette machine connaît est la séquence de tokens que vous venez de lui fournir.

Ce qui ressemble à de la mémoire dans une interface de chat, c’est votre client qui renvoie toute la conversation, chaque tour, depuis le début. Le modèle relit tout depuis zéro, à chaque fois. Le chapitre 13 a mesuré ce que cette relecture coûte dans une passe avant ; le chapitre 16 en fait une ligne sur une facture. Ce qui compte ici, c’est la conséquence pour la conception : le prompt n’est pas un message adressé à un système qui a un état. Il est l’état.

Cela met fin à toute une famille de confusions. « Le modèle a oublié ce que je lui ai dit » signifie généralement que cela ne lui a jamais été envoyé. « Il a ignoré mon instruction précédente » signifie généralement que l’instruction est sortie de la fenêtre quand l’historique a été tronqué. « Il s’est comporté différemment en production » signifie généralement que la production assemble un prompt différent de celui que vous avez testé. Aucun de ces cas n’est un problème de modèle, et aucun ne se corrige en reformulant quoi que ce soit.

Affirmer que « ce prompt est meilleur » revient à faire une affirmation sur une distribution, et vous ne pouvez pas voir une distribution en regardant une seule sortie. Ce qu’il vous faut est ennuyeux : des cas dont les réponses sont connues, N variantes et un intervalle.

Le harness tient en cinquante lignes de TypeScript et a la même forme que le client du chapitre 14 — une requête, une échéance, un peu de concurrence, un comptage. Il réapparaît au chapitre 19 pour évaluer un retriever et au chapitre 29 comme jeu de référence.

export type Case = { input: string; expected: string };
export type Variant = { name: string; build: (c: Case) => ChatMessage[] };

async function pooled<T, R>(xs: T[], n: number, f: (x: T) => Promise<R>) {
  const out: R[] = new Array(xs.length);
  let i = 0;
  await Promise.all(
    Array.from({ length: n }, async () => {
      while (i < xs.length) {
        const k = i++;
        out[k] = await f(xs[k]);
      }
    }),
  );
  return out;
}

export async function runVariant(v: Variant, cases: Case[], concurrency = 6) {
  const hits = await pooled(cases, concurrency, async (c) => {
    const answer = await complete(v.build(c));      
    return answer.trim().toLowerCase() === c.expected;
  });
  return { name: v.name, hits, k: hits.filter(Boolean).length, n: cases.length };
}

Le nombre qui revient n’est pas le résultat. Le résultat, c’est ceci :

/** 95 % Wilson score interval for a proportion. Chapter 4 derives it. */
export function wilson(k: number, n: number, z = 1.96) {
  const p = k / n;
  const d = 1 + (z * z) / n;
  const centre = (p + (z * z) / (2 * n)) / d;
  const half = (z * Math.sqrt((p * (1 - p)) / n + (z * z) / (4 * n * n))) / d;
  return [Math.max(0, centre - half), Math.min(1, centre + half)] as const;
}

Le chapitre 4 a posé l’argument, et ce chapitre l’encaisse. Dix-sept bonnes réponses sur vingt, c’est 85 %, et son intervalle à 95 % va de 64 % à 95 %. Une variante qui obtient 13 sur 20 — 65 %, ce qui semble clairement moins bon — a un intervalle de 43 % à 82 %. Ces deux intervalles se chevauchent sur presque toute leur longueur. Vingt cas ne peuvent pas distinguer un bon prompt d’un prompt médiocre, et la plupart des conseils publiés sur les prompts ont été validés sur moins que cela.

Soixante cas, comme dans ce chapitre, ce n’est toujours pas beaucoup. C’est assez pour voir de grands effets et assez honnête pour admettre quand cela ne permet pas de voir les petits — et cela l’admettra plusieurs fois ci-dessous.

Trois blocs — les règles R, le ticket T, l’instruction I — concaténés dans un seul message utilisateur. Les six permutations, contenu identique au byte près, soixante cas chacune.

Du meilleur au pire, l’écart est de 28,3 points, et les intervalles ne se chevauchent pas : ce n’est donc pas une histoire de bruit. Puisque chaque bras est noté sur les mêmes soixante éléments, la question plus précise est la question appariée : parmi les cas où deux bras ne sont pas d’accord, à quel point le partage est-il déséquilibré ? Passer du pire ordre au meilleur a fait basculer 21 cas de faux à vrai et 4 de vrai à faux — probabilité appariée exacte : 0,0009.³

Lisez le tableau pour sa forme plutôt que pour son vainqueur. Les deux meilleures lignes se terminent par le ticket ; les deux pires enterrent l’instruction au milieu ou la traînent après les données. C’est le même phénomène que Liu et al. ont nommé Lost in the Middle : le contenu placé aux bords d’un prompt est utilisé plus fiable­ment que celui placé au centre.⁴ Le chapitre 16 chiffre le coût de la fenêtre et le chapitre 24 mesure correctement l’effet en longueur, là où le milieu s’effondre comme décrit et où la récupération tout à la fin ne réapparaît pas. Ici, la règle pratique tombe d’elle-même : la tâche en haut, les données en bas, rien d’important au milieu.

Déplaçons maintenant les mêmes mots entre les tours. Le chapitre 11 a établi que le chat template n’est pas une décoration autour du modèle mais une partie de celui-ci — <|im_start|>system et <|im_start|>user sont de vrais tokens que le modèle a vus des millions de fois pendant le fine-tuning, exactement à ces positions. Il devrait donc être important de savoir de quel côté de ces marqueurs votre instruction atterrit, et c’est bien le cas :

Déplacer les règles et l’instruction à travers la frontière du template a rapporté 21,7 points — 19 cas gagnés, 6 perdus, probabilité appariée 0,0146 — sans en changer un seul caractère. C’est la réponse concrète à system prompt versus user prompt : ce ne sont pas deux façons de dire la même chose. Ce sont deux positions de tokens différentes dans une structure sur laquelle le modèle a été entraîné, et la position système est celle où doivent aller les instructions qui s’appliquent à toute la conversation.

Remarquez aussi la troisième ligne. Répéter l’instruction après le ticket — une astuce largement recommandée — a obtenu un score inférieur à une instruction énoncée une seule fois. Sur ce modèle, sur cette tâche, le dire deux fois était pire que le dire une fois.

Même prompt, meilleur placement, soixante cas. La seule chose qui change est ce qui entoure le texte du ticket.

Dix-huit points d’écart dus à la ponctuation. Mais regardez les deux intervalles extrêmes : [73,9, 91,9] et [54,1, 77,3]. Ils se chevauchent. Selon la lecture grossière — comparez les barres d’erreur, et si elles se touchent, ne dites rien — ce tableau ne prouve absolument rien.

La lecture grossière est fausse ici, et comprendre pourquoi vaut plus que le tableau. Chaque variante a été notée sur les mêmes soixante tickets, les deux mesures ne sont donc pas des échantillons indépendants ; elles sont appariées. La majeure partie de la largeur de chaque intervalle vient d’une source d’incertitude partagée par les deux bras — le fait que ces soixante tickets soient ou non représentatifs — et cette source s’annule quand vous les comparez entre eux. Posez plutôt la question appariée, et la réponse est nette : passer des guillemets doubles à la balise XML a fait basculer 12 cas de faux à vrai et 1 de vrai à faux, probabilité appariée 0,0034. C’est une vraie différence.

Puis le même test dégonfle le titre. La balise XML a battu l’étiquette simple Ticket: de 8,3 points, le nombre qu’un article de blog mettrait dans son titre. Apparié : 6 gagnés, 1 perdu, probabilité 0,1250. Non établi. Sept cas : voilà sur quoi repose cette amélioration célèbre.

Il y a donc deux questions avec deux instruments différents, et les confondre est la façon dont les conseils de prompt se trompent dans les deux sens à la fois :

Le constat général — les modèles sont fortement et imprévisiblement sensibles à des choix de formatage sans contenu sémantique — n’est pas nouveau. Sclar et al. n’ont fait varier que les séparateurs, l’espacement et la casse sur des dizaines de tâches, et ont trouvé des écarts d’exactitude assez larges pour inverser des classements de modèles publiés.⁵ La conséquence pratique n’est pas « utilisez des balises XML ». C’est que le formatage est un hyperparamètre, qu’il ne coûte rien à balayer, et que toute comparaison de deux modèles qui fige un format compare les formats autant que les modèles.

L’in-context learning — montrer au modèle des exemples résolus dans le prompt et le laisser généraliser à partir d’eux sans aucune mise à jour des poids — est la capacité qui a rendu GPT-3 célèbre.⁶ La question pratique n’est jamais de savoir si cela fonctionne. C’est de savoir combien d’exemples payer.

Les exemples sont fournis comme de vrais tours précédents, alternant utilisateur et assistant, parce que c’est la structure sur laquelle le template a été entraîné. Chaque k a été exécuté avec cinq tirages aléatoires différents depuis un pool distinct de seize tickets étiquetés :

Deux exemples ont rapporté sept points. Les six exemples suivants n’ont rien rapporté de mesurable — 83,7, puis 81,7, puis 83,7, une séquence qui se promène dans son propre bruit. Seize en ont rapporté encore cinq et demi. La courbe n’est pas une montée régulière ; c’est une marche, un plateau et une marche.

La colonne la plus importante est la dernière. À k = 8, les huit exemples que vous avez par hasard choisis ont déplacé l’exactitude de 10 points — plus que tout le gain obtenu en passant de deux exemples à huit. Et la dernière ligne en est la version la plus nette : à k = 16, le pool est épuisé, donc les cinq exécutions contiennent exactement les mêmes seize exemples, ne différant que par leur ordre d’apparition. L’ordre seul a déplacé l’exactitude de 8,3 points.

C’est le résultat rapporté par Lu et al., et il survit partout où on l’a cherché : l’ordre des exemples est un véritable hyperparamètre, avec des effets comparables au nombre d’exemples.⁷ Le conseil honnête sur le few-shot prompting n’est donc pas un nombre. C’est ceci :

Passons au folklore. Chacune de ces phrases est une seule phrase ajoutée au début d’un system prompt par ailleurs identique, sur les mêmes soixante cas.

Quatre des cinq n’ont rien fait. Pas « un peu » ; rien que soixante cas appariés puissent voir. La persona d’expert et le pot-de-vin ont tous deux obtenu un score inférieur à la référence intacte, et même ces baisses échouent au test apparié — c’est du bruit orienté vers le bas.

La troisième ligne est celle sur laquelle s’attarder. « C’est très important pour ma carrière » a produit exactement la même exactitude, 46 sur 60 — et dix des soixante réponses ont changé, cinq dans chaque direction. La statistique synthétique était identique, mais pas le comportement. Si votre évaluation est un seul nombre sur un petit ensemble, un changement qui réécrit un sixième de vos sorties peut ressembler à un changement qui n’a rien fait, et vous le livrerez en croyant qu’il était gratuit.

Puis vient la menace, seule phrase à avoir fait bouger l’aiguille, et à l’avoir fait bouger de 35 points vers le bas, faisant basculer 24 cas de vrai à faux. Ce n’est pas un artefact d’arrondi ; c’est un comportement de modèle différent. La leçon n’est pas « ne menacez jamais un modèle ». C’est que le cadrage émotionnel n’est pas inerte. Il déplace la distribution, parfois fortement, dans une direction que personne ne peut prédire en lisant la phrase — précisément pourquoi il doit être mesuré plutôt que raisonné.

Une réserve que ce chapitre vous doit : ces cinq phrases ont été testées sur un petit modèle et une tâche. Certaines ont un soutien publié ailleurs — « respirez profondément » vient d’un article qui a cherché des instructions à score élevé plutôt que de les inventer, ce qui est une affirmation différente et meilleure que celle qui a circulé ensuite.⁸ Ce qui se généralise, ce ne sont pas les phrases. C’est que la liste qui survit dans les articles de blog et la liste qui survit à la mesure sont deux listes différentes, et que la seule façon de savoir laquelle vous avez entre les mains est d’exécuter le banc.

Une règle que tout le monde répète — dites ce que vous voulez, pas ce que vous ne voulez pas — avec l’absence habituelle de nombre. Voici le nombre. La même exigence de format, écrite de trois façons, avec le modèle qui génère librement pour que la conformité puisse être observée :

Trois interdictions ont fait pire qu’une instruction, et ont poussé le modèle à écrire cinq fois plus de texte — l’exact opposé des trois à la fois. Réintroduire la phrase positive l’a sauvé jusqu’à 68 %.

Le mécanisme n’a rien de mystérieux si vous vous souvenez du chapitre 8. Le modèle choisit un prochain token dans une distribution conditionnée par tout ce qui le précède, et une interdiction met la chose interdite dans ce conditionnement. Il n’existe pas d’opérateur de négation ; il existe un contexte dans lequel un mot apparaît désormais.

Cela se mesure directement. Prenez le prompt de référence et ajoutez une ligne : Do not use the shipping queue for software problems. Puis regardez uniquement les quarante-cinq tickets qui ne sont pas des tickets d’expédition :

Nommer une file pour l’exclure a poussé le modèle à la choisir trois fois plus souvent, a presque triplé la masse de probabilité qu’il lui attribuait, et a coûté 25 points d’exactitude globale — 16 cas perdus contre 1 gagné, probabilité appariée 0,0003.

Ne pensez pas à un éléphant, mesuré. La réécriture est toujours la même : remplacez l’interdiction par la règle positive qui la rend inutile. Pas « n’utilisez pas expédition pour les problèmes logiciels », mais « utilisez expédition uniquement lorsqu’un colis physique est impliqué ».

Le chapitre 12 a construit correctement la chain of thought — d’abord comme technique de prompting,⁹¹⁰ puis comme quelque chose entraîné avec des récompenses vérifiables — et s’est terminé par un avertissement reporté à ce chapitre : dire à un modèle de réfléchir étape par étape cesse d’aider une fois que le modèle raisonne par lui-même, et peut nuire. Voici cet avertissement avec un tableau dessous, sur une tâche où il est facile de supposer que plus de réflexion doit être meilleur.

Les deux bras sont lus avec le même instrument, à la même position. La seule différence est de savoir si une chain of thought écrite par le modèle lui-même se trouve d’abord dans le contexte.

L’exactitude a baissé et le coût a augmenté, et la règle de ce chapitre s’applique à son propre résultat : la baisse est de 7 cas gagnés contre 10 perdus, probabilité appariée 0,629, ce qui n’est pas établi. Ce qui est établi, c’est que cela a produit quatre-vingt-dix-huit tokens de sortie supplémentaires par appel et n’a rien acheté de mesurable avec eux. L’incertitude porte entièrement sur le bénéfice. La facture, elle, est certaine.

Une chaîne qui échoue est plus instructive qu’une chaîne qui fonctionne. Invité à raisonner sur « Votre intégration Slack a cessé de publier des messages après mardi », le modèle a écrit :

1. Check if the issue persists on Monday.
2. Verify if there are any updates or changes in your Slack setup that
   might affect message posting.
3. If no update has been made since Tuesday, check for any recent system
   restarts or downtime affecting Slack functionality.
4. If you have recently installed new software or updated your
   environment, ensure it's compatible with Slack version.
5. Contact Slack support for further assistance or troubleshooting steps.

C’est un conseil de dépannage compétent, et ce n’est pas la tâche. Invité à réfléchir, le modèle a dérivé vers le genre auquel « réfléchir étape par étape à ce ticket d’assistance » ressemble le plus dans ses données d’entraînement — puis a répondu à une question de classification avec cinq cents caractères de raisonnement sans rapport dans son propre contexte. La chain of thought aide sur les problèmes avec un état intermédiaire qui mérite d’être calculé : arithmétique, recherches multi-sauts, satisfaction de contraintes. Router une phrase dans l’un de quatre seaux n’a pas d’état intermédiaire. Il n’y a rien que la chaîne puisse tenir, donc tout ce qu’elle fait est d’ajouter un texte plausible auquel la décision finale doit ensuite survivre.

Deux corollaires pratiques. D’abord, pour un modèle entraîné à raisonner — les modèles RLVR du chapitre 12 — l’instruction est pire que redondante : elle peut remplacer la longue chaîne que le modèle aurait produite par une chaîne courte, en forme de prompt. Et échantillonner plusieurs chaînes puis voter, ce que fait la self-consistency,¹¹ ne peut pas sauver une tâche où il n’y a rien sur quoi diverger : cela multiplie le coût par le nombre d’échantillons pour départager des ex æquo qui n’existent pas. Le chapitre 12 a mesuré cet arbitrage là où il s’applique. Ensuite, notez ce que le dispositif de comparaison lui-même a coûté. Forcer la réponse dans une ligne Final queue: a fait chuter le bras sans raisonnement de 76,7 % à 61,7 %. Quinze points, payés pour rendre les deux bras comparables. Une structure qui existe pour votre confort n’est pas gratuite non plus.

Une dernière mesure, parce que c’est la question que tout le monde pose après le premier résultat surprenant. Soixante prompts, décodage greedy, exécutés plusieurs fois :

• Le même appel répété avec tout maintenu fixe a renvoyé des probabilités identiques au bit près. Déterministe.
• Le même appel batché avec des voisins différents — tailles de batch 1, 4, 12, 30 et 60 — a renvoyé des probabilités différant jusqu’à 0,0128. L’étiquette choisie n’a jamais changé, dans 0 cas sur 60.

L’étiquette a survécu parce qu’elle avait de la marge : sur les soixante cas, le plus petit écart entre les deux meilleures files était de 0,0459, trois fois et demie la dérive. La stabilité n’était pas une propriété de l’algorithme. C’était une marge, et les marges s’épuisent. Le chapitre 17 est l’endroit où se trouve la raison arithmétique et où les réglages d’échantillonnage qui élargissent et resserrent ces écarts sont démontés. La raison de la planter ici est qu’elle borne ce que toute mesure de prompt peut signifier : le banc mesure un système reproductible seulement jusqu’à une tolérance, et une différence de deux points entre variantes est dans cette tolérance un mauvais jour.

Tout ce qui précède, c’est un humain qui choisit une variante et une machine qui la note. L’étape évidente suivante est de laisser la machine choisir aussi les variantes.

APE fait exactement cela : un modèle propose des instructions candidates, elles sont notées sur des exemples mis de côté, et les meilleures survivent.⁸ Les instructions qu’il trouve sont souvent des instructions qu’aucun humain n’écrirait, et c’est le but — la recherche porte sur ce qui score, pas sur ce qui sonne professionnel.

DSPy va plus loin et constitue l’idée la plus utile pour un produit.¹² Vous déclarez ce que chaque étape d’un pipeline prend et renvoie, et le framework compile cela en prompts, sélectionne des démonstrations et optimise les instructions contre votre métrique. Changez de modèle, et vous recompilez au lieu de réécrire. Le prompt cesse d’être du code source réglé à la main par quelqu’un et devient un artefact généré contre une métrique, ce qu’il aurait dû être depuis le début.

Aucun des deux ne supprime le besoin du banc. Tous deux en font la seule chose dont vous avez besoin, parce qu’un optimiseur sans métrique n’optimise rien.

Reste la discipline. Les prompts doivent vivre dans le contrôle de version, dans des fichiers, à côté du code qui les envoie — pas dans une ligne de base de données que quelqu’un a modifiée un mardi. Ils ont besoin d’un identifiant de version stocké avec chaque sortie qu’ils ont produite, sinon le jour où quelque chose régresse, vous ne pouvez pas découvrir ce qui a changé. Ils ont besoin du banc en intégration continue, parce qu’un prompt est la seule partie de votre système qu’un fournisseur peut invalider silencieusement en déployant un nouveau modèle. Et ils ont besoin de cas : pas cent cas astucieux, seulement les vingt cas ennuyeux qui ont cassé le trimestre dernier, conservés pour toujours. Le banc est le livrable. Le prompt en est un sous-produit.

Tout dans ce chapitre a été mesuré en exactitude. Chacune de ces variantes a aussi un prix.

Le system prompt qui a rapporté 21,7 points est envoyé à chaque appel, pour toujours. Les deux exemples qui ont rapporté sept points sont envoyés à chaque appel, pour toujours. Les seize qui en ont rapporté douze sont envoyés à chaque appel, pour toujours, et ils font environ dix fois la longueur de la question réellement posée par l’utilisateur. La chain of thought qui n’a rien rapporté a produit quatre-vingt-dix-huit tokens supplémentaires par requête, et les tokens de sortie sont les plus chers.

Rien de cela n’est visible dans un tableau d’exactitudes, et tout cela est visible sur une facture.

Le chapitre 16 porte sur l’unité dans laquelle ces décisions sont réellement libellées. Le token comme unité de facturation, la context window comme budget plutôt que mémoire, pourquoi une conversation de quarante tours coûte bien plus que quarante fois le premier tour, ce que prompt caching paie et ne paie pas, et pourquoi l’ordre de votre prompt décide si le cache touche ou non — ce qui s’avère être une seconde raison, entièrement économique, de placer le contenu stable en premier et le contenu variable en dernier.

Le banc et chaque tableau ont été produits avec Qwen/Qwen2.5-0.5B-Instruct sous décodage greedy, ils se reproduisent donc exactement. La documentation Hugging Face sur les chat templates est la référence pour ce en quoi les marqueurs de template du chapitre 11 se développent réellement, et pour le fait qu’un modèle livré avec le mauvais template est une défaillance réelle et récurrente. Pour les effets de position et de format à l’échelle de production plutôt qu’à l’échelle de laboratoire, les citations ci-dessus sont les sources primaires ; les guides de prompting des fournisseurs sont utiles pour leurs exemples et doivent être lus en sachant qu’aucun ne publie d’intervalle.