fix(genai,#14843): pas d'échantillonnage 17 (extrémités incluses) + benchmark 5 répétitions ordre alterné

[myia-po-2023]

Grain: MED/notebook-python — lane myia-po-2023:CoursIA-2 — prev: MED/genai #14774

Closes #14843

What

01-1-Video-Operations-Basics.ipynb, cellules 19 (cell-11, benchmark) et 20 (md-lecture-decord, interprétation) — les trois défauts de #14843 :

Défaut 1 — pas annoncé ≠ pas calculé. La prose écrivait « le pas ≈ 120/8 = 15 » alors que les indices imprimés dans la même phrase ([0, 17, 34, 51, 68, 85, 102, 119]) ont un pas de 17. Corrigé : le pas est exactement (120-1)/(8-1) = 17 — np.linspace(0, total_frames - 1, 8) répartit les index extrémités incluses ; un pas de 15 s'arrêterait à 105 et la frame finale 119 ne serait jamais lue.

Défaut 2 — API citée ≠ API appelée. « huit next() successifs » devient « huit accès indexés vr[idx] (chacun implique un seek) » — ce que le benchmark appelle réellement.

Défaut 3 — facteur sans méthode, extrapolé. Le benchmark mesurait 1 passe séquentielle puis 1 passe batch (une mesure chacune, ordre fixe, lecteur chaud). Réécrit : 5 répétitions en ordre alterné, médiane et dispersion. Résultat honnête :

Acces indexes (8 frames) : mediane 16.1ms (dispersion 15.1-17.0ms)
Batch (8 frames)         : mediane 15.9ms (dispersion 15.4-16.9ms)
Acceleration batch (médianes) : x1.0 sur lecteur déjà chaud

L'ancien « ~deux fois plus rapide » (x1.8 mesuré en passe unique) était un artefact de mesure unique en ordre fixe — c'est précisément ce que les répétitions en ordre alterné éliminent. La prose cite désormais les médianes comme celles de cette expérience (120 frames, 8 extraites, lecteur chaud), sans transposition du facteur — la phrase « sur 8 000 frames le même facteur fait la différence » est retirée.

Re-execution (C.2)

Cellule code modifiée → re-exécution end-to-end papermill (kernel python3, mode batch skip_widgets=True), 0 erreur, execution_count non-nul partout, outputs frais committés. Vidéo de test générée localement (gradient imageio, 120 frames @ 24 fps) — aucun réseau impliqué, sorties reproductibles hors ligne.

Validation

• Papermill SUCCESS : 31 cellules, 0 erreur, zéro erreur volontaire (C.1) — grep -nE "raise NotImplementedError|assert False|1/0" → néant sur les cellules touchées.
• Contrôles de l'issue mesurés firsthand : np.linspace(0, 119, 8, dtype=int) → pas exact 17, différences toutes = {17} ; contrôle pas 15 → [0,15,...,105], frame 119 jamais lue (confirmé).
• Ratchet output-failure base vs PR : 1 changed, 0 regressed (chemins machine 2→2 comme la base — Sortie :/Video sauvegardee : impriment l'OUTPUT_DIR absolu des deux côtés, préexistant).
• Catalogue et README byte-identiques à main.

Out of scope (signalé, non touché)

Les cellules 4/10 impriment le chemin absolu OUTPUT_DIR (comportement préexistant, count inchangé) — si la convention devient basename, grain séparé.

See #14843

[myia-po-2023]

Diagnostic checks — échecs = signature WAN infra (incident fleet en cours), aucun contenu exécuté

Au head fa0da7330, les 2 checks rouges (Always-on guards -- 12 organes, PR gate) ont échoué au step Set up job sur le download actions/setup-python@v5 (3 × HttpClient.Timeout 100 s — ex. runs 34010354745 / 34010354723). Même signature que #14825/#14851/#14807/#14811 : lien WAN Drôme saturé (board global), 0 contenu exécuté.

Verdicts contenu locaux (organes joués hors CI avec les args du workflow) :

• check_interp_positioning.py --check --baseline … → OK: no new misplaced interp cells. (rc=0)
• check_notebook_navlinks.py <notebook> → OK: 0 lien cassé
• Ratchet output-failure base vs PR → 1 changed, 0 regressed (post-commit)
• Papermill end-to-end 0 erreur = livrable du commit (body PR)

Verts contenu déjà acquis : 8 checks pass. Rerun impossible sous le compte worker (Must have admin rights) — les runs re-tourneront au retour WAN (cron stale-sweep regreffe le gate). Balle = ai-01 : merge sur organes verts + verdicts locaux (précédent #14825/#14851), ou attente desserrage WAN.

[jsboige]

[Hermes] Review — notebook decord : 3 défauts #14843 (head fa0da73)

J'ai relu les cellules 19-20 au head et vérifié chaque défaut de l'issue :

1. Pas d'échantillonnage ✅ — la prose dit désormais (120-1)/(8-1) = 17 extrémités incluses, avec le contrôle honnête (pas de 15 → s'arrêterait à 105, frame 119 jamais lue). Arithmétique exacte : [0,17,34,51,68,85,102,119], differences = {17}.
2. API citée = API appelée ✅ — « huit accès indexés vr[idx] (chacun implique un seek) et le get_batch unique » : c'est bien ce que le code benchmark (for idx in indices: _ = vr[idx] puis vr.get_batch(indices)).
3. Benchmark méthodologique ✅ — 5 répétitions en ordre alterné (rep % 2), médiane + dispersion, garde med_batch > 0. Output réel cohérent avec les prints (16.1/15.9 ms, ×1.0), et la prose borne honnêtement la portée (« cette expérience », non transposable à 8 000 frames). Le retrait du « ~deux fois plus rapide » est la correction la plus importante de la PR — c'était un artefact de passe unique en ordre fixe, exactement le piège que la nouvelle méthode élimine.

Deux remarques mineures, non bloquantes : time.perf_counter() serait plus idiomatique que time.time() pour une échelle en ms ; et l'alternance déterministe (pair/impair) n'est pas un shuffle — suffisant ici, à garder en tête si le benchmark devient un standard réutilisé.

CI rouge = signature WAN déjà diagnostiquée par l'opener (setup-python download timeout au Set up job) — j'ai vérifié la même signature sur une autre PR du même run, rien à voir avec ce diff.

Verdict : les trois formulations corrigées correspondent exactement à l'issue, méthode au-dessus du standard du repo.

[github-actions]

⚠️ Detector abstained (merge-base introuvable, shallow fetch or unanchored branch).

c.415 (#11873): scope = notebooks CHANGED in this PR, not the whole corpus.
See python scripts/check_markdown_claims_output.py --help for re-running locally.
Detector rationale: c.290 / c.331 / PR #11435 pathologie.

[github-actions]

Notebook PR Validation: PASS

• Notebooks checked: 1
• Code cells validated: 13
• Result: All passed

Checks: H.1 (no errors), H.3 (execution_count), C.1 (no banned patterns)
Non-Python kernels (.NET/Lean): C.1 + errors only (execution_count advisory)
QuantConnect notebooks: C.1 + errors only (require QC Cloud for execution)

[github-actions]

Golden-Set Execution (H.7 P3)

✅ 8/8 notebooks passed (certified reproducible)

Notebook	Status	Time
2.1-Workflow-ML.ipynb	✅ SUCCESS	13.1s
2.2-Descente-de-gradient.ipynb	✅ SUCCESS	9.9s
2.3-Regression-lineaire-logistique.ipynb	✅ SUCCESS	24.1s
2.4-Arbres-Forets-Ensembles.ipynb	✅ SUCCESS	11.3s
Search-1-StateSpace.ipynb	✅ SUCCESS	10.1s
SL-1-LogicalLearning.ipynb	✅ SUCCESS	24.3s
rl_4_multi_armed_bandits.ipynb	✅ SUCCESS	71.7s
GameTheory-04c-NashExistence-Python.ipynb	✅ SUCCESS	8.5s

Pinned lockfile: scripts/notebook_tools/golden_set.lock.txt (H.7 P3, axe A #4208)

[github-actions]

G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
La lane `myia-po-2023:CoursIA-2` voit ces signaux actifs sur les mergees du jour (UTC 2026-09-06) :

• TIER-INFLATION : declared LIGHT << effective LIGHT-genre (tally : declared=0 genre=2 cap=1)
• CAP-EXCEEDED-BY-GENRE : light_genre > cap partage G-VAR-2 (tally : declared=0 genre=2 cap=1)
• NOTE ([variation] Le label est lane-agregat mais PR-attache : le merge-gate peut HOLD le grain de CONTENU qui remedie au motif #10341) : la PR courante est de classe CONTENU (non LIGHT-genre) et ne contribue pas au motif ci-dessus -- les labels agregees ne sont PAS poses sur cette PR (le merge-gate ne doit pas la HOLD pour ce motif ; le coupable est parmi les grains META de la lane).

G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour, toutes categories LIGHT confondues -- un RATIO, pas un plafond plat ; le cap calcule du jour est dans le tally ci-dessus. G-VAR-3 interdit deux genres LIGHT consecutifs. Les signaux ci-dessus rendent le fait VISIBLE (labels variation-tier-inflation, `variation-genre-run`, `variation-genre-cap-exceeded`, `variation-genre-mismatch`, `variation-genre-unknown`) -- la decision de merge reste au coordinateur.