Blog · DAH Labs

TranslatePsy-AfriSLM testé en wolof et en yoruba : quand un petit modèle fait mieux qu'un grand

2026-10-12T00:00:00.000Z

Les assistants d'intelligence artificielle maîtrisent l'anglais et le français, mais qu'en est-il des langues africaines comme le yoruba, le haoussa ou le wolof ? Une équipe de recherche a récemment montré qu'un modèle minuscule peut, sur ces langues peu dotées en données, faire mieux que des systèmes bien plus gros. Nous avons voulu le vérifier nous-mêmes.

Ce que propose le papier

L'équipe Tether AI Research (Milan Gritta, Patrik Lambert, Jihye Back et Amril Nazir) a publié sur arXiv TranslatePsy-AfriSLM, un ensemble de ressources ouvertes de traduction automatique pour 19 langues d'Afrique subsaharienne, dont le wolof, le yoruba, le haoussa, l'igbo, le swahili et l'amharique. Le projet comprend des données parallèles filtrées, des données synthétiques et trois petits modèles (0,8, 2 et 4 milliards de paramètres), tous disponibles sur Hugging Face.

Le résultat qui attire l'attention : le plus petit modèle, avec 0,8 milliard de paramètres, devance sur les trois benchmarks testés (Flores-200, BOUQuET et Smol) des modèles bien plus gros, dont TranslateGemma-27B et Qwen3.5-122B-A10B, selon le score SSA-COMET, une métrique conçue pour évaluer les langues africaines.

Fig. 1. Qualité de traduction (SSA-COMET, benchmark BOUQuET) selon la taille du modèle : les modèles TranslatePsy-AfriSLM (points verts) devancent des modèles jusqu'à 150 fois plus gros. Source : Gritta et al. (2026), Figure 1, licence CC BY 4.0.

La qualité des données avant la taille

Comment un modèle aussi petit fait-il mieux ? Les auteurs l'attribuent au tri des données d'entraînement. Chaque paire de phrases (une phrase et sa traduction) reçoit une note de qualité calculée par trois outils d'évaluation automatique, et seules les meilleures sont gardées.

L'effet est spectaculaire : entraîné sur toutes les données ouvertes brutes (près de 45 milliards de tokens), un modèle obtient le même score qu'avec seulement 1,76 milliard de tokens bien choisis. Le filtrage écarte ainsi jusqu'à 96 % des données sans perte de qualité.

Fig. 2. Chaque forme est un modèle entraîné sur un mélange de données différent. Le modèle « Open-source (Unfiltered) », en bas à droite, utilise le plus de données pour l'un des scores les plus faibles. Source : Gritta et al. (2026), Figure 4, licence CC BY 4.0.

Notre test

Modèle : qvac/TranslatePsy-AfriSLM-0.8B, le plus petit des trois.
Langues : wolof et yoruba.
Directions : anglais ↔ wolof et anglais ↔ yoruba, dans les deux sens.
Phrases : 15 phrases de la vie courante.
Évaluation : chaque traduction a été relue par un locuteur du wolof ou du yoruba, qui a jugé sa qualité et sa fidélité au sens d'origine.

Nous n'avons pas réussi à faire tourner le modèle sur nos ordinateurs : le test a été réalisé sur Google Colab.

Résultats

Sur 15 phrases, 14 ont été jugées bonnes par nos relecteurs natifs, et une seule moyenne.

Direction	Phrases	Bonne	Moyenne
Wolof → anglais	5	4	1
Anglais → wolof	3	3	0
Anglais → yoruba	5	5	0
Yoruba → anglais	2	2	0

Quelques exemples représentatifs :

Phrase de départ	Direction	Traduction obtenue	Avis du relecteur
Senegal, dëkk bu am téranga la	Wolof → anglais	Senegal is a very teranga city.	Bonne
I'm heading to work, I'll be back late	Anglais → wolof	Maa ngi dem liggéey, dinaa dellu lu yàgg.	Bonne
Man ngi dem daara	Wolof → anglais	I'm going to bed.	Moyenne : « daara » (l'école coranique) est mal traduit
Could you please tell me how I can get to the train station from here?	Anglais → yoruba	Jọ̀wọ́ sọ fún mi bí mo ṣe lè dé ibùdókọ̀ ojú irin láti ibí yìí?	Bonne
Mo sábà máa ń tètè jí láàárọ̀, mo sì máa ń mu ife kọfí kí n tó bẹ̀rẹ̀ ọjọ́ mi.	Yoruba → anglais	I usually wake up early in the morning and have a cup of coffee before I start my day	Bonne, avec une petite nuance

La dernière ligne est un aller-retour : la phrase yoruba est la traduction produite par le modèle à partir de « I usually wake up early in the morning and start my day with a cup of coffee ». Le sens revient presque intact. Seule nuance : le café passe avant le début de la journée, alors que la phrase d'origine commence la journée avec un café.

Le temps de traitement allait de 19 à 60 secondes par phrase sur Colab, avec un cas isolé à 120 secondes.

Ces résultats rejoignent ceux du papier. Sur le benchmark BOUQuET, le fine-tuning fait nettement progresser le wolof comme le yoruba par rapport au modèle de base :

Fig. 3. Scores par langue sur quatre métriques, avant (gris) et après (vert) fine-tuning, pour le modèle 2B. Dans le deuxième graphique (SSA-COMET), le wolof (wol) et le yoruba (yor) passent d'environ 0,3 à plus de 0,6. Source : Gritta et al. (2026), Figure 11, licence CC BY 4.0.

Le papier montre aussi que le wolof reste une langue difficile : sur MetricX (troisième graphique, où un score bas est meilleur), c'est la langue où le modèle 2B obtient le moins bon score des 19.

Ce que le test nous a appris

Le modèle ne part que de l'anglais. Nous avons aussi essayé de traduire du français vers le wolof et vers le yoruba : le modèle a renvoyé les phrases telles quelles. Ce n'est pas étonnant : il a été entraîné sur des paires anglais ↔ langue africaine, et les auteurs ne testent pas le français comme langue de départ.

L'orthographe compte. Le modèle est sensible à l'orthographe, aux accents et aux caractères propres à chaque langue (ë, ñ, ŋ, à, é, ó, ọ, ṣ…). Une phrase écrite dans la graphie standard est bien mieux comprise qu'un texte tapé à la volée. Ce type de test demande donc un bon locuteur, capable d'écrire correctement et de juger la traduction obtenue.

Quinze phrases ne font pas un benchmark. Notre test est un premier contact, pas une évaluation complète : il dit si le modèle est utilisable sur des phrases simples, pas comment il se comporte sur des textes longs, techniques ou très idiomatiques.

Impact pour l'Afrique

Ce qui rend ce travail intéressant pour nous ne tient pas qu'à la performance : c'est la taille. Un modèle de 0,8 milliard de paramètres coûte beaucoup moins cher à faire tourner qu'un modèle de 27 ou 122 milliards, un écart qui compte directement là où la connectivité est limitée et où chaque heure de calcul se négocie. Ce n'est pas encore un modèle qui tourne hors ligne sur un téléphone d'entrée de gamme (nous ne l'avons même pas fait tourner sur un ordinateur), mais c'est une direction : la preuve qu'on peut viser la sobriété sans sacrifier la qualité.

L'autre apport, moins visible mais tout aussi important, est le jeu de données lui-même : 19 langues africaines, avec des ressources ouvertes et documentées. C'est exactement le type de brique sur laquelle un projet comme AfriVoice peut s'appuyer, et un rappel que la qualité des données compte souvent plus que la taille du modèle, un principe qui vaut aussi pour nos propres travaux.

Enfin, l'erreur sur « daara » est un bon rappel : un score de benchmark ne dit pas tout. Seule une relecture par un locuteur natif révèle ce genre de nuance culturelle et linguistique. Les auteurs le reconnaissent eux-mêmes : leur papier se termine sur la nécessité d'une évaluation humaine pour mesurer la qualité réelle des traductions en langues africaines. C'est exactement ce que notre démarche de veille testée cherche à faire : confronter un chiffre impressionnant à l'usage réel plutôt que de le relayer tel quel.

À retenir

Un modèle de 0,8 milliard de paramètres, entraîné sur des données soigneusement triées, traduit mieux le wolof et le yoruba que des modèles 30 à 150 fois plus gros. Notre test confirme qu'il est utilisable sur des phrases courantes, à condition de partir de l'anglais et d'écrire dans la graphie standard.

Références

Gritta, M., Lambert, P., Back, J., & Nazir, A. (2026). TranslatePsy-AfriSLM: High-Quality Data Scaling For Low-Resource Machine Translation. Tether AI Research. arXiv:2608.18655, licence CC BY 4.0.
Modèles et données sur Hugging Face : collection qvac/translatepsy-afrislm

Construire son premier assistant RAG avec LangChain

2026-09-28T00:00:00.000Z

Un modèle de langage ne connaît que ce qu'il a vu pendant son entraînement. Il ignore vos rapports internes, vos jeux de données ou la documentation de votre projet — et quand on l'interroge dessus, il peut inventer une réponse avec aplomb.

Le RAG (Retrieval-Augmented Generation) comble ce manque. Avant de répondre, l'assistant va chercher les passages utiles dans vos propres documents, puis s'en sert comme contexte pour construire sa réponse. Cet article présente les quatre briques d'un pipeline RAG et une première implémentation en Python.

Pourquoi le RAG ?

Réentraîner un modèle sur vos données coûte cher et devient vite obsolète. Avec le RAG, vos documents restent séparés du modèle : il suffit de les mettre à jour pour que l'assistant en tienne compte dès la question suivante. Autre avantage, la traçabilité — chaque réponse peut indiquer les passages dont elle est tirée, ce qui la rend vérifiable.

À retenir

Le RAG ne rend pas le modèle plus intelligent : il lui donne le bon contexte au bon moment. La qualité des réponses dépend d'abord de la qualité de vos documents et de leur découpage.

Les quatre étapes d'un pipeline RAG

Quel que soit l'outil, un système RAG a deux phases. L'indexation a lieu une fois, quand les documents sont ajoutés. L'interrogation a lieu à chaque question.

Fig. 1. Un pipeline RAG. Les documents sont indexés une fois ; chaque question récupère les passages les plus proches avant la génération.

Charger — lire les documents sources (PDF, pages web, fichiers texte).
Découper — les diviser en passages courts, qui se chevauchent légèrement pour ne pas perdre le contexte aux frontières.
Indexer — transformer chaque passage en vecteur (un embedding) et le ranger dans une base vectorielle.
Interroger — à chaque question, retrouver les passages les plus proches et les transmettre au modèle avec la question.

Choisir la taille des passages

Des passages trop longs diluent l'information utile ; trop courts, ils perdent leur contexte. Un point de départ courant est un chunk_size de quelques centaines à mille caractères, avec un chunk_overlap de 10 à 20 % — puis on ajuste en testant sur de vraies questions.

Mesurer la similarité

Pour trouver les passages les plus proches d'une question, les deux sont transformés en vecteurs puis comparés. La mesure la plus courante est la similarité cosinus : elle regarde l'angle entre les deux vecteurs plutôt que leur longueur.

\text{sim}(q, d) = \frac{q \cdot d}{\lVert q \rVert \, \lVert d \rVert}

Similarité cosinus entre le vecteur de la question q et celui d'un passage d.

Un premier pipeline en Python

Voici le squelette des quatre étapes avec LangChain. Le modèle d'embeddings est laissé au choix : un modèle open source en local ou une API.

from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import FAISS

# 1. Charger
docs = PyPDFLoader("guide_nutrition.pdf").load()

# 2. Découper
splitter = RecursiveCharacterTextSplitter(chunk_size=800, chunk_overlap=100)
chunks = splitter.split_documents(docs)

# 3. Indexer
embeddings = ...  # le modèle d'embeddings de votre choix
vectorstore = FAISS.from_documents(chunks, embeddings)

# 4. Interroger
retriever = vectorstore.as_retriever(search_kwargs=dict(k=4))
passages = retriever.invoke("Quels aliments locaux sont riches en fer ?")

Le retriever renvoie les quatre passages les plus pertinents pour la question posée. Il ne reste plus qu'à les insérer dans le prompt envoyé au modèle de langage, avec la consigne de répondre uniquement à partir de ce contexte — et de le dire quand la réponse n'y est pas.

Pour aller plus loin

Une fois ce socle en place, les vrais gains viennent généralement de trois leviers :

Évaluer les réponses sur un jeu de questions test, pour mesurer chaque changement.
Essayer différents modèles d'embeddings, en particulier pour le français et les langues locales.
Combiner la recherche vectorielle avec une recherche par mots-clés pour les noms, codes et sigles.

Références

Lewis, P., Perez, E., Piktus, A., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. arXiv:2005.11401
Johnson, J., Douze, M., & Jégou, H. (2017). Billion-scale similarity search with GPUs. arXiv:1702.08734
Documentation LangChain. python.langchain.com