Have same number of periods and comparable time window per company

[arianelestrade]

Actuellement on requête aléatoirement un nombre x d'observations SIRET x périodes. Grâce au tirage aléatoire, le nombre de d'observation avec des périodes différentes par SIRET est relativement similaire et bas. Cependant, lorsqu'on oversample la proportion d'observations avec Outcome TRUE (via fonction OversampledSFDataset), ce nombre peut augmenter assez fortement pour les entreprises avec Outcome TRUE.

L'objectif serait de pouvoir requêter un dataset en contrôlant le nombre de périodes temporelles et la fenêtre temporelle par SIRET. Par exemple pour tous les SIRET, avoir le même nombre d'observations (ie de périodes temporelles) en conservant une fenêtre temporelle comparable (par exemple des données allant de la période janvier 2015 - janvier 2018).

Cela remplirait plusieurs objectifs : 1) Eviter de sur-représenter certaines entreprises par rapport à d'autres. 2) Pouvoir faire des séries temporelles à termes sur ces données : chercher à identifier des pattern (des anomalies) dans l'évolution temporelle des variables explicatives sur la période précédant une défaillance pour une entreprise (SIRET) donnée.

[pierrecamilleri]

Le suréchantillonnage ou le sous-échantillonnage introduisent de facto un biais dans l'apprentissage ; et donc le fait d'avoir de nombreuses observations pour la même entreprise n'est pas pour moi un problème en soi (je faisais ça sur l'ancien modèle, notamment en travaillant uniquement sur les données Bourgogne-Franche-Comté pour gonfler un peu artificiellement le nombre d'observations défaillantes), tant qu'on veille à réunir ces observations corrélées pour la validation et le test.

Par contre, je pense qu'un suréchantillonnage un peu trop agressif (si le nombre d'observations des établissements défaillants > 3 par exemple) est surtout inutile, les différentes observations d'un même établissement risquent d'être très similaires en matière de données financières (màj une fois par an) et cela représente un coût en mémoire et temps de traitement des données. Un risque à noter tout de même : vu que les données financières sont au niveau de l'entreprise, un échantillonnage aléatoire au niveau de l'établissement pondère automatiquement l'observation des variables financières par la taille de l'entreprise (en nb d'établissements). Donc s'il faut stratifier l'échantillonnage, je dirais que c'est pour éviter la surreprésentation des grandes entreprises.

Nous avions opté pour du sous-échantillonnage pour la dernière liste de détection, et je pense que vu le volume de données, ça a le mérite d'être efficace. Nous avions fait en sorte de n'avoir qu'une observation par entreprise (en post-traitement avec R) mais à mon avis, la différence avec un échantillonnage aléatoire des entreprises est minime.

Concernant 2. le traitement en séries temporelles, on dispose déjà d'une partie de l'historique disponible dans les observations actuelles (3 derniers exercices, quelques variables passées sur l'effectif, les dettes URSSAF), je ne saurais pas faire plus de choses personnellement avec des observations plus nombreuses par entreprise / établissement.

[arianelestrade]

Le suréchantillonnage ou le sous-échantillonnage introduisent de facto un biais dans l'apprentissage ; et donc le fait d'avoir de nombreuses observations pour la même entreprise n'est pas pour moi un problème en soi (je faisais ça sur l'ancien modèle, notamment en travaillant uniquement sur les données Bourgogne-Franche-Comté pour gonfler un peu artificiellement le nombre d'observations défaillantes), tant qu'on veille à réunir ces observations corrélées pour la validation et le test.

--> Je suis d'accord. Ensuite pouvoir contrôler ce biais pour voir dans quelle mesure ça peut par exemple améliorer la qualité de prédiction du modèle reste à mon sens intéressant.

Concernant 2. le traitement en séries temporelles, on dispose déjà d'une partie de l'historique disponible dans les observations actuelles (3 derniers exercices, quelques variables passées sur l'effectif, les dettes URSSAF), je ne saurais pas faire plus de choses personnellement avec des observations plus nombreuses par entreprise / établissement.

--> L'idée serait justement de faire un peu plus que ce qu'on fait actuellement. Y réfléchir serait intéressant car même si la profondeur historique reste modeste, elle commence à être intéressante pour les variables mensuelles, et ne peut que grossir. Les pistes dans ce sens sont nombreuses :

• utiliser des modèles de séries temporelles
• ou simplement extraire des features temporelles qui prendraient en compte l'évolution dans le temps des variable, un peu comme c'est le cas actuellement avec les variables retardées, mais en plus fouillé, en regardant la littérature de détection d'anomalie.

Quoi qu'il en soit, cette issue n'est pas prioritaire pour le moment, il s'agit plutôt d'un élément à garder en tête pour ultérieurement.

[lcrmorin]

Ce point avait aussi attiré mon attention, mais plutôt pour ce qui concerne l'overlap des labels (Ceux-ci ne sont plus iid). Pour avoir passé pas mal de temps sur un problème similaire (plutôt dans un contexte de finance de marché), ce point semblait assez prioritaire. Nous n'avions pas vraiment conclu par une démonstration pratique...

Pour ce qui concerne des solutions, en général principalement des tirages pseudo-aléatoire / du bootstrap, ceux ci ne font pas de sens sur un échantillon d'entrainement dont la plage temporelle est du même ordre de grandeur que l'horizon de la target. On pourrait se lancer dans des solutions un peu 'système D', par ex. essayer de limiter le tirage à un par année. D'ailleurs ca garantie aussi un minimum de variation dans les features. (Ca va aussi dans le sens de prendre une target plus courte : réduction des overlap, possibilité de prendre deux années pour l'entrainement... mais c'est une autre discussion).