Quatre techniques de prompting qui tiennent

1Être explicite, et dire pourquoi

La première recommandation est aussi la moins glamour : le modèle répond bien aux instructions claires et explicites. Si tu veux un comportement « au-delà du minimum », demande-le, ne compte pas sur lui pour le déduire d'une consigne vague.

L'exemple donné dans la documentation :

Cree un tableau de bord analytique

devient :

Cree un tableau de bord analytique. Inclus autant de fonctionnalites et
d'interactions pertinentes que possible. Va au-dela du minimum pour produire
une implementation complete.

La variante la plus rentable : donner la raison de la contrainte. La documentation insiste sur ce point, le modèle généralise à partir de l'explication.

Ta reponse sera lue par un moteur de synthese vocale, donc n'utilise pas de
points de suspension : il ne saurait pas les prononcer.

Deux consignes de forme complètent le tableau : quand l'ordre ou l'exhaustivité des étapes comptent, donne-les en liste numérotée. Et pour piloter le format, dis ce qu'il faut faire plutôt que ce qu'il faut éviter : « écris en paragraphes de prose continue » marche mieux que « n'utilise pas de markdown ».

2Donner trois à cinq exemples, balisés

Les exemples sont décrits comme l'un des moyens les plus fiables de piloter le format, le ton et la structure de la sortie. Le chiffre est donné : trois à cinq exemples pour de bons résultats.

Trois critères de qualité sont posés :

• Pertinents : ils reflètent de près ton cas réel.
• Divers : ils couvrent les cas limites et varient assez pour que le modèle n'attrape pas un motif involontaire.
• Structurés : chaque exemple dans une balise <example>, l'ensemble dans <examples>, pour qu'ils se distinguent des instructions.

<examples>
<example>
Entree : « le paiement a echoue »
Sortie : {"categorie": "paiement", "urgence": "haute", "action": "escalade"}
</example>
<example>
Entree : « comment change-t-on de mot de passe ? »
Sortie : {"categorie": "compte", "urgence": "basse", "action": "self-service"}
</example>
</examples>

3Structurer avec des balises XML

Dès qu'un prompt mélange instructions, contexte, exemples et données variables, les balises XML lèvent l'ambiguïté sur ce qui est quoi. C'est la raison invoquée dans la documentation : réduire les mauvaises interprétations.

Deux bonnes pratiques y sont listées :

• Utiliser des noms de balises cohérents et descriptifs d'un prompt à l'autre, par exemple <instructions>, <context>, <input>.
• Imbriquer quand le contenu a une hiérarchie naturelle : des documents dans <documents>, chacun dans <document index="n">.

Les balises servent aussi côté sortie : demander « écris les passages en prose dans des balises <prose> » est un moyen de contrôle du format cité tel quel.

4Placer les longs documents en haut, et faire citer avant de répondre

Pour les entrées volumineuses, à partir de 20 000 tokens environ, la documentation donne trois consignes précises.

Les documents longs vont en haut du prompt, au-dessus de la question, des instructions et des exemples. La note est chiffrée : en tests, placer la requête à la fin peut améliorer la qualité de réponse jusqu'à 30 %, surtout sur des entrées complexes ou multi-documents.

Chaque document est balisé avec ses métadonnées :

<documents>
  <document index="1">
    <source>rapport_annuel_2023.pdf</source>
    <document_content>
      ...
    </document_content>
  </document>
</documents>

Analyse le rapport annuel et identifie les trois risques principaux.

Demande les citations d'abord. La technique est explicite : sur une tâche portant sur de longs documents, demander au modèle de citer les passages pertinents avant de traiter la tâche l'aide à se concentrer sur le contenu utile et à ignorer le reste.

Trouve d'abord les extraits pertinents et place-les dans des balises <quotes>.
Ensuite, en te basant uniquement sur ces extraits, redige ta reponse dans des
balises <reponse>.

Effet secondaire appréciable : tu peux vérifier les extraits. Une affirmation sans extrait devient visible.