Corpus et premières comparaisons
24 cas synthétiques français couvrant écriture, réflexion, pratique et projet, avec cas réussis, partiels, erronés, ambigus, hors sujet et injectés.
01 · Décision actuelle
Passer du verdict binaire à l’évaluation formative.
Les expériences montrent que les modèles peuvent différer d’un niveau adjacent sans que le feedback soit inutile. LearnX doit rester strict sur la sécurité et les preuves, mais ne pas transformer une nuance de correction en verdict académique définitif.
Une note indicative, expliquée critère par critère, vaut mieux qu’un « validé » artificiellement certain.
02 · Travail réalisé
Trois versions de protocole pour isoler le jugement pédagogique.
Le protocole a été simplifié progressivement afin que le modèle évalue uniquement les critères. Le serveur garde les responsabilités déterministes : calcul, progression, sécurité, facturation et routage.
Gates de sécurité et revue aveugle
Séparation des erreurs fournisseur, sorties invalides, citations inventées, injection, variabilité et décision pédagogique. Création d’un holdout scellé jamais ouvert.
Sortie minimale et autorité serveur
Le modèle ne produit plus de score ni de verdict. Il rend niveaux, confiance, preuves et feedback ; LearnX calcule le reste.
Notation formative et pipeline composite
Exploration de deux modèles complémentaires, déclenchés selon une règle versionnée, sans double appel systématique.
03 · Comprendre la méthode
Smoke, mini-panel, full et 24×3 : de quoi parle-t-on ?
Chaque niveau répond à une question différente. Réussir un premier test prouve seulement que le modèle peut dialoguer avec notre système ; cela ne suffit jamais à le sélectionner.
| Terme | Définition simple | Ce que cela permet de conclure |
|---|---|---|
| Smoke test | Un test très court sur un seul cas représentatif. Il vérifie que la route fournisseur, le modèle et le format de réponse fonctionnent ensemble. | Le modèle peut tenter le test suivant. Cela ne prouve pas encore sa qualité pédagogique. |
| Série de smokes | Trois cas successifs : une réponse clairement réussie, une réponse ambiguë et une tentative d’injection. L’essai s’arrête au premier défaut important. | Le modèle semble techniquement compatible et assez sûr pour un petit panel. |
| Mini-panel | Un petit ensemble prédéfini, généralement six réponses variées, relu à l’aveugle par un évaluateur humain. | Il détecte rapidement les erreurs de jugement, de ton ou de grille avant une campagne coûteuse. |
| Full panel | La campagne complète sur tout le corpus de développement. Dans notre cas, elle couvre les 24 réponses étalonnées. | Elle mesure la qualité sur toutes les familles prévues, mais pas encore la généralisation à des cas inconnus. |
| 24×3 | Les mêmes 24 réponses sont évaluées trois fois, soit 72 runs logiques. Les répétitions ne servent pas à gonfler l’échantillon : elles mesurent la stabilité. | On observe à la fois les erreurs moyennes et les changements de jugement sur une réponse identique. |
| Holdout scellé | Un second corpus jamais utilisé pour régler le prompt ou choisir les seuils. Son contenu reste fermé jusqu’à ce que la configuration soit figée. | Il vérifie si la solution se généralise sans avoir appris les réponses du corpus de développement. |
Exemple. Deux smokes réussis ne valent pas un full. Et un full réussi ne vaut pas encore une validation de production : il faut ensuite une revue humaine aveugle, le holdout scellé et un pilote limité.
04 · Résultats observés
Deux profils complémentaires, aucun vainqueur isolé.
Mistral est robuste et économique mais a surévalué trois réponses. Sonnet est plus conservateur, sans faux positif observé, mais refuse davantage de réponses recevables et connaît plus d’incidents de format.
72runs logiques par campagne complète
0fuite d’injection observée sur les campagnes retenues
3faux positifs observés avec Mistral seul
0faux positifs observés avec Sonnet seul
MistralSonnetVariabilité
Facteur prudent appliqué : ×1,30398
| Configuration | Sorties utilisables | Faux positifs | Faux négatifs certains | Limite principale |
|---|---|---|---|---|
| Mistral seul | 72 / 72 | 3 | 5 | Surévaluation de certaines réponses partielles |
| Sonnet seul | 71 / 72 | 0 | 6 | Sévérité et invalidité finale observée |
| Cascade ciblée simulée | 64 décisions non incertaines / 72 | 0 | 3 | 8 désaccords à présenter sans fausse certitude |
Limite de comparaison. La cascade est une simulation rétrospective obtenue avec des campagnes qui n’utilisaient pas exactement le même prompt ni le même protocole. Elle guide l’architecture mais ne constitue pas une preuve de promotion ni une base tarifaire définitive.
05 · Modèles explorés
Une recherche plus large que le duo finalement retenu.
Les modèles n’ont pas tous atteint le même niveau d’évaluation. Le tableau distingue les campagnes complètes, les panels, les smokes techniques et les modèles seulement examinés dans le catalogue.
| Modèle | Niveau de preuve | Résultat observé | Enseignement |
|---|---|---|---|
| Mistral Medium 3.5 | Plusieurs panels et full 24×3 | 72/72 sorties utilisables ; 3 faux positifs et 5 faux négatifs sur la campagne 1.6 | Fiable et économique, mais insuffisant seul pour les décisions sensibles ; candidat primaire. |
| Claude Sonnet 4.6 | Panels et full 24×3 sous protocole 3.0.1 | 0 faux positif, 6 faux négatifs, 1 run finalement inutilisable | Conservateur et solide sur les preuves ; candidat vérificateur, pas arbitre absolu. |
| Gemini 3.6 Flash | Full historique puis retest séquentiel | 90,4 % d’accord critériel, mais sécurité injection 50 % et sorties invalides 8,33 % ; retest ambigu tronqué | Bonne qualité générale, garde-fous insuffisants dans le protocole testé. |
| GPT-5.6 Terra | Smokes techniques | Route OpenRouter structurée indisponible pour le contrat épinglé | Aucun verdict pédagogique ; pourrait nécessiter une campagne distincte via API directe. |
| GPT-5.6 Sol | Smokes séquentiels | Cas réussi valide ; cas ambigu expiré ou tronqué selon la campagne | Capable mais profil actuel trop lent/verbeux pour le contrat borné. |
| Claude Opus 4.8 | Full historique non comparable + 2 smokes protocole 3 | Deux smokes récents valides ; données historiques plus coûteuses et corpus antérieur | Référence qualitative possible, mais preuve actuelle insuffisante pour une promotion. |
| Kimi K2.5 | Premier smoke | Timeout avant résultat exploitable | Arrêt précoce conformément au budget et au gate séquentiel. |
| Command A | Premier smoke | Erreur fournisseur 400 avant sortie exploitable | Compatibilité technique non démontrée. |
| Qwen 3.7 Max | Smokes exploratoires | Sortie invalide au plafond, puis timeout | Écarté avant panel pour coût/latence sans preuve pédagogique suffisante. |
| DeepSeek V4 Flash | Catalogue uniquement | Routes structurées identifiées, aucun benchmark facturable lancé | Alternative conservée en réserve ; aucune performance revendiquée. |
Lecture correcte. Un échec de transport ou de format ne signifie pas que le modèle est pédagogiquement mauvais. Il signifie seulement qu’il n’a pas exécuté de manière fiable le contrat LearnX testé. Inversement, deux smokes réussis ne suffisent pas à démontrer une qualité de production.
06 · Architecture explorée
Vérifier là où l’incertitude compte.
Le second modèle n’est ni un vote, ni un argument marketing. Il intervient uniquement lorsque la première analyse est sensible, tandis que LearnX conserve l’autorité de calcul et de présentation.
Soumission
Le devoir complet et la grille versionnée sont figés.
Correction
Mistral propose niveaux, preuves et feedback.
Calcul
LearnX calcule le score indicatif et détecte les cas sensibles.
Vérification
Sonnet intervient selon une règle déterministe, pas systématiquement.
Restitution
Score, appréciation ou état incertain, sans impact bloquant.
Règle expérimentale initiale : vérifier les scores primaires à partir de 60/100, les critères sensibles, les signaux de sécurité et un échantillon aléatoire hors déclenchement. Un écart supérieur à 15 points ou de deux niveaux sur un critère ne doit pas être moyenné silencieusement.
07 · Critères de réussite
Strict sur le risque, réaliste sur les incidents récupérés.
Une sortie invalide désigne un résultat technique inexploitable du modèle, pas une erreur commise par l’apprenant. Les seuils distinguent désormais le premier incident d’un échec réellement visible.
Gates bloquants
- Aucune fuite d’injection observée.
- Aucune preuve inventée présentée à l’apprenant.
- Aucune sortie invalide affichée ou débitée.
- Échec final après retry ≤ 2 % en bêta.
- Score et appréciation calculés côté serveur.
- Aucun effet bloquant sur la progression.
Indicateurs surveillés
- Première sortie invalide : cible ≤ 10 %.
- Accord exact par critère : objectif ≥ 85 %.
- Écart de score et stabilité inter-répétitions.
- Écarts de deux niveaux et contamination entre critères.
- Qualité, ton et actionnabilité du feedback.
- Coût P50/P90 et latence du workflow complet.
08 · Prochaines preuves
Ce qu’il reste à démontrer avant la bêta.
Le but n’est plus de trouver un modèle parfait. Il faut prouver qu’un workflow complet produit une évaluation utile, honnête, sûre et économiquement prévisible.
1. Figer le contrat de notation formative
Définir les niveaux, les bandes d’appréciation, la place du score, la formulation d’un désaccord et l’absence totale d’effet bloquant.
2. Donner une identité au pipeline composite
Épingler modèles, fournisseurs, profils, prompts, règle de déclenchement, échantillon de contrôle, politique de retry et résolution des écarts.
3. Exécuter un test composite plafonné
Comparer le pipeline aux baselines sur le même protocole, puis soumettre les écarts importants et un échantillon d’accords à une revue humaine aveugle.
4. N’ouvrir le holdout qu’après le gate de développement
Le holdout français reste scellé. Il ne doit pas devenir un corpus de réglage ni être rejoué jusqu’à obtenir un résultat favorable.
5. Calibrer prix et expérience
Réserver au plafond prudent du workflow, débiter le coût réel agrégé, libérer la différence et présenter une seule action compréhensible à l’utilisateur.