<figure><img src="image_1.png" /></figure>

HAL
open science

# Participation de l'équipe Défense au défi TextMine'25 en extraction de relations dans des bulletins de renseignement

Nicolas Diniz, Nihel Kooli, Lucie Chasseur, Pauline Soutrenon

► To cite this version:

Nicolas Diniz, Nihel Kooli, Lucie Chasseur, Pauline Soutrenon. Participation de l'équipe Défense au défi TextMine'25 en extraction de relations dans des bulletins de renseignement. TextMine 2025 - Atelier du Groupe de travail sur la fouille de texte, Jan 2025, Strasbourg, France. hal-04974411

HAL Id: hal-04974411

https://hal.science/hal-04974411v1

Submitted on 3 Mar 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Participation de l'équipe Défense au défi
TextMine'25 en extraction de relations dans des
bulletins de renseignement

Nicolas Diniz*,
Nihel Kooli*,
Lucie Chasseur**,
Pauline Soutrenon**

*prénom.nom@def.gouv.fr,

**prénom.nom@inria.fr

**Résumé.** L'extraction d'informations, en particulier l'extraction de relations dans un contexte spécifique, reste un défi malgré les progrès réalisés dans le domaine du Traitement Automatique des Langues (TAL). Cet article s'inscrit dans le cadre du défi TextMine'25¹, proposé lors de la conférence EGC 2025, qui porte sur l'extraction de relations entre entités et événements d'intérêt militaire dans des rapports de renseignement simulés. Nous y présentons une analyse approfondie du corpus utilisé, ainsi qu'une méthode d'augmentation des données basée sur des modèles de langage de grande taille. Cette approche, basée sur le transformeur pré-appris multilingue mDeBERTa, vise à enrichir les annotations et diversifier les exemples pour l'entraînement des modèles.

# 1 Introduction

L'extraction d'informations, en particulier la tâche d'extraction de relations d'intérêt dans des contextes spécifiques, représente un défi persistant dans le domaine du Traitement Automatique des Langues (TAL). Bien que les récents progrès en réseaux neuronaux profonds, tels que BERT (Devlin et al., 2019) ou GPT (Brown et al., 2020), aient considérablement amélioré les performances des modèles sur diverses tâches linquistiques, leur application à des domaines spécialisés reste complexe. La sémantique des relations et la précision contextuelle requises dans ces contextes soulèvent encore des questions non résolues.

Parmi les principaux obstacles figurent l'interprétation de textes ambigus, l'identification de relations implicites, et la gestion de données limitées, souvent observées dans des domaines sensibles comme le renseignement militaire. Dans ces contextes, où la qualité et la contextualisation des informations extraites sont cruciales, des avancées méthodologiques spécifiques s'avèrent nécessaires.

1. https://www.kaggle.com/competitions/defi-text-mine-2025/overview
Le défi TextMine'25, organisé dans le cadre de la conférence Extraction et Gestion des Connaissances (EGC) 2025, illustre parfaitement ces problématiques. Il vise à évaluer des approches d'extraction de relations entre entités et événements dans des rapports de renseignement factices. Ce défi, à l'intersection du TAL et du renseignement d'intéret militaire, met en lumière l'importance de modèles capables de s'adapter aux particularités des textes spécialisés tout en garantissant une précision optimale.

Pour relever ces enjeux, la disponibilité d'ensembles de données représentatifs et annotés est essentielle. L'émergence des modèles de langage de grande taille (*Large Language Models*, LLM) offre de nouvelles perspectives, notamment pour la génération de données annotées supplémentaires et diversifiées. Ces modèles permettent non seulement d'améliorer l'apprentissage, mais aussi de concevoir des approches innovantes pour renforcer la robustesse et la généralisation des systèmes d'extraction dans des contextes complexes.

Dans cet article, nous analysons en détail le corpus utilisé pour cette tâche et proposons une stratégie d'augmentation de données basée sur les LLM. Nous évaluons ensuite les performances des modèles entraînés avec et sans augmentation de données, en explorant l'impact de cette méthode sur la précision et la diversité des exemples d'entraînement. Les résultats obtenus mettent en lumière les avantages de notre approche et ouvrent des perspectives prometteuses pour des applications dans des domaines spécialisés.

Les codes sources développés dans le cadre du défi sont publiquement disponibles sur github<fnref n="2" />.

# 2 Étude de corpus

## 2.1 Données à disposition

L'objectif principal du défi était de proposer une méthode d'extraction de relations entre des éléments textuels. Pour mener à bien cette tâche, un *dataset* composé de 800 documents factices a été élaboré et annoté manuellement. Au total, le *dataset* comprend 40 types d'entités distincts, 15 types d'attributs et 37 types de relations.

## 2.2 Distribution du corpus

Dans un premier temps, nous avons examiné la répartition des entités et des relations dans le corpus d'entraînement. Une observation initiale met en évidence un déséquilibre marqué entre les catégories, en particulier pour la relation *IS LOCATED IN*, qui est massivement sur-représentée par rapport aux autres types de relations.

<footnote n="2">2. https://github.com/DinizNicolas/defi_textmine_2025</footnote>
<figure><img src="image_3.png" /><figcaption>FIG. 1 – Répartition des relations.</figcaption></figure>

Cependant, la distribution des relations influence directement la performance des modèles, notamment dans des contextes avec des déséquilibres importants. Une annota-
tion équilibrée et détaillée permet non seulement de former des modèles plus robustes, mais aussi de répondre à des cas spécifiques comme les relations rares ou les tâches inter-dépendantes. (Delaunay et al., 2023) (Bassignana et Plank, 2022)

Afin donc d'évaluer l'impact de ce déséquilibre sur la performance, une première
expérimentation a été réalisée sans modification du corpus. Les résultats montrent que
les relations ayant moins de 100 occurrences affichent une micro-F1 faible ou nulle, ce
qui indique un effet direct du déséquilibre des données sur les performances de ces ca-
tégories. De plus, malgré une fréquence élevée de certaines relations, les performances
demeurent faibles. Des ajustements dans la conception du corpus et la stratégie de
modélisation sont donc nécessaires pour améliorer les performances.

En outre, nous avons pu remarquer que certaines relations, tableau 1 et parfois
certaines entités, tableau 2, avaient une annotation différente dans le guide et dans les
données ce qui a conduit à une absence de représentation pour ces catégories. Voici une
liste non exhaustive de ce que nous avons pu remarquer et donc adapter :
<table><caption>TAB. 1 – *Relations différentes entre le guide et les données.*</caption><thead><tr><td>Guide</td><td>Données</td></tr></thead><tbody><tr><td>death number</td><td>deaths number</td></tr><tr><td>created in</td><td>was created in</td></tr><tr><td>dissolved in</td><td>was dissolved in</td></tr></tbody></table>

<table><caption>TAB. 2 – *Entités différentes entre le guide et les données.*</caption><thead><tr><td>Guide</td><td>Données</td></tr></thead><tbody><tr><td>hooliganism trouble-making</td><td>hooliganism troublemaking</td></tr><tr><td>criminal</td><td>terrorist or criminal</td></tr><tr><td>non governmental organization</td><td>non governmental organisation</td></tr><tr><td>non military organization</td><td>non military organisation</td></tr><tr><td>material</td><td>materiel</td></tr><tr><td>intergovernmental organization</td><td>intergovernmental organisation</td></tr><tr><td>coup d'état</td><td>coup d'état</td></tr><tr><td>military organization</td><td>military organisation</td></tr></tbody></table>

## 2.3 Caractéristiques des relations

Les relations sont annotées comme suit : [entité1,relationA,entité2]. On notera le couple d'entités : entité1-entité2. Les entités 1 et 2 pourront être référencé par "entité", "attribut" ou leur label.

Les relations présentent des caractéristiques différentes. Notamment pour les relations entre une entité et un attribut, et les relations entre deux entités. On remarque tableau 6 que les couples entité-entité peuvent avoir plusieurs relations simultanément. Tandis que les couples entité-attribut ne peuvent avoir qu'une seule relation à la fois. Dans la colonne "multiple", lorsqu'il y a 1 ou 2, ce sont des erreurs d'annotations.

Néanmoins, il y a quelques exceptions :

- Pour les couples *EVENT-TIME*, les relations *START_DATE* et *END_DATE* sont possible simultanément.

- Pour les relations *INITIATED*, *HAS_CONSEQUENCE* et *DIED_IN*, il se trouve que le couple entité-EVENT n'a qu'une de ces relations.

- Les deux relations *GENDER* sont entre une entité *PERSON* et elle-même. Dans le corpus un unique genre est possible.

Pour la suite des expérimentations les relations sont séparées en deux groupes. Le groupe des relations de type entité-attribut, avec les deux relations *GENDER*, et excepté les relations *START_DATE* et *END_DATE*. Le reste des relations forment le deuxième groupe. Les relations *INITIATED*, *HAS_CONSEQUENCE* et *DIED_IN* sont dans le deuxième groupe puisqu'il semble préférable de garder les relations autour des *EVENT* dans le même groupe.
# 3 Augmentation des données à l'aide de LLM

Pour remédier au déséquilibre, nous avons choisi de recourir à l'augmentation de données à l'aide de modèles de langage de grande taille (ou *Large Language Model* en anglais, LLM). En effet, l'intégration de données synthétiques générées par LLM constitue une approche prometteuse pour rééquilibrer les corpus utilisés en extraction de relations sémantiques. Les corpus annotés manuellement présentent souvent des déséquilibres significatifs, avec des relations fréquentes sur-représentées et des relations rares insuffisamment couvertes, ce qui limite la capacité des modèles d'apprentissage à généraliser efficacement. Les LLM peuvent être exploités pour générer des exemples supplémentaires de relations sous-représentées en s'appuyant sur leurs vastes connaissances encodées et leur capacité à produire du texte contextuellement cohérent (Armingaud et al., 2024). Ces données augmentées permettent d'atténuer les biais dans les *datasets* tout en diversifiant les contextes relationnels, renforçant ainsi la robustesse des modèles formés. De plus, l'utilisation de ces approches réduit le coût d'annotation manuel tout en maintenant une qualité satisfaisante des données, à condition d'établir des filtres stricts pour vérifier la validité des exemples générés.

Nous avons donc choisi d'augmenter le nombre d'exemples de relations pour certaines catégories qui présentaient un score nul de micro-F1 après la première exécution. Ces catégories spécifiques sont : WAS_DISSOLVED_IN, WAS_CREATED_IN, CREATED, DIED_IN, IS_COOPERATING_WITH, et IS_BORN_IN.

En générant des exemples supplémentaires pour ces relations sous-représentées, nous visons à améliorer leur couverture dans le corpus et, par conséquent, à renforcer la performance des modèles d'apprentissage sur ces classes.

## 3.1 Choix du LLM

Nous avons utilisé le modèle Llama 3.2 3B via la plateforme Ollama<fnref n="3" /> pour effectuer l'augmentation de données. Ce modèle, caractérisé par sa taille réduite et ses faibles exigences en termes de ressources computationnelles, permet d'obtenir de bonnes performances tout en restant efficace en termes de consommation de mémoire et de puissance de calcul.

## 3.2 Stratégie de formulation du prompt

Différentes configurations de *prompts* ont été testées pour optimiser et stabiliser les résultats. La figure 3 illustre celui retenu, avec les contraintes imposées au modèle décrites ci-après.

Nous introduisons en premier lieu une restriction sur la taille des phrases générées (100 mots maximum) afin de réduire les risques d'erreur du modèle. Cette limitation assure également une meilleure uniformité des données générées et permet de faciliter leur traitement par la suite.

<footnote n="3">3. https://github.com/ollama/ollama</footnote>
Nous définissons ensuite le format attendu (JSON) avec un identifiant, un texte, des entités et une relation. Nous fournissons un exemple de manière à ce que le modèle puisse reproduire le format attendu.

Enfin, nous précisons que seule la phrase générée, sans explications ni introduction, doit être produite. En l'absence de cette précision dans le *prompt*, le modèle Llama 3.2 a tendance à inclure des explications sur la phrase générée, ce qui complique l'exploitation de ces phrases.

Afin de clarifier la relation attendue, nous fournissons une brève définition au début du *prompt* (par exemple : "la date de naissance d'une personne civile" pour la relation *IS_BORN_IN*). Nous incluons également des explications concernant les annotations attendues à la fin du *prompt*. L'objectif principal de ces explications est de s'assurer que les entités soient effectivement présentes dans le texte et qu'une relation entre elles existe.

Ce *prompt* a été appliqué à l'ensemble des 6 catégories en modifiant à chaque fois la définition de la relation au début du *prompt*, l'exemple JSON et les explications sur l'exemple à la fin du *prompt*. Nous avons opté pour des exemples courts pour chaque catégorie afin de simplifier les consignes au maximum et ainsi limiter les risques d'erreurs.

## 3.3 Problématiques liées à la génération de texte

Au cours de nos différentes expérimentations sur l'augmentation de données, nous nous sommes confrontés à des problématiques de génération de texte. Parfois, certaines phrases sont redondantes voire même identiques (la même phrase générée sur plus de 1 000 exemples avec les mêmes entités). Il a donc parfois été nécessaire de relancer plusieurs fois le *prompt* et même de redémarrer le modèle.

Malgré les contraintes spécifiées dans le *prompt* (voir la sous-section précédente), les sorties du modèle ne correspondaient pas toujours au format attendu. En effet, nous avons rencontré des problèmes récurrents d'encodage, de format (principalement l'ajout de caractères comme des *backslashes*, des nouvelles lignes, des espaces ou encore des tabulations) et de contenu. Au niveau du contenu, les relations ne portaient pas toujours le label attendu et les entités fournies par le modèle n'étaient pas toujours présentes dans la phrase générée.

Enfin, le modèle semble présenter des limitations quant à la détermination précise des positions de début (*start*) et de fin (*end*) des entités. Les informations générées sont souvent peu fiables, avec des erreurs fréquentes dans les positions indiquées. Ce phénomène est fréquemment observé avec les LLM, qui, bien qu'efficaces pour des tâches linguistiques générales, peinent à gérer des aspects plus structurés et précis du texte, tels que la localisation exacte d'entités.

Pour pallier ces problèmes et éviter l'introduction de bruit dans notre *dataset* d'entraînement, nous avons mis en place un processus de post-traitement des sorties du modèle, que nous décrivons ci-après.
## 3.4 Post-traitement des réponses du LLM

Les phrases générées par le LLM n'étant pas toujours de qualité constante, nous avons mis en place un post-traitement automatique afin de nettoyer ou d'écarter les sorties générées par le modèle qui comportaient des erreurs. Ce traitement automatique nous a permis de :

- corriger les problèmes d'encodage lorsque cela était nécessaire;

- vérifier et corriger le format des données (par exemple, s'assurer que la sortie est bien sous format JSON sans espaces ou tabulations additionnels et si ce n'est pas le cas un dictionnaire correctement formé est re-créé automatiquement);

- vérifier l'exactitude des données (par exemple, vérifier si les entités fournies par le modèle sont bien présentes dans le texte généré et si ce n'est pas le cas la sortie est écartée);

- corriger le label de la relation si celui-ci est traduit dans une autre langue (par exemple, EST_COOPERANT_AVEC au lieu de IS_COPPERATING_WITH);

- corriger les positions de début (start) et de fin (end) des entités.

Ces différentes opérations permettent d'obtenir des données plus fiables et mieux structurées, facilitant ainsi leur utilisation dans le processus d'entraînement.

## 3.5 Résultats

Nous présentons dans le tableau 3, les résultats de l'augmentation de données sur les 6 catégories : WAS_DISSOLVED_IN, WAS_CREATED_IN, CREATED, DIED_IN, IS_COOPERATING_WITH, IS_BORN_IN. Malgré le post-traitement automatisé décrit précédemment, nous observons une perte significative des données : seules 37 % des phrases générées par le LLM sont retenues pour l'ajout au dataset d'entraînement (soit 3 210 nouvelles phrases avec leur annotation).

Parmi les 6 catégories, seule la catégorie IS_BORN_IN semble très bien fonctionner, puisque 84 % des phrases générées ont été retenues.

<table><caption>TAB. 3 – Résultats de l'augmentation de données sur les 6 catégories.</caption><thead><tr><th></th><th>Nombre de<br>phrases générées</th><th>Nombre de<br>phrases retenues</th><th>Pourcentage de<br>phrases retenues</th></tr></thead><tbody><tr><td>WAS_DISSOLVED_IN</td><td>1 582</td><td>311</td><td>20 %</td></tr><tr><td>WAS_CREATED_IN</td><td>1 574</td><td>418</td><td>27 %</td></tr><tr><td>CREATED</td><td>1 396</td><td>393</td><td>28 %</td></tr><tr><td>DIED_IN</td><td>1 600</td><td>579</td><td>36 %</td></tr><tr><td>IS_COOPERATING_WITH</td><td>1 571</td><td>615</td><td>39 %</td></tr><tr><td>IS_BORN_IN</td><td>1 069</td><td>894</td><td>84 %</td></tr><tr><td>Total</td><td>8 792</td><td>3 210</td><td>37 %</td></tr></tbody></table>

En outre, nous avons constaté que, malgré un premier post-traitement, certaines données générées restaient incohérentes. Cela a motivé la mise en place d'un nouveau
filtrage plus rigoureux pour garantir la cohérence et la pertinence des données.

Ce processus vise à isoler les relations correspondant à une cible spécifique, par exemple une relation de type `WAS_CREATED_IN`, et à vérifier qu'elles respectent un format attendu. Chaque relation doit contenir exactement trois éléments (id source, type de relation, id cible), et le type de relation doit être correctement spécifié. Si une relation ne respecte pas ces critères, elle est supprimée. Les relations valides sont ensuite utilisées pour identifier et conserver uniquement les entités pertinentes associées à cette relation cible.

Les entités retenues subissent des corrections pour assurer un format homogène, notamment la conversion des identifiants de chaîne de caractères en entiers. Les relations mal formatées ou non pertinentes sont éliminées, et les entités qui ne sont pas associées aux relations cibles sont également supprimées.

Ce tri extrêmement sélectif a entraîné une importante perte de données générées. En effet, près de 84 % des données ont été supprimées après ce filtrage. Le détail des résultats est présenté dans le tableau 4.

<table><caption>TAB. 4 – Résultats après le filtrage sur les 6 catégories.</caption><thead><tr><th></th><th>Nombre de<br>phrases après<br>post-traitement</th><th>Nombre de<br>phrases filtrées</th><th>Pourcentage de<br>phrases filtrées</th></tr></thead><tbody><tr><td>WAS_DISSOLVED_IN</td><td>311</td><td>9</td><td>3 %</td></tr><tr><td>WAS_CREATED_IN</td><td>418</td><td>86</td><td>21 %</td></tr><tr><td>CREATED</td><td>393</td><td>115</td><td>29 %</td></tr><tr><td>DIED_IN</td><td>579</td><td>53</td><td>9 %</td></tr><tr><td>IS_COOPERATING_WITH</td><td>615</td><td>45</td><td>7 %</td></tr><tr><td>IS_BORN_IN</td><td>894</td><td>198</td><td>22 %</td></tr><tr><td>Total</td><td>3 210</td><td>506</td><td>16 %</td></tr></tbody></table>

# 4 Extraction de relations

## 4.1 Méthode proposée pour la classification de relations

Nous avons modélisé le problème d'extraction de relations sous la forme d'une classification de couples d'entités. Dans un premier temps, nous faisons une énumération exhaustive des couples d'entités possibles dans un document. En effet, lors de l'énumération des couples, ces derniers sont filtrés selon le guide des relations fourni dans le cadre du challenge. Seuls les couples pouvant avoir une relation sont gardés. Par exemple, un couple de type EVENT-PLACE peut avoir la relation `STARTED_IN`, il est donc retenu. Cependant, un couple de type PLACE-EVENT n'ayant pas de relation possible est donc rejeté. Dans un second temps les tokens spéciaux `[e1]` et `[e2]` sont insérés, respectivement, autour des mentions des entités 1 et 2. Le label de l'entité est également inséré autour de chaque mention. Cela donne, par exemple, `[e1][CIVILIAN]` Anam Des-
tresse[CIVILIAN][e1]". Lors de l'entraînement, en entrée du modèle, par chaque couple d'entité pouvant avoir une relation, est envoyé le texte entier du document avec les informations insérées dans le texte comme présenté ci-dessus.

Etant donné les différences entre les relations entité-entité et les relations entité-attribut, nous avons fait le choix de mettre en place deux modèles.

Le premier modèle concerne les relations entité-attribut, où pour chaque couple d'entités, il y a une unique relation à prédire. Ainsi, la modélisation du problème est une classification en multi-classe.

Le deuxième modèle, pour les relations entité-entité, doit pouvoir prédire plusieurs relations pour un couple d'entités. Ainsi, la modélisation du problème est une classification en multi-classe et en multi-label.

En effet, nous avons testé plusieurs configurations, celle-ci obtient les meilleurs résultats. Les autres configurations sont :

- Différents niveaux de granularité pour les entités de type ACTOR ou EVENT. Le niveau de granularité le plus bas a été retenu.

- Différentes sections du texte. Seulement les phrases contenant au moins une mention du couple d'entité sont gardées. Le contexte des autres phrases est important. Pour les relations de type entité-attribut, nous avons remarqué que le texte contient au moins une phrase où se trouve au moins une mention de chaque entité du couple. Nous avons essayé de ne garder que cette phrase et avons observé des résultats dégradés.

## 4.2 Résultats et interprétations

Nous avons expérimenté deux architectures de transformeurs pré-appris : un BERT et mDeBERTav3 (He et al., 2021). Les résultats, sur le *dataset* de validation, des *fine-tuning* de mDeBERTa sur les deux groupes sont reportés dans le tableau 5 pour les relations entité-attribut et dans le tableau 7 pour les relations entité-entité. Le tableau 5 montre que mDeBERTa est le plus adapté à la tâche et sera le modèle utilisé pour les entraînements suivants.

Les relations entité-attribut sont des relations simples et sont bien reconnues par le modèle. Cependant plusieurs de ces relations ayant moins de 50 occurrences dans le *dataset* ont un F1-score de 1. Il est probable que le modèle ne soit pas robuste pour ces relations. Notamment pour les relations ayant moins de 20 occurrences qui possèdent entre 2 et 4 exemples dans le *dataset* de validation.

Les relations entité-entité sont plus complexes. Le nombre d'occurrence dans le *dataset* d'entraînement est un facteur de la qualité mais pas uniquement. En effet, les résultats sont très mauvais pour les relations de moins de 100 exemples. Cependant, un nombre d'exemple élevé ne garantit pas de bons résultats. Par exemple, la relation *HAS_CONTROL_OVER* est la deuxième relation la plus représentée avec plus de 4000 occurrences. Pourtant, nous obtenons un F1-score de 0,5.
Concernant l'entraînement avec les données augmentées, nous avons dû l'arrêter avant la fin par faute de temps. Les scores sur la validation sont montrés dans la colonne 2 du tableau 7. Cela explique que les F1-scores soient moins élevés, pour les entités non augmentées, que pour le modèle sans augmentation. Néanmoins, le F1-score des relations augmentées est meilleur avec augmentation des données.

Après la fin du challenge, nous avons relancé un entraînement avec les données augmentées. Bien que les résultats n'apparaissent pas dans les résultats du challenge, il nous semble important de pouvoir conclure sur l'augmentation de données avec un entraînement qui a abouti. Les résultats de cet entraînement se trouvent dans la colonne 3 du tableau 7.

Dans un premier temps, nous observons une augmentation du score F1 sur les relations augmentées entre les colonnes 1 et 3 du tableau 7. Pour les relations *IS_BORN_IN*, *IS_COOPERATING_WITH* et *CREATED*, les scores F1 sont doublés avec l'augmentation de données. Les relations *WAS_CREATED_IN* et *WAS_DISSOLVED_IN* sont maintenant détectées par le modèle. Cependant, la relation *DIED_IN* n'a pas d'augmentation significative du score. Les 53 exemples synthétiques ajoutés n'ont pas suffi à augmenter le score.

Dans un second temps, nous observons des effets de bord avec une baisse du score F1 pour les relations non augmentées ayant moins de 500 occurrences. Il semble que les données augmentées ajoutent un bruit qui dégrade le score des relations avec peu d'occurrences. La relation qui subit le plus cette dégradation est la relation *IS_BORN_ON*. Etant la relation avec le moins d'exemples, seulement 20, le score chute de 0.49 points. Cette baisse de score est due à une augmentation des faux positifs. De plus, on remarque que la relation *IS_BORN_IN* est la relation augmentée dont le score augmente le plus, passant de 0.19 à 0.48. Les deux relations portant sur la naissance d'un individu, il est possible que ces évolutions soient corrélées.

Notre soumission finale au challenge est la concaténation des prédictions de 3 modèles :

- Les relations entité-attribut sont prédites par le modèle dont les résultats sont dans le tableau 5.

- Les relations pour lesquelles nous avons ajouté des données sont prédites par le modèle dont les résultats sont dans la deuxième colonne du tableau 7. C'est le modèle entraîné sur les données augmentées.

- Le reste des relations sont prédites par le modèle dont les résultats sont dans la première colonne du tableau 7. C'est le modèle entraîné sans les données augmentées.
<table><caption>TAB. 5 – F1 score par label pour les relations de type entité-attribut sur le dataset de validation.</caption><thead><tr><th></th><th>bert</th><th>mdeberta</th><th>n train</th></tr></thead><tbody><tr><td>DEATHS_NUMBER</td><td>0,23</td><td><strong>0,79</strong></td><td>75</td></tr><tr><td>HAS Category</td><td>0,97</td><td><strong>0,99</strong></td><td>894</td></tr><tr><td>HAS COLOR</td><td>0,86</td><td><strong>0,90</strong></td><td>91</td></tr><tr><td>HAS_FORHeight</td><td>0,00</td><td><strong>1,00</strong></td><td>12</td></tr><tr><td>HAS_FORLength</td><td>0,57</td><td><strong>1,00</strong></td><td>16</td></tr><tr><td>HAS_FORWIDTH</td><td>0,00</td><td><strong>1,00</strong></td><td>14</td></tr><tr><td>HAS_LATITUDE</td><td>0,00</td><td><strong>0,57</strong></td><td>10</td></tr><tr><td>HAS_LONGITUDE</td><td>0,00</td><td><strong>1,00</strong></td><td>12</td></tr><tr><td>HAS_QUANTITY</td><td>0,94</td><td><strong>0,95</strong></td><td>191</td></tr><tr><td>INJURED_NUMBER</td><td>0,00</td><td><strong>0,30</strong></td><td>70</td></tr><tr><td>IS_OF_NATIONALITY</td><td>0,84</td><td><strong>0,91</strong></td><td>179</td></tr><tr><td>IS_OF_SIZE</td><td><strong>0,96</strong></td><td>0,95</td><td>438</td></tr><tr><td>IS REGISTERED_AS</td><td>0,75</td><td><strong>1,00</strong></td><td>34</td></tr><tr><td>WEIGHS</td><td>0,60</td><td><strong>1,00</strong></td><td>41</td></tr><tr><td>GENDER_FEMALE</td><td>0,90</td><td><strong>0,93</strong></td><td>414</td></tr><tr><td>GENDER_MALE</td><td>0,92</td><td><strong>0,95</strong></td><td>908</td></tr></tbody></table>

# 5 Optimisation des résultats : pistes d'amélioration et réflexions

## 5.1 Augmentation de données

Plusieurs axes d'amélioration peuvent être envisagés pour affiner davantage les résultats obtenus. Tout d'abord, il serait pertinent de relancer les expérimentations en modifiant les prompts, en explorant différentes formulations, ou en adoptant des modèles de langage plus puissants et récents comme GPT-4 (OpenAI et al., 2023) ou Mistral 7B (Jiang et al., 2023) (voire même un modèle plus conséquent comme Mistral large 123B). Toutefois, il serait important d'évaluer le ratio coût/efficacité avant de privilégier l'utilisation de ces modèles plus complexes, souvent très gourmands en ressources matérielles et énergétiques. Cette évaluation permettrait de déterminer si les gains potentiels en termes de performance justifient les coûts additionnels.

Une autre stratégie consisterait à revoir la structuration des prompts. Par exemple, une approche pourrait impliquer la génération d'une phrase contenant les entités en premier, suivie uniquement des relations à annoter. Cette reformulation pourrait potentiellement améliorer la précision des sorties en clarifiant les attentes pour le modèle.

Enfin, une approche hybride mériterait d'être explorée : utiliser un modèle pour générer les phrases et un autre, spécialisé, pour effectuer l'annotation des relations. En combinant les forces spécifiques de différents modèles, cette stratégie pourrait augmen-
ter la robustesse des résultats tout en minimisant les biais spécifiques à un seul modèle.

Ces ajustements, pris individuellement ou de manière combinée, ouvrent la voie à
des résultats plus précis et plus fiables.

Cependant, il ne s'agit pas uniquement d'améliorations algorithmiques. Nous pen-
sons également que le post-traitement des données générées permettrait de couvrir une
partie des pertes. À cet égard, le second filtrage des données générées pourrait être amé-
lioré en identifiant précisément les raisons pour lesquelles certaines sont supprimées et
en analysant ce qui les rend incohérentes. Ce travail, pourrait fournir des pistes pour
affiner les prompts et ajuster les critères du filtrage, augmentant ainsi le nombre de
phrases conservées tout en maintenant la cohérence et de pertinence des données. Ce
rééquilibrage, permettrait non seulement de compenser certaines lacunes des modèles,
mais également de garantir une meilleure contextualisation des résultats.

5.2 Représentation à base de graphe

Plusieurs relations entité-entité ont des propriétés particulières par rapport aux
autres relations. Nous remarquons de la transitivité pour des relations, notamment la
relation *IS LOCATED IN*. En effet pour deux entités *PLACE* : "place1" et "place2",
si "place1" is \_located\_in "place2" et qu'une autre entitéA is \_located\_in "place1" alors
entitéA is \_located\_in "place2".

Nous avons imaginé deux méthodes pour initialiser un graphe au niveau du document. La première est de reprendre la méthode d'énumération des couples d'entités possibles utilisée dans la première approche pour générer le *dataset*. Ensuite, l'idée était de modifier la tâche en classification des arcs du graphe.

La deuxième méthode est de construire un graphe à partir des arbres de dépendance syntaxique pour chaque phrase. Le *dataset* étant annoté en coréférence, nous pouvons utiliser les mentions des entités pour combiner les graphes de chaque phrase en un seul graphe à l'échelle du document.

Nous avons utilisé SpaCy<fnref n="4" /> pour extraire les arbres de dépendance des phrases. Exemple de graphe pour un document figure 2. Un tel graphe pourrait amener le contexte nécessaire à la détection des relations les plus complexes.

<footnote n="4">4. https://spacy.io/usage/linguistic-features/#dependency-parse</footnote>
<figure><img src="image_4.png" /><figcaption>FIG. 2 – Graphe des entités à partir des dépendances syntaxiques sur un document.</figcaption></figure>

## 5.3 Modèle de classification de relation

Différentes améliorations sont possibles concernant les modèles et leurs sorties. Tout d'abord, pour le modèle entité-attribut, faire une augmentation de données simple pour les relations avec moins de 20 occurrences pour s'assurer de la robustesse du modèle. Les relations étant simples une augmentation à base de dictionnaire ou de reformulation pourrait être suffisante.

Ensuite, pour le modèle entité-entité, faisant de la classification multi-classe multi-label, un seuil a été défini empiriquement à partir duquel on accepte la prédiction du modèle. Ce seuil est le même pour toutes les entités. Un seuil par classe pourrait être plus pertinent.

La représentation par graphe semble être pertinente par rapport à la structure des données. Soit par la modélisation du problème en fournissant le graphe en entrée du modèle. Soit en faisant des post-traitements, notamment en complétant le graphe des relations prédites par un modèle. Un tel travail pourrait permettre de trouver les relations transitives implicites, observé par exemple pour la relation *IS Located In*.

Enfin, les modèles joints en reconnaissance d'entités et en extraction de relation ont montré leur performance dans la littérature. Une exploration de ces approches semble être prometteuse. Dans le cadre de ce challenge, nous avons initié des expérimentations, non concluantes, dans ce sens. En effet, nous avons expérimenté le modèle EnRICO (Zaratiana et al., 2024), basé sur un mécanisme d'attention simultané sur les
entités et les relations, dans un contexte one-shot. Comme ce modèle est pré-entrainé en anglais, nous avons opté par une traduction automatique des données du challenge vers l'anglais en pré-traitement. Une analyse qualitative montre des résultats décevants. Un fine-tunning du modèle EnRiCO sur les données du challenge nous semble une piste pertinente.

# 6 Conclusion

L'objectif de cette étude était d'explorer les méthodes d'extraction de relations entre entités textuelles en utilisant un corpus augmenté grâce à l'application de modèles de langage de grande taille (LLM). Nos expérimentations ont révélé que l'un des principaux défis réside dans le déséquilibre des relations dans le corpus, ce qui impacte particulièrement les relations rares. Pour surmonter cette difficulté, nous avons utilisé des modèles LLM pour générer des données supplémentaires, ce qui a permis d'améliorer en partie la couverture de certaines catégories de relations, en particulier celles initialement sous-représentées en micro-F1. Par exemple, les relations comme *IS_BORN_IN* et *IS_COOPERATING_WITH* qui avaient un faible F1 sans augmentation, ont montré des améliorations grâce à l'augmentation des données.

Pendant le challenge, nous avons observé que l'augmentation des données permet une légère amélioration des résultats, notamment pour les relations complexes ou peu fréquentes. En effet, parmi les 6 classes pour lesquelles l'augmentation des données a été effectuée, seules 5 classes montrent un gain en performance (par exemple, la relation *IS_BORN_IN*, dont le F1 score passe de 0,19 à 0,29 avec augmentation de données). Cependant, ces résultats sont issus d'un entraînement qui n'a pas été mené à son terme. Ainsi, à la fin du challenge, nous avons effectué un nouvel entraînement complet avec les données augmentées. Bien que ces résultats ne soient pas inclus dans les résultats finaux du challenge, nous avons observé une amélioration notable des scores F1 sur les relations augmentées, avec des scores doublés grâce à l'augmentation des données (par exemple, la relation *IS_BORN_IN*, dont le F1 score passe de 0,19 à 0,48). Toutefois, un peu de bruit persiste sur les relations non augmentées, notamment celles avec peu d'occurrences.

Des problèmes persistent, notamment en ce qui concerne le format des données générées et l'exactitude des informations, telles que la position des entités dans les phrases. Un post-traitement des sorties du modèle a été nécessaire pour nettoyer et garantir leur conformité aux exigences d'annotation. Malgré ces efforts, des pertes de données significatives ont été constatées, dues en grande partie à la redondance ou aux erreurs dans la génération des données.

Nos résultats montrent que l'optimisation des *prompts* et l'expérimentation avec des modèles encore plus puissants, comme GPT-4, pourraient améliorer la précision et la fiabilité des phrases générées. Une approche hybride, combinant génération et annotation par des modèles spécialisés, pourrait également s'avérer bénéfique. De plus, les comparaisons entre les modèles mDeBERTa et BERT ont révélé que mDeBERTa
est mieux adapté à la tâche d'extraction de relations entité-attribut, comme l'illustre
le tableau 5, où les scores F1 pour mDeBERTa sont supérieurs à ceux de BERT dans
notre contexte.

Par ailleurs, des expérimentations supplémentaires ont été menées avec des graphes,
qui semblaient prometteuses pour l'extraction de relations, mais elles n'ont pas pu être
approfondies en raison de contraintes de temps. Ces approches apparaissent néanmoins
pertinentes, notamment par rapport à la structure des données, et mériteraient d'être
explorées davantage dans de futures recherches.

En conclusion, bien que des améliorations aient été apportées grâce à l'augmen-
tation des données et à l'utilisation de modèles puissants comme mDeBERTa, des
ajustements supplémentaires sont nécessaires pour surmonter les défis liés à la généra-
tion de données et à leur traitement afin d'obtenir des résultats encore plus robustes et
fiables. L'intégration de données augmentées a d'ores et déjà montré un impact positif
sur les performances des modèles, mais une optimisation continue est nécessaire pour
maximiser l'efficacité de l'extraction des relations complexes.
Références

Armingaud, R., A. Peuvot, R. Besançon, O. Ferret, S. Souihi, et al. (2024). Cea-list@evalllm2024 : prompter un très grand modèle de langue ou affiner un plus petit ? In *Atelier sur l'évaluation des modèles génératifs (LLM) et challenge d'extraction d'information few-shot*, Toulouse, France. Institut des sciences informatiques et de leurs interactions - CNRS Sciences informatiques [INS2I-CNRS].

Bassignana, E. et B. Plank (2022). What do you mean by relation extraction? a survey on datasets and study on scientific relation classification. In S. Louvan, A. Madotto, et B. Madureira (Eds.), *Proceedings of the 60th Annual Meeting of the Association for Computational Linguistics : Student Research Workshop*, Dublin, Ireland, pp. 67–83. Association for Computational Linguistics.

Brown, T. B., B. Mann, N. Ryder, M. Subbiah, J. Kaplan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sastry, A. Askell, et al. (2020). Language models are few-shot learners. *Advances in Neural Information Processing Systems 33*, 1877–1901.

Delaunay, J., H. T. H. Tran, C.-E. González-Gallardo, G. Bordea, N. Sidere, et A. Doucet (2023). A comprehensive survey of document-level relation extraction (2016-2023).

Devlin, J., M.-W. Chang, K. Lee, et K. Toutanova (2019). BERT : Pre-training of deep bidirectional transformers for language understanding. In J. Burstein, C. Doran, et T. Solorio (Eds.), *Proceedings of the 2019 Conference of the North American Chapter of the Association for Computational Linguistics : Human Language Technologies, Volume 1 (Long and Short Papers)*, Minneapolis, Minnesota, pp. 4171–4186. Association for Computational Linguistics.

He, P., J. Gao, et W. Chen (2021). Debertav3 : Improving deberta using electra-style pre-training with gradient-disentangled embedding sharing. *CoRR abs/2111.09543*.

Jiang, A. Q., A. Sablayrolles, A. Mensch, C. Bamford, D. S. Chaplot, D. de las Casas, F. Bressand, G. Lengyel, G. Lample, L. Saulnier, L. R. Lavaud, M.-A. Lachaux, P. Stock, T. L. Scao, T. Lavril, T. Wang, T. Lacroix, et W. E. Sayed (2023). Mistral 7b.

OpenAI, J. Achiam, S. Adler, S. Agarwal, L. Ahmad, I. Akkaya, F. Aleman, D. Almeida, J. Altenschmidt, S. Altman, S. Anadkat, R. Avila, I. Babuschkin, S. Balaji, V. Balcom, P. Baltescu, H. Bao, M. Bavarian, J. Belgum, et B. Zoph (2023). Gpt-4 technical report.

Zaratiana, U., N. Tomeh, Y. Dauxais, P. Holat, et T. Charnois (2024). Enrico : Enriched representation and globally constrained inference for entity and relation extraction.
Annexe 1

Génère un paragraphe annoté de 100 mots maximum, au format JSON, sans
introduction ni explications, décrivant la date de naissance d'une personne
civile.

Par exemple : {
'id': '186',
'text': 'À Bruxelles, Annette Deneuve a perdu ses bras sur le chantier de construction d'une voie ferrée à Louise. Un coffrage en béton de plusieurs tonnes est tombé de la flèche en porte-à-faux d'une grue alors qu'elle travaillait courbée sur les rails. Suite à cet accident qui s'est produit le 4 octobre 2017, elle a été amputée des deux bras. Cette femme de nationalité américaine est née le 20 mars 1995 en Pennsylvanie et réside à Bruxelles pour son travail. D'après l'Association des cheminots, ces morts tragiques sont devenues répétitives et ont plongé les travailleurs dans une grande insécurité.'

'entities': [
  {
    'id': 2, 'mentions': [
      {
        'value': 'Annette Deneuve', 'start': 13, 'end': 28
      },
      {
        'value': 'elle', 'start': 206, 'end': 210
      },
      {
        'value': 'elle', 'start': 304, 'end': 308
      },
      {
        'value': 'femme', 'start': 344, 'end': 349
      }
    ], 'type': 'CIVILIAN'
  },
  {
    'id': 6, 'mentions': [
      {
        'value': 'Pennsylvanie', 'start': 403, 'end': 415
      }
    ], 'type': 'PLACE'
  },
  'relations': [[2, 'IS_BORN_IN', 6]]
].

Dans cet exemple : 'id' : un identifiant unique pour chaque phrase générée.
'entities' : une liste d'entités mentionnées dans la phrase, chacune avec
son propre identifiant et ses mentions. Si une entité est mentionnée
plusieurs fois, ses mentions partagent le même identifiant. 'start' et
'end' indiquent les positions des caractères de début et de fin de chaque
mention. 'relations' : décrit la relation entre deux entités par leur
identifiant, par exemple [[2, 'IS_BORN_IN', 6]] indique que l'entité 2 a
initié une interaction avec l'entité 6.

<caption>FIG. 3 – Exemple de prompt utilisée pour l'augmentation de données de la relation BORN_IN.</caption>
Annexe 2

<table><caption>TAB. 6 – Nombre de relations unique ou multiple pour chaque couple d'entité, par le label de la relation.</caption><thead><tr><th></th><th>unique</th><th>multiple</th></tr></thead><tbody><tr><td>STARTED_IN</td><td>213</td><td>1647</td></tr><tr><td>IS Located_IN</td><td>6460</td><td>2565</td></tr><tr><td>OPERATES_IN</td><td>2256</td><td>179</td></tr><tr><td>IS_PART_OF</td><td>989</td><td>473</td></tr><tr><td>CREATED</td><td>25</td><td>101</td></tr><tr><td>HAS_CONTROL_OVER</td><td>3018</td><td>1529</td></tr><tr><td>IS_IN_CONTACT_WITH</td><td>2001</td><td>918</td></tr><tr><td>IS COOPERATING_WITH</td><td>154</td><td>218</td></tr><tr><td>INITIATED</td><td>468</td><td>1</td></tr><tr><td>HAS_CONSEQUENCE</td><td>769</td><td>0</td></tr><tr><td>IS_AT_ODDS_WITH</td><td>1107</td><td>419</td></tr><tr><td>RESIDES_IN</td><td>19</td><td>203</td></tr><tr><td>IS BORN_IN</td><td>22</td><td>28</td></tr><tr><td>HAS FAMILY_RELATIONSHIP</td><td>123</td><td>99</td></tr><tr><td>DIED_IN</td><td>40</td><td>1</td></tr><tr><td>DEATHS_NUMBER</td><td>73</td><td>2</td></tr><tr><td>HAS CATEGORY</td><td>894</td><td>0</td></tr><tr><td>HAS COLOR</td><td>91</td><td>0</td></tr><tr><td>HAS FOR HEIGHT</td><td>12</td><td>0</td></tr><tr><td>HAS FOR LENGTH</td><td>16</td><td>0</td></tr><tr><td>HAS FOR WIDTH</td><td>14</td><td>0</td></tr><tr><td>HAS LATITUDE</td><td>10</td><td>0</td></tr><tr><td>HAS LONGITUDE</td><td>10</td><td>0</td></tr><tr><td>HAS QUANTITY</td><td>191</td><td>0</td></tr><tr><td>INJURED_NUMBER</td><td>69</td><td>1</td></tr><tr><td>IS_OF_NATIONALITY</td><td>179</td><td>0</td></tr><tr><td>IS_OF_SIZE</td><td>437</td><td>1</td></tr><tr><td>IS REGISTERED_AS</td><td>34</td><td>0</td></tr><tr><td>WEIGHS</td><td>41</td><td>0</td></tr><tr><td>GENDER FEMALE</td><td>413</td><td>1</td></tr><tr><td>GENDER MALE</td><td>906</td><td>2</td></tr><tr><td>IS BORN_ON</td><td>20</td><td>0</td></tr><tr><td>IS DEAD_ON</td><td>68</td><td>0</td></tr><tr><td>WAS CREATED_IN</td><td>15</td><td>0</td></tr><tr><td>WAS DISSOLVED_IN</td><td>14</td><td>0</td></tr><tr><td>START_DATE</td><td>233</td><td>801</td></tr><tr><td>END_DATE</td><td>73</td><td>801</td></tr></tbody></table>
Annexe 3

<table><caption>TAB. 7 – F1 score par label avec et sans augmentation de données pour les relations entité-entité sur le dataset de validation. *1 sont les résultats de notre soumission finale, dont l’entraînement a été arrêté avant la fin. Cet entraînement a été refait après la fin du challenge, les résultats sont dans la colonne *2.</caption><thead><tr><th></th><th>sans<br>augmentation</th><th>avec<br>augmentation<br>*1</th><th>avec<br>augmentation<br>*2</th><th>nombre<br>d'occurences<br>(+ augmentation)</th></tr></thead><tbody><tr><td>HAS Family RELATIONSHIP</td><td><strong>0,91</strong></td><td>0,82</td><td>0,82</td><td>222</td></tr><tr><td>START_DATE</td><td><strong>0,83</strong></td><td>0,78</td><td>0,82</td><td>1034</td></tr><tr><td>OPERATES_IN</td><td>0,73</td><td>0,74</td><td><strong>0,76</strong></td><td>2435</td></tr><tr><td>END_DATE</td><td>0,77</td><td>0,70</td><td><strong>0,79</strong></td><td>874</td></tr><tr><td>STARTED_IN</td><td>0,69</td><td>0,69</td><td><strong>0,70</strong></td><td>1860</td></tr><tr><td>IS Located_IN</td><td>0,69</td><td>0,68</td><td><strong>0,73</strong></td><td>9025</td></tr><tr><td>HAS CONSEQUENCE</td><td><strong>0,52</strong></td><td>0,50</td><td><strong>0,52</strong></td><td>769</td></tr><tr><td>HAS CONTROL_OVER</td><td>0,50</td><td>0,50</td><td><strong>0,52</strong></td><td>4547</td></tr><tr><td>IS AT ODDS WITH</td><td><strong>0,50</strong></td><td>0,47</td><td>0,49</td><td>1526</td></tr><tr><td>IS BORN_ON</td><td><strong>0,80</strong></td><td>0,44</td><td>0,31</td><td>20</td></tr><tr><td>IS IN CONTACT WITH</td><td><strong>0,48</strong></td><td>0,44</td><td>0,47</td><td>2919</td></tr><tr><td>IS PART_OF</td><td>0,45</td><td>0,42</td><td><strong>0,46</strong></td><td>1462</td></tr><tr><td>INITIATED</td><td><strong>0,45</strong></td><td>0,41</td><td>0,40</td><td>469</td></tr><tr><td>IS DEAD_ON</td><td><strong>0,50</strong></td><td>0,38</td><td>0,36</td><td>68</td></tr><tr><td>IS BORN_IN</td><td>0,19</td><td>0,29</td><td><strong>0,48</strong></td><td>50 (+ 198)</td></tr><tr><td>RESIDES_IN</td><td><strong>0,41</strong></td><td>0,24</td><td>0,34</td><td>222</td></tr><tr><td>IS COOPERATING_WITH</td><td>0,11</td><td>0,19</td><td><strong>0,20</strong></td><td>372 (+ 45)</td></tr><tr><td>DIED_IN</td><td>0,09</td><td><strong>0,15</strong></td><td>0,11</td><td>41 (+ 53)</td></tr><tr><td>CREATED</td><td>0,06</td><td>0,11</td><td><strong>0,13</strong></td><td>126 (+ 115)</td></tr><tr><td>WAS CREATED_IN</td><td>0</td><td>0</td><td><strong>0,17</strong></td><td>15 (+ 86)</td></tr><tr><td>WAS DISSOLVED_IN</td><td>0</td><td>0</td><td><strong>0,10</strong></td><td>14 (+ 9)</td></tr></tbody></table>
Summary

Information extraction, in particular the extraction of relations in a specific con-
text, remains a challenge despite the progress made in the field of Natural Language
Processing (NLP). This article is part of the TextMine'25 challenge, proposed at the
EGC 2025 conference, which focuses on the extraction of relationships between enti-
ties and events of military interest in simulated intelligence reports. We present an
in-depth analysis of the corpus used, as well as a data augmentation method based on
Large Language Models. This approach aims to enrich annotations and diversify the
examples used for model training.