Chinese Language Is Not More Efficient Than English in Vibe Coding: A Preliminary Study on Token Cost and Problem-Solving Rate

1. Problématique et Contexte

Une affirmation circulant largement sur les réseaux sociaux et les forums de développeurs suggère que l'utilisation de prompts en chinois pour les tâches de codage avec des Modèles de Langage (LLM) serait plus efficace en termes de tokens que l'anglais. Cette hypothèse, basée sur la densité informationnelle supposée des caractères chinois, prétend pouvoir réduire les coûts d'API de jusqu'à 40 %.

Cette croyance a conduit de nombreux développeurs à adopter une approche de « vibe coding » (génération de code par langage naturel) en chinois pour économiser des coûts. Cependant, cette affirmation confond trois phénomènes distincts :

1. La densité informationnelle (les caractères chinois expriment des idées avec moins de caractères).
2. L'allocation des tokenizers (les tokenizers optimisés pour l'anglais peuvent fragmenter les caractères CJK en plusieurs tokens).
3. La verbosité du raisonnement (la longueur du texte de sortie).

L'objectif de cette étude est de vérifier empiriquement si le chinois offre réellement un avantage en termes de coût et de taux de réussite sur des tâches d'ingénierie logicielle complexes.

2. Méthodologie

Les auteurs ont mené une étude empirique rigoureuse et contrôlée en utilisant le benchmark SWE-bench Lite, qui évalue la capacité des modèles à résoudre des bugs réels dans des projets open-source Python (Django, matplotlib, etc.).

• Données : 50 instances de tâches extraites de SWE-bench Lite, sélectionnées par échantillonnage aléatoire stratifié.
• Modèles testés : Trois familles de modèles aux architectures et stratégies de tokenisation différentes :
  • MiniMax-2.7 (développé en Chine, optimisé pour le CJK).
  • GPT-5.4-mini (OpenAI, entraîné principalement sur des données anglaises).
  • GLM-5 (Z.ai, modèle chinois avec mode de raisonnement explicite).
• Protocole expérimental :
  • Phase 1 (Génération) : Un agent (MiniSWEAgent) tente de générer un correctif (patch) pour chaque bug, en utilisant soit le prompt original en anglais, soit une traduction professionnelle en chinois (préservant la terminologie technique).
  • Phase 2 (Évaluation) : Les patches sont appliqués et exécutés via le harness officiel de SWE-bench pour déterminer si le test passe.
• Mesures : Suivi granulaire des tokens (prompt, complétion, raisonnement) et des coûts via l'API OpenRouter. Calcul du coût attendu par tâche réussie ($C_{eff}$), qui intègre à la fois la consommation de tokens et le taux de réussite.

3. Contributions Clés

1. Comparaison systématique : Première évaluation contrôlée comparant l'anglais et le chinois sur des tâches de débogage logiciel réelles, en distinguant les types de tokens.
2. Analyse du coût réel : Introduction d'une métrique de coût qui pondère la consommation de tokens par le taux de réussite, démontrant que les échecs répétés annulent les économies potentielles de tokens.
3. Déconstruction du mythe : Démonstration que l'efficacité des tokens dépend de l'architecture du modèle (notamment du tokenizer) et non d'une propriété intrinsèque de la langue.

4. Résultats Principaux

A. Taux de Résolution (Success Rate)

L'utilisation du chinois entraîne généralement un taux de réussite inférieur par rapport à l'anglais sur tous les modèles testés :

• MiniMax-2.7 : 66,0 % (Anglais) vs 61,5 % (Chinois).
• GPT-5.4-mini : 36,0 % (Anglais) vs 26,1 % (Chinois).
• GLM-5 : 64,6 % (Anglais) vs 55,1 % (Chinois).
  La différence de performance entre les modèles (environ 30 points de pourcentage) est bien plus significative que l'effet de la langue.

B. Coût en Tokens et Efficacité

Les résultats contredisent l'idée d'une efficacité universelle du chinois :

• MiniMax-2.7 : Le chinois consomme 1,28 fois plus de tokens que l'anglais.
• GPT-5.4-mini : Le chinois consomme 1,09 fois plus de tokens.
• GLM-5 : C'est le seul cas où le chinois consomme moins de tokens (ratio 0,98), grâce à un tokenizer optimisé pour le CJK.

C. Coût Attendu par Tâche Réussie

L'analyse la plus critique porte sur le coût total incluant les échecs. Même si le chinois génère parfois moins de tokens par tentative, le taux de réussite plus faible oblige à relancer les tâches, augmentant drastiquement le coût total.

• Pour GPT-5.4-mini, bien que le surcoût en tokens soit faible (9 %), la baisse du taux de réussite (près de 10 points) rend le passage au chinois contre-productif économiquement.
• Aucune combinaison modèle/langue n'a montré un gain d'efficacité coût/performance significatif en passant au chinois.

D. Rôle du Tokenizer

L'étude confirme que l'efficacité dépend de l'allocation du vocabulaire du tokenizer :

• Les tokenizers dominés par l'anglais (ex: cl100k utilisé par GPT/Llama) fragmentent les caractères chinois, augmentant le nombre de tokens.
• Les tokenizers natifs chinois (ex: GLM) peuvent être plus efficaces en chinois.
• La densité de caractères par token est toujours plus élevée en chinois, mais cela ne se traduit pas par une compression de tokens si le tokenizer n'est pas adapté.

5. Signification et Implications

Cette étude « démythifie » l'affirmation selon laquelle le chinois est intrinsèquement plus efficace pour le codage assisté par IA.

• Pour les praticiens : Changer de langue pour réduire les coûts est une stratégie risquée et probablement inefficace. Le gain potentiel est nul ou négatif une fois le taux de réussite pris en compte.
• Priorité d'optimisation : Le choix du modèle (et de son tokenizer) est le facteur déterminant pour la performance et le coût, bien plus que la langue du prompt.
• Conclusion : Les développeurs ne devraient pas s'attendre à des économies de 30-40 % en passant au chinois. L'optimisation des coûts doit se concentrer sur la sélection du modèle le plus performant pour la tâche et la gestion des taux d'échec, plutôt que sur le changement de langue.

En résumé, l'efficacité des tokens est une propriété dépendante du modèle (liée à la conception du tokenizer et aux données d'entraînement) et non une propriété linguistique universelle.