JioNLP : la boîte à outils chinoise qui reste en dehors du pipeline neuronal

Le problème que JioNLP prend en charge, et celui qu'il laisse de côté

Un pipeline de traitement du langage en chinois commence rarement par un modèle. Il commence par du nettoyage : retirer les balises HTML, les URL, les adresses électroniques, les numéros de téléphone, convertir les lettres et chiffres pleine chasse en demi-chasse. Ensuite viennent les conversions de formats : une date écrite en chinois (« 下周三 », « 三个月后 »), un montant en toutes lettres, une adresse postale, un numéro de carte d'identité à dix-huit chiffres. Ces tâches n'ont pas besoin de gradient ni de GPU, et pourtant elles décident de la qualité de tout ce qui suit.

JioNLP se présente comme un paquet de prétraitement et d'analyse, et le README le destine explicitement aux développeurs NLP. La fonction clean_text illustre bien cette orientation : elle cumule le nettoyage des caractères anormaux et redondants, des balises HTML, des informations entre parenthèses, des URL, des courriels et des numéros de téléphone, plus la conversion pleine chasse vers demi-chasse. Ce n'est pas un modèle, c'est une passe déterministe qu'on peut relire et corriger.

Le public visé n'est donc pas celui qui cherche un modèle pré-entraîné chinois. C'est celui qui a déjà ce modèle et qui bute sur les couches de normalisation en amont, ou celui qui construit un système d'extraction d'informations à base de règles et veut éviter de réécrire sa propre bibliothèque de regex pour la troisième fois.

Tables lexicales, expressions régulières et une seule fonction qui sort du lot

Le README classe les fonctions en trois familles : un ensemble de petits utilitaires (小工具集), l'augmentation de données, puis l'extraction et l'analyse par expressions régulières. Cette organisation dit quelque chose sur l'architecture : la majorité des fonctions sont des analyseurs déterministes adossés à des ressources embarquées dans le paquet, dont la taille annoncée par le badge du dépôt est de 15,6 Mo. Une part importante de ce poids correspond aux tables lexicales et aux dictionnaires, pas au code.

Prenons parse_location : la fonction reçoit une chaîne d'adresse chinoise et en extrait la province, la ville, le district ou comté, le canton ou sous-district, et le village ou quartier. Une telle extraction ne s'invente pas. Elle suppose une hiérarchie administrative stockée quelque part dans le paquet, et cette hiérarchie doit être mise à jour quand les découpages administratifs changent. C'est le coût caché de toutes les fonctions de cette famille.

Le README signale lui-même que parse_time est la fonction la plus utilisée. Elle prend un texte temporel et renvoie sa sémantique, horodatage et durée comprises. C'est aussi la seule pour laquelle le dépôt propose un service : le README indique qu'une version personnalisée aux meilleurs résultats est disponible en contactant l'auteur par WeChat. Cette phrase mérite d'être lue attentivement, car elle délimite la promesse de l'outil open source. La version publiée est la version générique.

D'autres fonctions suivent le même modèle d'analyse par règles : parse_motor_vehicle_licence_plate pour les plaques d'immatriculation, parse_id_card pour les numéros de carte d'identité (province, ville, comté, date de naissance, sexe, chiffre de contrôle), extract_money pour les montants, extract_parentheses pour le contenu entre crochets, parenthèses et guillemets chinois. Deux fonctions de cette famille sont notées d'une étoile dans le tableau du README : clean_text et extract_money.

Augmentation de données : ce qui dépend du réseau et ce qui n'en dépend pas

La deuxième famille du paquet concerne l'augmentation de données textuelles, et elle se divise en deux groupes qu'il vaut la peine de distinguer avant d'adopter l'outil.

Le premier groupe fonctionne hors ligne. swap_char_position échange aléatoirement la position de caractères proches. homophone_substitution remplace des mots par leurs homophones. random_add_delete insère ou supprime des caractères au hasard. replace_entity substitue des entités à partir d'un dictionnaire, ce que le README présente comme applicable à l'étiquetage de séquences et à la classification de textes.

Le second groupe, BackTranslation, ne fonctionne pas hors ligne. Le README précise qu'il s'appuie sur les interfaces de traduction automatique de plusieurs plateformes cloud. Autrement dit, la fonction ne contient pas de modèle de traduction : elle orchestre des appels à des services tiers. Cela implique des clés d'API, une connexion réseau, un coût par appel et, selon le fournisseur choisi, l'envoi de vos données textuelles à un service externe. Pour un jeu de données interne ou sensible, ce point doit être tranché avant l'installation, pas après.

Cette asymétrie est la caractéristique la plus intéressante de cette section. Quatre méthodes d'augmentation sur cinq sont locales et reproductibles ; une seule introduit une dépendance externe, et c'est précisément celle que le README met en avant avec une étoile.

Installation et premiers appels

L'installation tient en une ligne, telle que donnée dans le README :

pip install jionlp

Le paquet s'importe sous l'alias jio, convention utilisée dans tous les exemples du README :

import jionlp as jio print(jio.__version__) dir(jio) print(jio.extract_parentheses.__doc__)

Cette dernière ligne est le mécanisme de découverte que le projet privilégie : les docstrings des fonctions servent de documentation de premier niveau, et le README invite à les consulter plutôt qu'à parcourir une documentation séparée. Le paquet expose aussi une fonction help, décrite comme une recherche par mots-clés lorsque l'on ne sait pas quelle fonction existe. C'est un choix cohérent avec un paquet qui regroupe des dizaines de fonctions aux noms longs et peu mémorisables.

Deux points pratiques ressortent de ces commandes. D'abord, la version est accessible par jio.__version__, ce qui permet de l'épingler dans un fichier de dépendances, et c'est utile étant donné la quantité de tables embarquées. Ensuite, dir(jio) reste le moyen le plus fiable de savoir ce que contient réellement la version installée, car le README lui-même indique qu'il faut descendre dans la page et utiliser Ctrl+F pour s'y retrouver. Un sommaire de cette taille est un signal : l'API est large et plate, sans espaces de noms intermédiaires visibles dans le matériel fourni.

Le dépôt contient également un répertoire test, avec au moins un fichier mentionné, test/test_mellm.py, qui porte sur MELLM, un algorithme d'évaluation mutuelle de grands modèles de langage ajouté en décembre 2023. Ce fichier n'a rien à voir avec les fonctions de prétraitement, et il faut télécharger deux fichiers JSON depuis un lien externe avant de l'exécuter. Le README précise que le mot de passe d'accès est fourni dans la page. C'est une dépendance à un hébergement tiers pour faire tourner un test, ce qui complique toute intégration en chaîne d'intégration continue.

Ce que le paquet ne fait pas, et où il devient le mauvais outil

Le README ne liste nulle part de fonction de segmentation en mots, d'étiquetage morphosyntaxique ou de reconnaissance d'entités nommées par apprentissage. remove_stopwords, par exemple, prend en entrée une liste de mots déjà segmentée. La segmentation est donc supposée faite ailleurs, par un autre outil. Si votre besoin principal est de découper du chinois en mots, JioNLP ne le couvre pas, et l'installer ne vous avancera pas.

Deuxième limite, plus discrète : plusieurs fonctions reposent sur des ressources dont la fraîcheur n'est pas vérifiable depuis le matériel fourni. parse_location s'appuie sur un découpage administratif qui évolue ; phone_location et cell_phone_location reposent sur des plages d'attribution d'opérateurs qui changent aussi. Le dépôt a reçu une poussée en juillet 2026 selon les métadonnées, mais aucune version publiée n'a été récupérée, et le README affiche un badge de version 1.5.29. Impossible de dire depuis ces seuls éléments à quelle date remontent les tables d'adresses et de préfixes téléphoniques. C'est le point à vérifier en premier si votre usage dépend de ces fonctions.

Troisième limite : les fonctions notées d'une étoile dans le README ne sont pas toutes du même niveau. extract_keyphrase et extract_summary sont présentées comme des extractions, sans indication de méthode ni de mesure de qualité dans le matériel fourni. Sur un domaine spécialisé, une extraction par règles ou par statistiques de surface peut produire des résultats plausibles mais inutilisables. Le README ne donne aucun chiffre permettant d'en juger, et je ne peux pas en inventer.

Enfin, la présence de filtres de données présentés comme « 色情 » et « 反动 » dans le tableau des utilitaires, sans nom de fonction associé (les cellules correspondantes sont vides), laisse penser que ces fonctions existent mais ne sont pas documentées au même niveau que les autres. À traiter comme non documenté.

Face à quoi : jieba et les chaînes à base de modèles

L'alternative la plus directe pour un développeur chinois est jieba, qui vise la segmentation en mots et l'extraction de mots-clés à partir d'un dictionnaire de fréquences et d'un modèle de découpage. La différence d'approche est nette : jieba répond à la question « où sont les frontières entre les mots ? », JioNLP répond à la question « que signifie cette chaîne de caractères ? ». Une date relative, une adresse, un montant, un numéro de carte d'identité ne se segmentent pas utilement, ils s'analysent. Les deux outils se cumulent plus qu'ils ne se remplacent, et le README de JioNLP suppose d'ailleurs que la segmentation a déjà eu lieu pour remove_stopwords.

L'autre alternative est la voie neuronale : un modèle pré-entraîné chinois fine-tuné pour l'extraction d'entités. Sur des entités générales comme les noms de personnes ou d'organisations, cette approche est plus robuste aux formulations inattendues qu'un ensemble de règles. Mais elle exige des données annotées, un entraînement, et elle reste difficile à auditer : quand un modèle se trompe sur une date, on ne peut pas corriger la règle fautive. JioNLP se situe à l'opposé de ce compromis. Ses erreurs sont localisables dans une expression régulière ou une table, ce qui compte dans les domaines où l'on doit expliquer un résultat.

Le choix se résume donc à un critère de nature de la tâche. Pour normaliser un format contraint (un identifiant, un montant, une date relative), les règles déterministes sont adaptées et peu coûteuses. Pour interpréter du langage libre, elles plafonnent vite.

Coût de maintenance et implications de licence

Le paquet est publié sous Apache-2.0, licence permissive qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver les mentions de copyright et le texte de la licence, et de signaler les fichiers modifiés. Elle comporte aussi une clause de brevets. Je ne donne pas de conseil juridique : la seule vérification utile de votre côté est de lire le fichier de licence du dépôt et de confirmer que les ressources embarquées dans le paquet (tables d'adresses, dictionnaires d'homophones, listes de stop words) sont couvertes par la même licence que le code. Le matériel fourni ne permet pas de trancher ce point.

Sur le coût de mise à jour, la structure du projet impose une contrainte précise : une fonction comme parse_location dépend d'un découpage administratif qui bouge. Une montée de version peut donc changer des résultats sur des adresses que votre chaîne traitait correctement, sans que le code de votre côté ait changé. Un test de non-régression sur un échantillon d'adresses et de dates réelles, exécuté à chaque mise à jour du paquet, est la seule protection sérieuse. Le README ne décrit pas de politique de versionnement sémantique, et aucune note de version n'a été récupérée.

Autre coût, celui de la découverte : avec une API plate de plusieurs dizaines de fonctions aux noms longs, l'arrivée d'un nouveau membre dans une équipe passe par dir(jio) et par les docstrings. C'est acceptable, mais cela signifie qu'il n'existe pas de frontière nette entre les fonctions stables et les fonctions expérimentales dans le matériel fourni. Les étoiles du README signalent des fonctions mises en avant, pas des garanties de stabilité.

Conclusion éditoriale

Adoptez JioNLP si votre chaîne traite du texte chinois et que vous avez besoin de normaliser des dates, des adresses, des montants ou des identifiants avant de les confier à un modèle, sans vouloir entraîner quoi que ce soit. Passez votre chemin si vous attendez une segmentation, un étiquetage en parties du discours ou une reconnaissance d'entités nommées neuronale : le paquet ne les fournit pas, et ses fonctions de découverte de nouveaux mots ou d'extraction de phrases clés ne remplacent pas un modèle entraîné. Avant d'intégrer quoi que ce soit, vérifiez deux points dans le dépôt : le contenu réel de la page wiki de parse_time, qui porte la promesse la plus forte du projet, et le fichier de licence, pour confirmer que les données lexicales embarquées dans le paquet relèvent bien de la même Apache-2.0 que le code.

Sources officielles

1. dongrixinyu/JioNLP on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README