Shahar Azulay, CEO y cofundador de groundcover

Shahar Azulay, CEO y cofundador de groundcover es un líder de I+D en serie. Shahar aporta experiencia en el mundo de la ciberseguridad y el aprendizaje automático, habiendo trabajado como líder en empresas como Apple, DayTwo y Cymotive Technologies. Shahar pasó muchos años en la división de ciberseguridad de la Oficina del Primer Ministro de Israel y tiene tres títulos en Física, Ingeniería Eléctrica y Ciencias de la Computación del Instituto de Tecnología de Israel y la Universidad de Tel Aviv. Shahar se esfuerza por utilizar los conocimientos tecnológicos de este rico trasfondo y llevarlos al campo de batalla de la nube nativa de hoy en día en la forma más innovadora y afilada posible para hacer del mundo del desarrollo una mejor lugar.

groundcover es una plataforma de observabilidad nativa en la nube diseñada para brindar a los equipos de ingeniería una visibilidad completa y en tiempo real de sus sistemas sin la complejidad ni el costo de las herramientas de monitoreo tradicionales. Construida sobre la tecnología eBPF, recopila y correlaciona registros, métricas, trazas y eventos en entornos nativos en la nube y Kubernetes sin cambios de código, lo que permite un análisis de causa raíz más rápido y una comprensión del sistema más clara. La plataforma enfatiza la facturación predecible, la implementación flexible que mantiene los datos en la nube del cliente y la observabilidad de extremo a extremo que abarca la infraestructura, las aplicaciones y las cargas de trabajo modernas impulsadas por IA.

Al mirar hacia atrás en su viaje, desde liderar equipos de I+D en ciberseguridad en la Oficina del Primer Ministro de Israel hasta gestionar iniciativas de aprendizaje automático en Apple, ¿qué experiencias finalmente lo llevaron a fundar groundcover, y cuándo reconoció la brecha en la observabilidad para sistemas de IA modernos?

El impulso para fundar groundcover provino de mi tiempo en Apple y DayTwo. Incluso con presupuestos enormes, nos vimos obligados a elegir entre pagar una fortuna para registrar todo o muestrear y volar a ciegas. En ese momento, estábamos buscando una tecnología que resolviera ese problema. Una vez que nos encontramos con el Extended Berkeley Packet Filter (eBPF), estaba claro que cambiaría todo. El eBPF nos permite ver todo lo que sucede en el núcleo sin depender de cambios en la aplicación. No podía entender por qué las herramientas de observabilidad no estaban aprovechando eso. La brecha en la IA se volvió clara más tarde. Una vez que nuestra plataforma de Kubernetes maduró, vimos a los clientes apresurándose a implementar despliegues de IA de generación mientras trataban a los LLM como cajas negras. Sabían que el modelo respondía, pero no por qué se comportaba de manera impredecible o por qué los costos estaban aumentando. Nos dimos cuenta de que los flujos de trabajo agentes son simplemente microservicios complejos y no determinísticos que necesitan la misma visibilidad sin tocar que habíamos construido previamente.

¿Cómo influyó su experiencia en ciberseguridad, sistemas integrados y I+D de aprendizaje automático en la visión detrás de groundcover, y qué desafíos enfrentó al principio al construir una empresa centrada en la observabilidad para aplicaciones y flujos de trabajo de IA?

Mi trasfondo en ciberseguridad dio forma al ADN de la empresa. En el mundo de la inteligencia, se asume que no se controla la aplicación. Ese enfoque es la razón por la que groundcover no requiere instrumentación. Sé por experiencia que pedir a los desarrolladores que modifiquen el código es la forma más rápida de bloquear la adopción. El desafío más difícil al principio con el monitoreo de LLM fue la privacidad. La observabilidad de IA captura prompts que pueden contener información de identificación personal sensible o propiedad intelectual. Mi trasfondo hizo que fuera obvio que las empresas no querrían que esos datos salieran de su entorno. Es por eso que construimos nuestra arquitectura en la nube, lo que nos permite proporcionar una visibilidad profunda del comportamiento del agente mientras mantenemos todos los datos dentro del entorno del cliente.

¿Cómo define la observabilidad de LLM, y en qué se diferencia de la monitorización tradicional o del monitoreo de aprendizaje automático?

La observabilidad de LLM es la práctica de instrumentar y monitorear sistemas de producción que utilizan modelos de lenguaje grande para que puedas capturar el contexto completo de cada inferencia: el prompt, el contexto, la finalización, el uso de tokens, la latencia, los errores, los metadatos del modelo e idealmente señales de retroalimentación o calidad hacia abajo. En lugar de preguntar solo “¿Está el servicio arriba y rápido?” o “¿Falló esta solicitud?”, la observabilidad de LLM te ayuda a responder preguntas como “¿Por qué esta solicitud en particular tuvo éxito o falló?”, “¿Qué sucedió realmente dentro de este flujo de trabajo de múltiples pasos?” y “¿Cómo afectan los cambios en los prompts, el contexto o las versiones del modelo al costo, la latencia y la calidad de salida?” Eso es muy diferente de la monitorización tradicional o incluso del monitoreo de aprendizaje automático clásico. Los enfoques heredados están ajustados para sistemas determinísticos, métricas de infraestructura y umbrales estáticos. Las aplicaciones de LLM son no determinísticas, de fin abierto y muy dependientes del contexto. El éxito a menudo es semántico y subjetivo, no solo un código de estado 200 versus 500. Eso significa que debes rastrear las entradas y salidas, comprender las llamadas a herramientas y los pasos de recuperación, evaluar las respuestas para cosas como alucinaciones o violaciones de políticas y conectar los costos y retrasos a nivel de token con la aplicación y la infraestructura circundantes.

¿Qué desafíos plantean las aplicaciones impulsadas por LLM que hacen que las herramientas de observabilidad tradicionales sean insuficientes?

Los sistemas impulsados por LLM presentan varios desafíos que exponen los límites de las herramientas tradicionales:

• Flujos de trabajo complejos y de múltiples pasos – Pasamos de flujos simples “llamar a un modelo, obtener una respuesta” a agentes de múltiples pasos, pipelines de múltiples pasos, generación aumentada con recuperación y uso de herramientas. Un fallo silencioso en cualquiera de esos pasos, como la recuperación, el enriquecimiento, la incrustación, la llamada a una herramienta o la llamada a un modelo, puede romper toda la experiencia. La monitorización tradicional generalmente no te da una visión completa y a nivel de traza de esas cadenas con prompts y respuestas incluidas.
• Pilas de IA en constante evolución – Los equipos están agregando nuevos modelos, herramientas y proveedores a un ritmo que nunca han visto antes. En muchas empresas, nadie puede enumerar con confianza qué modelos están en producción en un momento dado. La observabilidad clásica generalmente asume que tienes tiempo para instrumentar SDK, redeployar y curar cuidadosamente lo que se mide. Eso simplemente no sigue el ritmo al que se adopta la IA.
• Economía y cuotas basadas en tokens – La facturación y los límites de velocidad están vinculados a tokens y longitud de contexto, que a menudo están controlados por desarrolladores, prompts o comportamiento del usuario, y no por operaciones centrales. Las herramientas tradicionales no están diseñadas para mostrarte “quién quemó cuántos tokens en qué modelo, para qué flujo de trabajo, a qué latencia”.
• Corrección semántica en lugar de éxito binario – Un LLM puede devolver un 200 y aún así alucinar, desviarse de tu prompt o violar una política. Las herramientas tradicionales ven eso como un éxito. Necesitas observabilidad que pueda exponer prompts y respuestas y darte suficiente contexto para inspeccionar el comportamiento y, con el tiempo, conectar comprobaciones de calidad automatizadas.
• Datos de entrada sensibles que fluyen hacia terceros – Los LLM invitan a los usuarios a compartir información muy sensible a través de interfaces de estilo de chat. Ahora eres responsable de esos datos, de dónde se almacenan y de qué proveedores los ven. La observabilidad de SaaS convencional que envía toda la telemetría a un tercero a menudo es inaceptable para estas cargas de trabajo.

Todo esto significa que los sistemas de LLM requieren observabilidad que sea consciente de la IA, rica en contexto y mucho menos dependiente de la instrumentación manual que las herramientas que la mayoría de los equipos utilizan hoy en día.

¿Qué señales o métricas son las más importantes para comprender el rendimiento y la calidad de los sistemas de LLM, incluyendo la latencia, el uso de tokens y el comportamiento de prompt/resposta?

Hay algunas categorías de señales que importan mucho en la práctica:

Latencia y rendimiento

• Latencia de extremo a extremo por solicitud, incluyendo el tiempo del modelo y el tiempo de la aplicación circundante.
• Latencias de cola (P90, P95, P99) por modelo y por flujo de trabajo.
• Rendimiento por modelo, ruta y servicio, para que sepas dónde va realmente la carga.

Uso de tokens y controladores de costos

• Tokens de entrada y salida por solicitud, desglosados por modelo.
• Uso de tokens agregado en el tiempo por modelo, equipo, usuario y flujo de trabajo.
• Tamaños de contexto para pipelines de recuperación intensiva para que puedas ver cuándo los prompts estallan.
• Esto es lo que te permite responder “¿Quién está gastando realmente nuestro presupuesto de IA y en qué?”

Comportamiento de prompt y respuesta

• Las cargas útiles reales de prompt y respuesta en trazas representativas, incluyendo llamadas a herramientas y rutas de razonamiento.
• Qué herramientas el LLM eligió llamar y en qué secuencia.
• Variación en las respuestas para prompts similares para que puedas decir cómo estable es el comportamiento.

Confiabilidad y errores

• Tasas de error y tipos de error específicos del modelo (errores del proveedor, timeouts, problemas de autenticación, errores de cuota).
• Fallos en el flujo de trabajo circundante, como timeouts de herramientas o errores de recuperación, correlacionados con la llamada al LLM.

Contexto clásico de infraestructura

• Métricas de CPU, memoria y red de los contenedores para los servicios que orquestan tus llamadas a LLM.
• Registros correlacionados que describen lo que la aplicación estaba tratando de hacer.

Cuando puedes ver todo eso en un solo lugar, la observabilidad de LLM pasa de “Sé que algo es lento o caro” a “Sé exactamente qué modelo, patrón de prompt y servicio son responsables y por qué”.

¿Cómo puede la observabilidad ayudar a los equipos a detectar fallos silenciosos como la deriva de prompts, alucinaciones o degradación gradual de la calidad de salida?

Los fallos silenciosos en los sistemas de LLM generalmente ocurren cuando todo parece “verde” a nivel de infraestructura, pero el comportamiento real se está desviando. La observabilidad ayuda de varias maneras:

• Rastrear el flujo de trabajo completo, no solo la llamada al modelo – Al capturar el camino completo de una solicitud del cliente al servicio, a la recuperación, al modelo y a las herramientas, puedes ver dónde cambió el comportamiento. Por ejemplo, tal vez la recuperación comenzó a devolver menos documentos, o una llamada a una herramienta está fallando intermitentemente, y el modelo está improvisando.
• Mantener prompts, contexto y respuestas a la vista – Cuando puedes inspeccionar prompts y respuestas junto con trazas, se vuelve mucho más fácil detectar casos en los que una nueva versión de prompt, una nueva instrucción del sistema o una nueva fuente de contexto cambiaron el comportamiento, aunque la latencia y las tasas de error se mantuvieron igual.
• Filtrar y dividir en condiciones semánticas – Una vez que tienes telemetría de LLM rica, puedes filtrar hacia cosas como “llamadas a bedrock que toman más de un segundo”, “solicitudes que usan esta familia de modelos” o “trazas que involucran esta ruta en particular”, y luego leer los prompts y respuestas para ver si el modelo se está desviando o alucinando en un escenario específico.
• Alertar sobre SLO a nivel empresarial – Puedes definir SLO como “cualquier llamada a LLM que tome más de un segundo viola nuestro SLA de cara al usuario” y activar alertas cuando se cumplan esas condiciones. Con el tiempo, SLO similares se pueden vincular a puntuaciones de calidad o comprobaciones de política para que te alerten cuando la calidad se degrada, no solo cuando falla la infraestructura.

Debido a que la capa de observabilidad tiene acceso tanto a las señales específicas de IA como a los registros, métricas y trazas clásicas, se convierte en un lugar natural para detectar problemas que de otra manera se degradarían silenciosamente la experiencia del usuario.

¿Cómo apoya el enfoque de groundcover el diagnóstico de latencia impredecible o comportamiento inesperado dentro de flujos de trabajo de agentes de múltiples pasos y llamadas a herramientas?

groundcover toma un enfoque diseñado para sistemas de IA modernos. Usamos un sensor basado en eBPF a nivel de núcleo para observar el tráfico a través de microservicios sin cambios de código ni redeploy. Tan pronto como introduces un flujo de trabajo de LLM, podemos autodescubrir esas llamadas. Si comienzas a usar un nuevo modelo como Anthropic, OpenAI o Bedrock mañana, groundcover captura automáticamente ese tráfico. Eso te da:

• Trazas de extremo a extremo de flujos de trabajo de múltiples saltos – Ves el camino completo de una solicitud a través de servicios, incluyendo dónde se usa un LLM o una herramienta.
• Contexto profundo en cada llamada a LLM – Cada llamada incluye el modelo utilizado, la latencia, el uso de tokens, los prompts, las respuestas y los registros y métricas de infraestructura correlacionados.
• Filtrado potente en latencia y condiciones – Por ejemplo, puedes filtrar todas las llamadas a Claude 3.5 que toman más de un segundo e inspeccionar inmediatamente las trazas que violan tu SLA.
• Alertas y paneles vinculados al comportamiento de LLM – Una vez que los datos están disponibles, puedes crear alertas para violaciones de SLA o construir paneles que rastreen la latencia, el rendimiento, el uso de tokens y los errores.

Debido a que todo se recopila en el borde por eBPF y se almacena en tu propia nube, obtienes una visión de granularidad sin agregar instrumentación dentro de cada agente o llamada a una herramienta.

¿Qué riesgos de seguridad y cumplimiento de datos ve surgir en las implementaciones de LLM, y cómo puede la observabilidad ayudar a reducir esos riesgos?

Las implementaciones de LLM presentan algunos riesgos de datos únicos:

• Entrada de usuario ilimitada – Los usuarios pueden ingresar información extremadamente sensible en interfaces de chat y interfaces de IA. Eso puede incluir datos personales, datos del cliente o información regulada que nunca pretendiste recopilar.
• Proveedores de modelos de terceros – Una vez que envías esos datos a un proveedor de LLM externo, eres responsable de dónde fueron, cómo se almacenan y qué subprocessores están involucrados. Eso tiene implicaciones importantes para el RGPD, la residencia de datos y la confianza del cliente.
• Telemetría como una segunda copia de datos sensibles – Si tu pila de observabilidad envía cargas útiles completas a un proveedor de SaaS, ahora tienes otra copia de esa información sensible almacenada fuera de tu entorno.

La arquitectura de groundcover está diseñada para abordar exactamente esas preocupaciones:

• Usamos un modelo de “trae tu propia nube” donde la parte trasera de observabilidad completa se ejecuta dentro de tu cuenta de nube, en una subcuenta, como un plano de datos completamente administrado. El plano de control que lo escala y lo administra lo ejecutamos nosotros, pero no accedemos, almacenamos ni procesamos tus datos de telemetría.
• Como podemos capturar cargas útiles de manera segura en tu propio entorno, puedes observar prompts, respuestas y flujos de trabajo sin que esos datos salgan nunca de tu nube. No hay almacenamiento de terceros de tus trazas de LLM y no hay salida de datos extraña de la que preocuparse.
• Con esa visibilidad, puedes ver quién está subiendo qué y hacia dónde fluye, detectar usos inesperados de datos sensibles y hacer cumplir políticas alrededor de qué modelos y regiones están permitidos.

En otras palabras, la observabilidad se convierte no solo en una herramienta de confiabilidad y costo, sino también en un punto de control clave para la privacidad, la residencia de datos y el cumplimiento.

¿Cómo escalan las organizaciones desde una integración de LLM a múltiples servicios impulsados por IA, qué desafíos operativos tienden a surgir alrededor de la visibilidad, la confiabilidad y el costo?

La primera integración generalmente es un solo modelo en un solo flujo de trabajo. En ese punto, las cosas parecen manejables. Tan pronto como los equipos ven valor, el uso explota y surgen varios desafíos:

• Dispersión de modelos y proveedores – Los equipos prueban constantemente nuevos modelos. Pronto se vuelve confuso qué modelos están en producción y cómo se utilizan.
• Sorpresas de costos por uso de tokens – El consumo de tokens crece con la longitud del contexto y la complejidad del flujo de trabajo. Sin visibilidad en el uso de tokens por modelo y flujo de trabajo, es muy difícil gestionar los costos.
• Dependencias de confiabilidad en proveedores externos – Las API de cara al usuario se vuelven sensibles a la latencia del modelo o a los errores, lo que puede interrumpir los SLA incluso cuando la infraestructura central es saludable.
• Deuda de instrumentación en crecimiento – La observabilidad tradicional asume que tienes tiempo para agregar instrumentación cuando sea necesario. En pilas de IA en constante evolución, los desarrolladores rara vez tienen tiempo para eso.

groundcover aborda estos proporcionándote:

• Visibilidad centralizada de qué modelos y proveedores se utilizan.
• Paneles que muestran la latencia, el rendimiento y el uso de tokens en el tiempo.
• Correlación entre el comportamiento de LLM y los servicios que dependen de él
• Alertas para violaciones de SLO impulsadas por IA.

Eso hace que sea mucho más fácil escalar de “una característica de IA genial” a “la IA está tejida en decenas de servicios críticos” sin perder el control.

¿Hacia dónde espera que evolucione la observabilidad de LLM en los próximos cinco años a medida que la IA agente, la orquestación de múltiples modelos y las presiones regulatorias se aceleran?

Todavía estamos en los primeros días. En los próximos cinco años, espero varios cambios importantes:

• De nivel de solicitud a nivel de agente – La observabilidad se expandirá para capturar secuencias de herramientas, rutas de razonamiento y lógica de reintento, no solo llamadas al modelo.
• Señales y métricas semánticas más ricas – Las comprobaciones de calidad automatizadas para alucinaciones, problemas de seguridad y alineación de marca se convertirán en métricas estándar.
• Vínculo más estrecho con la gobernanza y la privacidad – A medida que crece la regulación, la observabilidad también servirá como una capa de cumplimiento y auditoría para la residencia de datos, la retención y el uso de modelos aprobados.
• Optimización de modelo cruzado y proveedor múltiple – Los equipos enrutaran tráfico a través de modelos dinámicamente basados en el rendimiento y el costo, guiados por datos de observabilidad en tiempo real.
• Menos instrumentación manual – Técnicas como la recopilación basada en eBPF y el autodescubrimiento se convertirán en el valor predeterminado, para que los equipos puedan innovar sin ralentizarse.

En resumen, la observabilidad de LLM evolucionará de “bonitas pantallas para IA” a un sistema nervioso central que conecta la confiabilidad, el control de costos, la gobernanza de datos y la calidad del producto en todo lo que una organización hace con IA.

Gracias por la gran entrevista, los lectores que deseen aprender más pueden visitar groundcover.