Shahar Azulay, CEO e cofundador da Groundcover.

Shahar Azulay, CEO e cofundador da Groundcover, Shahar é um líder serial em P&D. Ele traz consigo experiência no mundo da cibersegurança e aprendizado de máquina, tendo atuado 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: Física, Engenharia Elétrica e Ciência da Computação, obtidos no Technion (Instituto de Tecnologia de Israel) e na Universidade de Tel Aviv. Shahar busca utilizar o conhecimento tecnológico adquirido com essa sólida formação e aplicá-lo de forma inovadora e precisa no cenário atual da computação em nuvem, contribuindo para um mundo de desenvolvimento melhor.

cobertura do solo é uma plataforma de observabilidade nativa da nuvem, projetada para oferecer às equipes de engenharia visibilidade completa e em tempo real de seus sistemas, sem a complexidade ou o custo das ferramentas de monitoramento tradicionais. Construída com a tecnologia eBPF, ela coleta e correlaciona logs, métricas, rastreamentos e eventos em ambientes nativos da nuvem e Kubernetes sem alterações de código, permitindo análises de causa raiz mais rápidas e insights mais claros do sistema. A plataforma prioriza preços previsíveis, implantação flexível que mantém os dados na nuvem do cliente e observabilidade de ponta a ponta, abrangendo infraestrutura, aplicativos e cargas de trabalho modernas orientadas por IA.

Ao relembrar sua trajetória — desde liderar equipes de P&D cibernética no gabinete do primeiro-ministro israelense até gerenciar iniciativas de aprendizado de máquina na Apple — quais experiências o impulsionaram a fundar a Groundcover e quando você percebeu pela primeira vez a lacuna na observabilidade dos sistemas modernos de IA?

A motivação para fundar a Groundcover surgiu da minha experiência na Apple e na DayTwo. Mesmo com orçamentos enormes, nos víamos diante da escolha entre pagar uma fortuna para registrar tudo ou fazer amostragem e navegar às cegas. Naquela época, buscávamos uma tecnologia que resolvesse esse problema. Quando nos deparamos com o Extended Berkeley Packet Filter (eBPF), ficou claro que ele mudaria tudo. O eBPF nos permite ver tudo o que acontece no kernel sem depender de alterações nos aplicativos. Eu não conseguia entender por que as ferramentas de observabilidade não aproveitavam isso. A lacuna na IA ficou evidente mais tarde. Assim que nossa plataforma Kubernetes amadureceu, vimos clientes migrando rapidamente para implantações de GenAI enquanto tratavam os LLMs como caixas-pretas. Eles sabiam que o modelo respondia, mas não entendiam por que ele se comportava de forma imprevisível ou por que os custos estavam disparando. Percebemos que os fluxos de trabalho agentivos são simplesmente microsserviços complexos e não determinísticos que precisam da mesma visibilidade automatizada que já havíamos construído.

De que forma sua experiência em cibersegurança, sistemas embarcados e P&D de aprendizado de máquina influenciou a visão por trás da Groundcover, e quais foram os primeiros desafios que você enfrentou ao construir uma empresa focada em observabilidade para aplicações orientadas por LLM e agentes?

Minha experiência em cibersegurança moldou o DNA da empresa. No mundo da inteligência artificial, parte-se do princípio de que você não controla a aplicação. Essa abordagem explica por que o Groundcover não exige instrumentação. Sei por experiência própria que pedir aos desenvolvedores para modificar o código é a maneira mais rápida de bloquear a adoção. O maior desafio inicial com o monitoramento de LLM foi a privacidade. A observabilidade para IA captura prompts que podem conter informações pessoais identificáveis ​​(PII) ou propriedade intelectual (IP) sensíveis. Minha experiência deixou claro que as empresas não gostariam que esses dados saíssem de seu ambiente. É por isso que construímos nossa arquitetura em nuvem, permitindo-nos fornecer visibilidade profunda do comportamento do agente, mantendo todos os dados dentro do ambiente do cliente.

Como você define observabilidade LLM e o que a diferencia do monitoramento tradicional ou do monitoramento por aprendizado de máquina?

A observabilidade de modelos de linguagem de grande porte (LLM, na sigla em inglês) é a prática de instrumentar e monitorar sistemas de produção que utilizam grandes modelos de linguagem, permitindo capturar o contexto completo de cada inferência: o prompt, o contexto, a conclusão, o uso de tokens, a latência, os erros, os metadados do modelo e, idealmente, o feedback ou os sinais de qualidade subsequentes. Em vez de apenas perguntar "O serviço está funcionando e rápido?" ou "Esta solicitação apresentou erro?", a observabilidade de LLM ajuda a responder perguntas como "Por que esta solicitação específica foi bem-sucedida ou falhou?", "O que realmente aconteceu dentro deste fluxo de trabalho de várias etapas?" e "Como as alterações nos prompts, no contexto ou nas versões do modelo estão afetando o custo, a latência e a qualidade da saída?". Isso é muito diferente do monitoramento tradicional ou mesmo do monitoramento clássico de aprendizado de máquina. As abordagens legadas são otimizadas para sistemas determinísticos, métricas de infraestrutura e limites estáticos. Os aplicativos de LLM são não determinísticos, abertos e altamente dependentes do contexto. O sucesso é frequentemente semântico e subjetivo, não se limitando a um código de status 200 ou 500. Isso significa que você precisa rastrear entradas e saídas, entender as chamadas de ferramentas e as etapas de recuperação, avaliar as respostas em busca de problemas como alucinações ou violações de políticas e conectar os custos e atrasos em nível de token ao aplicativo e à infraestrutura circundantes.

Que desafios introduzem as aplicações baseadas em LLM que tornam as ferramentas de observabilidade tradicionais insuficientes?

Os sistemas baseados em LLM apresentam diversos desafios que expõem as limitações das ferramentas tradicionais:

• Fluxos de trabalho complexos e multietapas Passamos de fluxos simples de "chamar um modelo e obter uma resposta" para agentes com múltiplas interações, pipelines com várias 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 comprometer toda a experiência. O monitoramento tradicional geralmente não oferece uma visão completa e detalhada dessas cadeias, incluindo prompts e respostas.
• Plataformas de IA em rápida evolução – As equipes estão adicionando novos modelos, ferramentas e fornecedores em um ritmo sem precedentes. Em muitas empresas, ninguém consegue listar com certeza quais modelos estão em produção em um determinado momento. A observabilidade clássica geralmente pressupõe que você tenha tempo para instrumentar SDKs, reimplantá-los e selecionar cuidadosamente o que você mede. Isso simplesmente não acompanha a velocidade com que a IA está sendo adotada.
• Economia baseada em tokens e quotas – Os preços e limites de taxa estão vinculados a tokens e ao comprimento do contexto, que geralmente são 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 consumiu quantos tokens em qual modelo, para qual fluxo de trabalho e com qual latência".
• Correção semântica em vez de sucesso binário Um usuário de LLM pode retornar um código 200 e ainda assim ter alucinações, se desviar das instruções ou violar as políticas. As ferramentas tradicionais consideram isso um sucesso. Você precisa de observabilidade que revele instruções e respostas e forneça contexto suficiente para inspecionar o comportamento e, com o tempo, implementar verificações de qualidade automatizadas.
• Dados de entrada sensíveis sendo repassados ​​a terceiros – Os LLMs convidam os usuários a compartilhar informações muito sensíveis por meio de interfaces de bate-papo. Agora você é responsável por esses dados, onde eles são armazenados e quais fornecedores têm acesso a eles. A observabilidade convencional baseada em SaaS, que envia toda a telemetria para terceiros, geralmente é inaceitável para essas cargas de trabalho.

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

Quais sinais ou métricas são mais importantes para entender o desempenho e a qualidade dos sistemas LLM, incluindo latência, uso de tokens e comportamento de solicitação/resposta?

Existem algumas categorias de sinais que são muito importantes na prática:

Latência e taxa de transferência

• Latência de ponta a ponta por solicitação, incluindo o tempo do modelo e o tempo de aplicação adjacente.
• Latências de cauda (P90, P95, P99) por modelo e por fluxo de trabalho.
• Taxa de transferência por modelo, rota e serviço, para que você saiba para onde a carga está realmente indo.

Utilização de tokens e fatores de custo

• Tokens de entrada e saída por solicitação, discriminados por modelo.
• Utilização agregada de tokens ao longo do tempo por modelo, equipe, usuário e fluxo de trabalho.
• Tamanhos de contexto para pipelines com grande volume de recuperação de dados, para que você possa ver quando os prompts estão se tornando excessivos.
• É isso que permite responder à pergunta: "Quem está realmente gastando nosso orçamento de IA e em quê?"

Comportamento de resposta e prontidão

• Os payloads reais de prompt e resposta em rastreamentos representativos, incluindo chamadas de ferramentas e caminhos de raciocínio.
• Quais ferramentas o LLM optou por utilizar e em que sequência?
• A variação nas respostas a estímulos semelhantes permite avaliar a estabilidade do comportamento.

Confiabilidade e erros

• Taxas e tipos de erros específicos do modelo (erros do provedor, tempos limite, problemas de autenticação, erros de cota).
• Falhas no fluxo de trabalho adjacente, como timeouts de ferramentas ou erros de recuperação, estavam correlacionadas com a chamada LLM.

Contexto clássico de infraestrutura

• Métricas de CPU, memória e rede do contêiner para os serviços que orquestram suas chamadas LLM.
• Registros correlacionados que descrevem o que o aplicativo estava tentando fazer.

Quando você consegue visualizar tudo isso em um só lugar, a observabilidade do LLM passa de "Eu sei que algo é lento ou caro" para "Eu sei exatamente qual modelo, padrão de solicitação e serviço são responsáveis ​​e por quê".

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

Falhas silenciosas em sistemas LLM geralmente ocorrem quando tudo parece "verde" no nível da infraestrutura, mas o comportamento real está se desviando do esperado. A observabilidade ajuda de algumas maneiras:

• Rastrear todo o fluxo de trabalho, não apenas a chamada do modelo. Ao capturar todo o caminho de uma requisição, desde o cliente até o serviço, passando pela recuperação, pelo modelo e pelas ferramentas, você consegue identificar onde o comportamento mudou. Por exemplo, talvez a recuperação tenha começado a retornar menos documentos, ou uma chamada de ferramenta esteja falhando intermitentemente, e o modelo esteja improvisando.
• Tendo em vista as instruções, o contexto e as respostas. – Quando você consegue inspecionar prompts e respostas juntamente com os rastreamentos, 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 alterou o comportamento, mesmo que a latência e as taxas de erro tenham permanecido as mesmas.
• Filtragem e segmentação com base em condições semânticas. – Depois de obter uma telemetria LLM completa, você pode filtrar itens como "chamadas ao bedrock em mais de um segundo", "solicitações usando esta família de modelos" ou "rastreamentos envolvendo esta rota específica" e, em seguida, ler os prompts e as respostas para verificar se o modelo está apresentando comportamentos instáveis ​​ou alucinatórios em um cenário específico.
• Alertas sobre SLOs de nível empresarial Você pode definir SLOs como "qualquer chamada LLM com duração superior a um segundo viola nosso SLA voltado para o usuário" e acionar alertas quando essas condições forem atendidas. Com o tempo, SLOs semelhantes podem ser vinculados a pontuações de qualidade ou verificações de políticas, para que você seja alertado quando a qualidade se degradar, e não apenas quando a infraestrutura falhar.

Como a camada de observabilidade tem acesso tanto aos sinais específicos da IA ​​quanto aos registros, métricas e rastreamentos clássicos, ela se torna um local natural para detectar problemas que, de outra forma, degradariam silenciosamente a experiência do usuário.

Como a abordagem do Groundcover auxilia no diagnóstico de latência imprevisível ou comportamento inesperado em fluxos de trabalho de agentes com várias etapas e chamadas de ferramentas?

O Groundcover adota uma abordagem projetada para sistemas de IA modernos. Usamos um sensor baseado em eBPF no nível do kernel para observar o tráfego entre microsserviços sem alterações de código ou reimplantações. Assim que você introduz um fluxo de trabalho LLM, podemos descobrir automaticamente essas chamadas. Se você começar a usar um novo modelo como Anthropic, OpenAI ou Bedrock amanhã, o Groundcover captura esse tráfego automaticamente. Isso lhe proporciona:

• Rastreamento completo de fluxos de trabalho com múltiplas etapas – Você consegue visualizar todo o percurso de uma solicitação entre os serviços, incluindo onde um LLM ou ferramenta é utilizado.
• Contexto detalhado em cada chamada do LLM – Cada chamada inclui o modelo utilizado, a latência, o uso de tokens, as solicitações, as respostas e os logs e métricas de infraestrutura correlacionados.
• Filtragem poderosa com base na latência e nas condições. – Por exemplo, você pode filtrar todas as chamadas do Claude 3.5 com duração superior a um segundo e inspecionar imediatamente os registros que violaram seu SLA.
• Alertas e painéis de controle vinculados ao comportamento do usuário no LLM – Assim que os dados estiverem disponíveis, você poderá criar alertas para violações de SLA ou construir painéis que monitorem latência, taxa de transferência, uso de tokens e erros.

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

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

As implementações de LLM trazem alguns riscos de dados exclusivos:

• Entrada de usuário ilimitada – Os usuários podem digitar informações extremamente sensíveis em chatbots e interfaces com inteligência artificial. Isso pode incluir dados pessoais, dados de clientes ou informações regulamentadas que você nunca teve a intenção de coletar.
• Fornecedores de modelos de terceiros – Depois de enviar esses dados para um provedor externo de serviços de gestão de dados (LLM), você se torna responsável por onde eles foram parar, como são armazenados e quais subcontratados estão envolvidos. Isso tem implicações importantes para o GDPR, a residência de dados e a confiança do cliente.
• Telemetria como segunda cópia de dados sensíveis – Se sua pilha de observabilidade enviar payloads completos para um fornecedor de SaaS, você terá agora outra cópia dessas informações confidenciais fora do seu ambiente.

A arquitetura do Groundcover foi projetada para abordar exatamente essas preocupações:

• Utilizamos um modelo de nuvem própria (BYON), no qual todo o backend de observabilidade é executado dentro da sua conta na 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.
• Como podemos capturar dados com segurança em seu próprio ambiente, você pode observar solicitações, respostas e fluxos de trabalho sem que esses dados saiam da sua nuvem. Não há armazenamento de terceiros para seus rastreamentos LLM nem necessidade de se preocupar com a saída adicional de dados.
• Com essa visibilidade, você pode ver quem está enviando o quê e para onde o fluxo de dados vai, detectar o uso inesperado de dados sensíveis e aplicar políticas sobre quais modelos e regiões são permitidos.

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

À medida que as organizações expandem de uma única integração de LLM para vários serviços baseados em IA, quais desafios operacionais tendem a surgir em relação à visibilidade, confiabilidade e custo?

A primeira integração geralmente envolve um único modelo em um único fluxo de trabalho. Nessa fase, tudo parece administrável. Assim que as equipes percebem o valor, o uso explode e vários desafios surgem:

• Proliferação de modelos e fornecedores – As equipes testam novos modelos constantemente. Rapidamente fica difícil entender quais estão em produção e como estão sendo usados.
• Surpresas de custo decorrentes do uso de tokens O consumo de tokens aumenta com o comprimento do contexto e a complexidade do fluxo de trabalho. Sem visibilidade do uso de tokens por modelo e fluxo de trabalho, o gerenciamento de custos torna-se muito difícil.
• Dependências de confiabilidade em fornecedores externos – As APIs voltadas para o usuário tornam-se sensíveis à latência ou a erros do modelo, o que pode interromper os SLAs mesmo quando a infraestrutura principal está funcionando corretamente.
• Dívida crescente de instrumentação – A observabilidade tradicional pressupõe que você possa adicionar instrumentação quando necessário. Em ambientes de IA de rápida evolução, os desenvolvedores raramente têm tempo para isso.

O Groundcover resolve esses problemas descobrindo automaticamente o tráfego de IA e, em seguida, fornecendo a você:

• Visibilidade centralizada dos modelos e fornecedores utilizados.
• Painéis que mostram a latência, a taxa de transferência e o uso de tokens ao longo do tempo.
• Correlação entre o comportamento do LLM e os serviços que dependem dele.
• Alertas para violações de SLOs impulsionados por IA.

Isso torna muito mais fácil escalar de "um recurso de IA interessante" para "IA integrada em dezenas de serviços críticos" sem perder o controle.

Olhando para o futuro, como você espera que a observabilidade de modelos de longo prazo (LLM) evolua nos próximos cinco anos, à medida que a IA ativa, a orquestração multimodelos e as pressões regulatórias se intensificam?

Ainda estamos nos estágios iniciais. Nos próximos cinco anos, espero algumas grandes mudanças:

• Desde o nível de solicitação até o nível de agente, compreendendo tudo. – A observabilidade será expandida para capturar sequências de ferramentas, caminhos de raciocínio e lógica de repetição, e não apenas chamadas de modelo.
• Sinais semânticos e de política mais ricos – As verificações automatizadas de qualidade para alucinações, problemas de segurança e alinhamento com a marca se tornarão métricas padrão.
• Maior integração com a governança e a privacidade. – À medida que a regulamentação se expande, a observabilidade também servirá como uma camada de fiscalização e auditoria para residência de dados, retenção e uso de modelos aprovados.
• Otimização cruzada de modelos e múltiplos fornecedores – As equipes irão rotear o tráfego entre os modelos dinamicamente, com base no desempenho e no custo, guiadas por dados de observabilidade em tempo real.
• Menos instrumentação manual – Técnicas como a coleta baseada em eBPF e a descoberta automática se tornarão o padrão, permitindo que as equipes inovem sem perder o ritmo.

Resumindo, a observabilidade do LLM evoluirá de "painéis de controle interessantes para IA" para o sistema nervoso central que conecta confiabilidade, controle de custos, governança de dados e qualidade do produto em tudo o que uma organização faz com IA.

Obrigado pela ótima entrevista, os leitores que desejam saber mais devem visitar cobertura do solo.