Shahar Azulay, PDG et cofondatrice de Groundcover

Shahar Azulay, PDG et cofondateur de Groundcover, Shahar est un leader chevronné en R&D. Fort d'une solide expérience en cybersécurité et en apprentissage automatique, il a occupé des postes à responsabilité au sein d'entreprises telles qu'Apple, DayTwo et Cymotive Technologies. Shahar a également travaillé plusieurs années au sein de la division Cyber ​​du cabinet du Premier ministre israélien et est titulaire de trois diplômes en physique, génie électrique et informatique, obtenus à l'Institut de technologie Technion d'Israël et à l'Université de Tel Aviv. Grâce à cette riche expérience, Shahar s'attache à mettre à profit ses connaissances technologiques pour développer des solutions innovantes et performantes dans le domaine du cloud, contribuant ainsi à un monde du développement plus performant.

couverture de sol Cette plateforme d'observabilité native du cloud offre aux équipes d'ingénierie une visibilité complète et en temps réel sur leurs systèmes, sans la complexité ni le coût des outils de supervision traditionnels. Basée sur la technologie eBPF, elle collecte et met en corrélation les journaux, les métriques, les traces et les événements dans les environnements cloud natifs et Kubernetes, sans aucune modification de code. Elle permet ainsi une analyse des causes profondes plus rapide et une meilleure compréhension du système. La plateforme privilégie une tarification prévisible, un déploiement flexible qui conserve les données dans le cloud du client, et une observabilité de bout en bout couvrant l'infrastructure, les applications et les charges de travail modernes pilotées par l'IA.

En repensant à votre parcours – de la direction d'équipes de R&D en cybersécurité au sein du cabinet du Premier ministre israélien à la gestion d'initiatives d'apprentissage automatique chez Apple – quelles expériences vous ont finalement poussé à fonder Groundcover, et quand avez-vous pris conscience pour la première fois du manque d'observabilité des systèmes d'IA modernes ?

L'idée de fonder Groundcover m'est venue de mon expérience chez Apple et DayTwo. Malgré des budgets colossaux, nous étions confrontés à un dilemme : payer une fortune pour tout consigner ou procéder par échantillonnage et naviguer à vue. À l'époque, nous recherchions une technologie capable de résoudre ce problème. Lorsque nous avons découvert Extended Berkeley Packet Filter (eBPF), il est devenu évident que cela allait tout changer. eBPF nous permet de voir tout ce qui se passe dans le noyau sans dépendre des modifications apportées aux applications. Je ne comprenais pas pourquoi les outils d'observabilité n'en tiraient pas parti. Le fossé en matière d'IA est devenu flagrant plus tard. Une fois notre plateforme Kubernetes arrivée à maturité, nous avons vu des clients se précipiter sur des déploiements d'IA générale tout en traitant les LLM comme des boîtes noires. Ils savaient que le modèle répondait, mais ignoraient pourquoi son comportement était imprévisible ou pourquoi les coûts s'envolaient. Nous avons réalisé que les flux de travail agentiques sont simplement des microservices complexes et non déterministes qui nécessitent la même visibilité sans intervention que nous avions déjà mise en place.

Comment votre expérience en cybersécurité, en systèmes embarqués et en R&D sur l'apprentissage automatique a-t-elle influencé la vision de Groundcover, et quels défis initiaux avez-vous rencontrés lors de la création d'une entreprise axée sur l'observabilité pour les applications pilotées par LLM et les agents ?

Mon expérience en cybersécurité a façonné l'ADN de l'entreprise. Dans le domaine du renseignement, on part du principe qu'on ne contrôle pas l'application. C'est pourquoi Groundcover ne nécessite aucune instrumentation. Je sais par expérience que demander aux développeurs de modifier le code est le meilleur moyen de freiner l'adoption. Le principal défi initial de la surveillance LLM était la protection de la vie privée. L'observabilité pour l'IA capture des requêtes pouvant contenir des informations personnelles sensibles ou des adresses IP. Mon expérience m'a clairement montré que les entreprises ne souhaiteraient pas que ces données quittent leur environnement. C'est pourquoi nous avons conçu notre architecture cloud, qui nous permet d'offrir une visibilité approfondie sur le comportement des agents tout en conservant toutes les données au sein de l'environnement du client.

Comment définir l'observabilité LLM, et en quoi la différencie-t-elle de la surveillance traditionnelle ou de la surveillance ML ?

L'observabilité des modèles de langage complexes (LLM) consiste à instrumenter et à surveiller les systèmes de production qui les utilisent afin de capturer le contexte complet de chaque inférence : l'invite, le contexte, la complétion, l'utilisation des jetons, la latence, les erreurs, les métadonnées du modèle et, idéalement, les retours d'information ou les signaux de qualité en aval. Au lieu de se contenter de se demander « Le service est-il opérationnel et rapide ? » ou « Cette requête a-t-elle échoué ? », l'observabilité des LLM permet de répondre à des questions telles que « Pourquoi cette requête a-t-elle réussi ou échoué ? », « Que s'est-il réellement passé au sein de ce flux de travail en plusieurs étapes ? » et « Comment les modifications apportées aux invites, au contexte ou aux versions du modèle affectent-elles le coût, la latence et la qualité des résultats ? ». Cette approche est très différente de la surveillance traditionnelle, voire de la surveillance classique du ML. Les méthodes traditionnelles sont optimisées pour les systèmes déterministes, les métriques d'infrastructure et les seuils statiques. Les applications LLM sont non déterministes, ouvertes et fortement dépendantes du contexte. Le succès est souvent sémantique et subjectif, et ne se résume pas à un simple code d'état 200 ou 500. Cela signifie que vous devez retracer les entrées et les sorties, comprendre les appels d'outils et les étapes de récupération, évaluer les réponses pour détecter des problèmes tels que des hallucinations ou des violations de politique, et relier les coûts et les délais au niveau du jeton à l'application et à l'infrastructure environnantes.

Quels sont les défis posés par les applications basées sur LLM qui rendent les outils d'observabilité traditionnels insuffisants ?

Les systèmes basés sur la technologie LLM soulèvent plusieurs défis qui mettent en évidence les limites des outils traditionnels :

• Flux de travail complexes en plusieurs étapes Nous sommes passés de flux simples du type « appeler un modèle, obtenir une réponse » à des agents multi-étapes, des pipelines à plusieurs étapes, la génération augmentée par récupération et l'utilisation d'outils. Une défaillance silencieuse à l'une de ces étapes, comme la récupération, l'enrichissement, l'intégration, l'appel d'outil ou l'appel de modèle, peut compromettre l'ensemble du processus. La supervision traditionnelle ne fournit généralement pas une vue complète et détaillée de ces chaînes, incluant les invites et les réponses.
• Piles d'IA en évolution rapide Les équipes ajoutent de nouveaux modèles, outils et fournisseurs à un rythme sans précédent. Dans de nombreuses entreprises, il est impossible de recenser avec certitude les modèles en production à un instant T. L'observabilité classique suppose généralement d'avoir le temps d'instrumenter les SDK, de redéployer et de sélectionner avec soin les données mesurées. Or, cette approche ne permet tout simplement pas de suivre la vitesse d'adoption de l'IA.
• Économie basée sur les jetons et les quotas La tarification et les limites de débit sont liées aux jetons et à la durée du contexte, souvent gérées par les développeurs, les invites ou le comportement des utilisateurs, et non par une équipe d'exploitation centrale. Les outils traditionnels ne permettent pas d'afficher « qui a consommé combien de jetons, selon quel modèle, pour quel flux de travail et avec quelle latence ».
• L'exactitude sémantique plutôt que le succès binaire Un LLM peut renvoyer un code 200 tout en ayant des hallucinations, en s'écartant des consignes ou en enfreignant les règles. Les outils traditionnels considèrent cela comme une réussite. Il vous faut une observabilité permettant de faire apparaître les consignes et les réponses, et de fournir suffisamment de contexte pour analyser le comportement et, à terme, mettre en place des contrôles qualité automatisés.
• Données sensibles transmises à des tiers Les plateformes de gestion de l'activité (LLM) invitent les utilisateurs à partager des informations très sensibles via des interfaces de type messagerie instantanée. Vous êtes alors responsable de ces données, de leur lieu de stockage et des fournisseurs qui y ont accès. Les solutions d'observabilité SaaS classiques, qui transmettent toutes les données de télémétrie à un tiers, sont souvent inadaptées à ces charges de travail.

Tout cela signifie que les systèmes LLM nécessitent une observabilité qui soit consciente de l'IA, riche en contexte et bien moins dépendante de l'instrumentation manuelle que les outils que la plupart des équipes utilisent aujourd'hui.

Quels signaux ou indicateurs sont les plus importants pour comprendre les performances et la qualité des systèmes LLM, notamment la latence, l'utilisation des jetons et le comportement des invites/réponses ?

Il existe quelques catégories de signaux qui sont très importantes en pratique :

Latence et débit

• Latence de bout en bout par requête, incluant le temps de modélisation et le temps d'application environnant.
• Latences de queue (P90, P95, P99) par modèle et par flux de travail.
• Débit par modèle, itinéraire et service, pour que vous sachiez exactement où va la charge.

Facteurs de coût liés à l'utilisation des jetons

• Jetons d'entrée et de sortie par requête, ventilés par modèle.
• Utilisation agrégée des jetons au fil du temps par modèle, équipe, utilisateur et flux de travail.
• Tailles de contexte pour les pipelines à forte intensité de récupération afin que vous puissiez voir quand les invites explosent.
• C’est ce qui vous permet de répondre à la question : « Qui dépense réellement notre budget IA et pour quoi ? »

Comportement prompt et réactif

• Les charges utiles réelles d'invite et de réponse sur des traces représentatives, y compris les appels d'outils et les chemins de raisonnement.
• Quels outils le LLM a-t-il choisi d'utiliser et dans quel ordre ?
• Variance des réponses à des incitations similaires afin de déterminer la stabilité du comportement.

Fiabilité et erreurs

• Taux et types d'erreurs spécifiques au modèle (erreurs du fournisseur, délais d'attente, problèmes d'authentification, erreurs de quota).
• Les défaillances dans le flux de travail environnant, telles que les délais d'expiration des outils ou les erreurs de récupération, étaient corrélées à l'appel LLM.

Contexte infra classique

• Métriques du processeur, de la mémoire et du réseau des conteneurs pour les services orchestrant vos appels LLM.
• Journaux corrélés décrivant ce que l'application tentait de faire.

Lorsque vous pouvez visualiser toutes ces informations au même endroit, l'observabilité LLM passe de « Je sais que quelque chose est lent ou coûteux » à « Je sais exactement quel modèle, quel modèle d'invite et quel service sont responsables et pourquoi ».

Comment l'observabilité peut-elle aider les équipes à détecter les défaillances silencieuses telles que la dérive des prompts, les hallucinations ou la dégradation progressive de la qualité de la production ?

Les défaillances silencieuses dans les systèmes LLM surviennent généralement lorsque tout semble fonctionner correctement au niveau de l'infrastructure, mais que le comportement réel dérive. L'observabilité apporte des solutions de plusieurs manières :

• En traçant l'intégralité du flux de travail, et pas seulement l'appel de modèle, on ne peut pas se contenter de l'appel de modèle. En capturant l'intégralité du parcours d'une requête, du client au service, puis à la récupération, au modèle et enfin aux outils, vous pouvez identifier les changements de comportement. Par exemple, il se peut que la récupération renvoie moins de documents, ou qu'un appel d'outil échoue de manière intermittente et que le modèle s'adapte.
• Garder à l'esprit les invites, le contexte et les réponses – Lorsque vous pouvez examiner les invites et les réponses en parallèle des traces, il devient beaucoup plus facile de repérer les cas où une nouvelle version d'invite, une nouvelle instruction système ou une nouvelle source de contexte a modifié le comportement, même si la latence et les taux d'erreur sont restés les mêmes.
• Filtrage et découpage selon des conditions sémantiques – Une fois que vous disposez de données de télémétrie LLM complètes, vous pouvez filtrer les données pour obtenir des résultats tels que « appels bedrock sur une seconde », « requêtes utilisant cette famille de modèles » ou « traces impliquant cet itinéraire particulier », puis lire les invites et les réponses pour voir si le modèle dérive ou hallucine dans un scénario spécifique.
• Alertes sur les SLO au niveau de l'entreprise Vous pouvez définir des SLO comme « tout appel LLM de plus d'une seconde enfreint notre SLA destiné aux utilisateurs » et déclencher des alertes lorsque ces conditions sont remplies. À terme, des SLO similaires peuvent être associés à des scores de qualité ou à des contrôles de politiques afin d'être alerté en cas de dégradation de la qualité, et non plus seulement en cas de défaillance de l'infrastructure.

Étant donné que la couche d'observabilité a accès à la fois aux signaux spécifiques à l'IA et aux journaux, métriques et traces classiques, elle devient un endroit naturel pour détecter les problèmes qui, autrement, dégraderaient silencieusement l'expérience utilisateur.

Comment l'approche de Groundcover permet-elle de diagnostiquer les latences imprévisibles ou les comportements inattendus dans les flux de travail d'agents à plusieurs étapes et les appels d'outils ?

Groundcover adopte une approche conçue pour les systèmes d'IA modernes. Nous utilisons un capteur basé sur eBPF au niveau du noyau pour observer le trafic entre les microservices, sans modification de code ni redéploiement. Dès que vous mettez en place un workflow LLM, nous pouvons détecter automatiquement ces appels. Si vous commencez à utiliser un nouveau modèle comme Anthropic, OpenAI ou Bedrock demain, Groundcover capture automatiquement ce trafic. Vous bénéficiez ainsi de :

• Traçabilité de bout en bout des flux de travail multi-sauts – Vous visualisez le parcours complet d'une requête à travers les services, y compris les endroits où un LLM ou un outil est utilisé.
• Contexte détaillé de chaque appel LLM – Chaque appel inclut le modèle utilisé, la latence, l'utilisation des jetons, les invites, les réponses, ainsi que les journaux et les métriques d'infrastructure corrélés.
• Filtrage performant de la latence et des conditions – Par exemple, vous pouvez filtrer tous les appels Claude 3.5 de plus d'une seconde et examiner immédiatement les traces qui ont enfreint votre SLA.
• Alertes et tableaux de bord liés au comportement LLM – Une fois les données disponibles, vous pouvez créer des alertes en cas de non-respect des SLA ou construire des tableaux de bord qui suivent la latence, le débit, l'utilisation des jetons et les erreurs.

Comme toutes les données sont collectées en périphérie par eBPF et stockées dans votre propre cloud, vous bénéficiez de cette vue très détaillée sans avoir à ajouter d'instrumentation dans chaque agent ou appel d'outil.

Quels risques liés à la sécurité des données et à la conformité voyez-vous apparaître dans les déploiements LLM, et comment l'observabilité peut-elle contribuer à réduire ces risques ?

Les déploiements LLM comportent des risques uniques en matière de données :

• Entrée utilisateur illimitée Les utilisateurs peuvent saisir des informations extrêmement sensibles dans les chatbots et les interfaces basées sur l'IA. Il peut s'agir de données personnelles, de données clients ou d'informations réglementées que vous n'aviez jamais l'intention de collecter.
• Fournisseurs de modèles tiers Une fois vos données transmises à un prestataire LLM externe, vous êtes responsable de leur destination, de leur stockage et des sous-traitants impliqués. Cela a des conséquences majeures en matière de RGPD, de résidence des données et de confiance des clients.
• La télémétrie comme deuxième copie de données sensibles – Si votre pile d'observabilité envoie des charges utiles complètes à un fournisseur SaaS, vous disposez désormais d'une autre copie de ces informations sensibles en dehors de votre environnement.

L'architecture des couvre-sols est conçue pour répondre précisément à ces préoccupations :

• Nous utilisons un modèle BYOD (Bring Your Own Cloud) où l'ensemble du système d'observabilité s'exécute au sein de votre compte cloud, dans un sous-compte, sous la forme d'un plan de données entièrement géré. Le plan de contrôle qui assure la mise à l'échelle et la gestion est géré par nos soins, mais nous n'accédons pas à vos données de télémétrie, ne les stockons pas et ne les traitons pas.
• Grâce à notre capacité à capturer les données en toute sécurité dans votre environnement, vous pouvez observer les invites, les réponses et les flux de travail sans que ces données ne quittent votre cloud. Vos traces LLM ne sont stockées chez aucun tiers et vous n'avez aucun souci à vous faire concernant les sorties de données.
• Grâce à cette visibilité, vous pouvez voir qui télécharge quoi et où cela circule, détecter toute utilisation inattendue de données sensibles et appliquer des politiques concernant les modèles et les régions autorisés.

Autrement dit, l'observabilité devient non seulement un outil de fiabilité et de réduction des coûts, mais aussi un point de contrôle clé pour la confidentialité, la résidence des données et la conformité.

À mesure que les organisations passent d'une seule intégration LLM à de nombreux services basés sur l'IA, quels défis opérationnels ont tendance à apparaître en matière de visibilité, de fiabilité et de coût ?

La première intégration concerne généralement un seul modèle dans un seul flux de travail. À ce stade, tout semble gérable. Dès que les équipes constatent la valeur ajoutée, l'utilisation explose et plusieurs défis apparaissent :

• Prolifération des modèles et des fournisseurs – Les équipes testent constamment de nouveaux modèles. On ne sait plus très bien lesquels sont en production et comment ils sont utilisés.
• Les coûts imprévus liés à l'utilisation des jetons La consommation de jetons augmente avec la longueur du contexte et la complexité du flux de travail. Sans visibilité sur l'utilisation des jetons par modèle et flux de travail, la gestion des coûts est très difficile.
• Dépendance de la fiabilité vis-à-vis des fournisseurs externes – Les API destinées aux utilisateurs deviennent sensibles à la latence ou aux erreurs des modèles, ce qui peut perturber les SLA même lorsque l'infrastructure de base est saine.
• Dette croissante liée à l'instrumentation L’observabilité traditionnelle suppose qu’il est possible d’ajouter des instruments au besoin. Dans les environnements d’IA en constante évolution, les développeurs ont rarement le temps de s’en occuper.

Groundcover résout ces problèmes en détectant automatiquement le trafic IA et en vous fournissant ensuite :

• Visibilité centralisée sur les modèles et les fournisseurs utilisés.
• Tableaux de bord affichant la latence, le débit et l'utilisation des jetons au fil du temps.
• Corrélation entre le comportement des LLM et les services qui en dépendent
• Alertes en cas de violation des SLO pilotée par l'IA.

Cela facilite grandement le passage d'une « fonctionnalité d'IA intéressante » à une « IA intégrée à des dizaines de services critiques » sans perdre le contrôle.

Pour les cinq prochaines années, comment prévoyez-vous l'évolution de l'observabilité LLM, compte tenu de l'accélération de l'IA agentielle, de l'orchestration multi-modèles et des pressions réglementaires ?

Nous n'en sommes qu'aux prémices. Au cours des cinq prochaines années, je m'attends à quelques changements majeurs :

• De la compréhension au niveau de la requête jusqu'au niveau de l'agent – L’observabilité s’étendra pour capturer les séquences d’outils, les chemins de raisonnement et la logique de nouvelle tentative, et non plus seulement les appels de modèles.
• Des signaux sémantiques et politiques plus riches – Les contrôles de qualité automatisés concernant les hallucinations, les problèmes de sécurité et la conformité à la marque deviendront des indicateurs standard.
• Un lien plus étroit avec la gouvernance et la protection de la vie privée – À mesure que la réglementation se développe, l’observabilité servira également de couche de contrôle et d’audit pour la résidence des données, leur conservation et l’utilisation des modèles approuvés.
• Optimisation inter-modèles et multi-fournisseurs – Les équipes achemineront le trafic entre les modèles de manière dynamique en fonction des performances et des coûts, guidées par des données d'observabilité en temps réel.
• Moins d'instrumentation manuelle – Des techniques comme la collecte basée sur eBPF et la découverte automatique deviendront la norme, permettant ainsi aux équipes d'innover sans ralentissement.

En bref, l'observabilité LLM évoluera de simples « tableaux de bord utiles pour l'IA » vers le système nerveux central qui relie la fiabilité, le contrôle des coûts, la gouvernance des données et la qualité des produits dans tout ce qu'une organisation fait avec l'IA.

Merci pour cette excellente interview, les lecteurs qui souhaitent en savoir plus devraient visiter couverture de sol.