AWS Builder Center

Builder Center

Tu aplicación GenAI está saludable. Entonces, ¿por qué está dando malas respuestas?

Extendiendo la observabilidad en AWS más allá del HTTP 200 para detectar, investigar y recuperar fallos silenciosos en aplicaciones de IA generativa.

Mario Rodrigo Serrano Pineda

English version: https://builder.aws.com/content/3KIJYWLvGNQSZARKUUczA14Xfb0/your-genai-application-is-healthy-so-why-is-it-giving-bad-answers

De una charla en Community Day a una discusión técnica más profunda

Este artículo nació a partir de mi charla “Cuando tu IA falla a las 3 AM: cómo detectar, investigar y recuperar fallos silenciosos en aplicaciones GenAI sobre AWS”, presentada en el AWS Data & AI Community Day.
Durante la sesión exploramos un problema de confiabilidad que cobra cada vez más importancia a medida que las aplicaciones de IA generativa pasan de experimentos a entornos productivos:
Una aplicación puede estar técnicamente saludable y, aun así, estar fallándole a sus usuarios.
Construimos y demostramos este escenario utilizando una aplicación GenAI sobre AWS, donde Amazon API Gateway, AWS Lambda, Amazon Bedrock, una Knowledge Base y Amazon CloudWatch continuaban funcionando normalmente, incluso cuando la aplicación comenzaba a producir respuestas de baja calidad.
La sesión giró alrededor de tres preguntas:
¿Cómo detectamos un fallo cuando no existe un HTTP 500?
¿Cómo investigamos qué cambió cuando toda la infraestructura parece saludable?
¿Y cómo podemos aplicar prácticas SRE para recuperarnos de manera segura?
Este artículo profundiza en una de las ideas principales de aquella sesión: la observabilidad semántica, es decir, extender la observabilidad tradicional para monitorear no solo si una aplicación de IA responde, sino también si sus respuestas continúan siendo útiles, fundamentadas y alineadas con el comportamiento esperado del sistema.
Si quieres ver la implementación detrás de estos conceptos, puedes explorar la arquitectura y la demo práctica en el repositorio de GitHub o ver el recorrido completo en YouTube.
▶ Ver la demo en YouTube 
⌨ Explorar la implementación en GitHub 

Imagina este escenario

Son las 3:00 AM.
Tu equipo de soporte informa que el asistente de IA de la compañía ha comenzado a entregar respuestas incorrectas, irrelevantes o incompletas.
Abres tu dashboard de monitoreo.
Todo parece saludable.
Las solicitudes de la API están retornando HTTP 200.
Las funciones de AWS Lambda se ejecutan correctamente.
Amazon Bedrock está respondiendo.
La latencia se encuentra dentro del rango esperado.
No existen alarmas de infraestructura.
Desde la perspectiva operacional tradicional, el sistema está saludable.
Pero desde la perspectiva del usuario, la aplicación está fallando.
Este es uno de los desafíos que aparecen cuando llevamos aplicaciones de IA generativa desde experimentos hacia producción:
Disponibilidad técnica no significa necesariamente calidad de la IA.
Para los equipos DevOps y SRE, esto cambia la manera en que debemos pensar acerca de la observabilidad.

El fallo invisible

Las aplicaciones tradicionales suelen exponer sus fallos mediante señales que nuestros sistemas de monitoreo entienden muy bien.
Una solicitud devuelve HTTP 500.
Una invocación de Lambda falla.
La latencia aumenta.
La utilización de CPU alcanza un umbral.
Una dependencia deja de estar disponible.
Estas señales encajan naturalmente dentro del modelo tradicional de observabilidad basado en métricas, logs y trazas.
La IA generativa introduce otra categoría de fallo.
La infraestructura puede funcionar perfectamente mientras la respuesta generada es incorrecta.
Consideremos una aplicación RAG (Retrieval-Augmented Generation) ejecutándose sobre AWS.
Una solicitud podría recorrer este camino:
Usuario → Amazon API Gateway → AWS Lambda → Amazon Bedrock → Knowledge Base → Foundation Model → Usuario
Todos los componentes podrían completar exitosamente su operación.
Pero la aplicación todavía podría devolver:
  • una respuesta que no tiene relación con la pregunta;
  • información que no está respaldada por el contexto recuperado;
  • una respuesta incompleta;
  • información desactualizada;
  • una respuesta que incumple el formato esperado;
  • o una respuesta convincente, pero factualmente incorrecta.
No necesariamente existe una excepción.
No hay HTTP 500.
No hay timeout.
No hay una invocación fallida de Lambda.
Desde la perspectiva de infraestructura:
SUCCESS
Desde la perspectiva del usuario:
FAILURE
Esa brecha es precisamente donde la observabilidad tradicional comienza a ser insuficiente.

De la salud del sistema a la calidad de la respuesta

Cuando operamos workloads GenAI, resulta útil separar la observabilidad en dos dimensiones complementarias.

1. Observabilidad técnica

Responde preguntas como:
  • ¿La API está disponible?
  • ¿Lambda se está ejecutando correctamente?
  • ¿Cuánto tarda la solicitud?
  • ¿Amazon Bedrock está respondiendo?
  • ¿Existen errores de throttling?
  • ¿Cuántos tokens estamos consumiendo?
  • ¿Cuánto cuesta cada interacción?
Algunas señales típicas son:
Latencia, tasa de errores, throughput, disponibilidad y consumo de recursos.
Estas señales continúan siendo fundamentales.
No debemos reemplazar la observabilidad tradicional.
Debemos extenderla.

2. Observabilidad semántica

La observabilidad semántica plantea una pregunta diferente:
¿La respuesta fue realmente buena?
En lugar de monitorear únicamente si la solicitud terminó correctamente, comenzamos a observar características de la propia respuesta.
Dependiendo de la aplicación, algunas señales de calidad podrían ser:
  • relevancia;
  • groundedness o fundamentación en el contexto;
  • completitud;
  • fidelidad al contexto recuperado;
  • cumplimiento del formato esperado;
  • seguridad;
  • éxito de la tarea.
Ahora el panorama operacional comienza a ser mucho más interesante.
En lugar de observar únicamente:
HTTPStatus = 200
podríamos observar:
SemanticQualityScore = 0.42
La solicitud fue técnicamente exitosa.
Pero la señal de calidad nos está diciendo que algo puede estar mal.

Una arquitectura sencilla sobre AWS

Consideremos una arquitectura RAG simplificada.
Un usuario envía una pregunta a la aplicación.
Amazon API Gateway recibe la solicitud e invoca una función AWS Lambda.
La función recupera información relevante desde una Knowledge Base e invoca un foundation model mediante Amazon Bedrock.
La respuesta generada regresa al usuario.
Pero junto con ese camino normal podemos introducir un segundo proceso encargado de evaluar la calidad de la respuesta.
El evaluador puede recibir información como:
Pregunta del usuario + contexto recuperado + respuesta generada
y determinar si la respuesta satisface los criterios de calidad definidos para nuestra aplicación.
El resultado puede convertirse en una señal operacional.
Por ejemplo:
SemanticQualityScore = 0.91
o:
SemanticQualityScore = 0.38
Cuando la calidad se vuelve medible, puede convertirse en observable.

Convirtiendo la calidad de la IA en una señal operacional

Aquí es donde este enfoque resulta especialmente interesante para los equipos SRE.
Supongamos que nuestra aplicación genera un score de calidad entre 0 y 1.
Establecemos inicialmente:
SemanticQualityScore >= 0.70 → aceptable
SemanticQualityScore < 0.70 → degradado
El umbral exacto no es universal.
Debe calibrarse según el caso de uso, el dataset de evaluación y la tolerancia de la aplicación frente a respuestas incorrectas.
Pero una vez obtenemos una señal significativa, podemos publicarla como una custom metric en Amazon CloudWatch.
Ahora podemos observar algo que el monitoreo tradicional no podía mostrarnos:
La aplicación está disponible, pero la calidad de sus respuestas se está degradando.
Una alarma de CloudWatch podría detectar respuestas repetidas de baja calidad.
Esa alarma podría iniciar una investigación o incluso un workflow automatizado de recuperación.
Esto representa una evolución interesante del modelo tradicional de SRE.
Ya no monitoreamos únicamente la confiabilidad de la infraestructura.
Comenzamos a monitorear el comportamiento de la IA como parte de la confiabilidad del sistema.

Pero detectar es solamente el comienzo

Supongamos que una alarma nos informa:
La calidad semántica cayó por debajo del umbral esperado.
La siguiente pregunta es exactamente la misma que los equipos SRE hemos hecho durante años:
¿Por qué?
En una aplicación GenAI existen múltiples componentes capaces de afectar una respuesta.
El problema podría estar relacionado con:
  • el prompt;
  • la calidad del retrieval;
  • documentos faltantes;
  • conocimiento desactualizado;
  • chunking incorrecto;
  • comportamiento del modelo;
  • cambios de configuración;
  • lógica de aplicación;
  • una dependencia.
Por eso las trazas y la correlación adquieren tanta importancia.
Para cada interacción queremos conservar suficiente contexto como para reconstruir lo sucedido.
Por ejemplo:
request_id
prompt_version
model_id
retrieved_documents
retrieval_score
latency
token_usage
semantic_quality_score
Ahora imaginemos que durante la investigación descubrimos:
Prompt v1 → quality ~0.91
Prompt v2 → quality ~0.54
Mientras tanto, las métricas de infraestructura permanecen estables.
Ahora sí tenemos algo accionable.
Un cambio reciente del prompt podría haber introducido una regresión semántica.
Sin señales semánticas, esta regresión podría permanecer invisible hasta que suficientes usuarios comenzaran a quejarse.

Recuperación: aplicando pensamiento SRE a GenAI

Detectar no es suficiente.
Los sistemas confiables también necesitan una estrategia de recuperación.
Supongamos que nuestra aplicación conserva disponible la última versión conocida como estable del prompt.
Desplegamos:
prompt-v2
La calidad comienza a degradarse.
Nuestro monitoreo detecta repetidamente scores por debajo del umbral aceptado.
En lugar de continuar indefinidamente con una configuración degradada, podemos iniciar una respuesta controlada:
Detectar → Investigar → Decidir → Recuperar → Validar
Recuperarse podría significar:
  • regresar a una versión anterior del prompt;
  • cambiar la configuración del retrieval;
  • utilizar como fallback un modelo o workflow más seguro;
  • deshabilitar una funcionalidad problemática;
  • enviar la solicitud a revisión humana;
  • activar una experiencia degradada pero más confiable.
La idea importante no es automatizar ciegamente todas las decisiones.
El objetivo es construir mecanismos de recuperación controlados y con guardrails claramente definidos.
Aquí es donde los principios establecidos de SRE adquieren muchísimo valor para la IA generativa.

Un nuevo tipo de SLI

Site Reliability Engineering utiliza habitualmente Service Level Indicators (SLIs).
Medimos cosas como:
Disponibilidad
Latencia
Tasa de errores
Throughput
Pero las aplicaciones GenAI introducen una posibilidad interesante:
SLIs semánticos.
Por ejemplo:
Good Answer Rate
podría representar:
respuestas aceptables / total de respuestas evaluadas
Un equipo podría monitorear entonces:
GoodAnswerRate = 96.4%
Esto no significa que las organizaciones deban crear inmediatamente SLOs semánticos formales para todas sus aplicaciones de IA.
La propia evaluación contiene incertidumbre.
Pero esta métrica proporciona una señal operacional mucho más útil que limitarnos a preguntar si la API respondió con HTTP 200.

¿Qué deberíamos monitorear?

Un workload GenAI en producción debería proporcionar visibilidad sobre varias capas:
CapaEjemplos de señales
Infraestructuradisponibilidad, CPU, memoria, concurrencia
Aplicaciónlatencia, errores, throughput
Modelotokens, latencia de invocación, throttling
Retrievaldocumentos recuperados, relevancia, retrieval scores
Calidad semánticarelevancia, groundedness, completitud
Negociofinalización de tareas, feedback del usuario, conversión
La idea fundamental es que estas capas se complementan entre sí.
La observabilidad semántica no reemplaza la observabilidad de infraestructura. Completa el panorama.

El rol de DevOps y SRE está evolucionando

GenAI no elimina la necesidad de las prácticas DevOps o SRE.
Las vuelve todavía más importantes.
La infraestructura continúa necesitando ser confiable.
Los despliegues continúan necesitando controles.
Los cambios necesitan trazabilidad.
Los sistemas necesitan observabilidad.
Los incidentes necesitan investigación.
Pero ahora aparece una nueva pregunta:
¿La IA se está comportando como el sistema fue diseñado para comportarse?
Esta pregunta conecta AI Engineering, observabilidad y Reliability Engineering.
Y será cada vez más relevante a medida que más organizaciones lleven aplicaciones GenAI a producción.

Un camino práctico hacia la madurez

Los equipos no necesitan construir una plataforma avanzada de observabilidad para IA desde el primer día.
Podemos avanzar progresivamente.
Este camino permite incrementar progresivamente la madurez operacional sin intentar resolver desde el primer día todos los problemas de confiabilidad asociados con GenAI.

Reflexión final

Si tuviera que quedarme con una sola idea de este artículo sería esta:
Una solicitud exitosa a una API no garantiza una interacción exitosa con la IA.
En sistemas tradicionales, un HTTP 200 suele indicarnos que la operación técnica finalizó correctamente.
Para aplicaciones de IA generativa necesitamos otra capa de comprensión.
Debemos observar no solamente si el sistema respondió, sino también si la respuesta fue útil, fundamentada y alineada con lo que esperábamos que hiciera la aplicación.
Ahí es donde la observabilidad semántica se convierte en parte de Reliability Engineering.
Y esto nos deja una pregunta interesante para el futuro de SRE:
Si el comportamiento de la IA forma parte del sistema, ¿no debería la calidad de la IA formar también parte de aquello que monitoreamos?

¿Qué construimos ahora?

Este artículo es solamente el comienzo.
El siguiente paso es convertir estos conceptos en nuevos labs prácticos sobre AWS.
He creado una encuesta en AWS Builder Center para que la propia comunidad pueda decidir qué tema deberíamos construir a continuación.
🗳️ Votar por el próximo lab en AWS Builder Center 
El tema ganador puede convertirse en un nuevo artículo técnico, video de YouTube y hands-on lab para la comunidad.
# ai# agentic-ai# generative-ai# retreival-augmented-generation# failure
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article