Observabilidad para funciones de IA: qué registrar, trazar y vigilar
Cuando una función de IA se porta mal, necesitas saber qué petición, qué prompt y qué modelo lo causaron, y cuánto costó. Qué registrar, trazar y vigilar para responder eso en minutos, no en días.
Una función de IA puede fallar de formas en que un servicio normal nunca falla. Puede responder rápido a cada petición y aun así estar equivocada, volverse más lenta y más cara semana tras semana, o cambiar su comportamiento porque alguien editó un prompt. Los chequeos de disponibilidad no ven nada de eso. Para operar IA en producción necesitas ver lo que realmente hizo, para quién, con qué instrucciones y a qué costo.
Si lideras el equipo: qué preguntar
- Si un cliente reporta una respuesta rara, ¿cuánto tardamos en averiguar qué la produjo?
- ¿Sabemos cuánto cuesta cada uso de cada función con IA, y nos daríamos cuenta si se dispara?
- ¿Hay una vista que yo mismo pueda leer, que muestre con qué frecuencia la gente acepta o corrige lo que produce la IA?
Esto es lo que instrumentamos antes de que una función de IA salga a producción.
Una traza por petición, de punta a punta
Una sola acción del usuario a menudo se convierte en varios pasos: traer contexto, armar un prompt, llamar a un modelo, validar la salida, quizá llamarlo otra vez, y luego guardar un resultado. Dale a toda esa cadena un ID de correlación y llévalo en cada línea de log, cada llamada al modelo y cada escritura en la base de datos. Cuando alguien reporte una respuesta extraña, deberías poder pegar un ID y ver el camino completo: qué entró, qué salió, cuánto tardó cada paso y dónde se torció.
Registra entradas y salidas, sin datos personales
No puedes depurar lo que no guardaste. Guarda el prompt que realmente se envió (ya con la plantilla aplicada) y la respuesta cruda, no solo el resultado procesado. Pero las entradas de una IA suelen contener nombres, correos, teléfonos y texto libre sobre personas reales, así que redacta antes de escribir, no después. Decide qué campos se guardan, cuáles se enmascaran y cuáles nunca se registran, y define un periodo de retención.
Versión en cada llamada
Cada llamada al modelo debería registrar el modelo y su versión, la versión del prompt y la configuración (temperatura, herramientas, límites) que la produjo. Sin esto, un cambio de calidad no tiene explicación: ¿fue el proveedor del modelo, la edición del prompt del martes o una bandera de configuración? Con esto, sabes qué salidas revisar cuando una versión resulta estar mal.
Latencia y costo por función, no por cuenta
La factura del proveedor te dice cuánto gastaste en total. No te dice que una función consume la mayoría de los tokens, ni que un ciclo de reintentos duplicó el costo de otra. Mide la latencia (mediana y la cola lenta) y el costo en tokens por función y por paso. Así detectas un costo descontrolado antes que la factura.
Errores, respaldos y reintentos
Cuenta las fallas que no parecen fallas:
- respuestas rechazadas por los controles de esquema o de completitud;
- reintentos, y cuántos funcionan al segundo intento;
- respaldos usados: un modelo más pequeño, una respuesta basada en reglas, un resultado en caché;
- timeouts y respuestas de límite de tasa del proveedor.
Una tasa de respaldos que sube suele ser la primera señal de que algo cambió aguas arriba, mucho antes de que los usuarios se quejen.
Señales de calidad del uso real
Las métricas técnicas muestran que el sistema está corriendo. Las señales de calidad muestran que es útil. Las mejores vienen de las personas: alguien que corrige una salida, la rechaza, la edita mucho o la ignora. Regístralas como eventos ligados a la traza y a la versión del prompt. Con el tiempo te dicen dónde el modelo es confiable y dónde no, y se convierten en los casos de prueba del próximo cambio.
Vigila la deriva
Las entradas cambian: productos nuevos, tipos de cliente nuevos, una fuente de datos nueva con otro formato. Las salidas se mueven con ellas. Sigue distribuciones simples en el tiempo, como el largo de las entradas, la proporción de cada categoría que asigna el modelo y las puntuaciones promedio, y alerta cuando se muevan bruscamente.
Alertas que le importan al negocio
Alerta sobre lo que alguien va a atender: la tasa de respaldos por encima de un umbral, el costo por función sobre el presupuesto, un salto en las salidas rechazadas, una señal de calidad que cae. Evita alertas que suenan a diario y todos ignoran. Cada alerta debería tener un responsable y un primer paso escrito al lado.
Tableros para quienes no son ingenieros
Los dueños de producto y los gerentes necesitan una vista en sus propios términos: qué tanto se usa la función, qué tan seguido la gente acepta lo que produce, cuánto cuesta por uso y si eso está cambiando.
Lista antes de que una función de IA salga a producción
- Un ID de correlación en cada paso de una petición.
- Prompts y respuestas registrados, datos personales redactados, retención definida.
- Modelo, versión del prompt y configuración registrados en cada llamada.
- Latencia y costo medidos por función.
- Rechazos, reintentos y respaldos contados.
- Correcciones y rechazos humanos capturados como eventos.
- Deriva vigilada en algunas distribuciones simples.
- Una lista corta de alertas, cada una con responsable.
- Un tablero que alguien que no es ingeniero pueda leer.
Si quieres ver qué tan listos están tus propios planes de IA para esto, empieza con nuestro chequeo de preparación para IA.
Escrito a partir del trabajo de nuestros ingenieros en sistemas en producción. ¿Quieres una segunda opinión sobre tu proyecto? Habla con un ingeniero.
Ver el trabajo →