Mesuré, pas promis.
Les chiffres que Klorn publie, d’où vient chacun d’eux, et ce que chacun ne peut pas vous dire. Chaque jeu de données et chaque script cité ici se trouve dans le dépôt public.
Trois chiffres, et leurs sources
- ≥90%Rappel des messages urgents, seuil CI
Toute modification du classifieur qui fait passer le rappel des messages urgents sous 90 % sur le jeu synthétique de contrôle fait échouer le build.
Source : eval-floors.ts - 95.5%Précision de Silent
Mesurée sur le jeu d’e-mails réels étiquetés à la main : sur 22 messages que Klorn a classés en Silent, 21 étaient étiquetés silent. Trois exécutions le 2026-08-26, identiques à chaque fois.
Source : eval/README.md - 0Actions non approuvées
Les envois, les suppressions définitives et les transferts vers des adresses externes attendent une approbation et enregistrent un reçu lié à une empreinte (hash) de ce qui est parti. Une règle de réponse automatique que vous avez vous-même créée vaut approbation.
Imposé dans le code : attention-floor.ts
Pas de chiffre global de précision. Le jeu d’e-mails réels est antérieur aux files Meeting et Info : ses étiquettes n’utilisent que trois files, il ne peut donc pas évaluer les deux autres, et il doit être réétiqueté selon les cinq. Tant qu’il ne l’est pas, nous n’en tirons aucun chiffre global de précision. Le chiffre de précision de Silent ci-dessus vient du même jeu et a les mêmes limites.
Comment l’évaluation s’exécute
Les jeux versionnés
Deux jeux se trouvent dans packages/api/eval/. Le jeu d’e-mails réels (real-eval-set.json) contient
53 e-mails réels, étiquetés à la main et débarrassés de toute donnée personnelle. Le jeu synthétique de contrôle
(judge-eval-set.json) contient 56 e-mails inventés, sans aucune donnée personnelle.
Le script d’exécution
Depuis packages/api, pnpm eval:real évalue le classifieur sur le jeu d’e-mails réels ;
pnpm eval:judge fait de même pour le jeu synthétique.
Le contrôle en CI
Chaque pull request qui modifie le classifieur fait passer le jeu synthétique de contrôle par le modèle, avec trois seuils imposés : 80 % au global, 90 % de rappel des urgents et 90 % de précision de Silent. Une exécution sous l’un de ces seuils échoue. Si le job n’a pas de clé de modèle, comme pour une pull request venant d’un fork, il est ignoré avec un avertissement au lieu d’être validé.
Un second contrôle, sans modèle, s’exécute à chaque passage des tests en CI : le chemin rapide à base de règles et le repli par mots-clés doivent atteindre 70 % sur le même jeu, un message urgent manqué doit retomber dans Queue plutôt que dans Silent, et un message marketing ne doit jamais être marqué urgent.
Le jeu d’e-mails réels est évalué sur les mêmes pull requests, à titre de rapport uniquement. Sa file urgente compte 4 messages étiquetés, trop peu pour qu’un seuil de 90 % ait un sens.
Consulter les jeux, le script et l’historique des mesures sur GitHub
Vérifié le 2026-10-14 par rapport au dépôt. Une erreur ici ? Dites-le-nous.