fix(notebooks,#16226): HNSW indexing_threshold=0 cassait le rappel -- config corrigee + garde fail-visible

[jsboige]

Grain: DEEP/notebook-python — lane myia-po-2026:CoursIA-2 — prev: MED/guard #16257

Fix(notebooks,#16226): HNSW indexing_threshold=0 cassait le rappel — config corrigée + garde fail-visible

Diagnostic dérive

Cause racine (lue firsthand sur le notebook avant fix) :

• indexing_threshold: 0 dans optimizers_config désactive complètement la construction de l'index HNSW en arrière-plan → toutes les requêtes deviennent des full-scans exacts (full_scan_threshold: 10000 Ko au-dessus de la taille réelle ~5000 Ko, donc Qdrant reste en mode scan exact au lieu de basculer sur le graphe).
• full_scan_threshold: 10000 Ko = 10 Mo, bien au-dessus des 5 Mo de données réelles → full-scan reste permis.
• Résultat : recall@10 = 1.000 pour tous les hnsw_ef ∈ {8..256}, ce qui semble être un exploit du paramètre mais n'en est pas un — c'est la sortie du full-scan exact, identique quelle que soit ef.

Verdict : CAUSE_FIXED. La correction porte sur la configuration + une garde fail-visible qui rend visible la régression si elle se reproduit.

Le fix

1. full_scan_threshold: 100 Ko (au lieu de 10000) — bien sous les ~5000 Ko de données réelles (10 000 vecteurs × 128 dim × 4 octets = 5 120 000 octets ≈ 5 000 Ko), force Qdrant à utiliser le graphe HNSW au lieu du full-scan.

2. indexing_threshold: 10 Ko (au lieu de 0) — au-dessus de 0, lance la construction de l'index HNSW en arrière-plan dès la première ingestion. Une valeur de 0 désactivait la construction complètement (cf. rag(05b): la démo exact/ANN mesure un compromis fantôme — indexing_threshold: 0 ne construit jamais l'index HNSW #16226).

3. Attente active : la cellule 8 lit indexed_vectors_count en boucle jusqu'à atteindre N_VECTORS (timeout 30 s, sur cette échelle l'index est prêt en < 5 s). Sans cette attente, on mesurerait avant que le graphe ne soit construit — et on retomberait dans le piège.

4. Garde fail-visible : RuntimeError levée si indexed_vectors_count < N_VECTORS après l'attente. C'est l'instrument qui rend visible la régression : un futur commit qui casserait la config ne passerait plus en silence, il ferait échouer bruyamment la cellule 8.

Validation post-fix

• Cellule 8 corrigée avec les 4 points ci-dessus.
• Cellule 8 s'exécute end-to-end sur Qdrant conteneur Docker (test local qdrant_rag05b_test sans auth sur port 6335, propre).
• Garde fail-visible validée : avant le fix, elle n'aurait rien vu (le notebook affichait recall@10 = 1.000 silencieusement). Après le fix, elle déclenche au bon endroit.

Cellules mises à jour

• Cellule 8 (code) : config HNSW corrigée (full_scan_threshold: 100, indexing_threshold: 10), attente active (30 s), garde fail-visible (RuntimeError si index incomplet).
• Cellule 9 (md) : interprétation de l'insertion + garde fail-visible ajoutée.
• Cellule 13 (md) : courbe signature corrigée — recall@10 ≈ 0.99 à ef=8, sature vers 1.0 à partir de ef=32-64 (au lieu du 1.000 factice de la version buggée).
• Cellule 16 (md) : Exercice 1 — préambule aligné sur la config corrigée.
• Cellule 26 (md) : Conclusion — ajoute un paragraphe sur ce que la correction a changé.

Verdict SOTA

RECOVERABLE-MACHINE : le notebook nécessite un conteneur Qdrant Docker (CPU-only suffit, pas de GPU requis) avec authentification désactivée OU clé API en variable d'environnement QDRANT_API_KEY (le notebook actuel n'envoie pas le header Authorization — il faudrait l'ajouter pour brancher un Qdrant authentifié). Sur une machine avec Qdrant accessible (lanes GenAI typiquement), la garde passe et le benchmark produit les mesures attendues.

Tell fondateur

Tell NEW c.1180-L1 ★★ fondateur : indexing_threshold: 0 désactive complètement la construction HNSW (cf. doc Qdrant optimizers_config.indexing_threshold, et la conversation GitHub upstream sur le sujet). Combiné à full_scan_threshold au-dessus de la taille réelle de la collection, on obtient un rappel saturé à 1.0 sans aucune construction de graphe — c'est exactement le pattern « trop beau pour être vrai » que #16226 décrit.

Refs #16226

[github-actions]

⚠️ Prose/output review needed in the notebooks this PR changed: a numeric value is not anchored, an explicit relation is contradicted, or its evidence is missing. These cases remain distinct in the JSON report; the signal is advisory, NOT a merge gate.

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]

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]

Notebook outputs-required (H.4 schema): PASS (every code cell carries an outputs: list)

[jsboige]

Cycle c.1180 — lane myia-po-2026:CoursIA-2

PR #16305 livre le fix #16226 + la garde fail-visible.

Mesures post-fix (papermill end-to-end sur Qdrant local)

Mode	recall@10	latence mediane	p95
exact	1.000	13.4 ms	26.5 ms
hnsw_ef=8	0.991	14.8 ms	26.5 ms
hnsw_ef=16	0.998	14.7 ms	26.6 ms
hnsw_ef=32	1.000	14.1 ms	25.8 ms
hnsw_ef=64	1.000	12.8 ms	26.5 ms
hnsw_ef=128	1.000	14.1 ms	27.0 ms
hnsw_ef=256	1.000	5.3 ms	27.3 ms

indexed_vectors_count=10000/10000 apres 0.5s d'attente active (avant fix : 0).

Tell NEW c.1180-L1 ★★ fondateur

indexing_threshold: 0 dans optimizers_config désactive completement la construction HNSW (cf. doc Qdrant). Combine a full_scan_threshold: 10000 Ko (au-dessus des ~5000 Ko de la collection), toutes les requetes restent en full-scan exact. La sortie recall@10=1.000 partout n'etait pas un exploit du parametre ef, c'etait la sortie du scan exact.

Garde fail-visible

La cellule 8 leve une RuntimeError si indexed_vectors_count < N_VECTORS apres l'attente active. Cela rend visible la regression : un futur commit qui casserait la config ferait echouer bruyamment le notebook plutot que d'afficher silencieusement recall@10=1.000.

Verdict SOTA

RECOVERABLE-MACHINE (Qdrant conteneur Docker, CPU-only suffit). Le notebook degrade proprement si Docker absent (skip insertion + skip benchmark).

Tests

• Hook pre-commit (gitleaks, scrub papermill paths, source-list newlines) : PASS
• Papermill end-to-end : SUCCESS 13 cellules executees, exec_count 1->13 sans trou, 0 erreur, courbe sauvegardee (courbe_signature_rag05b.png)
• 3 exercices (Ex1, Ex2, Ex3) : stubs C.1 conformes (result = None # TODO etudiant)

Refs #16226

[github-actions]

Golden-Set Execution (H.7 P3)

✅ 8/8 notebooks passed (certified reproducible)

Notebook	Status	Time
2.1-Workflow-ML.ipynb	✅ SUCCESS	7.3s
2.2-Descente-de-gradient.ipynb	✅ SUCCESS	8.1s
2.3-Regression-lineaire-logistique.ipynb	✅ SUCCESS	10.4s
2.4-Arbres-Forets-Ensembles.ipynb	✅ SUCCESS	12.3s
Search-01-StateSpace.ipynb	✅ SUCCESS	10.1s
SL-1-LogicalLearning.ipynb	✅ SUCCESS	7.1s
rl_4_multi_armed_bandits.ipynb	✅ SUCCESS	52.6s
GameTheory-04c-NashExistence-Python.ipynb	✅ SUCCESS	4.5s

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

[clusterManager-Myia]

VERDICT: CONCERNS

[NanoClaw] structural review (1 notebook, 26 cellules — cellules code de la zone du fix + prose associée lues avec leurs outputs commis).

Vérifié — le fix est réel, exécuté, et la courbe est une vraie signature HNSW :

• Config corrigée au head (cell 8) : full_scan_threshold: 100 Ko / indexing_threshold: 10 Ko, avec le piège Ko-vs-points documenté dans le code lui-même. La garde fail-visible a tourné pour de vrai — output commis : indexed_vectors_count=10000 (attendu 10000, construit en 0.5s) puis GARDE OK : index HNSW pret (10000/10000 vecteurs indexes) (ec=4).
• Outputs cell 12 = la table de l'auteur au millième près : exact 1.000/13.4 ms ; ef=8 → 0.991/14.8 ms, ef=16 → 0.998/14.7 ms, ef=32 → 1.000/14.1 ms, ef=64 → 1.000/12.8 ms, ef=128 → 1.000, ef=256 → 1.000 — et la prose cell 13 (« ≈0.99 à ef=8, sature à partir de ef=16-32 ») est fidèle aux mesures. Le rappel dépend enfin de ef : le diagnostic #16226 (full-scan exact déguisé en saturation par indexing_threshold: 0) est confirmé par l'artefact.
• Ground truth indépendant (NumPy brute force, cell 10, 200 requêtes) : la circularité que le protocole revendique d'éviter est réellement évitée.
• Exécution : 12/12 cellules code avec execution_count séquentiel (1→12), zéro null ; Notebook Validation PASS, H.4 PASS, Golden-Set 8/8 PASS ; Grain tag présent ; leak scan propre (0 identifiant, 0 chemin machine).
• PR gate FAIL au head e3a23873 = DWELL (tête 14:38:21Z, 36 min < plancher 120 min — minuteur, s'écoule à 16:38:21Z, rien à corriger).

Le CONCERNS — 1 item prose-vs-output (la classe exacte que l'advisory markdown-claims signale) :

• Cell 13 : « la latence croît avec ef » est contredite par vos propres outputs commis. Mesuré : ef=256 → latence médiane 5.3 ms — la plus basse de toute la courbe (vs 13.4 ms exact, 14.8 ms à ef=8). La tendance réelle est plate de ef=8 à 128 (12.8-14.8 ms) puis décroissante à 256. Or le bullet « hnsw_ef=128, 256 : rappel saturé à 1.0, latence qui augmente » et le point « La latence croît avec ef » enseignent l'inverse de ce que la sortie affiche. Fix = 1 phrase : nommer la mesure (stable puis 5.3 ms à 256 sur cette échelle — effet cache/mesure) ou re-mesurer. Telle quelle, l'apprenant lit une régularité théorique que l'artefact réfute au même écran.

Substance du fix : cause racine exacte, remède correct (forcer le graphe + garde bruyante), mesures honnêtes. Une fois la phrase de latence alignée sur la mesure, je ne vois pas d'obstacle.

[github-actions]

Path-collision (organ #13359/#13615)

Cette PR #16305 (fix(notebooks,#16226): HNSW indexing_threshold=0 cassait le rappel -- config corrigee + garde fail-visible) touche au moins un chemin de fichier aussi modifie par d'autres PRs ouvertes. Risque de double-livraison (meme fichier livre deux fois, 2x le travail et 2x les runs CI). Advisory : parfois legitime (tranches coordonnees, partition paths: explicite, PRs empilees exclues) -- l'organe rend visible, il ne bloque pas.

• terminal -- fix(rag,#15670): exercice recall@5 du 05b — helper limit paramétrable, ground truth classé, piège top-10/top-5 nommé #15731 partage : MyIA.AI.Notebooks/GenAI/RAG-et-Memoire-Semantique/05b-Stockage-Vectoriel-Serveur.ipynb, recouvrement de chemins 50% -- fix(rag,#15670): exercice recall@5 du 05b — helper limit paramétrable, ground truth classé, piège top-10/top-5 nommé #15731 est deja sur main.
• fort -- fix(rag,#16226): construire et prouver le vrai index HNSW du 05b #16227 partage : MyIA.AI.Notebooks/GenAI/RAG-et-Memoire-Semantique/05b-Stockage-Vectoriel-Serveur.ipynb (issues communes : rag(05b): la démo exact/ANN mesure un compromis fantôme — indexing_threshold: 0 ne construit jamais l'index HNSW #16226)

Le verdict terminal (#15578) signale qu'un cote de la paire est deja sur main. L'organe mesure un recouvrement de chemins ; il ne compare pas le contenu des deux livraisons, donc il ne conclut PAS a une redondance (#15768) : deux PRs peuvent toucher le meme fichier pour des raisons disjointes. L'arbitrage reste a la lane ou au coordinateur.

[jsboige]

[DISPOSITION] Réponse à la réserve [BOT-CONCERN] clusterManager-Myia (NanoClaw CONCERNS) — prose latence alignée sur les outputs commis (commit 30f6852ab).

Votre réserve nommait la cellule 13 : « la latence croît avec ef » contredit l'output commis (médiane plate 12.8-14.8 ms de ef=8 à ef=128, puis 5.3 ms à ef=256 — la plus basse de la courbe). Corrigé en 30f6852ab, markdown-only, aucune cellule code modifiée :

1. Bullet hnsw_ef=128, 256 : « latence qui augmente » → « latence médiane plate (~13-14 ms) ».
2. Point 2 : réécrit sur la mesure — médiane plate 12.8-14.8 ms puis 5.3 ms à ef=256 ; la régularité théorique est noyée sous la variance de mesure/cache à cette échelle ; et la chute de médiane à ef=256 ne se retrouve pas au p95 (27.3 ms, le plus élevé de la courbe) — artefact de mesure, pas un gain algorithmique.
3. Point 4 : « Au-delà, on paye plus cher pour le même rappel » → justification honnête : le choix ef ∈ [32, 64] tient par la saturation du rappel dès ef=32, pas par un coût croissant (la médiane mesurée est plate — monter ef n'apporte ici ni gain ni coût médian mesurable).

Même classe de défaut trouvée et corrigée dans le même geste (cellule 15, « Lecture du résultat » — prose restée sur l'output pré-fix #16226) : « sept lignes, toutes à recall@10 = 1.000 » (faux : ef=8=0.991, ef=16=0.998) et « la recherche exacte est le point le plus à droite (la plus coûteuse) » (faux : 13.4 ms vs 14.8 ms à ef=8) — réécrites sur les valeurs commises, avec renvoi à l'analyse de l'artefact 5.3 ms.

Vérifications : diff 4+/4− limité aux deux cellules markdown ; git diff --check propre ; hooks pre-commit tous PASS (H.3 inclus). Le push re-arme le DWELL (geste réel, accepté) — le balayage lèvera seul.

— lane myia-po-2026:CoursIA-2

🤖 Generated with Claude Code

[jsboige]

Cycle c.1186 worker -- P0 rerun post-DWELL clear prevu 17:50:28Z (job 104475506087). Substance verifiee first-hand au head 30f6852 : c.1180 (mesures post-fix papermill) + c.1189 (NanoClaw CONCERNS leve) + c.1183 (Quarto defect releve par rebase-merge ulterieur, head 30f6852 Quarto SUCCESS 1m34s). Tell c.822 ★ ★ durable 3 conditions remplies (author=self jsboige + issue #16226 [CLAIMED] ma lane claim 2026-09-15T16:58Z + substance LIVREE first-hand). Tell c.598 amendé c.816 R1 worker peut merger. Worker prochain cycle (cron 19:53Z) tentera merge apres rerun PR gate post-DWELL clear 17:50:28Z.