Évaluateur-Optimiseur
Un premier LLM génère une réponse tandis qu'un second l'évalue par rapport à des critères et renvoie des commentaires ; le générateur la révise et la boucle se répète jusqu'à ce que l'évaluation soit validée. Cela améliore la qualité sur les tâches dotées de critères d'évaluation clairs, au prix d'appels supplémentaires.
Problème
Un résultat généré en une seule passe peut omettre certaines exigences, et il n'existe aucun mécanisme intégré pour le vérifier et l'améliorer avant son utilisation.
Quand l'utiliser
Utilisez le pattern évaluateur-optimiseur lorsque vous pouvez formuler des critères d'évaluation clairs et que l'affinement itératif améliore le résultat de manière mesurable — par exemple pour la qualité d'une traduction, du code devant passer des tests ou de la rédaction basée sur une grille d'évaluation.
Solution
Un générateur produit une proposition ; un évaluateur (un appel LLM distinct ou un contrôle déterministe) lui attribue un score selon des critères explicites et renvoie des commentaires exploitables. Le générateur révise sa proposition, et le cycle se répète jusqu'à ce que les critères soient satisfaits ou qu'un budget limite soit atteint.
Séparer la génération de l'évaluation s'apparente à la relation entre un auteur et son éditeur : le critique détecte les problèmes qui ont échappé à l'auteur, et des critères explicites permettent à la boucle de converger.
Composants
Avantages
- Qualité supérieure sur les tâches dotées de critères clairs.
- Détecte les erreurs qu'une seule passe aurait laissées passer.
- Les retours sont explicites et exploitables.
Risques
- Les appels supplémentaires augmentent la latence et les coûts.
- Un évaluateur peu performant fournit des retours trompeurs.
- Les boucles peuvent ne pas converger en l'absence de budget limite.
Quand ne pas l'utiliser
- Lorsque les critères ne peuvent pas être définis clairement.
- Lorsqu'une seule passe est déjà amplement suffisante.
- Lorsque les budgets de latence ou de coût sont très serrés.
Technologies
Exemples
- Générer du code, exécuter des tests et réviser jusqu'à ce qu'ils réussissent.
- Rédiger une traduction et l'affiner par rapport au texte source.
- Rédiger selon une grille d'évaluation avec un critique veillant au respect de chaque critère.
KPI
- Taux d'acceptation
- Part des propositions acceptées par l'évaluateur dès la première passe — un taux trop élevé signifie que la barre est placée trop bas, un taux trop bas indique un problème avec le générateur ou la grille d'évaluation.
- Itérations jusqu'à acceptation
- Nombre moyen de boucles évaluation→révision avant acceptation ; une augmentation de ce nombre signale un générateur faible ou des critères vagues.
- Coût et latence par résultat accepté
- Nombre total de tokens et temps réel écoulé sur l'ensemble des itérations de la boucle, et pas seulement lors de l'appel final — la boucle multipliant ces deux facteurs.
- Accord évaluateur-humain
- Fréquence à laquelle le verdict de l'évaluateur correspond à celui d'un réviseur humain sur un ensemble échantillonné ; la boucle ne vaut que ce que vaut l'évaluateur.
Modes de défaillance observés
- Détournement de récompense (reward hacking) : le générateur apprend à satisfaire la formulation de l'évaluateur plutôt que l'objectif réel.
- Évaluateur faible ou mal calibré : il accepte de mauvaises sorties ou rejette les bonnes, de sorte que la boucle ajoute du coût sans apporter de qualité.
- Boucles infinies ou oscillantes lorsqu'aucun candidat ne franchit le seuil — sans limite d'itérations, le coût est illimité.
- Dérive des critères : des grilles d'évaluation vagues ou changeantes rendent l'acceptation non déterministe et difficile à auditer.
Leçons apprises
- Limitez les itérations et définissez une solution de repli (renvoyer le meilleur résultat obtenu jusqu'à présent, ou escalader) afin que la boucle se termine toujours.
- Rendez les critères d'acceptation explicites et stables ; un évaluateur ne vaut que ce que vaut sa grille d'évaluation.
- Validez l'évaluateur par rapport au jugement humain avant de lui faire confiance comme filtre de validation.
- N'utilisez la boucle que là où la qualité justifie le coût multiplié — pas pour des sorties peu coûteuses et à faibles enjeux.
FAQ
- En quoi cela diffère-t-il de la réflexion ?
- La réflexion repose sur l'autocritique du même modèle. Le modèle évaluateur-optimisateur sépare les rôles : un évaluateur distinct juge le générateur, ce qui donne souvent des retours plus précis et moins biaisés.
- L'évaluateur peut-il être déterministe ?
- Oui. Pour du code, un exécuteur de tests est un évaluateur idéal ; pour une sortie structurée, une vérification de schéma convient. Utilisez un modèle comme juge pour des critères nuancés.
- Combien d'itérations ?
- Définissez un budget (par exemple, 2 à 3) et arrêtez-vous lorsque les critères sont respectés. Les boucles illimitées gaspillent du budget et peuvent ne pas converger.