doc(migration-mimo): suite 18/08 - straggler nyora-veille corrige + Nabil-Key/Tirith a trancher

2026-08-18 09:52:49 +01:00
parent 0035d193ef
commit 9ee5c3fa40
1 changed files with 36 additions and 0 deletions
@@ -142,3 +142,39 @@ changement, a ne pas oublier lors d'une future migration modele generale sur Bif
 **Point ouvert** : `Yesmine-Key` reste provisionnee sans consommateur actif — aucun agent/client
 n'appelle cette cle aujourd'hui (`hermes-desktop-yesmine` n'existe pas encore cote Windows/Claude
 Desktop). A reevaluer (usage reel, cout, modele par defaut souhaite) quand ce client devient actif.
 ## Suite (2026-08-18) — Straggler nyora-veille (traduction titres) + Nabil-Key/Tirith a trancher
 **Contexte** : sweep demande par Nabil pour reperer tout reliquat DeepSeek V4 Flash apres la
 migration cerveau du 17/08 ci-dessus. Analyse logs Bifrost (`logs.db`) sur une fenetre test
 07h02-07h12 (heure locale) -> 44 appels `deepseek-v4-flash` releves, 2 sources distinctes.
 **Trouvaille 1 (fixee)** : `nyora-veille/backend/routers/opportunites.py`, fonction
 `_translate_titre_fr()` (traduction des titres d'articles a l'ingestion) avait
 `"model": "deepseek-v4-flash"` code en dur, hors de la constante `MODEL = "mimo-v2.5"` deja
 utilisee par le reste du service -- oubli isole, pas un choix delibere. En corrigeant, **meme
 piege deja documente le 17/08** (context_length/max_tokens herites) : `max_tokens: 120` etait
 insuffisant pour mimo-v2.5 (modele reasoning, ~150-190 tok de raisonnement consommes avant le
 contenu final) -> reponse tronquee -> repli silencieux sur le titre original a chaque appel (le
 `except: return titre` avale l'echec sans logger). Corrige a `max_tokens: 500`, verifie en
 direct (traduction correcte, log Bifrost confirme `model=mimo-v2.5`). **Latence x8-10** (1-2s ->
 11-18s/appel) a surveiller sur le prochain run 3x/jour (boucle sequentielle dans `ingest_batch`,
 pas de parallelisation). Commit `bolbol/nyora-veille@08cd09e`.
 **Trouvaille 2 (PAS touchee, decision a prendre avec Nabil)** : virtual key `Nabil-Key`, prompt
 "security reviewer for an AI coding agent" (garde-fou Tirith avant execution de commande shell)
 -- toujours sur `deepseek-v4-flash`. Source introuvable sur le filesystem NAS (grep infructueux
 dans hermes-platform/*/config, workspace, scripts) -- probablement cuit dans l'image agent, pas
 dans un fichier monte/versionne. **Volontairement pas migre** : c'est un garde-fou de securite
 sur le chemin critique (avant CHAQUE commande shell), et mimo-v2.5 ajoute 10-15s de latence par
 appel (reasoning) -- risque de ralentir/bloquer visiblement les agents si applique sans
 reflexion prealable. A trancher : cout (raison de la migration globale, cf tarification
 DeepSeek en tete de ce runbook) vs latence sur un chemin de securite. Ne pas migrer sans
 validation explicite de Nabil.
 **Regle generale retenue** : apres toute migration de modele par defaut, chercher aussi les
 appels Bifrost HORS de la config centrale (model code en dur dans du code applicatif, comme
 ici) -- une migration "config.yaml" ne couvre pas ces cas ; seul un balayage des logs Bifrost
 (`logs.db`, table `logs`, colonnes `model`/`virtual_key_name`/`timestamp`) sur une fenetre
 temporelle les revele de facon fiable.