Observabilité Opik LLM : scores de fil d'audit avant le vert

Opik peut vous en dire beaucoup sur un agent multi tours, mais une trace visible ou un score de conversation élevé ne constitue pas encore un verdict de santé. La valeur par défaut raisonnable consiste à utiliser Opik pour les preuves de trace et d'évaluation, puis à exiger quatre faits supplémentaires avant d'afficher le vert : les tours prévus ont atterri sous une seule identité de thread, le thread était éligible pour l'évaluation, le score a été produit après la dernière activité et le résultat demandé existe à sa destination. Cette distinction est particulièrement importante lorsqu’une partition manque ou semble rassurante. « Aucun score » peut signifier que la conversation est toujours active, que la règle d'échantillonnage l'a exclue, que la notation est en attente ou que la notation est bloquée. Une partition de 0.94 peut appartenir à la version précédente d'un fil de discussion. Même un nouveau 0.94 peut coexister avec un fichier manquant, un message non envoyé ou une mise à jour ayant échoué. Ce guide crée un reçu sans contenu et rejoue dix cas contre celui ci. Il a été vérifié par rapport à Opik 2.2.12 lors de la validation du référentiel c54a6a9 le 29 juillet 2026. Il ne nécessite aucune invite, réponse, identifiant ou identifiant client. Prouvez le fil avant de juger le score Opik regroupe les traces associées avec un thread id défini par l'utilisateur. C'est documentation de conversation épinglée dit que l'identifiant doit être unique au sein d'un projet. Cela donne aux opérateurs une limite importante : une conversation ne concerne pas "les lignes qui semblent liées" dans le tableau de bord. Avant de lire le résultat d'un évaluateur au niveau du thread, enregistrez : l'espace de travail et le projet censés recevoir les traces ; un hachage opaque ou une représentation non sensible de l'ID de thread attendu ; les identifiants de thread distincts observés pour les tours prévus ; la dernière heure d'activité de trace ; le temps de collecte ou de requête utilisé pour établir la visibilité. Un identifiant observé correspondant à l’identifiant attendu passe le portail d’identité. Zero ID est un problème de télémétrie. Deux identifiants pour une conversation prévue constituent une fragmentation, même si les deux fragments ont des étendues individuellement valides. La réutilisation du même identifiant convivial dans un projet différent constitue également une portée de preuve différente. Ne commencez pas par blâmer l’évaluateur lorsqu’une trace est absente. Opik guide de configuration épinglé du SDK le regroupement de documents dans les contrôles TypeScript SDK et explicites client.flush() et flushAll() . Un vidage terminé est une preuve de livraison utile, mais il ne prouve toujours pas que le collecteur a accepté le lot ou que la requête lit le projet prévu. Confirmez la visibilité après la limite affleurante. Cet ordre évite une erreur de diagnostic courante : Considérez le temps de recharge et l'échantillonnage comme une éligibilité et non comme un échec. L’évaluation en ligne au niveau du thread est intentionnellement asynchrone. Opik documente un temps de recharge par défaut de 15 minutes après la dernière activité avant qu'un thread ne soit évalué. La valeur peut être modifiée dans les paramètres de l'espace de travail ou via le paramètre d'environnement auto hébergé documenté. Le même documentation épinglée explique que le retard est destiné à permettre à la conversation complète de se régler. Par conséquent, now last activity at < configured cooldown est actif et non en retard. L'agent peut être en train de travailler, en attente du tour d'un utilisateur légitime ou simplement à l'intérieur de la fenêtre d'observation. La recherche de personnes à la cinquième minute alors que la politique enregistrée est de 15 minutes crée un incident. L'échantillonnage crée un deuxième chemin de non échec. Une règle en ligne Opik possède un taux d'échantillonnage explicite ainsi que son modèle, son invite, son mappage de variables et sa définition de score. Si un reçu indique qu'un fil de discussion n'a pas été sélectionné, l'état correct est coverage excluded . Ce n'est pas scoring overdue . Pour les threads sélectionnés, ajoutez une période de grâce de notation distincte après le temps de recharge. Cette période de grâce constitue votre SLO d'exploitation et non une garantie Opik : Entre ces moments là, gardez le verdict scoring pending . Après overdue at , inspectez les journaux de règles, les informations d'identification de l'évaluateur, la disponibilité du modèle, les limites de débit et l'état de la file d'attente. Cela crée une limite d'alerte claire sans confondre une activité légitime avec un évaluateur défaillant. Le reçu doit préserver la politique qui a donné lieu à la décision. Stockez le temps de recharge réellement configuré, la version de la règle, la décision d'échantillonnage, le nom de l'évaluateur et le délai de grâce avec la classification. Si le temps de recharge passe de 15 à 30 minutes, les événements historiques devraient rester explicables plutôt que d'acquérir silencieusement une nouvelle signification. Une partition visible peut toujours être obsolète Une nouvelle activité modifie la version des preuves. Opik documentation du fil de conversation indique que l'ajout d'une trace préserve les scores de feedback existants, redémarre le temps de recharge et réexécute l'évaluation en ligne après le nouveau temps de recharge. La préservation est utile pour la continuité, mais elle crée un risque temporaire de péremption. Utilisez cette règle : Si le score visible est antérieur au tour le plus récent, classez le comme score stale quelle que soit sa valeur. Attendez la réexécution ou évaluez explicitement la dernière révision du thread. Ne faites pas la moyenne de l'ancien score en vert et ne l'effacez pas ; conservez le comme preuve d’un état de thread antérieur. La fraîcheur est nécessaire mais pas suffisante. Le Opik stocke les résultats des évaluations en ligne sous forme de scores de feedback, et ses règles de fil de discussion peuvent juger une conversation entière. Le documentation des règles épinglées décrit également la cohérence des conversations, la frustration des utilisateurs et les métriques personnalisées, y compris l'accès au chemin d'exécution lorsque le modèle sélectionné prend en charge l'appel d'outils. Ce sont des résultats d’évaluation. Ils répondent à la question codée dans la métrique. Ils ne prouvent pas automatiquement l’existence d’un effet secondaire externe ou d’un livrable. Supposons qu’un agent de support reçoive un score de pertinence et de cohérence élevé après avoir déclaré avoir mis à jour un ticket. Les preuves du fil de discussion peuvent soutenir que « la conversation était cohérente » et peut être que « l'appel d'outil attendu est apparu ». Seul le système de tickets peut prouver que le ticket prévu contient désormais le changement limité prévu. La porte finale doit interroger cette destination à l'aide d'une clé de corrélation non sensible et comparer le résultat avec une règle d'acceptation déterministe. Cela donne lieu à trois décisions distinctes : score frais inférieur au seuil : quality alert ; nouveau score acceptable sans reçu de destination : outcome unverified ; un nouveau score acceptable plus un reçu de destination correspondant : verified . La commande est délibérée. Un reçu de destination ne rend pas une mauvaise conversation saine, et un bon score de conversation ne crée pas le résultat de destination. Revivez l’audit des dix États Le luminaire opik thread score audit.mjs qui l'accompagne ne contient aucun contenu de conversation. Chaque cas fournit uniquement la visibilité, l'identité attendue et observée, la dernière activité, la sélection d'échantillonnage, le score et le temps de score, ainsi qu'un reçu de destination booléen. L'exemple de stratégie utilise le temps de recharge par défaut documenté de 900 secondes, une grâce de notation de 300 secondes choisie localement et un seuil de démonstration de 0.7 . La priorité de l’État est la plus simple à appliquer en tant que liste de décisions sécurisée pour les appareils mobiles : 1. telemetry missing : la trace prévue n'est pas visible. Vérifiez la fraîcheur du vidage, du collecteur, du projet et de la requête. 2. thread fragmented : les identifiants observés ne correspondent pas à un identifiant attendu. Réparer la propagation avant de juger. 3. active : la dernière activité est en cours de recharge. Laissez le tranquille. 4. coverage excluded : le thread éligible n’a pas été échantillonné. Couverture record ; ne pagez pas. 5. scoring pending : le fil de discussion sélectionné est éligible mais en grâce. Conservez l'inconnu et attendez. 6. scoring overdue : le fil sélectionné est au delà de la grâce sans score. Inspectez le chemin de l’évaluateur. 7. score stale : le temps de score est antérieur à la dernière activité. Évaluez la dernière révision. 8. quality alert : un nouveau score est inférieur au seuil choisi. Examinez les preuves avec une autorité limitée. 9. outcome unverified : le score est frais et acceptable, mais il n'y a pas de reçu de destination. Vérifiez le résultat réel. 10. verified : l’identité, le timing, le score et le résultat sont tous réussis. Conservez les reçus. Exécutez l'artefact depuis son répertoire : La relecture corrigée renvoie dix états attendus différents et quitte une valeur différente de zéro si un cas change de manière inattendue. Deux cas méritent d’être comparés : Le premier a un score de 0.94 , mais le score est antérieur à la dernière trace. Le second a un nouveau 0.91 , mais aucun reçu de destination. Seul le troisième a un thread stable, une évaluation en cours terminée, un score acceptable et une sortie vérifiée. Adaptez le luminaire en remplaçant les reçus synthétiques par une exportation au contenu minimisé depuis votre environnement. Hachez les identifiants si l’égalité est tout ce dont vous avez besoin. Gardez le texte des invites, les réponses, les charges utiles des outils, les secrets et les chemins locaux absolus hors du flux de santé. Définissez le seuil de grâce et de qualité de notation à partir des données de latence et d'étalonnage de votre propre évaluateur ; aucune des deux valeurs n’est fournie comme valeur par défaut universelle du Opik. Utilisez une règle de fonctionnement calme Pour l’observabilité Opik LLM, la règle pratique est : N'interprétez pas un score de thread tant que les traces prévues ne forment pas un thread actuel et que la stratégie de notation n'indique pas que ce thread était éligible. N'effacez pas l'exécution tant que le score n'est pas plus récent que la dernière activité et que le résultat demandé n'a pas été vérifié de manière indépendante. Cette règle préserve l'attente légitime, rend l'échantillonnage visible et empêche à la fois les alarmes de score manquant et les états verts de score obsolète. Il maintient également la frontière honnête : Opik fournit des preuves de trace et d'évaluation précieuses ; votre destination fournit le reçu de résultat. L'audit a des limites. Il ne teste pas l'étalonnage de l'évaluateur, la qualité des invites, l'exactitude sémantique, l'exhaustivité du fournisseur ou la disponibilité d'un déploiement Opik en direct. Une machine à états sans contenu ne peut pas décider si 0.7 est le bon seuil pour votre tâche. Calibrez les juges par rapport aux étiquettes déterministes et humaines, enregistrez l’incertitude et conservez un processus de révision humaine pour les décisions conséquentes. Sidewisp est actuellement en préversion privée. Sa couche d'intégrité prévue est destinée à regrouper les preuves, la fraîcheur, les états d'attente et les résultats vérifiés dans une seule vue opérateur, mais cet article n'implique pas qu'un adaptateur Opik ou un moteur de surveillance de la production soit livré aujourd'hui. Sources primaires Documentation sur la conversation Opik et l'identité du thread, épinglée au commit révisé Règles d'évaluation en ligne Opik, épinglées au commit révisé Configuration Opik SDK et contrôles de vidage, épinglés au commit révisé