Jeff Champagne, Field CTO chez Cribl – Série d’entretiens

Jeff Champagne, Field CTO chez Cribl, apporte une expérience approfondie dans les domaines de l’observabilité, des données d’entreprise, de la stratégie de produit et de l’architecture technique. Avant de rejoindre Cribl, il a occupé le poste de directeur de la gestion de produit chez Databricks et a passé plus de sept ans chez Splunk en tant que responsable de la gestion de produit, de l’architecture et de l’ingénierie des systèmes mondiaux. Son parcours comprend également des postes de direction en architecture de systèmes chez BNY ConvergEx, des travaux d’ingénierie senior chez Premier Technology Solutions et des postes de direction en ingénierie chez Assist-2-Sell, lui donnant une perspective large sur la façon dont les entreprises collectent, gèrent, analysent et agissent sur les données opérationnelles à grande échelle.

Cribl est une entreprise de télémétrie d’entreprise qui se concentre sur l’aide aux équipes IT, sécurité, SRE et DevOps pour collecter, traiter, acheminer, stocker et analyser les données d’observabilité et de sécurité sans être verrouillées dans un seul fournisseur. L’entreprise se positionne comme la « plateforme d’intelligence artificielle pour la télémétrie », avec des produits tels que Cribl Stream pour la collecte, la réduction, l’enrichissement et l’acheminement de la télémétrie en temps réel ; Cribl Edge pour la collecte de télémétrie de point de terminaison neutre ; Cribl Search pour la recherche de données sur place ; et Cribl Lake pour le stockage. Sa mission plus large est de donner aux entreprises plus de contrôle, de flexibilité et d’efficacité à mesure que les volumes de télémétrie augmentent et que les opérations alimentées par l’IA nécessitent des données plus propres et plus accessibles.

Vous avez travaillé dans plusieurs entreprises, notamment Splunk, Databricks et maintenant Cribl, ce qui vous donne une vision rare sur les données d’entreprise, l’observabilité et l’infrastructure sur plusieurs cycles technologiques. De ce point de vue, qu’est-ce qui vous semble vraiment différent dans le défi d’observabilité créé par l’IA agente ?

Dans l’observabilité des applications, nous avons toujours traité des chemins d’exécution complexes et ramifiés, en traçant les requêtes à travers les microservices et en corrélant les journaux à travers les systèmes distribués. Dans les opérations de sécurité, nous avons affronté des sources de données à haute volume et disparates pour détecter les menaces à travers des systèmes qui, bien que complexes, se comportent de manière largement prévisible. L’IA agente ne réinvente aucun de ces problèmes ; elle les fait exploser simultanément.

Les agents enchaînent des décisions, invoquent des outils externes et font apparaître des sous-agents de manière dynamique de manière non prédéterminée au moment de l’écriture. Le graphique d’exécution n’est pas seulement complexe, il peut être très différent à chaque fois, et le volume de télémétrie nécessaire pour reconstruire ce qui s’est réellement passé augmente de manière exponentielle à chaque saut.. La collecte de toute la télémétrie nécessaire pour rendre les systèmes agents observables doit être à la fois facile à instrumenter et rentable à exploiter à grande échelle. Sinon, les entreprises feront le même compromis qu’elles ont toujours fait et réduiront la visibilité pour contrôler les coûts — exactement au mauvais moment pour devenir aveugle.

Lorsque les entreprises intègrent des agents autonomes dans leurs flux de travail, où se trouvent les plus grands écarts de visibilité entre ce qu’un agent d’IA est censé faire et ce qui se passe réellement à travers les systèmes sous-jacents ?

Les agents terminent des flux de travail qui semblent réussis en surface tout en faisant discrètement de mauvaises appels d’outils, en hallucinant des paramètres ou en s’écartant de l’objectif initial. Les conséquences apparaissent souvent plus tard dans un autre système.

La déconnexion commence généralement à l’interprétation : une légère ambiguïté dans l’instruction originale est résolue différemment en fonction de ce que l’agent récupère de la mémoire, des outils disponibles à ce moment ou de la façon dont une étape précédente de la chaîne a façonné son contexte. Vous devez également instrumenter les systèmes en aval sur lesquels l’agent dépend, car un agent peut effectuer un appel de base de données parfaitement formé et retourner encore une mauvaise réponse si la table sous-jacente n’a jamais été rafraîchie parce qu’un travail ETL a échoué silencieusement en amont.

L’agent a fait exactement ce qu’on lui a dit ; les données qu’il a fait confiance étaient simplement obsolètes.

Pourquoi les outils d’observabilité traditionnels sont-ils souvent insuffisants pour surveiller les systèmes d’IA agente ?

Tout d’abord, ils ont été construits autour de schémas rigides et propriétaires et de formes de données prévisibles. Les traces d’agents ne répondent pas à ces attentes — elles sont volumineuses, très variables dans leur structure et incluent des types de données tels que le texte complet de la requête, les chaînes de raisonnement du modèle et les charges utiles des appels d’outils que les outils hérités n’ont pas été conçus pour ingérer sans un travail de transformation important. Des normes ouvertes comme les conventions sémantiques GenAI d’OpenTelemetry émergent pour répondre à ce problème, mais de nombreuses plates-formes héritées n’ont pas été conçues pour en tirer parti.

Deuxièmement, l’équation d’échelle et de coût se brise rapidement. Un seul agent gérant des charges de travail de production peut générer plus de télémétrie en une heure que toute la pile d’applications produisait en un jour, et la plupart des plates-formes traditionnelles facturent en fonction du volume ingéré et stocké. Cela crée un compromis impossible — soit instrumenter tout et faire face à des coûts déraisonnables, soit réduire la visibilité dans les systèmes où vous en avez le plus besoin.

Lorsqu’un agent d’IA échoue, comment les organisations peuvent-elles déterminer si la cause profonde était le modèle, la couche de récupération, une dépendance d’API, un problème de permissions ou un problème d’infrastructure en aval ?

L’isolement de la cause profonde d’une défaillance d’agent est un processus d’élimination à travers les couches. Cela ne fonctionne que si votre télémétrie couvre toutes ces couches de manière cohérente. Les signaux de latence et d’erreur sur les étendues du modèle pointent vers le LLM lui-même. Les étendues de récupération vous indiquent si le contexte renvoyé était pertinent ou obsolète. Les étendues des appels d’outils exposent les dépendances d’API défaillantes ou les erreurs de permissions.

Comme mentionné, vous avez également besoin de télémétrie à partir des systèmes en aval sur lesquels l’agent dépend, car un agent peut faire un appel parfaitement formé et produire encore une mauvaise réponse si les données qu’il a fait confiance n’ont jamais été rafraîchies. Aucun signal unique ne raconte toute l’histoire, ce qui explique pourquoi la corrélation à travers toutes ces couches en un seul endroit sépare les équipes qui peuvent déboguer rapidement les défaillances d’agent de celles qui sont encore en train de deviner.

Quels types de données de télémétrie deviennent les plus importants lorsque les entreprises tentent de comprendre le comportement de l’agent à grande échelle ?

La base est toujours MELT — les métriques, les événements, les journaux et les traces — mais le poids se déplace considérablement lorsque vous passez aux systèmes agents. Les métriques vous indiquent que quelque chose ne va pas et les journaux vous donnent l’enregistrement brut de ce qui s’est passé, mais aucun des deux ne peut reconstruire la chaîne de raisonnement qu’un agent a suivie pour arriver à une mauvaise réponse. C’est là que les traces deviennent le signal le plus critique.

Dans un système distribué traditionnel, une trace vous montre comment une requête a traversé les services. Dans un système agente, elle vous montre comment un modèle a raisonné à travers un problème, quels outils il a appelés, quel contexte il a récupéré, où il a bifurqué et ce qu’il a décidé à chaque étape. Sans cette trace, vous regardez une sortie avec aucune façon de expliquer comment vous êtes arrivé là.

Les autres signaux MELT ne disparaissent pas ; les métriques sur l’utilisation de jetons et la latence sont importantes pour les coûts et les performances, et les journaux des systèmes en aval restent essentiels. Mais les traces sont ce qui rend le comportement de l’agent lisible à grande échelle.

De nombreuses discussions sur l’IA se concentrent encore fortement sur les hallucinations. Les entreprises sous-estiment-elles les défaillances opérationnelles telles que les récupérations incorrectes, les intégrations cassées, les pics de latence ou le manque de contexte ?

La plupart des hallucinations en production ne sont pas des défaillances du modèle ; ce sont des défaillances opérationnelles déguisées. Une récupération incorrecte renvoie un contexte obsolète ou incomplet, et le modèle remplit le vide avec quelque chose qui sonne plausible. Une intégration cassée signifie que l’agent n’a jamais obtenu les données dont il avait besoin pour raisonner correctement en premier lieu. Le manque de contexte d’un travail ETL défaillant ressemble à une hallucination mais est en réalité un problème d’infrastructure.

Lorsque les équipes ne peuvent pas voir la différence, elles font défaut à ce qu’elles peuvent contrôler, qui est généralement le modèle lui-même. Ils itèrent sur les invites de système, ajoutent des garde-fous et affinent les cadres d’évaluation, et même si ces techniques ont une valeur réelle, elles traitent un symptôme plutôt que la cause. Dans mon expérience, l’investissement à haut rendement est presque toujours la qualité des données et la fraîcheur dans la couche de récupération. Un agent bien ancré avec des données propres et à jour surpassera toujours un agent fortement conçu pour les invites de système qui travaille à partir d’un contexte obsolète ou incomplet.

À mesure que les agents deviennent plus autonomes, qu’est-ce que les équipes d’entreprise doivent journaliser, tracer ou surveiller pour maintenir la responsabilité sans s’étouffer avec du bruit ?

La base est toujours MELT, mais la responsabilité pour les systèmes agents nécessite de superposer un cadre d’évaluation sur la télémétrie traditionnelle. Les métriques, les événements et les journaux mettent en évidence les défaillances d’infrastructure et les intégrations cassées qui peuvent corrompre le comportement de l’agent avant que le modèle ne réponde ; les traces vous donnent la chaîne de raisonnement pour comprendre pourquoi il est arrivé à une réponse particulière. Mais aucun des deux ne vous indique si la réponse était réellement correcte, et c’est là que l’évaluation LLM-as-judge remplit le vide. Les mêmes capacités d’IA qui alimentent les agents peuvent être utilisées pour les évaluer, en notant les sorties pour l’exactitude, la solidité et l’achèvement de la tâche à une échelle que aucun processus d’examen humain ne peut égaler.

En préproduction, cela agit comme une porte de qualité, capturant les régressions avant qu’elles n’atteignent les utilisateurs. En production, cela devient un moniteur continu, échantillonnant le trafic en direct et signalant les réponses qui se situent en dehors des seuils acceptables. La clé pour éviter le bruit est de reconnaître que chaque flux de travail d’agent ne comporte pas le même risque, ce qui signifie passer d’une surveillance uniforme à quelque chose que l’industrie commence à appeler la gouvernance humaine dans la boucle. Vous définissez des lignes de comportement et des seuils de confiance à l’avance, laissez les agents fonctionner et réservez l’intervention humaine aux exceptions.

Quel rôle les pipelines de télémétrie peuvent-ils jouer pour aider les équipes de sécurité, SRE, données et IA à travailler à partir d’une vue partagée du comportement de l’agent ?

Les équipes de sécurité, les SRE, les ingénieurs de données et les équipes d’IA regardent différents morceaux du même problème à travers différents outils, et aucune d’entre elles n’a l’image complète. La raison pour laquelle les pipelines de télémétrie sont devenus une partie standard de l’architecture de données d’entreprise moderne est qu’ils résolvent exactement ce problème : un pipeline unique et bien géré en amont de tous vos outils garantit que chaque équipe travaille à partir des mêmes données normalisées et enrichies sans agents et collecteurs déployés spécifiquement pour chaque équipe.

Cette flexibilité est importante à deux niveaux. Le premier est le tiering des données. Un pipeline de télémétrie bien conçu vous permet de faire correspondre les données à la bonne stratégie de stockage et d’analyse afin que vous ne payiez pas des prix d’analyse pour des données dont vous n’avez besoin que pour la rétention de conformité à long terme. Le second est l’optionnalité à mesure que le paysage des outils d’IA continue d’évoluer rapidement. Les entreprises qui construisent leur stratégie d’observabilité autour de l’écosystème d’un seul fournisseur feront face à des projets de migration coûteux chaque fois qu’un outil meilleur émerge.

Quelles erreurs voyez-vous les entreprises commettre lorsqu’elles tentent de réutiliser les pratiques de surveillance existantes sur les déploiements d’IA agente ?

L’erreur la plus courante que je vois est de tendre la main vers des plates-formes d’observabilité premium existantes pour collecter les traces d’agent sans réfléchir aux implications de coût en premier lieu. Les traces d’agent sont grandes, variables et volumineuses de manière que la télémétrie d’application traditionnelle ne l’est pas, et la plupart des plates-formes premium sont facturées en fonction de l’ingestion et du stockage. La facture peut devenir un problème grave avant même que les équipes ne réalisent ce qui se passe, et la réponse typique est de réduire ce qu’elles collectent. Le résultat est le pire des deux mondes : coût élevé et visibilité incomplète.

La deuxième erreur est d’appliquer le mauvais modèle mental à ce que la surveillance est censée répondre. La surveillance traditionnelle de l’infrastructure demande « le système est-il opérationnel ? » et déclenche des alertes lorsqu’il ne l’est pas. Cette question est nécessaire mais n’est nulle part près d’être suffisante pour les systèmes agents, où l’infrastructure peut être parfaitement saine tandis que l’agent prend discrètement de mauvaises décisions, récupère des données obsolètes ou s’écarte de son objectif initial. Les équipes qui réutilisent les tableaux de bord et les seuils d’alerte existants sur les flux de travail d’agent se convainquent souvent qu’elles ont une couverture lorsqu’elles ne regardent en réalité que les tuyauteries.

La troisième erreur est de traiter l’instrumentation comme une après-pensée. Les entreprises qui testent rapidement les agents et passent à la production sans réfléchir à l’observabilité se retrouvent dans des cycles de réparation coûteux, reconstruisant l’architecture de collecte de données après la première défaillance de production significative. Les équipes qui déployent les agents avec le plus de succès instrumentent tôt, établissent des lignes de base tandis que le trafic est faible et que le comportement est prévisible, et construisent leur cadre d’évaluation avant d’en avoir besoin plutôt qu’après que quelque chose se soit mal passé.

En regardant vers l’avenir, la visibilité de l’infrastructure deviendra-t-elle une condition préalable à l’adoption de l’IA d’entreprise de la même manière que l’observabilité du cloud est devenue essentielle pour la migration du cloud à grande échelle ?

La parallèle avec le cloud est extrêmement similaire. La chose la plus importante que je dis aux clients lorsqu’ils déplacent l’infrastructure vers le cloud est qu’ils ne font pas de levage et de déplacement. Ils déployeront une toute nouvelle architecture avec de nouvelles capacités. Tout cela doit être instrumenté et surveillé de manière que les outils précédents ne l’ont probablement pas été. Les entreprises qui ont sauté cette étape ont rencontré des défaillances en cascade qu’elles ne pouvaient pas diagnostiquer, des coûts en spirale qu’elles ne pouvaient pas expliquer et des pannes qu’elles ne pouvaient pas prévenir. L’observabilité est devenue la fondation de confiance qui a rendu la mise à l’échelle du cloud possible, et le même modèle se reproduit maintenant avec l’IA agente, se déplaçant plus rapidement et avec des enjeux plus élevés.

La raison principale pour laquelle les agents auront besoin de ce type de surveillance indéfiniment est qu’ils sont non déterministes par conception, leur comportement émerge à l’exécution et leur capacité effective augmente chaque fois que vous connectez un nouvel outil. La certification préalable à la mise en production statique ne peut pas couvrir un système dont la surface d’action change avec chaque intégration. Les agents fonctionneront dans des limites de confiance définies, et ces limites s’étendront avec le temps à mesure que l’infrastructure d’observabilité, de politique et d’évaluation mûrit. Les limites elles-mêmes ne disparaîtront jamais, et ce n’est pas un état d’échec. C’est ainsi que chaque système autonome conséquent dans le monde fonctionne déjà.

Merci pour cette grande interview, les lecteurs qui souhaitent en savoir plus peuvent visiter Cribl.