Shahar Azulay, CEO e Co-Fundador da groundcover

Shahar Azulay, CEO e co-fundador da groundcover é um líder de R&D em série. Shahar traz experiência no mundo da cibersegurança e do aprendizado de máquina, tendo trabalhado como líder em empresas como Apple, DayTwo e Cymotive Technologies. Shahar passou muitos anos na Divisão de Cibersegurança do Gabinete do Primeiro-Ministro de Israel e possui três diplomas em Física, Engenharia Elétrica e Ciência da Computação do Instituto de Tecnologia de Israel, bem como da Universidade de Tel Aviv. Shahar busca usar os conhecimentos tecnológicos dessa rica formação e trazê-los para o campo de batalha nativo em nuvem de hoje, na forma mais inovadora e afiada, para tornar o mundo do desenvolvimento melhor.

groundcover é uma plataforma de observabilidade nativa em nuvem projetada para fornecer às equipes de engenharia visibilidade completa e em tempo real dos seus sistemas, sem a complexidade ou o custo de ferramentas de monitoramento tradicionais. Construída com tecnologia eBPF, ela coleta e correlaciona logs, métricas, rastreios e eventos em ambientes nativos em nuvem e Kubernetes, sem alterações de código, permitindo uma análise de causa raiz mais rápida e uma visão mais clara do sistema. A plataforma enfatiza preços previsíveis, implantação flexível que mantém os dados na nuvem do cliente e observabilidade de ponta a ponta que abrange infraestrutura, aplicações e cargas de trabalho modernas impulsionadas por IA.

Olhando para trás, em sua jornada – desde liderar equipes de R&D em cibersegurança no Gabinete do Primeiro-Ministro de Israel até gerenciar iniciativas de ML na Apple – quais experiências finalmente o impulsionaram a fundar a groundcover, e quando você primeiro reconheceu a lacuna na observabilidade para sistemas de IA modernos?

O impulso para fundar a groundcover veio do meu tempo na Apple e DayTwo. Mesmo com orçamentos enormes, estávamos presos escolhendo entre pagar uma fortuna para registrar tudo ou amostrar e voar cegamente. Naquela época, estávamos procurando por uma tecnologia que resolvesse isso. Assim que encontramos o Extended Berkeley Packet Filter (eBPF), ficou claro que mudaria tudo. O eBPF nos permite ver tudo o que acontece no kernel sem depender de alterações de aplicativos. Eu não conseguia entender por que as ferramentas de observabilidade não estavam aproveitando isso. A lacuna em IA se tornou clara mais tarde. Assim que nossa plataforma Kubernetes amadureceu, vimos os clientes se apressando para implantações de GenAI, tratando LLMs como caixas pretas. Eles sabiam que o modelo respondia, mas não por quê se comportava de forma imprevisível ou por que os custos estavam aumentando. Percebemos que os fluxos de trabalho agênticos são simplesmente microserviços complexos e não determinísticos que precisam da mesma visibilidade sem toque que já havíamos construído.

Como sua formação em cibersegurança, sistemas embarcados e R&D de ML influenciou a visão por trás da groundcover, e quais desafios iniciais você enfrentou ao construir uma empresa centrada na observabilidade para aplicações LLM e agênticas?

Minha formação em cibersegurança moldou o DNA da empresa. No mundo da inteligência, você assume que não controla o aplicativo. Essa abordagem é o motivo pelo qual a groundcover não requer instrumentação. Eu sei por experiência que pedir aos desenvolvedores que modifiquem o código é a maneira mais rápida de bloquear a adoção. O desafio mais difícil no início com o monitoramento de LLM foi a privacidade. A observabilidade para IA captura prompts que podem conter informações de identificação pessoal (PII) ou propriedade intelectual (IP) sensíveis. Minha formação tornou óbvio que as empresas não queriam que esses dados deixassem o ambiente. É por isso que construímos nossa arquitetura em nuvem, permitindo-nos fornecer visibilidade profunda sobre o comportamento do agente, mantendo todos os dados dentro do ambiente do cliente.

Como você define a observabilidade de LLM, e o que a torna diferente do monitoramento tradicional ou do monitoramento de ML?

A observabilidade de LLM é a prática de instrumentar e monitorar sistemas de produção que usam grandes modelos de linguagem para capturar o contexto completo de cada inferência: o prompt, contexto, conclusão, uso de token, latency, erros, metadados do modelo e, idealmente, feedback ou sinais de qualidade downstream. Em vez de apenas perguntar “O serviço está funcionando e rápido?” ou “Essa solicitação resultou em erro?”, a observabilidade de LLM ajuda a responder a perguntas como “Por que essa solicitação específica teve sucesso ou falhou?”, “O que realmente aconteceu dentro desse fluxo de trabalho de múltiplos passos?” e “Como as alterações nos prompts, contexto ou versões do modelo afetam o custo, a latency e a qualidade de saída?” Isso é muito diferente do monitoramento tradicional ou mesmo do monitoramento de ML clássico. As abordagens legadas são ajustadas para sistemas determinísticos, métricas de infraestrutura e limites estáticos. As aplicações de LLM são não determinísticas, abertas e altamente dependentes do contexto. O sucesso é frequentemente semântico e subjetivo, não apenas um código de status 200 vs 500. Isso significa que você precisa rastrear entradas e saídas, entender chamadas de ferramentas e etapas de recuperação, avaliar respostas para coisas como alucinações ou violações de política e conectar custos e atrasos de token de volta à aplicação e infraestrutura circundantes.

Quais desafios as aplicações impulsionadas por LLM introduzem que tornam as ferramentas de observabilidade tradicionais insuficientes?

Os sistemas impulsionados por LLM introduzem vários desafios que expõem os limites das ferramentas tradicionais:

• Fluxos de trabalho complexos e multi-etapas – Mudamos de fluxos simples “chamar um modelo, obter uma resposta” para agentes multi-turnos, pipelines multi-etapas, geração aumentada por recuperação e uso de ferramentas. Uma falha silenciosa em qualquer uma dessas etapas, como recuperação, enriquecimento, incorporação, chamada de ferramenta ou chamada de modelo, pode quebrar a experiência toda. O monitoramento tradicional geralmente não fornece uma visão completa e de nível de rastreamento dessas cadeias com prompts e respostas incluídas.
• Pilhas de IA em evolução rápida – As equipes estão adicionando novos modelos, ferramentas e fornecedores a um ritmo que nunca viram antes. Em muitas empresas, ninguém pode confiantemente listar quais modelos estão em produção a qualquer momento. A observabilidade clássica geralmente assume que você tem tempo para instrumentar SDKs, reimplantar e cuidadosamente curar o que medir. Isso simplesmente não acompanha a velocidade com que a IA está sendo adotada.
• Economia e cotas baseadas em token – Preços e limites de taxa estão vinculados a tokens e comprimento de contexto, que são frequentemente controlados por desenvolvedores, prompts ou comportamento do usuário, e não por operações centrais. As ferramentas tradicionais não são projetadas para mostrar “quem queimou quantos tokens em qual modelo, para qual fluxo de trabalho, com que latency”.
• Correção semântica em vez de sucesso binário – Um LLM pode retornar um 200 e ainda alucinar, desviar do seu prompt ou violar política. As ferramentas tradicionais veem isso como um sucesso. Você precisa de observabilidade que possa superfície prompts e respostas e dar a você contexto suficiente para inspecionar o comportamento e, ao longo do tempo, conectar verificações de qualidade automatizadas.
• Dados de entrada sensíveis fluindo para terceiros – Os LLMs convidam os usuários a compartilhar informações extremamente sensíveis por meio de interfaces de estilo de chat. Agora você é responsável por esses dados, onde eles são armazenados e quais fornecedores os veem. A observabilidade SaaS convencional que envia toda a telemetria para um terceiro é frequentemente inaceitável para essas cargas de trabalho.

Tudo isso significa que os sistemas de LLM exigem observabilidade que seja consciente de IA, rica em contexto e muito menos dependente de instrumentação manual do que as ferramentas que a maioria das equipes usa hoje.

Quais sinais ou métricas são mais importantes para entender o desempenho e a qualidade dos sistemas de LLM, incluindo latency, uso de token e comportamento de prompt/resposta?

Há algumas categorias de sinais que importam muito na prática:

Latency e throughput

• Latency de ponta a ponta por solicitação, incluindo tempo de modelo e tempo de aplicação circundante.
• Latencies de cauda (P90, P95, P99) por modelo e por fluxo de trabalho.
• Throughput por modelo, rota e serviço, para que você saiba onde a carga está realmente indo.

Uso de token e drivers de custo

• Tokens de entrada e saída por solicitação, divididos por modelo.
• Uso de token agregado ao longo do tempo por modelo, equipe, usuário e fluxo de trabalho.
• Tamanhos de contexto para pipelines pesados de recuperação para que você possa ver quando os prompts estão explodindo.
• Isso é o que permite responder “Quem está realmente gastando nosso orçamento de IA e em quê?”

Comportamento de prompt e resposta

• As cargas reais de prompt e resposta em traços representativos, incluindo chamadas de ferramentas e caminhos de raciocínio.
• Quais ferramentas o LLM escolheu chamar e em qual sequência.
• Variação em respostas para prompts semelhantes para que você possa dizer como estável é o comportamento.

Confiabilidade e erros

• Taxas de erro e tipos de modelo específicos (erros de provedor, timeouts, problemas de autenticação, erros de quota).
• Falhas no fluxo de trabalho circundante, como timeouts de ferramentas ou erros de recuperação, correlacionados com a chamada de LLM.

Contexto de infra clássico

• Métricas de CPU, memória e rede de contêiner para os serviços que orquestram as chamadas de LLM.
• Logs correlacionados que descrevem o que a aplicação estava tentando fazer.

Quando você pode ver tudo isso em um lugar, a observabilidade de LLM muda de “Eu sei que algo está lento ou caro” para “Eu sei exatamente qual modelo, padrão de prompt e serviço são responsáveis e por quê”.

Como a observabilidade pode ajudar as equipes a detectar falhas silenciosas, como drift de prompt, alucinações ou degradação gradual na qualidade de saída?

As falhas silenciosas nos sistemas de LLM geralmente acontecem quando tudo parece “verde” no nível de infraestrutura, mas o comportamento real está se desviando. A observabilidade ajuda de algumas maneiras:

• Rastreando o fluxo de trabalho completo, não apenas a chamada de modelo – Ao capturar o caminho completo de uma solicitação do cliente para o serviço, para a recuperação, para o modelo, para as ferramentas, você pode ver onde o comportamento mudou. Por exemplo, talvez a recuperação começou a retornar menos documentos, ou uma chamada de ferramenta está falhando intermitentemente, e o modelo está improvisando.
• Mantendo prompts, contexto e respostas em vista – Quando você pode inspecionar prompts e respostas ao lado de traços, fica muito mais fácil identificar casos em que uma nova versão de prompt, uma nova instrução do sistema ou uma nova fonte de contexto mudou o comportamento, mesmo que a latency e as taxas de erro tenham permanecido as mesmas.
• Filtrando e fatiando em condições semânticas – Uma vez que você tem telemetria de LLM rica, você pode filtrar para coisas como “chamadas de bedrock com mais de um segundo”, “solicitações usando essa família de modelo” ou “traços envolvendo essa rota específica”, então leia os prompts e respostas para ver se o modelo está se desviando ou alucinando em um cenário específico.
• Alertando em SLOs de nível de negócios – Você pode definir SLOs como “qualquer chamada de LLM com mais de um segundo viola nossa SLA de interface do usuário” e acionar alertas quando essas condições são atendidas. Com o tempo, SLOs semelhantes podem ser vinculados a pontuações de qualidade ou verificações de política para que você seja alertado quando a qualidade se degrada, não apenas quando a infraestrutura falha.

Porque a camada de observabilidade tem acesso a sinais específicos de IA e logs, métricas e traços clássicos, ela se torna um local natural para capturar problemas que de outra forma degradariam silenciosamente a experiência do usuário.

Como a abordagem da groundcover apoia o diagnóstico de latency imprevisível ou comportamento inesperado dentro de fluxos de trabalho de agente multi-etapas e chamadas de ferramenta?

A groundcover adota uma abordagem projetada para sistemas de IA modernos. Nós usamos um sensor baseado em eBPF no nível do kernel para observar o tráfego entre microserviços sem alterações de código ou reimplantações. Assim que você introduz um fluxo de trabalho de LLM, podemos descobri-lo automaticamente. Se você começar a usar um novo modelo como o Anthropic, OpenAI ou Bedrock amanhã, a groundcover captura esse tráfego automaticamente. Isso lhe dá:

• Rastreios de ponta a ponta de fluxos de trabalho de multi-hop – Você vê o caminho completo de uma solicitação através dos serviços, incluindo onde um LLM ou ferramenta é usada.
• Contexto profundo em cada chamada de LLM – Cada chamada inclui o modelo usado, latency, uso de token, prompts, respostas e logs e métricas de infra correlacionados.
• Filtragem poderosa em latency e condições – Por exemplo, você pode filtrar todas as chamadas de Claude 3.5 com mais de um segundo e inspecionar imediatamente os traços que violaram sua SLA.
• Alertas e painéis vinculados ao comportamento de LLM – Uma vez que os dados estão disponíveis, você pode criar alertas para violações de SLA ou construir painéis que rastreiam latency, throughput, uso de token e erros.

Porque tudo é coletado na borda pelo eBPF e armazenado na sua própria nuvem, você obtém uma visão de granularidade alta sem adicionar instrumentação dentro de cada agente ou chamada de ferramenta.

Quais riscos de segurança de dados e conformidade você vê surgindo em implantações de LLM, e como a observabilidade pode ajudar a reduzir esses riscos?

As implantações de LLM trazem alguns riscos de dados únicos:

• Entrada de usuário ilimitada – Os usuários podem digitar informações extremamente sensíveis em interfaces de estilo de chat e IA. Isso pode incluir dados pessoais, dados do cliente ou informações regulamentadas que você nunca pretendia coletar.
• Fornecedores de modelo de terceiros – Uma vez que você envia esses dados para um provedor de LLM externo, você é responsável por onde eles foram, como são armazenados e quais subprocessadores estão envolvidos. Isso tem implicações significativas para a GDPR, residência de dados e confiança do cliente.
• Telemetria como uma segunda cópia de dados sensíveis – Se a pilha de observabilidade do seu SaaS enviar payloads completos para um fornecedor de terceiros, você agora tem outra cópia dessas informações sensíveis fora do seu ambiente.

A arquitetura da groundcover é projetada para abordar exatamente essas preocupações:

• Nós usamos um modelo de traga sua própria nuvem, onde o backend de observabilidade completo é executado dentro da sua conta de nuvem, em uma subconta, como um plano de dados totalmente gerenciado. O plano de controle que o dimensiona e gerencia é executado por nós, mas não acessamos, armazenamos ou processamos seus dados de telemetria.
• Porque podemos capturar payloads com segurança no seu próprio ambiente, você pode observar prompts, respostas e fluxos de trabalho sem que esses dados jamais deixem sua nuvem. Não há armazenamento de terceiros para os traços de LLM e não há egresso de dados extra com o qual se preocupar.
• Com essa visibilidade, você pode ver quem está carregando o que e para onde flui, detectar uso inesperado de dados sensíveis e aplicar políticas sobre quais modelos e regiões são permitidas.

Em resumo, a observabilidade se torna não apenas uma ferramenta de confiabilidade e custo, mas também um ponto de controle-chave para privacidade, residência de dados e conformidade.

À medida que as organizações escalam de uma integração de LLM para muitos serviços impulsionados por IA, quais desafios operacionais tendem a aparecer em torno de visibilidade, confiabilidade e custo?

A primeira integração geralmente é um modelo único em um fluxo de trabalho único. Nessa etapa, as coisas parecem gerenciáveis. Assim que as equipes veem o valor, o uso explode e vários desafios aparecem:

• Propagação de modelo e fornecedor – As equipes testam novos modelos constantemente. Logo se torna incerto quais modelos estão em produção e como são usados.
• Surpresas de custo devido ao uso de token – O consumo de token cresce com o comprimento do contexto e a complexidade do fluxo de trabalho. Sem visibilidade no uso de token por modelo e fluxo de trabalho, gerenciar custos é muito difícil.
• Dependências de confiabilidade em provedores externos – As APIs de interface do usuário se tornam sensíveis à latency do modelo ou erros, o que pode interromper os SLAs, mesmo que a infraestrutura central esteja saudável.
• Crescimento da dívida de instrumentação – A observabilidade tradicional assume que você pode adicionar instrumentação quando necessário. Nas pilhas de IA em movimento rápido, os desenvolvedores raramente têm tempo para isso.

A groundcover aborda esses desafios fornecendo:

• Visibilidade centralizada sobre quais modelos e fornecedores são usados.
• Painéis mostrando latency, throughput e uso de token ao longo do tempo.
• Correlação entre o comportamento de LLM e os serviços que dependem dele.
• Alertas para violações de SLO impulsionadas por IA.

Isso torna muito mais fácil escalar de “um recurso de IA legal” para “IA é tecida em dezenas de serviços críticos” sem perder o controle.

Olhando para o futuro, como você espera que a observabilidade de LLM evolua nos próximos cinco anos, à medida que a IA agêntica, a orquestração de multi-modelo e as pressões regulamentares aceleram?

Estamos ainda nos dias iniciais. Nos próximos cinco anos, eu espero alguns grandes deslocamentos:

• Do nível de solicitação para o nível de agente de compreensão – A observabilidade se expandirá para capturar sequências de ferramentas, caminhos de raciocínio e lógica de retry, não apenas chamadas de modelo.
• Sinais semânticos e de política mais ricos – Verificações de qualidade automatizadas para alucinações, questões de segurança e alinhamento de marca se tornarão métricas padrão.
• Vinculação mais apertada com governança e privacidade – À medida que a regulamentação cresce, a observabilidade também servirá como uma camada de aplicação e auditoria para residência de dados, retenção e uso de modelo aprovado.
• Otimização de multi-modelo e multi-fornecedor – As equipes rotearão tráfego dinamicamente entre modelos com base no desempenho e no custo, guiadas por dados de observabilidade em tempo real.
• Menos instrumentação manual – Técnicas como coleta baseada em eBPF e autodescoberta se tornarão o padrão, para que as equipes possam inovar sem desacelerar.

Em resumo, a observabilidade de LLM evoluirá de “ter dashboards legais para IA” para o sistema nervoso central que conecta confiabilidade, controle de custo, governança de dados e qualidade de produto em tudo o que uma organização faz com IA.

Obrigado pela grande entrevista, leitores que desejam aprender mais devem visitar groundcover.