Shahar Azulay, CEO und Mitgründer von groundcover

Shahar Azulay, CEO und Mitgründer von groundcover ist ein serieller R&D-Leiter. Shahar bringt Erfahrung in der Welt der Cybersicherheit und des maschinellen Lernens mit, da er als Leiter in Unternehmen wie Apple, DayTwo und Cymotive Technologies gearbeitet hat. Shahar verbrachte viele Jahre in der Cyber-Abteilung im Büro des israelischen Premierministers und hält drei Abschlüsse in Physik, Elektrotechnik und Informatik von der Technion Israel Institute of Technology sowie der Tel Aviv University. Shahar strebt danach, technologische Erkenntnisse aus diesem reichen Hintergrund zu nutzen und sie in die heutige cloudbasierte Schlacht in der schärfsten, innovativsten Form zu bringen, um die Welt der Entwicklung zu einem besseren Ort zu machen.

groundcover ist eine cloudbasierte Observability-Plattform, die entwickelt wurde, um Engineering-Teams eine vollständige, Echtzeit-Sichtbarkeit in ihre Systeme zu geben, ohne die Komplexität oder die Kosten traditioneller Überwachungstools. Basierend auf eBPF-Technologie sammelt und korreliert es Protokolle, Metriken, Spuren und Ereignisse in cloudbasierten und Kubernetes-Umgebungen ohne Code-Änderungen, was eine schnellere Fehlerursachenanalyse und ein besseres Systemverständnis ermöglicht. Die Plattform betont vorhersehbare Preise, flexible Bereitstellung, die die Daten im Cloud-System des Kunden hält, und eine umfassende Observability, die Infrastruktur, Anwendungen und moderne AI-getriebene Workloads umfasst.

Wenn wir auf Ihre Reise zurückblicken – von der Leitung von Cyber-R&D-Teams im Büro des israelischen Premierministers bis zur Verwaltung von ML-Initiativen bei Apple – welche Erfahrungen haben Sie letztendlich dazu gebracht, groundcover zu gründen, und wann haben Sie den Gap in der Observability für moderne AI-Systeme erkannt?

Der Anstoß, groundcover zu gründen, kam aus meiner Zeit bei Apple und DayTwo. Selbst mit großen Budgets waren wir gezwungen, zwischen dem Bezahlen einer großen Summe, um alles zu protokollieren, oder dem Sampeln und dem Fliegen im Blindflug zu wählen. Damals suchten wir nach einer Technologie, die das lösen würde. Als wir auf den erweiterten Berkeley-Paket-Filter (eBPF) stießen, war es klar, dass es alles verändern würde. eBPF ermöglicht es uns, alles zu sehen, was im Kernel passiert, ohne auf Anwendungsänderungen angewiesen zu sein. Ich konnte nicht verstehen, warum Observability-Tools diese Möglichkeit nicht nutzten. Der Gap in der AI wurde später klar. Als unsere Kubernetes-Plattform ausgereift war, sahen wir, wie Kunden in GenAI-Deployments stürmten und LLMs wie schwarze Kisten behandelten. Sie wussten, dass das Modell reagierte, aber nicht, warum es unvorhersehbar oder warum die Kosten sprangen. Wir erkannten, dass agente Workflows einfach komplexe, nicht-deterministische Microservices sind, die die gleiche zero-touch-Sichtbarkeit benötigen, die wir bereits aufgebaut hatten.

Wie hat Ihre Erfahrung in der Cybersicherheit, eingebetteten Systemen und maschinellen Lernens die Vision hinter groundcover beeinflusst, und welche frühen Herausforderungen haben Sie beim Aufbau eines Unternehmens, das sich auf Observability für LLM-getriebene und agente Anwendungen konzentriert, erlebt?

Mein Hintergrund in der Cybersicherheit hat das DNA des Unternehmens geprägt. In der Welt der Nachrichtendienste geht man davon aus, dass man die Anwendung nicht kontrolliert. Dieser Ansatz ist der Grund, warum groundcover keine Instrumentierung erfordert. Ich weiß aus Erfahrung, dass die Bitte an Entwickler, den Code zu ändern, der schnellste Weg ist, die Akzeptanz zu blockieren. Die größte frühe Herausforderung bei der Überwachung von LLM war die Privatsphäre. Observability für AI erfasst Prompts, die möglicherweise sensible personenbezogene Daten oder geistiges Eigentum enthalten. Mein Hintergrund machte es offensichtlich, dass Unternehmen diese Daten nicht aus ihrer Umgebung herausgeben möchten. Deshalb bauten wir unsere In-Cloud-Architektur, um tiefere Einblicke in das Verhalten von Agenten zu ermöglichen, während alle Daten innerhalb der Umgebung des Kunden bleiben.

Wie definieren Sie LLM-Observability, und was unterscheidet es von traditioneller Überwachung oder ML-Überwachung?

LLM-Observability ist die Praxis, Produktions-Systeme zu instrumentieren und zu überwachen, die große Sprachmodelle verwenden, um den vollen Kontext jeder Inferenz zu erfassen: den Prompt, den Kontext, die Vervollständigung, die Token-Nutzung, die Latenz, die Fehler, die Modell-Metadaten und idealerweise auch Downstream-Feedback oder Qualitäts-Signale. Anstatt nur zu fragen, ob der Dienst verfügbar ist und schnell ist oder ob diese Anfrage fehlgeschlagen ist, hilft LLM-Observability Ihnen, Fragen wie Warum ist diese bestimmte Anfrage erfolgreich oder fehlgeschlagen?, Was ist tatsächlich innerhalb dieses mehrstufigen Workflows passiert? und Wie wirken sich Änderungen an Prompts, Kontext oder Modellversionen auf Kosten, Latenz und Ausgabe-Qualität aus? Das ist sehr unterschiedlich von traditioneller Überwachung oder sogar klassischer ML-Überwachung. Legacy-Ansätze sind für deterministische Systeme, Infrastruktur-Metriken und statische Schwellenwerte ausgelegt. LLM-Anwendungen sind nicht-deterministisch, offen und stark kontext-abhängig. Erfolg ist oft semantisch und subjektiv, nicht nur ein 200- gegenüber einem 500-Status-Code. Das bedeutet, dass Sie Eingaben und Ausgaben verfolgen, Tool-Aufrufe und Abruf-Schritte verstehen, Antworten auf Dinge wie Halluzinationen oder Richtlinien-Verstöße bewerten und Token-Kosten und Verzögerungen mit der umgebenden Anwendung und Infrastruktur verbinden müssen.

Welche Herausforderungen stellen LLM-getriebene Anwendungen dar, die traditionelle Observability-Tools unzureichend machen?

LLM-Systeme stellen mehrere Herausforderungen dar, die die Grenzen traditioneller Tools aufzeigen:

• Komplexe, mehrstufige Workflows – Wir sind von einfachen Flows wie Aufruf eines Modells und Erhalt einer Antwort zu mehrstufigen Agenten, mehrstufigen Pipelines, retrieval-augmentierter Generierung und Tool-Nutzung übergegangen. Ein stiller Fehler in einem dieser Schritte, wie z.B. Abruf, Anreicherung, Einbettung, Tool-Aufruf oder Modell-Aufruf, kann die gesamte Erfahrung brechen. Traditionelle Überwachung bietet normalerweise keinen vollständigen, spurenbasierten Überblick über diese Ketten mit Prompts und Antworten.
• Schnell evolvierende AI-Stacks – Teams fügen neue Modelle, Tools und Anbieter in einem Tempo hinzu, das sie noch nie zuvor gesehen haben. In vielen Unternehmen kann niemand mit Sicherheit auflisten, welche Modelle derzeit in Produktion sind. Klassische Observability geht normalerweise davon aus, dass man Zeit hat, um SDKs zu instrumentieren, neu zu bereitstellen und sorgfältig zu kuratieren, was gemessen wird. Das hält einfach nicht mit dem Tempo der AI-Adoption Schritt.
• Token-basierte Ökonomie und Quoten – Preise und Rate-Limits sind an Token und Kontext-Länge geknüpft, die oft von Entwicklern, Prompts oder Benutzerverhalten und nicht von zentralen Ops kontrolliert werden. Traditionelle Tools sind nicht darauf ausgelegt, Ihnen zu zeigen, wer wie viele Token auf welchem Modell, für welchen Workflow und mit welcher Latenz verbraucht.
• Semantische Korrektheit anstelle von binärer Erfolg – Ein LLM kann einen 200-Status-Code zurückgeben und dennoch halluzinieren, vom Prompt abweichen oder gegen Richtlinien verstoßen. Traditionelle Tools sehen das als Erfolg. Sie benötigen Observability, die Prompts und Antworten zu Tage fördern und Ihnen genug Kontext bieten kann, um das Verhalten zu untersuchen und im Laufe der Zeit automatisierte Qualitäts-Checks einzubauen.
• Empfindliche Eingabedaten, die in Drittanbieter fließen – LLMs laden Benutzer ein, sehr empfindliche Informationen über Chat-Interfaces und AI-getriebene Schnittstellen zu teilen. Jetzt sind Sie für diese Daten verantwortlich, wo sie gespeichert werden und welche Anbieter sie sehen. Konventionelle SaaS-basierte Observability, die alle Telemetrie an einen Drittanbieter sendet, ist oft für diese Workloads inakzeptabel.

All dies bedeutet, dass LLM-Systeme Observability erfordern, die AI-bewusst, kontext-reich und weit weniger von manueller Instrumentierung abhängig ist als die Tools, die die meisten Teams heute verwenden.

Welche Signale oder Metriken sind am wichtigsten, um die Leistung und Qualität von LLM-Systemen zu verstehen, einschließlich Latenz, Token-Nutzung und Prompt-/Antwort-Verhalten?

Es gibt einige Kategorien von Signalen, die in der Praxis sehr wichtig sind:

Latenz und Durchsatz

• End-to-End-Latenz pro Anfrage, einschließlich Modellzeit und umgebender Anwendungszeit.
• Schwanz-Latenzen (P90, P95, P99) pro Modell und pro Workflow.
• Durchsatz pro Modell, Route und Dienst, damit Sie wissen, wo die Last tatsächlich hingeht.

Token-Nutzung und Kosten-Treiber

• Eingabe- und Ausgabe-Token pro Anfrage, aufgeschlüsselt nach Modell.
• Gesamte Token-Nutzung über die Zeit pro Modell, Team, Benutzer und Workflow.
• Kontext-Größen für Abruf-Intensive Pipelines, damit Sie sehen können, wenn Prompts explodieren.
• Dies ist es, was Ihnen ermöglicht, zu antworten: Wer verbraucht tatsächlich unseren AI-Budget und wofür?

Prompt- und Antwort-Verhalten

• Die tatsächlichen Prompt- und Antwort-Payloads auf repräsentativen Spuren, einschließlich Tool-Aufrufen und Denkpfaden.
• Welche Tools das LLM gewählt hat und in welcher Reihenfolge.
• Varianz in Antworten für ähnliche Prompts, damit Sie erkennen können, wie stabil das Verhalten ist.

Zuverlässigkeit und Fehler

• Modell-spezifische Fehler-Raten und -Typen (Anbieter-Fehler, Timeouts, Authentifizierungs-Fehler, Quoten-Fehler).
• Fehler im umgebenden Workflow, wie z.B. Tool-Timeouts oder Abruf-Fehler, korreliert mit dem LLM-Aufruf.

Klassischer Infra-Kontext

• Container-CPU-, Speicher- und Netzwerk-Metriken für die Dienste, die Ihre LLM-Aufrufe orchestrieren.
• Korrelierte Logs, die beschreiben, was die Anwendung zu tun versuchte.

Wenn Sie all dies an einem Ort sehen können, bewegt sich die LLM-Observability von Ich weiß, dass etwas langsam oder teuer ist zu Ich weiß genau, welches Modell, welches Prompt-Muster und welcher Dienst dafür verantwortlich sind und warum.

Wie kann Observability helfen, Teams stillschweigende Fehler wie Prompt-Drift, Halluzinationen oder allmähliche Verschlechterung der Ausgabe-Qualität zu erkennen?

Stillschweigende Fehler in LLM-Systemen treten normalerweise auf, wenn alles auf der Infrastruktur-Ebene grün aussieht, aber das tatsächliche Verhalten driftet. Observability hilft auf mehrere Weise:

• Die gesamte Workflow-Verfolgung, nicht nur den Modell-Aufruf – Durch die Erfassung des gesamten Pfads einer Anfrage von Client zu Dienst zu Abruf zu Modell zu Tools können Sie sehen, wo sich das Verhalten geändert hat. Zum Beispiel könnte der Abruf begonnen haben, weniger Dokumente zurückzugeben, oder ein Tool-Aufruf ist intermittierend fehlgeschlagen, und das Modell improvisiert.
• Prompts, Kontext und Antworten im Blick behalten – Wenn Sie Prompts und Antworten neben Spuren untersuchen können, wird es viel einfacher, Fälle zu erkennen, in denen eine neue Prompt-Version, eine neue System-Anweisung oder eine neue Kontext-Quelle das Verhalten geändert hat, obwohl die Latenz und die Fehler-Raten gleich geblieben sind.
• Filtern und Schneiden auf semantische Bedingungen – Sobald Sie reiche LLM-Telemetrie haben, können Sie auf Dinge wie Bedrock-Aufrufe über eine Sekunde, Anfragen, die dieses Modell-Familie verwenden, oder Spuren, die diese bestimmte Route involvieren, filtern, und dann die Prompts und Antworten lesen, um zu sehen, ob das Modell in einem bestimmten Szenario driftet oder halluziniert.
• Alarmieren auf Geschäfts-Level-SLOs – Sie können SLOs wie Jeder LLM-Aufruf über eine Sekunde verletzt unsere benutzerseitige SLA definieren und Alarme auslösen, wenn diese Bedingungen erfüllt sind. Im Laufe der Zeit können ähnliche SLOs an Qualitäts-Scores oder Richtlinien-Checks geknüpft werden, damit Sie alarmiert werden, wenn die Qualität verschlechtert, nicht nur, wenn die Infrastruktur fehlschlägt.

Weil die Observability-Ebene Zugriff auf AI-spezifische Signale und klassische Logs, Metriken und Spuren hat, wird sie zu einem natürlichen Ort, um Probleme zu erkennen, die ansonsten stillschweigend die Benutzer-Erfahrung verschlechtern würden.

Wie unterstützt groundcovers Ansatz die Diagnose unvorhersehbarer Latenz oder unerwarteten Verhaltens innerhalb von mehrstufigen Agent-Workflows und Tool-Aufrufen?

groundcover verwendet einen Ansatz, der für moderne AI-Systeme entwickelt wurde. Wir verwenden einen eBPF-basierten Sensor auf Kernel-Ebene, um den Datenverkehr über Microservices ohne Code-Änderungen oder Neu-Bereitstellungen zu beobachten. Sobald Sie einen LLM-Workflow einführen, können wir diese Aufrufe automatisch erkennen. Wenn Sie morgen ein neues Modell wie Anthropic, OpenAI oder Bedrock einführen, erfasst groundcover diesen Datenverkehr automatisch. Das gibt Ihnen:

• End-to-End-Spuren von mehrstufigen Workflows – Sie sehen den gesamten Pfad einer Anfrage über Dienste hinweg, einschließlich der Stellen, an denen ein LLM oder ein Tool verwendet wird.
• Tiefe Einblicke in jeden LLM-Aufruf – Jeder Aufruf enthält das verwendete Modell, die Latenz, die Token-Nutzung, die Prompts, die Antworten und die korrelierten Logs und Infra-Metriken.
• Leistungsstarke Filterung auf Latenz und Bedingungen – Zum Beispiel können Sie alle Claude-3.5-Aufrufe über eine Sekunde filtern und sofort die Spuren untersuchen, die Ihre SLA verletzt haben.
• Alarme und Dashboards, die an LLM-Verhalten geknüpft sind – Sobald die Daten verfügbar sind, können Sie Alarme für SLA-Verletzungen erstellen oder Dashboards aufbauen, die Latenz, Durchsatz, Token-Nutzung und Fehler verfolgen.

Weil alles am Rand durch eBPF erfasst und in Ihrem eigenen Cloud-System gespeichert wird, erhalten Sie diese hochgranulare Sicht ohne Instrumentierung innerhalb jedes Agents oder Tool-Aufrufs.

Welche Daten-Sicherheits- und Compliance-Risiken sehen Sie bei LLM-Deployments entstehen, und wie kann Observability diese Risiken reduzieren?

LLM-Deployments bringen einige einzigartige Daten-Risiken mit sich:

• Unbegrenzte Benutzereingaben – Benutzer können sehr sensible Informationen in Chatbots und AI-getriebene Schnittstellen eingeben. Das kann personenbezogene Daten, Kunden-Daten oder regulierte Informationen umfassen, die Sie nie sammeln wollten.
• Drittanbieter-Modelle – Sobald Sie diese Daten an einen externen LLM-Anbieter senden, sind Sie für die Daten verantwortlich, wo sie gespeichert werden und welche Anbieter sie sehen. Das hat große Auswirkungen auf die DSGVO, die Daten-Residenz und das Vertrauen der Kunden.
• Telemetrie als zweite Kopie sensibler Daten – Wenn Ihre Observability-Stack die vollständigen Payloads an einen SaaS-Anbieter sendet, haben Sie jetzt eine weitere Kopie dieser sensiblen Informationen, die außerhalb Ihrer Umgebung gespeichert sind.

groundcovers Architektur ist entwickelt, um genau diese Bedenken zu adressieren:

• Wir verwenden ein Bring-Your-Own-Cloud-Modell, bei dem die gesamte Observability-Backend in Ihrem Cloud-Konto innerhalb eines Sub-Kontos als vollständig verwaltete Daten-Ebene läuft. Die Steuer-Ebene, die sie skaliert und verwaltet, wird von uns betrieben, aber wir greifen nicht auf Ihre Telemetrie-Daten zu, speichern oder verarbeiten sie.
• Da wir Payloads in Ihrer eigenen Umgebung sicher erfassen können, können Sie Prompts, Antworten und Workflows ohne dass diese Daten jemals Ihre Cloud verlassen, beobachten.
• Mit dieser Sichtbarkeit können Sie sehen, wer was hochlädt und wohin es fließt, unerwartete Nutzung sensibler Daten erkennen und Richtlinien umsetzen, welche Modelle und Regionen erlaubt sind.

Mit anderen Worten wird Observability nicht nur zu einem Zuverlässigkeits- und Kosten-Tool, sondern auch zu einem wichtigen Kontroll-Punkt für Privatsphäre, Daten-Residenz und Compliance.

Wenn Organisationen von einer LLM-Integration zu vielen AI-getriebenen Diensten skalieren, welche operativen Herausforderungen treten normalerweise um Sichtbarkeit, Zuverlässigkeit und Kosten auf?

Die erste Integration ist normalerweise ein einzelnes Modell in einem einzelnen Workflow. Auf dieser Stufe fühlt sich alles noch überschaubar an. Sobald Teams den Wert sehen, explodiert die Nutzung und mehrere Herausforderungen treten auf:

• Modell- und Anbieter-Sprawl – Teams testen ständig neue Modelle. Es wird schnell unklar, welche Modelle in Produktion sind und wie sie verwendet werden.
• Cost-Surprises durch Token-Nutzung – Token-Verbrauch wächst mit Kontext-Länge und Workflow-Komplexität. Ohne Sichtbarkeit in die Token-Nutzung pro Modell und Workflow ist es sehr schwierig, Kosten zu verwalten.
• Zuverlässigkeits-Abhängigkeiten von externen Anbietern – Benutzer-seitige APIs werden empfindlich gegenüber Modell-Latenz oder Fehlern, die SLAs sogar dann stören können, wenn die Kern-Infrastruktur gesund ist.
• Wachsende Instrumentierungs-Schulden – Traditionelle Observability geht normalerweise davon aus, dass man Zeit hat, um Instrumentierung hinzuzufügen, wenn es benötigt wird. In schnelllebigen AI-Stacks haben Entwickler selten Zeit dafür.

groundcover adressiert diese durch die automatische Erkennung von AI-Datenverkehr und dann:

• Zentrale Sichtbarkeit in die verwendeten Modelle und Anbieter.
• Dashboards, die Latenz, Durchsatz und Token-Nutzung über die Zeit hinweg zeigen.
• Korrelation zwischen LLM-Verhalten und den Diensten, die davon abhängen.
• Alarme für AI-getriebene SLO-Verletzungen.

Das macht es viel einfacher, von einer coolen AI-Funktion zu AI, die in Dutzende kritischer Dienste eingebettet ist, zu skalieren, ohne die Kontrolle zu verlieren.

Wenn wir in die Zukunft blicken, wie erwarten Sie, dass LLM-Observability in den nächsten fünf Jahren evolviert, wenn agente AI, Multi-Modell-Orchestrierung und regulatorischer Druck beschleunigen?

Wir sind noch in den frühen Tagen. In den nächsten fünf Jahren erwarte ich einige große Verschiebungen:

• Von Anfrage-Ebene zu Agent-Ebene-Verständnis – Observability wird sich ausdehnen, um Tool-Sequenzen, Denkpfade und Wiederholungs-Logik zu erfassen, nicht nur Modell-Aufrufe.
• Reichere semantische und Richtlinien-Signale – Automatisierte Qualitäts-Checks für Halluzinationen, Sicherheits-Probleme und Marken-Übereinstimmung werden zu Standard-Metriken.
• Engere Kopplung mit Governance und Privatsphäre – Wenn die Regulierung wächst, wird Observability auch als Durchsetzungs- und Audit-Ebene für Daten-Residenz, -Aufbewahrung und genehmigte Modell-Nutzung dienen.
• Optimierung über Modelle und Anbieter hinweg – Teams werden Datenverkehr dynamisch über Modelle hinweg basierend auf Leistung und Kosten routen, angeleitet durch Echtzeit-Observability-Daten.
• Weniger manuelle Instrumentierung – Techniken wie eBPF-basierte Erfassung und Auto-Discovery werden zum Standard, damit Teams innovieren können, ohne zu verlangsamen.

Kurz gesagt wird LLM-Observability von nice to have-Dashboards für AI zu dem zentralen Nervensystem evolvieren, das Zuverlässigkeit, Kosten-Kontrolle, Daten-Governance und Produkt-Qualität über alles, was ein Unternehmen mit AI tut, verbindet.

Vielen Dank für das großartige Interview. Leser, die mehr erfahren möchten, sollten groundcover besuchen.