Observabilidad de funciones de IA: latencia, costo y calidad

La pregunta que traba a un equipo de guardia frente a una función de IA es simple e incómoda: ¿el sistema está funcionando? En un servicio tradicional, la latencia y la tasa de error responden. En una función de LLM, ambas pueden verse perfectas mientras la respuesta entregada al usuario está equivocada.

Tres señales en lugar de una

Una función de IA necesita ser observada en tres ejes simultáneos, y ninguno sustituye al otro.

Latencia responde si el usuario esperó demasiado. Con generación de texto, la métrica útil no es solo el tiempo total: es el tiempo hasta el primer token, porque es el que determina la percepción de respuesta cuando hay streaming.

Costo responde si la operación es sostenible. Es el eje que no existe en un servicio tradicional y el que más suele descubrirse tarde.

Calidad responde si la respuesta sirvió. Es el único de los tres que no sale de un contador de servidor, y es el que realmente importa.

Un panel que muestra solo los dos primeros da una sensación de control que no corresponde al estado del sistema.

Estandariza los atributos antes de inventar los tuyos

OpenTelemetry mantiene convenciones semánticas específicas para sistemas de IA generativa, definiendo nombres de atributo para la operación, el modelo solicitado, el modelo que respondió, el conteo de tokens de entrada y salida, la temperatura y el motivo de parada.

Conviene adoptarlas aunque hoy uses una sola herramienta. Renombrar un atributo después de seis meses de historial es caro, y la estandarización es lo que permite cambiar de backend de observabilidad sin reescribir la instrumentación.

El detalle que más rinde: registrar por separado el modelo solicitado y el modelo que de hecho respondió. Un proveedor que apunta un alias a una versión nueva cambia el comportamiento de tu aplicación sin ningún despliegue de tu lado, y sin ese par de atributos la investigación empieza en el lugar equivocado.

La calidad necesita un proxy, porque no tiene contador

Como no existe un contador de "respuesta buena", la calidad se observa por aproximación. Cuatro proxies funcionan bien en la práctica:

• Señal explícita del usuario, el pulgar arriba o abajo. Poco volumen, mucho valor.
• Señal implícita, como repetir la misma pregunta, abandonar el flujo, editar pesadamente el texto sugerido o escalar a atención humana.
• Verificación automática de lo que es verificable: el JSON es válido, la cita existe en la base, el valor está dentro del rango posible.
• Muestra revisada por humanos, pequeña, continua y siempre con el mismo criterio.

Ninguno alcanza por sí solo. Juntos detectan la degradación silenciosa que ninguna alarma de latencia dispararía.

SLO para una respuesta que varía

El capítulo de SLO del libro de SRE de Google parte de una idea que encaja bien aquí: elegir pocos indicadores que representen la experiencia del usuario y definir un objetivo realista, no perfecto.

Para una función de IA, un conjunto inicial razonable es: tiempo hasta el primer token por debajo de un límite en el 95% de las solicitudes; tasa de fallo duro por debajo de un techo; tasa de queja o repetición por debajo de un techo; costo medio por interacción por debajo de un valor.

El objetivo de un SLO no es el número bonito en el panel. Es tener un presupuesto de error que decide si el próximo cambio puede ser arriesgado o no. Sin eso, la discusión sobre publicar una versión nueva de prompt se vuelve una disputa de opiniones.

El costo pertenece al panel principal

El costo por interacción, por ruta y por usuario debe estar en el mismo panel que la latencia, no en un reporte financiero aparte que alguien abre a fin de mes.

La razón es operativa: un cambio de prompt que duplica el contexto enviado aparece como un escalón en el gráfico de costo el mismo día. Si ese gráfico se mira treinta días después, la correlación con el despliegue ya se perdió.

Registra lo suficiente sin volverlo un pasivo

Los prompts y las respuestas contienen datos del usuario. Registrar todo indefinidamente crea un pasivo de privacidad que no compensa.

El término medio que funciona: registrar siempre los metadatos, es decir versiones, tokens, latencia, costo y resultado de la verificación automática; registrar contenido por muestreo, con retención corta y acceso restringido; y registrar siempre el contenido cuando hubo falla de verificación, porque es exactamente ahí donde la investigación necesita mirar.

Qué significa esto para tu equipo

Si tu función de IA ya está en producción sin observabilidad dedicada, empieza por lo más barato: registrar versión de prompt, versión de modelo, tokens y costo en cada llamada, con los nombres de atributo de OpenTelemetry. Son pocas horas de trabajo y cambia la naturaleza de la próxima investigación.

Después elige un proxy de calidad y ponlo en el mismo panel de latencia. Uno solo, el más fácil de recolectar en tu producto.

El informe DORA de 2025 refuerza un punto con el que vale cerrar: la adopción de IA amplifica la capacidad que ya existe. Un equipo con buena observabilidad se vuelve más rápido con IA. Un equipo sin ella solo descubre los problemas más tarde, y con más código para revisar.