Le prompt engineering n’est pas de la magie, c’est une discipline. C’est l’équivalent de l’UX pour un modèle de langage : on guide l’IA vers le résultat souhaité avec des instructions claires, des exemples pertinents et des contraintes explicites. Un bon prompt n’est pas le plus long ou le plus poétique, c’est celui qui produit des réponses utiles, stables et au coût le plus faible, de manière répétée.
prérequis
- Un objectif clair et un schéma de sortie attendu. Vous devez savoir à quoi ressemble une “bonne” réponse avant de commencer.
- Un petit jeu de données d’exemples réels (10 à 50) pour tester et évaluer vos prompts.
- Un moyen de journaliser (logger) chaque prompt et sa réponse pour assurer la traçabilité.
la structure d’un prompt efficace
Un prompt robuste est structuré comme un briefing. Chaque section a un rôle précis pour guider le modèle.
Voici comment cela se traduit en pratique :
- Rôle: “Tu es un assistant technique qui résume des rapports d’incident de manière factuelle.”
- Tâche: “Extrais les informations clés du rapport suivant.”
- Contraintes: “Ne dépasse pas 100 mots. N’invente aucune information. Utilise des puces.”
- Sortie: “Fournis la réponse au format JSON avec les clés :
id_ticket,resume,actions_proposees.” - Exemples: Fournir 2 ou 3 paires de rapport/résumé attendu.
travailler par variantes et A/B tester
Ne vous contentez jamais de votre premier prompt. Le prompt engineering est un processus itératif où l’on teste plusieurs variantes pour trouver la plus performante.
- Jouer avec les paramètres: Testez différentes valeurs de
temperatureoutop_p. Une température basse (ex: 0.2) favorise des réponses déterministes et factuelles. Une température plus élevée favorise la créativité. - Évaluer sur un lot fixe: Comparez les performances de vos variantes sur votre jeu d’exemples. Mesurez l’exactitude, la longueur, la conformité au format.
- Geler la version: Une fois que vous avez trouvé un prompt qui fonctionne, gelez sa version et ne le modifiez plus sans repasser par un cycle de test.
les garde-fous pour la production
Un prompt destiné à la production doit être défensif.
- Refuser les tâches hors périmètre: “Si la demande n’est pas liée à un rapport d’incident, réponds que tu ne peux pas l’aider.”
- Imposer un format de sortie strict: Demandez toujours une sortie en JSON et validez-la avec un parseur. Si le JSON est invalide, vous pouvez relancer la requête ou remonter une erreur.
- Couper les sorties trop longues: Utilisez le paramètre
max_tokenspour éviter les réponses interminables qui augmentent la latence et les coûts. - Filtrer les données personnelles (PII): Ajoutez une instruction explicite pour ne jamais inclure de nom, d’email ou de numéro de téléphone dans la réponse.
mesurer ce qui compte
- Taux de réponse utile: Demandez aux utilisateurs de noter la réponse avec un simple pouce levé/baissé. C’est la métrique la plus importante.
- Longueur moyenne: Surveillez le nombre de tokens pour maîtriser les coûts.
- Coût par tâche: Calculez le coût moyen pour accomplir une tâche métier (ex: “résumer un ticket”).
- Latence p95: Assurez-vous que l’expérience reste rapide pour 95% de vos utilisateurs.
erreurs fréquentes
-
Symptôme: Les réponses du LLM sont vagues et imprévisibles.
- Cause: L’objectif du prompt est flou.
- Correctif: Définir l’objectif en une seule phrase testable (ex: “le prompt doit extraire l’entité X du texte Y”).
-
Symptôme: L’application casse souvent en essayant de traiter la réponse du LLM.
- Cause: Le format de sortie est libre.
- Correctif: Toujours demander une sortie en JSON avec un schéma précis, puis la valider dans votre code.
-
Symptôme: La facture OpenAI est très élevée.
- Cause: Prompts trop longs et verbeux.
- Correctif: Soyez concis. Utilisez des sections claires. Chaque mot a un coût.
-
Symptôme: Impossible de reproduire une bonne réponse obtenue la semaine dernière.
- Cause: Pas de traçabilité.
- Correctif: Logguez et versionnez chaque prompt. Associez chaque réponse à la version exacte du prompt qui l’a générée.