Evaluation de petits LLM quantifiés sur une tâche de classification

seconde partie de l'année a été un peu différente : on a plutôt assisté à une diminution des tailles de modèles, avec notamment de nombreux modèles 7b, qui obtenaient les mêmes performances que des modèles de taille supérieure 13b, voire 40b, comme le français Mistral<fnref n="2" /> par exemple.

En même temps que la diminution du nombre de paramètres, un autre phénomène est apparu appelé la "quantification des modèles" qui vise à coder les poids des réseaux de neurones sur 16 bits, 8 bits, 4 bits voire moins au lieu de les coder sur 32 bits. Tous les poids ne sont d'ailleurs pas quantifiés de la même manière, mais l'objectif final est de disposer d'un modèle presque 10 fois plus petits tout en étant quasiment aussi performant. Les modèles ainsi quantifiés ou "quantified" sont stockés dans le format GGUF pour "Georgi Gerganov Universal Format" (remplaçant de GGML, devenue obsolète). Dès qu'un nouveau modèle est disponible auprès de la communauté, celui-ci est quantifié dans différentes qualités et rendu public, par des personnes comme "TheBloke"<fnref n="3" /> sur des sites comme HuggingFace ou autre<fnref n="4" />.

Les modèles quantifiés étant moins volumineux que leur version non quantifiée, ils deviennent utilisables sur des infrastructures plus légères comme des PC grand public. Un grand nombre de développeurs se sont alors emparés du phénomène pour développer des outils permettant d'utiliser ces modèles sur de telles infrastructures. On peut citer ici des outils comme **LoLLMS WebUI**<fnref n="5" />, **text-generation-webui**<fnref n="6" />, **koboldcpp**<fnref n="7" />, **LM Studio**<fnref n="8" />, **GPT4All**<fnref n="9" />, **Faraday**<fnref n="10" />, **Llama-cpp-python**<fnref n="11" />, **candle**<fnref n="12" /> ou **ctransformers**<fnref n="13" />. La plupart de ces outils sont construits au-dessus de **Llama.cpp**<fnref n="14" /> et offrent des APIs pour différents langages comme Python, Typescript, Go, C#, Java, Rust ou Go.

Dans ces conditions, quel modèle utiliser pour quoi faire ? Même s'il existe plusieurs "leaderboard", comme celui d**HuggingFace**<fnref n="15" /> pour les performances globales ou cet autre concernant les hallucinations<fnref n="16" /> ou encore ce très large panorama qui recense plusieurs approches pour évaluer les LLM (Guo et al., 2023), il est difficile de se fier uniquement aux scores affichés, sachant par exemple qu'il existe de grandes différences entre les langues et les tâches. Pour ces différentes raisons, nous présenterons une démarche pour évaluer des modèles 7b quantifiés sur une tâche de classification de textes rédigés en français.

<footnote n="2">2. https://mistral.ai/</footnote>

<footnote n="3">3. https://huggingface.co/TheBloke</footnote>

<footnote n="4">4. Explore the LLMs : https://llm.extractum.io/</footnote>

<footnote n="5">5. LoLLMs Web UI : https://github.com/ParisNeo/lollms-webui</footnote>

<footnote n="6">6. https://github.com/oobabooga/text-generation-webui</footnote>

<footnote n="7">7. https://github.com/LostRuins/koboldcpp</footnote>

<footnote n="8">8. https://lmstudio.ai/</footnote>

<footnote n="9">9. https://gpt4all.io/index.html</footnote>

<footnote n="10">10. https://faraday.dev/</footnote>

<footnote n="11">11. https://github.com/abetlen/llama-cpp-python</footnote>

<footnote n="12">12. https://github.com/huggingface/candle</footnote>

<footnote n="13">13. https://github.com/marella/ctransformers</footnote>

<footnote n="14">14. https://github.com/ggerganov/llama.cpp</footnote>

<footnote n="15">15. https://huggingface.co/spaces/HuggingFaceH4/open_llm leaderboard</footnote>

<footnote n="16">16. https://github.com/vectara/hallucination-leaderboard</footnote>
# 3 Corpus d'évaluation

Le corpus utilisé pour réaliser les tests qui suivent est un corpus en français, constitué d'avis sur des films, issus du site AlloCiné, extraits par Théophile Blard et rendus accessibles avec plusieurs résultats de classification (CamemBERT, RNN, CNN, LSTM et FastText) (Blard, 2020). Les avis sont étiquetés positif ou négatif. Trois corpus sont fournis : un corpus d'entraînement composé de 160 000 avis (corpus-train), un corpus de validation composé de 20 000 avis (corpus-valid) et un corpus de test composé de 20 000 avis (corpus-test). Dans l'article (Blard, 2020), c'est le modèle CamemBERT qui obtient le meilleur score. Les corpus train et valid servent à fine-tuner le modèle qui est ensuite appliqué sur le corpus-test. Il obtient un excellent score avec 97% de F-mesure.

Dans notre évaluation, nous utilisons uniquement les 2 000 premiers avis issus du corpus-test. Ces avis seront vectorisés à l'aide du LLM à tester. Les features du vecteur sont calculées par le LLM puis utilisées pour entraîner un classifieur intégré au logiciel Weka (Hall et al., 2009). Plusieurs classifieurs sont testés. LibLinear (Fan et al., 2008) est celui qui obtient les meilleurs résultats (Cf Annexe). Les entraînements et tests sont réalisés par validation croisée sur 5 plis (apprentissage sur 4/5 du corpus et test sur 1/5).

Les conditions de tests ne sont pas comparables à celles de l'article précédent : réalisé sur beaucoup moins de documents, sans fine-tuning de modèle et effectué sur une machine moins performante : PC Laptop Intel(R) Core(TM) i7-10850H CPU @ 2.70GHz, avec 32,0 Go de RAM. Néanmoins, nous ne cherchons pas à reproduire les conditions du test de l'article, notre objectif est de tester les modèles entre eux.

# 4 Modèles testés

Les caractéristiques des modèles testés sont présentées dans le tableau 1. En voici une présentation plus détaillée :

- BERT multilingue (Devlin et al., 2018) : le premier "grand" modèle à avoir connu beaucoup de succès. Avec ses 100 millions de paramètres "seulement", il semble petit aujourd'hui;

- Llama<fnref n="17" /> : disponible en version 7b, 13b et 40b, Llama puis Llama 2, développé par Facebook/Meta est un des modèles les plus utilisés et les plus performants;

- TinyLlama (Peiyuan Zhang et Lu, 2023) : il s'agit d'un modèle délibérément plus petit (1,1 milliard de paramètres et des embeddings de taille plus petits) qui va être entraîné pendant 90 jours sur 16 cartes graphiques A100;

- Mistral<fnref n="18" /> : le modèle de la société française éponyme qui se revendique comme le meilleur modèle 7b du marché;

- Zephyr : proposé par HuggingFace (Tunstall et al., 2023), avec un nom de vent, comme Mistral, est basé sur le « direct preference optimization » pour DPO, (Rafailov et al., 2023) une technique qui fait de l'ombre au RLHF (Christiano et al., 2017). Zephyr était devenu le modèle 7b le plus performant avant d'être détrôné par NeuralHermes-2.5;

- Open-Hermes 2.5 Mistral : développé par "Nous Research", une société privée spécialisée dans les modèles de langue et de vision basée à New-York;

<footnote n="17">17. https://ai.meta.com/llama/</footnote>

<footnote n="18">18. https://mistral.ai/</footnote>
## Evaluation de petits LLM quantifiés sur une tâche de classification

- Yi : il s'agit d'un modèle développé par la société chinoise Yi, dont le modèle 34b fût, un temps, premier sur le leaderboard d'HuggingFace, devançant le modèle Falcon 180b, un modèle 6 fois plus gros ;

- Neuralhermes-2.5-mistral<fnref n="19" /> : réalisé par le français Maxime Labonne, un modèle qui semble très prometteur, le modèle Mistral, fine-tuné avec DPO.

<table><caption>TAB. 1 – Liste des modèles évalués.</caption><thead><tr><td>Modèle</td><td>Nombre de paramètres</td><td>Taille embeddings</td></tr></thead><tbody><tr><td>BERT multilingue</td><td>100m</td><td>768</td></tr><tr><td>TinyLlama</td><td>1,1b</td><td>2048</td></tr><tr><td>Mistral Instruct</td><td>7b</td><td>4096</td></tr><tr><td>Zephyr</td><td>7b</td><td>4096</td></tr><tr><td>Open-Hermes 2.5 Mistral</td><td>7b</td><td>4096</td></tr><tr><td>Yi</td><td>7b</td><td>4096</td></tr><tr><td>Llama</td><td>7b</td><td>4096</td></tr><tr><td>Neuralhermes-2.5-mistral</td><td>7b</td><td>4096</td></tr></tbody></table>

# 5 Résultats obtenus

<figure><img src="image_20.png" /><figcaption>FIG. 1 – F-Mesure obtenues par les différents modèles.</figcaption></figure>

Les résultats obtenus avec les différents modèles sont présentés sur la figure 1. Plusieurs constats peuvent être tirés :

<footnote n="19">19. https://huggingface.co/mlabonne/NeuralHermes-2.5-Mistral-7B</footnote>
— Les bons résultats obtenus valident l’approche "génération de vecteurs via les LLM, suivie par l’entraînement d’un classifieur", puisque les scores obtenus par tous les LLM sont supérieurs aux résultats obtenus avec Bert;

— Le meilleur modèle est "NeuralHermès 2.5 Mistral" avec une F-Mesure de 93,8%. Seulement 6,15% des 2000 avis sont mal classés, soit 123 erreurs sur 2000 avis;

— Les modèles les plus récents obtiennent les meilleurs résultats.

# 6 Conclusion

Cet article s'est intéressé à l'évaluation de petits modèles LLM 7b quantifiés sur une tâche de classification sur un PC grand public. Pour cette tâche, c'est le modèle "NeuralHermès 2.5 Mistral" qui obtient le meilleur résultat avec une f-mesure de 93,8%. Grâce à la quantification des modèles, ces tests ont pu être réalisés sur un PC grand public, ce qui ouvre des perspectives pour les personnes ou entreprises ne disposant pas d'infrastructures importantes (en terme de serveurs et cartes graphiques).

Le choix avait été fait de comparer entre eux les modèles quantifié en "q4_0" (4bits). Il faudrait tester si les modèles quantifié en "q5_K_M" (d'autres paramètres de quantifications) obtiennent de meilleurs résultats.

D'autres tests comparatifs avec des modèles 13b pourraient être également réalisés.

# Références

Almazrouei, E., H. Alobeidli, A. Alshamsi, A. Cappelli, R. Cojocaru, M. Debbah, E. Goffinet, D. Heslow, J. Launay, Q. Malartic, B. Nouné, B. Pannier, et G. Penedo (2023). Falcon-40B : an open large language model with state-of-the-art performance.

Blard, T. (2020). French sentiment analysis with bert. https://github.com/TheophileBlard/french-sentiment-analysis-with-bert.

Christiano, P. F., J. Leike, T. Brown, M. Martic, S. Legg, et D. Amodei (2017). Deep reinforcement learning from human preferences. *Advances in neural information processing systems 30*.

Devlin, J., M.-W. Chang, K. Lee, et K. Toutanova (2018). Bert : Pre-training of deep bidirectional transformers for language understanding. *arXiv preprint arXiv:1810.04805*.

Fan, R.-E., K.-W. Chang, C.-J. Hsieh, X.-R. Wang, et C.-J. Lin (2008). Liblinear : A library for large linear classification. *the Journal of machine Learning research* 9, 1871–1874.

Guo, Z., R. Jin, C. Liu, Y. Huang, D. Shi, L. Yu, Y. Liu, J. Li, B. Xiong, D. Xiong, et al. (2023). Evaluating large language models : A comprehensive survey. *arXiv preprint arXiv:2310.19736*.

Hall, M., E. Frank, G. Holmes, B. Pfahringer, P. Reutemann, et I. H. Witten (2009). The weka data mining software : an update. *ACM SIGKDD explorations newsletter* 11(1), 10–18.

Peiyuan Zhang, Guangtao Zeng, T. W. et W. Lu (2023). Tinyllama.
Rafailov, R., A. Sharma, E. Mitchell, S. Ermon, C. D. Manning, et C. Finn (2023). Direct preference optimization: Your language model is secretly a reward model. *arXiv preprint arXiv:2305.18290*.

Touvron, H., T. Lavril, G. Izacard, X. Martinet, M.-A. Lachaux, T. Lacroix, B. Rozière, N. Goyal, E. Hambro, F. Azhar, et al. (2023). Llama: Open and efficient foundation language models. *arXiv preprint arXiv:2302.13971*.

Tunstall, L., E. Beeching, N. Lambert, N. Rajani, K. Rasul, Y. Belkada, S. Huang, L. von Werra, C. Fourrier, N. Habib, et al. (2023). Zephyr: Direct distillation of lm alignment. *arXiv preprint arXiv:2310.16944*.

Workshop, B., T. L. Scao, A. Fan, C. Akiki, E. Pavlick, S. Ilić, D. Hesslow, R. Castagné, A. S. Luccioni, F. Yvon, et al. (2022). Bloom: A 176b-parameter open-access multilingual language model. *arXiv preprint arXiv:2211.05100*.

## Annexe : Choix d'un classifieur

Afin d'éviter de tester tous les classifieurs sur tous les LLM, on s'intéresse ici seulement au LLM Mistral_instruct et allons tester les scores obtenus par les différents classifieurs sur ce LLM particulier.

Les documents que l'on souhaite classer (les avis sur des films) sont convertis en vecteurs à l'aide du LLM Mistral_instruct. Chaque avis se trouve ainsi transformé en un vecteur de taille 4096. Les entraînements et tests sont réalisés par validation croisée sur 5 plis (apprentissage sur 4/5 du corpus et test sur 1/5). Les différents classifieurs sont évalués au travers du score de F-Mesure.

Avec une F-Mesure de 0,915, c'est le classifieur LibLinear qui obtient le meilleur score et qui est donc choisi pour évaluer les différents modèles.

<table><caption>TAB. 2 – Liste des classifieurs testés et scores obtenus.</caption><thead><tr><td>Classifieur</td><td>F-Mesure</td></tr></thead><tbody><tr><td>LibLinear</td><td>0,915</td></tr><tr><td>Random Forest</td><td>0,892</td></tr><tr><td>Régression Logistique</td><td>0,848</td></tr><tr><td>kNN (k=10)</td><td>0,854</td></tr><tr><td>J48</td><td>0,785</td></tr><tr><td>SVM</td><td>0,909</td></tr><tr><td>NaïveBayes</td><td>0,843</td></tr><tr><td>LMT</td><td>0,906</td></tr></tbody></table>

## Summary

This article presents an evaluation of several "Large Language Models", quantified (on 4 bits) of size 7 billion carried out on a textual data classification task (AlloCiné reviews). The
texts are first transformed into vectors, using an LLM, and then used to train a classifier. The best result is obtained with the NeuralHermès-2.5-Mistral model.
<figure><img src="image_21.png" /></figure>
# Extraction automatique d'entités spatiales imbriquées et de relations spatiales à partir de texte pour la création de graphes de connaissances : Une approche et deux jeux de données

Helen Mair Rawsthorne*, Nathalie Abadie*,
Eric Kergosien**, Cécile Duchêne***, Éric Saux****

*LASTIG, Univ Gustave Eiffel, IGN-ENSG, 73 avenue de Paris, F-94165 Saint-Mandé, France

**GERiiCO, Université de Lille, F-59000 Villeneuve d'Ascq, France

***LASTIG, Univ Gustave Eiffel, IGN-ENSG, F-77420 Champs-sur-Marne, France

****IRENav, École navale, F-29240 Brest, France

**Résumé.** L'extraction automatique d'informations géographiques à partir de texte est essentielle pour exploiter l'ensemble des connaissances spatiales qui n'existent que sous cette forme non structurée. Les éléments clés sont les entités spatiales, leurs types et les relations spatiales entre elles. Structurées en graphe de connaissances géospatial, les connaissances spatiales ambiguës peuvent être désambiguïsées, ce qui facilite considérablement leur accessibilité et réutilisation. Nous présentons une approche pour l'extraction d'entités spatiales imbriquées et de relations spatiales binaires à partir de texte, un jeu de données annoté en français sur le domaine maritime qui peut être utilisé pour entraîner des algorithmes pour les deux tâches d'extraction, ainsi que des résultats de référence pour les deux tâches effectuées individuellement et de bout en bout. Notre approche applique le *Princeton University Relation Extraction system* (PURE), conçu pour l'extraction d'entités génériques plates et de relations binaires génériques, à l'extraction d'entités spatiales imbriquées et de relations binaires spatiales.

# 1 Introduction

Certaines connaissances spatiales, actuelles ou historiques, n'existent que sous forme de texte. Les guides de voyage, les documents historiques et les publications sur les réseaux sociaux sont quelques exemples de sources de connaissances spatiales non structurées. Les sources textuelles contiennent des connaissances spatiales naturellement hétérogènes : elles peuvent être écrites par différents auteurs, en utilisant un vocabulaire différent, à partir d'un point de vue différent. Elles peuvent par ailleurs couvrir des zones géographiques larges et diverses et contenir des niveaux de détail variés (Ezeani et al., 2023; Jiménez-Badillo et al., 2020; Hu et al., 2019; Kim et al., 2015; Beall, 2010). Pour toutes ces raisons il est difficile d'intégrer dans les modèles de systèmes d'information géographique (SIG) l'information géographique provenant de sources textuelles. L'hypothèse du monde ouvert des technologies du
Web sémantique induit que les graphes de connaissances sont une meilleure solution pour modéliser et stocker les connaissances géographiques extraites de textes hétérogènes, incomplets et parfaits en langage naturel (Janowicz et al., 2022; Chen et al., 2018; Melo et Martins, 2017; Stadler et al., 2012). Structurées en graphe de connaissances géospatial, les connaissances spatiales ambiguës peuvent être désambiguïsées et liées formellement à des ressources géographiques de référence (telles que DBpedia<fnref n="1" /> ou BD TOPO®<fnref n="2" />), ce qui les enrichit de références spatiales directes lorsque c'est possible et facilite considérablement leur accessibilité et réutilisation (Janowicz et al., 2022; Melo et Martins, 2017).

Pendant la population d'un graphe de connaissances, les entités spatiales deviennent des instances de classes ontologiques et les relations spatiales deviennent des propriétés d'objets. Afin de pouvoir attribuer une entité spatiale à sa classe ontologique correspondante, il faut connaître son *type*. Nous faisons l'hypothèse que le nom géographique d'une entité géographique contient souvent un nom commun qui indique son type, tel que *port* dans « *Port de Marseille* ». Bien que cette hypothèse soit valable pour de nombreuses langues romanes, elle ne s'applique pas à toutes les langues.

L'extraction d'entités spatiales *plates* vise à identifier simplement le nom d'une entité spatiale tel que « *Port de Marseille* » sans chercher à le définir plus finement, tandis que l'extraction d'entités spatiales *imbriquées* permet de définir plusieurs niveaux d'étiquettes pour la même section de texte. Nous utilisons les étiquettes introduites par Moncla (2015), dont les définitions sont les suivantes :

- *geographic feature* pour les noms communs qui identifient un *type* d'entité spatiale;

- *name* pour les noms propres pures;

- *geographic name* pour les noms complets associés à une entité spatiale.

Si nous reprenons notre exemple, l'extraction d'entités spatiales imbriquées viserait donc à identifier « *Port de Marseille* » comme *geographic name*, « *Port* » comme *geographic feature* et « *Marseille* » comme *name*. En extrayant des entités spatiales *imbriquées* au lieu de *plates*, le type de *geographic feature* de l'entité est déjà connu et une instance de la classe ontologique correspondante peut être créée automatiquement. Dans certains cas, comme dans notre exemple, le *name* donne une indication de la position géographique de l'entité. Ces deux informations supplémentaires, le type de *geographic feature* de l'entité et son *name*, facilitent la tâche de désambiguïsation qui lie l'instance à son entée correspondante dans une ressource géographique de référence (Southall et al., 2011).

En extrayant les relations spatiales entre entités, des assertions de propriétés d'objets peuvent être automatiquement créées entre instances. Ces informations peuvent également être utilisées pour faciliter la désambiguïsation des entités nommées et non nommées, et augmenter la fiabilité des résultats grâce au raisonnement spatial (Paris et al., 2017). Dans le cas où une entité de référence n'existe pas encore, une nouvelle entrée peut être créée dans la ressource géographique, appuyée par les informations relatives aux classes et aux propriétés de l'instance. Le même raisonnement s'applique à la création et à l'enrichissement de gazetiers : en identifiant spécifiquement les types d'entités pendant le processus d'extraction, les entrées de gazetiers peuvent être automatiquement classées ou dotées d'attributs et ainsi être plus facilement désambiguïsées. L'identification et l'extraction des relations spatiales dans lesquelles les entités

<footnote n="1">1. DBpedia (https://www.dbpedia.org/) est une ressource géographique de référence mondiale.</footnote>

<footnote n="2">2. La BD TOPO® (https://geoservices.ign.fr/bdtopo) est une ressource géographique de référence pour le territoire français.</footnote>
spatiales prennent part contribue à augmenter le niveau de détail dans les descriptions et les
positions géographiques des entrées de gazetiers.

Les textes qui couvrent un environnement international sont susceptibles de contenir des
noms géographiques en langues autre que la langue principale du texte. Il est important que
cela n'empêche pas le processus d'extraction : les noms géographiques et les types d'entités
écrits en autres langues doivent tout de même être identifiés. L'état de l'art en extraction d'in-
formation à partir de texte repose sur des modèles de langage à base de réseaux de neurones
profonds (Nasar et al., 2021). L'état de l'art en matière d'extraction d'informations à partir
de textes repose sur des modèles linguistiques de réseaux neuronaux profonds. Ces modèles
peuvent être entraînés dans une ou plusieurs langues et sont appelés respectivement modèles
de langage pré-entraînés *monolingues* ou *multilingues*. Une ontologie multilingue peut alors
être utilisée pour faciliter la désambiguïsation des entités dont le type est écrit dans d'autres
langues (Stadler et al., 2012).

Dans cet article nous présentons une approche pour l'extraction automatique d'entités im-
briquées et de relations binaires de texte, qui peut être appliquée aux entités et aux relations
spatiales si nécessaire (Rawsthorne et al., 2023). Notre approche est une adaptation du *Prin-
ceton University Relation Extraction system* (PURE) existant (Zhong et Chen, 2021), qui a
été conçu pour l'extraction d'entités génériques plates et de relations binaires génériques. Elle
s'insère dans la méthodologie *ATlantis Ontology and kKnowedge base development from Texts
and Experts* (ATONTE) pour la construction semi-automatique de graphes de connaissances,
géospatiaux ou non, à partir de sources textuelles hétérogènes, des connaissances d'experts et
des données de référence (Rawsthorne, 2024). Notre approche d'extraction peut être appliquée
à des corpus dans n'importe quelle langue (à condition qu'ils contiennent des noms d'entités
imbriqués) couvrant n'importe quel domaine, qu'il soit scientifique ou littéraire, historique ou
contemporain, de fiction ou non.

Cet article est une version raccourcie et traduite d'un article en anglais par Rawsthorne
et al. (2023). Ce dernier contient notamment une présentation complète de l'état de l'art de
l'extraction d'entités et de relations à partir de texte en utilisant des approches en apprentissage
profond.

## 2 Contexte d'application

Les travaux présentés dans cet article ont été réalisés dans le cadre d'un projet qui vise
à structurer en graphe de connaissances géospatial les informations géographiques contenues
dans les *Instructions nautiques* (Rawsthorne, 2024). Les *Instructions nautiques* sont une série
d'ouvrages PDF rédigés en français qui sont produites et publiées par le Service hydrogra-
phique et océanographique de la Marine (Shom). Elles décrivent l'environnement maritime
côtier et donnent des instructions de navigation côtière.

Les *Instructions nautiques* font partie d'une gamme de produits diffusés par le Shom qui
servent à la planification d'itinéraires de navigation maritime. D'autres ouvrages du Shom, plus
spécialisés, viennent compléter les connaissances sur l'environnement côtier et la navigation,
parmi lesquels on trouve *Feux et signaux de brume, Radiosignaux, Courants de marée* ainsi que
l'*Annuaire des marées*. Ils apportent des renseignements qui sont nécessaires à la préparation
d'un itinéraire adapté et sûr. Le type de navire, l'expérience du navigateur, la temporalité<fnref n="3" />, les conditions météorologiques et les conditions océanographiques sont également à prendre en considération lors de la planification. Les Instructions nautiques contiennent principalement trois types de renseignements (Shom, 2020) :

1. elles donnent des informations complémentaires à celles qui sont affichées sur les cartes marines comme les caractéristiques physiques (couleur, forme, taille, etc.) d'un amer 4 ;

2. elles recensent les informations absentes des cartes marines telles que le climat typique de la zone décrite;

3. elles donnent des instructions ou des informations à propos de la navigation telles que les routes conseillées, les conditions d'accès aux ports ou encore les réglementations en place.

Les Instructions nautiques sont divisées en plusieurs volumes, un par zone de couverture. Une zone de couverture peut être définie soit comme une section de trait de côte entre deux positions sur la côte, soit comme l'ensemble du trait de côte d'une île ou d'un ensemble d'îles. Chaque volume commence avec un chapitre de renseignements généraux. Le plan général du reste de l'ouvrage suit linéairement le trait de côte, chaque chapitre étant dédié à une section du trait de côte. En lisant un chapitre, le lecteur a l'impression d'être emmené le long de la côte par le rédacteur; chaque repère, danger et autre particularité de l'environnement est décrit, et chaque mouillage, accès de port et entrée de chenal est détaillé. Les consignes mentionnent également les spécificités de la météorologie, la courantologie et la réglementation locales. Des photographies montrant les amers et les ports notables sont intercalées dans le texte. Elles illustrent également le positionnement relatif des différentes entités géographiques et doivent conforter le lecteur dans la représentation qu'il se fait de son environnement.

## 3 Plan de l'article et disponibilité des données

Dans la section 4 nous présentons le jeu de données coAsTaL mAritime NavigaTion InstructionS (ATLANTIS)<fnref n="5" />, un nouveau jeu de données de référence en langue française, annoté manuellement, qui porte sur le domaine maritime (Rawsthorne et al., 2023). Il peut être utilisé pour entraîner des algorithmes pour l'extraction d'entités spatiales imbriquées et de relations spatiales binaires à partir de texte. Nous présentons également dans la section 4 le jeu de données TextMine'24⁶, qui est un sous-ensemble du jeu de données ATLANTIS et contient des annotations d'entités spatiales imbriquées (Rawsthorne et al., 2024).

Dans la section 5 nous présentons une approche pour l'extraction d'entités spatiales imbriquées et de relations spatiales binaires à partir de texte. Notre approche est une adaptation de PURE (Zhong et Chen, 2021), qui gère uniquement l'extraction d'entités plates génériques et de relations génériques. Nous la rendons applicable à l'extraction d'entités spatiales et imbriquées, et de relations spatiales en utilisant le code mis à disposition par Zhong et Chen (2021) ainsi qu'un format d'annotation modifié.

<footnote n="3">3. Une temporalité est une condition locale qui est dépendante sur le temps, par exemple l'heure, le mois de l'année ou le saison.</footnote>

<footnote n="4">4. Un amer est un « objet remarquable situé à un endroit fixe sur la terre et pouvant être utilisé pour déterminer un emplacement ou une direction. » Traduit du Hydrographic Dictionary Working Group (2019).</footnote>

<footnote n="5">5. https://github.com/umrlastig/atlantis-dataset</footnote>

<footnote n="6">6. https://www.kaggle.com/competitions/defi-textmine-2024</footnote>
Nous présentons dans la section 6 des résultats de référence pour le jeu de données ATLANTIS, obtenus grâce à l'approche décrite dans la section 5, pour les tâches d'extraction d'entités spatiales imbriquées, d'extraction de relations spatiales binaires, et d'extraction combinée d'entités et de relations spatiales de bout en bout. Les entités et relations spatiales extraites de notre corpus pourraient directement enrichir des ressources géographiques de référence ou des gazetiers, qui pourraient être utilisés pour des applications dans des domaines tels que l'hydrographie, la navigation maritime ou les humanités.

Enfin, dans la section 7 nous présentons les conclusions de ce travail et nous donnons
quelques perspectives.

4 Préparation des jeux de données

4.1 Le jeu de données ATLANTIS

Le le jeu de données ATLANTIS est composé d'extraits de chacun des 15 volumes des
*Instructions nautiques* dont nous disposions. Nous avons extrait le texte des PDF en utilisant
*pdfminer.six*<fnref n="7" />. Le jeu de données contient 101 400 jetons.

Nous avons annoté notre jeu de données à la main en utilisant le *brat rapid annotation tool*<fnref n="8" />. Il permet la création d'annotations d'étiquettes imbriquées ainsi que la création de liens entre elles, avec un sens et une étiquette propre à chaque lien (Stenetorp et al., 2012). Le schéma d'annotation, décrit ci-dessous, a été conçu et validé par l'ensemble des auteur·e·s. Une auteure a réalisé l'annotation du jeu de données et ensuite des extraits ont été vérifiés et validés par tout·e·s les auteur·e·s.

Étant donné que nous souhaitions réaliser l'extraction d'entités spatiales *imbriquées* afin de capturer simultanément le nom complet de l'entité spatiale ainsi que son type et son nom, nous avons mis en œuvre une approche d'étiquetage imbriqué en utilisant les étiquettes définies dans la section 1. Tout jeton peut être annoté de zéro ou d'une étiquette *geographic feature* ou *name*. Un jeton ne peut pas être annoté à la fois par une étiquette *geographic feature* et par une étiquette *name*. Un jeton ne peut pas être annoté uniquement avec une étiquette *name*. Un jeton annoté avec une étiquette *name* doit également être annoté une ou plusieurs fois avec une étiquette *geographic name*. Tout jeton, déjà étiqueté ou non, peut être annoté zéro ou plusieurs fois avec une étiquette *geographic name*.

Un très grand nombre de types différents de relations spatiales sont utilisés dans notre
corpus. Nous avons donc décidé de nous limiter à l'extraction de ceux qui seraient les plus
utiles au cours du processus de désambiguïsation.

Les directions cardinales sont très utilisées dans la navigation parce que les relations spa-
tiales qui les utilisent sont construites en utilisant un cadre de référence absolu, ce qui signifie
qu'il n'est pas nécessaire de préciser un point de vue spécifique (Levinson, 1996). Nous avons
choisi d'extraire les relations spatiales qui utilisent les directions cardinales en raison de leur
utilisation fréquente et de leur absence d'ambiguïté. Cela représente 16 types de relations au
total : quatre qui utilisent les directions cardinales (N, E, S, W), quatre qui utilisent les di-
rections intercardinales (NE, SE, SW, NW) et huit qui utilisent les directions intercardinales

<footnote n="7">7. https://github.com/pdfminer/pdfminer.six</footnote>

<footnote n="8">8. http://brat.nlplab.org</footnote>
secondaires (NNE, ENE, ESE, SSE, SSW, WSW, WNW, NNW). Dans notre corpus, ces relations spatiales sont toujours désignées par ces 16 abréviations à une, deux ou trois lettres, par exemple « le port est au NW de la ville » ou « la tour est à l'ESE du château ». Les 16 étiquettes qui correspondent à ces relations spatiales sont au format « est au XYZ de », ou « XYZ » est une des 16 abréviations des directions cardinales.

Nous avons identifié trois autres types de relations spatiales permettant de capturer plus d'informations sur les entités spatiales spécifiques à notre domaine qui ne sont souvent pas nommées dans le corpus ou qui sont susceptibles d'être absentes des ressources géographiques de référence telles que les marques de navigation (bouées, balises, etc.), les rochers ou encore les bancs de sable. Tout d'abord, l'étiquette « *is off the coast of* » est utilisée lorsqu'il est indiqué qu'une entité spatiale est située au large ou dans les eaux côtières d'une autre. Elle est donc fréquemment utilisée pour localiser des entités spatiales isolées. Ce type de relation spatiale, qui est également construit à partir d'un cadre de référence absolu, est toujours désigné par la même expression dans notre corpus : « est au large de ». Deuxièmement, l'étiquette « *is marked by* » est utilisée pour toute entité spatiale qui est marquée ou signalée par une autre entité délibérément placée, souvent une marque de navigation, soit lorsque la première représente un danger pour la navigation, soit lorsqu'elle permet un passage en toute sécurité : « Son musoir est marqué par un feu. » (Shom, 2021). Cette relation indique une proximité entre les deux entités et est exprimée de différentes manières dans notre corpus : « est marqué par » peut être exprimé alternativement par « est signalé par » ou « est indiqué par ». Troisièmement, l'étiquette « *is an element of* » indique une relation topologique qui inclut des entités situées *dans* ou *sur* d'une autre de manière à ce qu'une vue à vol d'oiseau montre l'empreinte spatiale de l'une comme étant à l'intérieur ou en partie à l'intérieur de l'autre. Cette relation est exprimée de différentes manières dans notre corpus, y compris de manière implicite, et inclut rarement le mot « élément ». Par exemple, « l'île porte un phare », « le feu est établi sur le quai » et « les hauts-fonds de la baie » indiquent tous une relation de type « *is an element of* ».

Toutes les annotations de relations doivent relier deux annotations d'entités, soit des étiquettes *geographic feature*, soit des étiquettes *geographic name*. Toutes les annotations de relation doivent avoir une direction. Au lieu de duppliquer les étiquettes de relation pour tenir compte de leurs inverses et de créer des annotations de relations orientées qui vont toujours dans le sens du texte (« *A → is marked by → B* » et « *C → marks → D* »), nous avons créé une version pour chaque étiquette et nous autorisons les annotations de relations orientées qui vont dans l'une ou l'autre direction (« *A → is marked by → B* » et « *C ← is marked by ← D* »).

La figure 1 montre une phrase des *Instructions nautiques* annotée selon notre schéma d'annotation d'entités spatiales imbriquées et de relations spatiales binaires. L'association de l'étiquette spécifique du *geographic feature* « ras » (« cap ») au sein du *geographic name* et des valeurs d'étiquettes multilingues dans une ontologie signifie que cette entité spatiale pourrait être automatiquement instanciée dans la bonne classe, quelle que soit la langue dans laquelle la *geographic feature* est écrite (dans ce cas l'arabe romanisé). La figure 2 montre des triplets *Resource Description Framework* (RDF) qui pourraient être automatiquement construits à partir de cette phrase selon l'ontologie ATLANTIS (Rawsthorne et al., 2022).

Nous avons divisé notre jeu de données annoté en trois parties : entraînement, développement et test, en veillant à respecter un rapport de 80 : 10 : 10 entre le nombre total de jetons et le nombre d'étiquettes d'entités. Nous avons également cherché à ce que du texte couvrant chaque zone géographique soit présent dans les trois parties. Notre jeu de données de 101 400
<figure><img src="image_22.png" /></figure>

<figure><img src="image_23.png" /><figcaption>FIG. 1 – Une phrase des Instructions nautiques annotée selon notre schéma d'annotation d'entités spatiales imbriquées et de relations spatiales binaires (Shom, 2021).</figcaption></figure>

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

@prefix ent: <http://data.shom.fr/id/spatialentity/> .

@prefix atln: <http://data.shom.fr/def/atlantis#> .

ent:0001 rdf:type atln:FishingPort ; # entit num ro 1 est un port de p che
atln:isENEof ent:0002 . # entit num ro 1 est ENE d'entit num ro 2

ent:0002 rdf:type atln:Cape ; # entit num ro 2 est un cap
rdfs:label "Ras Magroua" . # entit num ro 2 s'appelle Ras Magroua

<caption>FIG. 2 – Triplets RDF construits à partir de l'information annotée dans la figure 1 selon l'ontologie ATLANTIS (Rawsthorne et al., 2022).</caption>

jetons contient 16 777 étiquettes d'entités (qui peuvent s'étendre sur plusieurs jetons) et 3 051 étiquettes de relations (qui relient exactement deux étiquettes d'entités dans un sens donné). Au total, 18 030 jetons sont annotés avec au moins une étiquette d'entité, ce qui correspond à près d'un jeton sur cinq. La composition du jeu de données et affiché dans le tableau 1. La distribution des étiquettes peut être consulté sur le dépôt de notre jeu de données<fnref n="9" />.

<table><caption>TAB. 1 – Nombre de jetons et d'étiquettes dans chaque partie du jeu de données ATLANTIS. Une étiquette d'entité peut s'étendre sur un jeton ou plus.</caption><thead><tr><th></th><th>Entraînement</th><th>Développement</th><th>Test</th><th>Total</th></tr></thead><tbody><tr><td>Jetons</td><td>83 851</td><td>8 156</td><td>9 393</td><td>101 400</td></tr><tr><td>Jetons sans étiquette</td><td>69 200</td><td>6 507</td><td>7 663</td><td>83 370</td></tr><tr><td>Jetons avec étiquette d'entité</td><td>14 651</td><td>1 649</td><td>1 730</td><td>18 030</td></tr><tr><td>Étiquettes d'entité</td><td>13 582</td><td>1 476</td><td>1 719</td><td>16 777</td></tr><tr><td>Étiquettes de relation</td><td>2 507</td><td>222</td><td>322</td><td>3 051</td></tr></tbody></table>

Nous avons converti notre jeu de données du format *brat* au format *JSON Lines* (JSONL)<fnref n="10" /> requis pour PURE à l'aide d'un script Python<fnref n="11" />. La figure 3 montre la même phrase annotée que dans la figure 1 convertie en valeur JSON dans ce format. Dans notre cas, chaque valeur

<footnote n="9">9. https://github.com/umrlastig/atlantis-dataset</footnote>

<footnote n="10">10. Un fichier JSONL contient une valeur JSON valide sur chaque ligne.</footnote>

<footnote n="11">11. https://github.com/dwadden/dygiepp/blob/master/scripts/new-dataset/brat_to_input.py</footnote>
Extraction automatique d'entités et de relations spatiales à partir de texte

JSON correspond à un paragraphe des Instructions nautiques et contient une liste de phrases (dont chacune est une liste de jetons), une liste des annotations d'entités (les numéros des deux jetons frontaliers + l'étiquette), et une liste des annotations de relations (les numéros des deux fois deux jetons frontaliers + l'étiquette). Ce format d'annotation imbriquée, qui permet à tout jeton d'être annoté avec zéro ou plusieurs étiquettes, rend possible l'extraction d'entités imbriquées sans utiliser du joint labelling (Rawsthorne et al., 2023; Agrawal et al., 2022).

<figure><img src="image_24.png" /><figcaption>FIG. 3 – Une ligne d'un fichier JSONL formaté pour PURE. Elle contient le texte et les annotations illustrés dans la figure 1.</figcaption></figure>

## 4.2 Le jeu de données TextMine’24

Le jeu de données TextMine’24 est un sous-ensemble du jeu de données ATLANTIS. Il est composé de 66 030 jetons au total, et possède la même couverture géographique mondiale que le jeu de données ATLANTIS. Le jeu de données TextMine’24 contient uniquement des annotations d'entités spatiales, et ce dans la limite de deux niveaux d'imbrication. Il a été utilisé en tant que jeu de données de référence pour le Défi TextMine 2024¹², un défi de reconnaissance d'entités spatiales organisé en collaboration avec le groupe de travail TextMine<fnref n="13" />. Une description complète du jeu de données TextMine’24 et le défi associé se trouve dans l'article par Rawsthorne et al. (2024).

# 5 Entraînement des modèles

PURE (Zhong et Chen, 2021) entraîne indépendamment deux encodeurs de base à partir de modèles de langage profonds pré-entraînés existants : l'un pour identifier et étiqueter les entités, et l'autre pour identifier les paires reliées d'entités et classer la relation entre elles. Nous appelons le premier modèle le *modèle entité* et le second le *modèle relation*. PURE permet également de réguler la taille de la fenêtre contextuelle *W*, c'est-à-dire la quantité de contexte inter-phrases qui est mise à la disposition du modèle. Le contexte disponible lors du traitement d'une phrase donnée s'étend de $(W-n)/2$ mots à gauche de la phrase à $(W-n)/2$ mots à droite, où *n* est le nombre de mots dans la phrase. Une perte d'entropie croisée est utilisée pour les deux modèles.

<footnote n="12">12. https://www.kaggle.com/competitions/defi-textmine-2024</footnote>

<footnote n="13">13. https://textmine.sciencesconf.org/</footnote>
Pour les encodeurs de base, nous avons utilisé *bert-base-french-europeana-cased* comme modèle *Bidirectional Encoder Representations from Transformers (BERT)* monolingue français et *bert-base-multilingual-cased* comme modèle BERT multilingue. Nous avons utilisé les hyperparamètres par défaut fournis par (Zhong et Chen, 2021) et nous avons fait des expériences avec plusieurs tailles de fenêtres contextuelles, dans les plages des valeurs par défaut, pour le modèle entité et le modèle relation. Pour le modèle entité, nous avons utilisé des fenêtres contextuelles de 0, 50, 100, 150, 200 et 248 ($W = 250$ a dépassé le mémoire GPU disponible) et pour le modèle relation, nous avons utilisé des fenêtres contextuelles de 0, 50 et 100. Nous n'avons apporté aucune autre modification au code publié par Zhong et Chen (2021). Nous avons entraîné et évalué les deux encodeurs de base BERT pour l'extraction d'entités spatiales imbriquées grâce à notre format d'annotation imbriquée, puis nous avons entraîné et évalué séparément les deux mêmes encodeurs de base pour l'extraction de relations spatiales. Pendant l'entraînement, les modèles ont eu accès aux annotations manuelles (gold) des entités. Nous avons effectué deux évaluations différentes sur les modèles de relations : l'une avec les annotations d'entités manuelles et l'autre avec les entités prédites. Les relations prédites à partir des annotations d'entités manuelles donnent uniquement une évaluation du processus d'extraction de relations. Les relations prédites à partir des entités prédites donnent une évaluation du processus d'extraction d'entités et de relations de bout en bout. Pour chaque configuration, nous avons entraîné et évalué cinq modèles individuels en utilisant différentes valeurs de graines aléatoires et nous avons calculé la moyenne arithmétique et l'écart-type des scores F1 micro obtenus.

# 6 Résultats et analyse

Les scores F1 pour les trois tâches avec différentes tailles de fenêtres contextuelles sont affichés dans le tableau 2. La précision globale, le rappel et les scores F1 par étiquette peut être consulté sur le dépôt de notre jeu de données<fnref n="14" />.

Pour l'extraction d'entités, nos expériences montrent que la mise à disposition du contexte inter-phrases pendant l'entraînement et la prédiction améliore les scores F1 micro pour les deux modèles, et que le modèle multilingue BERT surpasse légèrement le modèle monolingue français BERT pour toutes les tailles de fenêtre contextuelle, avec son score F1 micro moyen le plus élevé étant de 92,3 lorsque $W = 200$ (tableau 2). Nous attribuons ce contraste dans les résultats par rapport à ceux de la littérature (Rawsthorne et al., 2023) à une caractéristique de notre jeu de données : bien que la langue principale du texte soit le français, il contient des mots provenant d'un grand nombre d'autres langues. Les mots en question sont principalement des *geographic feature* qui font partie de *geographic name*, ce qui signifie qu'ils doivent être identifiés et correctement étiquetés par le modèle entité. Dans ces cas, le modèle monolingue perd son avantage par rapport au modèle multilingue, car ce dernier est capable de comprendre le sens sémantique d'une plus grande proportion des mots de l'ensemble de données.

<footnote n="14">14. https://github.com/umrlastig/atlantis-dataset</footnote>
Extraction automatique d'entités et de relations spatiales à partir de texte

<table><caption>TAB. 2 – Score F1 micro moyen avec écart-type sur cinq exécutions pour différentes tailles de fenêtres contextuelles pour : l'extraction d'entités, l'extraction de relations à partir d'annotations manuelles (gold) d'entités, et l'extraction d'entités et de relations de bout en bout [e2e] à partir des meilleures annotations d'entités prédites (W = 248 pour le modèle monolingue et W = 200 pour le modèle multilingue). Pour chaque tâche, le score F1 le plus élevé parmi toutes les tailles de fenêtres contextuelles pour chaque encodeur de base est en **gras**, et le score F1 global le plus élevé parmi toutes les tailles de fenêtres contextuelles et les deux encodeurs de base est **souligné**.</caption><thead><tr><th rowspan="2">W</th><th colspan="2">Entités</th><th colspan="2">Relations</th><th colspan="2">Relations (de bout en bout)</th></tr><tr><th>Mono.</th><th>Multi.</th><th>Mono.</th><th>Multi.</th><th>Mono.</th><th>Multi.</th></tr></thead><tbody><tr><td>0</td><td>91.1 ± 0.3</td><td>91.9 ± 0.2</td><td><strong>64.2</strong> ± 2.2</td><td><strong>63.2</strong> ± 1.0</td><td><strong>63.9</strong> ± 2.2</td><td><strong>63.2</strong> ± 1.2</td></tr><tr><td>50</td><td>92.1 ± 0.2</td><td>92.3 ± 0.3</td><td>64.2 ± 1.4</td><td>63.0 ± 1.7</td><td>63.8 ± 1.4</td><td>63.1 ± 1.7</td></tr><tr><td>100</td><td>91.9 ± 0.2</td><td>92.3 ± 0.2</td><td>63.7 ± 0.7</td><td>62.9 ± 0.7</td><td>63.6 ± 0.7</td><td>62.9 ± 0.8</td></tr><tr><td>150</td><td>91.9 ± 0.2</td><td>92.2 ± 0.2</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>200</td><td>92.0 ± 0.2</td><td><strong>92.3</strong> ± 0.2</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>248</td><td><strong>92.2</strong> ± 0.2</td><td>92.3 ± 0.2</td><td>-</td><td>-</td><td>-</td><td>-</td></tr></tbody></table>

# 7 Conclusion et perspectives

Nous avons discuté et souligné l'importance d'une extraction fiable d'entités spatiales imbriquées et de relations spatiales pour la construction de graphes de connaissances géospatiales ou de gazetiers à partir de textes et pour la désambiguïsation d'entités spatiales. Nous avons présenté un nouveau jeu de données annoté en langue française pour ces deux tâches d'extraction, spécifique au domaine maritime. Nous avons fourni des résultats de référence pour notre propre jeu de données et avons ainsi démontré que PURE (Zhong et Chen, 2021), une approche existante pour l'extraction générique d'entités et de relations binaires à partir de textes, peut être utilisée pour extraire des entités imbriquées. Ceci a été réalisé en entraînant un encodeur BERT avec des annotations imbriquées, sans utiliser du joint labelling. Nous avons également montré que PURE est une approche de base adaptée à l'extraction d'entités spatiales et de relations spatiales spécifiques à un domaine. Nos résultats révèlent que le modèle multilingue BERT est légèrement plus performant que le modèle monolingue français BERT pour l'extraction d'entités, avec un score F1 micro moyen de 92,3, tandis que pour l'extraction de relations et l'extraction d'entités et de relations de bout en bout, le modèle monolingue français BERT est légèrement plus performant, avec des scores F1 micro moyens de 64,2 et 63,9 respectivement. Nos résultats montrent que la mise à disposition d'informations contextuelles inter-phrases lors de l'entraînement et de la prédiction favorise l'extraction d'entités mais entrave l'extraction de relations.

Une première perspective concerne la réduction du temps nécessaire pour annoter le jeu de données d'entraînement. Pour ce faire, on pourrait utiliser un outil d'annotation qui propose soit un étiquetage assisté par apprentissage machine, soit une annotation automatisée en fonction d'un ensemble de mots clés défini par l'utilisateur. Il faudrait évaluer et comparer les annotations produites à l'aide des différents outils afin de vérifier que la qualité ne diminue pas par rapport aux annotations que nous avons réalisées de manière entièrement manuelle. Dans le
but d'augmenter la fiabilité du jeu de données annoté, on pourrait adopter une approche d'ан-
notation à plusieurs et calculer l'accord inter-annotateurs. On pourrait aussi produire automa-
tiquement des données synthétiques sous la forme d'un texte annoté par le biais d'expressions
régulières. Il serait également possible de combiner un apprentissage non supervisé avec un
apprentissage supervisé en utilisant un plus petit jeu de données annoté manuellement lors de
l'étape d'extraction. Si les résultats sont identiques ou meilleurs que ceux obtenus avec notre
approche actuelle, l'apprentissage non supervisé pourrait être intégré à notre méthodologie et
le volume de données annotées manuellement nécessaire pourrait être réduit. Une autre pers-
pective concerne l'élargissement de l'approche d'extraction d'information à partir de texte afin
de permettre la prise en compte de plusieurs types d'entités simultanément et la gestion de re-
lations n-aires (ternaires ou plus). Ceci permettrait d'extraire des relations impliquant plus de
deux entités telles que la relation spatiale entre, comme par exemple dans la phrase « la bouée
est entre l'île Est et l'île Ouest ».

Références

Agrawal, A., S. Tripathi, M. Vardhan, V. Sihag, G. Choudhary, et N. Dragoni (2022). BERT-
Based Transfer-Learning Approach for Nested Named-Entity Recognition Using Joint La-
beling. *Applied Sciences* 12(3), 976.

Beall, J. (2010). Geographical research and the problem of variant place names in digitized books and other full-text resources. *Library Collections, Acquisitions, & Technical Services* 34(2-3), 74–82.

Chen, H., M. Vasardani, S. Winter, et M. Tomko (2018). A Graph Database Model for Know-
ledge Extracted from Place Descriptions. *International Journal of Geo-Information* 7(6),
221.

Ezeani, I., P. Rayson, et I. Gregory (2023). Extracting Imprecise Geographical and Temporal References from Journey Narratives. In *Proceedings of Text2Story — Sixth Workshop on Narrative Extraction From Texts*, Volume 3370, Dublin, Ireland. CEUR Workshop Proceedings.

Hu, Y., C. Deng, et Z. Zhou (2019). A Semantic and Sentiment Analysis on Online Neighbo-
rhood Reviews for Understanding the Perceptions of People toward Their Living Environ-
ments. *Annals of the American Association of Geographers* 109(4), 1052–1073.

Hydrographic Dictionary Working Group (2019). S-32 IHO Hydrographic Dictionary.

Janowicz, K., P. Hitzler, W. Li, D. Rehberger, M. Schildhauer, R. Zhu, C. Shimizu, C. K. Fisher, L. Cai, G. Mai, J. Zalewski, L. Zhou, S. Stephen, S. Gonzalez, B. Mecum, A. Lopez-Carr, A. Schroeder, D. Smith, D. Wright, S. Wang, Y. Tian, Z. Liu, M. Shi, A. D'Onofrio, Z. Gu, et K. Currier (2022). Know, Know Where, KnowWhereGraph : A densely connected, cross-domain knowledge graph and geo-enrichment service stack for applications in environmental intelligence. *AI Magazine* 43(1), 30–39.

Jiménez-Badillo, D., P. Murrieta-Flores, B. Martins, I. Gregory, M. Favila-Vázquez, et
R. Liceras-Garrido (2020). Developing Geographically Oriented NLP Approaches to Six-
teenth-Century Historical Documents : Digging into Early Colonial Mexico. *Digital Hu-
manities Quarterly* 14(4).
Kim, J., M. Vasardani, et S. Winter (2015). Harvesting large corpora for generating place graphs. Volume 12, Santa Fe, NM, USA.

Levinson, S. C. (1996). Language and Space. *Annual Review of Anthropology* 25, 353–382.

Melo, F. et B. Martins (2017). Automated Geocoding of Textual Documents : A Survey of Current Approaches. *Transactions in GIS* 21(1), 3–38.

Moncla, L. (2015). *Automatic reconstruction of itineraries from descriptive texts*. PhD, Université de Pau et des Pays de l'Adour, Pau, France.

Nasar, Z., S. W. Jaffry, et M. K. Malik (2021). Named Entity Recognition and Relation Extraction : State-of-the-Art. *ACM Computing Surveys* 54(1), 20 :1–20 :39.

Paris, P.-H., N. Abadie, et C. Brando (2017). Linking Spatial Named Entities to the Web of Data for Geographical Analysis of Historical Texts. *Journal of Map & Geography Libraries* 13(1), 82–110.

Rawsthorne, H. M. (2024). *Creation of Geospatial Knowledge Graphs From Heterogeneous Sources*. PhD, Université Gustave Eiffel, Champs-sur-Marne, France.

Rawsthorne, H. M., N. Abadie, A. Guille, P. Cuxac, et C. Lopez (2024). Défi TextMine'24 : Reconnaissance d'entités géographiques dans un corpus des Instructions nautiques. In *Actes de l'atelier TextMine'24*, Dijon, France.

Rawsthorne, H. M., N. Abadie, E. Kergosien, C. Duchêne, et Saux (2022). ATLANTIS : Une ontologie pour représenter les Instructions nautiques. In *Journées Francophones d'Ingénierie des Connaissances (IC) Plate-Forme Intelligence Artificielle (PFIA 2022)*, Saint-Étienne, France, pp. 154–163.

Rawsthorne, H. M., N. Abadie, E. Kergosien, C. Duchêne, et Saux (2023). Automatic Nested Spatial Entity and Spatial Relation Extraction From Text for Knowledge Graph Creation : A Baseline Approach and a Benchmark Dataset. In *7th ACM SIGSPATIAL International Workshop on Geospatial Humanities (GeoHumanities '23)*, November 13, 2023, Hamburg, Germany, Hamburg, Germany. Association for Computing Machinery.

Shom (2020). Guide de rédaction des Instructions Nautiques du Shom. Procédure spécifique, Shom.

Shom (2021). *Instructions nautiques. D6 : Mer Méditerranée, côtes d'Afrique et du Levant [Version à jour au 13 octobre 2021]*. Brest, France.

Southall, H., R. Mostern, et M. L. Berman (2011). On historical gazetteers. *International Journal of Humanities and Arts Computing* 5(2), 127–145.

Stadler, C., J. Lehmann, K. Höffner, et S. Auer (2012). LinkedGeoData : A core for a web of spatial open data. *Semantic Web* 3(4), 333–354.

Stenetorp, P., S. Pyysalo, G. Topić, T. Ohta, S. Ananiadou, et J. Tsujii (2012). brat : a Web-based Tool for NLP-Assisted Text Annotation. In *Proceedings of the Demonstrations at the 13th Conference of the European Chapter of the Association for Computational Linguistics*, Avignon, France, pp. 102–107. Association for Computational Linguistics.

Zhong, Z. et D. Chen (2021). A Frustratingly Easy Approach for Entity and Relation Extraction. In *Proceedings of the 2021 Conference of the North American Chapter of the Association for Computational Linguistics : Human Language Technologies*, Online, pp. 50–61. Association for Computational Linguistics.
Summary

Automatically extracting geographic information from text is the key to harnessing the
vast amount of spatial knowledge that only exists in this unstructured form. The fundamental
elements of spatial knowledge include spatial entities, their types and the spatial relations be-
tween them. Structuring the spatial knowledge contained within text as a geospatial knowledge
graph, and disambiguating the spatial entities, significantly facilitates its reuse. We present a
baseline approach for nested spatial entity and binary spatial relation extraction from text, a
new annotated French-language benchmark dataset on the maritime domain that can be used
to train algorithms for both extraction tasks, and benchmark results for the two tasks carried
out individually and end-to-end. Our approach involves applying the Princeton University Re-
lation Extraction system (PURE), made for flat, generic entity extraction and generic binary
relation extraction, to the extraction of nested, spatial entities and spatial binary relations.
<figure><img src="image_25.png" /></figure>
# Défi TextMine'24 : Reconnaissance d'entités géographiques dans un corpus des Instructions nautiques

Helen Mair Rawsthorne*, Nathalie Abadie*,
Adrien Guille**, Pascal Cuxac***, Cédric Lopez ****

* LASTIG, Univ Gustave Eiffel, IGN-ENSG, 73 avenue de Paris, F-94165 Saint-Mandé, France

**Université de Lyon, Lyon 2, UR 3083
adrien.guille@univ-lyon2.fr

***INIST-CNRS, UAR76, Nancy, France
pascal.cuxac@inist.fr

****Emvista, Jacou, France
cedric.lopez@emvista.com,

**Résumé.** Pour cette deuxième édition du défi TextMine, l'Institut national de l'information géographique et forestière (IGN) et le Service hydrographique et océanographique de la Marine (Shom) proposent de relever le défi de la reconnaissance d'entités géographiques nommées et non nommées à deux niveaux dans les *Instructions nautiques*, une série d'ouvrages publiée par le Shom. Neuf équipes académiques et industrielles ont participé à ce défi, les résultats de 5 de ces équipes, présentés lors de l'atelier, sont résumés dans cet article.

## 1 Introduction

Le 21 octobre 2022, l'association Extraction et Gestion des Connaissances (EGC) a lancé le groupe de travail TextMine<fnref n="1" />. Dans le cadre de ce groupe de travail, un objectif est de confronter l'état de l'art scientifique aux problèmes de fouille de texte (text mining en anglais) rencontrés par des industriels. Sous la forme de défis, le groupe de travail propose des jeux de données inédits et les partage avec la communauté scientifique. Le premier défi du groupe de travail TextMine a été lancé le 21 octobre 2022 en étroite collaboration avec la société Emvista, éditrice de logiciels fondés sur des technologies du Traitement Automatique du Langage Naturel, qui a fourni une partie des données. Cinq équipes ont partagé leurs expériences lors de l'atelier TextMine'23 qui s'est tenu à Lyon<fnref n="2" />.

Pour cette deuxième édition, l'Institut national de l'information géographique et forestière (IGN) et le Service hydrographique et océanographique de la Marine (Shom) proposent de relever le défi de la reconnaissance d'entités géographiques nommées et non nommées à deux niveaux dans les *Instructions nautiques*, une série d'ouvrages publiée par le Shom. Chaque volume décrit l'environnement maritime côtier d'une zone géographique et donne aux navigateurs les informations nécessaires pour naviguer près des côtes et accéder aux ports en sécu-

<footnote n="1">1. https://textmine.sciencesconf.org/</footnote>

<footnote n="2">2. https://textmine.sciencesconf.org/resource/page/id/4</footnote>
rité. Les zones géographiques couvertes par les *Instructions nautiques* sont réparties autour du monde entier.

Le défi a été lancé le 24 avril 2023 et clôturé le 16 novembre 2023. Neuf équipes académiques et industrielles ont participé, avec un total de 202 soumissions de résultats sur la plateforme Kaggle hébergeant le défi <fnref n="3" />. Ce défi a donné lieu à 7 articles publiés : un article hors compétition de la part de l'instigateur du défi (Rawsthorne et al., 2024), cinq articles de la part des équipes participantes (CIAD, CRIT, OctopusMind/IRISA, Inist-CNRS, CIRAD/INRAE), et un article de synthèse de la part des organisateurs du défi (le présent article). Les articles rédigés par les équipes sont associés au code source qui permet de reproduire les modèles développés.

## 2 Présentation du jeu de données

Ce défi est inspiré par un projet qui vise à structurer en graphe de connaissances géospatial les informations géographiques contenues dans les *Instructions nautiques* (Rawsthorne, 2024). Une partie du corpus utilisé dans ce projet, publié par Rawsthorne et al. (2023), constitue le corpus de ce défi. Ce dernier est constitué d'extraits de 15 volumes des *Instructions nautiques*, annotés selon 3 étiquettes. Il compte au total 66030 jetons et 18537 étiquettes, dont une partie est proposée pour l'apprentissage et l'autre réservée pour le test. Les 3 étiquettes utilisées suivent la proposition de Moncla (2015) pour annoter des entités géographiques imbriquées :

- geogFeat : Pour les noms communs qui identifient une caractéristique géographique.

- Par exemple : "À 8 M à l'ENE du phare de Nadji, le port de pêche de Sidi Abderrahmane (36° 29,7' N — 1° 05,7' E) est construit au bord du village de Soug el Bgar (pointe Rouge)." (Extrait de Shom (2021))

- name : Pour les noms propres purs.

- Par exemple : "À 8 M à l'ENE du phare de Nadji, le port de pêche de Sidi Abderrahmane (36° 29,7' N — 1° 05,7' E) est construit au bord du village de Soug el Bgar (pointe Rouge)."

- geogName : Pour le nom associé à une caractéristique géographique.

- Par exemple : "À 8 M à l'ENE du phare de Nadji, le port de pêche de Sidi Abderrahmane (36° 29,7' N — 1° 05,7' E) est construit au bord du village de Soug el Bgar (pointe Rouge)."

Chaque jeton peut recevoir entre 0 et 2 étiquettes selon les combinaisons indiquées dans la première colonne du tableau 1. Ce tableau donne le nombre d'annotations de chaque étiquette ou combinaison d'étiquettes présentes dans le jeu d'entraînement.

## 3 Expériences

Dans cette section nous synthétisons les expériences réalisées par chaque équipe ayant participé au défi.

- L'équipe CIAD (Armary et al., 2024) a expérimenté deux approches. D'une part, plusieurs modèles ont été affinés : BERT-Base-NER (un modèle BERT entraîne pour la tâche de NER (*Named Entity Recognition*) en anglais), CamemBERT-NER (un modèle BERT français entraîné pour la tâche de NER en français), TinyBERT (un réajustement

<footnote n="3">3. https://www.kaggle.com/competitions/defi-textmine-2024/overview</footnote>
<table><caption>TAB. 1 – Distribution des cinq étiquettes ou combinaisons possibles d’étiquettes dans le jeu d’entraînement, ainsi que le nombre de jetons sans étiquette dans ce dernier.</caption><thead><tr><td>Étiquette(s)</td><td>Nombre d'annotations dans le jeu d'entraînement</td></tr></thead><tbody><tr><td>geogFeat</td><td>4 167</td></tr><tr><td>geogFeat geogName</td><td>1 469</td></tr><tr><td>geogName</td><td>4 490</td></tr><tr><td>name</td><td>2 118</td></tr><tr><td>name geogName</td><td>2 123</td></tr><tr><td>jeton sans étiquette</td><td>32 668</td></tr></tbody></table>

du modèle BERT), et un modèle de NER utilisant GPT2 avec un apprentissage basé sur des invites. D'autre part, une approche basée sur un GCN (Graph Convolutional Network) (Kipf et Welling, 2017) considère que les jetons dans du jeu de données sont des nœuds du graphe et que ces nœuds sont connectés en fonction de leur co-occurrence dans le contexte. Dans cette approche, les étiquettes sont également vues comme des nœuds et un jeton est connecté à son étiquette grâce à la connaissance du jeu d'entraînement. L'approche basée sur le GCN obtient un score d'exactitude faible (77,9%) en comparaison à l'approche Bert-Base-NER qui atteint 92,8%.

— L'équipe CRIT (Gutehrlé, 2024) a utilisé le modèle fr_core_news_lg distribué par spaCy<fnref n="4" /> pour obtenir les parties du discours, les catégories grammaticales et les fonctions syntaxiques des jetons. Trois modèles CRF (Conditional Random Fields) (Laferty et al., 2001) linéaires ont été entraînés dans l'objectif d'identifier quelles caractéristiques (formes, catégories grammaticales, fonctions syntaxiques, etc.) permettraient d'obtenir les meilleurs résultats. Il a été conclu que les performances des modèles diminuent dans le cas où les catégories grammaticales et les fonctions syntaxiques sont considérées comme caractéristiques dans l'entraînement. Le meilleur score F1 obtenu est 96,4%.

— L'équipe OctopusMind/IRISA (Ahmia et al., 2024) a également expérimenté des modèles à base de CRF et de Transformers. Concernant les CRF : onze caractéristiques dont la forme du terme, son lemme, la présence de lettres dans le terme, la présence de ponctuation et les catégories grammaticales ont été utilisées. L'équipe a également utilisé des caractéristiques à longue portée qui modélisent le contexte d'occurrence des termes (les variables voisines d'un terme). L'optimisation des poids du CRF a été réalisée avec la méthode L-BFGS (Limited-memory Broyden-Fletcher-Goldfarb-Shanno) (Zhu et al., 1997). Par ailleurs, le modèle CamemBERT a été utilisé en ajoutant une couche linéaire dense en sortie. Un affinage a été réalisé sur les données TextMine. Contrairement à Gutehrlé (2024), les résultats montrent que le modèle obtient les meilleurs résultats (score F1 de 98%) lorsque toutes les caractéristiques sont prises en compte. L'utilisation de caractéristiques à longue portée améliore le score à condition que des contraintes concernant la portée soient respectées.

— L'équipe Inist-CNRS (Anki et al., 2024) utilise un réseau de neurones récurrents (RNN) en utilisant le framework Flair (Akbik et al., 2019). Un embedding contextuel de dimen-

<footnote n="4">4. https://spacy.io/</footnote>
sion 300 a été utilisé par défaut dans les expériences, contrairement aux expériences précédentes qui utilisent des embeddings de transformers. Le RNN mis en place est constitué de trois couches : une couche de reprojection de l'embedding et deux couches de type LSTM. Les paramètres par défaut de Flair ont été utilisés. Le meilleur score F1 obtenu sur le jeu de test public est de 97,9%.

— L'équipe CIRAD/INRAE (Decoupes et al., 2024) a expérimenté deux approches. La première consiste en un réentrainement d'un modèle en français de la librairie spaCy (fr_core_news_lg), identique à celui utilisé par CRIT. La seconde approche consiste à réajuster des modèles pré-entrainés de type Transformers : deux modèles en langue française (CamemBERT-base et CamemBERT-large) et deux modèles multi-langues (XLM-RoBERTa). CamemBERT-large obtient les meilleurs résultats (sans optimisation des hyperparamètres), soit 97,6%.

## 4 Résultats

Le classement final des équipes a été déterminé selon deux évaluations basées sur un jeu de test. Une partie du jeu de test, nommée le jeu de test "public" et composé de 41% du jeu de test total, couvre la zone géographique présente dans le jeu d'entraînement (la côte Ouest de l'Afrique, la mer Méditerranée, la mer Rouge, Saint-Pierre-et-Miquelon, les Antilles françaises, la France hexagonale et les îles de l'océan Indien). L'autre partie du jeu de test, nommée le jeu de test "privé" et composé de 59% du jeu de test total, couvre une zone géographique ab-sente du jeu d'entraînement et du jeu de test public : les îles de l'océan Pacifique. Les équipes ont pu évaluer leurs modèles sur le jeu de test public tout au long de la compétition. Le jeu de test privé a été utilisé au moment de clôturer le défi pour tester la version définitive du modèle de chaque équipe. Les scores F1 public et privé de chaque équipe qui a participé au défi sont affichés dans le tableau 2. Le score F1 moyen est la moyenne harmonique des scores F1 publics et privés. Le score final *S*, qui a permis d'établir le classement final des équipes, a été calculé de la manière suivante : *S* = *A* + *B*, où *A* est le score F1 moyen et *B* = 5 * *A* / 100 si l'équipe a rendu son code source ouvert, et 0 sinon. Les équipes ayant rendu leur code source ouvert sont indiquées par un astérisque (*) dans le tableau 2.

<table><caption>TAB. 2 – Résultats obtenus par chaque équipe sur les jeux de test public et privé, et les scores finaux qui ont permis d'établir le classement.</caption><thead><tr><th>Rang</th><th>Équipe</th><th>Soumissions</th><th>F1 public</th><th>F1 privé</th><th>F1 moy.</th><th>Score final</th></tr></thead><tbody><tr><td>1</td><td>OctopusMind*</td><td>16</td><td><strong>0,980</strong></td><td><strong>0,979</strong></td><td><strong>0,980</strong></td><td><strong>1,029</strong></td></tr><tr><td>2</td><td>Tetis*</td><td>8</td><td>0,976</td><td>0,978</td><td>0,977</td><td>1,026</td></tr><tr><td>3</td><td>Inist*</td><td>31</td><td>0,979</td><td>0,972</td><td>0,976</td><td>1,024</td></tr><tr><td>4</td><td>CRIT*</td><td>18</td><td>0,964</td><td>0,943</td><td>0,953</td><td>1,001</td></tr><tr><td>5</td><td>Valentin Nyzam</td><td>29</td><td>0,975</td><td>0,974</td><td>0,974</td><td>0,974</td></tr><tr><td>6</td><td>CIAD*</td><td>87</td><td>0,928</td><td>0,913</td><td>0,920</td><td>0,967</td></tr><tr><td>7</td><td>Nicolas Fouqué</td><td>5</td><td>0,954</td><td>0,951</td><td>0,952</td><td>0,952</td></tr><tr><td>8</td><td>Ben & Loïck</td><td>3</td><td>0,915</td><td>0,880</td><td>0,898</td><td>0,898</td></tr><tr><td>9</td><td>Sylvain Verdy</td><td>5</td><td>0,842</td><td>0,834</td><td>0,838</td><td>0,838</td></tr></tbody></table>
Nous invitons les lecteurs à consulter les articles rédigés par les équipes participantes afin d'obtenir plus de détails sur leurs approches et leurs résultats.

Références

Ahmia, O., D. Cao, N. Béchet, et P.-F. Marteau (2024). OctopusMind @ Défi TextMine'24 Re-
connaissance d'entités géographiques dans un corpus d'Instructions nautiques. In *Actes de
l'atelier TextMine'24*. Conférence Extraction et Gestion des Connaissances 2024 (EGC'24),
Dijon, France.

Akbik, A., T. Bergmann, D. Blythe, K. Rasul, S. Schweter, et R. Vollgraf (2019). FLAIR : An easy-to-use framework for state-of-the-art NLP. In W. Ammar, A. Louis, et N. Mostafazadeh (Eds.), *Proceedings of the 2019 Conference of the North American Chapter of the Association for Computational Linguistics (Demonstrations)*, Minneapolis, Minnesota, pp. 54–59. Association for Computational Linguistics.

Anki, L., L. Gaillard, et J. Revol (2024). Détection d'entités nommées géographiques par réseau de neurones récurrents. In *Actes de l'atelier TextMine'24*. Conférence Extraction et Gestion des Connaissances 2024 (EGC'24), Dijon, France.

Armary, P., C.-B. El-Vaigh, O. Labbani Narsis, et C. Nicolle (2024). CIAD System for Geo-
graphical Entity Detection at TextMine'24. In *Actes de l'atelier TextMine'24*. Conférence
Extraction et Gestion des Connaissances 2024 (EGC'24), Dijon, France.

Decoupes, R., R. Interdonato, R. Kafando, M. Roche, S. Mehtab Alam, M. Teisseire, et S. Valentin (2024). TETIS @ Challenge TextMine 2024 : "Reconnaissance d'entités géographiques dans un corpus des Instructions nautiques". In *Actes de l'atelier TextMine'24*. Conférence Extraction et Gestion des Connaissances 2024 (EGC'24), Dijon, France.

Gutehrlé, N. (2024). Défi TextMine 2024 : "Reconnaissance d'entités géographiques dans un corpus des Instructions nautiques" - soumission équipe CRIT. In *Actes de l'atelier TextMine'24*. Conférence Extraction et Gestion des Connaissances 2024 (EGC'24), Dijon, France.

Kipf, T. N. et M. Welling (2017). Semi-supervised classification with graph convolutional
networks. In *5th International Conference on Learning Representations, ICLR 2017, Toulon,
France, April 24-26, 2017, Conference Track Proceedings*.

Lafferty, J. D., A. McCallum, et F. C. N. Pereira (2001). Conditional random fields : Probabilistic models for segmenting and labeling sequence data. In *Proceedings of the Eighteenth International Conference on Machine Learning*, ICML '01, San Francisco, CA, USA, pp. 282–289. Morgan Kaufmann Publishers Inc.

Moncla, L. (2015). *Automatic reconstruction of itineraries from descriptive texts*. Ph. D. thesis,
Université de Pau et des Pays de l'Adour, Pau, France.

Rawsthorne, H. M. (2024). *Creation of Geospatial Knowledge Graphs From Heterogeneous Sources*. PhD, Université Gustave Eiffel, Champs-sur-Marne, France.

Rawsthorne, H. M., N. Abadie, E. Kergosien, C. Duchêne, et É. Saux (2023). Automatic Nes-
ted Spatial Entity and Spatial Relation Extraction From Text for Knowledge Graph Crea-
tion : A Baseline Approach and a Benchmark Dataset. In *7th ACM SIGSPATIAL Interna-
tional Workshop on Geospatial Humanities, 31st International Conference on Advances in*
*Geographic Information Systems (ACM SIGSPATIAL 2023)*, Hamburg, Germany, pp. 21–30.
Association for Computing Machinery, New York, NY, United States.

Rawsthorne, H. M., N. Abadie, E. Kergosien, C. Duchêne, et É. Saux (2024). Extraction automatique d'entités spatiales imbriquées et de relations spatiales à partir de texte pour la création de graphes de connaissances : Une approche et deux jeux de données. In *Actes de l'atelier TextMine'24*. Conférence Extraction et Gestion des Connaissances 2024 (EGC'24), Dijon, France.

Shom (2021). *Instructions nautiques. D6 : Mer Méditerranée, côtes d'Afrique et du Levant [Version à jour au 13 octobre 2021]*. Brest, France.

Zhu, C., R. H. Byrd, P. Lu, et J. Nocedal (1997). Algorithm 778 : L-bfgs-b : Fortran subroutines for large-scale bound-constrained optimization. *ACM Trans. Math. Softw.* 23(4), 550–560.

## Summary

For this second edition of the TextMine challenge, the National Institute of Geographic and Forestry Information (IGN) and the Hydrographic and Oceanographic Service of the Navy (Shom) proposed taking up the challenge of recognising two-level named and unnamed geographical entities in the *Instructions nautiques*, a series of books published by the Shom. Nine academic and industrial teams participated in this challenge, and the results obtained by five of these teams, which were presented during the workshop, are summarised in this article.
CIAD System for Geographical Entity Detection at
TextMine'24

Pauline Armary*,** Cheikh-Brahim El-Vaigh, * Ouassila Labbani Narsis* Christophe Nicolle*

* CIAD, UMR 7533, Université de Bourgogne, UB,
64 rue de Sully 21000 Dijon
firstname.lastname@u-bourgogne.fr

**Anabasis-Assets
https://www.anabasis-assets.com/fr/

**Abstract.** This paper outlines CIAD's approach to Named Entity Recognition (NER) in a corpus of nautical instruction. Employing a conventional entity detection approach, our system tackles the NER task through token classification. We handled this classification task using two approaches: 1. NER is performed using different BERT models (BERT-base, Tiny-BERT, and CamemBERT); 2. We also used a GCN-based token classification where a graph is built connecting words in the same context. Our results suggest that within these token classification setups, our models are bounded to an accuracy of around 92% on the test data regardless of the complexity of the used BERT model.

# 1 Introduction

Named Entity Recognition (NER) is a fundamental task in natural language processing that involves the identification and classification of named entities within textual data (Liu et al., 2022). Named entities are specific entities such as persons, organizations, locations, dates, and more, which carry significance in the given context. NER plays a crucial role in information extraction, and the process typically involves analyzing and annotating text to locate and classify named entities (Liu et al., 2022; Wang et al., 2022).

NER has undergone significant advancements, with various approaches and techniques employed for identifying and classifying named entities in text. Initially, rule-based NER systems were used relying on predefined linguistic rules and patterns to identify named entities in text (Collins and Singer, 1999). Then, machine learning algorithms, such as Conditional Random Fields (CRF) and Hidden Markov Models (HMM), have been applied to learn patterns and features from labeled data (Patil et al., 2020; Morwal et al., 2012). The advent of deep learning models, especially Recurrent Neural Networks (RNNs), Long Short-Term Memory networks (LSTMs), and Transformers has ushered in a new era of state-of-the-art performance for NER tasks (Peters et al., 2018; Chiu and Nichols, 2016). Finally, with the success of transformers despite their huge training cost, fine-tuning pre-trained language models like BERT (Bidirectional Encoder Representations from Transformers) (Devlin et al., 2018) and GPT (Generative Pre-trained Transformer) has become a common practice.
In the context of the initiative TextMine 2024¹, focusing on the identification of geographical entities through named entity processing from a French nautical instruction corpus (Rawsthorne et al., 2024), the application of NER becomes crucial for extracting entities from the text. TextMine 2024 is an EGC 2024² evaluation Lab. However, the inherent challenges of the geographical entities context make the NER task more intricate, given that the texts are of a small size and noisy. Moreover, the target entities are not fine-grained types but rather ambiguous. For example, in Tab. 1 which shows the statistics of the different entity types, the annotation *name* refers to a proper noun being it a Person, a Place, or an Organization, while in the standard NER these three categories are separated. Moreover, while NER is often seen as a multi-class classification task, in this evaluation the NER is both a multi-class and a multi-label classification problem, and for example, in Tab. 1, we have 2123 tokens that are both *name* and *geogName*.

This paper proposes two approaches for the NER task in Sec. 2. We first studied several pre-trained BERT models (Devlin et al., 2018) that we fine-tuned on the TextMine corpus and compared their accuracy (see Sec. 2.1). We also devised a graph convolutional network (GCN) (Kipf and Welling, 2017) based approach that considers the tokens in the corpus as nodes and connects these nodes based on their co-occurrence in the same context. Moreover, labels are also seen as nodes and a token is connected to its labels from the train dataset. We then tackle NER as a node classification task using the standard GCN architecture (see Sec. 2.2). The code of our system is on GitHub<fnref n="3" />.

<table><caption>TAB. 1 – *The different annotations present in the corpus.*</caption><thead><tr><th>Type</th><th>geogFeat</th><th>geogFeat geogName</th><th>geogName</th><th>name</th><th>name geogName</th><th>tokens without label</th></tr></thead><tbody><tr><td>annotations in the corpus</td><td>4167</td><td>1469</td><td>4490</td><td>2118</td><td>2123</td><td>32668</td></tr></tbody></table>

# 2 CIAD's Systems

## 2.1 Fine-tuning BERT models

Fine-tuning a BERT model for a specific task is nowadays the state-of-the-art option for several NLP tasks, especially for NER. A BERT (Devlin et al., 2018) model is a Large Language Model (LLM) trained with an Encoder architecture on a very large corpus of documents. As with any LLM, the principle is to transform each word of the corpus into a vector within a large-dimensional space. This vector is reduced using a neural network architecture by optimizing the result to a specific task while reducing the number of dimensions of the vector space.

As part of the Transformer family, BERT uses an Encoder architecture trained on a masked-word prediction task. The Encoder Neural Network is trained to predict what is the correct word which was masked within a sentence. As such, the model uses the overall context surrounding the word to create a vector representing its meaning. For NER task, the model is fine-tuned as a Token Classification or Sequence classification task, with a corpus associating a label of each specific kind of entity (Person, Organization, Place, etc) to each word.

<footnote n="1">¹https://textmine.sciencesconf.org/resource/page/id/8</footnote>

<footnote n="2">²https://iutdijon.u-bourgogne.fr/egc2024/</footnote>

<footnote n="3">³https://github.com/elvaigh/textmine-ciad</footnote>
<table><caption>TAB. 2 – Comparison of the different models.</caption><thead><tr><th></th><th>1</th><th>2</th><th>3</th><th>4</th><th>5</th></tr></thead><tbody><tr><th>Model</th><td>Bert-base NER</td><td>CamemBERT NER</td><td>GPT2</td><td>TinyBERT</td><td>GCN</td></tr><tr><th>Accuracy</th><td>0.92771</td><td>0.92679</td><td>0.91931</td><td>0.91508</td><td>0.77936</td></tr></tbody></table>

For predicting the label of the corpus, we used a pre-trained BERT model on Sequence Classification for NER, which was pre-trained for recognizing different kinds of entities within the text. We fine-tuned the model to recognize the specific label of our corpus ("geoFeat", "geoName", "name"). We choose a Sequence Classifier as the data is presented as an ordered list of tokens. We fine-tuned the following models: BERT-Base-NER (BERT trained for NER in English), CamemBERT-NER (French BERT trained for NER in French), TinyBERT (refinement of the BERT model), and a NER model using GPT2 within a prompt-based learning setup.

## 2.2 Using GCN for NER

The Graph Convolutional Network (GCN) architecture was first proposed by (Kipf and Welling, 2017) for node classification. In the context of Natural Language Processing, the text is first transformed into a graph representing the connections between the words that appear in the same context (a window of size 2). For NER, the words are also associated with their labels, each label and token representing a node in the graph. This architecture is often presented as more resilient to multi-label classification, as a node can easily be associated with multiple labels. Within the GCN, an embedding of each node is learned and a softmax layer is used to perform classification based on these embeddings. We used the GCN model to our classification task for geographical entities.

## 3 Experiments

Experimental validation was conducted on the TextMine 2024 French corpus to assess the quality of our system. We evaluate our system using the accuracy metric. The description of the TextMine corpus can be found in the challenge website.<fnref n="4" />

We discuss hereunder the performance of NER classifiers that we described in Sec. 2.1 and Sec. 2.2. We gathered in Tab. 2 the accuracy of the different classifiers on the test dataset (a.k.a "public score" on the Kaggle page of the challenge<fnref n="5" />). One can see that BERT-based classifiers are the best, reaching an accuracy of 92.7%. Meanwhile, the difference between the smallest model (TinyBERT column 4 in Tab 2) and the largest model (BERT-base column 1 in Tab 2) is rather small (1.2%). This conclusion can be explained by the fact that, for the fine-tuning task, only a subset of the parameters is used (unfrozen parameters), therefore most the parameters of the model are kept as they are. We also show the accuracy of the GPT2 model using prompt learning (column 3 in Tab 2). We notice that this model shows a comparable performance to the BERT-based ones. Finally, the GCN NER classifier did not perform very well on the test dataset and its accuracy is only 77.9% (column 5 in Tab 2). The GCN classifier showed

<footnote n="4">⁴https://textmine.sciencesconf.org/resource/page/id/8</footnote>

<footnote n="5">⁵https://www.kaggle.com/competitions/defi-textmine-2024/</footnote>
promising results on the training dataset, as most of the nodes are known and the underlying graph creation is straightforward. However, we noticed that this GCN tends to over-fit on the train data and could not generalize well. We believe this is due to the way the graph is created (connecting nodes that appear in the same context), as with the provided TextMine dataset, each word has only limited context. This approach is not suitable for small datasets as it will require different contexts for each word.

## 4 Conclusion

We built an entity processing system based on a BERT model for the NER task, exploiting the existing pre-trained models. Our system was evaluated on the TextMine 2024 French dataset. The proposed model achieved an accuracy of 92.7% being only 5% points away from the best model. We also proposed a GCN model that did not perform well due to the small size of the data. These results open new perspectives for taking into account BERT embedding in a GCN model for NER.

## References

Chiu, J. P. and E. Nichols (2016). Named Entity Recognition with Bidirectional LSTM-CNNs. *Transactions of the Association for Computational Linguistics* 4, 357–370.

Collins, M. and Y. Singer (1999). Unsupervised models for named entity classification. In *1999 Joint SIGDAT conference on empirical methods in natural language processing and very large corpora*.

Devlin, J., M.-W. Chang, K. Lee, and K. Toutanova (2018). Bert: Pre-training of deep bidirectional transformers for language understanding. *arXiv preprint arXiv:1810.04805*.

Kipf, T. N. and M. Welling (2017). Semi-supervised classification with graph convolutional networks. In *5th International Conference on Learning Representations, ICLR 2017, Toulon, France, April 24-26, 2017, Conference Track Proceedings*.

Liu, X., H. Chen, and W. Xia (2022). Overview of named entity recognition. *Journal of Contemporary Educational Research* 6(5), 65–68.

Morwal, S., N. Jahan, and D. Chopra (2012). Named entity recognition using hidden markov model (hmm). *International Journal on Natural Language Computing (IJNLC) Vol 1*.

Patil, N., A. Patil, and B. Pawar (2020). Named entity recognition using conditional random fields. *Procedia Computer Science* 167, 1181–1188.

Peters, M. E., M. Neumann, M. Iyyer, M. Gardner, C. Clark, K. Lee, and L. Zettlemoyer (2018). Deep contextualized word representations. In M. Walker, H. Ji, and A. Stent (Eds.), *Proceedings of the 2018 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies, Volume 1 (Long Papers)*, New Orleans, Louisiana, pp. 2227–2237.

Rawsthorne, H., N. Abadie, A. Guille, P. Cuxac, V. Lemaire, and C. Lopez (2024). Reconnaissance d'entités géographiques dans un corpus des instructions nautiques (2024) défi textmine'24). *Conférence Extraction et Gestion des Connaissances 2024 (EGC'24)*.

Wang, Y., H. Tong, Z. Zhu, and Y. Li (2022). Nested named entity recognition: a survey. *ACM Transactions on Knowledge Discovery from Data (TKDD)* 16(6), 1–29.
# Défi TextMine 2024 : "Reconnaissance d'entités géographiques dans un corpus des Instructions nautiques" - soumission équipe CRIT

Nicolas Gutehrlé*

*Université de Franche-Comté, CRIT
F-25000 Besançon, France
nicolas.gutehrle@univ-fcomte.fr,
https://nicolasgutehrle.github.io/

**Résumé.** Cet article présente notre participation au défi TextMine 2024. Nous proposons une méthode reposant sur un modèle CRF linéaire, ainsi qu'une méthode hybride combinant un modèle CRF linéaire et un modèle XGBoost. Nous entraînons les modèles sur des caractéristiques morphologiques et syntaxiques extraites de chaque mot. Notre modèle CRF linéaire obtient une micro F-mesure de 0.942 sur le jeu de test privé. Ces résultats montrent que des modèles simples tels que CRF linéaire entraînés sur des caractéristiques simples telles que la forme des mots sont efficaces pour la tâche de reconnaissance d'entités spatiales nommées et non nommées.

## 1 Introduction

Le défi TextMine 2024 consiste en la reconnaissance d'entités spatiales nommées et non nommées à plusieurs niveaux dans les Instructions nautiques, une série d'ouvrages publiée par le Shom (Service hydrographique et océanographique de la Marine). Le corpus mis à disposition est constitué d'extraits de 15 volumes des Instructions nautiques décrivant des environnements maritimes côtiers. La tâche de reconnaissance des entités nommées (REN) a suscité un vif intérêt ces dernières années, et a vu l'application de nombreuses approches, en particulier les approches par règles (Nadeau et Sekine, 2007; Sekine et Nobata, 2004; Kim et Woodland, 2000; Farmakiotou et al., 2000; Appelt et al., 1993), par apprentissage automatique (machine-learning) (Asahara et Matsumoto, 2003; Borthwick et al., 1998; Sekine, 1998; Bikel et al., 1998; McCallum et Li, 2003; Ritter et al., 2011; Rocktäschel et al., 2012), et plus récemment par apprentissage profond (deep-learning) (Yadav et Bethard, 2019; Li et al., 2020).

Dans cet article, nous présentons notre participation au défi TextMine 2024. Nous abordons la reconnaissance d'entités spatiales nommées et non nommées comme une tâche d'annotation de séquence. Nous entraînons pour cela trois modèles CRF linéaires (Lafferty et al., 2001), chacun entraîné sur des ensembles de caractéristiques différents. De plus, nous proposons un modèle hybride, combinant un modèle CRF linéaire pour la détection des mentions d'entités nommées, et un modèle XGBoost (Chen et Guestrin, 2016) pour la classification des mentions détectées. Nous entraînons les modèles sur des caractéristiques (features) morphologiques et
syntaxiques extraites de chaque mot dans le jeu de données d'entraînement mis à disposition. Les résultats du défi sont disponibles sur Kaggle<fnref n="1" />, tandis que notre code et nos expérimentations sont disponibles sur GitHub<fnref n="2" />. Le reste de l'article est structuré comme suit : nous présentons les données dans la section 2, puis notre méthodologie dans la section 3. Nous présentons l'évaluation de notre méthodologie en section 4 avant de présenter notre conclusion en section 5.

## 2 Données

Un jeu de données d'entraînement et de test ont été mis à disposition des participants, au format CSV. Le jeu d'entraînement est divisé en deux colonnes, une pour les tokens et une pour les classes correspondantes. Le jeu de test ne contient que les tokens. Le jeu de test mis à disposition, dit jeu de test public, représente environ 60 % des données totales de test. Afin d'entraîner nos modèles et identifier les meilleures combinaisons d'hyper-paramètres possibles, nous avons divisé le jeu d'entraînement en un jeu d'entraînement et un jeu de développement. Le Tableau 1 présente la distribution des classes dans les jeux de données d'entraînement et de développement.

<table><caption>TAB. 1 – Distribution des classes dans les jeux de données d'entraînement et de développement.</caption><thead><tr><td>Classe</td><td>Entraînement</td><td>Développement</td></tr></thead><tbody><tr><td>aucun</td><td>22 859</td><td>9 804</td></tr><tr><td>geogFeat</td><td>1 899</td><td>805</td></tr><tr><td>geogName name</td><td>1 491</td><td>626</td></tr><tr><td>geogFeat geogName</td><td>995</td><td>468</td></tr><tr><td>geogName</td><td>655</td><td>255</td></tr><tr><td>Total</td><td>27 899</td><td>11 958</td></tr></tbody></table>

Plusieurs classes sont composées de multiples étiquettes : par exemple, la classe *geogFeat* est composée des étiquettes *geogFeat* et *geogName*, qui sont toutes deux des classes à part entière dans le jeu de données. Le Tableau 2 présente la distribution des classes uniques dans les jeux d'entraînement et de développement.

<table><caption>TAB. 2 – Distribution des étiquettes uniques dans les jeux de données d'entraînement et de développement.</caption><thead><tr><td>Classe</td><td>Entraînement</td><td>Développement</td></tr></thead><tbody><tr><td>name</td><td>1 491</td><td>626</td></tr><tr><td>geogFeat</td><td>2 894</td><td>1 273</td></tr><tr><td>geogName</td><td>3 141</td><td>1 349</td></tr></tbody></table>

<footnote n="1">1. https://www.kaggle.com/competitions/defi-textmine-2024/submissions</footnote>

<footnote n="2">2. https://github.com/nicolasgutehrle/DefiTextmineCRIT</footnote>
# 3 Méthodologie et implémentation

Nous abordons ce défi comme une tâche d'annotation de séquence. Afin d'entraîner les modèles, nous extrayons des caractéristiques morphologiques et syntaxiques pour chaque token *t* dans le jeu de données. Nous extrayons ces mêmes caractéristiques des token qui précédent et suivent directement le token *t*. Ces caractéristiques sont préfixées par *prev_* et *next_* respectivement. Le Tableau 3 présente l'ensemble des caractéristiques extraites pour un token *t*. La caractéristique *shape* représente les lettres majuscules par un "X", les valeurs numériques par un "d" et les ponctuations par un ".". Tous les autres caractères sont représentés par un "x". Par exemple, l'entité nommée "Nadji" aura la forme "Xxxxx". Nous employons le modèle *fr_core_news_lg* du framework *spaCy*<fnref n="3" /> pour obtenir les parties du discours ainsi que les rôles syntaxiques des tokens. Nous employons également la liste de mots vides de ce modèle pour déterminer si un token est un mot vide.

<table><caption>TAB. 3 – *Caractéristiques extraites pour chaque token.*</caption><thead><tr><td></td><td>Caractéristique</td><td>Description</td></tr></thead><tbody><tr><td>1</td><td>Token</td><td>Mot</td></tr><tr><td>2</td><td>lower</td><td>Mot en minuscule</td></tr><tr><td>3</td><td>isdigit</td><td>Vrai si le mot est une valeur numérique, sinon Faux</td></tr><tr><td>4</td><td>isupper</td><td>Vrai si le mot est écrit en lettres capitales, sinon Faux</td></tr><tr><td>5</td><td>ispunct</td><td>Vrai si le mot est une ponctuation, sinon Faux</td></tr><tr><td>6</td><td>isstop</td><td>Vrai si le mot est un mot vide, sinon Faux</td></tr><tr><td>7</td><td>len</td><td>Nombre de caractères composant le mot</td></tr><tr><td>8</td><td>shape</td><td>Forme du mot</td></tr><tr><td>9</td><td>pos</td><td>Partie du discours du mot</td></tr><tr><td>10</td><td>dep</td><td>Rôle syntaxique du mot</td></tr></tbody></table>

Nous entraînons trois modèles CRF linéaires, chacun avec un ensemble différent de caractéristiques : *baseModel* entraîné avec les caractéristiques 1 à 8, *posModel*, entraîné avec les caractéristiques 1 à 9 et *posDepModel*, entraîné avec les caractéristiques 1 à 10. Notre objectif est de comparer l'apport des parties du discours et des dépendances syntaxiques pour la reconnaissance d'entités spatiales nommées et non nommées. Nous utilisons l'implémentation du modèle CRF linéaire proposée par le package *sklearn-crfsuite*<fnref n="4" />. Pour chaque modèle, nous recherchons la combinaison optimale de valeurs d'hyper-paramètres parmi les valeurs présentées dans le Tableau 4. Nous évaluons chaque modèle sur le jeu de développement. Les valeurs optimales de chaque hyper-paramètre pour chaque modèle sont présentées dans le Tableau 5. Enfin, nous entraînons chaque modèle CRF linéaire sur l'ensemble des données, c'est-à-dire sur les jeux d'entraînement et de développement combinés, avec les meilleurs valeurs d'hyper-paramètres identifiées.

Comme indiqué en section 2, la classe d'un token peut être une combinaison de plusieurs étiquettes. Afin d'exploiter la nature composite des classes, nous proposons un modèle hy-

<footnote n="3">3. https://spacy.io/</footnote>

<footnote n="4">4. https://sklearn-crfsuite.readthedocs.io/en/latest/</footnote>
<table><caption>TAB. 4 – Valeurs testées pour les hyper-paramètres c1 et c2 du modèle CRF linéaire.</caption><tr><td>c1</td><td>0.5, 0.1, 0.01, 0.001, 0.0001</td></tr><tr><td>c2</td><td>0.5, 0.1, 0.01, 0.001, 0.0001</td></tr></table>

<table><caption>TAB. 5 – Valeurs optimales des hyper-paramètres pour les modèles baseModel, posModel et posDepModel.</caption><thead><tr><td>Modèle</td><td>c1</td><td>c2</td></tr></thead><tbody><tr><td>baseModel</td><td>0.1</td><td>0.001</td></tr><tr><td>posModel</td><td>0.1</td><td>0.01</td></tr><tr><td>posDepModel</td><td>0.1</td><td>0.01</td></tr></tbody></table>

bride, qui combine un modèle CRF linéaire pour la détection d’entités nommées et un modèle XGBoost pour la classification de ces entités.

Afin d’entraîner le modèle CRF linéaire de ce modèle hybride, nous modifions les jeux d’entraînement et de développement de telle sorte que toutes les classes autre que "aucun" sont remplacées par l’étiquette "NER". Nous proposons ainsi une version binaire de jeu de données. La distribution des classes dans les jeux d’entraînement et de développement binaires est présentée dans le Tableau 6.

<table><caption>TAB. 6 – Distribution des classes binaires dans les jeux de données d’entraînement et de développement.</caption><thead><tr><td>Classe</td><td>Entraînement</td><td>Développement</td></tr></thead><tbody><tr><td>aucun</td><td>22 859</td><td>9 804</td></tr><tr><td>NER</td><td>5 040</td><td>2 154</td></tr><tr><td>Total</td><td>27 899</td><td>11 958</td></tr></tbody></table>

Nous entraînons plusieurs modèles CRF linéaires afin de trouver la combinaison optimale de valeurs d’hyper-paramètres parmi les valeurs présentées dans le Tableau 7. La valeur optimale de chaque hyper-paramètre y est notée en gras. Chaque modèle est évalué sur le jeu de développement. Nous entraînons enfin le modèle CRF linéaire binaire final sur l’ensemble des données avec les meilleurs valeurs d’hyper-paramètres identifiées.

Pour entraîner le modèle XGBoost, nous modifions les jeux de données d’entraînement et de développement de telle sorte qu’un token est associé à plusieurs classes. Ainsi, nous entraînons ce modèle selon une tâche classification multi-étiquettes (multi-label), et non pas une tâche de classification multi-classes. Nous employons l’implémentation du modèle XGBoost du package xgboost. Nous entraînons plusieurs modèles XGBoost afin de trouver la combinaison optimale de valeurs d’hyper-paramètres parmi les valeurs présentées dans le Tableau 8. La valeur optimale de chaque hyper-paramètre y est notée en gras. Chaque modèle est évalué sur le jeu de développement. Nous entraînons enfin le modèle XGBoost final sur l’ensemble des données avec les meilleurs valeurs d’hyper-paramètres identifiées.
<table><caption>TAB. 7 – Valeurs testées pour les hyper-paramètres c1 et c2 du modèle CRF linéaire. Les valeurs en gras sont les valeurs optimales identifiées.</caption><tr><td>c1</td><td>0.5, 0.1, 0.01, 0.001, <b>0.0001</b></td></tr><tr><td>c2</td><td>0.5, <b>0.1</b>, 0.01, 0.001, 0.0001</td></tr></table>

<table><caption>TAB. 8 – Valeurs testées pour les hyper-paramètres n_estimators, max_depth, learning_rate et subsample du modèle XGBoost. Les valeurs en gras sont les valeurs optimales identifiées.</caption><tr><td>n_estimators</td><td>50, 100, <b>150</b>, 200, 350, 500</td></tr><tr><td>max_depth</td><td>1, 2, 3, 4, 5, 6, 7, 8, <b>9</b>, 10</td></tr><tr><td>learning_rate</td><td>0.0001, 0.001, 0.01, 0.1, <b>1.0</b></td></tr><tr><td>subsample</td><td>.25, .5, .75, <b>1</b></td></tr></table>

# 4 Résultats et Discussion

Les modèles ont été évalués en terme de micro F-mesure sur un jeu de test public et un jeu de test privé. Le jeu de test public représente environ 60 % du jeu de test privé. Le Tableau 9 présente les performances des quatre modèles sur les jeux de test public et privé.

<table><caption>TAB. 9 – Evaluation des quatre modèles selon la micro F-mesure sur les jeux de test public et privé.</caption><thead><tr><td>Modèle</td><td>Micro F-mesure (public)</td><td>Micro F-mesure (privé)</td></tr></thead><tbody><tr><td>baseModel</td><td><b>0.964</b></td><td>0.942</td></tr><tr><td>posModel</td><td>0.959</td><td><b>0.944</b></td></tr><tr><td>posDepModel</td><td>0.959</td><td>0.943</td></tr><tr><td>hybrid</td><td>0.915</td><td>0.895</td></tr></tbody></table>

Sur le jeu de test public, le modèle *baseModel* atteint le meilleur score, qui est de 0.964. Les modèles *posModel* et *posDepModel* obtiennent tous deux un score de 0.959. Enfin, le modèle *hybrid* obtient le score le plus bas, qui est de 0.915. Sur le jeu de test privé, le modèle *posModel* atteint le meilleur score, qui est de 0.944. Les modèles *baseModel* et *posDepModel* obtiennent respectivement un score de 0.942 et 0.943. Enfin, le modèle *hybrid* obtient le score le plus bas, qui est de 0.895.

Les scores des modèles *baseModel*, *posModel* et *posDepModel* sont similaires. L'ajout des parties du discours et des rôles syntaxiques comme caractéristiques d'entraînement ne semblent pas affecter les performances du modèle. De simples caractéristiques d'entraînements, telles que celles que nous avons extraites, semblent donc adéquates pour identifier les entités spatiales nommées et non nommées. Cependant, les données mises à disposition rassemblent les tokens dans un seul grand document, sans les séparer en phrases. Cela peut affecter la qualité de l'analyse en partie du discours ainsi que l'analyse en dépendances syntaxiques. Le modèle *hybrid* obtient les scores les plus bas sur les deux évaluations. Cette baisse des scores peut s'expliquer par l'incapacité du modèle XGBoost à prendre en compte le
contexte de l'élément à catégoriser. La conversion de la tâche de classification multiclasse en une tâche de classification multi-étiquettes peut également expliquer ces résultats inférieurs.

Le Tableau 10 présente les dix plus importantes caractéristiques identifiées par le modèle *baseModel* contribuant positivement à l'identification de chaque classe. Chaque caractéristique est représentée par sa valeur et son poids. La caractéristique *lower*, c'est-à-dire la forme du mot en minuscule, est la plus fréquemment employée pour chaque classe. Le modèle se concentre sur le mot lui-même pour les classes contenant l'étiquette *geogFeat*, comme en témoigne l'emploi des caractéristiques *Token* et *lower*. Il en est de même pour les classes contenant l'étiquette *geogName* et *name*. Pour ces classes là, le modèle se concentre également sur les mots précédents et suivants, comme en témoigne l'emploi des caractéristiques *prev_Token*, *prev_lower*, *next_Token*, *next_lower*. Le modèle semble apprendre du vocabulaire maritime ("mouillage", "rade", "lagon", etc.) pour identifier les classe *geogFeat* et *geogFeat geogName*. De même, il semble apprendre des noms propres désignant des lieux ("Islande", "Djibouti", etc.) pour identifier les classes *geogFeat geogName* et *geogName name*.

<table><caption>TAB. 10 – Dix plus importantes caractéristiques identifiées par le modèle *baseModel* contribuant positivement à l'identification de chaque classe. Chaque caractéristique est représentée par sa valeur et son poids.</caption><thead><tr><th>aucun</th><th>geogName</th><th>geogName name</th><th>geogFeat</th><th>geogFeat geogName</th></tr></thead><tbody><tr><td>isdigit, 8.512</td><td>Token :», 6.085</td><td>Token :nouveau, 7.609</td><td>lower :mouillages, 11.987</td><td>lower :île, 10.255</td></tr><tr><td>lower :entre, 7.967</td><td>lower :», 6.085</td><td>lower :nouveau, 7.609</td><td>lower :amers, 9.929</td><td>lower :pointe, 8.422</td></tr><tr><td>Token :petit, 7.822</td><td>Token :principal, 4.995</td><td>prev_lower :côte, 7.492</td><td>lower :rade, 9.815</td><td>lower :ras, 7.632</td></tr><tr><td>lower :ouest, 7.780</td><td>lower :principal, 4.995</td><td>lower :djibouti, 7.405</td><td>lower :lagon, 9.778</td><td>lower :cap, 6.950</td></tr><tr><td>Token :grande, 6.443</td><td>prev_lower :capitainerie, 4.939</td><td>lower :blancpignon, 7.383</td><td>lower :alignement, 9.282</td><td>lower :îles, 6.755</td></tr><tr><td>lower :petite, 6.408</td><td>next_Token :médian, 4.922</td><td>lower :grande, 7.100</td><td>Token :appontement, 9.074</td><td>lower :aéroport, 6.554</td></tr><tr><td>lower :jusqu', 5.881</td><td>next_lower :médian, 4.922</td><td>lower :espagnole, 6.454</td><td>lower :pontons, 9.057</td><td>Token :Island, 6.535</td></tr><tr><td>shape :X, 5.880</td><td>shape :xxxxxxxx, 4.187</td><td>Token :ancien, 6.296</td><td>Token :baie, 8.515</td><td>lower :island, 6.535</td></tr><tr><td>lower :devant, 5.782</td><td>prev_lower :phare, 4.123</td><td>lower :ancien, 6.296</td><td>lower :échelles, 8.266</td><td>Token :Pass, 6.496</td></tr><tr><td>Token :Est, 5.746</td><td>next_Token :sur, 3.932</td><td>shape :Xxxxx.Xxxxxxx, 6.258</td><td>lower :îles, 8.249</td><td>prev_Token :ancienne, 6.251</td></tr></tbody></table>

## 5 Conclusion

Dans cet article, nous avons présenté notre participation au Défi TextMine 2024 : "Reconnaissance d'entités géographiques dans un corpus des Instructions nautiques". Nous avons proposé deux méthodes pour la tâche de reconnaissance d'entités spatiales nommées et non nommées. Notre première méthode repose sur un modèle CRF linéaire, tandis que notre seconde méthode est hybride, et combine un modèle CRF linéaire avec un modèle XGBoost. Notre modèle CRF linéaire, entraîné sur des caractéristiques morphologiques simples telles que la forme des mots, obtient une micro F-mesure de 0.964 sur le jeu de test public, et une micro F-mesure de 0.942 sur le jeu de test privé. Ces résultats montrent que des modèles simples tels que CRF linéaire entraînés sur des caractéristiques morphologiques également simples sont efficaces pour la tâche de reconnaissance d'entités spatiales nommées et non nommées. Dans des travaux futurs, nous comptons expérimenter avec d'autres caractéristiques d'entraînement d'ordre morphologique, syntaxique ou sémantique. Nous avons également l'intention d'approfondir notre étude sur la nature composite des entités nommées et non-nommées en continuant nos expérimentations sur la classification multi-étiquettes.
Références

Appelt, D. E., J. R. Hobbs, J. Bear, D. Israel, et M. Tyson (1993). Fastus : A finite-state
processor for information extraction from real-world text. In *IJCAI*, Volume 93, pp. 1172-
1178.

Asahara, M. et Y. Matsumoto (2003). Japanese named entity extraction with redundant mor-
phological analysis. In *Proceedings of the 2003 human language technology conference of
the North American chapter of the association for computational linguistics*, pp. 8–15.

Bikel, D. M., S. Miller, R. Schwartz, et R. Weischedel (1998). Nymble : a high-performance
learning name-finder. *arXiv preprint cmp-lg/9803003*.

Borthwick, A., J. Sterling, E. Agichtein, et R. Grishman (1998). Description of the mene named
entity system as used in muc-7. In *Proceedings of the Seventh Message Understanding
Conference (MUC-7), Fairfax, Virginia, April 29-May 1, 1998*.

Chen, T. et C. Guestrin (2016). Xgboost : A scalable tree boosting system. In *Proceedings of the 22nd acm sigkdd international conference on knowledge discovery and data mining*, pp. 785–794.

Farmakiotou, D., V. Karkaletsis, J. Koutsias, G. Sigletos, C. D. Spyropoulos, et P. Stamatopoulos (2000). Rule-based named entity recognition for greek financial texts. In *Proceedings of the Workshop on Computational lexicography and Multimedia Dictionaries (COMLEX 2000)*, pp. 75–78.

Kim, J.-H. et P. C. Woodland (2000). A rule-based named entity recognition system for speech input. In *Sixth International Conference on Spoken Language Processing*.

Lafferty, J., A. McCallum, et F. C. Pereira (2001). Conditional random fields : Probabilistic
models for segmenting and labeling sequence data.

Li, J., A. Sun, J. Han, et C. Li (2020). A survey on deep learning for named entity recognition.
*IEEE Transactions on Knowledge and Data Engineering* 34(1), 50–70.

McCallum, A. et W. Li (2003). Early results for named entity recognition with conditional
random fields, feature induction and web-enhanced lexicons.

Nadeau, D. et S. Sekine (2007). A survey of named entity recognition and classification.
*Lingvisticae Investigationes* 30(1), 3–26.

Ritter, A., S. Clark, O. Etzioni, et al. (2011). Named entity recognition in tweets : an ex-
perimental study. In *Proceedings of the 2011 conference on empirical methods in natural
language processing*, pp. 1524–1534.

Rocktäschel, T., M. Weidlich, et U. Leser (2012). Chemspot : a hybrid system for chemical
named entity recognition. *Bioinformatics* 28(12), 1633–1640.

Sekine, S. (1998). Nyu : Description of the japanese ne system used for met-2. http://www.muc.saic.com/.

Sekine, S. et C. Nobata (2004). Definition, dictionaries and tagger for extended named entity hierarchy. In *LREC*, pp. 1977–1980. Lisbon, Portugal.

Yadav, V. et S. Bethard (2019). A survey on recent advances in named entity recognition from deep learning models. *arXiv preprint arXiv:1910.11470*.
Summary

This article presents our participation to the TextMine 2024 challenge. We propose a method based on a linear CRF model, as well as a hybrid method combining a linear CRF model and an XGBoost model. We train the models on morphological and syntactic features extracted from each word. Our linear CRF model obtains a micro F-measure of 0.942 on the private test set. These results show that simple models such as linear CRF trained on simple features such as word shape are effective for the Named and Unnamed Spatial Entity Recognition task.
# OctopusMind @ Défi TextMine'24 Reconnaissance d'entités géographiques dans un corpus d'instructions nautiques

Oussama Ahmia*

Danrun Cao* **

Nicolas Béchet**

Pierre-François Marteau**

*OctopusMind

Nantes, France

o.ahmia@octopusmind.info, d.cao@octopusmind.info

https://www.octopusmind.info/

**Univ. Bretagne Sud, CNRS, IRISA

Vannes, France

danrun.cao@univ-ubs.fr; nicolas.bechet@univ-ubs.fr; pierre-rancois.marteau@univ-ubs.fr

https://www.irisa.fr/en/equipes/expression

**Résumé.** Le défi Textmine'24 concerne la reconnaissance d'entités nommées et non nommées au sein des instructions nautiques, en utilisant un jeu de données extrait d'une série d'ouvrages annotés publiés par le Shom. Cet article présente les résultats obtenus en appliquant des méthodes de l'état de l'art dans le domaine de la reconnaissance des entités nommées en considérant le problème de reconnaissance comme une tâche multi-classe plutôt que multi-label. Cette approach est mise en production chez OctopusMind, un acteur français spécialiste en intelligence économique.

## 1 Introduction

Le défi Textmine'24 (Rawsthorne et al., 2024) cible la "Reconnaissance d'entités géographiques dans un corpus d'instructions nautiques". Proposé par l'IGN (Institut Géographique National) et le Shom (Service hydrographique et océanographique de la Marine), ce défi concerne plus précisément l'identification d'entités spatiales nommées et non nommées dans les instructions nautiques. Le corpus annoté à partir d'ouvrages publiés par le Shom, offre des détails sur les environnements maritimes côtiers mondiaux, fournissant des informations cruciales pour la navigation sécurisée et l'accès aux ports. Ce corpus est constitué d'extraits annotés issus de 15 volumes d'instructions nautiques, totalisant 66 030 tokens et 18 537 labels.

Notre participation à ce défi nous offre l'opportunité d'évaluer des méthodes actuellement utilisées en production chez OctopusMind pour des tâches similaires. Dans cet article, nous appliquons certaines approches de l'état de l'art dans le domaine de l'extraction des entités nommées, notamment les modèles à base de CRF (Conditional Random Fields (Lafferty et al.,
2001)) et de Transformers (Vaswani et al., 2017), en changeant de perspective sur la problématique en considérant ainsi le problème de reconnaissance comme une tâche multi-classe plutôt que multi-label.

## 2 Jeu de données

Le jeu de données fourni aux participants comprend un total de 66 030 tokens et 18 537 labels. Il est préalablement tokenisé et annoté au niveau des tokens, puis divisé en deux parties distinctes :

**train**, le jeu d'entraînement annoté contenant 39 857 tokens et **test**, le jeu d'évaluation (public) non annoté contenant 26 173 tokens, ce qui représente 41% du jeu de **test** total (public + privé).

Les étiquettes (labels) utilisées sont les suivantes :

**name**: pour les noms propres purs, par exemple : "Port de Kpémé"
**geogFeat**: pour les noms communs qui identifient une caractéristique géographique, par exemple : le **récif** qui porte l'îlot Pagode, **geogName**: pour le nom associé à une caractéristique géographique, par exemple : "De l' Est du phare de Nadji jusqu'à ..."

Chaque token peut recevoir entre 0 et 2 labels, la problématique peut donc être considérée comme multi-label, ce qui fait 5 combinaisons possibles.

## 3 Méthode

Nous avons choisi de traiter le problème de reconnaissance comme une tâche multi-classe plutôt que multi-label. Cela signifie que si un token possède deux labels, nous considérons cette combinaison comme une classe distincte, ce qui nous donne un total de 5 classes : **geogFeat** **geogName**, **geogFeat**, **geogName**, **geogName name**, **aucun**. Cette approche a déjà fait ses preuves sur des tâches similaires (Ahmia et al., 2017) et permet de simplifier la tâche.

Le jeu de données est présenté sous la forme d'une seule séquence englobant l'ensemble des tokens. Par conséquent, nous avons organisé les tokens par phrases en utilisant le critère de fin de phrase défini par le token ".". Nous avons ainsi obtenu 1702 phrases. Le tableau 1, présente des statistiques sur le nombre de tokens par phrase.

<table><caption>TAB. 1 – Statistiques sur le nombre de tokens par phrase.</caption><tr><td>Moyenne</td><td>23.4</td></tr><tr><td>Maximum</td><td>302</td></tr><tr><td>Minimum</td><td>2</td></tr><tr><td>Median</td><td>17.5</td></tr></table>

Les algorithmes que nous avons utilisés sont présentés ci-après.
## 3.1 CRF

Les champs aléatoires conditionnels ou **CRF** constituent une famille de modèles discriminants probabilistes et peuvent être considérés comme des graphes non dirigés, les noeuds de ce graphe sont séparés en deux ensembles X et Y, les observations et les sorties (les étiquettes). Les arcs entres les noeuds représentent la probabilité conditionnelle de transition P(Y|X). Les **CRF** sont utilisés principalement pour la modélisation de séquences, en particulier dans le traitement du langage pour la détection d'entités nommées.

Nous avons utilisé différents types de caractéristiques pour représenter chaque token : **text** la forme du token, **lemma** le lemme, **lower** le token en minuscule, **shape** la forme du mot (majuscules, ponctuation, chiffres) exemple '4.5.3'='d.d.d', **is_alpha** si le token est formé que de lettres, **isglipt** si le token est un nombre, **is_lower** si le token est en minuscule, **is_lower** si le token est en majuscule, **is_punct** si le token est une ponctuation et **pos** qui est la catégorie morphosyntaxique du token.

Nous avons aussi utilisé des caractéristiques à longue portée qui modélisent le contexte d'occurrence des tokens (les variables voisines d'un token).

L'optimisation des poids du CRF est réalisée avec la méthode **Limited-memory Broyden-Fletcher-Goldfarb-Shanno** (L-BFGS, Zhu et al. (1997)), le **CRF** est entraîné avec l'outil **CRFsuite** et l'extraction de caractéristiques est produite avec **Spacy**.

## 3.2 CamemBERT

CamemBERT (Martin et al., 2019) est un modèle de langage basé sur l'architecture BERT (Bidirectional Encoder Representations from Transformers) pré-entraîné sur des corpus français et sur plusieurs tâches différentes (classification, séquence à séquence, ...). Nous adaptons ce modèle pour une tâche d'extraction d'entités nommées en rajoutant une couche linéaire dense en sortie du réseau CamemBERT qui permettra de prédire les classes de sorties pour chaque Token. Un apprentissage final (fine tuning) est ensuite pratiqué en exploitant les données **TextMine'24**. Afin d'éviter le sur-apprentissage du modèle, on effectue une stratification (Sechidis et al., 2011) des données afin de créer des ensembles d'entraînement et de validation homogènes en terme de représentation des classes (en ne considérant qu'une seule occurrence d'une classe dans une séquence). Pour l'entraînement du réseau de neurones on utilise l'outil **Transformers**<fnref n="1" />.

On notera aussi que le jeu de données fourni est préalablement tokenisé en mots, tandis que CamemBERT utilise une tokenisation en sous-mots (sub-word tokenization). Par conséquent, nous avons mis en place une correspondance entre les tokens d'origine et les tokens en sous-mots, ce qui nous permet de faire le lien entre les étiquettes fournies par CamemBERT et les tokens d'origine.

# 4 Résultats

L'évaluation du défi **TextMine'24** est obtenue via une mesure de F-score sur les données de test publiques. Le tableau 2, présente les scores des différentes versions de CRF testées : "CRF base" où seul le texte du token est utilisé comme caractéristique, "CRF context 3 text"

<footnote n="1">1. https://huggingface.co/docs/transformers/index</footnote>
<table><caption>TAB. 2 – Résultats des modèles en termes de F-score obtenus sur les données de test publiques</caption><thead><tr><td></td><td>F-score</td></tr></thead><tbody><tr><td>CRF base</td><td>90.1%</td></tr><tr><td>CRF context 3 text</td><td>93.9%</td></tr><tr><td>CRF context 5 all features</td><td>95.4%</td></tr><tr><td>CRF context 3 all features</td><td>95.7%</td></tr><tr><td>CamemBERT 16 ep</td><td>97.4%</td></tr><tr><td>CamemBERT stratified 30 ep</td><td>97.6%</td></tr><tr><td>CamemBERT alldata 60 ep</td><td>98.0%</td></tr><tr><td>CamemBERT alldata 30 ep</td><td>98.1%</td></tr></tbody></table>

un CRF utilisant des caractéristiques à longue portée (contexte local de taille 3 du token), "CRF context 5 all features" et "CRF context 3 all features" qui utilise toutes les caractéristiques mentionnées dans la Section 3.1 avec respectivement des contextes de tailles 5 et 3.

On remarque que l'utilisation de caractéristiques à longue portée améliore le score du CRF jusqu'à atteindre une certaine limite, sachant que l'augmentation du contexte augmente la dimensionnalité du problème pouvant ainsi dégrader les performances.

Nous avons aussi testé différentes approches d'entraînement pour le réseau CamemBERT en faisant varier le nombre d'époques ainsi que l'entraînement sur la totalité ou une partie des données. Le gain en termes de score est cependant marginal avec une légère amélioration de la performance pour le modèle entraîné sur la totalité des données. Au-delà de 30 époques, nous n'observons plus d'amélioration de performance. On notera aussi que le modèle CamemBERT obtient de meilleurs scores comparativement aux CRF (+0.03), néanmoins, le temps nécessaire pour générer un modèle CamemBERT est bien plus conséquent que pour générer un modèle CRF (30 minutes vs quelques secondes pour des tests effectués sur une machine munie d'une GeForce RTX 2080 Ti et d'un AMD Ryzen 9 3950X).

Le code permettant de générer le modèle obtenant le meilleur score est accessible via le lien suivant: https://github.com/oussamaahmia/textmine24

## 5 Conclusion

Cet article présente l'approche que nous avons développée dans le cadre de notre participation au défi TextMine 2024, dont l'objectif cible la reconnaissance des entités nommées et non nommées au sein d'un corpus d'instructions nautiques du Shom. L'originalité de notre approche consiste à aborder cette problématique comme un problème multi-classe plutôt qu'un problème multi-label. Nous avons comparé les performances de quelques architectures CRF à celles d'un réseau CamemBERT affiné spécifiquement pour cette tâche. Le modèle CamemBERT a obtenu la première place du classement du défi TextMine privé/public 2.

En perspective, compte tenu de l'écart faible de performance entre CRF et modèles camembert, le principe du rasoir d'Occam nous incite à approfondir les expérimentations sur les architectures CRF en testant d'autres combinaisons de caractéristiques. De plus, une analyse

<footnote n="2">2. https://www.kaggle.com/competitions/defi-textmine-2024/leaderboard</footnote>
approfondie des poids attribués aux différentes caractéristiques pourrait apporter des explications supplémentaires sur les résultats obtenus par ces architectures CRF.

## Références

Ahmia, O., N. Béchet, et P.-F. Marteau (2017). Apprentissage de structures séquentielles pour l'extraction d'entités et de relations dans des textes d'appels d'offres. In *EGC*, pp. 351–356.

Lafferty, J., A. McCallum, et F. C. Pereira (2001). Conditional random fields: Probabilistic models for segmenting and labeling sequence data.

Martin, L., B. Muller, P. J. O. Suárez, Y. Dupont, L. Romary, É. V. de La Clergerie, D. Seddah, et B. Sagot (2019). Camembert: a tasty french language model. *arXiv preprint arXiv:1911.03894*.

Rawsthorne, H., A. G. N. Abadie, V. L. P. Cuxac, et C. Lopez (2024). Reconnaissance d'entités géographiques dans un corpus des instructions nautiques. actes de l'atelier textmine'24. *Conférence Extraction et Gestion des Connaissances 2024 (EGC'24)*.

Sechidis, K., G. Tsoumakas, et I. Vlahavas (2011). On the stratification of multi-label data. In *Machine Learning and Knowledge Discovery in Databases: European Conference, ECML PKDD 2011, Athens, Greece, September 5-9, 2011, Proceedings, Part III 22*, pp. 145–158. Springer.

Vaswani, A., N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones, A. N. Gomez, Ł. Kaiser, et I. Połosukhin (2017). Attention is all you need. *Advances in neural information processing systems 30*.

Zhu, C., R. H. Byrd, P. Lu, et J. Nocedal (1997). Algorithm 778 : L-bfgs-b : Fortran subroutines for large-scale bound-constrained optimization. *ACM Transactions on mathematical software (TOMS)* 23(4), 550–560.

## Summary

The Textmine'24 challenge concerns the recognition of named and unnamed entities within nautical instructions, using a dataset extracted from a series of annotated documents published by Shom. This article presents the results obtained by applying state-of-the-art methods in named entity recognition by considering the recognition problem as a multi-class rather than multi-label task. This approach is currently deployed at OctopusMind, a French player specializing in business intelligence.
<figure><img src="image_26.png" /></figure>
# Détection d'entités nommées géographiques par réseau de neurones récurrents

Lucas Anki*, Léo Gaillard*, Justine Revol*

*Inist-CNRS (UAR 76), 2 rue Jean Zay, 54500 Vandoeuvre-lès-Nancy, France
[prénom].[nom]@inist.fr

**Résumé.** Cet article présente notre méthodologie pour répondre au défi Text-Mine 2024 (voir Guille (2023)). L'objectif est la **Reconnaissance d'entités géographiques dans un corpus des instructions nautiques**. Nous utilisons pour cela un réseau de neurones récurrents que nous construisons et entraînons en utilisant le framework **Flair** (Akbik et al. (2019)).

## 1 Introduction

Le groupe de travail TextMine a pour but de réunir des chercheurs et chercheuses sur la thématique large de la fouille de texte. Le défi TextMine naît d'une problématique spécifique à la fouille de texte (ici la détection d'entités nommées géographiques), la solution est apportée sous forme d'un défi, en mettant à disposition des jeux de données inédits à la communauté scientifique. C'est dans ce cadre que nous participons à l'édition 2024 : le problème est posé par l'Institut national de l'information géographique et forestière (IGN) et le Service hydrographique et océanographique de la Marine (Shom). L'objectif est la **reconnaissance d'entités géographiques dans un corpus des instructions nautiques**. Pour répondre à ce défi, les participants et participantes ont à leur disposition un corpus constitué d'extraits de 15 volumes des instructions nautiques annotés selon trois labels distincts : **name**, pour les noms propres purs ; **geogFeat**, pour les noms communs qui identifient une caractéristique géographique ainsi que **geogName**, pour les noms associés à une caractéristique géographique. Le jeu de donnée est constitué de 66030 tokens et de 18537 labels et chaque token peut avoir jusqu'à deux labels. L'ensemble de ces données est disponibles sur la plateforme Kaggle à ce lien<fnref n="1" />. Pour évaluer les scores, le modèle doit prédire les entités nommées sur le fichier *test.csv*, qui est non annoté, et les participants et participantes sont départagés en fonction de la micro f-mesure résultante.

## 2 Etat de l'art

La Reconnaissance d'entités nommées, une composante importante de la recherche d'information, a connu une évolution significative au fil des années. Depuis la sortie de *BERT* en 2019, les transformers fine-tunés pour la détection d'entités nommées ont des performances plus que compétitives.

<footnote n="1">1. https://www.kaggle.com/competitions/defi-textmine-2024/data</footnote>
Dans le cadre du défi TextMine, nous avons choisi d'utiliser un réseau de neurones récurrents (RNN) grâce à la bibliothèque **Flair**, ceci pour plusieurs raisons : encore aujourd'hui, les RNN sont toujours beaucoup utilisés pour faire de la détection d'entités nommées comme par exemple dans l'article de Smirnova et Mayr (2023) pour de la reconnaissance d'entités nommées sur des remerciements scientifiques ou encore dans l'article de Suignard et al. (2023) en réponse au défi TextMine 2023 (pour ne citer qu'eux). Dans ces deux cas, le framework **Flair** est utilisé et donne de bons résultats. De plus, en comparaison des transformers les RNN sont moins lourd pour une performance du même ordre sur cette tâche. On peut également noter que le framework **Flair** est encore maintenu : la dernière contribution apportée date de décembre 2023 contre décembre 2019 pour le projet **BERT-NER**<fnref n="2" />.

En comparant avec d'autres framework fréquemment utilisés pour faire de la détection d'entités nommées, cet article de Vychegzhanin et Kotelnikov (2019) montre que **Flair** obtient souvent des meilleurs f-mesure.

L'ensemble de ces raisons ainsi que nos expériences passées nous ont montré que **Flair** est un framework adapté pour répondre à ce défi, pour ses performances ainsi que pour sa fiabilité. Le framework **Flair** est entièrement disponible sur GitHub, à ce lien<fnref n="3" />.

# 3 Les données d'entraînement

## 3.1 Métriques sur les labels

Le jeu de données d'entrainement compte 39857 tokens, et chaque token peut avoir entre 0 et 2 étiquettes. Le tableau 1 la répartition des différents labels possibles. Nous pouvons observer que les classes sont déséquilibrées : il y a 41 fois plus de tokens dont le label est **aucun** que de token dont le label est **geogName**. Nous avons choisi de ne pas considérer la classe **aucun** à l'entraînement et d'attribuer ce label aux tokens n'en portant pas d'autres. En plus de régler le problème de déséquilibre entre les classes, ce procédé est naturel au vu de la signification logique du label.

<table><caption>TAB. 1 – Répartition des différentes étiquettes possibles dans le jeu d'entrainement train_2.csv.</caption><thead><tr><td>Labels</td><td>nombres d'occurence</td><td>fréquence d'occurence</td></tr></thead><tbody><tr><td>aucun</td><td>32663</td><td>0.82</td></tr><tr><td>geogFeat</td><td>2704</td><td>0.07</td></tr><tr><td>geogName name</td><td>2117</td><td>0.05</td></tr><tr><td>geogFeat geogName</td><td>1463</td><td>0.04</td></tr><tr><td>geogName</td><td>910</td><td>0.02</td></tr><tr><td>geogFeat name</td><td>0</td><td>0</td></tr><tr><td>name</td><td>0</td><td>0</td></tr></tbody></table>

Après analyse des données, seules quatre étiquettes se retrouvent dans les données d'entraînement sur les six possibles au départ. Le label **geogFeat name** n'est pas possible à trouver,

<footnote n="2">2. https://github.com/kamalkraj/BERT-NER</footnote>

<footnote n="3">3. https://github.com/flairNLP/flair</footnote>
étant donné que **geogFeat** fait référence à des noms communs et **name** à des noms propres. Il est possible que le label **name** se retrouve seul dans les données d'évaluation, mais nous avons choisi de ne pas le détecter pour éviter le bruit et se concentrer uniquement sur des entités nommées géographiques : seul les **name geogName** seront détectés.

## 3.2 Formatage des données

Pour une tâche de détection d'entités nommées et sous version 0.10 (dernière version documentée en date de juin 2023), l'utilisation du framework **Flair** nécessite une structure particulière (voir Akbik et al. (2019))

Les règles de formatage sont les suivantes :

1. Trois fichiers textes sont constitués : *train.txt*, *test.txt* et *dev.txt*.

2. Une ligne est constituée d'un unique token, et de son label, séparés par un espace ou une tabulation.

3. Une ligne vide sépare chaque phrase.

Le fichier *train.txt* contient les données d'entraînement. Après chaque époque, nous calculons la f-mesure sur un ensemble de données *dev.txt* et enfin à la fin de l'entraînement nous calculons la f-mesure ou toute autre métrique de qualité sur le corpus *test.txt*. Nous avons choisi une répartition assez usuelle des données à notre disposition : 0.7 / 0.15 / 0.15. La répartition entre les différents fichiers se fait aléatoirement : chaque phrase a une probabilité de 0.7 d'être dans le fichier *train.txt*, de 0.15 d'être dans le fichier *dev.txt* et le reste dans les données constituent le fichier *test.txt*.

# 4 Entraînement du modèle et utilisation de Flair

En adéquation avec la feuille de route du **CNRS** pour la science ouverte, nous mettons à disposition le code utilisé pour l'entraînement à ce lien<fnref n="4" />.

## 4.1 L'embedding

Nous avons choisi d'utiliser un embedding contextuel de dimension 300, suggéré dans cet article Akbik et al. (2018) par **Flair** pour la majorité des cas d'usages : on utilise la fonction *StackedEmbeddings* de **Flair** pour combiner<fnref n="5" /> un embedding **FastText** (Bojanowski et al. (2016)), un embedding contextuel prenant comme contexte le token juste après et un embedding contextuel prenant comme contexte le token juste avant. Chacun de ces embedding a été entraîné sur des données issues du Wikipédia français.

Dans notre optique de modèle léger, nous avons privilégié cet embedding contextuel plutôt qu'un embedding type transformers. En effet les embedding contextuels suggérés par **Flair** ne sont pas significativement différents pour des cas d'usages similaires d'après l'article de Brunner et al. (2020).

<footnote n="4">4. https://github.com/Luc-Ank/textmine-2023</footnote>

<footnote n="5">5. Ces trois Embedding sont nommés dans le code respectivement *FlairEmbeddings('fr')*, *FlairEmbeddings('fr-forward')* et *FlairEmbeddings('fr-backward')*</footnote>
## 4.2 Structure du modèle

Le réseau de neurone récurrent utilisé par notre modèle comporte trois couche :

- Une couche de reprojection de l'embedding. Dans notre cas la dimension n'est pas réduite et permet un simple ajustement des poids par un modèle linéaire lors de l'apprentissage.

- Deux couches type LSTM, chacune ayant un *word dropout* de 0.05.

## 4.3 Paramètres de l'entraînement

Pour information, les paramètres utilisés lors de l'entraînement du modèle sont écrits dans le tableau 2. Les paramètres non précisés sont les paramètres par défaut de **Flair** en version **0.10**. Avec le framework **Flair**, si une époque n'est pas une amélioration significative (sur un jeu distinct de l'entraînement), les poids du réseau sont inchangés. Nous souhaitions un grand *learning rate*, un grand nombre d'époque et une grande *patience* pour permettre le plus d'occurences possibles et éviter au maximum toute convergence de la loss vers un minimum local.

<table><caption>TAB. 2 – Exemple de données d'entrainements pour utiliser **Flair**.</caption><thead><tr><td>Paramètre</td><td>Valeur</td><td>Explicitation</td></tr></thead><tbody><tr><td>learning_rate</td><td>0.2</td><td>qu'on abrègera <i>lr</i></td></tr><tr><td>patience</td><td>10</td><td>réduction du <i>lr</i> après 10 mauvaises époques</td></tr><tr><td>mini_batch_size</td><td>12</td><td>petit batch size avec des LSTM</td></tr><tr><td>min_learning_rate</td><td>0.001</td><td>valeur par défaut</td></tr><tr><td>anneal_factor</td><td>0.8</td><td>facteur de réduction du <i>lr</i></td></tr></tbody></table>

# 5 Résultats

Afin d'optimiser les premiers résultats, nous avons utilisé la possibilité de faire de nombreuses soumissions à **Kaggle** pour augmenter artificiellement les données d'entraînement : nous n'avons alors plus besoin de fichier *test.txt*, la f-mesure obtenue lors de la soumission faisant office de résultat. Ainsi, les données présentes dans ce fichier peuvent être injectées dans les données d'entraînement : 0.85 pour le fichier *train.txt* et 0.15 pour le fichier *dev.txt*.

La figure 1 montre l'évolution<fnref n="6" /> de la loss calculée après chaque époque, calculée sur les données issues du fichier *dev.txt*. L'allure de la courbe ne montre ni un sur-apprentissage ni un sous-apprentissage.

La meilleure micro f-mesure obtenue sur le fichier *test.tsv* est de **0.97925**. Nous détaillons les métriques pour chaque label dans le tableau 3. Cependant, ces métriques sont calculées sur le jeu de donnée *dev.txt* étant donné que nous avons pris le parti d'utiliser le jeu de donnée d'évaluation du concours TextMine 2024, *test.tsv* comme unique évaluation de la qualité du modèle.

<footnote n="6">6. Pour modéliser des données discrètes par une courbe, nous avons utilisé une interpolation ce qui explique que la loss semble remonter légèrement lors de certaines époques, ce qui n'est pas possible avec la méthode employée.</footnote>
<figure><img src="image_27.png" /><figcaption>FIG. 1 – Evolution de la loss lors de l'entrainement du modèle pour le fichier 'dev.txt' en fonction des époques.</figcaption></figure>

<table><caption>TAB. 3 – Métriques obtenues sur le fichier "dev.txt" pour chacun des labels à la fin de l'entrainement</caption><thead><tr><td>Labels</td><td>precision</td><td>recall</td><td>f1-score</td></tr></thead><tbody><tr><td>geogFeat</td><td>0.8986</td><td>0.9538</td><td>0.9254</td></tr><tr><td>geogName name</td><td>0.9737</td><td>1.0000</td><td>0.9867</td></tr><tr><td>geogFeat geogName</td><td>1.0000</td><td>0.8333</td><td>0.9091</td></tr><tr><td>geogName</td><td>1.0000</td><td>0.8667</td><td>0.9286</td></tr></tbody></table>

# 6 Conclusion et perspective

En conclusion, les résultats de notre modèle sont plus que satisfaisant et ils peuvent être aisés reproductus ou modifiés en utilisant le code à disposition sur **Github** et les données sur **Kaggle**, même sur un ordinateur basique.

Nous n'avons pas beaucoup exploré la question de la dimension de l'embedding : en partant du principe qu'il y a moins de vocabulaire dans des corpus d'instructions nautique, ou tout autre corpus spécialisé, que dans Wikipédia il pourrait être intéressant de réduire la dimension sur laquelle l'embedding est projeté. Il peut être également intéressant de comparer ces résultats avec ceux que nous aurions pu obtenir en utilisant un LLM pour faire l'embedding, voir en utilisant la structure totale d'un modèle type transformers pour réaliser ce défic.
Références

Akbik, A., T. Bergmann, D. Blythe, K. Rasul, S. Schweter, et R. Vollgraf (2019). FLAIR : An easy-to-use framework for state-of-the-art NLP. In *NAACL 2019, 2019 Annual Conference of the North American Chapter of the Association for Computational Linguistics (Demonstrations)*, pp. 54–59.

Akbik, A., D. Blythe, et R. Vollgraf (2018). Contextual string embeddings for sequence labeling. In *COLING 2018, 27th International Conference on Computational Linguistics*, pp. 1638–1649.

Bojanowski, P., E. Grave, A. Joulin, et T. Mikolov (2016). Enriching word vectors with sub-word information. *arXiv preprint arXiv:1607.04606*.

Brunner, A., N. D. T. Tu, L. Weimer, et F. Jannidis (2020). To bert or not to bert - comparing contextual embeddings in a deep learning architecture for the automatic recognition of four types of speech, thought and writing representation. In *SwissText/KONVENS*.

Guille, A. (2023). Défi textmine 2024.

Smirnova, N. et P. Mayr (2023). Embedding models for supervised automatic extraction and classification of named entities in scientific acknowledgements. *Scientometrics*, 1–25.

Suignard, P., L. Hassani, et M. Bothua (EasyChair, 2023). Participation d'edf rd au défi textmine 2023 : Reconnaissance d'entités d'intérêts dans les signatures d'e-mails. *EasyChair Preprint no. 10098*.

Vychegzhanin, S. et E. Kotelnikov (2019). Comparison of named entity recognition tools applied to news articles. pp. 72–77.

Summary

This article presents the methodology we used for the TextMine 2024 challenge. The objective is the **Recognition of geographical entities in a corpus of nautical instructions**. We built and trained a RNN with the **Flair** framework.
# TETIS @ Challenge TextMine 2024 : "Reconnaissance d'entités géographiques dans un corpus des Instructions nautiques"

Rémy Decoupes*,** Roberto Interdonato*,***

Rodrique Kafando*,** Mathieu Roche*,*** Mehtab Alam Syed *,*** Maguelonne

Teisseire*,** Sarah Valentin*,***

*TETIS, Univ. Montpellier, AgroParisTech, CIRAD, CNRS, INRAE, Montpellier 34090, France

**INRAE, F-34398 Montpellier, France

***CIRAD, F-34398 Montpellier, France

## 1 Introduction

Notre équipe, issue de l'unité TETIS (Territoires, environnement, télédétection et information spatiale), s'intéresse à différents tâches du domaine du Traitement Automatique du Langage Naturel (TALN) en se concentrant sur les problématiques associées à l'information spatiale. La reconnaissance des entités spatiales dans les données textuelles représente une étape importante dans la majorité des chaînes de traitements. Aussi, les données relatives à l'information spatiale nécessitent une attention particulière. Par exemple, nos travaux proposent (i) des méthodes d'extraction d'information spatiale à partir de données non standards (Zenasni et al., 2018), (ii) des méthodes et outils de geocoding et désambiguïsation d'entités spatiales (Syed et al., 2023; Kafando et al., 2023), (iii) des algorithmes d'augmentation de données fondés sur l'information géographique pour l'entraînement de modèles de type Transformers (Decoupes et al., 2023).

La participation de notre équipe TETIS à ce challenge est dans la continuité de ces travaux. Nous résumons, dans la section suivante, notre approche et mettons à disposition nos codes<fnref n="1" /> et modèle<fnref n="2" />.

## 2 Approche

L'approche a consisté à comparer différents modèles pré-entraînés ajustés sur les données du challenge. Afin de commenter les différents résultats, nous présentons la distribution du jeu de données.

<footnote n="1">1. Dépôt logiciel: https://github.com/tetis-nlp/tetis-challenge_textmine_2024</footnote>

<footnote n="2">2. HuggingFace hub: https://huggingface.co/rdecoupes/tetis-textmine-2024-camembert-large-based</footnote>
## 2.1 Données d'apprentissage

Le jeu de données d'apprentissage est extrêmement déséquilibré (Figure 1) : les exemples associés à des labels géographiques (geogFeat, geogName, name GeogName et GeogFeat GeogName) ne représentent que 18% (n=7194/39857) des données labellisées.

<figure><img src="image_28.png" /><figcaption>FIG. 1 – Distribution du nombre d'exemples par classe dans le jeu de données d'entraînement</figcaption></figure>

La classe geogFeat se distingue des autres par l'absence de noms propres. En effet, les mots ou groupes de mots annotés avec ce label désignent une caractéristique géographique sans nom propre comme phare ou port.

## 2.2 Méthodes et résultats

Dans un premier temps, nous avons ré-entraîné un modèle en langue française proposé par la librairie spaCy (pipeline *fr core news lg*<fnref n="3" />). Le micro F1-score sur le jeu de données de validation (20 % du jeu de données mis à disposition, en utilisant l'échelle de la phrase) et le jeu de données calculé par la plateforme Kaggle est de 0.950 et de 0.927, respectivement. Ceci a constitué notre base de référence.

Notre deuxième approche a visé à ré-ajuster des modèles de type Transformers pré-entraînés (fine-tuning en anglais). Nous avons comparé trois modèles (Figure 2) : deux modèles en langue française (CamemBERT-base et CamemBERT-large) et un modèle multi-langues (XLM-RoBERTa). Sans optimisation des hyperparamètres, CamemBERT-large offre, sur le jeu de

<footnote n="3">3. https://github.com/explosion/spacy-models/releases/tag/fr_core_news_lg-3.7.0</footnote>
données calculé par la plateforme Kaggle, les meilleurs résultats. Nous avons ensuite fait varier certains hyperparamètres tels que les tailles de batch d'entraînement (batch size), le taux d'apprentissage (learning rate) et le nombre d'epochs (epochs) sur plusieurs entraînements différents. La meilleure combinaison d'hyperparamètres sur le jeu de données de validation est : batch size = 16, learning rate = 1e-05, epochs = 10, alors que pour les données calculées par la plateforme Kaggle, la meilleure combinaison est : batch size = 8, learning rate = 2e-05, epochs = 10. Nous avons, cependant, constaté une grande variabilité entre deux entraînements ayant des hyperparamètres identiques (Figure 2).

<figure><img src="image_29.png" /><figcaption>FIG. 2 – Comparaison des F1-score pendant l'entraînement des 3 modèles avec différents hyperparamètres. Les traces sous forme d'enveloppe correspondent aux écarts types des différents entraînements ayant des hyperparamètres identiques. La règle de nommage est : le nom du modèle pré-entraîné, le batch size, le learning rate et le nombre epochs</figcaption></figure>

Sur les données de validation, i.e. 20% du jeu de données mis à disposition, les performances du modèle issu du modèle spaCy sont très inégales : la classe *aucun* obtient le meilleur F1-score (0.978), tandis que le F1-score des autres classes ne dépassent pas 0.877 (Tableau 1). Ces performances modérées s'expliquent par une confusion des instances géographiques avec la classe *aucun*, ce qui diminue leur rappel (Figure 3). La classe *geogFeat*, qui obtient le score le plus bas, souffre également d'un manque de précision.

Les modèles de type transformers, bien que moins performant pour la classe *aucun*, obtiennent de meilleurs résultats pour les classes géographiques. Cependant ils rencontrent également des difficultés avec la classe *geogFeat* comme illustré par le Tableau 1. Cette classe est complexe à distinguer de *aucun* (Figure 4). Les modèles détectent plus efficacement les classes contenant un nom propre i.e. *geogName*, *name geogName* et *geogFeat_geogName*.

<table><caption>TAB. 1 – Comparaison des F1-scores par classe en fonction du modèle pré-entraîné</caption><thead><tr><th>Modèle</th><th>moyenne pondérée micro</th><th>aucun</th><th>geogFeat</th><th>name geogName</th><th>geogFeat geogName</th><th>geogName</th></tr></thead><tbody><tr><td>spaCy</td><td>0.950</td><td>0.978</td><td>0.779</td><td>0.877</td><td>0.823</td><td>0.804</td></tr><tr><td>xlm-roberta-large</td><td>0.926</td><td>0.927</td><td>0.914</td><td>0.932</td><td>0.931</td><td>0.914</td></tr><tr><td>camembert-large</td><td>0.950</td><td>0.947</td><td>0.915</td><td>0.969</td><td>0.980</td><td>0.971</td></tr></tbody></table>
<figure><img src="image_30.png" /><figcaption>FIG. 3 – Matrice de confusion obtenue à partir du modèle spaCy</figcaption></figure>

Références

Decoupes, R., M. Roche, et M. Teisseire (2023). GeoNLPlify : A spatial data augmentation enhancing text classification for crisis monitoring. *Intelligent Data Analysis*, 1–25.

Kafando, R., R. Decoupes, M. Roche, et M. Teisseire (2023). SNEToolkit : Spatial named entities disambiguation toolkit. *SoftwareX* **23**, 101480.

Syed, M. A., E. Arsevska, M. Roche, et M. Teisseire (2023). GeospatRE : extraction and geocoding of spatial relation entities in textual documents. *Cartography and Geographic Information Science*, 1–16.

Zenasni, S., E. Kergosien, M. Roche, et M. Teisseire (2018). Spatial information extraction from short messages. *Expert Systems with Applications* **95**, 351–367.
<figure><img src="image_31.png" /><figcaption>FIG. 4 – Matrice de confusion obtenue à partir du modèle camembert-large</figcaption></figure>
<figure><img src="image_32.png" /></figure>
# Index

## A

<table><tr><td>Abadie, Nathalie</td><td>75, 88</td></tr><tr><td>Ahmia, Oussama</td><td>107</td></tr><tr><td>Alam Syed, Mehtab</td><td>119</td></tr><tr><td>Anki, Lucas</td><td>112</td></tr><tr><td>Armary, Pauline</td><td>95</td></tr><tr><td>Atanassova, Iana</td><td>51</td></tr><tr><td>Auzoux, Sandrine</td><td>39</td></tr></table>

## B

<table><tr><td>Béchet, Nicolas</td><td>107</td></tr><tr><td>Bazin, Alexandre</td><td>1</td></tr><tr><td>Ben Sassi, Imen</td><td>1</td></tr></table>

## C

<table><tr><td>Cabanac, Guillaume</td><td>27</td></tr><tr><td>Cao, Danrun</td><td>107</td></tr><tr><td>Chetouani, Mohamed</td><td>52</td></tr><tr><td>Clausse, Alexandre</td><td>27</td></tr><tr><td>Cousot, Kevin</td><td>13</td></tr><tr><td>Cuxac, Pascal</td><td>27, 88</td></tr></table>

## D

<table><tr><td>Decoupes, Rémy</td><td>119</td></tr><tr><td>Duch, Cécile</td><td>75</td></tr></table>

## E

<table><tr><td>El-Vaigh, Cheikh-Brahim</td><td>95</td></tr></table>

## G

<table><tr><td>Gaillard, Léo</td><td>112</td></tr><tr><td>Guenoue, Hani</td><td>1</td></tr><tr><td>Guille, Adrien</td><td>88</td></tr><tr><td>Gutehrlé, Nicolas</td><td>99</td></tr></table>

## H

<table><tr><td>Huchard, Marianne</td><td>1</td></tr></table>

## I

<table><tr><td>Interdonato, Roberto</td><td>119</td></tr></table>

## J

<table><tr><td>Jonquet, Clément</td><td>39</td></tr></table>

## K

<table><tr><td>Kafando, Rodrique</td><td>119</td></tr><tr><td>Kergosien, Eric</td><td>75</td></tr></table>

## L

<table><tr><td>Labbé, Cyril</td><td>27</td></tr><tr><td>Labbani Narsis, Ouassila</td><td>95</td></tr><tr><td>Lafourcade, Mathieu</td><td>1</td></tr><tr><td>Lopez, Cédric</td><td>88</td></tr></table>

## M

<table><tr><td>Mair Rawsthorne, Helen</td><td>75, 88</td></tr><tr><td>Marteau, Pierre-François</td><td>107</td></tr><tr><td>Mechhour, Oussama</td><td>39</td></tr><tr><td>Mirzapour, Mehdi</td><td>13</td></tr><tr><td>Momtaz, Shaghayegh</td><td>13</td></tr></table>
N

Nicolle, Christophe .................... 95

R

Revol, Justine ......................... 112

Roche, Mathieu ....................... 39, 119

Rodrigues, Christophe .................... 55

S

Sallantin, Jean ......................... 1

Saux, Eric ................................ 75

Suignard, Philippe .................... 67

T

Teisseire, Maguelonne .................... 119

V

Valentin, Sarah ......................... 119

Z

Zahhar, Saber ......................... 55