Prompt engineering en production : comment tester les modifications ?
Traduction automatique
Cet article a été traduit automatiquement depuis la version originale en anglais.
Définissez les sorties attendues, rassemblez des cas représentatifs et comparez une modification du prompt à une référence fixe. Améliorez la consigne, les exemples ou le contexte fourni en fonction de l’échec observé. Gardez un jeu de test à part pour vérifier si la modification fonctionne au-delà des exemples utilisés pour la concevoir.
Un prompt en production doit gérer les entrées incomplètes, ambiguës et invalides, ainsi que les demandes ordinaires.
Transformez les échecs en cas de test
Supposons qu’un modèle extraie les champs de factures. Incluez des factures ordinaires, des valeurs manquantes, des mises en page inhabituelles, des dates contradictoires et des documents qui ne sont pas des factures. Définissez comment le système doit traiter chaque cas avant de modifier le prompt.
| Échec | Modification à comparer | Contrôle |
|---|---|---|
| Champ obligatoire manquant | Préciser le champ et ajouter un exemple pertinent | Le champ est présent lorsque la source le justifie |
| Valeur inventée | Spécifier le comportement en cas de valeur absente et fournir des éléments justificatifs | Le champ non justifié reste vide |
| Réponse impossible à analyser | Utiliser un schéma de sortie pris en charge | L’analyseur accepte la réponse complète |
| Valeur correcte provenant de la mauvaise source | Conserver l’identité de la source dans le contexte | La valeur appartient au document demandé |
Une sortie contrainte par un schéma peut résoudre les erreurs de syntaxe. La documentation de vLLM sur les structured outputs décrit les contraintes de sortie prises en charge. Un objet JSON valide peut néanmoins contenir une date erronée ou une affirmation non étayée ; validez donc les valeurs séparément.
Gardez une comparaison interprétable
Maintenez constants la version du modèle, les paramètres de décodage, les données sources, les définitions des outils et les limites de sortie pendant le test de la modification du prompt. Consignez la qualité, les catégories d’échec, les tokens et la latence. Répétez les cas non déterministes suffisamment de fois pour voir si l’amélioration se maintient.
Les exemples few-shot doivent couvrir les variations réelles, y compris les entrées incomplètes ou ambiguës. Ajoutez-les pour résoudre un problème mesuré, plutôt que de supposer que davantage d’exemples sont toujours utiles. La position dans le contexte peut aussi compter : Lost in the Middle a constaté une utilisation inégale des éléments justificatifs selon leur position dans les modèles et les tâches testés.
Utilisez des étapes explicites lorsqu’elles facilitent l’isolation d’un échec, mais incluez les appels et les interfaces supplémentaires dans la comparaison. Faites respecter les autorisations et les autres règles impératives de l’application dans le code ; un message système seul ne peut pas les garantir.
La section sur les prompts en production du Guide d’ingénierie des LLM explique les principales techniques et leurs limites.