From 9ee5c3fa40184e0bf6abe7e50ff606a54e8c565e Mon Sep 17 00:00:00 2001 From: Nabil Derouiche Date: Tue, 18 Aug 2026 09:52:49 +0100 Subject: [PATCH] doc(migration-mimo): suite 18/08 - straggler nyora-veille corrige + Nabil-Key/Tirith a trancher --- common/migration-mimo-v25-cerveau-hermes.md | 36 +++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/common/migration-mimo-v25-cerveau-hermes.md b/common/migration-mimo-v25-cerveau-hermes.md index 72e921c..e4b9482 100644 --- a/common/migration-mimo-v25-cerveau-hermes.md +++ b/common/migration-mimo-v25-cerveau-hermes.md @@ -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.