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.

🧩 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

🏋 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 d’entraînement. Chaque run teste une combinaison précise de paramètres (encodeur, segmentation, LLM, max_new_tokens, etc.). Les résultats sont tracés par run pour faciliter les comparaisons.
Exemples : run_012 (L-14k gelé, utterance, 48 tok), run_005 (B-1k dégelé, sentence_like).

✍️ 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.

🖥 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.