</>
Dr. EPL
Retour aux projets
IA

Modèle de Traduction FR-Wolof

Pipeline ML-Ops complet de traduction bidirectionnelle FR ⇄ Wolof : fine-tuning LoRA de NLLB-200, tracking MLflow, API Flask conteneurisée.

Code Source

Stack Technique

IA & NLP

NLLB-200PEFT (LoRA)PyTorchTransformers

MLOps

MLflowHuggingFace HubKaggle

Backend & API

FlaskGunicorn

Infra & Runtime

DockerDocker ComposeCUDA
BLEU 18.89

Qualité de traduction sur test set (11 802 paires)

0.17%

Paramètres entraînables grâce au LoRA

196 690

Paires bilingues vues pendant l'entraînement

Contexte & Objectifs

Le wolof est une langue à faibles ressources linguistiques : peu de corpus parallèles publiés, peu d'outillage spécialisé, et une qualité de traduction commerciale très inégale. Ce projet vise à fournir une API de traduction bidirectionnelle FR ⇄ Wolof exploitable en production, en adaptant un modèle multilingue généraliste, NLLB-200, au couple wolof-français via un fine-tuning paramétriquement efficace, plutôt qu'un réentraînement complet qui serait hors de portée d'un GPU unique.

La Problématique

La traduction automatique entre langues à faibles ressources reste un angle mort des grands modèles commerciaux. Pour le couple français-wolof, les corpus parallèles ouverts sont rares, le vocabulaire spécialisé est absent des données d'entraînement génériques, et les outils existants peinent à dépasser le mot-à-mot littéral.

Réentraîner intégralement un modèle multilingue de 600M+ paramètres pour ce seul couple linguistique n'est pas viable : coût GPU prohibitif, données insuffisantes pour stabiliser la convergence, et perte des capacités initiales du backbone sur les autres langues.

La Solution

Adoption d'un schéma modèle généraliste + adapter spécialisé : facebook/nllb-200-distilled-600M comme backbone gelé, et un adapter LoRA (r=16, α=32) entraîné sur les projections d'attention q_proj et v_proj. L'adapter pèse 9.4 MB, soit 0,17 % des paramètres du modèle, ce qui ouvre la voie à un fine-tuning sur GPU unique en fp16.

L'entraînement utilise le dataset galsenai/centralized_wolof_french_translation_data (98 345 paires), doublé dans les deux sens pour un total de 196 690 exemples, avec préfixage explicite du code langue cible (fra_Latn / wol_Latn) dès la tokenisation. Sélection du meilleur checkpoint sur BLEU ; métrique chrF loggée en parallèle pour capter la morphologie riche du wolof. MLflow tracke les hyperparamètres, métriques par epoch et artefacts.

Au déploiement, setup_module.py récupère l'adapter depuis Kaggle ou le MLflow Registry et le monte dans une image Docker PyTorch CUDA, servie par Flask + gunicorn (2 workers × 2 threads, gthread) avec healthchecks et timeout 120 s.

Résultats & Impact

Une API conteneurisée servant NLLB-200-distilled-600M augmenté de l'adapter LoRA fine-tuné, atteignant BLEU 18.89 et chrF 40.10 sur le set de test (11 802 paires), avec une latence d'inférence de 100 à 250 ms par requête sur GPU (≈ 4 GB VRAM, ≈ 2 GB RAM).

Quatre endpoints REST exposés : /health (disponibilité + état CUDA), /model-info (métadonnées du modèle), /predict (traduction unitaire ≤ 1000 caractères, auto-détection de langue, num_beams 1-8), /batch-predict (lot jusqu'à 100 textes par requête).

Le pipeline d'entraînement, l'adapter et l'API sont découplés : on peut réentraîner sur de nouvelles données et promouvoir une nouvelle version du modèle dans le Registry sans toucher au code de déploiement.

Architecture Visuelle

Les captures d'écran seront bientôt ajoutées.

Pipeline & Étapes

  1. 1

    Préparation des données

    Chargement du dataset galsenai/centralized_wolof_french_translation_data (98 345 paires), dédoublement bidirectionnel FR→WO + WO→FR (196 690 exemples), split 88 / 6 / 6 train/val/test.

  2. 2

    Tokenisation conditionnée

    Tokenisation NLLB avec préfixage explicite du code langue cible (fra_Latn / wol_Latn) en tête des labels, exigence des modèles NLLB pour orienter le décodage.

  3. 3

    Fine-tuning LoRA

    Adapter LoRA (r=16, α=32, dropout 0.05) sur q_proj et v_proj, 4 epochs, lr 1.2e-4, fp16, beam search 4. Sélection du best checkpoint sur BLEU, chrF loggée en parallèle.

  4. 4

    Tracking & versionnement MLflow

    Log de l'adapter (adapter_model.safetensors, 9.4 MB), des hyperparamètres et des métriques par epoch dans MLflow, avec promotion au MLflow Model Registry.

  5. 5

    Récupération de l'adapter

    setup_module.py --source mlflow (ou --source kaggle) télécharge l'adapter et le tokenizer dans ./deployment/model/, prêt à être monté dans le conteneur.

  6. 6

    Déploiement conteneurisé

    Image Docker PyTorch CUDA servie par Flask + gunicorn (2 workers × 2 threads gthread, timeout 120 s), healthcheck Docker /health toutes les 30 s, redémarrage on-failure.

Adaptations possibles

Le même schéma, modèle multilingue généraliste plus adapter LoRA spécialisé plus API conteneurisée, s'applique à toute langue ou tout domaine sous-représenté nécessitant une adaptation rapide et économe.

Domaines transposables

  • Terminologie médicale ou juridique sous-spécifiée par les LLM généralistes
  • Langues régionales africaines (peul, bambara, lingala, kinyarwanda)
  • Variétés dialectales et créoles
  • Vocabulaire métier sectoriel (industrie, finance, agronomie)
  • Localisation produit sur des marchés linguistiques de niche
  • Sous-titrage et accessibilité pour communautés linguistiques minoritaires