10 techniques de prompt engineering qui fonctionnent vraiment en production (et 3 qui ne fonctionnent pas)

Les conseils de prompt engineering que l'on trouve en ligne vont de réellement utiles à franchement contre-productifs. Le problème, c'est que la plupart viennent d'expérimentateurs qui testent des tâches simplifiées, et non de bâtisseurs qui exécutent des prompts à volume de production sur des entrées variées. Après avoir observé ce qui fonctionne dans des dizaines d'applications déployées, voici le signal séparé du bruit.

Les techniques qui fonctionnent de façon constante

1. Rôle + tâche + format + contraintes, dans cet ordre. Commencez par dire qui doit être le modèle (rôle), ce qu'il doit faire (tâche), à quoi doit ressembler la sortie (format) et ce qu'il doit éviter (contraintes). Cette structure donne de meilleurs résultats que le prompt en paragraphe de langage naturel pour presque toutes les tâches non créatives.

2. Des exemples (few-shot) pour toute sortie non standard. Si vous avez besoin d'une sortie dans une structure précise, peu courante dans les données d'entraînement (schémas JSON personnalisés, catégories de classification propriétaires, mise en forme propre à un domaine), fournissez 2 à 3 exemples. Les descriptions de ce que vous voulez sont bien moins fiables que des exemples.

3. Les contraintes négatives sont aussi importantes que les instructions positives. « N'incluez pas d'avertissements » et « N'utilisez pas de listes à puces » fonctionnent mieux que « Soyez concis et direct ». Les modèles ont des comportements par défaut ; une négation explicite les supprime plus sûrement que l'espoir qu'une instruction positive l'emporte.

4. Le raisonnement pas à pas (chain-of-thought) pour les tâches de raisonnement en plusieurs étapes. « Réfléchissez étape par étape » ou « Analysez d'abord X, puis déterminez Y, puis produisez Z » améliore réellement les performances sur les tâches de raisonnement. Ce n'est pas du culte du cargo : les étapes intermédiaires forcées font apparaître des erreurs qui sont corrigées avant la sortie finale.

5. Calibrer la température selon le type de tâche. Génération créative : 0,7 à 1,0. Extraction factuelle et classification : 0,0 à 0,2. Sortie structurée : 0,0. La plupart des développeurs laissent la température par défaut pour toutes les tâches, ce qui est une erreur dans la majorité des cas.

6. Séparer le prompt système du prompt utilisateur. Placez les instructions invariables (persona, contraintes, format de sortie) dans le prompt système. Placez le contenu variable (l'entrée réelle à traiter) dans le prompt utilisateur. Les mélanger donne de moins bons résultats et rend les prompts plus difficiles à maintenir.

7. Des ancres de sortie explicites. Terminez votre prompt par le début de la sortie attendue : « Sortie : { » pour du JSON, ou « Voici le résumé : » pour du texte. Les modèles poursuivent à partir de l'ancre de façon plus fiable que lorsqu'ils génèrent la sortie de zéro.

8. Tester avec des entrées adverses. Chaque prompt de production devrait être testé avec des entrées ambiguës, atypiques ou conçues pour contredire vos attentes. Les prompts qui semblent bons sur des entrées typiques échouent fréquemment de façon spectaculaire sur les cas limites que vous rencontrerez inévitablement à grande échelle.

9. Versionner vos prompts. Traitez les prompts comme du code. Versionnez-les, documentez ce qui a changé et mesurez l'impact des modifications sur un jeu de tests constant avant de déployer. La régression de prompt est réelle et souvent négligée.

10. Préciser explicitement le public. « Expliquez cela à un petit entrepreneur non technicien » fonctionne mieux que « Expliquez simplement ». La précision sur le lecteur visé calibre le vocabulaire, la profondeur et le choix des exemples de façon plus fiable que des consignes abstraites de simplicité.

Les techniques qui ne fonctionnent pas (malgré le battage)

Menacer ou soudoyer le modèle. « Si vous ne le faites pas correctement, de mauvaises choses se produiront » ou « Je vous donnerai 200 $ de pourboire » : ces formules ont circulé comme de véritables techniques. Elles ne produisent aucune amélioration mesurable et fiable en production. Ce n'est que du folklore.

Des prompts système extrêmement longs pour des tâches simples. Plus d'instructions ne signifie pas toujours de meilleurs résultats. Pour les tâches simples, un prompt système de 2 000 mots donne souvent de moins bons résultats qu'un prompt ciblé de 200 mots : le modèle « perd » les instructions clés dans le bruit.

Des formulations proches du jailbreak pour contourner la sécurité. Si un modèle refuse de faire quelque chose, reformuler la demande pour la faire passer pour hypothétique ou fictive produit rarement des résultats fiables, et donne souvent des sorties de moindre qualité, même lorsque cela fonctionne.

À retenir en pratique : Passez vos trois prompts de production les plus critiques au crible des techniques ci-dessus. Vous en trouverez presque certainement un qui enfreint le point 3 (contraintes négatives manquantes), un qui enfreint le point 5 (mauvaise température) et un qui n'a jamais été testé avec des entrées adverses. Corrigez d'abord ces trois points.