Paradigme du Data programming

Paradigme du Data programming

Comme nous l’avons mentionné dans le contexte de notre stage, nous disposons d’un corpus non annoté (cf. chapitre 4.1). Même si un corpus peut être annoté de manière manuelle, cela demande beaucoup de temps et surtout des moyens humains particuliers, car il faudrait des professionnels de l’apprentissage des langues qui soient capables de donner des étiquettes de niveaux pour chaque extrait. Nous allons donc annoter nos données de manière automatique grâce au principe du data programming. Le concept de data programming introduit par Ratner et al. (2016) consiste à créer un corpus d’apprentissage (données annotées) à partir d’un ensemble de règles d’annotations qui sont définies par l’utilisateur-expert. Ces règles d’annotation représentent des connaissances ou des heuristiques sur le domaine considéré. Elles permettent d’annoter automatiquement les données via des fonctions de labellisations. Dans notre cas, les fonctions de labellisation se basent sur des règles syntaxiques et lexicales que je vais développer à partir d’ouvrage de FLE et du lexique FleLex (cf. chapitre 4.5). Le data programming va nous permettre de gérer les conflits entre les fonctions de labellisation. Ceux-ci surviennentquand deux fonctions de labellisation annotent un sous-ensemble de données de manière différentes. Prenons l’exemple des deux phrases suivantes :
> Je mange une pomme
> Le parlementaire propose une motion
Si nous nous intéressons à la syntaxe et au lexique de chacune de ces phrases, nous voyons que la première phrase comporte une syntaxe simple de type sujet-verbe -complément et un lexique simple. Cela signifie que pour cette phrase le système va renvoyer la même étiquette. La deuxième phrase quant à elle possède une syntaxe simple également mais un lexique qu’on peut considérer comme plus difficile avec des mots comme « parlementaire » et « motion ». Pour cette phrase, le système va alors renvoyer deux étiquettes différentes pour une même phrase, il va donc y avoir un conflit. Ainsi, dans une approche d’annotation manuelle l’utilisateur va devoir choisir laquelle des deux étiquettes utiliser ou alors choisir de fusionner les deux, mais cela peut entraîner une perte de précision. Le data programming permet de faire cela automatiquement en apprenant un modèle en prenant en compte les deux étiquettes renvoyées par le système.
Snorkel est un outil de data programmingcréé par Ratner et al (2017) pour permettre à des utilisateurs de pouvoir construire facilement des données d’entraînements. Il a été bâti selon trois critères. Le premier est de pouvoir utiliser toutes les ressources disponibles, c’est-à-dire de permettre à l’utilisateur d’avoir des étiquettes venant de toutes les ressources faiblement supervisées à sa disposition. La deuxième est de créer des données d’entraînement comme interface pour l’apprentissage automatique. Le système doit être capable de modéliser les sources d’étiquette pour induire un seul étiquetage probabiliste pour chaque instance. Ces étiquettes sont utilisées pour entraîner un modèle discriminatif, qui va permettre de généraliser. Enfin le dernier critère est celui de l’efficacité, le système doit être capable de fournir rapidement des résultats avec un taux de fiabilité qui soit comparable à une annotation qui serait réalisée par des humains.

Ressources utilisées

Corpus : OpenSubtitles

Pour constituer notre corpus de sous-titres d’extraits de films, nous avons choisi d’utiliser OpenSubtitles 2018 (Lison et Tiedemann, 2016). Cette base de données, construite à partir d’IMDb (Internet Movie Database), est composée de plus de trois millions de fichiers au format XML de sous-titres de films et séries dans 60 langues différentes. Nous avons sélectionné dans ce grand volume de données uniquement les films et séries en langue française puisqu’il s’agit de la langue cible de notre système.
Nous travaillons donc sur une partie seulement de ces films. Pour pouvoir les sélectionner nous disposons d’un fichier « OPUS metadata json.pickle » qui nous donne accès aux métadonnées des films et séries comprenant notamment la langue, ainsi qu’un identifiant unique par film. A partir de ce fichier et dans le cadre d’un stage précédent (Petiot, 2018), un découpage automatique (Figure 3) a été fait grâce à l’application d’une règle simple qui consiste à segmenter les sous-titres en séquences, dès que deux sous-titres consécutifs sont séparés de plus de 7 secondes de non parole. Ce délai a été défini empiriquement lors de travaux précédents. L’idée est de découper les sous-titres en séquences d’interaction différentes (dialogue entre mêmes participants sur un sujet donné dans un même cadre spatio-temporel) en faisant l’hypothèse qu’une zone de non parole relativement longue ( > 7s) peut, dans la plupart des films, séparer deux scènes différentes. Cela a permis d’avoir un ensemble de fichiers de quelques lignes de dialogues.
Nous disposons pour notre corpus de plusieurs dossiers rangés par année de 1910 à 2017. Nous avons fait le choix de sélectionner des films et des séries sur une grande échelle de sortie de films pour avoir plus de données pour entraîner notre corpus. Il faut cependant noter que pour les films anciens, les extraits ne sont pas des dialogues, mais le texte inséré entre deux scènes de films muets. Ces dossiers classés par année comprennent des dossiers correspondant aux identifiants des films ou séries, eux-mêmes décomposés en plusieurs fichiers de séquences correspondant à des dialogues. Le corpus d’OpenSubtitles2018 sert à entraîner nos règles (Tableau 1). Nous disposons également d’un corpus de test issu d’une étude de Randria et al. (2020) sur l’évaluation de la compréhension dans les interactions cinématographiques. Celui-ci est composé de 55 extraits issus de 12 films français différents dont la difficulté a été évaluée par des enseignants du Français Langue Étrangère (FLE) sur une échelle de 1 à 100. Dans la figure 4, nous voyons que les soustitres du corpus de test sont formés différemment de ce que nous avons pour notre corpus d’entraînement. Pour pouvoir récupérer seulement les lignes de dialogue sans les time codes, nous avons dû utiliser la bibliothèque pysrt qui permet de passer les lignes qui ne correspondent pas au texte du sous-titre.
En plus du corpus de test (Tableau 1), nous disposons d’un second fichier comportant les notes des enseignants. Il y a trois types de notes pour chaque extrait de films : une note sur la difficulté syntaxique, une note sur la difficulté lexicale ainsi qu’une note globale sur la difficulté de l’extrait. Nous ne pouvons cependant pas donner d’exemple de ce fichier puisque la thèse est encore en cours.

Étiquettes du CECRL

Comme nous l’avons dit le principe du data programminget son outil Snorkel sont fondés sur l’annotation des données via la création de règles et la définition d’étiquettes. Pour notre système, nous avons besoin d’étiquettes qui reflètent un niveau de difficulté linguistique pouvant être assimilées à un niveau de difficulté de compréhension. Au début, nous avons pensé à choisir des étiquettes du type « facile-moyen-difficile » cependant comment délimiter ces étiquettes ? En effet, ces notions sont beaucoup trop subjectives pour être utilisées dans notre cadre théorique et dans un système que nous voulons utilisable par tous les enseignants de FLE. Nous avons pensé aux niveaux du Cadre Européen Commun de Référence pour les Langues (CECRL : A1, A2, B1, B2, C1 et C2). L’avantage d’utiliser ces niveaux était double. Dans un premier temps, il s’agissait d’utiliser des étiquettes qui soient familières pour les enseignants, car ce sont celles-ci qui représentent les niveaux dans l’enseignement des langues étrangères. Dans un second temps, ce choix a été motivé par l’aspect pratique de ces étiquettes. En effet, il est facile de trouver des ouvrages qui informent sur les éléments qui entrent en compte dans la définition de ces niveaux d’apprentissage selon les niveaux de difficulté. Nous avons limité la caractérisation du niveau de difficulté à des critères lexicaux et syntaxique. Pour obtenir ces informations, nous utilisons la ressource FleLex pour le lexique (cf. chapitre 4.5), et la bibliothèque python SpaCy pour le traitement des règles syntaxiques.

Bibliothèque python : SpaCy

SpaCy est une bibliothèque python très utilisée en traitement automatique des langues. Elle permet d’attribuer des vecteurs de mots, des catégories (POS ou part-of-speech), des dépendances, mais aussi de faire de la reconnaissance d’entités nommées dans plus de 50 langues différentes Pour cela, Spacy possède en français trois modèles statistiques de base entraînés sur différentes données. Un modèle basique «fr_core_news_sm», et deux modèles plus avancés «fr_core_news_md» et «fr_core_news_lg»1. Les trois sont entraînés sur le UD French Sequoia et WikiNER mais à la différence du modèle basique, les deux plus avancés ont en plus les vecteurs de mots entraînés à l’aide de la bibliothèque FastText1 utilisant le modèle CBOW (continuous bag  of words) sur les ressources Wikipedia et OSCAR (Common Crawl). Les vecteurs de mots vont permettre de faire des tests de similarité. Or pour notre système nous n’avons pas besoin de cette information (similarité des mots) . De plus l’accuracy pour le «fr_core_news_sm»1 est de 98,52 pour les tokens et 94,20 pour les tags contre respectivement 98,52 et 95,72 pour le «fr_core_news_md», la différence étant minime nous avons choisi d’utiliser le modèle basique «fr_core_news_sm ».

Règles syntaxiques

Pour rédiger nos règles qui sont l’élément central de notre système, nous nous sommes appuyés sur des ouvrages référentiels du Français Langue Étrangère (Beacco & al., 2004; Beacco & al., 2006; Beacco & al., 2008; Beacco & al., 2011; Riba, 2016). Nous disposions d’un livre par niveaux du CECRL, mais nous nous sommes principalement servi des niveaux A2, B1, et B2. En effet, les niveaux dit « avancés » c’est-à-dire C1 et C2 devenaient beaucoup trop précis et sémantiquement complexes, et donc allaient demander des règles beaucoup trop lourdes. Nous avons donc laissé la sélection des niveaux avancés au lexique dont nous parlerons plus tard. Ces ouvrages nous ont permis d’avoir des règles correctement délimitées selon les niveaux. Cependant, l’utilisation de ce genre de livres peut aussi poser un problème linguistique. La syntaxe de l’oral est différente de celle de l’écrit, or les sous-titres de films sont justement dans une modalité écrite retranscrivant ce qui est dit à l’oral (parfois en le simplifiant, mais nous ferons abstraction de cette question). Ainsi, nous avons pris en compte ce facteur dans la rédaction de no s règles, et certaines règles jugées trop littéraires ont été éliminées de notre script.
La définition d’un premier jeu de règles s’est opérée en considérant des familles de règles. En tout nous disposons de 60 règles comprenant 9 règles adjectivales, 3 règles nominales, 6 règles verbales, 8 règles passives, 13 règles pronominales (avec et sans négation) et 20 règles interrogatives ainsi qu’une règle sur la longueur des phrases. L’objectif n’était pas d’être exhaustif, mais d’avoir un premier ensemble qui couvre un ensemble significatif de cas. Il y a différentes structures de règles qui sont chacune utiliséesselon les informations fournies par SpaCy. Certaines
vont chercher un pattern ou motif fixe de catégories syntaxiques (il s’agit de la plupart des règles), d’autres vont chercher une expression figée, ou encore d’autres vont chercher les informations dans le tag des catégories. Cependant, même si la structure des règles et les patterns de recherche peuvent changer selon les fonctions, ces dernières ont toutes une structure identique.

Règle lexicale

Comme nous l’avons dit précédemment, en plus des livres, nous nous sommes servis d’un lexique pour définir les étiquettes de niveaux. Ces informations lexicales sont très importantes, car la difficulté de compréhension passe aussi par le vocabulaire du lecteur. Bien qu’il faille différencier lexique et vocabulaire, les deux niveaux d’informations sont importants. Le premier correspond au regroupement des mots d’une langue (représentant la structure de groupes de mots) tandis que le second représente une partie de ce que connaît le lecteur du lexique de la langue cible langue.
Dans un contexte d’apprentissage d’une langue en milieu scolaire, il y a tout de même un socle de vocabulaire à connaître à chaque niveau.
Dans ce contexte, nous avons choisi d’utiliser FLELex CRF (François et al., 2014) qui est un lexique regroupant les fréquences normalisées de plus de 14 000 mots pour chaque niveau du CECRL. Il a été développé conjointement par Le Centre de traitement du langage naturel (CENTAL) de l’Université catholique de Louvain, le Laboratoire Parole et Langue de l’Université Aix-Marseille et la société EarlyTracks. Pour obtenir ce corpus, les chercheurs ont récupéré 2071 textes de différentes manuels scolaires datant d’après 2011. Chaque texte s’est vu attribuer le même niveau que celui de son manuel, puis a été transformé au format XML par des outils de reconnaissance optique de caractères. Après une correction manuelle, un corpus de 777 000 mots a été créé.
Après avoir utilisé deux taggers pour étiqueter les mots, la fréquence d’apparition des mots dans les différents niveaux a été calculée pour pouvoir créer deux lexiques différents basés sur les deux taggers utilisés. Le premier lexique est FLELex TT qui a basé sa fréquence sur la tokenization et les part-of-speech de Treetagger. Ce lexique compte en tout 14 236 entrées. Le deuxième est FLELex CRF qui lui est basé sur les résultats du tagger CRF et qui compte 17 871 entrées. Nous avons choisi d’utiliser FLELex CRF tout d’abord car il contient un plus grand nombre d’entrées mais aussi car selon François et al (2014), celui-ci fournit une meilleure estimation des fréquences, même si certaines d’entre elles ne sont pas bien étiquetées.
Nous avons décidé de récupérer principalement les fréquences des niveaux B2, C1 et C2, car les deux derniers niveaux ne sont pas représentés dans les règles syntaxiques, ce qui donne ainsi une information complémentaire. Pour cela, nous disposons d’un fichier « fle_converted_B2.txt » créé à partir des fréquences qui se compose uniquement du lemme, du part-of-speech, et de son niveau de difficulté (figure 7).

Mise en œuvre

Le corpus de sous-titre dont nous disposons étant très important, il est nécessaire de lancer le traitement sur une machine capable de traiter ce volume de données en un temps raisonnable.
Avant de décrire l’implémentation des règles, je vais donnerune brève explication sur la plate-forme utilisée pour exécuter mon script.

Osirim Osirim

(Observatoire des Systèmes d’Indexation et de Recherche d’Information Multimédia) est une plate forme de l’IRIT disposant d’environ 1 Po de stockage. Elle est composée de deux nœuds : le nœud interactif et le nœud de calcul. Le premier permet à l’utilisateur de se connecter, on peut y accéder grâce à des identifiants via ssh (Secure Shell) qui est une commande sécurisée de connexion à distance. Un fois connecté, il permet de lancer les calculs sur le second nœud en utilisant un job  SLURM via la commande sbatch. Pour cela, il est possible de créer un fichier shell qui va lancer le job lié à l’exécution d’un script donné. Le temps d’exécution du script peut être surveillé avec la commande squeue, cependant cette commande va montrer tous les jobs en cours, alors il est possible de surveiller uniquement son calcul avec la commande suivante : squeue|grep <nom_utilisateur>
L’utilisation de la plate-forme OSIRIM a été un avantage pour pouvoir gagner en performance, et permettre de lancer notre script sur un grand volume de données. C’est aussi sur cette plate-forme que nous avons récupéré notre corpus et toutes les ressources nécessaires pour notre projet.

Implémentation des règles

Notre système d’annotation faiblement supervisé dispose d’un premier jeu de 60 règles, chacune d’elle est classée dans des catégories différentes : verbales, adjectivales, pronominales, modales ou encore interrogatives.
L’écriture de ces règles s’est faite en plusieurs étapes. La première a été de sélectionner dans les ouvrages les différentes règles (structure syntaxique ou niveaux de l’apprentissage des temps et mode par exemple, cf. chapitre 4.4) selon plusieurs critères. Le premier concerne la complexité de la règle, il ne fallait pas choisir une règle trop complexe à écrire en code car même si en théorie nous pouvons penser que cela va nous aider à être précis dans ce que nous renvoyons, en pratique il est possible qu’un mot ou une ponctuation vienne « polluer » la structure que nous recherchons et ainsi la rendre inutilisable. Prenons l’exemple des constructions pronominales, pour les niveaux les plus élevés dans certaines structures il pouvait y avoir plus de quatre pronoms dans une même phrase ce qui les rend intéressantes mais beaucoup trop complexes à décrire.
Le deuxième critère est la pertinence, par exemple, nous n’avons pas sélectionné la règle de subordination, c’est-à-dire renvoyer une étiquettes suivant le temps qui suit une subordonnée introduite par « que » ou « qu’ », car nous donnons déjà une étiquette avec le mode et le temps verbal. Le dernier critère est les informations fournies par SpaCy qui vont nous aider à décider quelles règles sont réalisables. Ce premier travail a permis de récupérer les règles qui semblaient les plus judicieuses pour notre système. Unefois cette sélection faite, la deuxième étape a consisté à écrire toutes ces règles en pseudo-code, c’est à ce moment là que le travail en amont sur les informations fournies par SpaCy a été utile. Par exemple, pour ce qui est des règles verbales, l’information du mode et du temps étaient données dans le token.tag c’est-à-dire les informations du part-of-speech (POS ou catégorie lexicale). Ainsi pour pouvoir renvoyer des étiquettes de niveaux, il fallait chercher dans le token.tag le mode et le temps du verbe. La troisième étape a été d’écrire les règles en code python sur le script Snorkel fourni préalablement par Tim Van De Cruys. Cet teétape a été la plus longue, car il fallait gérer les erreurs de SpaCy (que nous aborderons plus tard), mais aussi la syntaxe de Snorkel dans la manière d’articuler les fonctions, et de renvoyer les étiquettes.

Erreurs de SpaCy

Nous savons que SpaCyn’est pas aussi bien entraîné sur le français que sur l’anglais, il est donc possible d’avoir des erreurs d’étiquetage qui peuvent porter préjudice au déclenchement des règles. Par exemple, le pronom « tu » va être étiqueté en tant que déterminant(DET), auxiliaire (AUX) ou encore verbe (VERB)au lieu de pronom (PRON). Autre exemple, les temps et les modes peuvent ne pas être correctement étiquetés. Ainsi nous aurons un temps au présent alors que le verbe est à l’imparfait. Cela peut empêcher une règle de se déclencher ou alors en déclencher une qui n’a pas lieu d’être. Cependant, nous avons choisi d’ignorer ce mauvais étiquetage, car il constitue une infime partie de ce que donne SpaCy et ainsi peut être considéré comme du bruit marginal. Malgré la décision de garder les erreurs, si les règles le permettaient, certains changements ont été apportés pour pallier certainsproblèmes d’étiquetage syntaxiques de SpaCy.

Analyse des résultats avec les règles syntaxiques et lexicales

Pour nos règles lexicales, nous utilisons le lexique FLELex, si un des mots du corpus apparaît dans la liste des mots de B2, C1 et C2 alors le niveau associé à ce mot va être renvoyé. Cette analyse nous permet de voir les conflits entre les règles lexicales et syntaxiques. En effet, il est possible que la syntaxe d’une phrase soit simple mais que ce soit le lexique qui rende la compréhension difficile. La figure 16, ci-dessous, montre les résultats de l’entraînement des règles syntaxiques et lexicales. Nous voyons que sur les 18 000 mots du corpus FLElex_CRF seulement 5 000 sont sélectionnés, car ils apparaissent dans le lexique à partir du niveau B2.
Avec les 5 dernières lignes du résultat, nous remarquons que la couverture, le chevauchement et le conflit sont les mêmes, ce qui signifie que ces 5 mots se sont retrouvés dans des structures des règles syntaxiques et qu’à chaque fois l’étiquette de niveau renvoyée était différente de celle renvoyé par la règle syntaxique. La couverture de chacun de ces mots est très faible (<1%). On explique ce faible score par l’utilisation peu courante de certains mots dans un contexte non précis.
Par exemple, le mot évierest un mot rare dans une conversation sauf exception dans un contexte précis (cuisine, salle de bain, pièce d’eau…), il en va de même pour îlotqui lui est encore moins courant dans une conversation ordinaire.
L’addition d’un ensemble de règles lexicales à nos règles syntaxiques nous permet de rendre notre système plus complet puisque nous prenons en compte deux paramètres. Après cette première analyse, nous voulons tester notre système sur un corpus test différent de celui d’OpenSubtitle, mais pour lequel nous disposons d’une vérité de terrain (Randria et al., 2020). En effet, pour l’instant nous ne pouvons pas affirmer que l’étiquetage de notre système peut être en accord avec ce que pensent des enseignants du FLE. Pour tester notre système, nous allons donc utiliser le corpus test d’Estelle Randria présenté plus haut (cf. chapitre 4.1).

Analyse des résultats avec le corpus test

L’analyse des résultats du corpus de test doit permettre de vérifier l’accuracyde nos fonctions de labellisations. En effet, Snorkel dispose pour cela de la fonction label_model_acc. Pour tester notre modèle nous disposons donc du corpus d’Estelle Randria constitué de 55 extraits pour 12 films, ainsi que des niveaux de difficulté donnéspar des enseignants de FLE pour chaque extrait.
Pour notre test, nous allons ainsi comparer les étiquettes renvoyées par notre système avec celles que les enseignants ont attribuées.
Pour pouvoir travailler avec le corpus d’Estelle Randria qui est composé de fichier srt, nous avons utilisé pysrt, puis assemblé les notes des enseignants avec le titre des extraits de film et leurs sous-titres dans un dictionnaire, où le titre de l’extrait est la clé et les notes (lexicale ou syntaxique) et les sous-titres sont les valeurs (figure 17). Les notes données par les enseignants étaient de 0 à 100 sur une échelle de difficulté. Pour correspondre à notre propre échelle de niveau, nous avons tout simplement divisé l’échelle des notes des enseignants par 4 pour faire une échelle qui corresponde au 4 niveaux les plus utilisés dans notre système (c’est-à-dire A1, A2, B1 et B2).

Améliorations possibles

Comme nous l’avons constaté pour nos résultats, certaines fonctions ne se déclenchent pas pour plusieurs raisons. La première est le caractère « écrit »textuel des règles, car malgré le fait que nous travaillons sur des données écritestextuelles, celles-ci sont avant tout calquées sur de l’oral. Et même s’il y a une certaine mise en forme textuel ledes interactions, les sous-titres restent quand même plus proche de la syntaxe orale. De ce fait, nos règles tout droit sorties de livre peuvent parfois être inadaptées à la réalité langagière de l’oral. Ainsi, il serait intéressant de faire un travail pour adapter ces règles à un contexte oral, pour pouvoir réduire les erreurs et le nombre de règles non déclenchées.
Une deuxième amélioration possible serait d’utiliser un autre annotateur que SpaCy pour limiter le nombre d’erreurs d’étiquetage, car nous savons que certaines de nos règles ne se sont pas déclenchées à cause de problème de ce genre. D’autres ont renvoyé des ABSTAIN, car les critères que nous cherchions dans les tagsn’étaient pas toujours présents. Par exemple, pour le passif, il y a des fois où dans le tag du verbe la mention« voice=passive » n’est pas présente. S’il n’est pas aisé de changer d’annotateur, car avec snorkel, SpaCy est le mieux intégré, il est cependant possible d’adapter certaines règles pour qu’elles prennent en compte les erreurs d’étiquetage et de manque d’information. Pour illustrer les erreurs de SpaCy nous pouvons prendre l’exemple de la fonction interrogative struc_interro2a qui cherchait la structure [‘VERB’, ‘PRON’,‘SCONJ’,‘PRON’,‘VERB’] (figure 19) mais nous avons dû changer car la construction de la liste des part-of-speech pour rechercher la structure ne se faisait pas bien.

Bilan

Travail réalisé

Pour ce stage notre objectif était de créer un système qui permet d’annoter automatiquement de grandes quantités de données selon des niveaux de difficulté.
La première étape a donc été de définir ces niveaux de difficulté, notre choix s’est porté sur les étiquettes du CECRL. A partir de là, j’ai pu définir, implémenter et lancer des règles syntaxiques et lexicales.
Pour les règles syntaxiques, je me suis basé sur des ouvrages du Français Langue Étrangère des différents niveaux du CECRL. J’ai sélectionné dans ces ouvrages des structures pour construire mes règles, cette sélection s’est faite en lien avec les informations fournies par SpaCy et la pertinence des règles dans un contexte de transcription de l’oral (sous-titre). Une fois les structures sélectionnées, j’ai travaillé à l’implémentation des règles d’abord sur un script utilisant uniquement SpaCy puis une fois la règle mise au point et fonctionnelle, je suis passée sur le script Snorkel permettant de renvoyer les étiquettes. Ce script a été fourni par mon tuteur Tim Van De Cruys au début de mon stage, il a été modifié et amélioré à quelques reprises pendant mon stage(par exemple pour récupérer uniquement les films dont les sous-titres sont français, gérer les problèmes d’identifiants de certains films). Chacune des règles syntaxiques a demandé un travail de réflexion sur la langue, c’est-à-dire se questionner sur la réalité linguistique de l’oral et de la transcription. Pour les règles lexicales, il a juste fallu ajouter au script Snorkel le fichier des fréquences d’apparition des mots par niveaux constitué comme ceci : mot, part-of-speech, niveau. Une fois ce travail fait, j’ai lancé le script Snorkel depuis le serveur Osirim, analyser les résultats et apporter des modifications à certaines règles si nécessaire. Quand la majorité des règles ont été déclenchées par le système pour le corpus d’entraînement, nous avons décidé de le lancer sur le corpus test.
Pour la partie test, Estelle Randria nous a fourni son corpus (fichierssrt) ainsi que les notes des enseignants (fichier csv). Pour le fichier csv, ma tutrice Isabelle Ferrané s’est occupé de modifier le fichier pour que les notes des enseignants correspondent à nos niveaux de difficulté.
J’ai donc récupéré le corpus et le fichier des notes, et grâce à un script j’ai pu stocker les informations dans un dictionnaire python. Celui-ci va permettre ensuite de récupérer plus facilement le corpus et les notes pour pouvoir tester notre système puis comparer nos étiquettes de niveaux avec les étiquettes données par les enseignants.

Table des matières
Remerciements
Résumé
Abstract
Introduction
PARTIE 1
Chapitre 1 : Contexte du stage
Chapitre 2 : Comment mesurer la difficulté de compréhension ?
PARTIE 2
Chapitre 3 : Paradigme du Data programming
Chapitre 3.1 : L’outil Snorkel
Chapitre 4 : Ressources utilisées
4.1 Corpus : OpenSubtitles
4.2 Étiquettes du CECRL
4.3 Bibliothèque python : SpaCy
4.4 Règles syntaxiques
4.5 Règle lexicale
PARTIE 3
Chapitre 5 : Mise en œuvre
5.1 Osirim
5.2 Implémentation des règles
5.3 Erreurs de SpaCy
Chapitre 6 : Résultats et analyse
6.1 Analyse des premiers résultats de l’entraînement
6.1.1 Explication des résultats fournis par Snorkel
6.1.2 Analyse des résultats avec les règles syntaxiques
6.1.2 Analyse des résultats avec les règles syntaxiques et lexicales
6.2 Analyse des résultats avec le corpus test
Chapitre 7 : Améliorations possibles
PARTIE 4
Chapitre 8 : Bilan
8.1 Travail réalisé
8.2 Bilan personnel
Bibliographie
Sitographie
Annexes

Télécharger le rapport complet