Pruebas de regresión para agentes de IA

Idea en 30 segundos

Regression testing para agentes de IA compara candidate con baseline sobre los mismos casos y bajo las mismas condiciones.

Su valor principal es mostrar exactamente dónde cambió el comportamiento del sistema después de cambios en modelo, prompts, herramientas o runtime.

Problema

Sin regression testing, el equipo suele ver solo un "mejor/peor" general, pero no entiende qué se rompió exactamente.

Consecuencias típicas:

• regresiones sutiles llegan a release;
• escenarios críticos empeoran aunque el resultado promedio parezca normal;
• es difícil explicar si la causa está en cambios de código, modelo, prompt o condiciones de ejecución.

Al final, la release parece segura, pero en producción aparecen incidentes repetidos.

Cuándo usarlo

Regression testing es necesario cada vez que los cambios puedan afectar el comportamiento del agente:

• se actualizó la versión del modelo;
• se cambió el prompt o reglas de policy;
• se agregaron o rediseñaron herramientas;
• se cambiaron ajustes de runtime (timeouts, retries, límites).

Regression testing responde una pregunta: qué cambió entre versiones del sistema.

También conviene ejecutarlo después de incidentes, para verificar que el arreglo no rompió escenarios cercanos.

Implementación

En la práctica, regression testing sigue una regla: mismos casos, mismas condiciones de ejecución y comparación contra baseline fijado. Los ejemplos de abajo son esquemáticos y no dependen de un framework concreto.

Cómo funciona en una ejecución

Una ejecución de regression suele correr el mismo eval harness, pero comparando resultados contra baseline.

1. Fijar baseline y versión de dataset

regression_context = {
    "dataset_version": "golden-v1.4",
    "baseline_report": "reports/baseline-golden-v1.4.json",
    "model_version": "gpt-4o-2024-08-06",
}

baseline debe quedar ligado a una versión concreta de dataset, modelo y condiciones de ejecución.

2. Ejecutar candidate en las mismas condiciones

def run_candidate(agent, dataset, runtime_config):
    return run_eval_suite(
        agent=agent,
        dataset=dataset,
        timeout_sec=runtime_config["timeout_sec"],
        max_steps=runtime_config["max_steps"],
        tool_mocks=runtime_config["tool_mocks"],
    )

Sin condiciones iguales, diff se vuelve ruidoso rápido y pierde valor diagnóstico.

3. Calcular diff con umbrales de riesgo

def compare_summary(candidate, baseline):
    deltas = {
        "task_success_drop": baseline["task_success_rate"] - candidate["task_success_rate"],
        "latency_growth": candidate["p95_latency"] - baseline["p95_latency"],
        "cost_growth": candidate["avg_token_cost"] - baseline["avg_token_cost"],
    }
    return deltas

Los umbrales deben definirse explícitamente para que la decisión de release sea determinista.

4. Revisar casos, no solo summary

def critical_case_regressions(case_diffs):
    bad = []
    for diff in case_diffs:
        if diff["status"] == "regressed" and "critical" in diff["tags"]:
            bad.append(diff["case_id"])
    return bad

Aunque el summary se vea bien, caídas en casos críticos deben bloquear release.

5. Añadir regression gate en CI

deltas = compare_summary(candidate_summary, baseline_summary)
critical_failures = critical_case_regressions(case_diffs)

if deltas["task_success_drop"] > 0.03:
    fail("gate_failed:task_success_drop")
if deltas["latency_growth"] > 800:  # ms
    fail("gate_failed:latency_growth")
if critical_failures:
    fail(f"gate_failed:critical_cases:{critical_failures}")

Regression gate debe ser obligatorio para cambios que impactan modelo, prompts, herramientas o runtime.

Notas para QA y automatización

Los equipos de QA suelen ejecutar regression tras actualizar modelo o prompt para ver de inmediato el diff de comportamiento frente a baseline.

En práctica esto funciona como ejecución CI obligatoria para cambios de configuración model/prompt y como suite completa programada de regression para detectar degradaciones lentas.

Errores típicos

Sobrescritura automática de baseline

El equipo pierde un punto de comparación estable y el historial de regresiones se vuelve difuso.

Causa típica: baseline se actualiza automáticamente sin una decisión explícita.

Condiciones de ejecución distintas entre baseline y candidate

Se comparan ejecuciones con timeouts, modelo o mocks diferentes.

Causa típica: no existe runtime config fijo para regression.

Comparar solo métricas globales

El resultado promedio parece correcto, pero los casos críticos se degradan.

Causa típica: el reporte no incluye diff por caso.

Sin umbrales claros para CI gate

La decisión de release se toma "a ojo" y la señal de regression se pierde.

Causa típica: umbrales no fijados en reglas de CI.

Casos inestables en el set de regression

El mismo caso a veces pasa y a veces falla, y el equipo deja de confiar en el reporte.

Causa típica: escenarios flaky entraron al set principal sin estabilización.

Resumen

FAQ

Q: ¿En qué se diferencia regression testing de eval harness?
A: Eval harness ejecuta una corrida estandarizada, y regression testing usa esa corrida para comparar candidate contra baseline.

Q: ¿Cuándo actualizar baseline?
A: Después de una release confirmada, cuando el equipo acepta explícitamente el nuevo comportamiento como referencia.

Q: ¿Qué suele bloquear una release en regression gate?
A: Degradación en casos críticos, caída de task_success_rate, aumento fuerte de latency o de token cost.

Q: ¿Bastan casos sintéticos para regression?
A: Para empezar sí, pero una señal más estable sale de combinar casos sintéticos con escenarios replay de producción.

Qué sigue

Después de configurar regression gate, conecta casos estables mediante Golden Datasets y corridas estandarizadas mediante Eval Harness. Para validar lógica local usa Unit Testing, y analiza incidentes con Replay and Debugging.