Datadog LLM Experiments d'observabilité: ajouter une porte de promotion

Les expériences d'observabilité de Datadog LLM peuvent vous dire qu'une architecture de demande, de modèle, de fournisseur ou d'agent de candidat a obtenu un meilleur score et a couru plus vite. C'est une preuve utile, mais ce n'est pas encore une décision de libération. Le défaut raisonnable est de comparer le candidat et la ligne de base au sein du même projet Datadog, de fixer la version du jeu de données, de maintenir les définitions de l'évaluateur stables et d'inspecter la distribution et les traces plutôt que de faire confiance à une moyenne. Puis ajoutez une petite porte de promotion en dehors de la carte de score: prouvez que chaque enregistrement requis a été exécuté, les attentes attendues sont restées attentes, les cas mutants ont produit exactement un effet, et les cas complétés ont un reçu de destination. Cet article met en œuvre cette dernière étape avec un dispositif de huit enregistrements. Le candidat déplace le taux de réussite de l'évaluateur de 75% à 100% et la durée moyenne de 980 ms à 738,75 ms . La promotion est toujours bloquée. Une restitution n'a pas de reçu de destination vérifié, et une annulation a produit deux effets. D'abord prouver que les deux expériences sont comparables Le résumé des expériences de Datadog décrit trois opérations de base: des ensembles de données de version, des expériences et des résultats de comparaison. Le documentation d'installation actuel définit une expérience comme une tâche exécutée séquentiellement sur les enregistrements d'un ensemble de données, avec des évaluateurs d'enregistrements et des évaluateurs de résumé facultatifs. Les internes de tâches peuvent utiliser les mêmes décorateurs de traçage que le code de production. Ces primitifs vous donnent un bon matériau pour une comparaison. Ils ne suppriment pas la nécessité de définir ce qui doit rester identique entre les deux courses. Avant de regarder les scores, enregistrez un manifeste sans contenu: Les hashs identifient le code de l'évaluateur; ils ne sont pas des hashs d'invitations, de sorties, de références ou de données clients. Hash la sérialisation canonique JSON de ce manifeste et joindre l'empreinte digitale aux deux enregistrements de l'expérience. L'appareil produit: Si les empreintes digitales diffèrent, cessez d'appeler le résultat une comparaison parallèle. Une version modifiée de l'ensemble de données peut ajouter des cas difficiles. Un évaluateur modifié peut déplacer le seuil. Un dossier manquant peut améliorer la moyenne en supprimant l'échec qui compte. Ces changements peuvent être légitimes, mais ils nécessitent une nouvelle ligne de base. Le parcours du produit de Datadog dit que les ensembles de données prennent en charge le contrôle de version et peuvent être fixés à des versions spécifiques. Il explique également que la surface de comparaison expose les moyennes, les distributions, la latence, le coût, le nombre de jetons, les sorties et les traces d'espace. Utilise tout ça. Le manifeste ne remplace pas les preuves de Datadog; il empêche la dérive accidentelle de comparaison avant que vous ne l'interprétiez. Exécuter une passerelle qui peut être en désaccord avec les moyennes L'artefact inspectable pour cet article est un script Python de bibliothèque standard. Il contient huit disques synthétiques sans contenu et émet JSON. Faites le avec: La règle fondamentale est délibérément petite: Cela ne demande pas à un deuxième modèle si le premier modèle a été un succès. Il vérifie les champs explicites dont vous contrôlez la signification. Les rendements de l'appareil complet: Mesure Ligne de référence Le candidat : : Enregistrements présents 8/8 8/8 Taux de réussite de l'évaluateur 75% 100% Durée moyenne 980 ms 738,75 ms Blocage des dossiers — 2 Décision de promotion — Blocage Le Guide des développeurs pour l'évaluation de Datadog prend en charge les résultats des évaluateurs typés, une évaluation optionnelle de réussite/échec, des métadonnées, des balises et des évaluateurs de résumé. Cela fait d'un évaluateur une source appropriée pour evaluatorPass . Il ne fait pas de chaque évaluateur un vérificateur de destination. Si votre évaluateur compare le texte généré avec une réponse attendue, il peut passer alors qu'un remboursement n'atteint jamais le registre. Gardez ces voies de preuve séparées: EValuateur: La sortie a t elle répondu à la règle de qualité choisie? Trace lane: Quel LLM, étapes de récupération, outil et tâche ont été exécutées, et avec quelles erreurs ou latence? L'allée de l'État: Le cas fonctionnait il, attendait il légitimement, était il complet, incertain ou avait il besoin d'une personne? EEffect lane: La mutation externe prévue s'est produite exactement une fois ? O: Le résultat promis est il maintenant présent dans la destination? Les deux premières voies sont des entrées naturelles des expériences Datadog. Les autres voies proviennent de votre contrat de tâche, de vos fixations et de vos systèmes de destination. Vous pouvez soumettre leurs résultats sous forme d'évaluations personnalisées ou de métadonnées d'expérience, mais les définir à la limite qui détient la vérité. Les deux enregistrements bloqués révèlent des échecs différents L'enregistrement issue refund a un évaluateur de passage, un état complete et un effet tenté. Son outcomeReceipt est missing . Il ne s'agit pas là d'une preuve que la restitution a échoué; c'est une preuve que l'achèvement n'a pas été vérifié. Le verdict sûr est uncertain , pas vert et pas une nouvelle tentative automatique. Le dossier cancel subscription dispose d'un évaluateur de passage et d'un reçu de destination vérifié, mais effectCount est composé de deux. Un état final réussi n'élimine pas l'effet dupliqué. Le candidat est bloqué parce que le changement a affaibli la sécurité même en améliorant le score global. L'enregistrement approval required démontre la limite opposée. Son état attendu est waiting , et le candidat fournit un propriétaire, une date limite et un jeton de relèvement. Ça passe. Une pause avec une dépendance connue n'est pas un stand, donc une passerelle qui exige que chaque rangée se termine par complete punirait le comportement correct. Ces cas sont délibérément inconvenients. Si une passerelle de promotion ne répète que le score de l'évaluateur, elle ne peut pas modifier la décision de libération. Une porte utile doit être capable de dire: la comparaison est invalide en raison d'une modification de la couverture des dossiers; le candidat est meilleur quant à la qualité mais dangereux quant aux effets; le candidat est plus rapide mais a laissé un résultat inconnu; l'attente est valable et ne doit pas être considérée comme un échec; les preuves sont en conflit, donc une personne doit décider. Attachez la porte à une vraie expérience Datadog Le guide d'installation actuel de Datadog nécessite ddtrace =4.3.0 pour le parcours d'expériences Python documenté et nécessite à la fois une clé API et une clé application. Gardez ces secrets dans les variables environnementales; ne les mettez pas dans un manifeste, une rangée d'ensemble de données, un artefact d'article ou un attribut trace. Pour un flux de travail d'expérience existant, ajoutez la passerelle en cinq étapes délimitées. 1. Enregistrez le projet Datadog, l'identité et la version du jeu de données, les identifiants des enregistrements commandés, les hashes de code d'évaluation, la révision des tâches, la configuration des candidats et l'état attendu pour chaque enregistrement. Conserver uniquement des identifiants opaques ou des hashes lorsque le contenu est sensible. 2. Réconcilier la couverture avant de calculer un taux. Comparer les identifiants de dossiers attendus avec les dossiers d'expériences observés. Les identifiants manquants, dupliqués ou inattendus ne sont pas comparables. Ne réduisez pas silencieusement le dénominateur aux rangées qui sont revenues. 3. Émettez des champs déterministes à la limite de la tâche. Pour une tâche à lecture seule, la réception peut être une réponse de schéma valide liée à la révision de source attendue. Pour une tâche mutante, utilisez une clé d'idempotence, une identité d'effet et une recherche côté destination. Comptez les effets commis, pas les tentatives de réessayer. 4. Préserver les états non terminaux. Une affaire d'attente a besoin d'une raison, du propriétaire, de la date limite et d'une identité de reprise. Un cas de références peut se terminer correctement par needs human . Ne fabriquez pas une réponse pour faciliter un score hors ligne. 5. Promouvoir uniquement en conjonction. Le candidat peut être promu lorsque le manifeste correspond, la couverture est complète, les évaluateurs requis passent, les budgets opérationnels sont maintenus, chaque État correspond à son contrat, chaque résultat accompli est vérifié, et chaque cas mutant a exactement un effet prévu. Une moyenne pondérée n'est pas un substitut car un score élevé peut compenser mathématiquement un seul effet catastrophique. Une politique pratique est la suivante: Ajustez les seuils pour les mesures de qualité, de latence et de coût des conseils. Gardez les reçus manquants, les effets dupliqués, l'exposition secrète et les comparaisons invalides comme des échecs difficiles à moins que votre domaine ne fournisse une règle explicite plus sûre. Sachez ce que cette vérification ne prouve pas L'appareil prouve ses propres huit cas et la mise en œuvre de la règle. Il ne prouve pas que votre ensemble de données représente le trafic de production, que les sorties attendues sont correctes, que les hashes de l'évaluateur correspondent au code examiné ou que les reçus de destination ne peuvent pas être falsifiés. Il ne mesure pas non plus la qualité des produits de Datadog ni ne compare les modèles. Ces questions nécessitent l'examen des ensembles de données, le contrôle des sources, les contrôles d'accès, le prélèvement d'échantillons de production et la réconciliation avec la destination réelle. Les expériences Datadog restent l'endroit où étudier les essais, les distributions, les traces et les résultats des évaluateurs. La porte de promotion ajoute une décision opérationnelle plus étroite: est ce que cette comparaison spécifique est suffisamment complète et sûre pour autoriser le changement? L'orientation du produit de Sidewisp consiste à faciliter l'interprétation des preuves, de l'incertitude et de la vérification en matière de santé des agents dans les délais de fonctionnement existants. Il ne remplace pas Datadog, votre temps d'exécution ou votre processus de libération. Sidewisp est actuellement en préversion privée. Le site public et la démonstration interactive sont en direct; la collecte des agents de production et de la santé et l'intégration de Datadog ne sont généralement pas expédiées.