Filters - Githubissues

La branche "filters" introduit les filtres de recherche (pour l'instant seulement 'date') en ajoutant au df renvoyé par la fonction get_sentence_dataframe_from_paragraph_dataframe() présente dans le module sententizer.py, une colonne "Date". Cette colonne contient :

Une liste de date si une date est présente dans le champs "sentence"
False si le champs "sentence" ne contient pas de date
"BL" (black list) si le champs "sentence" contient une date, mais qu'il n'est pas judicieux de lui appliquer le filtre.

Le dernier point soulève le problème suivant : quelles dates sont pertinentes pour l'user et lesquelles ne le sont pas ? On voit apparaitre des patterns donnant des "faux positifs" de date (les normes ISO, les intitulés de projets ou de documents contenant des dates...etc). On choisit donc une approche de white list, autrement dit, une série de mots qui doivent être présents avant la date pour que celle-ci soit "validée". Pour l'instant ces mots sont présents dans un csv dans le dossier "webapp". C'est bien sur une approche à améliorer, ainsi que les règles de parsing pour les dates.

En résumé, ces règles de parsing et ces white words ne relèvent pas d'une décision à priori évidente mais de notre propre jugement et de la pertinence par rapport au projet. Je vous exposerai dans une issue les choix déjà faits mais aussi les cas tangents sur lesquels j'aimerai avoir l'avis de tout le monde (voir même du ministère ?)

Un mot sur cette branche : elle est partie d'une ancienne version du projet cas il y a eu un certains nombres de commit pour lequel le parsing de pdf soulevait une erreur, il faudrait donc appliquer ce filtre à la dernière version du sententizer.py, mais là je manque d'expérience dans Git pour savoir comment faire exactement.

Un mot sur cette branche : elle est partie d'une ancienne version du projet cas il y a eu un certains nombres de commit pour lequel le parsing de pdf soulevait une erreur, il faudrait donc appliquer ce filtre à la dernière version du sententizer.py, mais là je manque d'expérience dans Git pour savoir comment faire exactement. Sur ce point on pourra le faire en pair coding éventuellement :) C'est vrai que l'architecture a pas mal changé, mais comme tu as codé sous forme d'objet ce devrait être facilement déplaçable et appelable !

En résumé, ces règles de parsing et ces white words ne relèvent pas d'une décision à priori évidente mais de notre propre jugement et de la pertinence par rapport au projet. Je vous exposerai dans une issue les choix déjà faits mais aussi les cas tangents sur lesquels j'aimerai avoir l'avis de tout le monde (voir même du ministère ?) J'ai un peu de mal à comprendre les notions de contexte, mais j'essayerai de runer le code demain pour mieux comprendre le type de date qui est identifié. Mais globalement le concept de white list me paraît pertinent, et à même de faire une bonne pré-selection des engagements datés. Si je comprends bien les mots suivants apparaissent très souvent à coté d'une date, qui est un entier de quatre digits supérieurs à 0.
[('en', 1452),
('En', 506),
('depuis', 223),
('fin', 151),
('à', 140),
('décembre', 134),
('Depuis', 114),
('ici', 88),
('année', 87),
('de', 81),
('et', 78),
('octobre', 65),
('juin', 65),
('mars', 62),
('janvier', 56),
('novembre', 54),
('septembre', 51),
('dès', 51),
('juillet', 45),
('horizon', 42),
('entre', 39),
('consolidé', 38),
...
('sociale', 1)]
Le dernier point soulève le problème suivant : quelles dates sont pertinentes pour l'user et lesquelles ne le sont pas ? A mon avis, simplement en prenant les mots ayant plus d'un seuil d'occurence (disons 20, en faisant attention à tout passer en minuscule), on a déjà un bon proxy de ce qu'est une date "classique".

Et maintenant la question de l'engagement: est-ce que les résultats de l'approche par patterns t'ont semblé probant ? Si ça a l'air de marcher pour la majorité des dpefs, ça peut être très bien pour "résumer" un dpef sur la page de l'entreprise.

Sinon, à mon avis une des manières les plus simple de qualifier un niveau d'engagement d'une phrase, c'est de simplement utiliser la proximité vectorielle avec les termes de ta liste ["engager", "viser", 'objectif', 'atteindre', 'prévoir'] --> on peut obtenir un score de proximité au moment du parsing. Pour chaque entreprise on n'aura ensuite qu'a prendre les tops. Je pense que le résultats peut vraiment être pas mal !

Au niveau de l'intégration dans la recherche, il y a deux endroits ou ca peut être fait:

au niveau de l'entreprise, prendre les plus forts engagements contenant une date
au niveau de la recherche par mort clef, rajouter un bouton "daté" et un bouton "engagement" (ou alors combiner en un seul "engagement daté"

Un mot sur cette branche : elle est partie d'une ancienne version du projet cas il y a eu un certains nombres de commit pour lequel le parsing de pdf soulevait une erreur, il faudrait donc appliquer ce filtre à la dernière version du sententizer.py, mais là je manque d'expérience dans Git pour savoir comment faire exactement. Sur ce point on pourra le faire en pair coding éventuellement :) C'est vrai que l'architecture a pas mal changé, mais comme tu as codé sous forme d'objet ce devrait être facilement déplaçable et appelable !

Réponse : Je suppose que le pair coding signifie "coder à deux". Dans tous les cas je vais regarder l'architecture du nouveau code mais les fonctions de filtres fonctionnement par le même mécanisme que le parsing donc ça ne devrait pas poser de problèmes.

En résumé, ces règles de parsing et ces white words ne relèvent pas d'une décision à priori évidente mais de notre propre jugement et de la pertinence par rapport au projet. Je vous exposerai dans une issue les choix déjà faits mais aussi les cas tangents sur lesquels j'aimerai avoir l'avis de tout le monde (voir même du ministère ?) J'ai un peu de mal à comprendre les notions de contexte, mais j'essayerai de runer le code demain pour mieux comprendre le type de date qui est identifié. Mais globalement le concept de white list me paraît pertinent, et à même de faire une bonne pré-selection des engagements datés. Si je comprends bien les mots suivants apparaissent très souvent à coté d'une date, qui est un entier de quatre digits supérieurs à 0.

Réponse : La notion de contexte désigne deux choses :

soit une condition sur l'objet doc (une collection de tokens), malheureusement on a une prise assez faible à ce niveau là du aux limitations de Spacy en Français sur les dependencies et sur les named entites mais par exemple si la date est situées entre deux quotes, on admet qu'il s'agit de l'intitulé d'un programme ou d'une initiative donc par forcément pertinent sur une recherche de date.
soit le mot précédent la "date" en question. Ce critère ci offre une bonne discrimination pour les dates, mais il faut une liste exhaustive, pas une correspondance de lemme et pas case-insensitive, car cela fait souvent la différence entre une date authentique ou une date faisant partie du nom d'un programme.

Le dernier point soulève le problème suivant : quelles dates sont pertinentes pour l'user et lesquelles ne le sont pas ? A mon avis, simplement en prenant les mots ayant plus d'un seuil d'occurence (disons 20, en faisant attention à tout passer en minuscule), on a déjà un bon proxy de ce qu'est une date "classique".

Réponse : effectivement on pourrait ne prendre les mots de plus qu'un certain seuil d'occurence mais souvent les mots avec peu d'occurence apparaissent dans une phrase contenant beaucoup de sens, et à l'inverse, des mots précédent une date non interessante apparaissent beaucoup (ça suit un peu le principe de certains algos de retrieving, qui donnent beaucoup d'importance aux mots rares). Donc il faut trier à la main... Ca n'est pas très long heureusement et j'ai tout ce qu'il faut dans un notebook pour ça. Je vais le cleaner un peu et le rendre plus user friendly. De manière générale, tous ces problèmes se comprennent bien mieux avec des exemples et j'en ai donné très peu, désolé pour ça. Je vais reprendre ces problèmes avec des exemples concrets dans des une issue.

Et maintenant la question de l'engagement: est-ce que les résultats de l'approche par patterns t'ont semblé probant ? Si ça a l'air de marcher pour la majorité des dpefs, ça peut être très bien pour "résumer" un dpef sur la page de l'entreprise.

Sinon, à mon avis une des manières les plus simple de qualifier un niveau d'engagement d'une phrase, c'est de simplement utiliser la proximité vectorielle avec les termes de ta liste ["engager", "viser", 'objectif', 'atteindre', 'prévoir'] --> on peut obtenir un score de proximité au moment du parsing. Pour chaque entreprise on n'aura ensuite qu'a prendre les tops. Je pense que le résultats peut vraiment être pas mal !

Réponse : Oui pour moi l'approche par pattern pour récupérer les phrases avec engagement ou avec engagement chiffrés était plutôt prometteuse, avec effectivement une recherche de pattern lemme de ["engager", "viser", 'objectif', 'atteindre', 'prévoir']. Là encore j'ai un peu travaillé dans mon coin sur les notebook sans trop partager... Mais effectivement je pense qu'utiliser directement la proximité vectorielle peut être très probant. A ce propos, je voulais essayer la recherche par proximité vectorielle avec ton notebook mais je n'ai pas réussi à l'utiliser. Quelle version fonctionne chez toi ?

dataforgoodfr / batch7_rse

Filters #39