Codification automatique & mutualisation pour la PCS2020

Séminaire DMS - SSP Lab

13 décembre 2023

Sommaire


I. Contexte et fastText

II. Mutualisation : Données et méthodologie

III. Résultats et interprétations

IV. Suite et fin des travaux

I. Contexte et fastText

La PCS2020

  • Cas d’usage de codification nombreux
    • Recensement de la population (RP)
    • Enquêtes ménage
  • Une tâche pas toujours évidente
    • Matrice de libellés mise à jour
    • Des libellés hors liste écrits en clair

Vers une sortie de Sicore

  • Logiciel développé en C
    • Parfois instable
    • Difficilement maintenable car compétences très limitées
  • Pas de possibilité d’arbitrage entre efficacité et fiabilité
    • Pas de pilotage de la charge de reprise
    • Renvois en reprise manuelle potentiellement trop nombreux, induisant un coût important, notamment pour le pôle PCS
  • Coût important d’adaptation et de maintenance de l’outil
    • Comportements déclaratifs changeant avec le temps
    • Pour l’APE, seulement 30% des bulletins du guichet unique codés par Sicore
  • Avec les refontes de plusieurs nomenclatures, l’occasion parfaite pour une nouvelle méthodologie
    • Exemple du passage de la PCS2003 à la PCS2020

fastText : Historique

  • Bibliothèque C++ open source développée par Meta (anciennement Facebook) en 2015

  • Dernière version sortie en avril 2020

fastText : Les + et les -

  • Les + :
    • Faible utilisation des ressources
    • Rapidité d’entraînement
    • Bonnes performances en classification supervisée
    • Peu exigeante en termes d’infrastructure
    • Fournit une métrique de confiance pour chaque prédiction
  • Les - :
    • Peu maintenue
    • Documentation perfectible
    • Réentrainement from scratch à chaque projet, par opposition à du fine-tuning
    • Pas de recours à des plongements pré-entraînés

fastText : Historique des travaux

  • Sur la PCS2020 :
    • Expérimentations de fastText dès 2020 par T. Loisel, T. Leroy et S. Himpens
    • Continuation dès 2021 par Théo Leroy, Tom Seimandi et Lucas Malherbe
    • Mise en production dans le RP par Etienne Maeght dès 2022
    • Travaux de mutualisation pour les enquêtes ménage par Samuel Bazaz en 2023
  • Sur l’APE :
    • Travaux réalisés par Tom Seimandi et Thomas Faria en 2022
    • Modèle déployé en Novembre 2022
  • Sur les données de caisse :
    • Premiers résultats à partir de 2018, par Yves-Laurent Benichou, Julie Djiriguian et Jérémy L’Hour
    • Tests avec l’équipe ICA sur la NAF en 2020
    • Tests par l’équipe données de caisses sur la COICOP dans les DROM en 2021
    • Travaux de Julien Peignon sur les hard discounters en 2023

Codification automatique avec fastText

Prise en compte des variables annexes

  • Concaténation du libellé avec les noms et valeurs des variables annexes :
Libellé NAT TYP EVT SUR
Chanteur d’opéra NaN X 01P NaN
🢃

“Chanteur d’opéra NAT_NaN TYP_X EVT_01P SUR_NaN”


  • Enjeu de comment choisir les variables catégorielles à inclure

Prédictions et scores


  • Pour chaque code PCS, on obtient une probabilité d’attribution
  • fastText renvoie la prédiction à la probabilité la plus haute
    • Ou les k meilleures prédictions si désiré
  • Score de la prédiction : différence de probabilité des deux meilleures prédictions
    • A quel point la meilleure prédiction se distingue-t-elle bien des autres ?
    • Réflexions en cours pour un score plus pertinent
  • Chaque prédiction n’est conservée que si elle passe un certain seuil de score
    • Sinon, elle doit passer en reprise manuelle

Pertinence du score - Cas du RP

Pourquoi mutualiser ?


  • Des vagues d’enquête à codifier avec peu ou pas données historiques labellisées en PCS2020
    • Entraînement de modèles difficile
  • Objectif d’amélioration des performances
  • Un rapprochement des questionnaires propice à la mutualisation
    • Tronc Commun des Enquêtes Ménage (TCM)
    • Questionnaire du RP également amené à changer
  • Objectif de réduction des coûts de maintenance
    • Mutualisation des questions méthodologiques

Calendrier des travaux sur 2023


  • Stage de Samuel Bazaz de février à juillet 2023
    • Rapport de stage disponible ici
  • Un premier semestre dédié à la construction de l’architecture du projet
    • Un outil généralisé de codification permettant la génération et comparaison de modèles par enquête
    • Itérations sur le preprocessing et la génération d’hyperparamètres optimaux
    • Code disponible ici
  • Un second semestre dédié à la génération et l’interprétation des résultats
    • Utilisation de l’outil pour évaluer les performances des différentes approches
    • Exploitation des résultats et conclusions
    • Chiffres bruts disponibles ici
    • Annexe technique en cours de rédaction !

Enquêtes incluses - Cadrage du modèle

Enquêtes ajoutées - Analyse des performances

Enquêtes à venir - Tests pratiques



II. Mutualisation : Données et méthodologie

Catégories de professions étudiées

  • PROFS : Professions Salariées
  • PROFI : Professions Indépendantes
  • PROFA : Professions Antérieures
  • PROFA - Hors RP : Artificiellement rajoutée en excluant les données du RP des mutualisations
    • Ceci est dû au fait que pour le RP la PCS2020 des professions antérieures n’est codée que sur 2 positions, pouvant ainsi dégrader les performances des modèles mutualisés.

L’étude est décorrélée pour les 3 catégories, notamment en raison des champs disponibles différents.

Volumes de données dédoublonnées

En milliers d’observations



  • Des volumes en hors liste principalement portés par le RP

Volumes - PROFS

En milliers d’observations


Volumes - PROFI

En milliers d’observations



  • Des volumes hors liste très faibles pour la plupart des enquêtes

Volumes - PROFA

En milliers d’observations



  • Des données RP moins prépondérantes pour les professions antérieures

Que cherche-t-on à comparer ?


  • Mesurer sur chaque enquête l’évolution des performances du modèle de codification lors de l’agrégation de plusieurs bases d’entraînement distinctes.
  • Or toutes les bases d’enquêtes n’ont pas les mêmes champs disponibles
    • A variables égales, pas nécessairement les mêmes types de réponses
  • Le but a donc été d’estimer dans un premier temps la méthode d’agrégation optimale entre plusieurs bases différentes.
    • Faut-il conserver l’union des variables disponibles ? L’intersection ?
  • Dans un second temps, l’objectif est de mesurer l’impact de la cohérence des données dans une base agrégée.
    • Peut-on mélanger les libellés hors & sur liste dans une base d’entrainement ?

Une estimation par Monte-Carlo


  • Dans une optique de généralisation des résultats, sur chaque configuration :
    • Répétition des phases de train, de test et d’évaluation 10 fois sur des splits disjoints différents
    • Performance médiane retenue pour comparaison ultérieure
    • Information disponible sur la variance des résultats

Parenthèse technique : les hyperparamètres


  • Définition : Constantes prédéfinies d’un modèle dont les valeurs influent sur l’entrainement
    • Ex: Dimension de l’embedding, taille des N-Grams, etc.
  • On peut trouver un ensemble de paramètres optimaux via une recherche exhaustive appelée grid search.
  • Quels hyperparamètres pour la mutualisation ?

Configurations testées - Hyperparamètres des modèles


  • 0 : Hyperparamètres repris tels quels des travaux sur les données du RP.
  • eg0 : Mêmes hyperparamètres que la config 0, mais cette fois-ci la concaténation se fait « à volumes égaux ». On ne conserve qu’un échantillon aléatoire de chaque table, aligné sur la taille de la plus petite des tables étudiées, pour retirer tout effet de volume.
  • gs0 : Hyperparamètres issus du grid search effectué sur l’ensemble des tables, qu’il s’agisse des enquêtes individuelles ou des tables entières concaténées.
  • eggs0 : Non testée en raison de résultats préliminaires non concluants.

Modes de concaténation testés


  • Seul : Pas de concaténation, le modèle est entraîné directement sur l’enquête sur laquelle on veut faire les tests de performances.
  • Union : La méthode de concaténation la plus conservatrice, l’ensemble des variables de chaque table sont conservées, quitte à rajouter des NaN pour les enquêtes ne disposant pas des variables des autres.
  • Intersection no prio : Une concaténation sur l’intersection stricte des colonnes de chaque table.
  • Intersection (+ prioritaires) : Une concaténation sur seulement l’intersection des variables disponibles pour chacune des bases accumulées, en forçant tout de même cette fois à garder un ensemble de variables qualifiées de prioritaires.

Variables par enquête - PROFS


Variables par enquête - PROFI


Variables par enquête - PROFA


III. Résultats et interprétations

Schéma de codification


Résultats initiaux bruts - Cadrage

Travail sur l’ensemble des libellés



Chiffres bruts disponibles ici

Observations principales - Grid Search


  • Une étape très gourmande en temps et en calculs

Observations principales - Grid Search


  • Des hyperparamètres qui ne semblent pas suivre une logique particulière

  • Des écarts de performance très faibles avec la configuration initiale

  • Conclusion : Parmi les intervalles de valeurs issus des travaux précédents, peu d’impact des variations sur les performances
    • Refaire un grid search à chaque ajout de données ou d’enquêtes ne serait alors pas forcément nécessaire
  • Pour la suite, on se concentrera donc sur la configuration gs0
    • La configuration eg0 donne des résultats strictement inférieurs, piste non approfondie

Observations principales - Modes de concaténation

  • Mode Union strictement dominé
    • Malgré la conservation de toutes les informations possibles, la présence de trop de NaN dans les colonnes dégrade les performances
  • Interprétation : le modèle va apprendre à l’entrainement à se servir de toutes les variables possibles pour faire ses prédictions, même si une majorité sera manquante lors des tests, et ce au détriment d’une focalisation plus importante sur les variables importantes

Observations principales - Modes de concaténation

  • Mode Inter no prio dominé par le mode Intersection
    • 4.5ppt d’écart en moyenne sur les performances
    • Effet inverse cette fois-ci : se limiter à l’intersection des variables disponibles restreint trop l’information
    • Mode Inter no prio parfois équivalent au libellé seul (ou presque)
  • Si mutualisation il y a, c’est donc un mode avec variables indispensables à privilégier

Choix des variables prioritaires

Effets incrémentaux sur la mutualisation


Choix des variables prioritaires

Effets incrémentaux sur le mode seul


La mutualisation est-elle donc bénéfique ?


  • En général oui !
  • Il reste maintenant à regarder les performances sur ce qui nous intéresse : les libellés hors liste.
    • Ces analyses seront répliquées sur une architecture “à neuf” pour plus de validité.

Résultats - PROFS


Résultats - PROFI



  • Des taux de convergence plus élevés que sur PROFS !

Résultats - PROFA


Dans quels cas la mutualisation marche-t-elle moins bien ?


  • Si une enquête dispose de :
    • Plusieurs variables supplémentaires au tronc commun & pertinentes
      • Ex: Informations sur les communes pour l’EEC
    • Un volume d’entraînement déjà important
    • Un code PCS2020 codé sur un nombre différent de positions
      • Ex: RP sur PROFA
  • Focus sur VRS PROFA
    • Beaucoup de trous dans les variables annexes ?

Bilan des expérimentations


  • Influence du choix des paramètres du modèle
    • Peu d’influence une fois limité à un hypercube bien choisi
  • Quel mode de concaténation choisir ?
    • Intersection des variables, modulo une liste de variables prioritaires à conserver
  • Quelles variables annexes prioriser ?
    • Estimation de l’effet incrémental de chaque variable
    • Liste de variables prioritaires redéfinie, cohérente avec les variables annexes généralement disponibles
  • Peut-on mélanger libellés sur et hors liste dans l’entraînement ?
    • Oui, cela augmente bien les performances
  • Quid du data drift ?

Limites de l’analyse


  • Plus la base étudiée est petite, plus la variance des performances est élevée
    • Avec parfois jusqu’à 20ppt d’écart entre les 1ers et 3è quartiles sur MDG

IV. Suite et fin des travaux

Développer une architecture à neuf


  • Un code actuel complexe, fait pour la comparaison de multiples modèles
    • Maintenant, le modèle est (quasiment) sélectionné
  • Objectif d’un code à neuf, fait pour l’utilisation du modèle sélectionné en pratique
    • Une cible plus minimaliste et plus claire
    • Architecture finale largement inspirée des travaux sur le RP
  • Développement d’une API pour la codification automatique en PCS2020
  • Possibilité dès lors de répliquer les visualisations issues d’autres travaux
    • Ainsi que quelques sanity checks (ex: performances par CS)

Exemples d’output dans le futur

  • Visualisation des prédictions en fonction du score sur APE

Exemples d’output dans le futur


  • Taux d’observations pour lesquelles le code est dans le top k des prédictions de fastText


Et en pratique ?

  • Fin de la mise sur papier des résultats d’ici janvier 2024
  • Développement et tests du code à neuf et de l’API au premier semestre 2024
    • Incluant la réplication des analyses majeures du modèle RP
    • Incluant aussi l’estimation de la charge de reprise manuelle à l’issue
  • Groupe de travail à venir pour les réflexions techniques :
    • Renvoi en reprise manuelle, réentraînement, non codables, etc.

Merci pour votre attention !

Des questions ?


Ressources disponibles

https://ssplab.pages.lab.sspcloud.fr/presentations-mutualisation-pcs-2020/