Introduction

Pour certaines tâches, une seule vérification suffit. Si la compilation réussit et que tous les tests passent, le travail est terminé. Certains problèmes d’optimisation, en revanche, demandent de nombreuses itérations, chacune suivie de près par une évaluation. Pour décider comment avancer, Codex doit examiner le résultat obtenu, lui attribuer un score, choisir la prochaine modification et recommencer jusqu’à obtenir un résultat satisfaisant.

Une interface personnalisée se prête bien à ce type de tâche. Demandez à Codex d’enregistrer les résultats et les artefacts générés à chaque itération pour pouvoir suivre les progrès visuellement. Dans l’application, vous pouvez voir Codex poursuivre son travail et suivre l’amélioration de l’artefact visé, de la sortie du modèle ou de la ressource générée. Pour cela, fournissez à Codex les scripts nécessaires pour calculer les métriques d’évaluation et générer les artefacts à examiner.

Commencez par les évaluations

Avant de lancer la tâche, définissez vos critères de réussite. En général, il est préférable de combiner deux types de vérifications :

• Vérifications déterministes : les scripts calculent directement un score, par exemple en comptant les violations de contraintes ou en calculant des métriques déterministes par programme.
• Vérifications par un LLM évaluateur : le LLM utilise une grille de notation pour évaluer des qualités difficiles à traduire en règles précises, comme la ressemblance, la lisibilité, l’utilité ou la qualité globale. Il peut évaluer du texte ou des images.

Si les critères subjectifs sont importants, fournissez à Codex un script capable d’appeler un modèle, par exemple via l’API Responses, et de renvoyer les scores dans un format structuré. Le modèle complète les vérifications déterministes en appliquant les mêmes critères aux aspects qu’une personne devrait autrement apprécier à l’œil.

La boucle fonctionne mieux si les résultats des évaluations sont lisibles par machine, enregistrés après chaque exécution et faciles à comparer d’une exécution à l’autre.

Donnez à Codex un critère d’arrêt

Une tâche difficile risque de se prolonger indéfiniment si le prompt indique « continue à améliorer le résultat » sans préciser quand s’arrêter. Formulez explicitement le critère d’arrêt.

Vous pouvez procéder ainsi :

1. Fixez un seuil pour le score global.
2. Fixez un seuil distinct pour la moyenne des scores attribués par le LLM.
3. Demandez à Codex de poursuivre jusqu’à ce que les deux scores dépassent leurs seuils respectifs. Franchir un seul seuil ne suffit pas.

Par exemple, si vous visez un artefact de grande qualité, demandez à Codex de poursuivre jusqu’à ce que le score global et la moyenne des scores attribués par le LLM dépassent tous deux 90 %. Codex peut ainsi déterminer quels scores restent sous leur seuil, où se situe l’écart et si la dernière modification a amélioré le résultat.

Tenez un journal des itérations

Pour les tâches de longue durée, le travail de Codex est bien plus fiable s’il consigne le déroulement des itérations au lieu de s’appuyer uniquement sur le contexte de la discussion.

Demandez à Codex de consigner dans ce journal :

• les meilleurs scores obtenus à ce jour
• les modifications apportées lors de la dernière itération
• les améliorations et les régressions relevées par l’évaluation
• ce que Codex prévoit d’essayer à l’itération suivante

Ce suivi est particulièrement important pour les tâches de longue durée. Le journal permet de reprendre la tâche là où elle s’est arrêtée et conserve une trace de l’autoévaluation de Codex pour l’exécution en cours.

Examinez aussi l’artefact produit

Pour certaines tâches difficiles, les différences entre les versions du code et les valeurs des métriques ne suffisent pas. Codex doit examiner l’artefact qu’il a produit.

Si le résultat est visuel, par exemple une image générée, une mise en page ou le rendu d’une interface dans un état donné, permettez à Codex de l’examiner directement. Il peut par exemple ouvrir une image enregistrée sur disque, puis comparer le résultat au meilleur résultat obtenu jusque-là ou le confronter aux critères de la grille d’évaluation.

La boucle d’évaluation gagne ainsi en efficacité :

• le script d’évaluation fournit le score
• l’examen de l’artefact révèle ce que le score ne reflète pas
• Codex s’appuie sur les deux pour choisir la modification suivante

Cette méthode est bien plus efficace que de modifier le code à l’aveugle entre deux exécutions.

Précisez les étapes de chaque itération

Demandez à Codex de suivre les mêmes étapes à chaque itération :

1. Exécutez les évaluations sur la version de référence actuelle.
2. Identifiez le principal problème à partir des scores et des artefacts.
3. Apportez une seule modification ciblée pour remédier à ce problème.
4. Relancez les évaluations.
5. Consignez les nouveaux scores et indiquez si la modification a amélioré le résultat.
6. Poursuivez jusqu’à ce que les seuils soient atteints.

Suivez ces étapes avec rigueur. Si Codex modifie trop de choses à la fois, il ne peut pas déterminer quelle modification a amélioré le score. S’il omet de tenir le journal, il devient difficile de se fier aux résultats et de reprendre la tâche.