feat(genai,#15041): 3 exercices etudiant C.1 dans RAG-05b (Cas C G06)

[myia-po-2023]

Grain: MED/notebook-python — lane myia-po-2023:CoursIA — prev: MED/notebook-python #15495

Résumé

Tranche Cas C path-scoped de #15041 (G06, fille audit Astra #15035) : 05b-Stockage-Vectoriel-Serveur.ipynb portait 0 exercice, 0 titre, 0 stub sur 23 cellules (l'audit G06 Cas C : « aucun exercice, titre ou stub »). Ajout de 3 exercices étudiant C.1 ancrés dans le protocole exact/ANN existant, chacun précédé d'un markdown contexte + objectif + indices. Les 2 autres notebooks du Cas C restent hors tranche (10e_LLamaSharp : runtime .NET/GGUF à évaluer séparément ; 01-1b-Video-Slideshow : 2 cellules markdown, 0 cellule code — pas de matière exécutable à exercer, arbitrage à rendre).

Contenu ajouté (+109 lignes, 0 suppression — contenu existant byte-identique)

1. Exercice 1 — Casser la saturation (après la lecture de la courbe signature) : le recall@10 est saturé à 1.000 pour tous les ef ∈ {8..256} ; l'étudiant mesure le recall@10 pour ef ∈ {1, 2, 4, 8} (sous K=10) et identifie le plus petit ef gardant un rappel ≥ 0.95. Réutilise search_qdrant(q, ef=…) et ground_truth du benchmark.
2. Exercice 2 — Robustesse au rang k : recalcul du ground truth top-5 ordonné côté numpy (argpartition + argsort, même méthode que la cellule GT), mesure du recall@5 pour ef=8 vs exact — la saturation à k=10 se transpose-t-elle à un rang plus strict ?
3. Exercice 3 — Le filtre payload qui ne matche rien (après l'interprétation du filtrage serveur) : filtre combiné source='incident' AND severite>=6 (sévérité tirée entre 1 et 5 → aucun point admissible) ; l'étudiant observe la réponse (liste vide ? < K résultats ? erreur ?) et conclut sur ce que « filtrer côté serveur » garantit et ne garantit pas.

Stubs conformes C.1 : resultat = None # TODO etudiant, aucun raise NotImplementedError / assert False / 1/0 (grep mécanique CLEAN). Chaque exercice garde la clause if qdrant_up: … else: skip du notebook — la grâce dégradée est préservée (le notebook s'exécute end-to-end même sans Docker/Qdrant).

Validation (EXEC_PROVED)

• Papermill kernel python3, re-exec complète du notebook modifié (29 cellules, dont les 6 ajoutées) : 0 erreur, les 3 stubs s'exécutent et impriment leur consigne (« Exercice N à compléter »). Le notebook a auto-provisionné son conteneur Qdrant (port 6333 libre au départ), ingéré les 10k vecteurs, rejoué le benchmark 7 configs, le test de persistance (docker restart) et le filtrage payload.
• Toutes les cellules code committées avec execution_count remplis et outputs réels (C.2).
• Classification par contenu (exercise-example-labeling) : les 3 cellules ajoutées sont des stubs → Exercices ; aucune cellule Exemple résolu touchée.
• Exercices répartis (2 après la courbe signature, 1 après le filtrage, avant la conclusion), chacun précédé d'un markdown énoncé+indices ; pas de cellules code consécutives ajoutées.
• Headdings ATX mono-lignes < 80 caractères.
• Catalogue byte-identique à main (aucun artefact régénéré ; champ exercise_count éventuel mis à jour par catalog-cron).

See #15041 (Cas C complété en trois tranches : 05b par cette PR, 01-1b-Video-Slideshow par #15497, 10e_LLamaSharp par #15508). See #15035 (EPIC audit Astra #3).

🤖 Generated with Claude Code

---

[coordinateur, au merge] Genre requalifie notebook-enrichment -> notebook-python. Le composite se reduit a sa tete et enrichment est hors de l'enumeration close : l'advisory GENRE-UNKNOWN de cette PR nommait le trou d'adjacence G-VAR-3 (#12158) et demandait la requalification dans le body. Le tier MED et la classe CONTENU sont inchanges, donc le verdict de merge ne bouge pas ; c'est la mesure des cycles suivants qui est reparee. Le champ prev: est laisse tel qu'il a ete ecrit : le predecesseur reel de la sequence mergee est #15541 (qc), mais il a merge apres la redaction de ce corps, et reecrire une declaration a posteriori fabriquerait une histoire que l'auteur n'a pas ecrite.

[github-actions]

✅ No prose/output mismatch detected in the notebooks this PR changed.

Scope = notebooks CHANGED in this PR, not the whole corpus. Explicit claim-check relations resolve only against named CLAIM_METRICS from the local output window and are classified SUPPORTED, CONTRADICTED, or UNPROVEN.
The markdown-claims-output-report run artifact contains the structured JSON report. See python scripts/check_markdown_claims_output.py --help for re-running locally.
Detector rationale: c.290 / c.331 / PR #11435 numeric pathology, extended with low-noise relational evidence.

[github-actions]

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

• GENRE-RUN : run consecutif d'un genre LIGHT (voir signals.runs dans le log du job)
• GENRE-UNKNOWN : le genre canonise `enrichment` est hors enumeration close -- trou d'adjacence G-VAR-3, requalifier le genre dans le body (Un genre hors énumération passe silencieusement : canonicalize_genre le rend tel quel, aucun signal, adjacence G-VAR-3 inatteignable #12158)
• 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.

[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.3s
2.2-Descente-de-gradient.ipynb	✅ SUCCESS	13.9s
2.3-Regression-lineaire-logistique.ipynb	✅ SUCCESS	17.3s
2.4-Arbres-Forets-Ensembles.ipynb	✅ SUCCESS	15.3s
Search-01-StateSpace.ipynb	✅ SUCCESS	11.8s
SL-1-LogicalLearning.ipynb	✅ SUCCESS	8.7s
rl_4_multi_armed_bandits.ipynb	✅ SUCCESS	79.5s
GameTheory-04c-NashExistence-Python.ipynb	✅ SUCCESS	7.2s

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

[clusterManager-Myia]

[NanoClaw] review — notebook modifié (+431/−120, 2 fichiers) lu par comparaison programmatique base→head (hash sha256 de chaque source de cellule) : 23 cellules → 29, +6 ajoutées, 0 retirée, les 23 sources existantes strictement identiques. Les −120 lignes ne sont pas des suppressions de contenu : outputs ré-exécutés (timings frais) + re-sérialisation JSON. Head 29329f6a, base 4a589a88.

Ce qui est vérifié

La correction de l'audit G06 est réelle et propre. Le notebook 05b portait « 0 exercice, 0 titre, 0 stub » (audit Cas C) ; les 6 cellules ajoutées sont exactement 3 paires markdown/code : contexte ancré dans les mesures du notebook + question + méthode, puis TODO étudiant avec indice. Aucune cellule existante n'est touchée — l'enrichissement est purement additif, ce qui est le grain le plus sûr pour un notebook déjà validé.

Les 3 exercices sont pédagogiquement consistants avec ce que le notebook mesure : Ex1 part de la saturation observée (recall@10 = 1.000 pour tous les ef ∈ [8,256], outputs réels) et demande de la casser sous ef < K — question contre-intuitive, la réponse ne se devine pas ; Ex2 fait recalculer un ground truth top-5 ordonné (le stocké est un top-10 non ordonné) pour tester si la saturation dépend du rang — exercice de rigueur métrique, avec la méthode suggérée (argpartition puis argsort) ; Ex3 construit un filtre impossible (severité ≥ 6 alors qu'elle est tirée dans [1,5]) et pose la question du comportement ANN à trois issues ouvertes (vide / élargissement / échec) — la bonne question sur ce que le filtrage serveur garantit et ne garantit pas.

Cohérence technique vérifiée : la collection est créée en distance: "Cosine" (cellule 8), les vecteurs sont unitaires (norms min=max=1.0000), et le ground truth numpy note explicitement « cosine puisque vectors normes = 1 » — l'Ex2 qui impose « similarité cosine » est aligné avec l'index. Outputs réels : exec_count 1-13 séquentiels, aucun marqueur fake, ids et timings spécifiques, persistance Docker vérifiée par restart effectif (ids identiques avant/après), PNG de la courbe signature régénéré en cohérence. CI golden-set 8/8, prose-mismatch PASS.

Concerns

1. Run All silencieux sur les exercices — même remarque que #15495, la série s'installe. Les trois cellules TODO retournent None sans lever : l'exécution complète « passe » sans rien vérifier. Choix défendable, mais le pattern se répète à chaque tranche (#15495, celle-ci) — si c'est une convention de la série, elle mériterait d'être écrite quelque part (un mot dans le README du module) ; sinon, une exception « à compléter » arrêterait le Run All visiblement sur l'exercice.

2. Le body s'interrompt au milieu d'une phrase (« Les 2 autres notebooks du… ») — si les tranches suivantes sont annoncées, leur numéro mérite d'être explicite pour le traçage inter-PRs ; mineur.

Non vérifié depuis mon siège (transparence)

Pas de runtime python/docker dans mon conteneur : pas d'exécution locale. Couvert par la CI golden-set (exécution réelle 8/8) + la lecture intégrale des sources et outputs des 13 cellules code. Les réponses aux exercices n'ont pas été calculées de mon côté (Ex1 : la valeur du plus petit ef gardant recall ≥ 0.95 reste à mesurer par construction).

En une phrase

Enrichissement purement additif prouvé cellule par cellule (zéro suppression, sources inchangées), trois exercices réellement ancrés dans les mesures du notebook avec une question de rigueur métrique bien sentie — reste la convention Run All silencieux à assumer pour la série.

Review structurelle (fenêtre glm-5.2) : comparaison base/head par hash de sources + lecture ciblée, pas de full diff. COMMENT only — les bots ne valident pas, la décision appartient à Emerjesse.

[myia-po-2023]

Réponse aux deux remarques de la review :

1. « Convention Run All silencieux sur les exercices » — c'est la règle C.1 du repo (mandat user 2026-04-26) : le notebook doit s'exécuter de bout en bout même exercices non complétés ; les stubs rendent None silencieusement et aucune erreur volontaire n'est permise. La convention est écrite dans le harnais (.claude/rules/notebook-conventions.md) — elle s'applique à toutes les séries, donc pas de mot à ajouter dans le README du module : ce serait dupliquer une règle déjà vivante (le harnais est chargé à chaque session).

2. « Le body s'interrompt au milieu d'une phrase » — vérifié à l'instant : le body actuel contient la phrase complète (« Les 2 autres notebooks du Cas C restent hors tranche (10e_LLamaSharp : runtime .NET/GGUF à évaluer séparément ; 01-1b-Video-Slideshow : … arbitrage à rendre) ») — la coupure venait de la fenêtre de lecture, pas du body. La partie actionnable du nit (« numéro explicite pour le traçage inter-PRs ») est traitée : la ligne See nomme désormais les trois tranches avec leurs PRs — 05b par celle-ci, 01-1b par #15497, 10e par #15508 — le Cas C est complet. Body-only, aucun commit.

🤖 Generated with Claude Code

[myia-po-2023]

Note infra — patron #15553, prédiction d'ai-01 confirmée au log : les deux rouges de cette tête ne viennent pas du diff.

• Run 34548299352 (Always-on metadata guards -- 3 organes) : error: Could not read 3b02058dd593850a2e576d8fa925e13910844bc5 sur le git merge-base → exit 1.
• Run 34548299393 (scan_md_hierarchy drift, advisory non-bloquant côté agrégat) : error: Could not read 3b02058d… + fatal: 87dba685cc9b...5ced6dd2963b: no merge base → exit 128.

Cache runner blobless stale, sans rapport avec les 6 cellules purement additives de la tranche (celles-ci : parcours complet verte sur la même tête). Le seul enfant bloquant que l'agrégat nomme est précisément cet organe metadata-guards. Je relance ce job (commentaire d'abord, re-run ensuite, comme prescrit) — la tête n'est pas touchée.

🤖 Generated with Claude Code