Documenter les limites d'utilisation

Ce que vous saurez faire

Notez à quoi sert le modèle, à quoi il ne sert pas et sa qualité. Ainsi, les personnes hors du projet l’utilisent seulement là où les résultats le justifient.

Carnet JupyterFaites cette leçon dans un carnet JupyterColab · Kaggle · GitHub · en anglais

Le carnet (notebook) Jupyter entraîne le modèle avec le fichier train.py du cours et exécute evaluate.py une seule fois. Il calcule les valeurs de la fiche à partir des fichiers. Ensuite, il écrit MODEL_CARD.md et vérifie que la fiche correspond à l’artefact. Aucune configuration locale n’est nécessaire.

Ouvrir dans ColabOuvrir dans KaggleVoir sur GitHub

Le carnet est en anglais. Colab et Kaggle ouvrent votre propre copie. Il faut un compte Google ou Kaggle gratuit. Vous êtes bloqué ? Consultez le carnet de solution.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 55 minutes

Ce que vous devez savoir

• Les références de base et l’objectif d’amélioration, dans Définir une référence de base.
• Le rapport de test, produit une seule fois avec evaluate.py, dans Seuils et calibration : tester une seule fois avec evaluate.py.
• Le seuil de 0,19 et l’écart de calibration après le changement de politique, dans Seuils et calibration.
• Pourquoi le modèle plus simple a été choisi, dans Régler les hyperparamètres : la règle d’une erreur-type et Quand un modèle simple est meilleur.
• Les sous-groupes et la taille de leurs échantillons, dans L’analyse par sous-groupes. Pourquoi les coefficients ne sont pas des causes, dans Expliquer les prédictions.

Ce qu’il vous faut sur votre ordinateur (seulement pour le parcours local; le carnet n’en a pas besoin)

• Le projet ~/projects/ticket-model avec .venv activé, dans Définir une référence de base : préparer votre projet.
• Le dossier model/ avec ses trois fichiers, produits par python train.py dans Empaqueter les artefacts : exemple détaillé : train.py. S’il manque, exécutez python train.py. Si vous avez modifié REVIEW_CAPACITY, remettez d’abord sa valeur à 0.20.
• reports/test_report.json, produit par python evaluate.py dans Seuils et calibration : tester une seule fois avec evaluate.py. S’il manque, exécutez python evaluate.py une seule fois. Si evaluate.py manque, téléchargez le fichier du cours : curl -fsSL -O https://raw.githubusercontent.com/Nextia-Intelligence/nextia-learning-labs/main/C05/project/evaluate.py (curl.exe sous Windows).

Testé sous macOS avec Python 3.14.6, pandas 3.0.6 et scikit-learn 1.9.1. Le carnet a été testé dans Jupyter.

La notice dans la boîte de médicaments

Ouvrez une boîte de médicaments achetée en pharmacie : vous y trouvez une notice pliée. Elle indique à quoi sert le médicament et qui ne doit pas le prendre. Elle donne la dose, les effets secondaires et ce que le fabricant a testé. Elle nomme le fabricant et donne la date du dernier changement. Le pharmacien n’est pas chez vous, mais la notice répond aux questions que vous lui poseriez.

La notice existe parce qu’on utilise un médicament loin des personnes qui l’ont fabriqué. C’est pareil pour un modèle. Les fichiers dans model/ indiquent à un programme comment exécuter le modèle. Ils ne disent pas à une personne à quoi il sert, sa qualité ou où il ne faut pas l’utiliser. Priya ne sera pas assise à côté de chaque personne qui utilise les scores.

Le problème : un modèle reçoit une deuxième tâche

Omar, le gestionnaire de produit, pose une question raisonnable : « Les scores sont utiles. Peut-on aussi les utiliser pour autre chose? » Un chef d’équipe a déjà une idée : classer les agents de soutien selon les scores de leurs billets, pour l’évaluation annuelle du rendement.

Rien dans les fichiers ne l’empêche. Les scores sont des nombres, et un tableur peut calculer leur moyenne par agent. Mais le modèle n’a jamais rien appris sur les agents. Il attribue un score à un billet de soutien dès sa création, avant qu’un agent s’en occupe. Un classement des agents selon ces scores mesurerait les billets reçus, pas la qualité de leur travail. Des personnes pourraient perdre une prime à cause d’un nombre qui signifie autre chose.

C’est courant : un modèle conçu pour une décision sert à prendre une deuxième décision que personne n’a testée. Le problème n’est pas une mauvaise intention. Le problème, c’est que les limites étaient dans la tête de Priya, pas à côté du modèle. Il faut écrire la réponse, à côté du modèle, avant que quelqu’un essaie.

Ce qu’est une fiche de modèle

Une fiche de modèle est un court document qui accompagne un modèle, comme la notice dans la boîte de médicaments. Elle indique à quoi sert le modèle, qui l’utilise et à quoi il ne sert pas. Elle présente aussi les données d’entraînement, les résultats, les points faibles et les responsables. Le nom vient d’un article de recherche publié en 2019, Model Cards for Model Reporting, par Margaret Mitchell et ses collègues. Aujourd’hui, beaucoup d’équipes publient une fiche avec chaque modèle.

Commencez petit : une fiche pour la règle « signaler les billets de priorité 1 », la référence de base de Définir une référence de base. Rappelez-vous les nombres. En mai, 163 des 1 179 billets de validation ont la priorité 1, et 61 d’entre eux ont été escaladés. Les données de validation comptent 183 escalades au total.

Ce qu’elle fait	Signale chaque billet de priorité 1.
Usage prévu	Envoyer des billets à l’équipe senior quand aucun modèle n’est disponible.
Usages exclus	Décider quels clients comptent davantage.
Résultats (mai)	Signale 163 billets sur 1 179 (13,8 %). Précision 61 ÷ 163 = 0,374. Rappel 61 ÷ 183 = 0,333.
Limite	Manque 2 escalades sur 3 : toutes celles de priorité 2 ou 3.
Responsable	Grace

Vérifiez les nombres à la main : 163 ÷ 1 179 = 0,138, 61 ÷ 163 = 0,374 et 61 ÷ 183 = 0,333. Rappelez-vous ce que signifient les deux proportions. La précision répond à la question : « Quand la règle signale un billet, à quelle fréquence est-il escaladé? » Le rappel répond à la question : « Parmi toutes les escalades, combien la règle a-t-elle signalées? »

Avec six lignes, un nouveau collègue comprend ce que fait la règle, sa qualité et où ne pas l’utiliser. Une fiche pour le modèle d’escalade contient les mêmes parties, avec davantage de résultats à l’appui.

Les sections d’une fiche

Une bonne fiche répond aux questions d’un utilisateur prudent, dans l’ordre où il les pose. Qu’est-ce que c’est, et qui en est responsable? À quoi ça sert? Quelles données ont servi à l’entraîner, et pourquoi ce type de modèle? Quelle est sa qualité, comparée à une solution simple? Où est-il plus faible? Que dois-je savoir pour l’utiliser sans risque? À quoi ne dois-je jamais l’utiliser?

Chaque réponse vient d’éléments que vous avez déjà. Vous n’inventez rien de nouveau pour la fiche : vous rassemblez ces éléments. Le diagramme montre d’où viennent les éléments à l’appui de chaque section.

D'où viennent les éléments à l'appui de chaque section de la fiche de modèle. Seules deux sections, Usages exclus et les notes éthiques, reposent sur le jugement; les autres viennent de fichiers et d'analyses que vous avez déjà produits.

Description textuelle du diagramme

Le cadrage du modèle du module 2 donne l’usage prévu et les données. model/model_info.json fournit l’en-tête (le SHA-256 de l’artefact et le seuil), les résultats de validation et la justification du modèle. reports/test_report.json ajoute le résultat du test, effectué une seule fois. L’analyse par sous-groupes du module 7 donne les sous-groupes et leurs nombres de cas. Les problèmes connus donnent les limites : écart de calibration, canaux jamais vus par le modèle, invités sans historique. Votre jugement fournit les usages exclus et les notes éthiques.

Le tableau présente les mêmes liens, avec la question à laquelle chaque section répond :

Section	La question à laquelle elle répond	D’où viennent les éléments à l’appui
En-tête	Quel fichier de modèle, quel seuil, quel responsable, quelle date pour la prochaine révision?	model/model_info.json (artifact_sha256, threshold)
Usage prévu	Quelle décision, prise par qui, à quel moment de prédiction, pour quelle cible?	Module 2 : la décision et la cible
Usages exclus	Quels usages sont risqués ou ne sont pas justifiés par les résultats?	Votre jugement, avec une raison pour chacun
Données	Quels billets, de quelle période, avec quelles variables?	La séparation des données et leur description (dataset.md dans le dépôt des exercices)
Pourquoi ce modèle	Pourquoi ce type de modèle, plutôt qu’un modèle plus complexe?	La comparaison et la règle d’une erreur-type (modules 5 à 7)
Évaluation	Quelle est sa qualité, et comparée à quoi?	model_info.json (validation), reports/test_report.json (test, une seule fois), la référence de base
Sous-groupes	Où est-il plus faible?	Module 7, avec le nombre de billets dans chaque sous-groupe
Limites	Que doivent savoir les utilisateurs pour l’utiliser sans risque?	Calibration (module 6), nouvelles catégories, problèmes de données (module 7)
Notes éthiques et pratiques	Qui peut subir un préjudice, et comment l’éviter?	La décision et ses coûts

La section Usages exclus est celle que les gens sautent, et celle qui évite le plus de préjudices. Rappelez-vous le classement des agents : un autre usage probable, que les résultats ne justifient pas. Chaque élément doit avoir une raison. Ainsi, le lecteur peut appliquer cette raison à un nouveau cas absent de la fiche.

Mais pourquoi pas simplement un README? Tomás demande : « On a déjà un README avec les commandes. Pourquoi un autre document? » Un README explique au développeur comment exécuter le code. Une fiche explique au décideur ce que les nombres signifient et dans quels cas ils ne veulent plus rien dire. Grace et Omar lisent la fiche; ils ne liront jamais train.py. Les deux documents ont des lecteurs différents, donc des contenus différents.

Exemple détaillé : la fiche de modèle de Priya

Priya rassemble d’abord les nombres. Elle les prend dans les fichiers, pas dans sa mémoire ni dans une ancienne diapositive. Ainsi, la fiche décrit exactement cet artefact :

card_numbers.py

import json

info = json.load(open("model/model_info.json"))
test = json.load(open("reports/test_report.json"))
print("threshold:", info["threshold"], "| artifact:", info["artifact_sha256"][:16])
print("valid:", info["valid"])
print("test:", {k: test[k] for k in ("flag_rate", "precision", "recall", "roc_auc", "average_precision")})
print("rule on test:", test["baseline_priority_1"])

La sortie :

Sortie

threshold: 0.19 | artifact: a4acd259a398e7c8
valid: {'rows': 1179, 'escalated': 183, 'roc_auc': 0.752, 'average_precision': 0.391, 'flagged': 227, 'flag_rate': 0.193, 'precision': 0.379, 'recall': 0.47}
test: {'flag_rate': 0.196, 'precision': 0.357, 'recall': 0.446, 'roc_auc': 0.749, 'average_precision': 0.345}
rule on test: {'flagged': 150, 'flag_rate': 0.15, 'precision': 0.367, 'recall': 0.35}

Pour les sous-groupes, elle utilise les données de validation au seuil de 0,19. Elle indique le nombre de billets et d’escalades à côté de chaque rappel. Pourquoi ces nombres? Un rappel de 1,000 sur 1 escalade ne signifie rien : une escalade de plus pourrait le faire passer à 0,500. Donc, pour un sous-groupe trop petit, elle écrit « trop peu de cas pour mesurer », comme dans L’analyse par sous-groupes.

Ensuite, elle écrit MODEL_CARD.md dans le dossier du projet, à côté de model/ :

MODEL_CARD.md

# Model card: ticket escalation model

| | |
|---|---|
| Model | Logistic regression in a scikit-learn pipeline (`model/escalation_model.joblib`) |
| Artifact SHA-256 | `a4acd259a398e7c84517b98bf50d811197f90b0f2f1ea15f1f9e168ba3aff736` |
| Threshold | 0.19, chosen on the validation set for a review capacity of 20% |
| Card date | 2026-07-01 |
| Owners | Priya (data scientist): the model and this card. Grace (support lead): the decision and the review capacity. Mei (data engineer): the input data and the input checks. |
| Next review | 2026-10-01, or earlier when a retraining trigger fires |

## Intended use

- **Decision:** when a support ticket is created, decide if it goes straight to the senior team.
- **How:** `predict.py` scores each new ticket. A ticket with a score of at least 0.19 is flagged and routed to the senior team. Other tickets stay in the normal queue.
- **Users:** Larkfield's support team. Grace's senior team reviews the flagged tickets.
- **Prediction time:** when the ticket is created. The model uses only facts known at that moment.
- **Target:** `escalated_72h`, 1 if the ticket is escalated to a senior agent within 72 hours of creation.

## Not for

- **Staff performance reviews.** A score describes a ticket, not the agent who handled it.
- **Refusing, delaying or reducing service** to any customer. A ticket without a flag gets the normal service, never less.
- **Showing a score as "the chance" of escalation** to customers or staff. Since the policy change of 2026-05-01, the scores are too low (see *Limits*). This needs recalibration on recent data first.
- **Other shops, other languages, or other prediction times** (for example, after the first reply). The model learned Larkfield's tickets at creation only.
- **Ranking customers.** One prediction is for one ticket, not for a customer.

## Data

Synthetic data made for the course: it has no real people. One row is one ticket, with only the facts known at creation.

| Part | Tickets | Escalated | Dates |
|---|---|---|---|
| Train | 16,939 | 1,983 (11.7%) | 2024-07-01 to 2026-04-30 |
| Validation | 1,179 | 183 (15.5%) | May 2026 |
| Test | 1,002 | 157 (15.7%) | 2026-06-01 to 2026-06-27 |

Features (11): `channel`, `team`, `segment`, `region`, `priority`, `order_value`, `word_count`, `customer_tenure_days`, `prior_tickets_90d`, `created_hour`, `prior_escalations_90d`. The checksums of the data files are in `model/model_info.json`.

## Why this model

Priya compared logistic regression with decision trees, random forests and gradient boosting, with 5-fold cross-validation on the train set. The best boosting setting had an average precision of 0.3424, and logistic regression 0.3393. The difference, 0.003, is smaller than one standard error (0.008), so it is noise. By the one-standard-error rule, she chose the simpler model. Its coefficients show how each feature moves a score, so the owners can explain a flag and find problems in the inputs.

## Evaluation

The threshold was chosen on the validation set. The test set was used once, after every choice, with `python evaluate.py`.

| At threshold 0.19 | Validation (May) | Test (June) | Rule "flag priority 1" (test) |
|---|---|---|---|
| Flagged | 227 (19.3%) | 196 (19.6%) | 150 (15.0%) |
| Precision | 0.379 | 0.357 | 0.367 |
| Recall | 0.470 | 0.446 | 0.350 |
| ROC AUC | 0.752 | 0.749 | |
| Average precision | 0.391 | 0.345 | |

Target: flag at most 20% of new tickets and catch at least 40% of escalations. The model meets it on validation and test. The rule catches 35% on test (33.3% on validation).

Slices (validation set, threshold 0.19):

| Slice | Tickets | Escalated | Flagged | Recall |
|---|---|---|---|---|
| Team payment | 206 | 48 | 91 | 0.771 |
| Team warranty | 168 | 48 | 50 | 0.521 |
| Team delivery | 348 | 42 | 39 | 0.310 |
| Team returns | 291 | 33 | 40 | 0.303 |
| Team account | 166 | 12 | 7 | 0.083 |
| Priority 3 | 617 | 59 | 19 | 0.102 |
| Segment guest | 9 | 1 | 1 | too few to measure |
| Channel unknown | 22 | 5 | 5 | too few to measure |

## Limits

- **Scores are too low since 2026-05-01.** After the new warranty policy, the mean score on the validation set is 0.120, but 15.5% of tickets escalated. For scores from 0.2 to 0.3, the mean score is 0.241 and the observed rate is 0.315. The ranking still works, so the threshold for the capacity still works.
- **Precision is about 0.36 to 0.38.** About 2 of 3 flagged tickets do not escalate. The senior team must expect this.
- **Weak slices.** The model rarely flags `account` tickets and priority 3 tickets, so it misses most of their escalations.
- **Categories the model never saw.** A new channel (for example `social`) gets 0 in every channel column. The model still scores the ticket, but with less information. `predict.py` warns and counts these tickets.
- **Guests and new customers.** Guests have no customer history (202 guest tickets in train). Small slices like guests and `channel = unknown` have too few validation tickets to measure.
- **A hidden customer tendency.** Some repeat customers escalate more often, and no column shows it. This limits any model on these features.

## Ethical and practical notes

- A flag adds a review by a senior agent. No flag must never mean worse service.
- Coefficients and feature importance describe the model, not the causes of escalation.
- The owners check the monitoring signals every week (flag rate, mean score, unknown categories) and recall when the labels arrive.
- With real data, the features would include personal data about customers. Then privacy rules apply to the data, the artifact and the predictions.

## How to reproduce

```sh
python -m pip install -r requirements.txt
python get_data.py
python train.py
python predict.py --check
```

`python train.py` prints `Trained on 16939 tickets. Threshold 0.19 for a review capacity of 20%.` `python predict.py --check` prints `Check passed: 20 scores are identical after reloading`.

Gardez ce fichier. Vous le réutiliserez dans le travail final.

Quatre choix dans cette fiche comptent particulièrement :

• La colonne de test est à côté de la colonne de validation et de la référence de base. Un nombre seul ne signifie rien. Le lecteur voit que le modèle dépasse la règle en rappel (0,446 contre 0,350 sur les données de test). La précision est semblable, et les résultats de test sont un peu inférieurs à ceux de validation.
• Chaque sous-groupe montre ses nombres de cas. Le rappel de 0,083 de l’équipe account (comptes) représente 1 escalade sur 12. C’est un sous-groupe faible avec peu de cas, et la fiche indique les deux. Les invités ont 9 billets : la fiche ne prétend pas savoir.
• Chaque élément des « Usages exclus » a une raison. Les « évaluations du rendement du personnel » ne figurent pas du tout dans les données, mais constituent un autre usage probable. La raison (un score décrit un billet, pas un agent) répond aussi à des demandes semblables absentes de la fiche.
• « Pourquoi ce modèle » justifie le choix d’un modèle simple. Un lecteur pourrait demander : « Pourquoi pas le modèle le plus puissant? » La fiche répond. La différence était plus petite que le bruit, et un modèle simple est plus facile à expliquer et à vérifier. Quand un modèle simple est meilleur donne d’autres raisons de ce genre.

Exercice guidé : rédiger et vérifier votre fiche

1. Dans ~/projects/ticket-model, activez .venv.
2. Exécutez python train.py. Vous devriez voir Threshold 0.19 (seuil de 0,19).
3. Si reports/test_report.json manque, exécutez python evaluate.py une seule fois.
4. Enregistrez card_numbers.py à partir de l’exemple détaillé, puis exécutez-le. Vous devriez voir les quatre lignes de la sortie ci-dessus.
5. Créez MODEL_CARD.md à côté de model/. Copiez-y la fiche de Priya.
6. Comparez chaque nombre du tableau Évaluation avec la sortie de l’étape 4.
7. Comparez le SHA-256 de l’artefact dans la fiche avec artifact_sha256 dans model/model_info.json. Sur un autre système, le vôtre peut différer : inscrivez alors le vôtre dans la fiche.
8. Lisez la liste Usages exclus. Ajoutez un élément adapté à Larkfield, avec une raison.

Exemple d’un « usage exclu » supplémentaire

• Choisir quels billets fermer sans réponse. Le modèle prédit l’escalade, pas si une réponse est nécessaire. Un score faible ne signifie pas qu’un billet est sans importance.

Autres bonnes réponses : décider des remboursements ou des compensations (le modèle ne sait rien de ce qu’on doit au client); acheminer les billets à un autre moment de prédiction, par exemple après le deuxième message du client (les variables décrivent le billet à sa création).

À vous de jouer : la demande d’Omar

Omar veut ajouter une phrase au courriel de confirmation de chaque client : « Il y a 24 % de chances qu’un agent senior traite votre billet. » Ce 24 % serait le score du billet. Utilisez la fiche pour décider. Avant de lire la réponse, écrivez deux ou trois phrases : oui ou non, et pourquoi, avec des nombres tirés de la fiche.

Afficher la réponse

Non, pas avec ces scores. La fiche l’indique dans Usages exclus : présenter un score comme « la probabilité ». La raison se trouve dans Limites : depuis le changement de politique, les scores sont trop faibles. En mai, les billets avec un score de 0,2 à 0,3 (moyenne de 0,241) avaient un taux d’escalade de 0,315. Donc, « 24 % » correspondrait à environ 31 % en réalité. Un nombre présenté à un client ressemble à une promesse, et celui-ci comporte une erreur dont le sens est connu.

Ce qui rendrait cela possible : recalibrer les scores sur des données récentes, ou réentraîner le modèle avec celles-ci (la prochaine leçon le prévoit). Ensuite, mesurez de nouveau et mettez la fiche à jour. Même alors, Omar et Grace doivent décider si les clients devraient voir ce nombre. C’est dans la fiche qu’on consigne cette décision.

Erreur courante

Une fiche qui ne correspond pas à l'artefact

Symptôme : Tomás essaie la capacité de 15 % de Empaqueter les artefacts et oublie de la remettre à sa valeur initiale. Le dossier du modèle contient maintenant le seuil de 0,22. La fiche indique encore 0,19, 227 billets signalés en mai et un rappel de 0,470. Grace planifie la semaine de l’équipe senior à partir de la fiche. Rien ne signale d’erreur.

Cause : la fiche a été rédigée à la main, une seule fois. L’artefact a changé ensuite. Le fichier du modèle n’a même pas changé : son SHA-256 est toujours a4acd259…, car le pipeline est identique. Seul le seuil dans model_info.json a changé, et le rappel réel sur les données de mai est maintenant de 0,41.

Correction : traitez la fiche comme une partie de l’artefact. Indiquez le fichier exact du modèle et son seuil, puis vérifiez les deux avant chaque passation :

check_card.py

import json
from pathlib import Path

card = Path("MODEL_CARD.md").read_text(encoding="utf-8")
info = json.loads(Path("model/model_info.json").read_text(encoding="utf-8"))
problems = []
if info["artifact_sha256"] not in card:
    problems.append("the card names another model file")
if f"| Threshold | {info['threshold']}," not in card:
    problems.append(f"the card does not give the threshold {info['threshold']}")
print("The card matches the artifact." if not problems else "The card does not match: " + "; ".join(problems) + ".")

Avec l’artefact à 15 % :

Sortie

The card does not match: the card does not give the threshold 0.22.

Avec l’artefact du cours (capacité de 20 %) :

Sortie

The card matches the artifact.

Quand la vérification échoue, mettez la fiche à jour : tous ses nombres, pas seulement le seuil. Ou produisez de nouveau l’artefact avec les paramètres décrits dans la fiche.

Conséquence pour le travail en IA : une fiche périmée est pire que l’absence de fiche, parce que les gens lui font confiance. Les équipes qui réentraînent souvent génèrent la fiche avec un script à partir de model_info.json et du rapport de test. Ainsi, les nombres ne peuvent pas diverger.

Vérification des connaissances

Vérifiez votre compréhension

Donnez trois usages exclus du modèle de transfert au niveau supérieur, chacun avec sa raison.

Afficher la réponse

Trois des usages suivants, chacun avec sa raison :

• Évaluer le rendement du personnel : un score décrit un billet, pas l’agent.
• Refuser, retarder ou réduire le service : le modèle ajoute seulement une vérification; l’absence de signalement ne doit jamais dégrader le service.
• Présenter le score aux clients ou au personnel comme « la probabilité » : les scores sont trop faibles depuis le changement de politique du 1er mai 2026 (les scores de 0,2 à 0,3 correspondaient à un taux de transfert de 0,315).
• D’autres boutiques, langues ou moments de prédiction : le modèle a appris uniquement à partir des billets de Larkfield au moment de leur création.
• Classer les clients : une prédiction porte sur un seul billet.

Vérifiez votre compréhension

Omar lit une précision moyenne de 0,391 dans la fiche et dit : donc, le modèle détecte 39 % des transferts. Quelle est son erreur, et quels nombres répondent à sa question?

Afficher la réponse

La précision moyenne résume le classement pour tous les seuils. Ce n’est pas la proportion des transferts que le modèle détecte. La proportion détectée est le rappel au seuil utilisé, soit 0,19 : 0,470 sur les données de validation (86 sur 183) et 0,446 sur les données de test (70 sur 157). Il s’accompagne du taux de signalement (19,3 % et 19,6 %), dont Grace a besoin pour gérer sa capacité, et de la précision (0,379 et 0,357).

Vérifiez votre compréhension

Pourquoi la fiche indique-t-elle le nombre de billets et de transferts à côté du rappel de chaque sous-groupe?

Afficher la réponse

Un taux calculé sur un petit sous-groupe est peu fiable. Le rappel de 0,083 de l’équipe account (comptes) représente 1 transfert sur 12. Avec si peu de cas, quelques billets de plus ou de moins le changent beaucoup. Les invités comptent 9 billets de validation et 1 transfert. Leur rappel de 1,000 ne signifie donc rien. Les nombres de cas indiquent au lecteur quelle confiance accorder à chaque valeur. Ils montrent aussi les points sur lesquels la fiche ne peut encore rien dire.

Récapitulatif

Vous pouvez maintenant transmettre un modèle dont les limites d’utilisation sont documentées :

• Une fiche de modèle décrit son usage prévu, ses utilisateurs et les usages exclus, avec leurs raisons. Elle présente aussi les données, le choix du modèle, les résultats comparés à la référence de base, les sous-groupes et leurs nombres de cas, les limites, les responsables et la date de révision.
• Les nombres proviennent des fichiers (model_info.json, test_report.json), pas de la mémoire : rappel de test de 0,446 contre 0,350 pour la règle, avec 19,6 % de billets signalés.
• La fiche désigne l’artefact exact (son SHA-256 et son seuil), et une courte vérification prouve qu’ils correspondent.

La fiche indique quand le modèle risque de ne plus convenir. Ensuite, vous planifiez les vérifications qui vous avertiront : vérifications des entrées, signaux de surveillance et critère déclenchant un nouvel entraînement.

Leçon suivante : Planifier les vérifications en production