Contribution Open-Source aux packages NLP

Un projet open source peut être défini comme un code source mis à la disposition du public pour être visualisé, utilisé, modifié et distribué sous une licence permissive. D'importants projets open source sont le résultat de contributions de personnes possédant non seulement des compétences en codage, mais également en documentation, en nettoyage de code et d'autres compétences.

Toute correction de faute de frappe, l'ajout d'une alerte sur un éventuel avertissement du compilateur, la correction d'un bogue ou même l'ajout d'une documentation détaillée à un projet peuvent être considérés comme une contribution open source.

Comment est le décor Open-source en PNL ?

Il existe plusieurs guides sur les contributions open-source (OSC) et sur la façon de démarrer avec votre première pull request. Compte tenu de la grande quantité de données textuelles disponibles sur Internet, le traitement du langage naturel s'est considérablement développé ces dernières années. Différents packages répondent aux besoins de divers flux de travail basés sur la PNL. TensorFlow , par exemple, utilise Keras-NLP comme module de flux de travail NLP holistique. Pytorch et TorchText forment ensemble TorchNLP pour tous les réglages fins basés sur les transformateurs à l'aide de PyTorch.

Étant donné que j'ai un vif intérêt pour le traitement du langage naturel et la linguistique computationnelle, je voulais que ma première contribution open-source soit sur le même sujet. En décembre 2022, j'ai été accepté dans la deuxième cohorte du programme de mentorat Kaggle BIPOC et j'ai commencé à travailler sur le package NLP-Profiler de Mani Sarkar pour y apporter des améliorations et y ajouter des fonctionnalités. Je tiens à le remercier pour son soutien constant, ses encouragements et son mentorat tout au long du programme.

Qu'est-ce que NLP-Profiler ?

NLP Profiler est un programme/une bibliothèque qui profile les données textuelles, extrait les données spécifiques à la PNL innées dans les corpus et produit des détails statistiques sur les données textuelles. Nous pouvons le considérer comme pandas.describe()mais sur des données textuelles. Il produit une trame de données sur laquelle vous pouvez ensuite exécuter la describe() fonction pour obtenir des statistiques descriptives.

Nous pouvons installer le NLP-Profiler en utilisant pip/pip3 sur les notebooks Kaggle et Colab. Pour travailler avec lui localement, il peut être construit à partir de la source . On commence par :

Une fois que nous avons le package dans notre environnement, nous pouvons l'utiliser pour obtenir un aperçu des données textuelles. En supposant que nous ayons une trame de données avec des données textuelles dans la colonne "texte", nous pouvons développer la trame de données récapitulative de la manière suivante :

Le "profiled_text_dataframe" est livré avec diverses fonctionnalités telles que le nombre de phrases, le nombre de caractères, la subjectivité des sentiments, le score de qualité orthographique, la facilité de vérification de la lecture, etc.

Cette base de données peut maintenant être utilisée à des fins statistiques et mathématiques pour développer des pipelines linguistiques computationnels. Par conséquent, le package bénéficie de la synthèse mathématique des données textuelles.

Comment ai-je contribué au package ?

Contribuer à n'importe quel package nécessite une analyse méticuleuse des différentes dépendances et fonctionnalités. Le NLP-Profiler dépend de plusieurs packages d'analyse linguistique et sémantique qui sont volatils mais aussi très couramment utilisés. Ceux-ci incluent TextBlob , Spacy , etc. Le relâchement de la dépendance vis-à-vis de ces packages diminue non seulement le temps de réponse du package, mais augmente également la stabilité du package. De plus, si nous n'épinglons pas les dépendances, nous finissons par rencontrer des résultats ou des comportements inattendus conduisant à des échecs de CI. Comme les packages continuent d'évoluer et que de multiples contributions ont lieu dans le référentiel de packages, il est tout à fait nécessaire de conserver un journal des modifications et de tester le flux de bout en bout du package à chaque fois qu'une modification est apportée.

J'ai commencé par lire la documentation et comment elle est implémentée dans les notebooks Jupyter (Colab/ Kaggle). Le package souffrait initialement de conflits de dépendance avec les environnements Colab et Kaggle. Cela a été facilement résolu en modifiant l'ordre dans lequel les packages ont été installés par pip dans les ordinateurs portables et en désinstallant le package "typing" avant de l'installer.

Un examen détaillé des problèmes ouverts et des demandes d'extraction vous permet de mieux comprendre les domaines du package qui nécessitent des corrections ou qui sont ouverts aux contributions. Vous pouvez soit choisir l'un des problèmes ouverts, soit rechercher les sections du package qui nécessitent des améliorations et commencer à collaborer avec les développeurs.

J'ai passé en revue les problèmes et les différentes fonctionnalités et j'ai trouvé certaines pistes d'amélioration. La fonction de vérification de la grammaire , lorsqu'elle a été testée sur de grands ensembles de données textuelles, a mis très longtemps à répondre. Cela dépendait du package language-tool-python qui ne tenait pas compte des ponctuations et avait un temps de réponse élevé. J'ai remplacé le package par Gingerit : un outil de correction grammaticale basé sur le contexte de phrases complètes. Lorsqu'il a été testé dans des notebooks Jupyter, le temps de réponse du profileur, dans l'ensemble, a été réduit de 8 secondes .

De plus, le calcul de la fonction de vérification orthographique a également mis beaucoup de temps à répondre, même pour de petits ensembles de données. Il était basé sur la formule :

La formule peut être remplacée par des algorithmes flous pour s'adapter à toutes sortes de calculs de pénalité de faute d'orthographe. Par exemple, "I ma bda persno" produit un score d'orthographe de 85% avec la formule. Cependant, avec des algorithmes flous, il produit un score de 73% qui est en meilleure parité avec la perception humaine. De plus, l'exigence d'utiliser TextBlob pour la tokenisation peut également être assouplie en utilisant le package SymSpell , qui prétend être beaucoup plus rapide que tout autre vérificateur d'orthographe disponible.

Ces changements, avant d'être intégrés, doivent être documentés dans les pull requests, faites pour chacun d'entre eux. Certaines directives doivent être obligatoirement suivies pour toute personne qui crée une pull request. Ces lignes directrices aident à maintenir la stabilité de la branche master du référentiel et informent le contributeur des éventuels conflits pouvant découler des modifications qu'il a apportées.

Le test sur la machine locale, avant de créer une pull request, est très nécessaire. Le référentiel comporte certains tests « lents » et « fumées » qui doivent être exécutés sur le référentiel modifié, de votre côté, avant de faire une demande d'extraction.

De plus, le référentiel dispose du plug-in Sourcery AI , qui vérifie les modifications apportées et fournit un rapport détaillé indiquant si les modifications améliorent la qualité du référentiel et, dans le cas contraire, où des améliorations sont nécessaires. GitHub Action effectue plusieurs autres vérifications telles que CodeQL , End-to-End flow et pre-commit . Ceux-ci garantissent la fusion sans conflit des demandes d'extraction.

À faire et à ne pas faire

Il y a quelques consignes à respecter. Celles-ci sont entièrement basées sur mon expérience, jusqu'à présent.

1. Lisez les fichiers Markdown qui contiennent des détails sur les contributions et les modifications apportées jusqu'à présent. Ceux-ci sont nécessaires pour avoir une idée préliminaire du flux de travail.
2. Autorisez les actions Github sur votre référentiel forké à exécuter des actions de flux de travail de bout en bout pour chaque branche, afin de garantir la stabilité de la construction.
3. Le test sur un environnement local avec plusieurs scénarios de test est obligatoire pour s'assurer que les modifications fonctionnent comme prévu.
4. Pour un contributeur amateur comme moi, il est essentiel d'être minutieux avec le package avant d'apporter des modifications massives.
5. Résoudre les dépendances ou créer l'environnement local pour les tests peut être difficile. On peut passer à l' alternative Github1s , qui permet un éditeur en ligne VSCode par référentiel.

Portée future

Le fichier du vérificateur d'orthographe doit être corrigé davantage car il a échoué à certains tests d'acceptation et de performances. Cela doit être corrigé et, par conséquent, est mentionné dans les problèmes ouverts du référentiel. Certaines fonctionnalités granulaires telles que ' répétition_lettres_count ', ' répétition_numériques ' , ' répétition_espaces_compte ', ' répétition_espaces_blancs ', ' répétition_ponctuations_compte ', ' english_characters_count ' et ' non_english_characters_count ' doivent être corrigées car elles ont tendance à ne pas être produites lorsque le profileur est invoqué.

Compte tenu de l'expérience que j'ai acquise en travaillant sur ce package, j'aspire à contribuer à Keras-NLP de manière similaire et à ajouter au monde de la linguistique, à ma manière humble.

Les références

1. Problèmes ouverts de NLP-Profiler
2. Créer un environnement local
3. Cahier Kaggle NLP-Profiler
4. Tests de construction dans Github
5. Pull-Requests sur lesquels j'ai travaillé : 1. Correcteur orthographique 2. Correcteur grammatical
6. Travaux complémentaires : 1. Bug à corriger 2. Rendre le package compatible python3.9
7. Mises à jour supplémentaires sur le package.
8. Les partisans du forfait .
9. Guide des cotisations.
10. Forfaits supplémentaires pour contribuer à .
11. Éditeur d'extraits de code