Anatomie d'un prompt

Vous donnez une requête à un modèle et vous recevez quelque chose de vague ou mal formaté. Un collègue demande ce qui semble être la même chose et obtient exactement ce qu'il voulait. Le modèle est identique. La différence, c'est le prompt, et plus précisément le fait qu'il soit construit avec les bonnes parties aux bons endroits.

Un prompt n'est pas juste "la question que vous tapez". C'est un petit document structuré, et une fois que vous en voyez les parties, vous pouvez corriger une réponse faible en corrigeant la partie qui manquait. Cette leçon démonte un prompt pour donner au reste du sujet une base concrète.

Un prompt est fait de parties

Commençons par un vrai. Voici un prompt pour un outil de support client qui doit router les messages entrants :

Vous êtes un assistant support pour une banque.
Classez le message ci-dessous en Facturation, Technique ou Autre.
Message : "Ma carte a été débitée deux fois pour un seul achat."
Répondez avec le nom de la catégorie uniquement.

Ce seul bloc fait quatre tâches distinctes, et chaque ligne correspond à l'une d'elles :

• Le contexte plante le décor : "Vous êtes un assistant support pour une banque." Il dit au modèle dans quel monde il opère et, ici, quel rôle jouer.
• L'instruction est la tâche : "Classez le message ci-dessous en Facturation, Technique ou Autre." C'est la seule partie qu'un prompt ne peut jamais abandonner.
• L'entrée est la donnée sur laquelle l'instruction agit : le message "Ma carte a été débitée deux fois pour un seul achat."
• L'indicateur de sortie contraint la réponse : "Répondez avec le nom de la catégorie uniquement." Sans lui, le modèle pourrait répondre "Cela ressemble à un problème de Facturation car le client mentionne un double débit", ce qui est plus difficile à exploiter par votre code.

AWS décrit un prompt comme une combinaison de ces composants : l'instruction que vous voulez voir exécutée, le contexte de la tâche, des exemples de démonstration, et le texte d'entrée que le modèle doit utiliser. Vous avez rarement besoin de tous à la fois. Un prompt doit combiner les parties que la tâche exige réellement, et rien de plus.

Instruction contre entrée : la distinction la plus importante

La confusion la plus fréquente consiste à traiter l'instruction et l'entrée comme un seul bloc. Elles sont différentes, et les garder séparées est ce qui rend un prompt réutilisable.

Prenez le texte d'avis "La nourriture était excellente mais le service était lent." Seul, ce n'est qu'une entrée. Il devient une tâche uniquement quand une instruction l'enveloppe :

• "Résume cet avis en une phrase" vous donne un résumé.
• "Classe le sentiment de cet avis comme positif, négatif ou neutre" vous donne une étiquette.
• "Traduis cet avis en anglais" vous donne une traduction.

Même entrée, trois instructions différentes, trois tâches différentes. C'est pourquoi les prompts de production gardent l'instruction fixe et changent l'entrée à chaque requête. Votre outil de support ne réécrit jamais "Classez le message" pour chaque client. Il réutilise cette instruction et y insère un nouveau message à chaque fois.

Contexte et indicateur de sortie : les deux parties qu'on oublie

L'instruction et l'entrée sont évidentes une fois nommées. Les deux autres sautent souvent, et c'est là que naissent les réponses faibles.

Le contexte est l'arrière-plan dont le modèle a besoin mais qui n'est pas l'entrée elle-même. "Le texte suivant provient d'un avis de restaurant" dit au modèle comment lire ce qui vient. Un rôle comme "Vous êtes un comptable fiscaliste senior" décale le vocabulaire et le niveau de prudence de la réponse. Le contexte ne demande rien ; il cadre la demande.

L'indicateur de sortie décrit la forme de la réponse. AWS le montre clairement avec le résumé : "Résume le texte ci-dessus" renvoie un paragraphe presque aussi long que l'original, alors que "Résume le texte ci-dessus en une seule phrase" renvoie une ligne serrée. Si votre code en aval attend un seul mot, un objet JSON ou trois puces, l'indicateur de sortie est là où vous le dites. Quand le modèle renvoie le mauvais format, c'est presque toujours la partie manquante.

Zero-shot et few-shot : enseigner par l'exemple dans le prompt

Parfois une instruction seule ne suffit pas à cerner ce que vous voulez, surtout le format exact ou la gestion des cas limites. Vous pouvez montrer au modèle au lieu de seulement lui dire, en incluant des exemples travaillés dans le prompt.

Une paire d'exemple, une entrée plus sa sortie correcte, s'appelle un shot. Un prompt sans exemple est zero-shot : vous vous reposez sur ce que le modèle a déjà appris pendant l'entraînement. Un prompt qui inclut un ou plusieurs exemples est few-shot (ou one-shot pour exactement un), aussi appelé apprentissage en contexte, parce que le modèle capte le motif depuis le prompt lui-même.

Voici un prompt de sentiment en zero-shot :

Dis-moi le sentiment de ce titre comme positif, négatif ou neutre :
Une nouvelle liaison aérienne offre une belle opportunité aux passagers et aux investisseurs.

Et la version few-shot, qui montre d'abord au modèle le format exact de la réponse :

Dis-moi le sentiment de chaque titre comme positif, négatif ou neutre.

Un cabinet d'études repousse des accusations d'irrégularités sur une nouvelle technologie.
Réponse : Négatif

Les parcs éoliens offshore prospèrent alors que l'opposition faiblit.
Réponse : Positif

Une usine devient la dernière cible d'une enquête publique.
Réponse :

Les exemples font deux choses : ils verrouillent la sortie sur un seul mot, et ils montrent comment traiter les formulations délicates. Le point clé pour les leçons suivantes, c'est que le few-shot se passe entièrement dans le prompt. Il ne change pas le modèle. Fermez la session et le modèle n'en garde rien, ce qui sépare exactement le prompting du fine-tuning.

Templates de prompt : la recette réutilisable

Une fois qu'un prompt fonctionne, vous ne voulez pas le retaper au risque d'en casser le libellé. Un template de prompt fige la structure et marque les parties qui changent. AWS écrit les emplacements changeants avec des doubles accolades :

Dis-moi le sentiment du {{type de texte}} suivant comme {{label A}} ou {{label B}}.

Texte : {{exemple d'entrée 1}}
Réponse : {{label A}}

Texte : {{entrée}}
Réponse :

Les accolades sont un signal pour celui qui remplit le template, pas du texte que le modèle voit. Avant l'envoi, vous remplacez {{entrée}} par le vrai message client et vous retirez les accolades. Cela compte parce que la dernière leçon de ce sujet, la gestion des prompts, repose entièrement sur des templates à variables nommées, et parce qu'une attaque de prompt, dans une leçon plus loin, exploite exactement la couture où votre instruction fixe rencontre l'{{entrée}} non fiable.

Conseils pour l'examen

• Si une question vous donne un prompt et vous demande d'en nommer les parties, mappez chaque ligne : quoi faire (instruction), sur quoi le faire (entrée), le cadrage (contexte), le format imposé (indicateur de sortie).
• "Instruction" et "entrée" sont le piège classique. L'instruction est le verbe, l'entrée est le nom sur lequel il agit. Une question qui les inverse teste cette confusion précise.
• Un shot est une paire d'exemple dans le prompt. Zéro exemple, c'est zero-shot ; un ou plus, c'est few-shot. Si une réponse affirme que le few-shot change le modèle ou ses poids, elle est fausse. L'apprentissage en contexte vit uniquement dans le prompt.
• Un indicateur de sortie contrôle le format et la longueur. Quand un scénario se plaint que les réponses sont trop longues ou de la mauvaise forme, le correctif est un indicateur de sortie, pas un nouveau modèle.

La chose à retenir : un prompt est une structure, pas une phrase. Quand une réponse déçoit, demandez-vous quelle partie manquait plutôt que de tout réécrire depuis zéro. Ensuite, vous verrez les techniques nommées, du zero-shot jusqu'au chain-of-thought, qui décident de la quantité de structure qu'une tâche donnée exige vraiment.