Un certain type de calme suit une bonne exécution de validation. Les chiffres à l'écran, AUC à 0.91, et tout le monde hoche la tête lors de la réunion matinale parce que, pour une fois, personne n'avait de raison de poser une question de suivi. Faites-moi confiance, c'est une bonne sensation.

Mais c'est aussi quelque chose que j'ai appris à ne pas saisir ou faire trop confiance. Le modèle est enfin mis en ligne ce vendredi. Rien de dramatique à ce sujet, pas de salle de guerre, pas de nuits blanches.

Juste un déploiement qui ressemait exactement à la dizaine précédente. D'ici mardi, quelque chose s'était mal passé d'une manière qui a mis du temps à être remarquée. La précision sur les cas signalés s'était discrètement aggravée, et rien de cela n'est apparu comme une erreur.

Pas de plantage, pas d'alerte, pas de ligne rouge sur aucun tableau de bord que quelqu'un regardait vraiment. Il était simplement là, devenant pire, jusqu'à ce qu'une équipe en aval se fatigue avec une file d'attente de révision remplie de drapeaux inutiles et demande pourquoi. C'est ainsi qu'il a été trouvé.

Pas un système qui se détecte lui-même. Une personne, assez irritée pour aller chercher. Et voici la partie qui me dérange encore un peu : rien dans le code n'avait changé.

Le modèle et le pipeline étaient exactement les mêmes qu'la veille. Ce qui avait changé, c'était le monde en dessous. Un nouveau niveau de tarification avait été lancé quelques jours plus tôt, et les clients sur celui-ci effectuaient des transactions plus souvent, avec des montants plus faibles à chaque fois.

J'ai vérifié une fonction à la fois, et rien ne semblait faux : la valeur de la transaction était dans une plage normale, et il en allait de même pour la fréquence des transactions. Ce n'est qu'au moment où je les ai regardées ensemble que les données sont clairement devenues quelque chose d'autre, et il n'y avait aucun contrôle dans le pipeline conçu pour attraper cela. J'avais déjà mis en place une surveillance de dérive avant cela et je pensais vraiment être couvert.

Eh bien, il s'est avéré que je ne l'étais pas. Le contrôle que j'avais faisait exactement ce que je lui avais demandé de faire, en surveillant chaque fonction individuellement, exactement comme je l'avais construit, et il aurait été là, signalant vert pendant toute la durée. Ce qui est assez étrange, honnêtement.

La surveillance n'était pas cassée. Et elle n'était pas paresseuse ou mal construite non plus. Elle répondait simplement à une question plus étroite que celle qui importait vraiment.

La partie qui se passe mal en silence. Cette question plus étroite est celle que la plupart des surveillances de dérive posent, y compris la mienne à l'époque. La distribution d'une seule fonction s'est-elle déplacée ? Prenez les valeurs de cette semaine et les valeurs de l'entraînement, alignez-les sous forme d'histogrammes, et obtenez un nombre.

Sur papier, ce n'est pas une mauvaise idée. C'est juste incomplet. Il fonctionne jusqu'au moment où l'échec n'est pas dans une seule fonction, mais dans la manière dont deux fonctions se déplacent ensemble, et c'est une manière beaucoup plus facile pour les données réelles de se casser que la plupart des rapports admettent.

L'affaire du niveau de tarification est un exemple propre parce que rien de cela ne semble faux isolément. Exécutez PSI sur avg_transaction_value seul, correct. Exécutez-le sur num_transactions_30d seul, également correct.

La relation entre les deux s'est inversée, et PSI, par conception, ne regarde jamais deux colonnes à la fois. Il ne peut pas. Ce n'est pas un défaut de la mesure autant que c'est une limite qu'elle n'a jamais été conçue pour franchir.

Alors la question devient : comment vérifier une relation au lieu d'une distribution ? Il s'avère que la réponse n'est pas une statistique exotique que vous devez apprendre. C'est simplement demander à un modèle de le remarquer pour vous. Laissez un classifieur faire le remarquer.

L'astuce a un nom, validation adversarial, et ça sonne plus sophistiqué qu'il n'en est. Étiquetez vos lignes d'entraînement 0, étiquetez un lot frais de lignes de production 1, et entraînez un classifieur pour les distinguer. Si les deux lots proviennent vraiment de la même distribution, il ne peut pas faire mieux que de deviner, AUC près de 0.5. S'il peut les séparer, quelque chose s'est déplacé, et parce que le classifieur reçoit toutes les fonctions à la fois, il détecte exactement le type de changement conjoint.