g2/enervision

Watch

Fork 0

[36] Le contrôle de rejouabilité tourne aussi sur le serveur #181

Merged

lenaic merged 2 commits from olivier/36-entrainement-modele into develop

2026-09-08 09:02:06 +00:00

olivier commented

2026-09-08 08:07:11 +00:00

Member

Deux lignes dans services/inference/bin/entrainer.sh. --deux-passes, le contrôle qui sert le quatrième critère du #36, ne pouvait pas tourner sur le serveur de la salle — c'est-à-dire au seul endroit où le ticket demande qu'il tourne.

Le défaut

entrainer: bornes figées pour les deux passes, --jusqu-a=2026-09-08T07:00:00+00:00
mktemp: too few X's in template 'passe1-36'

mktemp -t passe1-36 complète le motif tout seul sur macOS. GNU coreutils, lui, exige les XXXXXX et refuse. Le job sortait donc en échec avant d'avoir lu une seule ligne de la base, avec un message qui parle de fichier temporaire et non de modèle.

La passe unique n'était pas touchée : elle ne crée aucun fichier temporaire. Seul le chemin de rejouabilité tombait, ce qui explique qu'il soit passé inaperçu jusqu'ici — l'entraînement du 07/09 s'était joué sans lui.

La preuve

Rejoué depuis ce commit, sur enervision_prod, avec le venv du serveur :

entrainer: DEUX PASSES IDENTIQUES — rejouabilité constatée sur ces bornes

Deux entraînements sur des bornes figées, tableaux comparés ligne à ligne, aucun écart. Le quatrième critère du #36 est constaté sur les données de production, et non plus seulement affirmé.

Ce que la relecture doit savoir

Aucun test ne couvre entrainer.sh, et ça reste vrai après ce correctif. C'est ce qui a laissé l'écart entre les deux mktemp traverser la #166 : les 95 tests de tests/unit/model/ portent tous sur le paquet Python, jamais sur le lanceur. Un banc qui jouerait --deux-passes contre un module bouchonné fermerait la porte ; il n'est pas dans cette branche, qui se limite au défaut constaté.

Un point de méthode est apparu en rejouant l'entraînement, sans rapport avec ce diff mais qui concerne le #36 : le critère « MAE sur les trois derniers jours » de l'ADR 0013 change de signe selon le jour où on le lance, parce que trois jours tombent parfois sur un week-end — où la série est bien plus plate et la persistance quasi imbattable.

Fenêtre de test	Modèle	Persistance	Verdict
3 j, le critère ADR	25,118	10,217	perd de 14,9
10 j	19,203	20,200	gagne de 1,0
14 j	16,011	22,222	gagne de 6,2

Deux promotions ont déjà été décidées sur des fenêtres différentes. Le sujet mérite une décision de groupe plutôt qu'un arbitrage dans une branche : il n'est pas traité ici.

Deux lignes dans `services/inference/bin/entrainer.sh`. `--deux-passes`, le contrôle qui sert le quatrième critère du #36, ne pouvait pas tourner sur le serveur de la salle — c'est-à-dire au seul endroit où le ticket demande qu'il tourne. ### Le défaut ``` entrainer: bornes figées pour les deux passes, --jusqu-a=2026-09-08T07:00:00+00:00 mktemp: too few X's in template 'passe1-36' ``` `mktemp -t passe1-36` complète le motif tout seul sur macOS. GNU coreutils, lui, exige les `XXXXXX` et refuse. Le job sortait donc en échec avant d'avoir lu une seule ligne de la base, avec un message qui parle de fichier temporaire et non de modèle. La passe unique n'était pas touchée : elle ne crée aucun fichier temporaire. Seul le chemin de rejouabilité tombait, ce qui explique qu'il soit passé inaperçu jusqu'ici — l'entraînement du 07/09 s'était joué sans lui. ### La preuve Rejoué depuis ce commit, sur `enervision_prod`, avec le venv du serveur : ``` entrainer: DEUX PASSES IDENTIQUES — rejouabilité constatée sur ces bornes ``` Deux entraînements sur des bornes figées, tableaux comparés ligne à ligne, aucun écart. Le quatrième critère du #36 est constaté sur les données de production, et non plus seulement affirmé. ### Ce que la relecture doit savoir **Aucun test ne couvre `entrainer.sh`**, et ça reste vrai après ce correctif. C'est ce qui a laissé l'écart entre les deux `mktemp` traverser la #166 : les 95 tests de `tests/unit/model/` portent tous sur le paquet Python, jamais sur le lanceur. Un banc qui jouerait `--deux-passes` contre un module bouchonné fermerait la porte ; il n'est pas dans cette branche, qui se limite au défaut constaté. **Un point de méthode est apparu en rejouant l'entraînement**, sans rapport avec ce diff mais qui concerne le #36 : le critère « MAE sur les trois derniers jours » de l'ADR 0013 change de signe selon le jour où on le lance, parce que trois jours tombent parfois sur un week-end — où la série est bien plus plate et la persistance quasi imbattable. | Fenêtre de test | Modèle | Persistance | Verdict | |---|---|---|---| | 3 j, le critère ADR | 25,118 | 10,217 | perd de 14,9 | | 10 j | 19,203 | 20,200 | gagne de 1,0 | | 14 j | 16,011 | 22,222 | gagne de 6,2 | Deux promotions ont déjà été décidées sur des fenêtres différentes. Le sujet mérite une décision de groupe plutôt qu'un arbitrage dans une branche : il n'est pas traité ici.

olivier added 1 commit

2026-09-08 08:07:11 +00:00

inference: --deux-passes tourne aussi sur GNU coreutils (#36 )

Intégration / Tableau de bord — dépendances, tests et construction (pull_request) Successful in 35s

Details

Intégration / Contrôles statiques du dépôt (pull_request) Successful in 6s

Details

Intégration / Workflows — lint et audit de sécurité (pull_request) Successful in 19s

Details

Infra Ansible / Playbooks Ansible valides (pull_request) Successful in 1m5s

Details

Intégration / Python — qualité, tests et dépendances (pull_request) Successful in 5m12s

Details

40ae579ae6

`mktemp -t passe1-36` échoue sur GNU coreutils — « too few X's in
template » — alors que le mktemp de macOS complète le motif tout seul. Le
chemin `--deux-passes` ne pouvait donc jamais tourner là où le ticket
demande qu'il tourne : sur le serveur de la salle, en Ubuntu.

Le contrôle de rejouabilité du quatrième critère sortait en échec avant
d'avoir appris quoi que ce soit, avec un message qui parle de mktemp et
non du modèle.

Aucun test ne couvre `entrainer.sh` : c'est ce qui a laissé passer
l'écart entre les deux mktemp, et ça reste vrai après ce correctif.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

olivier requested review from lenaic

2026-09-08 08:08:39 +00:00

lenaic approved these changes

2026-09-08 08:19:16 +00:00

lenaic left a comment

Approuvée. Deux lignes, et mktemp -t modele.XXXXXX marche sur GNU comme sur BSD.

Le diagnostic est juste : la passe unique ne crée aucun temporaire, donc seul le chemin de rejouabilité tombait. C'est ce qui explique qu'il ait traversé la #166.

Rien à redire sur le diff. Ce qui suit ne le concerne pas et ne doit pas le retenir.

Ce que j'ai vu en vérifiant, et qui va au #36

J'ai relevé les huit entraînements de MLflow sur le serveur :

08/09 09:55   modèle 16,011   persistance 22,222   GAGNE   ← v6, porte l'alias production
08/09 09:50   modèle 25,118   persistance 10,217   PERD    ← 3 jours, le critère de l'ADR
07/09 19:27   modèle 19,203   persistance 20,200   gagne de 1,0
07/09 18:58   modèle 18,060   persistance 17,100   PERD
07/09 10:46   modèle  2,018   persistance 21,443   GAGNE

Ton tableau est confirmé, et il porte plus loin que tu ne l'écris.

Le modèle en ligne ne satisfait pas le critère écrit. L'ADR 0013 dit « l'alias production ne se déplace que si la MAE du candidat sur les trois derniers jours est strictement inférieure à celle de la persistance ». Sur trois jours il perd de 14,9. La v6 porte pourtant l'alias.

Et le 2,018 de la #166 n'est reproductible par aucun autre run. Tous les suivants tombent entre 16 et 25. Ce chiffre est dans le corps de la #166 fusionnée, et je l'ai repris dans la demande vers main.

Je porte ça au #36. Ta demande n'attend pas cette décision.

Approuvée. Deux lignes, et `mktemp -t modele.XXXXXX` marche sur GNU comme sur BSD. Le diagnostic est juste : la passe unique ne crée aucun temporaire, donc seul le chemin de rejouabilité tombait. C'est ce qui explique qu'il ait traversé la #166. Rien à redire sur le diff. Ce qui suit ne le concerne pas et ne doit pas le retenir. ## Ce que j'ai vu en vérifiant, et qui va au #36 J'ai relevé les huit entraînements de MLflow sur le serveur : ``` 08/09 09:55 modèle 16,011 persistance 22,222 GAGNE ← v6, porte l'alias production 08/09 09:50 modèle 25,118 persistance 10,217 PERD ← 3 jours, le critère de l'ADR 07/09 19:27 modèle 19,203 persistance 20,200 gagne de 1,0 07/09 18:58 modèle 18,060 persistance 17,100 PERD 07/09 10:46 modèle 2,018 persistance 21,443 GAGNE ``` Ton tableau est confirmé, et il porte plus loin que tu ne l'écris. **Le modèle en ligne ne satisfait pas le critère écrit.** L'ADR 0013 dit « l'alias `production` ne se déplace que si la MAE du candidat sur les trois derniers jours est strictement inférieure à celle de la persistance ». Sur trois jours il perd de 14,9. La v6 porte pourtant l'alias. **Et le 2,018 de la #166 n'est reproductible par aucun autre run.** Tous les suivants tombent entre 16 et 25. Ce chiffre est dans le corps de la #166 fusionnée, et je l'ai repris dans la demande vers `main`. Je porte ça au #36. Ta demande n'attend pas cette décision.

lenaic added 1 commit

2026-09-08 08:27:16 +00:00

Merge branch 'develop' into olivier/36-entrainement-modele

Intégration / Tableau de bord — dépendances, tests et construction (pull_request) Successful in 39s

Details

Intégration / Contrôles statiques du dépôt (pull_request) Successful in 7s

Details

Intégration / Workflows — lint et audit de sécurité (pull_request) Successful in 18s

Details

Intégration / Python — qualité, tests et dépendances (pull_request) Successful in 5m43s

Details

89b5ae0298