Regression Testing
Detectar degradación después de cambios
Regression Testing es la práctica de volver a evaluar comportamientos importantes después de un cambio para detectar si una propiedad previamente aceptable se degradó. En sistemas AI el cambio puede estar en el modelo, prompt, retrieval, herramientas, routing, guardrails, código, dependencias, configuración o datos. El objetivo no es demostrar que el sistema es perfecto, sino descubrir una pérdida relevante frente a una referencia y condiciones declaradas.
Una regresión puede ser una respuesta incorrecta nueva, una herramienta que deja de usarse apropiadamente, una caída de groundedness, una violación de formato, un costo o una latencia que supera el contrato, un rechazo excesivo o una acción fuera de alcance. La propiedad evaluada debe corresponder al uso. Cambiar una redacción sin afectar el contrato no es necesariamente una regresión; cambiar una decisión de permisos aunque el texto suene mejor sí puede serlo.
AI Regression y software regression
Las pruebas tradicionales suelen comprobar comportamiento exacto bajo assertions y entradas controladas. AI Regression puede usar esas assertions cuando el resultado es exacto, y también scores graduados, tolerancias, distribuciones, varias muestras, graders humanos o model-based. No son prácticas opuestas: un sistema AI incluye componentes deterministas y propiedades semánticas que requieren evidencia distinta.
Un cambio puede pasar tests de tipos y romper una respuesta, o mantener una respuesta aceptable y modificar un estado de herramienta. La suite debe observar las fronteras relevantes. Un snapshot visual, un schema check, un test de ejecución y un juicio de groundedness aportan señales diferentes. Ejecutar más veces el mismo check no compensa que el check no cubra el riesgo.
Dataset de regresión
Un dataset estable o versionado de casos representativos, históricos y críticos permite comparar antes y después. Puede reutilizar un Evaluation Dataset, pero su propósito es detectar degradación recurrente alrededor de cambios. No debe permanecer congelado para siempre: incorporar fallos significativos y retirar casos obsoletos puede mejorar la cobertura, siempre conservando versiones que permitan interpretar la serie.
Cuando aparece un fallo relevante, conviene considerar convertirlo en un caso de regresión. Un incidente no siempre se traduce en un prompt estático: puede depender de estado, secuencia, timing, servicio externo, permisos o distribución de datos. El caso debe capturar la propiedad que se quiere conservar y documentar qué parte del incidente se reproduce. Una simplificación útil no debe presentarse como replay completo.
Los casos deben conservar contrato, versión, criterios, referencia o rúbrica y cualquier condición de entorno necesaria. Un caso que fue editado para aceptar el comportamiento nuevo puede borrar evidencia de la regresión. Si la referencia anterior era errónea, la corrección debe registrar motivo, evidencia y fecha, no ocultarse como una actualización rutinaria.
Qué cuenta como cambio
El diff relevante no es solo el diff de código. Actualizar un modelo, tokenizer, prompt, retrieval index, embedding, fuente, schema, herramienta, threshold, guardrail, dependencia o configuración puede cambiar el comportamiento. La suite debe identificar qué versiones y condiciones representan la ejecución, especialmente cuando una mejora o caída no puede atribuirse a una sola capa.
Un cambio grande puede necesitar evaluar el sistema end-to-end. Un cambio localizado puede beneficiarse de un check específico y una suite más amplia. La profundidad depende del riesgo, reversibilidad y alcance. No existe una lista universal que deba ejecutarse completa para cada modificación, pero los criterios de selección deben ser explicables.
No determinismo y repetición
Non-Determinism recuerda que una ejecución distinta no prueba por sí sola regresión. Pueden haber cambiado contexto, estado, versión, servicio externo, retrieval, scheduling o selección de salida. Del mismo modo, un solo run igual no demuestra ausencia de degradación. Comparar requiere conocer las condiciones o reconocer la incertidumbre.
Según la tarea puede ser útil repetir casos, estimar pass rate, observar una distribución o conservar múltiples muestras. No todos los casos requieren múltiples runs: un schema determinista o una incompatibilidad de contrato puede necesitar una sola evidencia clara, mientras una respuesta abierta puede variar legítimamente. La cantidad de repeticiones debe seguir la propiedad y el costo de error.
La comparación debe distinguir variación esperada de pérdida del contrato. Una formulación diferente puede ser aceptable; un dato inventado no. Un score promedio más bajo puede provenir de una muestra distinta; un fallo crítico nuevo puede bloquear aunque el promedio mejore. La interpretación no debe reducirse a una única cifra.
Umbrales y gates
Un regression gate puede usar cero tolerancia para fallos críticos, un umbral absoluto, un cambio relativo, una distribución aceptable, intervalos de incertidumbre o criterios específicos por tarea. No se prescribe un porcentaje universal. Un límite apropiado depende de impacto, frecuencia, reversibilidad, capacidad de detectar después y costo de una falsa aceptación o rechazo.
Los gates pueden distinguir severity. Una caída pequeña en una tarea de bajo riesgo puede requerir revisión; una nueva exposición de datos, acción no autorizada o pérdida de contrato puede bloquear inmediatamente. También conviene diferenciar failure del sistema, failure del grader, timeout, caso no aplicable y ejecución incompleta. Si todos se convierten en pass/fail sin estado, el gate puede ocultar incertidumbre.
Una comparación relativa necesita baseline compatible. Cambiar dataset, grader, modelo y threshold a la vez puede hacer que un delta no sea interpretable. Si la comparación conjunta es la decisión real, debe declararse como evaluación del sistema completo. Si se quiere atribuir una causa, hay que controlar o aislar los demás cambios cuando sea posible.
Regression Testing y Evaluation
Regression Testing utiliza evaluación para una finalidad temporal y comparativa: saber si un cambio degradó un comportamiento. AI Evaluation es más amplia e incluye definir calidad, comparar alternativas, caracterizar capacidades y entender límites sin que exista un baseline previo. Un dataset de evaluación puede servir para regresión, pero no todo caso de evaluación necesita ejecutarse en cada cambio.
La regresión también puede usar tests exactos, smoke checks, graders automáticos, revisión humana o tareas de ejecución. La etiqueta regression no convierte un test en un benchmark ni una suite en una representación completa de producción. La conclusión debe decir qué casos se repitieron, qué versión de baseline se comparó y qué quedó fuera.
Regression Testing y CI
CI es un mecanismo para ejecutar validaciones en cambios de software y comunicar resultados. Regression Testing es el propósito de detectar degradación. Una evaluación de regresión puede ejecutarse dentro de CI, en un job nocturno, antes de un release o en un entorno separado. No todo CI check es regresión y no toda regresión puede permitirse en el tiempo o entorno de cada pull request.
Los equipos pueden tener gates rápidos y suites profundas. Un gate rápido puede comprobar formato, casos críticos y cambios obvios; una suite más costosa puede evaluar diversidad, varias muestras, herramientas o revisión humana. Separar frecuencia y severidad evita elegir una suite inútilmente pequeña o bloquear cada cambio por una señal inestable. El resultado debe conservar qué job se ejecutó y qué versión de casos representó.
Regression Testing y Monitoring
Regression Testing suele evaluar casos controlados, replay o preparados alrededor de cambios. Monitoring observa señales de un sistema desplegado a lo largo del tiempo: errores, latencia, volumen, recursos o indicadores operativos. Ambos pueden detectar deterioro, pero responden a contextos diferentes.
Un monitor puede disparar una investigación o añadir un caso de regresión; una suite de regresión puede pasar mientras una distribución real cambia. Monitoring no es automáticamente evaluación de calidad y Regression Testing no sustituye observación operacional. Evaluation in Production, Drift, MLOps y AI Observability conservan sus propios alcances y no se materializan aquí.
Fallos derivados y mantenimiento
Una suite de regresión pierde valor si solo conserva casos fáciles o si se actualiza para eliminar todo fallo incómodo. Los cambios de datos, modelos y productos pueden volver obsoleta una referencia. Revisar casos requiere preguntar si la propiedad sigue siendo parte del contrato, si el entorno es reproducible y si el caso distingue el riesgo que importa.
Los resultados también deben clasificarse por dimensión. Una modificación puede mejorar correctness y empeorar latencia, tool use o cobertura de un idioma. Reportar solo la dimensión que mejoró permite una regresión parcial. La decisión puede aceptar un trade-off, pero debe hacerlo de manera explícita y con autoridad para el producto.
Diagnóstico de una regresión
Cuando un gate falla, el siguiente paso no es asumir que el último cambio es la única causa. Conviene comparar el caso, el resultado previo, el resultado nuevo, el contexto, el grader y el entorno. El fallo puede estar en el sistema, en una referencia obsoleta, en un servicio externo, en una ejecución incompleta o en el propio evaluador. Un diagnóstico útil conserva la diferencia observable y la hipótesis, sin presentar una causa no confirmada como hecho.
Los fallos pueden agruparse por propiedad: formato, contenido, evidencia, herramienta, estado, permisos, latencia, costo o seguridad. La agrupación ayuda a decidir si se necesita corregir el sistema, añadir cobertura, cambiar el grader o revisar el contrato. Un test que falla por un mensaje de error distinto puede ser una regresión de interfaz, una mejora compatible o una assertion demasiado específica; la etiqueta depende del requisito.
Una respuesta aceptable puede cambiar de texto y seguir cumpliendo el contrato. Por eso las regresiones semánticas necesitan criterios que describan la propiedad, no solo snapshots literales. Los snapshots siguen siendo útiles para interfaces o artefactos donde la forma exacta importa. La técnica debe seguir el tipo de comportamiento.
Integración con el cambio
La suite puede ejecutarse antes de modificar el sistema para establecer un baseline, después del cambio y en una revisión posterior si el entorno externo es variable. Registrar las versiones evita comparar el resultado nuevo con una ejecución antigua que utilizó otro índice, prompt o grader. Cuando el baseline no está disponible, la evaluación puede aportar evidencia de estado actual, pero no debe llamarse regresión confirmada sin una referencia.
Los casos críticos pueden ejecutarse en cada cambio y los casos amplios en una cadencia distinta. Un resultado pendiente puede exigir revisión antes de publicar, mientras una señal exploratoria puede alimentar análisis sin bloquear. La política debe decir qué ocurre ante timeout, ausencia de referencia, fallo del grader o cambio de dataset. Un gate que simplemente reintenta hasta verde puede ocultar una inestabilidad real.
No toda mejora de score justifica desplegar. Puede coexistir con un fallo nuevo en un caso crítico, una mayor latencia o una disminución en un idioma minoritario. La revisión debe evaluar el conjunto de criterios y la autoridad de la decisión. Regression Testing aporta evidencia; no decide por sí solo todos los trade-offs del producto.
La suite también necesita observar falsos alarms y regresiones que no detectó. Si un gate bloquea muchos cambios por variación irrelevante, el equipo puede dejar de atenderlo o relajar un threshold sin comprender el riesgo. Si nunca falla pese a cambios que usuarios reportan como degradación, su cobertura u oráculo son insuficientes. Revisar periódicamente casos, graders y decisiones mantiene el propósito vivo.
Fuentes y alcance
Fuentes consultadas: OpenAI Evals, Anthropic, Demystifying evals for AI agents, y Google Cloud generative AI evaluation. Este canonical trata regresión como propósito de evaluación y no materializa CI, Monitoring, Drift, MLOps u Observability.