Un score ne vaut que par son test
À retenir : Un bon score devient une preuve utile seulement si le test reflète les conditions réelles d’utilisation du modèle.
Définir la prédiction avant de choisir la métrique
Imaginons un classifieur qui signale les demandes d’assistance à traiter en urgence. Prévoir l’urgence à l’arrivée d’une demande est différent de la reconnaître une fois le problème résolu. L’évaluation doit commencer par préciser le moment de la prédiction, les informations alors disponibles et l’action déclenchée par le résultat.
Formulez ce contrat en une phrase. Déterminez ensuite les erreurs importantes : urgences manquées, escalades inutiles, ou les deux. Une métrique doit permettre de comparer ces conséquences, plutôt que de produire un chiffre impressionnant.
Préserver l’indépendance du test
La documentation scikit-learn sur les fuites de données explique pourquoi les transformations doivent être apprises uniquement sur les données d’entraînement. Un Pipeline permet de les intégrer correctement à la validation croisée. Il ne rend toutefois pas réaliste un découpage des données inadapté. scikit-learn : fuites de données
Dans cet exemple, vérifiez si des messages d’une même conversation se retrouvent dans plusieurs partitions. Si le modèle doit traiter des demandes futures, évaluez-le aussi sur une période ultérieure. Documentez le découpage, la déduplication et les champs exclus parce qu’ils n’étaient pas disponibles au moment de la prédiction.
Comparer à une solution simple
Commencez par une règle ou un modèle léger soumis à la même évaluation. Si le candidat plus complexe n’apporte qu’un faible gain, comparez celui-ci à sa latence, à son coût de maintenance et à ses modes de défaillance. Une référence simple fait du choix du modèle une décision d’ingénierie.
Dans un exemple de test contenant 20 demandes urgentes sur 1 000, prédire systématiquement « non urgent » donne 98 % d’exactitude sans détecter aucune urgence. Présentez les effectifs derrière le score et examinez la précision et le rappel de la classe qui déclenche l’action. Ces chiffres sont illustratifs et ne constituent pas un résultat de projet.
Examiner les erreurs et conserver les preuves
Examinez les faux positifs et faux négatifs par langue, longueur de texte et type de demande. Un journal utile conserve l’entrée, le résultat attendu, la prédiction et la cause supposée. Certaines erreurs exigent de meilleurs labels, d’autres un périmètre plus précis ou une validation humaine. Augmenter la capacité du modèle n’est qu’une réponse possible.
Choisissez les seuils sur les données de validation, puis évaluez la configuration finale sur le jeu de test réservé. Conservez une fiche : version des données, découpage, référence, définition des métriques, seuil et limites connues. Après le lancement, collectez de nouveaux exemples annotés et vérifiez si la conclusion initiale reste valable.