Itération et débogage des prompts

La conception efficace de messages ne consiste pas à trouver une formule magique : c’est un processus empirique et itératif, davantage comparable au débogage qu’à l’écriture. Vous rédigez un message, l’exécutez avec des entrées de test, observez où il échoue, formulez une hypothèse sur la cause de l’échec, puis modifiez le message pour le corriger. L’intuition seule n’est pas fiable ; vous avez besoin de données.

De nombreux développeurs commettent l’erreur de tester leur message sur un ou deux exemples conçus manuellement, d’obtenir de bons résultats, puis de le mettre en production — pour découvrir ensuite qu’il échoue sur 30 % des entrées réelles. Un processus d’évaluation systématique évite cela en exposant votre message à des exemples divers et représentatifs avant sa mise en service.

Avant d’écrire votre message, constituez un ensemble de test de référence : une collection de 20 à 100 exemples d’entrées représentatifs, associés au résultat attendu ou aux critères de réussite. Cet ensemble devient votre référence pour évaluer toute modification du message.

Les bons ensembles de test comprennent : des entrées typiques, des cas limites (chaînes vides, entrées très longues, cas ambigus), des entrées adverses conçues pour mettre le message en défaut et des entrées provenant de différents segments de votre population d’utilisateurs. Plus votre ensemble de test est diversifié, plus vous pouvez avoir confiance dans le fait qu’une modification constitue une véritable amélioration plutôt qu’un surapprentissage des quelques exemples que vous aviez en tête.

Écrire un script d’évaluation simple prend une heure et vous fait économiser des jours de débogage des problèmes de production. Le script exécute votre message avec chaque cas de test, compare la sortie au résultat attendu et indique un taux de réussite. Vous pouvez ensuite itérer sur le message et voir immédiatement si vos modifications ont amélioré le score global.

Lorsque votre message échoue sur certains cas de test, regroupez les échecs par type afin d’identifier des tendances. Les modes d’échec courants comprennent :

• Échecs de format : le modèle produit la bonne réponse, mais dans un format incorrect
• Échecs liés à l’ambiguïté : le modèle interprète la tâche différemment de ce que vous aviez prévu
• Échecs sur les cas limites : le modèle fonctionne avec les entrées typiques, mais échoue avec les entrées inhabituelles
• Échecs dus aux hallucinations : le modèle produit avec assurance un contenu factuel erroné
• Non-respect des instructions : le modèle suit partiellement les instructions, mais ne respecte pas certaines contraintes précises

Chaque type d’échec exige une correction différente. Les échecs de format nécessitent des instructions de sortie plus explicites ; les échecs liés à l’ambiguïté nécessitent une définition plus claire de la tâche ou des exemples.

L’OpenAI Playground (platform.openai.com/playground) est l’outil le plus rapide pour itérer sur des messages sans écrire de code. Il vous permet de changer de modèle, d’ajuster les paramètres à l’aide de curseurs, d’enregistrer des versions de messages et de comparer les sorties côte à côte.

Utilisez le Playground pendant la phase d’exploration de la conception des messages : essayez différentes formulations, testez interactivement les cas limites et développez votre intuition sur ce qui fonctionne. Une fois que vous avez convergé vers un message prometteur, passez au code avec un outil d’évaluation afin de le valider systématiquement sur l’ensemble de votre jeu de tests avant sa mise en production.

Les messages sont du code. Ils doivent être gérés avec un contrôle de version, examinés et déployés avec la même rigueur que le code de l’application. L’approche la plus simple consiste à stocker vos modèles de messages sous forme de chaînes dans un fichier de constantes de votre dépôt, afin que les modifications soient suivies dans git et nécessitent une revue du code.

Les approches plus avancées consistent notamment à stocker les messages dans une base de données dédiée à leur gestion (LangSmith, PromptLayer ou une simple table Supabase), à étiqueter les versions et à effectuer des tests A/B entre les versions de messages en production. Cela est particulièrement important lorsque plusieurs membres de l’équipe travaillent sur les mêmes messages ou lorsque vous devez annuler une modification qui a dégradé la qualité en production.

Lorsque vous avez deux versions concurrentes d’un prompt, exécutez-les toutes les deux sur l’intégralité de votre ensemble de tests et comparez les scores. Même une amélioration de 5 % de la précision sur un système en production traitant des milliers de requêtes par jour justifie l’effort d’évaluation. Ne choisissez jamais un prompt sur la base d’un ou deux exemples testés manuellement — comparez-les toujours sur l’ensemble des tests.

Pour les mesures de qualité subjectives, lorsqu’il n’existe pas de réponse unique correcte (par exemple le ton, l’utilité ou la créativité), vous pouvez utiliser un LLM comme évaluateur : demandez à un modèle puissant comme GPT-4o d’évaluer laquelle de deux réponses respecte le mieux vos critères de qualité. Cette méthode permet d’étendre l’évaluation au-delà de ce qu’un examen humain peut traiter.

Par défaut, les sorties des LLM ne sont pas déterministes. Définir temperature=0 rend les sorties presque déterministes (le jeton le plus probable à chaque étape), ce qui est essentiel pour le débogage, car cela vous permet d’exécuter deux fois le même prompt et d’obtenir la même sortie. Lors du débogage, définissez toujours la température sur 0 afin de déterminer si une modification du prompt a provoqué le changement de sortie ou s’il s’agit simplement d’une variation aléatoire.

Une fois le prompt corrigé, réactivez une certaine température en production si votre cas d’utilisation bénéficie de variété (écriture créative, recherche d’idées), mais conservez une température de 0 pour les tâches d’extraction structurée et de classification qui nécessitent des sorties cohérentes et reproductibles.

Si votre prompt produit des faits hallucinés, ajoutez des contraintes qui rendent les hallucinations plus difficiles. Voici quelques techniques efficaces pour les limiter :

• Citer les sources : « Répondez uniquement à partir du contexte fourni. Si la réponse ne figure pas dans le contexte, dites que vous ne savez pas. »
• Quantifier la confiance : « Évaluez votre niveau de confiance de 1 à 5. S’il est inférieur à 3, ne répondez pas. »
• Ajouter une étape de vérification : « Avant de répondre, vérifiez que chaque fait que vous prévoyez d’utiliser figure dans le document fourni. »

Aucune technique n’élimine complètement les hallucinations, mais la combinaison de la récupération (RAG) et de contraintes fortes dans le prompt les réduit considérablement pour les applications qui reposent largement sur les connaissances.

Les recherches montrent que les LLM accordent davantage d’attention aux instructions placées au début et à la fin d’un prompt qu’à celles placées au milieu. C’est ce qu’on appelle le problème du milieu oublié. Si vous avez un long prompt contenant des instructions importantes enfouies au milieu et entourées de contexte, le modèle risque de ne pas les suivre de manière fiable.

Bonne pratique : placez vos instructions les plus importantes (la définition de la tâche et les contraintes critiques) tout au début du prompt système, puis rappelez les contraintes essentielles à la fin. Pour les longs documents injectés comme contexte, placez la question de l’utilisateur après le document plutôt qu’avant, car le modèle accorde davantage de poids au contenu le plus récent.

Le cycle de développement des prompts comporte trois phases :

• Exploration : utilisez le Playground pour expérimenter librement. Cherchez à comprendre ce qui fonctionne sur le plan conceptuel, plutôt qu’à obtenir une sortie parfaite.
• Évaluation : constituez un ensemble de tests et un dispositif d’évaluation. Exécutez les prompts candidats sur l’ensemble des tests et mesurez les taux de réussite. Répétez le processus jusqu’à atteindre votre seuil de qualité.
• Production : gérez la version du prompt final, ajoutez une surveillance pour suivre les indicateurs de qualité en production et configurez des alertes en cas de dégradation de la qualité. Prévoyez de futures itérations lorsque les versions des modèles changent.

Le fait de sauter la phase d’évaluation est la cause la plus fréquente des régressions de qualité des prompts en production. Le temps consacré à constituer un ensemble de tests approprié est largement rentabilisé.

Vérifiez votre compréhension des concepts d’ingénierie de l’IA présentés dans cette leçon.

Dans cette leçon, vous avez appris que l’ingénierie des prompts nécessite un ensemble de tests de référence et un dispositif d’évaluation pour mesurer les améliorations de manière fiable, que les modes d’échec doivent être catégorisés afin d’identifier la correction adaptée à chaque type, et que la température 0 est essentielle au débogage, tandis que la gestion des versions des prompts et la surveillance en production permettent de boucler le suivi de la qualité. Nous allons maintenant voir comment les LLM traitent le texte au moyen de jetons et pourquoi le nombre de jetons est important pour le coût et le contexte.