CangjieBench: Benchmarking LLMs on a Low-Resource General-Purpose Programming Language

Each language version is independently generated for its own context, not a direct translation.

Imaginez que vous êtes un chef cuisinier (le modèle d'intelligence artificielle) qui est un génie absolu pour cuisiner des plats français, italiens ou chinois. Vous connaissez chaque ingrédient, chaque recette et chaque technique par cœur.

Mais un jour, on vous demande de cuisiner un plat à base d'un nouvel ingrédient que personne n'a jamais utilisé avant, et dont il n'existe aucune recette dans vos livres de cuisine. C'est exactement le défi que pose le langage de programmation Cangjie.

Voici l'histoire de la recherche présentée dans ce papier, racontée simplement :

1. Le Problème : Le Chef perdu dans une nouvelle cuisine

Les intelligences artificielles actuelles (les LLM) sont formées sur des montagnes de données existantes. Elles excellent en Python ou en C++ (les "ingrédients" classiques). Mais Cangjie, un nouveau langage créé par Huawei pour les systèmes d'exploitation modernes (comme HarmonyOS), est comme un ingrédient mystérieux. Il y a très peu de recettes disponibles sur Internet.

Les chercheurs se sont demandé : "Si on donne à notre chef génie une recette en français (Python) et qu'on lui demande de la cuisiner avec cet ingrédient mystérieux (Cangjie), va-t-il réussir ?"

2. La Solution : Le "CangjieBench" (Le nouveau livre de recettes)

Pour tester cela, les chercheurs ont créé CangjieBench.

L'idée : Ils n'ont pas cherché des recettes existantes (car il n'y en a pas). À la place, ils ont pris des défis de cuisine classiques (des problèmes de logique connus en Python) et les ont traduits manuellement en langage Cangjie.
Pourquoi ? C'est comme si vous preniez un plat complexe (un soufflé) et que vous écriviez la recette en utilisant uniquement les règles de cet ingrédient mystérieux. Cela garantit que le test est juste : on ne teste pas si le chef a "mémorisé" la recette, mais s'il comprend la logique et peut l'adapter.

3. Les 4 Stratégies de Cuisine (Les Méthodes Testées)

Les chercheurs ont testé comment le chef pouvait réussir ce nouveau plat en utilisant quatre approches différentes :

A. La Devinette Pure (Direct Generation) :
Le chef regarde le plat à faire et essaie de cuisiner sans aucune aide.
- Résultat : Catastrophe. Il invente des ingrédients qui n'existent pas. Le plat ne tient pas debout (le code ne compile pas).
B. Le Guide de Cuisine Rapide (Syntax-Constrained) :
On donne au chef une petite carte avec les règles de base de l'ingrédient mystérieux (ex: "ici, on met le sel avant le poivre", "les mots-clés sont en majuscules").
- Résultat : C'est le meilleur rapport qualité/prix ! Le chef comprend la logique et, avec ces petites règles, il réussit à cuisiner un excellent plat. C'est efficace et ne coûte pas cher en temps.
C. Le Rechercheur de Recettes (RAG - Retrieval Augmented Generation) :
Le chef a le droit de fouiller dans une bibliothèque de vieux documents ou de recettes volées pour trouver des indices.
- Résultat : Ça aide un peu, mais le chef a du mal à trouver les bonnes infos dans la masse de documents. C'est moins efficace que d'avoir juste les règles claires (la méthode B).
D. Le Chef Apprenti Actif (Agent) :
On donne au chef un téléphone et on lui dit : "Si tu ne sais pas faire, appelle le manuel, lis la page, puis essaie. Si ça rate, relis et corrige." Le chef agit comme un vrai développeur qui cherche des infos en ligne.
- Résultat : C'est la méthode qui donne les meilleurs résultats (le plat est parfait !). Mais c'est très long et très coûteux en énergie (le chef passe 99% de son temps à lire le manuel et 1% à cuisiner).

4. La Surprise : Traduire vs Inventer

Une découverte amusante : il est parfois plus difficile de traduire une recette existante (du Python vers le Cangjie) que de créer le plat à partir de zéro (de la description en texte vers le Cangjie).

Pourquoi ? Quand le chef voit la recette en français, il a tendance à copier les gestes du français (la grammaire du Python) au lieu de penser en "Cangjie". Il se fait piéger par ses anciennes habitudes. C'est ce qu'on appelle un "transfert négatif".

En Résumé

Ce papier nous apprend deux choses importantes pour l'avenir de l'IA :

Les règles claires sont magiques : Pour apprendre un nouveau langage, donner à l'IA une liste de règles simples (comme un guide de cuisine) est souvent plus efficace et moins cher que de lui faire chercher des infos partout.
L'IA est un grand logique, mais un mauvais imitateur : Elle comprend très bien la logique des problèmes, mais elle a du mal à changer ses habitudes de syntaxe (la façon d'écrire) quand on lui montre un exemple de l'ancien langage.

C'est une étape cruciale pour préparer l'IA à travailler avec les technologies de demain, même quand il n'y a pas encore de "recettes" disponibles sur Internet.

Each language version is independently generated for its own context, not a direct translation.

1. Problématique

Les grands modèles de langage (LLM) excellent dans la génération de code pour des langages à haute ressource (comme Python ou C++), mais peinent considérablement avec les langages à faible ressource. La recherche existante se concentre principalement sur les langages spécifiques à un domaine (DSL) comme Verilog ou Solidity, ce qui rend difficile la distinction entre un manque de connaissances syntaxiques et un manque d'expertise de domaine.

De plus, les besoins industriels croissants, notamment avec l'écosystème HarmonyOS de Huawei, exigent des langages modernes capables de gérer des scénarios de calcul variés (du périphérique embarqué au cloud). Cangjie, un langage généraliste développé par Huawei, répond à ce besoin mais souffre d'un manque de corpus public à grande échelle. Cela pose un défi unique : comment évaluer et améliorer la capacité de généralisation des LLMs vers un langage généraliste nouveau, sans contamination des données d'entraînement et sans mise à jour des paramètres du modèle (fine-tuning) ?

2. Méthodologie

Les auteurs proposent une approche structurée en trois volets : la construction du benchmark, la définition des tâches et l'évaluation de différentes stratégies d'inférence.

A. Construction du Benchmark (CANGJIEBENCH)

Pour pallier l'absence de données, l'équipe a adopté une stratégie de traduction manuelle plutôt que de scraping, garantissant une absence totale de contamination des données.

Sources : Traduction de HumanEval (tâches fonctionnelles) et ClassEval (tâches orientées objet) depuis Python vers Cangjie.
Volume : 248 échantillons de haute qualité (164 de HumanEval, 84 de ClassEval).
Principes de traduction :
- Adaptation stricte des types (ex: int $\to$ Int64).
- Préservation des conventions de nommage (snake_case).
- Reproduction fidèle des flux algorithmiques.
- Gestion des dépendances (exclusion des tâches nécessitant des bibliothèques tierces absentes de Cangjie, comme sqlite3 ou PIL).
Validation : Vérification manuelle par des experts du langage pour assurer la justesse des cas de test et des solutions.

B. Tâches d'Évaluation

Le benchmark évalue deux types de tâches :

Text-to-Code : Génération de code Cangjie à partir d'instructions en langage naturel.
Code-to-Code : Traduction de code Python existant vers Cangjie.

C. Stratégies d'Évaluation

L'étude compare quatre paradigmes d'inférence sur divers LLMs (GPT-5, DeepSeek-V3, Qwen3, Kimi-K2, etc.) sans fine-tuning :

Génération Directe (Zero-shot) : Le modèle tente de générer du code uniquement à partir de la description du problème.
Génération Contrainte par la Syntaxe : Injection de règles grammaticales concises et expertes dans le prompt pour guider le modèle.
RAG (Retrieval-Augmented Generation) :
- RAG (Docs) : Récupération de segments de documentation officielle.
- RAG (Code) : Récupération d'exemples de code Cangjie existants.
Agents : Utilisation d'agents CLI autonomes capables d'interroger la documentation, d'exécuter des tests et de corriger itérativement le code (simulation d'un processus de développement humain).

3. Résultats Clés

Les expériences révèlent des tendances significatives concernant la généralisation des LLMs :

Échec de la Génération Directe : Les modèles obtiennent des scores Pass@1 très faibles (< 5% pour la plupart, ~4% pour GPT-5 en moyenne). Les taux de compilation sont quasi identiques aux taux de réussite, indiquant que l'échec provient d'un manque de connaissances syntaxiques et non de logique algorithmique.
Efficacité de la Contrainte Syntaxique : L'ajout de règles grammaticales dans le prompt améliore drastiquement les performances. Par exemple, GPT-5 passe de 4,3% à 53,8% en Pass@1. Cela démontre que les LLMs possèdent déjà la logique algorithmique, mais bloquent sur la syntaxe de surface. C'est le meilleur compromis entre coût (tokens) et précision.
Limites du RAG : Bien que supérieur à la génération directe, le RAG (Code et Docs) sous-performe par rapport à la méthode contrainte par la syntaxe. Le RAG échoue souvent car les modèles ne parviennent pas à généraliser des règles complexes à partir d'exemples isolés ou génèrent de mauvaises requêtes de recherche.
Performance des Agents : L'approche par Agent (notamment avec GPT-5) atteint l'état de l'art (77,6% de Pass@1). Cependant, elle est extrêmement coûteuse en tokens (consommation massive due aux itérations et à la lecture de documentation).
Phénomène de Transfert Négatif (Code-to-Code) : Paradoxalement, la traduction de Python vers Cangjie fonctionne souvent moins bien que la génération à partir de texte. Les modèles tendent à sur-adapter les patterns de Python (typage dynamique, idiomes) et échouent à respecter la syntaxe statique stricte de Cangjie.

4. Contributions Principales

CANGJIEBENCH : Le premier benchmark complet et sans contamination pour un langage généraliste à faible ressource (Cangjie), couvrant la génération et la traduction de code.
Perspective de Recherche : Traitement de Cangjie comme un langage généraliste (et non un DSL), permettant d'évaluer purement la capacité d'apprentissage de nouvelles syntaxes sans interférence de connaissances de domaine.
Analyse Comparative des Paradigmes : Évaluation systématique de quatre approches (Direct, Syntax-Constrained, RAG, Agent), identifiant la génération contrainte par la syntaxe comme la méthode la plus efficace pour un déploiement pratique (coût/précision).
Découverte du Transfert Négatif : Mise en évidence du fait que fournir le code source (Python) peut nuire à la performance de traduction vers un langage à faible ressource en raison de l'interférence des patterns de la source.

5. Signification et Implications

Ce travail offre des perspectives cruciales pour l'avenir de l'adaptation des LLMs aux nouveaux langages de programmation :

Alternative au Fine-Tuning : Il démontre que pour les langages émergents, l'ajout de contexte (règles syntaxiques) dans le prompt est une alternative viable et immédiate au fine-tuning coûteux en données et en calcul.
Stratégie Hybride : Les auteurs suggèrent une approche hybride : utiliser la génération contrainte pour les tâches simples et basculer vers des agents uniquement lorsque la compilation échoue ou que la complexité le requiert.
Futur de la Traduction de Code : Il souligne la nécessité de développer des méthodes de traduction sémantique (passant par une représentation intermédiaire) plutôt que littérale (ligne par ligne) pour éviter les interférences syntaxiques entre la source et la cible.
Ressource pour la Communauté : CANGJIEBENCH fournit un terrain d'essai standardisé pour évaluer la capacité des modèles à s'adapter à des écosystèmes logiciels nouveaux, comme celui d'HarmonyOS.

En conclusion, l'article établit que la barrière principale pour les LLMs face aux nouveaux langages n'est pas la logique, mais la syntaxe, et que des méthodes d'inférence ciblées (contraintes syntaxiques) peuvent surmonter cette barrière de manière efficace.