LLM-as-a-judge : prompts libres, notation par grille ou juge typé avec abstention

LLM-as-a-judge est un schéma d’évaluation : un modèle lit une tâche, la sortie du système testé et parfois une réponse de référence, puis rend une note. La recherche qui a nommé ce schéma (Zheng et al., 2023, « Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena ») décrit trois formes : comparaison par paires, notation d’une réponse unique et notation guidée par une référence. Quelle que soit la forme, un juge mesure l’accord avec les critères que vous avez écrits, tels qu’un autre modèle les interprète. Il ne mesure ni la vérité, ni la satisfaction utilisateur, ni le résultat métier, sauf si vos critères et labels humains y sont reliés. Le juge doit donc être évalué comme tout classifieur. Cette page porte sur le jugement d’autres sorties d’IA—réponses de chatbot, résumés, réponses RAG, étapes d’agent. Pour évaluer un workflow JevModel lui-même avec des labels, voir evaluation.

Les trois options diffèrent surtout par la stabilité de la sortie et la visibilité de l’incertitude. Les prompts libres démarrent vite ; les grilles rendent les notes comparables entre exécutions ; un juge typé ajoute un schéma fixe et des probabilités seuillables. Il s’agit de compromis d’ingénierie, pas d’un classement de modèles juges.

Zheng et al. (2023) décrivent trois biais à anticiper. Biais de position : en comparaison par paires, le verdict peut s’inverser quand les deux réponses échangent leur place ; exécutez donc chaque paire dans les deux ordres et ne comptez une victoire que si les deux concordent, sinon notez une égalité. Biais de verbosité : le juge peut préférer la réponse la plus longue même si la longueur n’apporte rien ; rédigez des critères qui récompensent le respect de l’exigence, pas l’exhaustivité, et incluez des réponses courtes et justes dans vos fixtures. Biais d’auto-valorisation : un juge peut favoriser des sorties qui lui ressemblent ; ne laissez pas le modèle testé se noter lui-même et masquez quel système a produit chaque réponse. Deux habitudes aident aussi : un critère par question plutôt qu’une note globale de « qualité », et, pour les tâches factuelles, une réponse de référence fournie au juge, car il peut être induit en erreur par une réponse fausse mais assurée qu’il aurait su résoudre.

Échantillonnez de vraies sorties, y compris les difficiles, et faites-les labelliser à l’aveugle par deux personnes avec les mêmes critères écrits. Si elles sont souvent en désaccord, corrigez les critères avant d’accuser le juge : des humains qui ne s’accordent pas ne donnent au juge rien de stable à reproduire. Exécutez ensuite le juge sur les mêmes éléments et rapportez l’accord par classe, pas seulement global : un juge qui valide tout paraît précis quand la plupart des sorties sont correctes. Une table de confusion juge vs humain, plus une statistique corrigée du hasard comme le kappa de Cohen si votre équipe l’utilise, montre où il échoue. Vérifiez ensuite les bandes de probabilité : parmi les éléments notés avec forte probabilité par le juge, combien les humains ont-ils jugés pareil ? Choisissez à partir de ce tableau une bande d’acceptation automatique et une bande de revue. Figez l’échantillon comme jeu de régression et relancez-le à chaque changement de prompt, de critères ou de modèle. Console → Batch de JevModel peut exécuter une question de juge fixe sur des lignes importées et exporter les réponses pour cette jointure.

Placez dans state la tâche, une référence facultative et une sortie candidate, puis posez une question par critère. Dans JevModel, Noul est une question oui/non qui renvoie une probabilité de 0 à 1, adaptée aux contrôles binaires comme « chaque affirmation est-elle étayée par le contexte fourni ? ». Score prend 2 à 10 descriptions de niveaux ordonnés et renvoie une valeur sur cette échelle, qui peut tomber entre deux niveaux ; il convient aux critères gradués comme l’utilité, mais ce n’est pas une probabilité entre 0 et 1 : définissez vos propres bandes. Une requête peut porter 1 à 8 questions nommées, et le state sérialisé comme la requête complète doivent chacun tenir en 8 000 caractères : les longues réponses ou passages récupérés doivent être extraits. Pour la comparaison par paires, envoyez deux requêtes avec les candidats en ordre inverse et n’acceptez que les résultats cohérents. Une probabilité Noul proche du milieu, ou un Score entre vos niveaux réussite et échec, est votre signal d’abstention : envoyez ces éléments à une personne au lieu de les compter. Les appels vont vers POST /api/v1/systemone avec le modèle fixe typesafe/jev-1.13 via OpenRouter.

{
  "state": {
    "task": "Answer the customer using only the help-center context.",
    "context": "Refunds are available within 30 days of purchase for annual plans.",
    "candidate_answer": "You can get a refund within 30 days if you are on an annual plan."
  },
  "questions": {
    "grounded": {
      "type": "noul",
      "instructions": "Is every factual claim in candidate_answer supported by the context?",
      "criteria": {
        "true": "All claims appear in or follow directly from the context.",
        "false": "At least one claim is missing from or contradicts the context."
      }
    },
    "helpfulness": {
      "type": "score",
      "instructions": "How well does candidate_answer resolve the task? Do not reward length.",
      "criteria": [
        "Does not address the task or is misleading.",
        "Addresses part of the task or needs a follow-up.",
        "Fully resolves the task in the needed detail."
      ]
    }
  }
}

Passez-vous du juge quand le code peut vérifier la réponse : JSON valide, correspondance exacte avec un label attendu, test unitaire réussi, requête SQL renvoyant les bonnes lignes. Les contrôles déterministes coûtent moins et ne dérivent pas. N’utilisez pas un juge comme seule validation pour des décisions juridiques, médicales, financières ou de sécurité ; servez-vous-en pour prioriser la revue humaine. Ne faites pas confiance à un juge jamais comparé à des labels humains, et ne laissez pas un modèle noter ses propres sorties. Méfiez-vous des mathématiques, de l’exactitude du code et du raisonnement en plusieurs étapes, où le juge peut être induit en erreur par la réponse qu’il note ; préférez des réponses de référence ou des tests par exécution. JevModel en particulier est un modèle de décision pour texte et JSON : il n’exécute pas de code, ne navigue pas et ne lit pas d’images ; il juge donc ce qui est écrit dans state, pas ce qui se passe quand la sortie est exécutée. Il n’est pas open source, et les comptes gratuits vérifiés ont 5 exécutions réussies par jour UTC : assez pour essayer un juge, pas pour noter chaque jour un grand jeu d’évaluation.