Observabilidad de aplicaciones con IA: cómo rastrear calidad, coste y fallos hasta su causa

Qué problema resuelve la observabilidad

Una respuesta deficiente no identifica por sí sola el componente que falló. Puede haber sido una generación no fundamentada, pero también una consulta de recuperación que devolvió documentos poco pertinentes, una herramienta externa que respondió con error, una validación que aceptó una salida incorrecta o un reintento que cambió el comportamiento y el coste. Limitarse a registrar el texto final y una marca de error deja demasiadas hipótesis abiertas.

La observabilidad convierte una interacción en una secuencia reconstruible de hechos técnicos. Su finalidad práctica es responder, para una ejecución concreta y también para una población de ejecuciones, qué versión atendió la solicitud, qué entradas estructuradas recibió, qué pasos realizó, cuánto tardó cada uno, qué recursos consumió y cuál fue el resultado verificable. Esa evidencia permite distinguir un incidente aislado de una regresión tras un cambio.

No sustituye las evaluaciones previas al despliegue ni garantiza que una respuesta sea correcta. Su función es complementar esas prácticas con señales de producción. Las fuentes aportadas describen la necesidad de conectar modelo, prompt, tiempos por etapa, reintentos, tokens, coste y calidad cuando el caso de uso lo exige. Esta guía traduce ese marco a un contrato mínimo de instrumentación, sin asumir que una métrica agregada explique por sí misma la causa raíz.

Para navegar desde este marco hacia materiales relacionados, la arquitectura de contenidos puede enlazar con [Aprende](route:learn.index), [Compara](route:compare.index) y [Descubre](route:discover.index). Esos enlaces no sustituyen la evidencia recogida en la traza de cada ejecución.

La unidad de análisis: una traza de interacción

La unidad mínima útil es una traza por interacción de negocio, no por llamada aislada al modelo. Debe iniciar cuando la aplicación acepta una tarea identificable —por ejemplo, responder una consulta o procesar una solicitud— y terminar cuando entrega, rechaza o abandona un resultado. La traza tiene un identificador estable y contiene intervalos hijos para las etapas que la componen.

Un intervalo representa una operación delimitada: normalización de entrada, recuperación, llamada al modelo, ejecución de herramienta, reintento, validación, postprocesado o entrega. Cada intervalo conserva su relación de parentesco, inicio, final, estado y atributos específicos. Así, una latencia total elevada puede descomponerse sin atribuir automáticamente la demora al proveedor del modelo.

La traza debe relacionarse con un identificador de solicitud o conversación seudonimizado, un canal, un tipo de tarea y una cohorte de despliegue. No conviene usar esos atributos para almacenar texto libre o identificadores directos de personas. El propósito es poder segmentar una degradación por versión, tarea, entorno o canal sin reidentificar a quien utilizó el servicio.

La reconstrucción tiene que incluir referencias inmutables a las versiones utilizadas: modelo y parámetros relevantes, plantilla de prompt, configuración de recuperación, definición de herramientas, reglas de validación y versión del flujo. Si un identificador apunta a contenido mutable, una investigación posterior puede reconstruir una configuración distinta de la que produjo el incidente.

El contrato mínimo de telemetría

Defina el contrato antes de instrumentar. En el nivel de traza, registre identificador, hora, entorno, tipo de tarea, canal, cohorte, versión de flujo, estado final y un resultado de negocio cuando exista. En el nivel de intervalo, registre tipo de operación, estado, duración, número de intento, dependencias y atributos que permitan comparar configuraciones. Use un vocabulario controlado para estados como éxito, error técnico, error de validación, rechazo seguro, cancelación y tiempo agotado.

Para una llamada al modelo, los atributos mínimos incluyen proveedor o familia de modelo, versión o alias resuelto cuando esté disponible, parámetros que alteren de forma material la salida, identificador de plantilla, tokens de entrada y salida, y coste calculado o datos suficientes para calcularlo según la tarifa vigente. Para recuperación, incluya índice o colección versionada, estrategia, filtros, número de candidatos y documentos seleccionados mediante identificadores no sensibles.

Las herramientas necesitan nombre y versión, operación solicitada, código de resultado, clase de error, duración e idempotencia o clave de correlación si se ejecutan acciones. Para validaciones, registre el nombre y versión de la regla, el resultado y una categoría de fallo. No confunda un JSON sintácticamente válido con una respuesta aceptable para el negocio: son señales distintas.

El contrato debe documentar qué se excluye. Por defecto, evite prompts, respuestas, documentos recuperados, argumentos completos de herramientas, correo electrónico, teléfono, direcciones, secretos, tokens de acceso y cualquier dato que no sea imprescindible para el diagnóstico. Cuando el texto sea necesario para depuración autorizada, aplique minimización, enmascaramiento, controles de acceso y una retención diferenciada.

Cómo medir el coste real por interacción

El coste por interacción no equivale al coste medio de una llamada principal. Sume las llamadas de entrada y salida del modelo, los reintentos, las llamadas de herramientas con facturación propia, la recuperación si genera gasto atribuible y los pasos fallidos. Mantenga separado el coste observado de una estimación: la primera procede de datos de uso y precios aplicados; la segunda puede depender de tarifas, redondeos o información incompleta.

Atribuya cada componente a la misma traza y preserve la moneda, fecha de cálculo y versión de la tabla tarifaria o del método de estimación. Esta precaución importa porque un cambio de precio, modelo o modalidad de procesamiento puede hacer que dos periodos no sean directamente comparables. Si no existe coste verificable para un componente, márquelo como desconocido en lugar de imputar cero.

Mida distribuciones, no solo promedios. Una media estable puede ocultar una cola de interacciones con múltiples reintentos o contextos excesivos. Segmente por tarea, canal, versión y resultado final. El coste de una ejecución que termina en error sigue siendo coste operativo y debe aparecer tanto en el total como en el análisis de desperdicio.

Cuando interviene revisión humana, es preferible registrarla como coste o esfuerzo operativo separado, con un método explícito de estimación. Mezclarla con el gasto de inferencia puede ocultar que una optimización de latencia trasladó trabajo a las personas.

Separar las fuentes de latencia

La latencia de extremo a extremo es el tiempo que percibe quien usa la aplicación, pero no señala qué componente debe corregirse. Registre intervalos para cola o admisión, preparación de contexto, recuperación, llamadas al modelo, red cuando pueda observarse, herramientas, reintentos, validación y serialización de salida. La suma puede no coincidir exactamente con el total si hay operaciones paralelas; por ello también debe registrarse la relación temporal entre intervalos.

Compare percentiles de duración por etapa y no solo el valor medio total. Una subida en el percentil alto de herramientas con latencia de modelo estable dirige la investigación a una dependencia externa. Un incremento de recuperación puede proceder de un índice, un filtro o un crecimiento de candidatos. Una respuesta lenta por reintentos requiere revisar tanto la condición que los dispara como su política de límites.

Evite atribuciones simplistas. Que una traza contenga una llamada al modelo no demuestra que el modelo haya sido el cuello de botella. La evidencia adecuada es una distribución temporal segmentada por la misma versión, tipo de tarea y condiciones comparables. Los cambios de tráfico, contenido o mezcla de usuarios son factores de confusión que deben quedar anotados.

Señales de calidad en producción y sus límites

La calidad no debe reducirse a una única puntuación. El feedback de usuarios refleja experiencia percibida, pero puede ser escaso, sesgado hacia casos extremos o carecer de contexto. La revisión humana permite aplicar criterios definidos y detectar fallos sutiles, aunque tiene coste y cobertura limitada. Las reglas deterministas son reproducibles para requisitos verificables, como un esquema o una autorización, pero no capturan por sí solas utilidad, exactitud factual o adecuación contextual.

Los evaluadores automáticos pueden ayudar a priorizar muestras y seguir tendencias si se versionan, se calibran contra revisión humana y se usan con límites explícitos. No constituyen una prueba independiente de verdad, especialmente cuando evalúan tareas ambiguas o comparten sesgos con el sistema evaluado. Registre su versión, entrada disponible, criterio, resultado y nivel de confianza si el método lo produce.

Vincule todas las señales a la traza y distinga claramente su procedencia. Una caída de pulgares arriba no es equivalente a una regla de negocio incumplida; una salida con JSON válido no demuestra que sus valores sean correctos. El panel debe permitir ver cada señal por separado y, después, examinar coincidencias o divergencias.

Muestree casos sin feedback además de los negativos. De lo contrario, el equipo aprende sobre quienes reportan problemas, pero no sobre errores silenciosos. El diseño de la muestra debe ser documentado: población, periodo, estratos, tamaño y criterio de revisión.

Diagnóstico de cuatro incidentes frecuentes

Una respuesta inventada debe investigarse desde el resultado hacia atrás. Compruebe si la tarea requería fundamentación, si hubo contexto recuperado, qué documentos se seleccionaron, qué instrucciones de uso de fuentes aplicaban y si una regla o revisión detectó afirmaciones no sustentadas. Si no se registró la configuración de recuperación o la versión de prompt, la causa puede quedar indeterminada; no atribuya el fallo al modelo por exclusión.

Ante contexto irrelevante, compare consulta normalizada, filtros, colección versionada, estrategia, número de candidatos y selección final. El problema puede ser de indexación, filtros, metadatos, cambios de corpus o estrategia de ranking. La baja relevancia también puede originarse porque la solicitud se clasificó en una tarea equivocada antes de recuperar información.

Para JSON inválido, separe la capa sintáctica de la semántica. Revise el esquema exigido, el método de salida estructurada, la versión de parser, los reintentos y la respuesta de validación. Un reintento exitoso puede ocultar una tasa creciente de primeras respuestas inválidas y elevar coste y latencia.

Ante una acción de herramienta fallida, determine si la herramienta fue llamada, si recibió argumentos permitidos, si la dependencia respondió, si se produjo un tiempo agotado y si hubo efectos parciales. Las acciones con consecuencias deben incorporar claves de idempotencia, estados de confirmación y límites de reintento. Una respuesta final satisfactoria no prueba que la acción se ejecutara.

Alertas, umbrales y decisiones de detención

Una alerta útil especifica métrica, ventana, segmento, umbral, responsable, evidencia requerida y acción inicial. “La calidad baja” no cumple ese criterio. Una formulación operativa podría vigilar el aumento de errores de validación de una versión concreta durante una ventana definida, exigir trazas de muestra y asignar una revisión a la persona responsable del flujo.

Use umbrales como reglas de atención, no como prueba de causalidad. Deben basarse en una línea base del propio servicio y revisarse cuando cambia el volumen, la mezcla de tareas o el producto. Combine alertas de disponibilidad y seguridad con revisión de calidad y coste: optimizar una métrica aislada puede empeorar otra.

Detenga, revierta o limite un cambio cuando infrinja una condición de seguridad, una regla de negocio crítica o un límite económico acordado, o cuando la evidencia muestre una degradación relevante frente a una cohorte comparable. En otros casos, reduzca exposición mediante despliegues graduales y aumente el muestreo antes de concluir.

Las fuentes aportadas recomiendan relacionar rendimiento, coste y calidad y comparar versiones o entornos. La elección concreta de umbrales no aparece establecida de forma universal en esas fuentes; debe derivarse de los riesgos, la línea base y los compromisos del servicio.

Retención, minimización y acceso

Una traza detallada puede convertirse en un repositorio sensible si se diseña sin límites. Empiece por la pregunta diagnóstica y registre únicamente los atributos necesarios para responderla. Los identificadores seudonimizados, hashes con gestión adecuada y categorías de error suelen aportar más valor operativo que almacenar de forma indiscriminada prompts, respuestas o documentos completos.

Separe datos operativos de datos de depuración excepcional. Los primeros pueden incluir duraciones, versiones, contadores, estados y referencias técnicas; los segundos, si están justificados, requieren acceso limitado, enmascaramiento, registro de acceso y una retención corta definida. Revise también qué datos envían bibliotecas de instrumentación a terceros antes de habilitarlas.

Defina quién puede consultar trazas, quién puede acceder a contenido excepcional y quién puede modificar reglas de redacción o retención. Las solicitudes de eliminación, los requisitos regulatorios y las políticas internas pueden variar según jurisdicción y caso de uso. Esta guía no determina obligaciones legales; requieren evaluación aplicable al contexto de la organización.

La documentación de New Relic aportada menciona filtros para descartar datos sensibles antes de su envío. Ese hecho respalda la viabilidad técnica de filtrar, pero no demuestra que una configuración concreta sea suficiente para todas las categorías de datos ni para todos los marcos normativos.

Plantilla final de lanzamiento y panel mínimo

Antes de liberar una versión, compruebe que cada ejecución puede vincularse a una versión inmutable de flujo, prompt, modelo, recuperación, herramientas y validaciones. Verifique que los reintentos aparecen como intervalos o atributos distinguibles, que los tokens y costes se atribuyen a todos los intentos y que los resultados de negocio no se confunden con errores técnicos.

El panel mínimo debe combinar volumen de trazas, tasa de estados finales, latencia total y por etapa, tokens y coste por interacción, reintentos, resultados de validación, errores de herramientas y señales de calidad separadas por origen. Todos los gráficos deben admitir filtros por periodo, entorno, versión, tarea, canal y cohorte para evitar comparaciones de poblaciones heterogéneas.

Para el lanzamiento, seleccione una cohorte de control o una línea base anterior y defina de antemano las condiciones de ampliación, pausa y reversión. Conserve muestras de trazas representativas, incluidas ejecuciones exitosas, fallidas y con alto coste. Documente cambios de tráfico, corpus, precios o políticas que puedan alterar la interpretación.

El resultado esperado no es una explicación automática para cada incidente. Es un sistema que reduce la dependencia de recuerdos, capturas de pantalla e impresiones aisladas, y que muestra de manera explícita cuándo la evidencia permite una conclusión y cuándo todavía no.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.