Utilisateur:EtienneR15u/Brouillon

Tri des modèles modifier

Critères de sélection modifier


La qualité des modèles est un des enjeux majeurs de Tetrao, il faut donc y porter une attention particulière. Mais quelles sont les métriques que l'on utilise dans l'évaluation des différentes composantes du modèles pour évaluer la qualité ? Qu'est ce qui fait un bon modèle ?

Avant d'expliquer les critères choisis, il est nécessaire de définir la nomenclature utilisée lors de l'évaluation d'un modèle. Lorsqu'on compare la prédiction d'un modèle à une annotation (qui est supposée être correcte), on a quatre cas envisageables :

  • True Positive (TP), ou Vrai Positif en français, ce qui signifie que le modèle a prédit une valeur normalisée avec un niveau de certitude supérieur au seuil défini, et qu'elle est identique à celle de l'annotation.
  • True Negative (TN), ou Vrai Négatif en français, ce qui ce qui signifie que le modèle n'a pas pu prédire une valeur normalisée avec un niveau de certitude supérieur au seuil défini, ce qui est en accord avec l'annotation invalide, puisque la métadonnée n'est pas présente dans le document.
  • False Positive (FP), ou Faux Positif en français, ce qui signifie que le modèle a prédit une valeur normalisée avec un niveau de certitude supérieur au seuil défini, et qu'elle n'est pas identique à celle de l'annotation, soit parce que les valeurs normalisées sont différentes, soit parce que la métadonnée n'est pas présente dans le document.
  • False Negative (FN), ou Faux Négatif en français, ce qui ce qui signifie que le modèle n'a pas pu prédire une valeur normalisée avec un niveau de certitude supérieur au seuil défini, alors que la métadonnée est présente sur la page et que l'annotation contient donc sa valeur normalisée.


Les critères actuellement utilisés sont calculés à partir de la mesure du nombre de cas précédents :

  • La précision : la capacité du modèle à fournir une réponse juste lorsqu'il en fournit une.

P = TP / (TP + FP)

  • Le rappel : la capacité du modèle à fournir une réponse.

R = TP / (TP + FN)

  • Le score F1 est une moyenne calculée à partir de la précision et du rappel.

F1 = 2 * (P * R) / (P + R)

L'objectif est bien sûr d'avoir un modèle ayant une précision, un rappel et donc un score F1 de 100%, mais comme ce n'est pas toujours le cas, il est nécessaire de définir certaines règles de priorité :

  • La première règle, qui est primordiale, est d'avoir une précision de 100% pour le seuil choisi. En effet, il est inconcevable que le modèle puisse se tromper lors de son utilisation, puisque la qualité des données extraites est l'enjeu principal de Tetrao. On préfère donc avoir une tâche pour laquelle la prédiction n'a pas été prise en compte et faire annoter le document par un opérateur humain, que l'on juge plus fiable.
  • La seconde règle est d'avoir un rappel aussi élevé que possible, afin que le modèle puisse traiter un maximum de documents. Les documents pour lesquels le modèle n'est pas capable d'émettre une prédiction dont le niveau de certitude est supérieur au seuil défini sont redirigés vers l'équipe d'annotation. Il faut donc en minimiser le nombre afin de ne pas faire augmenter sensiblement la quantité de travail qu'elle doit fournir. Toutefois, cela ne doit jamais se faire au détriment de la précision.
  • La troisième règle est de choisir un seuil suffisamment haut, car si le modèle rencontre un document sensiblement différent des documents avec lesquels il a été entraîné et que le seuil est trop bas, il peut se tromper car on ne lui a pas demandé d'être suffisamment certain du résultat qu'il renvoie. Ce cas de figure peut arriver si le format du type de document est changé par la société de gestion d'actifs et que le contexte local de la métadonnée n'est plus le même.

Une règle, plus générale, est de développer des modèles robustes et génériques. Autrement dit, les modèles devraient idéalement être en mesure de fonctionner sur n'importe quel type de document pour n'importe quelle métadonnée. Pour l'instant, on développe un modèle pour chaque langue pour chaque corpus, c'est à dire un type de document et une société de gestion d'actifs donnés.

Si vous ne devez retenir qu'une seule chose de ce chapitre, c'est cette règle : "Lorsqu'on ne sait pas, on laisse un annotateur effectuer la tâche."

Aucun modèle susceptible d'effectuer des prédictions fausses qui seront conservées ne doit être déployé en production.

Sources d'erreurs possibles des modèles modifier

Un modèle étant constitué d'une phase de classification, d'une étape de NER puis d'une étape de normalisation, les sources d'erreurs sont multiples. Il est important d'identifier la sources des erreurs du modèle, afin de pouvoir le corriger. Par ailleurs, il arrive que les erreurs du modèle soient liées à des anomalies dans les annotations, qui baissent la précision du modèle alors que celui-ci se trouve avoir raison. Dans ce cas, le modèle est valide et déployable, s'il n'y a pas d'autres erreurs par ailleurs.

Erreurs de classification modifier

Cela peut arriver si la configuration du modèle n'est pas efficace. Dans ce cas le modèle classifie comme positif un bloc ne contenant pas l'information, ce qui l'amène à faire de fausses prédictions. Il faut dans ce cas là trouver une meilleure configuration pour le modèle, en allant consulter un des documents sources pour voir quels modules seraient pertinents pour la configuration du modèle.

Exemple :

Un modèle cherche une performance CAD sur une page Web, qui se trouve dans un tableau avec d'autres pourcentages. La configuration du modèle ne contient ni top_module ni left_module, alors que les entêtes permettant d'identifier la bonne cellule du tableau se trouvent à gauche et en haut. Le modèle risque de ne pas bien fonctionner, et il faudrait donc lui rajouter les bons modules.

Erreurs du NER modifier

Cela peut arriver si le bloc retenu par la classification contient plusieurs données qui peuvent être choisies par le NER, et que ce dernier se trompe. Dans ce cas, on peut changer la granularité des blocs dans le modèle, essayer un autre type de NER, ou bien changer le paramètre maybe_text_formatting_mode qui correspond à la façon dont est transformé le texte visuel en chaîne de caractères.

Erreurs de la normalisation modifier

La normalisation étant un algorithme déterministe, les erreurs à ce niveau sont dues à un cas qui n'a pas été prévu par les développeurs, ce qui doit donc être corrigé.

Exemple :

Un modèle cherche un actif net. Sur le document, l'actif net est donné dans la forme 14.2 Mios €. La valeur annotée est donc 14200000, mais le normalisateur n'associe pas Mios à "millions", et renvoie donc 14.2.

Erreurs d'annotation modifier

Il existe plusieurs types d'erreurs d’annotations :

  • Les erreurs ne permettant pas au modèle d'apprendre correctement. C'est le cas quand la donnée recherchée se trouve à plusieurs endroits sur le document annoté, que les annotateurs annotent parfois à un endroit et parfois à un autre, et qu'il arrive que soient différentes aux différents endroits.

Exemple :

On recherche une date de performance CAD. Celle-ci figure à deux endroits sur le document, donc les annotations sont parfois à un endroit et parfois à un autre endroit. Pour certains des documents, les deux dates sont différentes : le modèle ne sait pas laquelle choisir : il risque de se tromper et est donc invalide.


  • Les erreurs permettant au modèle d'être déployé malgré une précision inférieure à 100%. C'est le cas quand le modèle a raison et que l'annotation est incorrecte.

Exemple :

Un annotateur se trompe sur une annotation, en annotant la mauvaise valeur par exemple. Le modèle trouve la bonne valeur, mais celle-ci étant donc différente de la valeur annotée, cela est compté comme un faux positif, et affecte la précision du modèle. Cependant, puisque le modèle a raison, il peut être déployé si aucune autre erreur n'est à signaler.

Autre type d'erreur modifier

Il peut arriver que l'entraînement d'un modèle n'aie pas pu s'effectuer correctement, par manque d'annotation. Dans ce cas, le modèle ne présente aucun résultat et on pourra trouver dans le dossier de sortie un FLAG expliquant l'erreur.

Exemple :

Lors d'un entraînement, un des sets de données était vide, on retrouve le fichier TRAINING_VALIDATION_OR_TEST_SET_IS_EMPTY.flag dans le dossier de sortie. Il faut corriger ce problème avant de retenter l'entraînement.

Arborescence d'un modèle modifier


TODO

Méthode de sélection modifier

On commence par regarder le dossier postprocessing, et on visualise les 3 courbes de résultats. Sur ces courbes figurent la précision, le rappel et le score F1 de l'ensemble du modèle.

Pour une tâche donnée, et pour chaque configuration testée :

  1. Vérifier le couple précision/rappel de chacun des trois sets training, test et validation.
  2. Si la précision est à 100% sur les trois ensembles, sur une plage de valeurs de threshold :
    1. Si le rappel est bon, le modèle est valide sur cette plage.
    2. Si le rappel est à 0 sur cette plage, le modèle n'est pas valide, et il faut voir comment il peut être amélioré.
  3. Si la précision n'est pas à 100% :
    1. Regarder les erreurs dans les fichiers de debugging csv.
    2. Si le modèle à finalement raison et que les erreurs sont dues à des anomalies dans les annotations, on peut considérer que la précision du modèle est de 100%
    3. Si le modèle se trompe, il ne peut pas être déployé et il faut identifier comment il peut être amélioré. voir sources d'erreurs

Si parmi toutes les configurations testées, une seule fonctionne : celle-ci peut être déployée. Si aucune ne fonctionne, il faudra trouver pourquoi les modèles ne fonctionnent pas.

Si plusieurs modèles fonctionnent : il faut choisir le modèle qui à la configuration la plus pertinente en fonction du template du fichier source.

Exemple :

La donnée recherchée est identifiable par un label se trouvant à sa gauche. Il faudra donc retenir le modèle qui présente un top_module dans sa configuration.

Attention : parfois le label est contenu dans le bloc "central", et dans ce cas il vaut mieux garder un modèle très simple, sans module supplémentaire.

D'une manière générale, on cherche à retenir le modèle le plus simple possible, mais également le plus pertinent possible, qui "voit" ce qu'un humain verrait pour trouver la bonne donnée.


Ceci est un "test". 

Note : l'intégralité de ce brouillon à été écrit dans le modificateur de code

TEST TABLEAU :

1 2 3 4

TEST LIEN : [1]