Glossaire du projet

Définitions succinctes des termes techniques employés dans les pages du projet S3T. Survolez un terme souligné dans n’importe quelle page pour voir sa définition, ou retrouvez-le ici avec son contexte.

📐 Métriques d’évaluation

Comment mesure-t-on la qualité d’une traduction automatique ?

BLEU métrique
Score standard pour évaluer la qualité d’une traduction automatique (Papineni et al., 2002). Il compare les n-grammes de l’hypothèse avec ceux de la référence via une moyenne géométrique de précisions modifiées. SacreBLEU (Post, 2018) l’affiche sur une échelle 0–100.
Le BLEU classe surtout des systèmes entre eux sur un même test ; un traducteur humain natif obtient ~26 BLEU sur le benchmark de Papineni et al. (2 références). Sur m-TEDx ST, la référence article Pantagruel est 25,2 (Table 8). Détail : page Évaluation.
run_013 : 15,2 BLEU → meilleur run speechLLM sur utterance.
Contexte (entrée / sortie) décodage
Dans ce projet, le contexte désigne ce que le modèle « voit » et produit à l’inférence : taille de l’entrée audio + prompt (s’il y en a un) + input modèle (représentations audio / tokens) + plafond de sortie (ex. max_new_tokens). Ce n’est pas le « contexte conversationnel » d’un chatbot, mais la fenêtre utile pour une traduction ST.
Comparer utterance vs sentence_like (et des buckets de durée) permet de voir sur quelle taille de contexte un modèle comme Canary reste performant. Voir page Résultats · contexte.

🧩 Composants du modèle

Les briques qui composent les architectures du projet.

Encodeur (acoustique) modèle
Partie du modèle qui convertit le signal audio en vecteurs numériques représentant le contenu de la parole. On peut l’imaginer comme une « oreille entraînée » qui résume chaque instant de son en un point dans un espace mathématique à haute dimension.
Dans ce projet, l’encodeur est toujours Pantagruel. Selon la variante, il peut être gelé (poids fixes) ou dégelé (poids mis à jour pendant l’entraînement).
Pantagruel B-1k · L-14k · L-114k modèle
Encodeur acoustique développé au LIG-GETALP, basé sur l’architecture Whisper. Trois tailles sont disponibles : B-1k (Base, entraîné sur 1 000 h), L-14k (Large, 14 000 h), L-114k (Large, 114 000 h). Plus la version est grande, meilleure est la représentation acoustique — mais plus coûteuse en calcul.
La nomenclature B/L indique la taille de l’architecture (Base ≈ 74 M paramètres, Large ≈ 307 M) ; le nombre indique la quantité de données d’entraînement en heures.
LLM (Large Language Model) modèle
Grand modèle de langue : réseau de neurones pré-entraîné sur d’immenses quantités de texte, capable de générer du texte cohérent. Il sert ici de « cerveau textuel » qui reçoit les vecteurs audio transformés et produit la traduction en anglais.
Dans la variante 2, les LLMs testés sont Phi-2 (2,7 Mds de paramètres, Microsoft), Qwen2.5-3B (Alibaba), Llama-3.2-3B-Instruct (Meta) et Mistral. Le LLM est gelé : seul le projecteur est entraîné.
Projecteur (adaptateur B1) modèle
Petit adaptateur composé de quelques couches linéaires qui « traduit » les vecteurs produits par l’encodeur audio dans l’espace numérique attendu par le LLM. C’est le seul composant entraîné en mode B1 — ce qui rend l’entraînement beaucoup plus rapide qu’une approche bout-en-bout complète.
Inspiré de l’article SLAM-ASR (Ma et al., 2024). Le terme « B1 » désigne le mode où seul le projecteur est mis à jour, par opposition à « B2 » où le LLM est partiellement dégelé.
Voir aussi : LLM Encodeur
Speech-to-text ST modèle
Tâche de traduction directe de la parole en texte dans la langue cible (ici audio français → texte anglais), en un seul modèle. À distinguer de la cascade ASR→MT (transcription FR puis traduction texte) et des approches entraînées sur m-TEDx (variantes 1–2).
Variante 6 : Whisper-ST (task=translate), SeamlessM4T v2 et Canary-1B, évalués en zero-shot sur les manifests utterance.
Utilisé dans : Variante 6 · Voir aussi : Zero-shot Open weights
Open weights (poids ouverts) modèle
Modèle dont les poids (paramètres) sont publiés et téléchargeables (Hugging Face, NeMo, etc.). On peut relancer l’inférence localement sans API propriétaire — condition importante pour la reproductibilité académique.
Variante 6 : alternative ouverte à Gemini (API fermée). Canary-1B atteint 40,0 BLEU test en zero-shot.
Utilisé dans : Variante 6
Zero-shot modèle
Utilisation d’un modèle sans entraînement ni fine-tuning sur les données du projet : on charge les poids pré-entraînés et on évalue directement sur m-TEDx. Les performances reflètent le savoir général du modèle, pas un apprentissage spécifique au corpus.
Tous les runs de la variante 6 sont zero-shot. À comparer aux variantes 1–2 qui entraînent ou adaptent un modèle sur m-TEDx.
Utilisé dans : Variante 6 · Voir aussi : Inférence

🏋 Entraînement

Concepts liés à l’optimisation et à l’ajustement du modèle sur les données.

Gelé / Dégelé frozen / unfrozen entraînement
Un module est gelé quand ses poids (paramètres internes) sont bloqués pendant l’entraînement : il traite les données mais n’apprend pas. Un module dégelé peut se mettre à jour. Geler l’encodeur stabilise l’entraînement et réduit les risques de catastrophic forgetting, mais plafonne les performances.
Dans la variante 2, l’encodeur est gelé par défaut. run_005 (dégelé) donne 19 BLEU mais le dégel en segmentation utterance (run_015) a échoué (3,7).
Warmup LR (montée progressive du taux d’apprentissage) entraînement
Stratégie où le taux d’apprentissage (vitesse à laquelle le modèle met à jour ses poids) commence très faiblement, monte progressivement pendant les premières mises à jour (warmup), puis suit un planning de décroissance. Cela évite les mises à jour trop brusques en début d’entraînement qui pourraient déstabiliser le modèle.
Implémenté dans 2_speechLLM/train.py. Typiquement les 500–1000 premiers updates servent de warmup.
SpecAugment entraînement
Technique d’augmentation de données audio : pendant l’entraînement, on masque aléatoirement des bandes de fréquences ou des intervalles de temps dans le spectrogramme d’entrée. Cela force le modèle à être robuste aux occultations partielles, améliorant la généralisation.
Testé dans run_039 (L-14k + SpecAugment) → 13,84 BLEU test.
Run run_XXX entraînement
Identifiant d’une expérience (entraînement ou évaluation). Chaque run teste une combinaison précise de paramètres (encodeur, segmentation, LLM, modèle ST, etc.). Les résultats sont tracés par run pour faciliter les comparaisons.
Exemples : run_012 (L-14k gelé, utterance, 48 tok), run_074 (Canary-1B zero-shot, variante 6).
Inférence entraînement
Phase où le modèle produit des traductions à partir d’audio, sans mettre à jour ses poids. Les variantes 3–4–6 n’entraînent rien sur m-TEDx : elles chargent des modèles pré-entraînés et passent directement à l’inférence (souvent en zero-shot).
À l’opposé de l’entraînement (variantes 1–2), où les poids sont optimisés sur le corpus du projet.
Utilisé dans : Variante 6 · Voir aussi : Zero-shot

✍️ Décodage et génération de texte

Comment le modèle produit la traduction mot par mot.

Token (sous-mot) décodage
Unité de base du texte pour un LLM. Les tokens ne correspondent pas exactement aux mots : un mot courant est souvent un seul token (« the »), un mot rare est découpé en plusieurs (« trans·la·tion »). En moyenne, 1 mot anglais ≈ 1,3 tokens.
max_new_tokens=48 correspond à environ 35–40 mots anglais, suffisant pour une phrase de traduction.
Voir aussi : max_new_tokens
max_new_tokens décodage
Nombre maximal de tokens que le modèle peut générer pour une traduction. Si la valeur est trop élevée, le modèle peut produire des textes bien trop longs, faisant chuter le score BLEU même si la traduction est correcte au début.
Valeur critique dans la variante 2 : 48 tokens ≈ correct (15 BLEU), 128 tokens → hypothèses 3× trop longues → BLEU 5–6 (run_017, run_021).
Voir aussi : Token BLEU
Beam search (recherche en faisceau) décodage
Algorithme de décodage qui maintient en parallèle N hypothèses de traduction (le « faisceau », ou beam) à chaque étape. À chaque token, on ne garde que les N meilleures extensions. Un beam plus large explore plus de possibilités mais est plus lent ; un beam trop grand peut produire des répétitions avec certains modèles.
Dans la variante 2, beam ≥ 4 génère des boucles de répétition. Valeur recommandée : 1 (greedy) à 3.
Voir aussi : Greedy
Greedy (décodage glouton) décodage
Stratégie de décodage la plus simple : à chaque étape, on choisit le token le plus probable sans explorer d’autres options. C’est beam search avec beam=1. Rapide, mais peut rater de meilleures traductions accessibles en explorant davantage.
Voir aussi : Beam search
Prompt / Consigne décodage
Texte d’instruction passé au LLM avant les vecteurs audio pour lui indiquer ce qu’on attend de lui : traduire en anglais, ne pas commenter, respecter une certaine longueur, etc. La qualité du prompt influence fortement la langue de sortie et la verbosité du modèle.
Format utilisé dans la variante 2 : dialog USER/ASSISTANT. La consigne est un hyperparamètre à affiner.

✂️ Données et segmentation

Comment les données audio sont organisées et découpées pour l’entraînement et l’évaluation.

Segmentation données
Façon dont les enregistrements audio longs sont découpés en segments pour l’entraînement et l’évaluation. Le choix de segmentation influe sur le type de référence (phrase vs énoncé) et donc sur la manière dont le BLEU est calculé. Les scores utterance et sentence_like ne sont pas directement comparables.
Utterance données
Mode de segmentation qui découpe l’audio par énoncé : chaque segment correspond à une prise de parole continue (une phrase parlée, ou fragment). Les segments sont courts et correspondent aux alignements du corpus m-TEDx.
La plupart des runs récents (run_012, run_013…) utilisent la segmentation utterance. Les scores obtenus (15 BLEU) sont comparables entre eux mais pas avec sentence_like.
sentence_like données
Mode de segmentation qui regroupe des énoncés consécutifs en pseudo-phrases plus longues, en cherchant des pauses naturelles. Les segments sont plus longs et la référence de traduction aussi, ce qui peut donner de meilleurs scores BLEU absolus mais représente une tâche légèrement différente.
run_005 et run_002 utilisent sentence_like et atteignent 16–19 BLEU, mais ce n’est pas comparable directement aux 15 BLEU utterance de run_013. Variante 6 : Whisper/Seamless sentence_like mesurés (run_080/080b, baisse vs utterance) ; Canary sentence_like (run_081) préparé.
Manifest *.tsv données
Fichier tabulé (train.tsv, valid.tsv, test.tsv) qui liste les segments audio à utiliser pour l’entraînement ou l’évaluation, avec leurs chemins et références de traduction. Toutes les variantes évaluent sur les mêmes manifests pour garantir la comparabilité des scores BLEU.
Les runs open baselines (variante 6) consomment les mêmes test.tsv utterance que Gemini et la cascade.
Utilisé dans : Variante 6 Corpus · Voir aussi : Utterance

🖥 Infrastructure et calcul

Ressources matérielles utilisées pour les entraînements.

GPU (carte graphique de calcul) infrastructure
Processeur spécialisé pour les calculs matriciels en parallèle, indispensable à l’entraînement de réseaux de neurones. La « durée GPU » indique combien de temps de calcul sur GPU a été consommé par un run (entraînement + évaluation).
Les entraînements de la variante 2 durent 1,4 h (run_012) à 15 h (run_017) selon la taille de l’encodeur et max_new_tokens.