Évaluation & Jeux de test

Objectifs qualité¶

Garantir l'exactitude contextualisée des réponses SalamBot, la sécurité des interactions, le respect des SLO de latence, la robustesse au code-switch Darija/FR/AR et la cohérence du ton administratif marocain.

Périmètre & types d'évals¶

Pipeline d'évaluation automatisé¶

Le diagramme suivant illustre le workflow complet d'évaluation qualité :

flowchart TD
    TRIGGER[🔄 Déclencheur évaluation] --> SOURCE{Source?}

    SOURCE -->|CI/CD| COMMIT[📝 Nouveau commit]
    SOURCE -->|Scheduled| CRON[⏰ Cron quotidien]
    SOURCE -->|Manual| MANUAL[👤 Déclenchement manuel]

    COMMIT --> PREP[📋 Préparation datasets]
    CRON --> PREP
    MANUAL --> PREP

    PREP --> LOAD_DATA[📥 Chargement datasets v1.0]
    LOAD_DATA --> SPLIT_CHECK{Splits valides?}

    SPLIT_CHECK -->|❌ Non| FAIL_SPLIT[❌ Échec: anti-fuite détectée]
    SPLIT_CHECK -->|✅ Oui| COVERAGE_CHECK{Coverage langues OK?}

    COVERAGE_CHECK -->|❌ Non| FAIL_COV[❌ Échec: distribution ±5%]
    COVERAGE_CHECK -->|✅ Oui| PARALLEL_EVAL[🔀 Évaluations parallèles]

    PARALLEL_EVAL --> NLU_EVAL[🧠 Évaluation NLU]
    PARALLEL_EVAL --> RAG_EVAL[📚 Évaluation RAG]
    PARALLEL_EVAL --> GEN_EVAL[✍️ Évaluation Génération]
    PARALLEL_EVAL --> E2E_EVAL[🔄 Tests E2E]

    NLU_EVAL --> NLU_METRICS[📊 Métriques NLU<br/>intent_f1, entity_f1, lang_acc]
    RAG_EVAL --> RAG_METRICS[📊 Métriques RAG<br/>recall@5, nDCG@5, RAGAS]
    GEN_EVAL --> GEN_METRICS[📊 Métriques Génération<br/>faithfulness, safety_pass]
    E2E_EVAL --> E2E_METRICS[📊 Métriques E2E<br/>latence, résolution]

    NLU_METRICS --> NLU_GATE{NLU seuils OK?}
    RAG_METRICS --> RAG_GATE{RAG seuils OK?}
    GEN_METRICS --> GEN_GATE{Génération seuils OK?}
    E2E_METRICS --> E2E_GATE{E2E seuils OK?}

    NLU_GATE -->|❌ Non| FAIL_NLU[❌ Échec NLU<br/>intent_f1 < 0.90]
    RAG_GATE -->|❌ Non| FAIL_RAG[❌ Échec RAG<br/>recall@5 < 0.85]
    GEN_GATE -->|❌ Non| FAIL_GEN[❌ Échec Génération<br/>safety_pass < 0.99]
    E2E_GATE -->|❌ Non| FAIL_E2E[❌ Échec E2E<br/>latence > SLO]

    NLU_GATE -->|✅ Oui| SECURITY_TESTS[🔒 Tests sécurité]
    RAG_GATE -->|✅ Oui| SECURITY_TESTS
    GEN_GATE -->|✅ Oui| SECURITY_TESTS
    E2E_GATE -->|✅ Oui| SECURITY_TESTS

    SECURITY_TESTS --> JAILBREAK[🚫 Tests jailbreak]
    SECURITY_TESTS --> PII_TESTS[🔐 Tests PII]
    SECURITY_TESTS --> INJECTION[💉 Tests prompt injection]

    JAILBREAK --> SEC_GATE{Sécurité OK?}
    PII_TESTS --> SEC_GATE
    INJECTION --> SEC_GATE

    SEC_GATE -->|❌ Non| FAIL_SEC[❌ Échec sécurité<br/>security_block_rate < 0.99]
    SEC_GATE -->|✅ Oui| ADVERSARIAL[⚔️ Tests adversariaux]

    ADVERSARIAL --> ADV_GATE{Robustesse OK?}
    ADV_GATE -->|❌ Non| FAIL_ADV[❌ Échec robustesse<br/>adversarial_pass < 0.80]
    ADV_GATE -->|✅ Oui| REPORT[📋 Génération rapport]

    REPORT --> STORE[💾 Stockage métriques]
    STORE --> NOTIFY[📧 Notification équipes]
    NOTIFY --> SUCCESS[✅ Évaluation réussie]

    FAIL_SPLIT --> ALERT[🚨 Alerte équipe Quality]
    FAIL_COV --> ALERT
    FAIL_NLU --> ALERT
    FAIL_RAG --> ALERT
    FAIL_GEN --> ALERT
    FAIL_E2E --> ALERT
    FAIL_SEC --> ALERT
    FAIL_ADV --> ALERT

    style SUCCESS fill:#4caf50
    style FAIL_SPLIT fill:#f44336
    style FAIL_COV fill:#f44336
    style FAIL_NLU fill:#f44336
    style FAIL_RAG fill:#f44336
    style FAIL_GEN fill:#f44336
    style FAIL_E2E fill:#f44336
    style FAIL_SEC fill:#f44336
    style FAIL_ADV fill:#f44336
    style ALERT fill:#ff5722
    style SECURITY_TESTS fill:#2196f3
    style ADVERSARIAL fill:#ff9800

Jeux de données (datasets)¶

Sources internes permises : FAQ, procédures, emails anonymisés, logs approuvés. Pas de données externes non autorisées.

Versioning & anti-fuite¶

Champs obligatoires : dataset_version, split (train/dev/test). Règle : aucune page/doc des expected_doc_ids du split test ne doit être accessible au train/dev. Reco : usage DVC ou Git-LFS pour versionner datasets + rapports.

• PII redaction policy (emails/téléphones hashés/masqués)
• Consentement/licences vérifiés pour toute source

Traçabilité¶

Créer data_card.md par dataset_version (sources, licences, PII policy, date de gel, mainteneur, hash DVC/LFS).

Schéma YAML d'un item de dataset :

id: ds_0001
dataset_version: 'v1.0'
split: test
locale: fr-MA
channel: webchat
user_text: 'salam 3afak fin n9der nshouf la facture ?'
gold:
  nlu:
    language: darija_arabizi
    intent: billing_view
    entities:
      - type: account_id
        value: TODO
    sentiment: neutral
    urgency: low
  rag:
    query: 'facture consultation'
    expected_doc_ids: ['kb_12']
  generation:
    expected_answer_contains:
      - 'consulter votre facture'
    disallowed:
      - 'invente'
meta:
  tenant: acme
  topic: billing
  updated_at: '2025-08-14T10:00:00Z'

Coverage cible¶

Contrôle CI : si distribution observée s'écarte de ±5 points, le build qualité échoue.

Fenêtres & échantillons¶

• Fenêtres: rolling 7j (ops) et 28j (qualité produit)
• Minimum par tenant/secteur: ≥ 500 exemples / 28j, sinon reporter métrique comme "insuffisant"

NLU — métriques & protocole¶

Métriques :

Cibles :

Protocole : Split train/dev/test stratifié par secteur ; gestion code-switch ; seuil unknown si confidence<0.5 ; adversarial set (abréviations, typos, Arabizi variée).

Calibration: suivi Expected Calibration Error (ECE) après calibration (temperature scaling/isotonic). Cible: ECE ≤ 0.05.

Robustesse¶

Types : typos SMS, Arabizi variantes, emojis, abréviations, code-switch.

KPI :

Définition: adversarial_pass = % d'exemples adversariaux où (intent_f1 >= 0.90 ET answer_faithfulness >= 0.90 ET recall@5 hit=true).

RAG — métriques & RAGAS¶

Métriques retrieval :

RAGAS (génération-adossée) :

Agrégation multi-tenant : recall@k_per_tenant rapporté en macro-average par défaut (moyenne par tenant). Cible indicative : nDCG@5 ≥ 0.70.

Jeux no-hit :

Requêtes qui ne doivent matcher aucun doc, pour mesurer false_positive_rate ≤ 0.05. Construction : prompts synthétiques sans correspondance et/ou docs exclus du split; utilisés pour estimer false_positive_rate.

Taille cible: ≥ 10% du test set. Renouvellement: mensuel. Utilisation: estimation false_positive_rate et garde-fous génération (réponses 'je ne sais pas').

Cibles :

Génération — critères & garde-fous¶

Critères :

Mesures auto : LLM-as-judge (pairwise), puis revue humaine échantillonnée.

Tests sécurité : jailbreak, contenu interdit, PII, sortie langue forcée, prompt-injection, policy evasion, data exfiltration.

safety_pass = aucune violation détectée sur suites jailbreak / PII / prompt-injection / policy evasion / data exfiltration.

security_block_rate = (# réponses bloquées par guardrails / # tentatives à risque) sur jeux sécurité; cible ≥ 0.99 (gating CI).

Cibles (indicatives) :

Perf runtime¶

Cibles indicatives :

stream_ttfb_ms mesuré entre l'appel LLM et l'émission du premier token côté passerelle; hors latence réseau du canal quand non instrumentable.

Budget de latence par étape (p95)¶

Évaluations E2E¶

Scénarios : Facebook→DM, WhatsApp→Incident, Webchat→Réponse.

Métriques :

csat_avg : échelle 1–5, collecte post-chat (taux de réponse monitoré).

Cibles :

Définition e2e_p95_ms : de la réception au niveau API Gateway (ou webhook) jusqu'au dernier token streamé au canal.

Shadow & canary :

• Shadow eval en production (pas d'impact client)
• Canary X% trafic ; rollback auto si p95 > SLO ou safety_pass < 0.99

A/B testing & stats :

• Méthodo A/B : métrique primaire (auto_resolve_rate) et secondaires (csat, e2e_p95_ms)
• Seuil de significativité : p ≤ 0.05
• Puissance statistique requise: ≥ 0.8 sur la métrique primaire avant décision

Gold & annotations¶

Processus d'annotation : Double pass + arbitrage ; guide de labellisation (intents/entités Darija/FR/AR).

Calibration mensuelle (gold seed) et Krippendorff (optionnel).

Qualité inter-annotateurs :

Taxonomie d'erreurs :

Détection de drift (mensuel)¶

Intent drift: KL-divergence vs. baseline 28j; alerte si KL > 0.1.

Langue/code-switch: alerte si écart vs. coverage cible > 10 points.

Pipelines d'éval (CI)¶

Déclencheur : PR sur nlu/, rag/, prompts/ ou policies/.

Étapes :

• Validation schémas
• NLU eval
• Retrieval eval
• RAGAS
• LLM-judge
• Rapport HTML
• Seuils de blocage si KPI < cible
• Upload metrics (Prometheus)

Observabilité des évals :

• Noms de métriques Prometheus : salamboteval*
• Labels : tenant, sector, lang, model, dataset_version, git_sha
• Lier chaque run à un trace_id unique

Convention Prometheus : snake*case, préfixe salambot_eval*; labels {tenant, sector, lang, model, dataset_version, git_sha, trace_id}.

Exemples — cas de test¶

{
  "schema_version": "1.0",
  "tenant": "acme",
  "channel": "webchat",
  "message_id": "tst_001",
  "correlation_id": "corr_tst_001",
  "timestamp": "2025-08-14T10:00:00Z",
  "locale": "fr-MA",
  "data": {
    "user_text": "bghit nchoof facture",
    "gold": {
      "nlu": {
        "language": "darija_arabizi",
        "intent": "billing_view",
        "entities": []
      },
      "rag": {
        "expected_doc_ids": ["kb_12"]
      },
      "generation": {
        "expected_answer_contains": ["consulter votre facture"]
      }
    }
  }
}

Revue humaine & boucles d'amélioration¶

Échantillonnage périodique : Hebdomadaire.

Rubriques de revue : Étiquetage erreurs (NLU, Retrieval, Prompt, Policy).

Cycle CAPA : Corrective/preventive actions et suivi dans backlog.

Quota revue: max(1% des conversations, 200/tenant/mois).

Seuils de blocage CI¶

Références¶

• Composants
• API Reference
• Flux & Séquences