Shahar Azulay, PDG et co-fondateur de groundcover

Shahar Azulay, PDG et co-fondateur de groundcover est un leader R&D sériel. Shahar apporte une expérience dans le monde de la cybersécurité et de l’apprentissage automatique ayant travaillé comme leader dans des entreprises telles qu’Apple (AAPL ), DayTwo et Cymotive Technologies. Shahar a passé de nombreuses années dans la division Cyber au bureau du Premier ministre israélien et détient trois diplômes en physique, en génie électrique et en informatique de l’Institut de technologie d’Israël ainsi que de l’Université de Tel-Aviv. Shahar s’efforce d’utiliser les connaissances technologiques de ce riche passé et de les apporter au champ de bataille natif du cloud d’aujourd’hui sous la forme la plus innovante pour rendre le monde du développement plus agréable.

groundcover est une plate-forme d’observabilité native du cloud conçue pour offrir aux équipes d’ingénieurs une visibilité complète et en temps réel sur leurs systèmes sans la complexité ou le coût des outils de surveillance traditionnels. Basée sur la technologie eBPF, elle collecte et corréle les journaux, les métriques, les traces et les événements dans les environnements cloud natifs et Kubernetes sans modification de code, permettant une analyse de cause racine plus rapide et une compréhension du système plus claire. La plate-forme met l’accent sur la tarification prévisible, le déploiement flexible qui maintient les données dans le cloud du client et l’observabilité de bout en bout couvrant l’infrastructure, les applications et les charges de travail modernes alimentées par l’IA.

En regardant votre parcours – de la direction des équipes de R&D en cybersécurité au bureau du Premier ministre israélien à la gestion des initiatives de ML chez Apple – quels ont été les facteurs qui vous ont finalement poussé à fonder groundcover, et quand avez-vous reconnu le fossé en matière d’observabilité pour les systèmes d’IA modernes ?

La poussée pour fonder groundcover est venue de mon temps chez Apple et DayTwo. Même avec des budgets énormes, nous étions coincés entre payer une fortune pour tout enregistrer ou échantillonner et voler aveuglément. À l’époque, nous recherchions une technologie qui résoudrait ce problème. Dès que nous avons rencontré le filtre de paquets Berkeley étendu (eBPF), il était clair que cela changerait tout. eBPF nous permet de voir tout ce qui se passe dans le noyau sans nous appuyer sur des modifications d’application. Je ne pouvais pas comprendre pourquoi les outils d’observabilité ne profitaient pas de cela. Le fossé de l’IA est devenu clair plus tard. Une fois que notre plate-forme Kubernetes a mûri, nous avons vu les clients se précipiter dans les déploiements de GenAI tout en traitant les LLM comme des boîtes noires. Ils savaient que le modèle répondait, mais pas pourquoi il se comportait de manière imprévisible ou pourquoi les coûts explosaient. Nous avons réalisé que les flux de travail agents sont simplement des microservices complexes et non déterministes qui ont besoin de la même visibilité sans contact que nous avions déjà construite.

Comment votre expérience en cybersécurité, en systèmes intégrés et en R&D de ML a-t-elle influencé la vision derrière groundcover, et quels défis précoces avez-vous rencontrés en construisant une entreprise centrée sur l’observabilité pour les applications LLM et les applications agentic ?

Mon expérience en cybersécurité a façonné l’ADN de l’entreprise. Dans le monde du renseignement, on suppose que l’on ne contrôle pas l’application. Cette approche est la raison pour laquelle groundcover n’exige pas d’instrumentation. Je sais par expérience que demander aux développeurs de modifier le code est le moyen le plus rapide de bloquer l’adoption. Le défi le plus difficile avec la surveillance des LLM était la confidentialité. L’observabilité de l’IA capture des invites qui peuvent contenir des informations sensibles PII ou IP. Mon expérience a rendu évident que les entreprises ne voudraient pas que ces données quittent leur environnement. C’est pourquoi nous avons construit notre architecture dans le cloud, nous permettant de fournir une visibilité approfondie sur le comportement de l’agent tout en gardant toutes les données à l’intérieur de l’environnement du client.

Comment définissez-vous l’observabilité LLM, et en quoi diffère-t-elle de la surveillance traditionnelle ou de la surveillance de ML ?

L’observabilité LLM est la pratique de l’instrumentation et de la surveillance des systèmes de production qui utilisent de grands modèles de langage pour capturer le contexte complet de chaque inférence : l’invite, le contexte, la completion, l’utilisation de jetons, la latence, les erreurs, les métadonnées du modèle et, idéalement, les signaux de rétroaction ou de qualité en aval. Au lieu de se demander simplement « Le service est-il actif et rapide ? » ou « Cette demande a-t-elle abouti à une erreur ? », l’observabilité LLM vous aide à répondre à des questions comme « Pourquoi cette demande particulière a-t-elle abouti ou échoué ? », « Qu’est-ce qui s’est réellement passé à l’intérieur de ce flux de travail multi-étapes ? » et « Comment les modifications des invites, du contexte ou des versions de modèle affectent-elles le coût, la latence et la qualité de sortie ? » Cela est très différent de la surveillance traditionnelle ou même de la surveillance classique de ML. Les approches traditionnelles sont conçues pour des systèmes déterministes, des métriques d’infrastructure et des 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 non seulement un code de statut 200 ou 500. Cela signifie que vous devez tracer les entrées et les sorties, comprendre les appels d’outils et les étapes de récupération, évaluer les réponses pour des choses comme les hallucinations ou les violations de politique, et relier les coûts et les retards au niveau des jetons aux applications et infrastructures environnantes.

Quels défis les applications alimentées par LLM introduisent-elles qui rendent les outils d’observabilité traditionnels insuffisants ?

Les systèmes alimentés par LLM introduisent plusieurs défis qui exposent les limites des outils traditionnels :

• Flux de travail complexes et multi-étapes – Nous sommes passés de flux simples « appelez un modèle, obtenez une réponse » à des agents multi-étapes, des pipelines multi-étapes, une génération assistée par récupération et des appels d’outils. Une défaillance silencieuse dans l’une de ces étapes, telle que la récupération, l’enrichissement, l’intégration, l’appel d’outils ou l’appel de modèle, peut casser toute l’expérience. La surveillance traditionnelle ne vous donne généralement pas une vue complète et au niveau de la trace de ces chaînes avec les invites et les réponses incluses.
• Évolution rapide des piles d’IA – Les équipes ajoutent de nouveaux modèles, outils et fournisseurs à un rythme qu’elles n’ont jamais vu auparavant. Dans de nombreuses entreprises, personne ne peut lister avec confiance quels modèles sont en production à un moment donné. La surveillance classique suppose que vous avez le temps d’instrumenter les SDK, de réimplanter et de mesurer soigneusement ce que vous mesurez. Cela ne suit simplement pas le rythme auquel l’IA est adoptée.
• Économie et quotas basés sur les jetons – La tarification et les limites de débit sont liées aux jetons et à la longueur du contexte, qui sont souvent contrôlés par les développeurs, les invites ou le comportement de l’utilisateur, et non par les opérations centrales. Les outils traditionnels ne sont pas conçus pour vous montrer « qui a brûlé combien de jetons sur quel modèle, pour quel flux de travail, à quelle latence ».
• Correction sémantique au lieu du succès binaire – Un LLM peut renvoyer un code 200 et toujours halluciner, s’éloigner de votre invite ou enfreindre une politique. Les outils traditionnels voient cela comme un succès. Vous avez besoin d’une observabilité qui peut exposer les invites et les réponses et vous donner suffisamment de contexte pour inspecter le comportement et, avec le temps, brancher des contrôles de qualité automatisés.
• Données d’entrée sensibles qui circulent vers des tiers – Les LLM invitent les utilisateurs à partager des informations extrêmement sensibles via des interfaces de type chat. Vous êtes maintenant responsable de ces données, de l’endroit où elles sont stockées et des fournisseurs qui les voient. La surveillance SaaS conventionnelle qui envoie toute la télémétrie à un tiers est souvent inacceptable pour ces charges de travail.

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

Quels signaux ou métriques 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 d’invite/réponse ?

Il y a quelques catégories de signaux qui comptent beaucoup dans la pratique :

Latence et débit

• Latence de bout en bout par demande, y compris le temps de modèle 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, afin que vous sachiez où la charge va réellement.

Utilisation des jetons et facteurs de coût

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

Comportement d’invite et de réponse

• Les invites et les réponses réelles sur les traces représentatives, y compris les appels d’outils et les chemins de raisonnement.
• Quels outils le LLM a choisi d’appeler et dans quel ordre.
• Variance dans les réponses pour des invites similaires afin que vous puissiez dire à quel point le comportement est stable.

Fiabilité et erreurs

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

Contexte d’infrastructure classique

• Métriques CPU, mémoire et réseau des conteneurs pour les services qui orchestreront vos appels LLM.
• Journaux corrélés qui décrivent ce que l’application essayait de faire.

Lorsque vous pouvez voir tout cela en un seul endroit, l’observabilité LLM passe de « Je sais que quelque chose est lent ou coûteux » à « Je sais exactement quel modèle, motif d’invite et service sont responsables et pourquoi ».

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

Les défaillances silencieuses dans les systèmes LLM se produisent généralement lorsque tout semble « vert » au niveau de l’infrastructure, mais que le comportement réel dérive. L’observabilité aide de plusieurs manières :

• En traçant l’ensemble du flux de travail, et non seulement l’appel de modèle – En capturant l’ensemble du chemin d’une demande client vers service vers récupération vers modèle vers outils, vous pouvez voir où le comportement a changé. Par exemple, peut-être que la récupération a commencé à renvoyer moins de documents, ou qu’un appel d’outil est en train de défaillir de manière intermittente, et que le modèle improvise.
• En gardant les invites, le contexte et les réponses en vue – Lorsque vous pouvez inspecter les invites et les réponses aux côtés des traces, il devient beaucoup plus facile de repérer les cas où une nouvelle version d’invite, une nouvelle instruction de 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.
• En filtrant et en découpant sur des conditions sémantiques – Une fois que vous disposez d’une télémétrie LLM riche, vous pouvez filtrer vers des choses comme « les appels de base de données supérieurs à une seconde », « les demandes utilisant cette famille de modèles » ou « les traces impliquant cette route particulière », puis lire les invites et les réponses pour voir si le modèle dérive ou hallucine dans un scénario spécifique.
• En déclenchant des alertes sur les SLO de niveau commercial – Vous pouvez définir des SLO comme « tout appel LLM supérieur à une seconde enfreint notre SLA utilisateur » et déclencher des alertes lorsque ces conditions sont remplies. Au fil du temps, des SLO similaires peuvent être liés à des scores de qualité ou à des vérifications de politique afin que vous soyez averti lorsque la qualité se dégrade, et non seulement lorsque l’infrastructure échoue.

Parce 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 point naturel pour capturer les problèmes qui auraient autrement dégradé silencieusement l’expérience utilisateur.

Comment l’approche de groundcover prend-elle en charge le diagnostic de la latence imprévisible ou du comportement inattendu au sein des flux de travail d’agents multi-étapes et des 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 à travers les microservices sans modification de code ou réimplémentation. Dès que vous introduisez un flux de travail LLM, nous pouvons découvrir automatiquement ces appels. Si vous commencez à utiliser un nouveau modèle comme Anthropic, OpenAI ou Bedrock demain, groundcover capture automatiquement ce trafic. Cela vous donne :

• Des traces de bout en bout des flux de travail multi-hops – Vous voyez l’ensemble du chemin d’une demande à travers les services, y compris où un LLM ou un outil est utilisé.
• Un contexte profond sur chaque appel LLM – Chaque appel inclut le modèle utilisé, la latence, l’utilisation des jetons, les invites, les réponses et les journaux et les métriques d’infrastructure corrélés.
• Un filtrage puissant sur la latence et les conditions – Par exemple, vous pouvez filtrer toutes les appels Claude 3.5 supérieurs à une seconde et inspecter immédiatement les traces qui ont enfreint votre SLA.
• Des alertes et des tableaux de bord liés au comportement LLM – Une fois que les données sont disponibles, vous pouvez créer des alertes pour les violations de SLA ou construire des tableaux de bord qui suivent la latence, le débit, l’utilisation des jetons et les erreurs.

Parce que tout est collecté à la limite par eBPF et stocké dans votre propre cloud, vous obtenez cette vue à granularité élevée sans ajouter d’instrumentation à l’intérieur de chaque agent ou appel d’outil.

Quels risques de sécurité des données et de conformité voyez-vous émerger dans les déploiements LLM, et comment l’observabilité peut-elle aider à réduire ces risques ?

Les déploiements LLM présentent quelques risques de données uniques :

• Entrée utilisateur non limitée – Les utilisateurs peuvent taper des informations extrêmement sensibles dans les interfaces de chat et les interfaces d’IA. Cela peut inclure des données personnelles, des données client ou des informations réglementées que vous n’aviez jamais l’intention de collecter.
• Fournisseurs de modèles tiers – Une fois que vous envoyez ces données à un fournisseur LLM externe, vous êtes responsable de l’endroit où elles se trouvent, de la façon dont elles sont stockées et des sous-traitants impliqués. Cela a des implications majeures pour le RGPD, la résidence des données et la confiance des clients.
• 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 avez maintenant une autre copie de ces informations sensibles en dehors de votre environnement.

L’architecture de groundcover est conçue pour répondre exactement à ces préoccupations :

• Nous utilisons un modèle « apportez votre propre cloud » où la pile d’observabilité complète s’exécute à l’intérieur de votre compte cloud, dans un sous-compte, en tant que plan de données entièrement géré. Le plan de contrôle qui le met à l’échelle et le gère est exécuté par nous, mais nous n’accédons pas, ne stockons pas ni ne traitons vos données de télémétrie.
• Parce que nous pouvons capturer en toute sécurité les charges utiles dans votre propre environnement, vous pouvez observer les invites, les réponses et les flux de travail sans que ces données quittent jamais votre cloud. Il n’y a pas de stockage tiers de vos traces LLM et pas de sortie de données supplémentaire à vous soucier.
• Avec cette visibilité, vous pouvez voir qui télécharge quoi et où cela s’écoule, détecter une utilisation inattendue de données sensibles et faire respecter les politiques autour des modèles et des régions autorisés.

En d’autres termes, l’observabilité devient non seulement un outil de fiabilité et de coût, mais également 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 intégration LLM à de nombreux services alimentés par l’IA, quels défis opérationnels tendent à apparaître autour de la visibilité, de la fiabilité et du coût ?

La première intégration est généralement un seul modèle dans un seul flux de travail. À ce stade, les choses semblent gérables. Dès que les équipes voient la valeur, l’utilisation explose et plusieurs défis apparaissent :

• Éparpillement de modèles et de fournisseurs – Les équipes testent constamment de nouveaux modèles. Il devient rapidement flou de savoir quels modèles sont en production et comment ils sont utilisés.
• Surprises de coûts due à 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 par flux de travail, la gestion des coûts est très difficile.
• Dépendances de fiabilité sur les fournisseurs externes – Les API orientées utilisateur deviennent sensibles à la latence du modèle ou aux erreurs, qui peuvent perturber les SLA même si l’infrastructure de base est saine.
• Dettes d’instrumentation croissantes – La surveillance traditionnelle suppose que vous pouvez ajouter une instrumentation lorsque vous en avez besoin. Dans les piles d’IA en évolution rapide, les développeurs n’ont rarement le temps pour cela.

groundcover répond à ces défis en découvrant automatiquement le trafic IA, puis en vous donnant :

• Une visibilité centralisée sur quels modèles et fournisseurs sont utilisés.
• Des tableaux de bord montrant la latence, le débit et l’utilisation des jetons au fil du temps.
• Une corrélation entre le comportement LLM et les services qui en dépendent
• Des alertes pour les violations de SLO IA.

Cela facilite grandement le passage d’une « fonctionnalité IA sympa » à « l’IA est tissée dans des dizaines de services critiques » sans perdre le contrôle.

En regardant vers l’avenir, comment prévoyez-vous que l’observabilité LLM évoluera au cours des cinq prochaines années à mesure que l’IA agentic, l’orchestration multi-modèles et les pressions réglementaires s’accélèrent ?

Nous sommes encore dans les premiers jours. Au cours des cinq prochaines années, j’attends plusieurs grands changements :

• De la compréhension au niveau de la demande à la compréhension au niveau de l’agent – L’observabilité s’étendra pour capturer les séquences d’outils, les chemins de raisonnement et la logique de réessai, et non seulement les appels de modèle.
• Signaux sémantiques et de politique plus riches – Les contrôles de qualité automatisés pour les hallucinations, les problèmes de sécurité et l’alignement sur la marque deviendront des métriques standard.
• Un couplage plus étroit avec la gouvernance et la confidentialité – À mesure que la réglementation augmente, l’observabilité servira également de couche d’exécution et d’audit pour la résidence des données, la rétention et l’utilisation de modèles approuvés.
• Optimisation multi-modèles et multi-fournisseurs – Les équipes routeront le trafic à travers les modèles dynamiquement en fonction des performances et des coûts, guidés par des données d’observabilité en temps réel.
• Moins d’instrumentation manuelle – Les techniques telles que la collecte basée sur eBPF et la découverte automatique deviendront la norme, de sorte que les équipes puissent innover sans ralentir.

En bref, l’observabilité LLM évoluera d’une « jolie fonctionnalité à avoir pour les tableaux de bord IA » en 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 à travers tout ce qu’une organisation fait avec l’IA.

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