Je retourne étudier l’IA, mais je commence encore par la donnée

Je retourne aux études cette année pour faire une maîtrise en intelligence artificielle à l’Université Laval. On parle d’IA partout et je veux comprendre ce qui se passe entre la base de données et la prédiction, pas juste apprendre le vocabulaire du moment.

Je garde mes réflexes d’architecte. Quand je vois un modèle, je pense tout de suite aux sources, aux définitions et au moment où l’information est devenue disponible. Un algorithme n’apprend pas directement « le risque qu’un client parte ». Il reçoit une matrice de nombres et cherche une relation statistique avec une cible qu’on a nous-mêmes définie.

Construire un exemple que le modèle peut apprendre

Prenons un exemple simple : prédire si un client passera 60 jours sans commander. Il faut d’abord choisir une date d’observation, comme si on arrêtait l’horloge ce jour-là. Les features décrivent seulement ce qu’on connaissait à cette date. L’étiquette, elle, regarde ce qui s’est produit dans les 60 jours suivants.

Une ligne d’entraînement pourrait ressembler à ceci :

client_id:               1842
date_observation:        2017-06-30
jours_depuis_commande:   24
commandes_90_jours:       3
retours_90_jours:         1
solde_impaye:           0.00
aucune_commande_60j:      0   ← cible connue seulement après le 29 août

Le pipeline doit ensuite répéter le même travail pour plusieurs dates historiques :

  1. extraire les transactions disponibles à la date d’observation;
  2. relier les clients sans mélanger leurs identifiants entre systèmes;
  3. calculer les variables avec une fenêtre définie, par exemple les 90 jours précédents;
  4. regarder les 60 jours suivants pour produire la cible;
  5. conserver la version des règles et la provenance de chaque colonne.

Cette séparation évite une fuite de données. Si j’utilise le statut « compte fermé » mis à jour après le départ du client pour prédire ce même départ, le modèle obtient une information qu’il n’aurait jamais eue au moment de décider. Le score de test devient magnifique et le système tombe à plat en production.

Entraîner ne veut pas dire mémoriser

Le jeu de données est généralement séparé en trois parties. L’entraînement sert à ajuster les paramètres du modèle. La validation aide à choisir les variables et les réglages. Le test reste à l’écart jusqu’à la fin pour estimer le résultat sur des cas jamais utilisés pendant la construction.

Avec des données qui évoluent dans le temps, je préfère une séparation chronologique à un mélange aléatoire : entraîner sur les mois les plus anciens, valider sur les suivants et tester sur la période la plus récente. C’est plus proche de la vraie utilisation, où on demande au passé d’aider avec demain.

Le modèle calcule ensuite un score, par exemple 0,72. Ce nombre n’est pas une certitude de 72 %. Il dépend de l’algorithme, de sa calibration et surtout de la population observée. Pour décider quoi en faire, il faut choisir un seuil et regarder les erreurs des deux côtés :

  • un faux positif déclenche une intervention pour un client qui aurait commandé quand même;
  • un faux négatif laisse partir un client que le système n’a pas signalé;
  • un vrai positif n’a de valeur que si l’équipe peut réellement agir à temps.

L’exactitude globale peut cacher le problème. Si seulement 5 % des clients partent, un modèle qui répond toujours « non » affiche déjà 95 % d’exactitude. La précision, le rappel et une matrice de confusion disent beaucoup mieux quelles erreurs il fait.

Le dictionnaire de données fait partie du modèle

Dans une présentation, le jeu d’entraînement est déjà propre. En entreprise, on tombe plutôt sur CODE_2, un code qui a changé de sens après une migration, ou sur deux systèmes qui utilisent le même numéro pour parler de deux affaires différentes.

Je veux donc un dictionnaire qui indique pour chaque feature sa source, son type, son unité, sa règle de calcul, sa période de validité et son responsable. Si CODE_2 voulait dire « client commercial » avant 2015 et « compte en révision » après la migration, le pipeline doit tenir compte de cette date. Remplacer les valeurs manquantes par zéro sans poser la question peut aussi inventer une information : « inconnu » et « aucun » ne sont pas toujours la même chose.

Le travail ne s’arrête pas au déploiement. Le pipeline de production doit refaire exactement les transformations apprises, enregistrer la version du modèle et surveiller si la distribution des features ou le taux d’erreur change. Une nouvelle politique commerciale peut rendre l’historique moins représentatif en quelques semaines.

Avant de comparer deux algorithmes, je veux donc être capable de reconstruire une ligne d’entraînement à une date précise et d’expliquer chaque valeur. Pour l’instant, la maîtrise me confirme une chose très pratique : un modèle commence par une cible bien définie, une horloge qu’on respecte et beaucoup de plomberie de données.

Et CODE_2 ne va malheureusement pas s’expliquer tout seul pendant que je suis en classe.