LLM en tant que juge : Exécution inline comme garde-fou du Gateway

Ce qu’est réellement un LLM en tant que juge

Un juge est un modèle auquel on fournit trois éléments : une sortie à évaluer, une grille décrivant ce qui est « bon », et une instruction pour retourner un verdict lisible par une machine : succès/échec, une note, ou une préférence entre deux candidats.

Il existe parce que l’alternative n'est pas évolutive. Les métriques d'équivalence exacte fonctionnent lorsqu'il n'y a qu'une seule bonne réponse ; elles sont inutiles pour une réponse de support où cinq réponses différentes sont toutes correctes. Les humains évaluent bien ces réponses, mais lentement. Un juge se situe entre les deux : moins précis qu'un humain attentif, bien meilleur qu'une comparaison de chaînes de caractères, et suffisamment rapide pour des milliers d'échantillons. Traitez-le comme un proxy économique, bruyant et corrélé aux évaluations humaines.

Deux modes constamment confondus

L’erreur la plus fréquente consiste à traiter l’évaluation offline et le filtrage online comme une seule et même chose ayant deux cibles de déploiement différentes.

La ligne concernant les défaillances est celle qu'il faut intégrer. En mode offline, un score erroné fausse une décision que vous réviserez au prochain sprint ; en mode online, c'est un utilisateur face à une erreur. Il faut donc régler un juge online pour maximiser la précision, même au détriment du rappel. Dupliquer une grille d'évaluation d'un mode à l'autre est la raison pour laquelle des équipes finissent par bloquer un pourcentage de trafic légitime.

Où les juges excellent, et où ils échouent

Les juges sont efficaces pour les critères qui sont descriptibles mais non calculables — par exemple : cela est-il ancré dans le contexte extrait, le ton est-il adapté à un contexte clinique. Vous pouvez rédiger la règle dans un paragraphe, mais pas sous forme de regex. Ils échouent principalement de trois manières.

Biais de position. Face à deux candidats, les juges favorisent un emplacement précis ; inversez l'ordre et une part significative des verdicts bascule. La solution consiste à évaluer chaque paire deux fois en inversant les positions et à ne comptabiliser que les accords, ce qui double vos coûts.

Biais de verbosité. Les réponses plus longues obtiennent des scores plus élevés, indépendamment du fait que les mots supplémentaires apportent de la valeur. Cela pousse insidieusement les prompts de production à ajouter du remplissage : vous optimisez par rapport au juge, le juge récompense la longueur, la facture de tokens augmente, et personne ne fait le lien entre les deux.

Auto-préférence. Un modèle attribue des notes plus élevées aux textes qui ressemblent à ses propres générations. Si GPT évalue la sortie de GPT, le score est surestimé — c'est le meilleur argument pour utiliser un juge issu d'une famille différente de celle du modèle testé.

Les juges sont également mal calibrés sur les échelles continues : demandez une note sur 10 et toutes les réponses se regroupent entre 7 et 8. Un résultat binaire succès/échec basé sur un critère strict est bien plus fiable. Et un juge ne peut pas vérifier un fait qu'il ne possède pas — sans document de référence, vous obtenez ses a priori, pas une vérification des faits.

Choisir un juge et en financer le coût

Issu d'une famille différente de celle du modèle évalué, car l'auto-préférence est réelle et facile à éviter. Plus petit que vous ne le pensez, car juger consiste à classifier selon un long prompt, et non à raisonner. Versionné et fixe, et non flottant, car un alias de fournisseur qui évolue automatiquement modifie votre niveau d'exigence sans changement de code. Et avec un p99 inférieur à celui de l'élément qu'il protège, sous peine de voir le juge devenir votre facteur limitant de latence.

Passons au calcul. Un juge inline représente une seconde inférence ; si vous contrôlez à la fois le prompt et la réponse, cela en fait deux. Il ne s'agit pas d'un surcoût que vous pouvez éliminer par l'ingénierie, la question est donc de savoir quelle portion du trafic est concernée :

• Échantillonnez. Évaluez 5 % pour la télémétrie de qualité ; passez à 100 % uniquement pour les contrôles de sécurité qui ne doivent jamais manquer leur cible.
• Divisez la grille d'évaluation. Appliquez des contrôles déterministes économiques sur l'ensemble du trafic ; n'utilisez le juge que si ces contrôles réussissent et que la surface est sensible.
• Filtrez en entrée, échantillonnez en sortie. Les garde-fous d'entrée peuvent s'exécuter en parallèle de l'appel au modèle, coûtant des tokens mais peu de temps d'exécution. Ce n'est pas le cas des garde-fous de sortie.

Quand un classificateur plus économique l'emporte

Si vous pouvez exprimer la règle sous forme de code, exprimez-la sous forme de code.

Où les équipes commettent des erreurs

Elles déploient la grille d'évaluation offline sur le parcours de la requête. Une grille à dix dimensions qui fonctionne lors d'un test nocturne devient un obstacle lent et instable en production. Les grilles online doivent se limiter à un seul critère binaire, rédigé de manière suffisamment précise pour qu'un petit modèle y réponde de façon constante.

Elles ne mesurent jamais le juge. C'est un modèle en production dépourvu de sa propre évaluation. Annotez manuellement quelques centaines d'exemples réels et analysez la précision et le rappel séparément. Si vous ne pouvez pas déterminer le taux de faux positifs, vous ne pouvez pas savoir quelle proportion d'utilisateurs subit des échecs liés au garde-fou.

Elles passent directement au blocage strict. Un juge précis à 90 % bloque une bonne réponse sur dix dès le jour où vous l'imposez. Procédez d'abord à un audit, analysez une semaine de traces, puis passez en production.

Elles oublient les réponses en streaming. Envoyez des tokens au navigateur en streaming et un juge de sortie n'aura rien à évaluer avant la fin du flux. La plupart des gateways, TrueFoundry inclus, ignorent les garde-fous de sortie sur les requêtes en streaming.

Vous souhaitez voir le verdict d'un juge apparaître sur une trace ?

Acheminez une requête via un gateway avec un garde-fou de type juge et ouvrez le span.

Commencer gratuitement

Comment cela fonctionne dans TrueFoundry

TrueFoundry ne propose pas de produit d'évaluation dédié. Pas de page d'évaluation, pas de jeux de données, pas de suivi d'expériences, pas d'interface de notation. L’évaluation offline relève des plateformes conçues à cet effet, et le rôle de TrueFoundry consiste à exporter des traces via OpenTelemetry — des traces, et non des métriques OTEL, depuis cet écran. Pour un jeu de données noté et un tableau de classement, utilisez Braintrust, Arize ou un équivalent et pointez l'exportateur vers cet outil.

Ce que TrueFoundry implémente, c'est la partie online : un juge s'exécutant comme un garde-fou sur le parcours de la requête, son verdict, sa latence et sa consommation de tokens figurant sur la même trace que la requête contrôlée.

Chaque juge ci-dessous est un microservice que vous déployez, appelé par le gateway comme un rail via le contrat de garde-fou personnalisé (custom guardrail). Ce contrat contient une règle essentielle à retenir : HTTP 2xx signifie que le garde-fou s'est exécuté jusqu'au bout, et la décision de politique réside uniquement dans le corps JSON. La documentation précise qu'un blocage signalé par un HTTP 400 peut être interprété comme une erreur d'exécution et être laissé passer. Renvoyez 2xx avec verdict: false.

NVIDIA NeMo : le parcours JUDGE_MODEL

NeMo s'exécute sous la forme d'un wrapper FastAPI déployé sur TrueFoundry — aucun appel SDK NeMo natif depuis le gateway, aucune modification du SDK client dans votre application. En interne, il utilise un petit LLM juge combiné à Colang, un langage spécifique au domaine, pour évaluer les prompts et les réponses via les rails self_check_input et self_check_output. La grille d'évaluation réside dans le bundle Colang, où config/prompts.yml contient des exemples few-shot qui, en v1, détectent les jeux de rôle de type DAN, les instructions « ignore previous instructions », l'extraction de prompt système et les tentatives de contournement de politique.

Le détail technique important d'un point de vue opérationnel : le LLM juge passe par le même AI Gateway TrueFoundry. Le fichier .env du wrapper contient TFY_BASE_URL, TFY_API_KEY et JUDGE_MODEL — l'exemple de la documentation étant openai-main/gpt-4o-mini. Comme l'inférence du juge constitue du trafic gateway, ses tokens, son coût et sa latence apparaissent dans les mêmes tableaux de bord que tout le reste, vous permettant de visualiser précisément ce que coûtent les garde-fous. Changer de juge se fait en une seule ligne : modifiez JUDGE_MODEL (la documentation montre openai-main/gpt-4o) et redéployez.

Enregistrez deux configurations de garde-fous personnalisés (Custom Guardrail Configs), toutes deux en mode Validate — sélecteurs nemo-self-check/nemo-self-check-input et .../nemo-self-check-output — en recommandant l'option Enforce But Ignore On Error. Le contrat de verdict est très simple : HTTP 200 plus {"verdict": bool, "message": Optional[str]} ; une défaillance réelle renvoie un code 5xx.

Le gateway lance l'appel au rail d'entrée et l'appel au modèle en parallèle, afin que le juge n'augmente pas le temps d'obtention du premier token (TTFT) ; en cas de blocage, il annule l'appel au modèle en cours. Le rail de sortie s'exécute de manière séquentielle, car cela est techniquement nécessaire.

La documentation est transparente quant au coût. Parmi les limitations connues, selon leurs propres termes : chaque requête contrôlée ajoute un ou deux appels LLM, un par direction. Elle note également l'absence de garde-fous adaptés au streaming, le contrat étant mis en mémoire tampon (buffered), et précise que l'état en mémoire est géré par réplique.

Patronus : un juge géré avec une liste de critères fixes

Patronus est la solution clé en main la plus proche d'un juge dans le catalogue, et fonctionne uniquement en mode Validate — l'opération est littéralement « validate », et la documentation confirme qu'il ne peut pas effectuer de mutation.

Le type de configuration est integration/guardrail-config/patronus. Définissez target sur request ou response, puis listez les évaluateurs ; il existe six types — answer-relevance, glider, judge, pii, phi, toxicity. Le type judge correspond au LLM en tant que juge, et son champ criteria est obligatoire. Voici les quinze valeurs documentées :

La famille voisine glider en ajoute cinq : patronus:is-compliant, patronus:is-factually-consistent, patronus:is-good-summary, patronus:is-harmful-advice, patronus:is-informal-tone.

En comparant avec le tableau de décision ci-dessus, la répartition est évidente : is-json et is-csv sont des contrôles de format qu'un validateur exécute mieux et pour moins cher, tandis que no-harmful-therapeutic-guidance et is-good-summary sont des critères en langage naturel pour lesquels un juge est conçu.

Si data.results[].evaluation_result.pass est false, la requête est bloquée et un code 400 est retourné. L'exemple de réponse de la documentation montre evaluator_id: "judge-large-2024-08-08", evaluator_family: "Judge", profile_name: "patronus:prompt-injection", pass: false, score_raw: 0, evaluation_duration: "PT4.44S", usage_tokens: 687, ainsi que evaluation_metadata.highlighted_words. La page annonce des temps de réponse pouvant descendre jusqu'à 100 ms ; cet exemple de durée de 4,44 secondes rappelle que les pires temps de réponse d'un juge diffèrent fortement de sa médiane.

Guardrails AI : principalement local, juges en option

La majeure partie de Guardrails AI n'est volontairement pas un juge. Son offre v1 — DetectPII, SecretsPresent, ToxicLanguage, ProfanityFree répartis sur sept endpoints — s'exécute localement dans le pod du wrapper, sans aller-retour LLM par requête, avec une latence inférieure à 100 ms en régime permanent.

Les meillleurs évaluateurs basés sur un juge sont disponibles en option via le Hub : hub://guardrails/restricttotopic (évalué par LLM), hub://guardrails/provenance_llm — que la documentation qualifie de coûteux — et hallucination_check. Configurez-les via des variables d'environnement LITELLM_* et acheminez-les via votre gateway pour une observabilité unifiée, selon le même modèle que NeMo pour JUDGE_MODEL. Des alternatives économiques existent à leurs côtés : competitor_check est basé sur une liste d'autorisations, regex_match est, selon les termes de la documentation, très peu coûteux.

Détection des hallucinations

La page dédiée aux hallucinations de TrueFoundry répertorie quatre types — factuelle, contextuelle, logique et de source — et exactement deux méthodes d'implémentation : AWS Bedrock Guardrails, où vous activez Grounding et Relevance, définissez Guardrail Action sur Block et fixez un seuil ; ou un garde-fou personnalisé basé sur le dépôt de modèles.

La documentation indique clairement que le dépôt de modèles n'inclut pas actuellement de garde-fou contre les hallucinations prêt à l'emploi — il fournit des exemples tels que l'anonymisation PII et le filtrage NSFW. L'approche personnalisée nécessite un réel travail d'ingénierie, il ne s'agit pas d'une simple case à cocher.

Tester un rail, puis le surveiller

Le Playground exécute les quatre hooks, vous permettant de tester un prompt d'attaque sur le rail d'entrée avant d'appliquer la moindre politique.

Une fois en production, chaque évaluation de garde-fou constitue son propre span dans Monitor → Request Traces avec le temps d'exécution, le résultat, la portée, l'entrée et la sortie — enregistrés également pour les requêtes bloquées, afin qu'un appel refusé serve de preuve plutôt que d'être une zone d'ombre.

De manière agrégée, la vue garde-fou du Metrics Dashboard répartit les requêtes par seconde entre allowed, blocked, mutated et audit_mode_blocked, avec des taux de blocage et de mutation par garde-fou et la latence du garde-fou aux centiles P50, P75, P90 et P99. Ce dernier graphique permet d'identifier un juge dont les délais extrêmes dégradent la latence globale.

Boucler la boucle avec le feedback humain

Le verdict d'un juge est une estimation de la qualité, et la seule façon de la valider est de la comparer à un verdict humain sur la même requête. Chaque réponse d'AI Gateway contient un en-tête x-tfy-feedback-target-id. Envoyez une requête POST à https://{control_plane_url}/api/svc/v1/gateway-feedback avec {"target": {"feedbackTargetId": "<base64>"}, "rating": 4, "comment": "...", "metadata": {...}} — la note allant de 1 (la plus basse) à 5 (la plus haute) — et vous recevrez en retour {"data": {"id": "..."}}. Les corrections s'effectuent via PUT .../gateway-feedback/{feedback_id}, et les suppressions via DELETE. Les feedbacks apparaissent à côté du span, et la liste complète est accessible dans Raw Data sous tfyGatewayFeedbacks.

Une limitation : l'ID cible concerne uniquement le span racine (root span). Le feedback s'applique à la requête globale, pas à une sous-étape.

Exemple concret : filtrer un assistant de support clinique

Un assistant interne répond aux questions des coordinateurs de soins. L'équipe de conformité exige deux choses : aucun conseil thérapeutique dangereux et un ton adapté au domaine clinique. Aucun de ces critères ne pouvant s'exprimer par une regex, nous sommes dans le périmètre d'application d'un juge.

1. Sélectionnez la grille la plus précise. Deux critères du juge Patronus, et non dix — patronus:no-harmful-therapeutic-guidance et patronus:clinically-inappropriate-tone, avec target: response. Le reste de la liste de conformité est délégué à des détecteurs plus économiques.

2. Commencez en mode Audit. Une règle de politique sous AI Gateway → Policies → Guardrails cible les modèles de l'assistant et l'équipe des coordinateurs de soins, avec la stratégie d'application Audit : enregistrer le verdict sans rien bloquer.

3. Analysez une semaine de traces. audit_mode_blocked vous indique combien de requêtes réelles cette règle aurait bloquées ; evaluation_metadata.highlighted_words vous en explique la raison. Fréquemment, le critère de ton se déclenche sur de bonnes réponses qui se trouvent simplement être très concises.

4. Comparez aux évaluations humaines. Le système d'évaluation de l'assistant est relié à l'API de feedback via x-tfy-feedback-target-id. Si les requêtes signalées correspondent à celles que les humains ont notées 1 ou 2, le juge apporte une vraie valeur. Sinon, ajustez la grille d'évaluation, pas le seuil.

5. Passez en production, puis surveillez les coûts. Optez pour Enforce But Ignore On Error afin qu'une panne de Patronus bascule en mode non protégé plutôt qu'en une panne de votre propre service. Patronus indique les usage_tokens par évaluation et l'inférence du juge passe par le gateway, rendant le coût de l'évaluation clairement visible — cette donnée vous aidant à définir votre taux d'échantillonnage.

Prêt à placer un juge en amont de votre trafic ?

Enregistrez un garde-fou personnalisé, lancez-le en mode audit et analysez les verdicts.

Essai gratuit

Pièges importants à connaître

Les garde-fous de sortie sont ignorés sur les réponses en streaming. Lorsque "stream": true est activé, les rails de sortie ne s'exécutent pas ; les rails d'entrée s'exécutent toujours. Si votre produit utilise le streaming, votre juge protège le prompt et rien d'autre.

Les prompts système ne sont jamais transmis aux garde-fous. Le gateway les retire avant d’envoyer le contenu à n’importe quel garde-fou, CrowdStrike AIDR étant la seule exception documentée en lecture seule. Un juge ne peut pas vérifier si vos instructions système ont été suivies.

La validation de sortie engendre malgré tout le coût de l'appel au modèle. Si un rail d'entrée échoue en cours d'exécution, le gateway peut annuler la requête. Un rail de sortie s'exécute après la génération de la réponse, et la documentation rappelle que les coûts du modèle sont déjà engagés à ce stade.

Lectures complémentaires

• Évaluation LLM online au niveau du Gateway
• Explication des garde-fous de l'AI Gateway — hooks, modes, application
• NVIDIA NeMo Guardrails sur l'AI Gateway
• Intégration de Patronus avec TrueFoundry
• Benchmark des fournisseurs de garde-fous LLM — latence et précision

Conclusion

Le LLM en tant que juge est une excellente technique lorsqu'elle est utilisée à bon escient. C'est le seul moyen d'évaluer du texte subjectif à grande échelle, mais il présente des biais en faveur des réponses longues, des productions de sa propre famille de modèles et du premier candidat présenté. Une équipe qui n'intègre que la première partie de cette réalité risque de déployer un garde-fou qui bloquera silencieusement ses propres utilisateurs.

La distinction essentielle pour maîtriser cette approche est celle présentée au début de cet article. La notation offline est un sujet de jeu de données qui relève d'une plateforme d'évaluation, TrueFoundry y exportant les traces via OTEL. Le filtrage online concerne le parcours de la requête : un critère précis, un petit juge versionné d'une famille différente, un démarrage en mode audit, la priorité à la précision sur le rappel, et une visibilité claire sur les coûts.

Écrivez la règle sous forme de code lorsque c'est possible. Quand elle ne peut être rédigée que sous forme de phrase, utilisez un juge — et évaluez-le avec la même rigueur que n'importe quel modèle de production.

Placez un juge en amont de votre trafic sur TrueFoundry

Démarrage gratuit