Un bon prompt est un contrat : il décrit objectif, données disponibles, contraintes et format attendu. Il ne compense pas une connaissance absente, une mauvaise permission ou un workflow mal conçu. Commencez simple et ajoutez une technique seulement pour corriger un échec observé.
Donner un objectif testable
Précisez la tâche, le public et les critères de réussite. Séparez instructions stables, demande utilisateur et contexte. Utilisez des délimiteurs pour les documents non fiables et indiquez qu’ils sont des données, pas des ordres. Évitez les adjectifs vagues comme « excellent » sans critères.
Exemples et décomposition
Quelques exemples montrent le format et les décisions difficiles. Choisissez-les représentatifs, y compris cas limites, et surveillez leur coût en tokens. Pour une tâche complexe, décomposez en étapes applicatives vérifiables plutôt que d’exiger une longue réponse opaque. Ne demandez pas d’exposer un raisonnement interne détaillé ; demandez résultat, sources et vérifications.
Formats et outils
Utilisez les sorties structurées natives pour un objet JSON, puis validez côté serveur. Pour des faits actuels ou privés, fournissez un RAG ou un outil. Le prompt peut guider le choix d’un outil, mais permissions et effets restent contrôlés par le code.
Évaluer
Versionnez prompts, modèle et paramètres. Créez un dataset avec cas normaux, ambigus, longs, hostiles et sans réponse. Mesurez exactitude, format, fidélité, coût et latence. Comparez un changement à la fois et analysez les régressions par catégorie.
FAQ
Faut-il demander au modèle de réfléchir étape par étape ?
Préférez lui demander de vérifier son résultat ou de produire une justification concise adaptée à l’utilisateur.
Une température basse améliore-t-elle l’exactitude ?
Elle réduit surtout la variabilité ; elle n’ajoute pas de connaissance.
Quand arrêter d’améliorer le prompt ?
Lorsque le problème vient des données, du modèle ou de l’architecture.