Helicone LLM Observabilité: prouver que chaque modèle de route est couvert

Voir les demandes dans l'hélicone répond à une question importante: Certain trafic est observable . Il ne répond pas si chaque route d'appel modèle est représentée, si une tentative de fournisseur a été enregistrée deux fois ou si l'agent a produit son résultat promis. La solution pratique est de définir le dénominateur en dehors du tableau de bord. Gardez un petit tracé pour chaque chemin de production qui peut appeler un modèle. Pour chaque tentative de fournisseur réel, attendez vous à une observation exacte de l'hélicone par la méthode de proxy ou d'asynchronisation déclarée. Ensuite, classez l'état de travail et vérifiez séparément la destination. Cet ordre compte. Un tableau de bord peut être correct à l'intérieur pendant qu'une chute d'urgence le contourne. Il peut également surcomter lorsque le même appel passe par le proxy et un enveloppe asynchrone. Aucun des deux n'est un verdict de santé. Commencez par les routes qui peuvent envoyer du travail Helicone documente deux formes d'intégration avec un véritable compromis architectural. Son Comparaison proxy contre async dit que le proxy est le gardien de la porte de la demande: l'application modifie son URL de base, Helicone renvoie l'appel, et des fonctionnalités de passerelle telles que le caching, les retries et la limitation des taux peuvent être exécutées sur ce chemin. L'enregistrement en synchronisation reste hors du chemin critique, donc un problème d'hélicone ou de réseau d'enregistrement n'a pas besoin d'interrompre l'application, mais il ne fournit pas le même ensemble de fonctionnalités de passerelle. C'est un choix au niveau du parcours, pas un compte unique. Un service d'agent typique peut contenir tous les éléments suivants: Route Exemple d'appelant Mode d'observation prévu Motifs opérationnels chat primary API interactive porte d'entrée politique de routage et de réessayer en direct sur le chemin de la demande batch summarizer travailleur d'arrière plan synchronisation l'exploitation forestière ne doit pas prolonger le parcours critique du lot emergency fallback client de fournisseur direct porte d'entrée une chute n'est utile que si elle reste visible nightly evaluator travail Python programmé synchronisation le trafic d'évaluation doit être séparé du travail des utilisateurs La ligne dangereuse n'est pas forcément celle avec des erreurs. Il s'agit de la route qui existe en code ou en configuration mais n'a pas de contrat d'observation déclaré. Créer un enregistrement minimum de confidentialité par fournisseur: work id identifie l'unité de travail acceptée. provider attempt id identifie un vrai appel, y compris une nouvelle tentative. route indique quel chemin d'application l'a produit. Aucun de ces champs n'a besoin d'un prompt, d'une réponse, d'une clé API, d'une adresse e mail ou d'un chemin d'accueil absolu. Helicone expose les identifiants de requête, de propriété personnalisée, d'utilisateur et de session dans son répertoire d'en tête. Utilisez les métadonnées de corrélation minimales que votre demande peut valider. Ne mettez pas de secrets ou de contenu utilisateur arbitraire dans une propriété personnalisée simplement parce que le champ accepte une chaîne. Les séances résolvent un problème différent. Les groupes Documentation des séances d'Helicone ont enregistré les appels LLM, les requêtes vectorielles, les appels aux outils et d'autres demandes avec des identifiants et des chemins fournis par l'application. Cela aide à reconstruire un flux, mais il ne peut pas détecter un appel fournisseur qui n'a jamais atteint un chemin de logging. La même documentation prévient que la réutilisation d'un identifiant de session mélange des travaux non liés. Une séance est donc un contexte utile et non le dénominateur de couverture. Réconcilier les tentatives des fournisseurs avant de lire les totaux La règle d'audit est délibérément stricte: 1. Enumérez toutes les tentatives de fournisseur que l'application dit avoir eu lieu. 2. Trouvez des observations avec la même identité stable. 3. Exiger exactement une observation dans le mode déclaré de l'itinéraire. 4. Ce n'est qu'à ce moment là qu'il est possible d'interpréter l'état du travail et les preuves des résultats. L'appareil complémentaire contient huit affaires sans contenu. Faites le avec: Le résultat déterministe est: Deux cas méritent d'être examinés, car le modèle s'appelle complet et la destination existe. Dans direct provider bypass , le client d'urgence a fait tenter le fournisseur att 103 , mais l'observation de la passerelle attendue a été absente. Le verdict est BLIND ROUTE , pas sain. L'œuvre peut être bonne, mais la prétention d'observabilité ne l'est pas. Dans double instrumented attempt , att 105 apparaît une fois à travers la passerelle et une fois à travers l'instrumentation asynchrone. Le verdict est DUPLICATE OBSERVATION . La somme de ces enregistrements augmenterait les demandes, les jetons, les échantillons de latence et éventuellement les coûts. La déduplication ultérieure par timestamp est plus faible que la prévention de l'erreur de topologie parce que les appels simultanés peuvent ressembler. L'échec de l'asynchronisation est différent. L'actuel Guide de synchronisation OpenLLMetry d'Helicone montre la sélection du fournisseur lors de l'initialisation du logger et documente un contrôle qui désactive tous les logs asynchrone. Quand ce contrôle est éteint, aucune trace n'est envoyée. L'appareil renvoie donc LOGGING DISABLED avant de tenter de déduire la santé de l'agent à partir d'une requête vide. Cette priorité garde les preuves honnêtes: Un dossier manquant ne prouve pas que l'appel a échoué. Un enregistrement dupliqué ne prouve pas que l'appel a été effectué deux fois. Ce sont des résultats de couverture. Gardez cette portée plus étroite dans les alertes et les notes d'incident. Garder la couverture de l'observation séparée de l'achèvement utile Une fois que chaque fournisseur tente de cartographier exactement une observation, le tableau de bord devient digne de confiance pour les questions auxquelles il peut répondre: quel appel s'est produit, combien de temps il a fallu, quel modèle et quelle route ont été impliqués, si la demande a échoué et comment l'utilisation a changé. L'agent de santé a encore besoin de deux autres livres. Le registre de travail enregistre si la tâche acceptée fonctionne, attend, échoue ou est terminée. L'activité seule n'est pas un progrès. Un flux d'appels LLM réussis peut répéter la même action sans modifier l'artefact prévu. Le registre des résultats vérifie la destination promise. Un agent de rédaction de rapports peut exiger un fichier avec un schéma valide et un identifiant d'exécution actuel. Un agent d'assistance peut exiger une mise à jour des billets à l'API autorisée. Un assistant de déploiement peut exiger les contrôles d'engagement et de réussite attendus. Il est préférable d'effectuer une vérification déterministe de la lecture après l'écriture lorsque le résultat est inspectable. Considérez l'affaire report writer de l'appareil. Il a une observation d'asynchronisation pour une tentative de fournisseur. La demande marque l'achèvement de la tâche. La réception du rapport attendue manque. FALSE COMPLETE est le verdict utile parce qu'il identifie la limite exacte qui a échoué sans prétendre que l'appel modèle était invisible. Le cas d'approbation est intentionnellement plus calme. La route publish step dispose d'une nouvelle observation de la passerelle, mais le registre de travail nomme release manager comme propriétaire d'attente et fournit un délai. C'est WAITING , pas coincé. Page seulement si le délai expire, la propriété devient invalide, ou les preuves cessent de se rafraîchir. Cette conception à trois ledgers empêche également une surface de fournisseur de devenir un temps d'exécution forcé. L'hélicone peut rester la couche d'observation LLM sélectionnée. La demande demeure responsable de l'acceptation du travail et de la vérité sur la destination. Une couche de santé distincte peut corréler ces reçus plus tard sans devenir une passerelle de modèle obligatoire. Transformer l'audit de route en condition de libération Commencez par un canary inoffensif par route déclarée. Donnez à chaque canary un work id unique et un provider attempt id unique, n'envoyez pas de contenu sensible et écrivez son résultat à une destination jetable. Ensuite, consultez la couche d'observation après la quantité d'ingestion documentée. La condition de libération est: Ne pas être libéré en cas d'absence ou de duplication de la couverture. Ne convertissez pas silencieusement les preuves manquantes en zéro trafic. Il échoue également si un itinéraire a été supprimé du manifeste sans modification de code ou de configuration correspondant; autrement, la suppression du dénominateur peut rendre l'audit vert. Exécuter la même réconciliation en continu avec une fenêtre de temps plus large: l'alerte sur une route précédemment couverte qui produit des tentatives de fournisseur sans observation; enquêter sur une tentative qui apparaît à la fois en mode proxy et en mode asynchrone; maintenir la distinction entre les voies d'évaluation, de mise en scène et de production; expirent lorsque la requête d'observation ou le reçu de la demande ne sont plus frais; envoyer des attentes légitimes à leur propriétaire au lieu de les réessayer; vérifier à nouveau la destination après toute action de récupération. Il y a des limites. L'appareil local n'exerce pas un locataire Helicone en direct, des autorisations de requête, une latence d'ingestion ou une rétention. L'identification de tentative de fournisseur est une preuve de l'application et doit être générée et propagée correctement. Exactement un enregistrement de télémétrie est une cible d'audit, pas une garantie d'exécution unique. Ce sont des raisons de tester le contrat avec les canaries, pas des raisons de faire confiance à un graphique non vide. L'hélicone peut fournir de nombreuses preuves sur les demandes de modèle. Le manifeste de route démontre si cette preuve couvre la topologie de l'application. Les livres de travail et de résultats décident si l'agent a réalisé quelque chose d'utile. Sidewisp est actuellement en préversion privée. Son territoire prévu est la santé des agents sur les délais d'exécution existants, avec des preuves, de l'incertitude, des limites d'approbation et la vérification des résultats. Les adaptateurs de surveillance de la production et la récupération automatisée ne sont pas actuellement expédiés; la liste d'attente d'aperçu privé est destinée aux équipes qui souhaitent aider à façonner ces contrôles.