💬 NLP

ArkTS-CodeSearch: A Open-Source ArkTS Dataset for Code Retrieval

Ce document présente ArkTS-CodeSearch, le premier ensemble de données et benchmark systématique en open-source dédié à la recherche de code et à la compréhension du langage ArkTS pour l'écosystème OpenHarmony.

Auteurs originaux : Yulong He, Artem Ermakov, Sergey Kovalchuk, Artem Aliev, Dmitry Shalymov

Publié 2026-02-10

📖 3 min de lecture☕ Lecture pause café

CC BY 4.0

Auteurs originaux : Yulong He, Artem Ermakov, Sergey Kovalchuk, Artem Aliev, Dmitry Shalymov

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Le Problème : La "Langue Perdue" de la Technologie

Imaginez que vous venez d'arriver dans un pays magnifique, l'OpenHarmony (un système qui fait fonctionner des objets connectés, des montres, des voitures, etc.). Dans ce pays, tout le monde parle une langue très spécifique pour construire des choses : l'ArkTS.

Le problème ? C'est une langue très récente. Les grands traducteurs automatiques (les intelligences artificielles comme ChatGPT ou les outils de recherche de code) sont comme des touristes qui ne connaissent que l'anglais ou le français. Ils voient l'ArkTS, mais ils ne le comprennent pas vraiment. Ils sont perdus. Ils ne savent pas quel "mot" (quelle fonction de code) correspond à quelle "idée" (quelle description en langage humain).

La Solution : Le "Grand Dictionnaire de l'ArkTS"

Les chercheurs de cet article ont décidé de créer la première véritable bibliothèque de référence pour cette langue.

Voici ce qu'ils ont fait, étape par étape, avec des métaphores :

1. La Grande Cueillette (Data Collection)
Au lieu d'attendre que les gens écrivent des dictionnaires, ils sont allés sur les "marchés mondiaux" du code (GitHub et Gitee). Ils ont ramassé des milliers de petits morceaux de code ArkTS, comme on ramasserait des fleurs sauvages dans une prairie, pour construire leur propre jardin.

2. Le Tri Sélectif (Parsing & Extraction)
Ils n'ont pas juste pris n'importe quoi. Ils ont utilisé un outil très précis (un "parseur") qui agit comme un chirurgien. Au lieu de prendre un bloc de texte informe, ils ont découpé chaque morceau pour isoler :

La "recette" (le code informatique).
La "note de cuisine" (le commentaire qui explique ce que fait la recette).
C'est ce duo "Recette + Explication" qui est la clé.

3. L'Entraînement des Traducteurs (Fine-Tuning)
C'est la partie la plus cool. Ils ont pris des traducteurs existants (des modèles d'IA) et les ont envoyés à l'école.

L'astuce du "cousin proche" : Comme l'ArkTS ressemble beaucoup au TypeScript (une autre langue de programmation très connue), ils ont d'abord appris aux traducteurs le TypeScript. C'est comme apprendre l'espagnol avant d'apprendre l'italien : ça aide énormément !
Le test de la similarité : Ils ont entraîné l'IA à comprendre que si je dis "faire un gâteau au chocolat", elle doit pointer vers la recette qui contient "sucre, cacao, farine", même si le mot "gâteau" n'est pas écrit dans la recette.

Les Résultats : Qui est le meilleur élève ?

Ils ont testé plusieurs "étudiants" (modèles d'IA) et ont découvert deux choses surprenantes :

La taille ne fait pas tout : On pourrait croire qu'il faut le plus gros cerveau (le modèle avec le plus de paramètres) pour réussir. Mais ils ont vu qu'un "étudiant moyen" bien entraîné spécifiquement sur l'ArkTS pouvait battre un "génie" qui n'avait jamais étudié cette langue. C'est la spécialisation qui gagne, pas la force brute.
L'importance de la culture : Comme beaucoup de commentaires dans ce code sont en chinois, les IA qui connaissent déjà bien le chinois ont été de bien meilleurs traducteurs que celles qui ne connaissaient que l'anglais.

En résumé

Ce papier, c'est comme si ces chercheurs avaient créé le premier manuel scolaire et le premier dictionnaire complet pour une nouvelle langue technologique. Grâce à eux, les futurs développeurs pourront demander à leur ordinateur : "Trouve-moi le code qui permet d'afficher un bouton bleu", et l'ordinateur comprendra enfin l'ArkTS pour leur répondre instantanément.

Résumé Technique : ArkTS-CodeSearch

1. Problématique (Le Problème)

L'écosystème OpenHarmony s'étend rapidement, utilisant le langage ArkTS (dérivé de TypeScript) comme langage de programmation central. Cependant, la recherche en intelligence logicielle (recherche de code, recommandation, analyse automatique) pour ArkTS est freinée par un obstacle majeur : l'absence de jeux de données (datasets) publics et de bancs d'essai (benchmarks) standardisés. Les modèles de langage actuels sont largement entraînés sur des langages dominants (Python, Java, JavaScript), créant un fossé de représentation pour les langages émergents comme ArkTS, ce qui limite l'efficacité des outils d'assistance au développement.

2. Méthodologie

Les auteurs ont mis en place un pipeline complet pour construire un benchmark de recherche sémantique de code :

Collecte de données : Ils ont extrait des dépôts de code source à partir de GitHub et Gitee (essentiel pour couvrir la communauté OpenHarmony, très active sur Gitee). Ils ont identifié 1 577 dépôts uniques et filtré les fichiers avec l'extension .ets.
Extraction structurée : Au lieu d'utiliser des expressions régulières simples, ils ont utilisé tree-sitter-arkts pour parser le code en arbres de syntaxe abstraite (AST). Cela a permis d'extraire avec précision des paires "docstring (commentaire) – fonction/classe".
Tâche de recherche (Single-search) : La tâche consiste à utiliser une description en langage naturel (docstring) pour retrouver la fonction ArkTS correspondante dans un espace vectoriel.
Stratégies d'entraînement (Fine-tuning) : Pour améliorer les modèles d'embedding existants, ils ont testé trois configurations :
1. ARKTS-TRAINING : Entraînement uniquement sur les données ArkTS.
2. TS-TRAINING : Entraînement sur un large corpus TypeScript (langage parent).
3. TS $\rightarrow$ ARKTS-TRAINING : Une stratégie en deux étapes (adaptation préalable sur TypeScript, puis affinement sur ArkTS).
Objectif d'apprentissage : Utilisation de la perte de classement par négatifs multiples (Multiple Negatives Ranking Loss) pour aligner les représentations sémantiques du texte et du code via l'apprentissage contrastif.

3. Contributions Clés

Premier Dataset ArkTS à grande échelle : Un ensemble de données public contenant 24 452 fonctions ArkTS appariées à leurs docstrings.
Établissement d'un Benchmark : Création d'un protocole d'évaluation standardisé (basé sur CodeSearchNet) utilisant des métriques de recherche d'information (MRR, NDCG, Recall).
Modèle Fine-tuné : Publication d'un modèle d'embedding optimisé pour ArkTS, disponible sur Hugging Face.

4. Résultats Principaux

Supériorité du Fine-tuning : L'application de modèles "off-the-shelf" (prêts à l'emploi) est insuffisante. Le fine-tuning améliore considérablement les performances sur toutes les métriques.
Efficacité de la stratégie en deux étapes : La méthode TS $\rightarrow$ ARKTS surpasse souvent l'entraînement direct, car elle permet au modèle de bénéficier de la richesse sémantique de TypeScript avant de se spécialiser.
Importance de la taille vs spécialisation : Les résultats montrent que des modèles de taille moyenne (ex: embeddinggemma-300m) bien entraînés sur le domaine spécifique peuvent surpasser des modèles beaucoup plus grands (ex: Qwen3-0.6B) qui ne sont pas spécialisés.
Facteur linguistique : Les modèles orientés vers le chinois (comme bge-base-zh) obtiennent de meilleurs résultats que les modèles purement anglais, car une part importante de la documentation ArkTS est rédigée en chinois.
Échec du lexical : L'algorithme classique BM25 est nettement moins performant que les méthodes basées sur les embeddings (vecteurs denses), prouvant que la recherche sémantique est indispensable pour ArkTS.

5. Signification et Impact

Ce travail est crucial pour l'avenir de l'écosystème HarmonyOS NEXT. En fournissant l'infrastructure nécessaire (données et benchmarks), les auteurs permettent à la communauté scientifique de développer des outils de génération de code, de détection de bugs et de migration de code plus performants. Cela réduit la barrière à l'entrée pour les chercheurs et favorise l'émergence d'outils de développement intelligents pour les langages de programmation non-occidentaux et émergents.