Tests de régression pour agents IA

Idée en 30 secondes

Le regression testing pour agents IA compare candidate à baseline sur les mêmes cas et dans les mêmes conditions.

Sa valeur principale est de montrer précisément où le comportement du système a changé après des modifications de modèle, prompts, outils ou runtime.

Le problème

Sans regression testing, l'équipe voit souvent seulement un signal global "mieux/pire", sans savoir ce qui s'est cassé exactement.

Conséquences typiques :

• des régressions discrètes passent en release ;
• des scénarios critiques se dégradent alors que le résultat moyen semble correct ;
• il devient difficile d'expliquer si la cause vient du code, du modèle, du prompt ou des conditions de run.

Au final, la release paraît sûre, mais des incidents répétitifs apparaissent en production.

Quand l'utiliser

Le regression testing est nécessaire dès que des changements peuvent affecter le comportement de l'agent :

• version du modèle mise à jour ;
• prompt ou règles de policy modifiés ;
• outils ajoutés ou refactorés ;
• paramètres runtime modifiés (timeouts, retries, limits).

Le regression testing répond à une question : qu'est-ce qui a changé entre versions du système.

Il faut aussi le lancer après des incidents, pour vérifier qu'un correctif n'a pas cassé des scénarios voisins.

Implémentation

En pratique, la règle est unique : mêmes cas, mêmes conditions de run, et comparaison avec un baseline figé. Les exemples ci-dessous sont schématiques et non liés à un framework précis.

Comment cela fonctionne sur un run

Un run de regression exécute généralement le même eval harness, mais avec comparaison des résultats contre baseline.

1. Figer baseline et version du dataset

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

baseline doit être lié à une version précise du dataset, du modèle et des conditions de run.

2. Exécuter candidate dans les mêmes conditions

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"],
    )

Sans conditions identiques, diff devient vite bruité et perd sa valeur diagnostique.

3. Calculer diff avec des seuils de risque

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

Les seuils doivent être explicites pour garder des décisions de release déterministes.

4. Regarder les cas, pas seulement le 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

Même si le summary semble correct, des régressions sur des cas critiques doivent bloquer la release.

5. Ajouter regression gate dans 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}")

Le regression gate doit être obligatoire pour les changements qui touchent modèle, prompts, outils ou runtime.

Notes pour QA et l'automatisation

Les équipes QA lancent généralement regression après une mise à jour de modèle ou de prompt pour voir immédiatement le diff de comportement contre baseline.

En pratique, cela devient un run CI obligatoire pour les changements de configuration model/prompt et une suite de regression complète planifiée pour suivre les dégradations lentes.

Erreurs typiques

Écrasement automatique de baseline

L'équipe perd un point de comparaison stable, et l'historique des régressions devient flou.

Cause typique : baseline est mis à jour automatiquement sans décision explicite.

Conditions de run différentes entre baseline et candidate

Les runs sont comparés, mais avec des timeouts, un modèle ou des mocks différents.

Cause typique : pas de runtime config figé pour regression.

Comparer seulement des métriques globales

Le résultat moyen paraît correct, mais des cas critiques se dégradent.

Cause typique : pas de diff au niveau cas dans le rapport.

Pas de seuils clairs pour CI gate

La décision de release est prise "au ressenti", et le signal de regression est perdu.

Cause typique : seuils non fixés dans les règles CI.

Cas instables dans le set de regression

Le même cas passe puis échoue de façon aléatoire, et l'équipe ne fait plus confiance au rapport.

Cause typique : des scénarios flaky sont entrés dans le set principal sans stabilisation.

En bref

FAQ

Q : Quelle différence entre regression testing et eval harness ?
R : Eval harness exécute un run standardisé, et regression testing utilise ce run pour comparer candidate contre baseline.

Q : Quand mettre à jour baseline ?
R : Après une release confirmée, quand l'équipe accepte explicitement le nouveau comportement comme référence.

Q : Qu'est-ce qui bloque le plus souvent une release dans regression gate ?
R : Dégradation de cas critiques, baisse de task_success_rate, forte hausse de latency ou de token cost.

Q : Les cas synthétiques suffisent-ils pour regression ?
R : Pour démarrer oui, mais un signal plus solide vient de la combinaison de cas synthétiques et de scénarios replay issus de production.

Et ensuite

Après avoir configuré le regression gate, branchez les cas stables via Golden Datasets et les runs standardisés via Eval Harness. Pour les vérifications locales de logique, utilisez Unit Testing, et analysez les incidents avec Replay and Debugging.