Sommaire

01

Les données d’entrée

02

Les choix effectués

03

Le pipeline

04

Les résultats

1 Les données d’entrée

1.1 De quoi part-on ?

Les données d’entrée

Dans un premier temps : analyse des copies de dictées seulement (dictée 2015). Pourquoi ? : car le texte de référence est connu à l’avance, ce qui facilite l’évaluation

Trois objets alimentent la chaîne de traitement :

  • L’image de la copie : l’imagette de la dictée manuscrite d’un élève de CM2
  • Le texte de référence : la dictée telle qu’elle aurait dû être écrite
  • La grille de codage : pour chaque item, le mot attendu et les fautes connues associées

Un item = un mot ou un signe de ponctuation. La dictée 2015 en compte 83, sur 3 469 imagettes, toutes annotées par un expert.

1.2 Le corpus

Les données d’entrée

Le corpus « dictée » — les travaux portent pour l’instant sur 2015
Dictée 2015 Dictée 2021
Niveau CM2 CM2
Imagettes disponibles 3 469 6 793
Copies annotées par un expert 3 469 6 793
Items par copie 83 83
Codes experts au total 287 728 563 819
  • Toutes les imagettes 2015 sont annotées : appariement 1 pour 1, aucune image sans code, aucun code sans image

1.3 Point de vigilance : le format des images

Les données d’entrée

  • Les fichiers .png fournis sont en réalité des TIFF bi-level 1 bit (compression G4, 1594 × 2044)
  • Chaque pixel est noir ou blanc : aucune nuance de gris
  • Conséquence : les accents se confondent avec le bruit et deviennent difficiles à lire
  • Le chargement (data/loaders.py) normalise systématiquement le format en entrée

2 Les choix effectués

2.1 Choix n°1 — Une grille de codage simplifiée

Les choix effectués

Grille complète (6 codes)

Code Signification
1 Orthographe correcte
3 Erreur lexicale
4 Erreur grammaticale
5 Lexicale et grammaticale
0 Mot absent

Grille simplifiée (cible principale)

Code Signification
1 Orthographe correcte
9 Erreur (3, 4 ou 5 regroupés)
0 Mot absent

Pourquoi ? Sur le test pilote, le regroupement 3/4/5 fait passer le kappa de 0,785 à 0,879 : il supprime exactement la zone où les correcteurs humains divergent le plus entre eux.

2.2 Choix n°2 — Deux approches comparées

Les choix effectués

End-to-end (par défaut)

Un modèle multimodal reçoit image + référence + grille et produit directement le code de chaque item.

  • Un seul appel : simple, rapide
  • Risque de sur-correction

Deux étapes

  1. HTR : transcrire l’image en texte brut, fautes comprises
  2. Codage : comparer ce texte à la référence
  • Transcription inspectable
  • Deux sources d’erreur cumulées

Les deux implémentent la même interface Scorer → évaluées par exactement le même code de métriques. On compare bien l’architecture, pas deux tuyaux différents.

2.3 Choix n°3 — Conception du code

Les choix effectués

  • Tout passe par la configuration : un fichier YAML validé (Pydantic) = un run reproductible. Aucun chemin en dur.
  • Un score de confiance par item : l’objectif opérationnel est de ne renvoyer vers un correcteur humain que les items incertains.
  • Règle des ratures (tranchée par la DEPP) : on lit l’état final, la version corrigée par l’élève. Consigne présente dans tous les prompts.
  • Modèles open weight servis sur le SSP Cloud (vLLM / llm.lab) : les données ne sortent pas.

3 Le pipeline

3.1 Vue d’ensemble

Le pipeline

Code 
flowchart LR
    A["Image<br/>(S3)"] --> S["Scorer"]
    R["Texte de référence<br/>+ grille"] --> S
    S --> P["Codes prédits<br/>+ confiance"]
    P --> N["Normalisation<br/>au schéma de codage"]
    E["Codes experts"] --> N
    N --> M["Métriques"]

flowchart LR
    A["Image<br/>(S3)"] --> S["Scorer"]
    R["Texte de référence<br/>+ grille"] --> S
    S --> P["Codes prédits<br/>+ confiance"]
    P --> N["Normalisation<br/>au schéma de codage"]
    E["Codes experts"] --> N
    N --> M["Métriques"]

Un Scorer expose une seule méthode : score_copy(copie, référence) → prédictions. VLMScorer (end-to-end) et TwoStageScorer produisent la même sortie.

3.2 Le déroulé d’un run

Le pipeline

Orchestré par pipeline/benchmark.py :

  1. Charger les données — imagettes depuis S3 et CSV des codes experts
  2. Charger la grille — mot attendu par item et texte de référence
  3. Coder chaque copie via le Scorer
  4. Normaliser les codes des deux côtés (modèle et expert), même échelle
  5. Écrire les prédictions au fil de l’eau dans un .jsonl
  6. Calculer les métriques

3.3 Robustesse et traçabilité

Le pipeline

Survivre aux incidents

Un run complet dure ~30 h (3 469 copies × ~30 s).

  • Écriture après chaque copie (flush + fsync)
  • Reprise automatique : les copies déjà traitées sont sautées
  • Les erreurs d’API sont journalisées, le run continue

Suivi des expériences

  • Langfuse (inférence) : session → trace (une copie) → génération (un appel)
  • MLflow (fine-tuning GPU) : courbes d’entraînement

4 Les résultats

4.1 Ce que l’on mesure

Les résultats

La grille de métriques commune
Famille Métriques
Codage Accord brut, kappa de Cohen, QWK, matrice de confusion, F1 pondéré
Transcription (HTR) CER, WER, taux d’illisibles, taux de sur-correction
Confiance Courbe de fiabilité, ECE
Référence Variabilité inter-codeurs humains (Dawid & Skene)

Le point de comparaison n’est pas « 100 % » mais l’accord entre correcteurs humains.

4.2 Résultats — codage

Les résultats

À compléter à l’issue du benchmark
Approche Copies Accord brut Kappa F1 pondéré
End-to-end — — — —
Deux étapes — — — —
Référence humaine — — — —

Note

Les tableaux de la page Résultats du site sont calculés automatiquement à partir des prédictions exportées sur S3. Le seul run disponible à ce jour est un échantillon de démonstration (~20 copies), non représentatif.

4.3 Résultats — transcription et confiance

Les résultats

HTR

Modèle CER WER Sur-correction
Base — — —
Fine-tuné — — —

Renvoi humain

Le livrable décisionnel : la courbe taux de renvoi humain vs taux d’erreur résiduel.

Graphique à insérer.

4.4 Prochaines étapes

Les résultats

  • Constituer le jeu d’évaluation « gold » (200–300 copies)
  • Lancer le benchmark HTR sur la dictée
  • Lancer le benchmark de codage (end-to-end vs deux étapes)
  • Fine-tuning LoRA sur les ~3 000 copies annotées
  • Étendre à la production écrite libre (pas de texte de référence)

  • Laura Gaimard
  • SSP Lab
  • Insee
  • laura.gaimard@insee.fr