# Pre-enregistrement — latence de Jev depuis l'Europe (via OpenRouter) **Ecrit le 2026-09-20, AVANT la collecte.** Les predictions ci-dessous sont figees. Les resultats seront publies qu'ils les confirment ou non. ## Contexte - Lieu : Europe de l'Ouest, fibre (~18 ms RTT vers la passerelle). - Acces : OpenRouter `POST /api/alpha/decisions`, modele `typesafe/jev-1.13`. Ce n'est PAS l'API native TypeSafe : les mesures incluent le detour par le gateway. C'est declare, pas corrige. - TypeSafe annonce 70-500 ms de bout en bout, mesures "depuis nos laptops sur la cote Ouest" (leur blog du 15/09). - Un appel pilote a donne 733 ms, TLS inclus, n=1. Les predictions ci-dessous sont faites en connaissance de ce chiffre. ## Questions 1. Quelle est la latence reelle depuis l'Europe, apres warm-up ? 2. Quelle part est du reseau, quelle part est du serveur ? 3. La latence est-elle plate en fonction du nombre de questions, comme l'implique leur revendication de sampler parallele ? 4. Comment se comporte-t-elle face a la taille de l'etat et a la cardinalite ? ## Predictions (falsifiables) - **P1** — La mediane apres warm-up depasse 500 ms, soit au-dessus de la fourchette annoncee. - **P2** — Le RTT reseau represente moins de 10 % de la latence totale. - **P3** — Passer de 1 a 12 questions coute moins de 50 ms en mediane (sampler parallele). Si c'est faux, leur revendication architecturale prend un coup. - **P4** — La latence croit avec la taille de l'etat, mais sous-lineairement. - **P5** — Une cardinalite de 200 est plus lente qu'une de 3 (le seuil des 255 options declenche un systeme en deux etapes, la degradation devrait s'amorcer avant). ## Protocole - 8 cellules : une baseline, puis un axe varie a la fois. - 60 mesures par cellule, ordre des appels **randomise** pour ne pas confondre une derive de charge serveur avec l'effet mesure. - 10 appels de warm-up jetes (handshake TLS, demarrage a froid). - Connexion HTTP reutilisee, comme en production. - RTT TCP et TCP+TLS re-mesures tous les 50 appels pour surveiller le reseau pendant la collecte. - On rapporte p50/p90/p95/p99, pas des moyennes : sur un budget temps reel c'est la queue qui tue. - Toutes les reponses brutes sont enregistrees en JSONL. ## Ce qui invaliderait la manip - Un RTT qui derive de plus de 50 % pendant la collecte (reseau instable). - Un taux d'erreur HTTP superieur a 2 %. - Une derive monotone de la latence dans le temps independante des cellules (rate-limiting progressif cote gateway). --- # Vague 2 — ecrit le 2026-09-20 avant la collecte ## Test 2 — biais de position (ordre des options) Meme question, options permutees. On mesure le taux de retournement de la reponse et le deplacement de la probabilite attribuee a une option donnee. - **P6** — Le taux de retournement sur des items NON ambigus est < 2 %. - **P7** — Sur des items ambigus (construits pour que deux options se valent), la position influence la reponse : ecart de probabilite > 5 points entre la position 1 et la derniere position pour la meme option. ## Test 3 — francais contre anglais Meme jeu d'items, traduit. Items a verite terrain certaine. - **P8** — L'ecart de justesse entre les deux langues est < 5 points. - **P9** — La confiance mediane est plus basse en francais qu'en anglais. - **P10** — La latence est identique (la langue ne change pas le cout fixe). ## Test 4 — arithmetique et comparaisons Leur doc : "ne peut pas compter, faire de l'arithmetique, raisonner sur des dates". Jamais chiffre. On gradue la difficulte. Familles : comparaison de deux nombres, comptage d'occurrences, somme simple, ordre de deux dates, appartenance a une fenetre de dates. - **P11** — Comparer deux nombres eloignes (ordre de grandeur different) marche > 90 %. - **P12** — Comparer deux nombres proches (meme ordre de grandeur, ecart < 5 %) tombe sous 70 %. - **P13** — Le comptage d'occurrences au-dela de 5 elements tombe sous 60 %. - **P14** — L'ordre de deux dates marche mieux que l'appartenance a une fenetre (qui demande deux comparaisons). - **P15** — Sur les items rates, la confiance reste haute (> 0.8) : le modele se trompe avec assurance. C'est le point qui compte pour l'usage reel. --- # Vague 3 — ecrit le 2026-09-20 apres les resultats de la vague 2 ## Pourquoi cette vague existe Deux corrections a mes propres erreurs de conception : 1. **Le test 3 etait trop facile.** 100 % dans les deux langues, confiance saturee a 1.000. Aucune information. C'est exactement l'erreur de Laszlo Fazakas que j'avais moi-meme relevee quelques heures plus tot. On refait avec des items durs : ironie, implicite, registre familier, fautes de frappe, et pieges lexicaux (un mot qui pointe vers la mauvaise categorie). 2. **Le test 4 presentait les nombres de facon epuree** ("A = 45231"). La doc de TypeSafe parle peut-etre de nombres noyes dans du texte. On refait avec les memes comparaisons placees dans des mails realistes. ## Test 3b — langue, version difficile - **P16** — La justesse chute sous 85 % dans les deux langues (le banc discrimine enfin). - **P17** — L'ecart FR/EN depasse 5 points, au desavantage du francais. - **P18** — Sur les items rates, la confiance mediane reste sous 0.80 (le modele signale son incertitude, comme au comptage). ## Test 4b — nombres noyes dans du texte realiste Memes familles qu'au test 4, mais les valeurs sont inserees dans un mail d'une centaine de mots, avec d'autres nombres parasites autour. - **P19** — La comparaison de nombres proches chute d'au moins 15 points par rapport au format epure (100 % au test 4). - **P20** — La presence de nombres parasites fait plus de degats que la longueur du texte. - **P21** — Le comptage reste le point faible, sous 80 %. --- # Vague 4 — cartographie complete. Ecrit le 2026-09-20 avant collecte. ## E5.1 — Latence sous concurrence Tous les travaux publics testent en sequentiel. Personne n'utilise un modele ainsi en production. Niveaux : 1, 2, 4, 8, 16, 32 requetes simultanees. - **P22** — La latence par requete reste stable jusqu'a 8 simultanees (hausse < 20 % de la mediane par rapport au sequentiel). - **P23** — Le debit (requetes/seconde) croit quasi lineairement jusqu'a 8. - **P24** — Au-dela de 16, degradation nette : soit erreurs de limitation de debit, soit latence mediane multipliee par plus de 1,5. - **P25** — Le taux d'erreur reste nul jusqu'a 8 simultanees. ## E2.1 — Replication du resultat "la doc sous-estime le modele" (R12) Designs alternatifs : formats de date varies (ISO, texte, americain, abrege), nombres decimaux / a separateurs / negatifs / tres grands, version anglaise, ordre des valeurs inverse, et comparaison a trois valeurs. - **P26** — La comparaison de nombres reste > 95 % sur TOUS les formats. - **P27** — Le format de date le plus fragile est le format americain (mm/jj/aaaa), ambigu avec le format francais. - **P28** — La comparaison a trois valeurs est moins bonne qu'a deux. - **P29** — Les nombres negatifs sont le point faible (il faut inverser l'ordre). ## E3.1/3.2/3.3/3.5 — Robustesse de conception La doc dit : "curer ce que tu envoies est ton travail, et c'est l'essentiel du travail". Jamais chiffre. On mesure ce que coute chaque erreur de conception. - **P30** — Cinq paraphrases de la meme instruction font varier la justesse de plus de 5 points entre la meilleure et la pire. - **P31** — Supprimer les descriptions de criteres coute plus de 10 points. - **P32** — Des descriptions volontairement trompeuses coutent plus cher que des descriptions absentes. - **P33** — Ajouter une option "autre" ameliore la justesse sur les items qui ne relevent d'aucune categorie, sans degrader les autres. - **P34** — Le determinisme est superieur a 99 % (reponse identique sur 60 appels identiques). ## E5.2/5.3/5.4 — Murs physiques - **P35** — La justesse chute avant 255 options (la doc annonce un basculement en deux etapes a ce seuil). - **P36** — La latence augmente nettement au-dela de 100 options. - **P37** — La limite de contexte reelle via OpenRouter est 32k, pas 64k. - **P38** — Le message d'erreur en cas de depassement est explicite. - **P39** — Aucune reponse ne sortira jamais du schema declare (type-safety). - **P40** — Il existe une limite au nombre de questions par appel, inferieure a 100. ## E4.1/4.3/4.4 + E2.4 — Confiance sous difficulte controlee Difficulte graduee par MELANGE : un message de 6 phrases dont k pointent vers la categorie A et 6-k vers B. Verite = majorite. k=3 : ambiguite vraie, sans reponse correcte definissable. - **P41** — Le banc peuple enfin les bandes de confiance intermediaires (moins de 60 % des reponses a confiance > 0.99). - **P42** — A k=3 (50/50 exact), la probabilite mediane de chaque option est comprise entre 0.40 et 0.60. - **P43** — La justesse suit monotonement l'ecart |k-3|. - **P44** — Sur un etat vide ou sans rapport, la confiance reste elevee (> 0.8) : le modele tranche dans le vide. Prolonge le resultat de E3.3. - **P45** — Des trois primitives, noul est la mieux calibree (c'est la seule dont la sortie EST une probabilite). ## E3.4 / E2.3 / E5.3bis / E2.2 — Dernier lot - **P46** — Le taux de retournement sous injection en francais est <= 5 % (Laszlo mesure 1/30 en anglais). - **P47** — Aucun retournement au-dessus de 0.90 de confiance (Laszlo : 0/30). - **P48** — Une instruction negative ("ne concerne PAS") fait chuter la justesse de plus de 20 points : la doc annonce une lecture litterale. - **P49** — La limite de contexte reelle via OpenRouter se situe entre 30k et 64k tokens. - **P50** — Au comptage, la similarite des distracteurs pese plus que la longueur de la liste.