MLflow LLM Évaluation: ajouter une passerelle de sortie en temps d'exécution pour la santé

L'évaluation MLflow LLM peut vous indiquer si les résultats d'une demande répondent aux critères que vous avez choisis. Il ne peut, par lui même, prouver que l'agent était accessible, a commencé à temps, a complété un effet secondaire externe ou a laissé le produit promis à sa destination. Le défaut pratique est de conserver le résultat de l'évaluation du débit ML et le verdict sur la santé en cours d'exécution comme deux couches de preuve, puis d'exiger les deux avant la libération. J'ai testé cette limite avec MLflow 3.14.0. Un marqueur basé sur le code a donné à trois agents un exact deliverable/mean parfait de 1.0 . Une règle de santé distincte de quatre reçus ne permettait qu'une seule de ces courses de passer. La différence n'était pas un défaut dans MLflow. Il s'agissait d'un désaccord entre la question posée par le marqueur et la décision opérationnelle plus large. Reproduire le parcours d'évaluation documenté de la délivrance ML Guide d'évaluation actuel de MLflow définit une évaluation à partir de trois composantes: un ensemble de données, un ou plusieurs scoreurs et une fonction de prédiction facultative. L'ensemble de données fournit des entrées et des attentes. Une fonction de prédiction génère des sorties lorsqu'elles ne sont pas déjà présentes. Les marqueurs transforment les preuves disponibles en rétroaction ou en métriques. Cette division est utile car elle rend explicite la question d'évaluation. Si la question est Est ce que cette sortie équivaut au nom de livraison attendu?, un marqueur déterministe basé sur le code est plus approprié qu'un juge LLM. MLflows documentation personnalisée du scoreur permet aux marqueurs de lire inputs , outputs , expectations , ou une trace complète, et de retourner un résultat primitif ou plus riche Feedback . L'expérience a utilisé une liste en ligne, des sorties pré générées, et ce scoreur: MLflow a enregistré exact deliverable/mean = 1.0 . C'est le bon résultat pour les preuves définies: chaque chaîne de sortie correspondait à ses attentes. Le résultat est reproductible, bon marché et facile à expliquer. Il est aussi plus étroit que Les trois courses d'agents sont saines. MLflows documentation des ensembles de données d'évaluation décrit les ensembles de données comme des exemples sélectionnés pour la prévention de la régression, la comparaison des versions et les tests de qualité ciblés. C'est le bon modèle mental. Un ensemble de données est une suite de tests pour les revendications codées dans ses exemples et ses scores; il ne s'agit pas automatiquement d'un recensement de chaque défaillance de production qui compte. Mettre les reçus opérationnels à côté du résultat de l'évaluation Le même appareil attachait un petit reçu d'exécution à chaque tâche. Il a enregistré quatre faits que le scoreur de sortie exacte n'a pas vérifiés: heartbeatFresh : le temps de fonctionnement est récemment atteignable; scheduleOnTime : la course attendue a débuté dans la période autorisée; effectVerified : la destination externe confirme l'effet secondaire prévu; deliverableVerified : l'artefact promis existe et passe la vérification de destination. La comparaison qui en résulte est la suivante: tâche Délivrable exactement Les preuves de l'exécution Décision de libération run 101 passe les quatre reçus présents libération run 102 passe rythme cardiaque stérile; effet et livrabilité non vérifiés bloc comme inaccessible run 103 passe l'horaire a raté sa fenêtre autorisée bloc aussi tard Les trois rangées d'évaluation sont passées. Une seule course était libérable. Une chaîne correcte peut survivre dans une réponse caché après la disparition d'un travailleur. Une charge utile correcte peut arriver après la date limite de l'activité. Un appel à l'outil peut renvoyer une confirmation plausible pendant que la destination reste inchangée. Aucun de ces cas n'invalide le scoreur de sortie; ils démontrent pourquoi la décision de libération a besoin de preuves supplémentaires. Gardez les couches reliées par un task id ou un run id stable, mais ne les faites pas tomber en un seul score vague. Un disque compact peut ressembler à ceci: Le lien est important. Sans elle, une équipe peut comparer un reçu de santé actuel à une évaluation d'une autre version, d'un environnement ou d'une nouvelle tentative. Incluez la version de l'application, la version de l'ensemble de données, la version du scoreur, l'environnement et le temps d'observation lorsque ces dimensions peuvent modifier le verdict. MLflow peut conserver les données d'évaluation et de traçabilité; le temps d'exécution ou la destination doit toujours fournir des faits qu'il seul peut connaître. Traiter les preuves manquantes comme unknown , et non comme pass . Un rythme cardiaque manquant peut signifier une défaillance du collecteur plutôt qu'une défaillance de l'agent. Un reçu de destination manquant peut signifier que l'écriture a échoué, que le vérificateur a échoué ou que l'intégration ne peut pas exposer le fait. Ces États demandent une enquête; ils ne justifient pas une libération verte. Utilisez une décision à deux portes au lieu d'un score mixte Une règle pratique est délibérément ennuyeuse: Chaque clause doit conserver sa propre preuve, sa fraîcheur et sa raison d'échec. Cela donne à un opérateur une action suivante limitée: Un échec d'évaluation renvoie au prompt, au modèle, à la politique des outils, au jeu de données ou au scorer. Un rythme cardiaque dépassé mène au diagnostic d'exécution ou de collecteur. Un itinéraire manqué de l'horaire pour le planificateur, la file d'attente ou la limite de capacité. Un effet non vérifié bloque les retentissements jusqu'à ce que la destination externe soit reconciliée. Une ligne de livraison manquante vers le producteur ou le vérificateur de destination. Cette séparation empêche également un juge LLM de devenir une autorité qu'il n'était pas prévu d'être. Les juges sont utiles lorsque la justesse ou la qualité nécessitent une évaluation sémantique. MLflow prend explicitement en charge les scorers intégrés, basés sur des lignes directrices, personnalisés et basés sur des codes. Utilisez ces outils pour répondre à leurs critères. Préférer des vérifications déterministiques de destination pour l'existence de fichiers, l'état de la base de données, les ressources API, les résultats des tests ou les reçus signés. Ne lisez pas l'expérience car MLflow manque de surveillance de la production. Évaluation, traces, surveillance, ensembles de données, commentaires et plusieurs types de scoreurs. La conclusion plus étroite est falsifiable: l'évaluation exacte effectuée ici n'a pas établi quatre faits opérationnels parce que ses données et son scoreur ne les ont pas testés. Vous pouvez ajouter des scores axés sur la santé lorsque les données probantes pertinentes sont présentes, ou conserver le classement de la santé à côté de MLflow lorsque les données probantes se trouvent dans les systèmes externe et en temps d'exécution. L'appareil est intentionnellement petit. Il ne compare pas les juges LLM, ne teste pas le débit MLflow à l'échelle, ne compare pas les fournisseurs ni ne mesure la couverture de la surveillance. Sa valeur est l'incohérence contrôlée: trois passes d'évaluation identiques, trois états opérationnels différents et une règle inspectable qui explique la décision de libération. Pour les équipes opérant avec des agents, cette limite est utile: évaluer la qualité de la sortie avec le scoreur approprié le plus fort, vérifier les faits opérationnels à leur source et joindre les preuves avant de déclarer le succès. Sidewisp est actuellement en préversion privée. Son rôle prévu est une couche de santé parallèlement aux temps d'exécution existants, et non un remplacement de MLflow ou une affirmation automatique selon laquelle une évaluation réussie signifie un agent sain. L'expérience publique actuelle consiste en un site d'accès anticipé et une démonstration de produits; les adaptateurs de surveillance de la production ne sont généralement pas expédiés.