LLM Évaluation: Chaque décision est dirigée vers les bonnes preuves

L'évaluation LLM est la pratique consistant à vérifier si un système alimenté par un modèle répond à un critère défini sur une cible définie. L'avantage est simple: nommer d'abord la décision, puis recueillir les preuves les plus étroites pouvant la soutenir. Un ensemble de données sélectionné peut appuyer une affirmation de qualité préalable à la publication. Une comparaison de base peut appuyer une décision de régression. Les essais de production échantillonnés peuvent révéler une dérive de qualité en direct. Aucune de ces preuves ne prouve par elle même qu'un agent était accessible, qu'il complétait un effet d'outil ou qu'il livrait l'artefact promis. Cette limite importe car l'évaluation passée semble plus large qu'elle ne l'est. Un score a toujours une cible, une montre et des preuves manquantes. Le traitement comme un verdict de santé universel crée un faux vert: la réponse semble bonne alors que le processus ou le résultat est cassé. Commencez par la décision, pas par la métrique. Avant de choisir une correspondance exacte, un score d'intégration, un juge LLM ou une plateforme, écrivez une phrase sous la forme suivante: À cette fois , décidez cette action de cette cible en utilisant cette preuve . Cette phrase met le travail dans une voie: Décision Cible Une horloge Les preuves minimales Clame soutenu le plus fort Un candidat est il suffisant ? Exemples sélectionnés Avant le déploiement Ensemble de données, scoreur spécifique à la tâche Le candidat remplit le critère nommé de ce ensemble de données La libération a t elle régressé ? L'indice de référence et le candidat Au moment de la libération Cours parallèles, seuil Le candidat n'a pas franchi la limite de régression nommée La qualité de vie est en baisse ? Expériences de production dans l'échantillon Pendant la circulation Probe fraîche, évaluateur de la production Cet échantillon répond ou manque au critère de vie L'agent est en bonne santé ? Temps d'exécution et travail attendu À l'heure d'exécution prévue Pouls cardiaques, horaire, réception des progrès Le temps d'exécution est atteignable et le travail utile est en mouvement Le résultat prévu s'est il produit? Destination externe Après la date limite d'effet ou de finalisation Réception de destination, somme de contrôle, test d'acceptation L'effet ou le livrable existe et passe la vérification Les deux dernières rangées ne sont pas des évaluations meilleures. Elles répondent à des questions différentes. Un évaluateur peut inspecter une réponse ou une trace; la santé opérationnelle a besoin de preuves sur le processus qui devrait être exécuté; la vérification des résultats a besoin de preuves provenant de la destination où le résultat devrait exister. L'évaluation hors ligne appuie les demandes limitées de pré édition Les lignes directrices d'évaluation d'OpenAI définit un flux de travail utile: indiquer l'objectif, collecter un ensemble de données, définir des mesures, exécuter des comparaisons et continuer à évaluer les changements du système. Il met également en garde contre les mesures génériques et l'évaluation basée sur vibe. L'implication pratique est qu'un score hors ligne a besoin d'une décision de libération qui lui est attachée. Supposons qu'un agent d'assistance doit sélectionner l'outil correct, passer l'identifiant de compte correct et retourner une réponse conforme aux politiques. Ne les réduisez pas en une moyenne. Utilisez trois contrôles: vérifications exactes ou basées sur des schémas pour l'outil et les arguments sélectionnés; une rubrique de qualité spécifique à la tâche pour la réponse; une vérification déterministique pour tout champ de sortie requis par le contrat d'application. Ensuite, comparez le candidat actuel avec la ligne de base de libération dans les mêmes cas. Un candidat qui améliore le style de réponse mais réduit l'exactitude de l'identifiant de compte n'est pas meilleur de 0.7%. Il a échangé une classe d'échec contre une autre. La porte de sortie devrait indiquer si ce commerce est autorisé. Les tests de régression constituent donc une utilisation particulière de l'évaluation hors ligne et ne sont pas synonymes de toute évaluation. Il nécessite une base stable, des cas couplés et un seuil lié à une action de libération. Enregistrez la version du jeu de données, la version du scoreur, le modèle et la configuration rapide, le nombre d'échantillons et les désaccords. Sans ce manifeste, un changement de score ne peut être attribué en toute sécurité. Le plancher raisonnable peut être petit. Cinq à dix exemples soigneusement examinés par composant critique sont plus utiles qu'un grand ensemble synthétique avec des critères d'acceptation peu clairs. Élargissez l'ensemble à partir d'incidents réels, de cas de bord et de désaccords entre les critiques. Un ensemble de données devrait devenir plus difficile parce que le système vous a appris où il échoue, pas parce qu'un tableau de bord récompense le nombre de cas. L'évaluation en ligne surveille le comportement en direct, avec des références plus faibles Le Les concepts d'évaluation de LangSmith fait une distinction de cible importante. Les évaluations hors ligne s'effectuent sur des ensembles de données et des exemples, souvent avec des résultats de référence. Les évaluations en ligne sont effectuées sur des circuits de production ou sur des fils, où une référence correcte n'est généralement pas disponible. Cela change le sens du verdict. Un évaluateur en ligne peut marquer un schéma de sécurité, une sortie malformée, une dérive de sujet, une faible satisfaction de l'utilisateur ou une trajectoire inhabituelle. Il peut également récolter des cas vivants difficiles pour l'ensemble de régression hors ligne. Il ne peut pas hériter silencieusement de la confiance d'un test de référence. Son échantillon peut être obsolète, filtré, non représentatif, ou noté par un juge qui a dérivé. Pour chaque règle en ligne, conservez: la politique d'échantillonnage et les exclusions; l'identifiant de course ou de fil, sans fuite de contenu sensible; la version et la rubrique de l'évaluateur; le temps d'observation et la vitre de fraîcheur; l'action déclenchée par une erreur; une voie d'examen humain et de détection des désaccords. Documentation du kit de développement d'agents de Google sépare l'évaluation de la trajectoire d'utilisation des outils de l'évaluation de la réponse finale. C'est utile, mais l'équivalence de trajectoire nécessite de la retenue. Deux agents valides peuvent résoudre la même tâche à travers différentes séquences d'outils. La correspondance exacte de la trajectoire est appropriée lorsque l'ordre fait partie du contrat de sécurité; autrement, vérifier les effets requis et les actions interdites plutôt que d'exiger une voie idéale. Le suivi de la production contient également des signaux de non évaluation. La latence, le taux d'erreur, l'utilisation des jetons et l'exhaustivité des traces décrivent le comportement du service. Un évaluateur de la qualité de la réponse décrit le contenu ou le comportement échantillonné. Aucun des deux n'indique que le travailleur de demain soit accessible. Gardez ces revendications séparées même si une plateforme les affiche ensemble. La limite de résultats a besoin de reçus, pas d'un autre juge. Trois cas de la fixation de l'article ont produit le même piège: un score générique LLM a passé, mais le seul verdict défendable a été UNKNOWN . 1. Le cas de santé en cours d'exécution avait un calendrier attendu et un record de progrès, mais aucun battement de cœur frais. Les anciens ouvrages ne prouvent pas la disponibilité actuelle. 2. Le cas d'effet outil avait une pièce d'identité d'exploitation stable, mais aucun reçu de la destination. Un temps d'arrêt pourrait cacher soit aucun effet, soit un effet complet. 3. Le cas de livraison finale avait une définition de test d'acceptation, mais aucune somme de vérification des artefacts. Il n'y avait rien de concret à tester. Un juge LLM ne peut pas réparer ces lacunes. Demandez à un modèle si un travailleur est probablement vivant ne crée pas un battement cardiaque. La question de savoir si un e mail a probablement été envoyé ne crée pas un reçu du fournisseur. La question de savoir si un fichier semble complet ne prouve pas que le fichier existe sur le chemin requis. Préférer des preuves déterministes près de la frontière: un rythme cardiaque frais et un enregistrement de la disponibilité attendue; un reçu d'avancement lié à une pièce d'identité non secrète pour exécution; une clé d'idempotence plus une clé de destination lue pour un effet externe; une somme de contrôle, une validation de schéma, un résultat d'essai ou une requête de destination pour un produit livré; un reçu de décision autorisé pour une action irréversible. Les preuves manquantes devraient rester manquantes. UNKNOWN est un état opérationnellement utile car il effectue des enquêtes sans inventer de succès ou d'échec. Reproduire l'audit de routage des preuves sur huit cas Le matériel inspectable utilisé pour cet article contient huit cas de décision. Chaque cas déclare la décision, les preuves disponibles, la voie attendue et le verdict attendu. La politique de base est délibérément mécanique: Le fichier couvre la qualité des candidats, la régression de la libération, la dérive de la qualité en direct, la santé en cours d'exécution, les effets externes, les résultats finaux, l'examen subjectif et l'autorité humaine. L'exécution a produit: Les huit affaires ont atteint leur piste de preuves attendue. Cinq avaient suffisamment de preuves pour justifier leur revendication limitée. Trois étaient inconnus, et tous les trois auraient semblé verts si la police avait accepté un score générique de passage. Ce n'est pas une norme universelle. Remplacez l'appareil par des décisions tirées d'un véritable flux de travail. Ajoutez les noms exacts de preuves que votre temps d'exécution et les destinations peuvent produire. Conserver le comportement de défaillance: si un signal requis est absent, retourner inconnu et répertorier les champs manquants. Ne convertissez pas l'absence en un score de zéro, car le zéro suggère que la mesure s'est produite. Choisissez le marqueur seulement après la cible des preuves Une fois que l'objectif est correct, la sélection des marqueurs devient plus facile. Utilisez le code lorsque la propriété est déterministe: forme JSON, nom de l'outil, plage d'arguments, somme de contrôle, présence de fichier, état de test ou état de destination. Utilisez un juge LLM lorsque la propriété est vraiment qualitative et que vous avez une rubrique claire, un ensemble d'étalonnage et un chemin de révision des désaccords. Les lignes directrices d'OpenAI soulignent que les modèles sont souvent plus fiables pour discriminer entre les options que pour produire des jugements sans fin, de sorte que la comparaison ou la classification par paires peut être plus forte qu'un score sans contrainte. Utilisez l'examen humain lorsque la décision implique un goût sans rubrique stable, autorité juridique ou politique, ambiguïté à fort impact, secrets ou action irréversible. Un juge peut résumer les preuves pour l'examinateur; il ne peut pas devenir la personne autorisée. Documentation d'évaluation de MLflow décrit les ensembles de données, les scores, les fonctions de prédiction, les retours humains, l'évaluation systématique et le suivi de la production comme des capacités connexes. C'est un menu de mise en œuvre utile. La règle de routage appartient toujours au propriétaire de l'application: l'outil peut calculer un score, mais seul le propriétaire peut définir quelle décision le score est autorisé à soutenir. Gardez quatre verdicts dans le dossier de la libération et des opérations. Un dossier d'évaluation compact devrait répondre indépendamment à quatre questions: Le candidat a t il répondu à ses critères de qualité hors ligne? A t il évité une régression interdite par rapport à la ligne de base? Un échantillon de production fraîche répond il à ses critères en ligne? Le travail attendu est il sain, et le résultat promis est il vérifié? Ne donnez pas une moyenne à ces réponses. Une publication peut passer une évaluation hors ligne alors que des preuves en direct ne sont pas encore disponibles. Un échantillon de production peut paraître sain alors qu'une course programmée est ratée. Une trace peut sembler complète alors que l'artefact final est absent. Préservez chaque verdict, son temps de preuve et son champ d'application. Cela produit une règle d'exploitation plus calme: évaluer le comportement du modèle et de l'application avec des ensembles de données et des échantillons; évaluer la santé de l'exécution avec des preuves de disponibilité, de calendrier, d'attente et de progrès; vérifier les résultats externes à leur destination. Ne faites que l'escalade de la voie manquante ou ratée. Sidewisp est actuellement en préversion privée. Il est conçu comme une couche de santé pour les temps d'exécution des agents existants, mais les adaptateurs de surveillance de la production et les systèmes de récupération ne sont généralement pas expédiés. Si la distinction entre une course en forme et un résultat vérifié est le problème que vous essayez de résoudre, la liste d'attente d'aperçu privé est la prochaine étape appropriée.