¿Cómo detectar la degradación de una función de IA?

Una función de IA se ha degradado cuando los usuarios obtienen menos valor por intento, aunque todas las solicitudes al modelo devuelvan HTTP 200. Esa definición importa. Una función puede seguir disponible desde el punto de vista técnico mientras las respuestas pierden utilidad, tardan más, un texto alternativo sustituye el resultado previsto, el consumo de tokens se duplica y los usuarios se marchan sin decir nada.

He visto a equipos dar una reparación por buena porque el gráfico de errores volvió a verde, aunque la tasa de finalización siguiera cayendo. Habían medido la llamada al proveedor, no el resultado para el usuario. Para verificar el funcionamiento en producción hace falta un registro por solicitud que conecte toda la ruta: qué intentó hacer el usuario, qué versiones de la aplicación y del modelo lo procesaron, cuánto tardó cada etapa, qué produjo el modelo, si apareció una alternativa, cuánto costó y qué hizo después el usuario.

Las seis familias de señales de este artículo responden a preguntas distintas. La latencia indica si la función responde dentro del plazo en el que sigue siendo útil. La tasa de errores encuentra fallos explícitos y encubiertos. Los controles de calidad determinan si una respuesta cumple su cometido. El uso de alternativas deja al descubierto pérdidas de capacidad ocultas. El gasto en tokens detecta prompts y bucles ineficientes. El abandono muestra cuándo los usuarios dejan de esperar o de confiar en el resultado. Una corrección solo queda verificada cuando la cohorte afectada mejora en las señales pertinentes sin empeorar otra.

Empieza con un evento por cada intento del usuario

Un evento por solicitud es la unidad útil más pequeña para monitorizar IA en producción, porque los promedios no pueden volver a unir una llamada lenta, una respuesta deficiente y al usuario que la abandonó. Emite un registro cuando el intento llegue a un estado terminal. Asígnale un identificador de solicitud opaco y adjunta ese identificador a las trazas, evaluaciones del modelo, registros de costes y eventos del producto. No registres prompts ni resultados sin procesar de forma predeterminada; guarda contenido censurado, hashes, clasificaciones o una referencia sujeta a tus controles de conservación.

El evento necesita dimensiones suficientes para comparar casos equivalentes. Como mínimo, registra la función y el tipo de tarea, la versión de la aplicación, la versión del prompt, el modelo y el proveedor, la clase de inquilino o plan, la región, la franja de tamaño de entrada, si hubo streaming, el estado, el número de reintentos, el motivo de la alternativa, los tokens de entrada y salida, la latencia hasta el primer token y la total, el resultado de calidad y la acción posterior del usuario. Usa etiquetas acotadas en las métricas. Conserva los identificadores de solicitud y otros valores de alta cardinalidad en registros o trazas, no en etiquetas de métricas.

Un evento terminal puede tener este aspecto:

{"request_id":"req_7f2c","feature":"support_reply","task":"draft","app_version":"2026.07.4","prompt_version":"p18","model":"model-a","region":"eu-west","input_band":"1k-4k","status":"success","retry_count":1,"fallback":"none","latency_ms":4820,"first_token_ms":910,"input_tokens":1824,"output_tokens":436,"quality":{"policy_pass":true,"schema_pass":true,"grounded":"unknown"},"user_action":"accepted","action_delay_ms":6400}

Este registro es un contrato de instrumentación, no un esquema universal. Una función de recuperación también necesita el número de resultados recuperados, el estado de resultado vacío, identificadores o clases de fuentes y la validez de las citas. Un agente necesita el número de llamadas a herramientas, la categoría de fallo de la herramienta, el motivo de terminación del bucle y el estado de los efectos secundarios. Un clasificador necesita la clase predicha, la franja de confianza y la verdad de referencia posterior cuando llegue.

Las convenciones semánticas de OpenTelemetry ofrecen a los equipos un vocabulario común para la duración de las operaciones, los atributos del modelo y el uso de tokens. Usa esos nombres cuando tu instrumentación los admita, pero mantén junto a ellos los campos de resultados del producto. Un span estándar del modelo no puede saber que un cliente aceptó un borrador o cerró el cuadro de diálogo. Esa última unión corresponde a tu aplicación.

Antes de cambiar el código, captura una ventana de referencia que represente la misma mezcla de tráfico que utilizarás para la verificación. Guarda la consulta, los filtros de cohorte, los tamaños de muestra y la zona horaria del panel. Si comparas el tráfico empresarial del lunes con el tráfico gratuito del domingo, el gráfico puede moverse más que la reparación.

La latencia de cola revela el fallo de tráfico

La degradación de la latencia suele aparecer en la cola antes de cambiar el promedio. Controla la mediana, p90, p95 y p99 de la latencia total, además del tiempo hasta el primer token para respuestas en streaming. La mediana describe la solicitud habitual. Los percentiles superiores revelan colas de espera, límites de tasa, arranques en frío, contextos largos, reintentos y una pequeña región o un grupo de clientes que el promedio oculta.

Mide al menos cuatro límites: desde el clic en el navegador hasta la respuesta visible, el tiempo del servidor de aplicaciones, el tiempo de llamada al proveedor y el tiempo de posprocesamiento. El proveedor puede seguir siendo rápido mientras se atasca la recuperación o una consulta a la base de datos. El tiempo del servidor puede parecer sano mientras el navegador espera un flujo bloqueado. Un solo temporizador invita al equipo a reparar la dependencia que ya tiene un gráfico.

Define un objetivo de servicio a partir de la tolerancia de los usuarios, no de un número redondo cómodo. Para una función de redacción, podrías exigir que el 95 % de los intentos válidos muestren el primer token útil dentro del margen de paciencia medido en el producto. En una extracción en segundo plano importa más el tiempo total de finalización. Fija esos límites a partir del comportamiento de referencia y de la investigación del producto; no copies umbrales de otra función.

Los histogramas de Prometheus permiten agregar controles de percentiles cuando los límites de los buckets coinciden con la decisión que necesitas tomar. La documentación de Prometheus advierte que los resúmenes del cliente y los histogramas calculados en el servidor tienen propiedades de agregación diferentes. Para un histograma clásico, una consulta útil por versión es:

histogram_quantile(0.95,
  sum by (le, app_version) (
    rate(ai_feature_duration_seconds_bucket{feature="support_reply",status="success"}[10m])
  )
)

Excluye los intentos fallidos solo cuando un gráfico de errores los muestre al lado del gráfico de latencia. De lo contrario, eliminar los tiempos de espera hace que la latencia parezca mejorar durante una interrupción. Mantén vistas separadas para llamadas correctas, todos los intentos terminales y tiempos de espera. Representa también el volumen de solicitudes, porque una caída del p95 durante un desplome del tráfico no es una recuperación.

En las respuestas en streaming, la latencia hasta el primer token y la latencia total pueden moverse en direcciones opuestas. Un cambio de prompt puede producir pronto un primer token, pero divagar durante el doble de tiempo. Los usuarios pueden percibir la función como rápida mientras se deterioran el coste de cómputo y el tiempo hasta una respuesta utilizable. Trata ambos temporizadores como controles de publicación independientes.

Después de la corrección, compara las distribuciones de latencia del segmento afectado con las de un segmento de control sin cambios. Exige observaciones suficientes para poblar la cola; un p99 basado en un puñado de intentos es puro teatro. Observa al mismo tiempo el crecimiento de los reintentos y la profundidad de la cola. Un p95 más bajo conseguido al abandonar más solicitudes con un tiempo de espera menor es un intercambio, no una reparación.

Cuenta los fallos silenciosos junto con las excepciones

La tasa de errores debe incluir cualquier intento que no pueda proporcionar el resultado prometido, no solo las excepciones y respuestas que no sean 2xx. Los tiempos de espera del proveedor, límites de tasa, salidas estructuradas mal formadas, respuestas vacías, rechazos por la política de contenido, fallos de herramientas, recuperación sin una fuente utilizable, rechazos de validación y reintentos agotados merecen categorías terminales explícitas. Si la aplicación los sustituye por un texto amable y devuelve 200, el usuario igualmente sufrió un fallo.

Usa estados terminales mutuamente excluyentes para que el denominador sea honesto. Empieza con success, user_error, system_error, policy_block y abandoned, y guarda debajo un motivo concreto. Decide por escrito si un resultado parcial cuenta como éxito para esa función. Un informe generado al que le falta una sección obligatoria puede ser un éxito parcial en un editor y un error del sistema en una exportación automatizada.

El control básico de producción es intentos válidos fallidos / todos los intentos válidos. Mantén los errores del usuario, como un tipo de archivo no compatible explicado antes de la inferencia, fuera del numerador de fiabilidad del sistema, pero muéstralos por separado. Un aumento repentino puede revelar una interfaz confusa o un cambio en la mezcla de entradas. Informa juntos de la tasa y el recuento. Un fallo en dos intentos y quinientos fallos en un millón plantean el mismo tipo de problema porcentual, pero a la inversa.

Los reintentos necesitan su propia tasa y distribución de intentos. Amazon Builders' Library explica que los reintentos añaden carga a una dependencia que quizá ya esté sobrecargada y que los reintentos en varias capas pueden multiplicar el trabajo. Esa advertencia se aplica directamente a las llamadas de IA, que son lo bastante lentas y caras como para que la amplificación duela. Registra qué capa reintentó, limita los intentos, usa espera incremental con jitter y emite el fallo original aunque un intento posterior tenga éxito.

Observa los errores recuperados como una señal temprana. Si el éxito se mantiene plano mientras aumenta la proporción de solicitudes que necesitan una segunda o tercera llamada al proveedor, la capacidad o la salud de la dependencia ya se han degradado. El usuario percibe más latencia y el equipo financiero ve más gasto antes de que cambie el gráfico de disponibilidad.

Configura alertas para consumo rápido y lento. Un pico brusco de errores necesita una ventana corta, mientras que un analizador de prompts que falle en una fracción adicional del tráfico durante días requiere una comparación más larga. Segmenta por versión, modelo, prompt, región, clase de cliente, franja de entrada y tarea. No generes alertas para cada segmento de forma independiente; dirige una alerta general y utiliza los segmentos para localizar el desgaste.

Para verificar una reparación, exige que el código de motivo afectado vuelva al nivel de referencia o lo mejore mientras también disminuyen los fallos totales. De lo contrario, el código puede haber cambiado de nombre al mismo fallo. Inspecciona una muestra de registros terminales y confirma que cada estado coincide con lo que recibió el usuario.

La calidad de salida necesita verdad tardía y señales indirectas en vivo

La calidad de salida del modelo no equivale a disponibilidad. Una respuesta fluida puede ser incorrecta, no estar respaldada, ser incompleta, insegura, tener un formato erróneo o resultar irrelevante mientras las métricas de infraestructura permanecen perfectas. Mide la calidad con una rúbrica específica de la tarea y separa las restricciones estrictas de los juicios graduados. Mezclarlos en una puntuación oculta qué falló.

Ejecuta controles estrictos en cada respuesta válida siempre que sea posible. Valida el JSON con su esquema, los campos obligatorios con las reglas de negocio, las citas con las fuentes recuperadas, los argumentos de las herramientas con listas permitidas y el idioma con la configuración regional solicitada. Registra cada control como un booleano o un motivo con nombre. Nunca dejes que una puntuación media anule una infracción de esquema que rompe el siguiente paso de la aplicación.

La evaluación gradual necesita una muestra estable y una rúbrica con criterios observables. Para un borrador de soporte, puntúa si responde a la solicitud del cliente, utiliza hechos presentes en el contexto aprobado, evita inventar políticas y ofrece una resolución que se pueda aplicar. Conserva la versión de la rúbrica, la del evaluador y la regla de muestreo en cada resultado. Cuando cambie el evaluador, aplica las versiones antigua y nueva a la misma muestra antes de unir sus series temporales.

Los evaluadores automáticos sirven para ampliar la cobertura, no como verdad incuestionable. Calíbralos con revisión humana, mide el desacuerdo por tarea e idioma y envía a personas los casos inciertos o de gran impacto. Un modelo que evalúa a otro puede cambiar cuando cambia cualquiera de los dos. Si el prompt de evaluación comparte el mismo punto ciego que el prompt de producción, el gráfico puede aprobar con seguridad un trabajo malo.

La guía de Google sobre ML en producción establece una distinción importante: la verdad de referencia en vivo suele llegar tarde o no llegar, por lo que los equipos necesitan métricas indirectas y deben prestar más atención a los cambios que a un valor bruto aislado. En las funciones generativas, algunas señales indirectas útiles son la tasa de aprobación del esquema, la tasa de respaldo de citas, la distancia de edición antes de aceptar, la tasa de regeneración, la tasa de copia o aceptación, las quejas y la finalización de la tarea posterior. Ninguna sirve para todo. Una tasa de copia alta puede indicar un borrador excelente, o que los usuarios copiaron el texto a otro lugar para repararlo.

Crea un pequeño conjunto etiquetado de forma continua a partir de tareas de producción reales y censuradas. Muestrea por segmentos importantes, no de forma puramente aleatoria, o la tarea fácil más frecuente dominará. Incluye fallos, entradas largas, idiomas poco comunes, clientes nuevos y solicitudes cercanas a los límites de la política. Revisa el mismo conjunto centinela fijo en cada versión para poder comparar y añade después una muestra rotatoria de producción para detectar cambios en el tráfico.

Declara degradación cuando una tasa de aprobación estricta incumpla su umbral de publicación, un criterio graduado caiga de forma relevante por debajo de su referencia con un tamaño de muestra adecuado o una señal indirecta del usuario cambie en la misma dirección que los hallazgos de los revisores. No exijas una cifra mágica de calidad. Las pruebas son más sólidas cuando coinciden los controles de restricciones, los revisores y el comportamiento, y resultan más interesantes cuando discrepan.

Una reparación pasa cuando el criterio que fallaba mejora en el segmento de tráfico original sin hacer retroceder la seguridad ni otro criterio de gran impacto. Lee ejemplos anteriores y posteriores. Las puntuaciones agregadas indican que algo se movió; los ejemplos emparejados indican si el cambio reparó el defecto real.

El uso de alternativas oculta una pérdida de capacidad

Una alternativa puede mantener la página en funcionamiento aunque la función de IA ya haya fallado. Controla la tasa de activación de alternativas como intentos que devolvieron una alternativa / intentos válidos, dividida por tipo y motivo. Controla también el éxito de la alternativa desde el punto de vista del usuario. Un consejo estático, un resultado en caché, un modelo más pequeño y un flujo manual no ofrecen un servicio equivalente.

Nombra cada ruta de forma explícita: cambio de proveedor, degradación de modelo, respuesta en caché, plantilla determinista, función desactivada o transferencia a una persona. Registra si el cambio ocurrió antes de la inferencia, después de una llamada fallida, tras la validación o cuando el usuario superó un tiempo de espera. Ese momento explica si la causa es capacidad, calidad, política o latencia.

Los equipos suelen incluir las respuestas alternativas correctas en la tasa de éxito principal. Así la disponibilidad parece estable mientras desaparece la capacidad prevista. Publica dos tasas: éxito de la ruta principal y éxito del resultado útil. La diferencia es la dependencia de la alternativa. Si el éxito principal cae respecto a su referencia pero la tasa de resultados se mantiene, la alternativa cumple su función y la ruta principal sigue degradada.

Fija un presupuesto de uso de alternativas a partir de las promesas del producto y la planificación de capacidad. Un modelo de conmutación puede ser aceptable para incidentes breves, pero caro o de menor calidad durante una semana. Una plantilla puede evitar una pantalla en blanco, pero no puede contar como una respuesta de investigación terminada. Añade una duración continua máxima además de un umbral de tasa para que el tráfico bajo no oculte una alternativa activada toda la noche.

Prueba las rutas alternativas con inyección controlada de fallos. Simula un tiempo de espera del proveedor, una salida no válida, una cuota agotada, la falta de contexto recuperado y un rechazo de validación. Confirma que el evento terminal nombra la causa original, la alternativa elegida, la latencia añadida y el resultado para el usuario. Una alternativa que nadie ejercita suele fallar justo cuando lo hace la ruta principal.

Tras una reparación, el éxito de la ruta principal debe recuperarse y la activación de alternativas debe volver al nivel de referencia. Comprueba que los operadores no se limitaron a desactivar el contador o mover la rama. Compara el número de llamadas al proveedor con los éxitos principales; las diferencias sin explicar suelen revelar un reintento o una ruta alternativa sin instrumentar.

El gasto en tokens debe seguir a un resultado terminado

El gasto en tokens se convierte en señal de degradación cuando la función consume más tokens de entrada o salida para completar la misma tarea con éxito. El total diario de tokens mide sobre todo el tráfico. Controla los tokens de entrada, salida y caché cuando corresponda, además del coste monetario por intento, y normalízalos por resultado aceptado o terminado.

Entre las medidas útiles están los tokens por intento válido, los tokens por éxito de la ruta principal, el coste por resultado aceptado y el coste por tarea posterior completada. Las dos últimas impiden que un modelo barato pero inútil parezca eficiente. Divide el gasto por modelo, versión del prompt, función, tarea, franja de entrada, número de reintentos y ruta alternativa. Mantén los precios en una tabla de consulta versionada en lugar de incrustar los precios actuales del proveedor en eventos históricos.

Las convenciones de IA generativa de OpenTelemetry definen atributos de uso de tokens y métricas de duración, distinguiendo tokens de entrada y salida. Proporcionan un vocabulario de transporte sensato. Tu aplicación todavía tiene que conectar el uso con accepted, edited, regenerated, abandoned o el resultado que aporte valor.

El crecimiento del prompt merece alertas directas. Registra por separado los tokens de instrucciones estáticas, el contenido del usuario y el contexto recuperado si tu sistema expone esos recuentos. Un error de plantilla puede duplicar la conversación, la recuperación puede adjuntar el mismo pasaje varias veces o un agente puede entrar en un bucle de herramientas. Los límites de salida pueden ocultar el síntoma de coste mientras el truncado perjudica la calidad, así que controla también el motivo de finalización y la tasa de truncado.

Usa una tarea de conciliación entre los eventos de la aplicación y las exportaciones de facturación del proveedor. La telemetría puede perderse, los reintentos pueden saltarse el envoltorio principal y el proveedor puede contabilizar de forma distinta los tokens en caché o de razonamiento. La conciliación no tiene que emparejar cada solicitud cuando el proveedor no ofrece identificadores, pero los totales por modelo y ventana temporal deben quedar dentro de la tolerancia acordada. Investiga el residuo en vez de multiplicar discretamente por un factor de corrección.

Una alerta práctica compara el coste por resultado correcto con un presupuesto fijo y con una referencia reciente comparable. Exige un volumen mínimo y excluye experimentos conocidos con presupuesto propio. Después empareja la alerta con las distribuciones de tokens. Una media superior puede deberse a un aumento legítimo de entradas largas, mientras que un p50 mayor dentro de cada franja de entrada apunta al crecimiento del prompt o del flujo de control.

Una reparación que reduce tokens pero baja la aceptación o aumenta el uso de alternativas ha trasladado el coste a los usuarios. Verifica las diferencias de tokens y dinero en la misma cohorte y después comprueba las protecciones de calidad, finalización y latencia. La eficiencia es la cantidad de trabajo útil por unidad de gasto, no la factura más pequeña.

El abandono conecta la salud del sistema con la paciencia

El abandono del usuario es la prueba más clara de que la función perdió su ventana útil, pero requiere una definición exacta del evento. Cuenta un intento como abandonado cuando el usuario cierra o deja la función antes de que aparezca un resultado utilizable, cancela la generación, inicia otro intento sin usar el primero o permanece inactivo más allá de un tiempo específico de la función. Mantén separados estos motivos.

El denominador debe ser el de intentos válidos que realmente comenzaron. No dividas por visitas a la página ni trates las desconexiones del navegador como abandonos sin comprobar si el trabajo continuó y el usuario volvió después. En trabajos en segundo plano, el abandono puede significar borrar la tarea o no abrir nunca el resultado dentro de un periodo definido. En un asistente integrado, cancelar y reintentar de inmediato son señales más fuertes.

Instrumenta el navegador y el servidor con el mismo identificador de solicitud. Emite marcas de tiempo para envío, primer token visible, resultado utilizable, cancelación, navegación, reintento, aceptación, edición y finalización posterior. Los eventos del cliente pueden perderse al cerrar una pestaña, así que usa un latido o un envío tipo sendBeacon cuando corresponda y etiqueta los resultados inciertos. No inventes certeza clasificando cada evento ausente como un usuario perdido.

Representa el abandono por franjas de latencia. Así aparece la curva de paciencia del producto: la proporción de intentos abandonados antes de 2, 5, 10 segundos y después, con límites adecuados para la función. Compara el tiempo hasta el primer resultado útil, no hasta cualquier token. Un preámbulo rápido que no dice nada puede mejorar la latencia del primer token sin retener a nadie.

Mide también la regeneración y el comportamiento de corrección. Los usuarios pueden esperar una respuesta mala y volver a intentarlo en vez de abandonar. Combina abandoned, cancelled y regenerated_before_use en una vista más amplia de intentos fallidos, pero conserva cada componente. La aceptación sin ediciones puede ayudar, aunque los flujos obligatorios y los clics accidentales la vuelven imperfecta.

La estacionalidad y la intención complican las métricas de comportamiento. Segmenta usuarios nuevos y recurrentes, tipo de tarea, clase de dispositivo y punto de entrada. Compara la misma hora y el mismo día de la semana cuando importen los patrones de tráfico. Usa una función sin cambios o un grupo de control cuando un problema general del sitio, una campaña de marketing o un cambio de interfaz puedan afectar al comportamiento.

Después de la corrección, la cohorte afectada debe mostrar menos abandono con un tráfico y una intención comparables. Confirma que no disminuyeron los inicios porque el botón se volvió más difícil de encontrar. Comprueba después la finalización posterior; mantener a los usuarios más tiempo ante un indicador de carga puede reducir las salidas registradas y empeorar la experiencia.

Segmenta primero y agrega después

La mayoría de los fallos de una función de IA afectan a un segmento antes que a toda la flota. Un prompt nuevo puede romper las entradas en español, una ruta de modelo puede fallar en una región, un cambio de recuperación puede perjudicar a documentos largos o la forma de los datos de un solo cliente puede activar un bucle de herramientas. Los promedios globales diluyen todos esos casos.

Adjunta dimensiones que correspondan a algo que puedas cambiar: versión de la aplicación, versión del prompt, modelo, proveedor, región, función, tarea, configuración regional, franja de entrada, versión del índice de recuperación, grupo del experimento y ruta alternativa. Para flujos con agentes, añade el nombre de la herramienta y el motivo de terminación. Usa clases de clientes que protejan la privacidad en lugar de mostrar su identidad en paneles amplios.

No crees una etiqueta de métrica para cada valor posible. La alta cardinalidad encarece la monitorización y vuelve poco fiables las consultas. Predefine franjas limitadas para tamaño de entrada, tamaño de salida, latencia y clase de cliente. Mantén los detalles exactos de la solicitud en las trazas o registros y salta desde un agregado sospechoso a intentos representativos.

Cada comparación de versiones necesita una tabla de cohortes. Muestra el número de solicitudes y la cuota de tráfico junto con latencia, fallos, aprobaciones de calidad estrictas, alternativas, coste por resultado y abandono. Compara candidato con control y estado actual con referencia. Si cambió la composición del tráfico, estratifica o vuelve a ponderar antes de afirmar una mejora.

La paradoja de Simpson es habitual en este ámbito. Cada tarea puede volverse más lenta y, aun así, mejorar el promedio global porque más tráfico pasó a una tarea rápida. Lo contrario puede condenar una buena versión que recibió entradas más difíciles. Inspecciona siempre los cambios dentro de cada tarea antes que la cifra combinada.

Las versiones canario ayudan a separar los efectos de la versión de los del tiempo. Dirige una proporción estable y determinista del tráfico válido al candidato, mantén la asignación fija para un usuario o flujo y registra tanto la elegibilidad como la asignación. Si solo llegan a analítica las asignaciones correctas, el experimento ya tiene sesgo de supervivencia antes del análisis.

Los segmentos pequeños exigen prudencia. Muestra intervalos de confianza o incertidumbre, fija recuentos mínimos y combina ventanas adyacentes cuando el incidente lo permita. No ignores un fallo de gran impacto porque la muestra sea pequeña; inspecciona los ejemplos y aplica una regla estricta de seguridad. La confianza estadística y la gravedad operativa responden a preguntas distintas.

Este trabajo de segmentación suele dejar al descubierto código de aplicaciones generado por IA que dispersó las llamadas al modelo entre varias rutas sin un envoltorio común. FixMyMess usa diagnóstico del código y verificación experta al reparar ese tipo de ruta de producción, pero el resultado duradero sigue dependiendo de un único contrato de instrumentación que deba cumplir el código futuro.

Una reparación solo pasa con un criterio de pruebas escrito

Una corrección está completa cuando una comparación predefinida muestra recuperación en la señal rota, protege las demás señales y resiste tráfico real durante el tiempo suficiente para cubrir el modo de fallo. «El gráfico parece mejor» no es un criterio de aceptación. Escribe el criterio antes del despliegue para que el equipo no pueda elegir después una ventana favorecedora.

Usa esta secuencia para un incidente o una reparación planificada:

1. Fija la cohorte del incidente. Registra la función, tarea, versiones, ruta del modelo, regiones, franjas de entrada y ventana temporal afectadas. Guarda identificadores de solicitudes representativos sin contenido sensible.
2. Expresa el fallo en términos medibles. Indica la métrica principal, la referencia, el valor observado, el umbral y la muestra mínima. Añade protecciones para la tasa de errores, controles estrictos de calidad, uso de alternativas, coste por resultado y abandono.
3. Despliega en un canario determinista. Confirma que la telemetría está completa antes de juzgar el código. El candidato y el control deben recibir tráfico válido comparable, y cada intento debe alcanzar un estado terminal.
4. Compara distribuciones y ejemplos. Contrasta el candidato con el control y después ambos con la referencia histórica. Revisa tareas fallidas emparejadas o un conjunto centinela fijo para que un cambio agregado no oculte el defecto original.
5. Promueve, mantén o revierte según el criterio escrito. Sigue observando durante el siguiente ciclo de tráfico relevante y registra después los resultados de las consultas y los identificadores de versión junto con la decisión.

Un criterio podría decir: la latencia total p95 para redactar documentos largos debe volver por debajo del umbral anterior al incidente durante al menos el número de solicitudes acordado; las tasas de tiempo de espera y alternativa no deben superar la referencia; la aprobación del esquema y las puntuaciones de los revisores no deben caer; el coste por borrador aceptado debe respetar el presupuesto; el abandono debe mejorar frente al control. Los valores reales deben proceder de la referencia de tu producto y de su tolerancia al riesgo.

Incluye la integridad de la telemetría en el criterio. Compara los inicios de intento con los eventos terminales, las llamadas al proveedor con los registros de uso y las acciones aceptadas con las tasas conocidas de entrega del cliente. Si una versión pierde el 15 % de los eventos terminales, todas las tasas posteriores pueden parecer mejores. Bloquea la promoción cuando el cambio en los datos ausentes baste para alterar la conclusión.

Mantén los criterios de reversión separados de los umbrales de alerta. Una alerta pide que alguien investigue. Una regla de reversión afirma que el candidato ha causado daño suficiente para detener la exposición. Las infracciones de calidad o seguridad pueden exigir una reversión inmediata por un solo caso confirmado, mientras que un cambio moderado de latencia necesita una muestra estable.

Ejecuta una evaluación en sombra o por repetición cuando la exposición real implique un riesgo alto, pero no la llames prueba de producción. Las repeticiones no reproducen las colas en vivo, los límites del proveedor, el comportamiento del navegador, los cambios en los datos recuperados ni las reacciones de los usuarios. Reducen la incertidumbre antes del canario; no lo sustituyen.

El paquete final de pruebas debe permitir que un ingeniero escéptico reproduzca la decisión: definición de cohorte, texto de consultas, definiciones de métricas, ventanas de referencia y candidato, tamaños de muestra, incertidumbre, ejemplos revisados, cobertura de telemetría y resultado de promoción. Si el paquete no puede explicar por qué los usuarios están mejor y cuánto costó conseguirlo, la corrección sigue siendo una opinión.