Lorsque votre application envoie la réponse de Claude directement à un utilisateur, personne ne la vérifie au préalable. Ce que Claude écrit est exactement ce que l'utilisateur reçoit. Claude doit donc savoir où va la réponse, à quoi elle doit ressembler, et ce qu'il faut omettre.
Pour rendre une requête claire et directe, donnez à Claude ces trois éléments : le contexte, le format de sortie que vous souhaitez, et les contraintes. Chacun répond à une question qu'un nouveau collègue vous poserait avant de commencer la tâche.
Une requête qui laisse Claude deviner
Imaginons qu'une application de prise de rendez-vous chez le dentiste envoie par SMS à chaque patient un rappel la veille de sa visite. L'application envoie à Claude une tâche d'une ligne et quatre lignes de données, puis envoie par SMS au patient tout ce qui revient. Voici la requête pour un patient :
Rédigez un rappel pour ce rendez-vous.
Patient : Dana Okafor
Date : jeudi 12 mars
Heure : 14h30
Traitement : Traitement de canal, deuxième visite
Claude a renvoyé cette réponse. Elle est affichée en texte brut, afin que vous puissiez voir chaque caractère que l'application enverrait :
**Rappel de rendez-vous**
Bonjour Dana,
Ceci est un rappel amical de votre prochain rendez-vous dentaire :
**Date :** jeudi 12 mars
**Heure :** 14h30
**Traitement :** Traitement de canal (deuxième visite)
**Avant votre visite :**
- Veuillez arriver environ 10 minutes en avance.
- Prenez un repas léger au préalable, car votre bouche pourrait être engourdie pendant quelques heures après.
- Continuez à prendre vos médicaments tels que prescrits, sauf indication contraire de votre dentiste.
- Faites-nous savoir si vous avez ressenti des douleurs, un gonflement, ou des problèmes avec votre obturation temporaire depuis votre dernière visite.
Si vous devez reporter votre rendez-vous ou si vous avez des questions, veuillez nous appeler au [numéro de téléphone] au moins 24 heures à l'avance.
Nous avons hâte de vous voir !
[Nom du cabinet]
L'application enverrait tout cela par SMS à Dana, et une grande partie n'a pas sa place sur son téléphone :
- Les astérisques et les tirets sont de la syntaxe Markdown pour le texte en gras et une liste. Un téléphone les affiche comme de simples caractères.
- Les conseils sur l'alimentation et l'arrivée en avance sont des conseils concernant la visite, et ces conseils devraient venir du dentiste.
- « Traitement de canal (deuxième visite) » peut s'afficher sur l'écran verrouillé du téléphone de Dana, où d'autres personnes peuvent le voir.
- « [numéro de téléphone] » et « [Nom du cabinet] » sont des espaces vides, et personne ne les remplit avant l'envoi du SMS.
Chacun de ces défauts remonte à quelque chose que la requête a omis. Elle ne dit jamais que le rappel est un SMS, que personne ne le vérifie au préalable, ou que d'autres personnes peuvent le voir sur un écran verrouillé. Elle ne précise pas ce que le rappel doit couvrir, et ne donne ni nom de cabinet ni numéro de téléphone. Claude a donc rédigé un rappel générique et laissé des espaces vides là où il n'avait aucune information.
Ce que vous obtenez en retour dépend surtout de ce que vous donnez en entrée. Avant de retravailler la formulation d'une requête, donnez à Claude les informations qui lui manquent.
Demandez-vous ce qu'un collègue demanderait
Pour trouver ce qui manque, imaginez que vous remettiez la requête à un collègue qui n'a jamais vu l'application. Il doit rédiger le rappel à partir de la seule requête. S'il serait perdu, Claude le sera aussi.
Avant d'écrire un mot, le collègue aurait des questions à vous poser. Chaque question pointe vers l'une des trois parties que vous pouvez ajouter à la requête :
| Partie | Ce qu'elle indique à Claude | Ce que demande le collègue |
|---|---|---|
| Contexte | À quoi sert la réponse, où elle va, et qui la lit | « Est-ce un SMS ou un e-mail ? De qui vient-il ? Quelqu'un le vérifie-t-il avant l'envoi ? » |
| Format de sortie | À quoi ressemble la réponse, par exemple sa longueur et si elle peut utiliser le Markdown | « Quelle doit être sa longueur ? Peut-elle contenir du texte en gras ou une liste ? » |
| Contraintes | Ce à quoi la réponse doit se limiter ou ce qu'elle doit omettre | « Doit-elle nommer le traitement ? Doit-elle donner des conseils ? » |
Répondez à chacune des questions du collègue dans la requête, dans la partie où elle appartient.
Ajoutez le contexte, le format et les contraintes
Énoncez le contexte sous forme de faits, et rédigez le format de sortie et les contraintes sous forme d'instructions. Ajoutez la raison à toute instruction dont Claude ne pourrait pas deviner l'objectif.
La requête finalisée de l'application de prise de rendez-vous ci-dessous répond aux questions du collègue en trois paragraphes, un pour le contexte, un pour le format de sortie, et un pour les contraintes.
Essayez la requête avec et sans chaque partie. Chaque réponse est réelle, enregistrée à partir de Claude pour cette requête exacte.
Essayez-le sur une nouvelle requête
Rendez maintenant vous-même une requête claire et directe. Imaginons qu'une application météo envoie la réponse de Claude telle quelle, dans une notification push que les gens lisent sur leur écran verrouillé à 7 h du matin. La requête de l'application donne à Claude seulement une tâche d'une ligne et quelques données :
Rédigez une notification pour ces prévisions.
Ville : Portland
Matin : nuageux, 48 °F
Après-midi : fortes pluies à partir de 15h
Vent : rafales jusqu'à 35 mph
Réfléchissez à ce qu'un collègue qui n'a jamais vu cette application vous demanderait. Choisissez ensuite le contexte, le format de sortie, et les contraintes qui répondent à ces questions. Après chaque choix, lisez pourquoi il est correct ou non.
La requête de l'application météo dit seulement « Rédigez une notification pour ces prévisions. » Quelle ligne ajouteriez-vous pour donner du contexte à Claude ?
La notification doit tenir sur un écran verrouillé. Quelle ligne ajouteriez-vous comme format de sortie ?
La même requête s'exécute chaque matin, avec de nouvelles prévisions chaque jour. Quelle ligne ajouteriez-vous comme contrainte ?
Où aller ensuite
Chaque fois qu'une réponse doit être corrigée avant que votre application puisse l'utiliser, cherchez la question à laquelle votre requête n'a pas répondu. Pour corriger la requête dans votre propre code, procédez étape par étape :
- Imaginez un collègue qui n'a jamais vu votre application, et réfléchissez à ce qu'il demanderait avant de faire la tâche.
- Dans la requête, répondez à chaque question sous forme de contexte, de format de sortie, ou de contraintes. Énoncez le contexte sous forme de faits, et ajoutez la raison à toute instruction dont Claude ne pourrait pas deviner l'objectif.
- Envoyez la nouvelle requête avec plusieurs entrées provenant de votre application.
- Lisez chaque réponse en texte brut, afin de voir chaque caractère que votre application enverrait. Cherchez les défauts que vous vouliez corriger, tels que du Markdown que votre application ne peut pas afficher, un espace vide que personne ne remplit, ou un détail que vos utilisateurs ne devraient pas voir.
Si un défaut persiste, trouvez la question à laquelle la requête ne répond toujours pas, et répondez-y également.
Lire quelques réponses ne peut pas vous dire à quel point la requête fonctionne bien sur l'ensemble des entrées de votre application. Pour cela, vous avez besoin d'une évaluation (eval), un test sur vos propres cas qui vous donne un chiffre pour décider. À partir d'ici, suivez le cours Introduction aux évaluations.