nas-runbooks/hermes-nyora/verdict-pilote-mimo-v25.md

4.2 KiB
Raw Blame History

Verdict pilote mimo-v2.5 sur hermes-nyora — GARDER mimo (2026-07-08)

Contexte

Pilote lancé le 2026-07-05 : mimo-v2.5 (provider opencode-go) en modèle par défaut de hermes-nyora, en comparaison avec DeepSeek V4 Flash (l'ancien défaut de la plateforme). Dispositif de comparaison : cron veille-ia-nexum-compare-deepseek rejouant le MÊME brief de veille Dr. Nexum (mêmes items de /opt/data/veille_raw.json) avec V4 Flash, 15 min après le run mimo, 3x/jour.

Précision de routage : mimo-v2.5 passe en DIRECT par https://opencode.ai/zen/go/v1 (provider built-in opencode-go, clé OPENCODE_GO_API_KEY), et NON par Bifrost. Vérifié dans logs.db de Bifrost : zéro trafic mimo. Les deux modèles sont couverts par le même forfait OpenCode Go → coût marginal nul des deux côtés.

Données (logs agent.log 2026-07-01 → 08, fenêtre pilote 05→08/07)

Métrique (0508/07) mimo-v2.5 deepseek-v4-flash
Appels API 591 194
Latence médiane / moyenne 9,7 s / 14,1 s 10,5 s / 26,1 s
p90 / p99 27 s / 73 s 53 s / 206 s
Streams gelés (kill 180 s) 0 19 sur la semaine (8 le 05/07, 6 le 08/07)
Échecs d'appel 1 (APIConnectionError) 19 (18 ReadError/broken pipe)
Jobs cron perdus (3/3 retries) 0 2
Débit médian 22,3 tok/s 28,3 tok/s

Comparaison qualitative sur les 3 runs appariés du cron de comparaison :

  • 07/07 20h : les deux briefs complets et bons. V4 Flash même légèrement meilleur en vérification factuelle (a identifié la « Caveman Method », flaggé les claims non vérifiés). Qualité ≈ parité.
  • 08/07 07h : V4 Flash CRASHRuntimeError: Broken pipe après 3 tentatives, aucun brief livré. mimo : brief complet de 24 Ko.
  • 08/07 12h : V4 Flash a rendu un méta-résumé de 867 caractères au lieu du brief Telegram demandé (hors format). mimo : brief complet conforme.

Verdict : GARDER mimo-v2.5, V4 Flash en fallback uniquement

Le problème de V4 Flash n'est pas la qualité d'analyse (équivalente quand il aboutit) mais la fiabilité du streaming : streams qui gèlent 180 s puis meurent en broken pipe, y compris pendant la semaine du pilote, avec 2 jobs cron réellement perdus. mimo-v2.5 : latence de queue 3x meilleure (p99 73 s vs 206 s), zéro stream gelé, un seul incident (réponses vides le 05/07 21h47, rattrapé par le fallback). Pas de routage par type de tâche : rien dans les données ne le justifie, et ça complexifierait la config pour rien.

Config finale appliquée (2026-07-08)

  • data/config.yaml : model.default: mimo-v2.5 + max_tokens: 8192 (modèle reasoning, jamais < 2048) ; delegation.model: mimo-v2.5 (était deepseek-v4-flash) ; fallback 1 = opencode-go/deepseek-v4-flash ; fallback 2 = openrouter/deepseek/deepseek-v4-flash.
  • data/profiles/veilleur/config.yaml : default: mimo-v2.5, max_tokens: 8192 (était deepseek-v4-flash).
  • data/cron/jobs.json : cron veille-ia-nexum-compare-deepseek désactivé (test terminé). Le cron principal veille-ia-nexum-4ee61494 garde son override model: mimo-v2.5.
  • Backups : config.yaml.bak-20260708T-verdict, profiles/veilleur/config.yaml.bak-20260708T-verdict, cron/jobs.json.bak_20260708_verdict_mimo.
  • Appliqué par docker restart hermes-agent-nyora (healthy, profils default + veilleur re-registrés).

Ce qui NE marche PAS / pièges

  • Ouvrir logs.db de Bifrost depuis le Mac via SMB échoue (unable to open database file, WAL) → interroger via ssh nas 'sqlite3 -readonly /volume1/docker/bifrost/data/logs.db ...'.
  • Les erreurs Bifrost deepseek-v4-flash de la semaine sont surtout des 401 virtual_key_not_found (76, client sans VK — autre chantier) + 16 erreurs 500 upstream ; sans lien avec le pilote Hermes.
  • mimo-v2.5 peut rendre des réponses vides en rafale (1 épisode observé) : le gateway retry 3x puis bascule sur le fallback tout seul — surveiller Empty response dans agent.log si ça devient fréquent.

Surveillance post-verdict

Vérifier dans une semaine : grep -c 'Stream stale' data/logs/agent.log et le taux d'Empty response mimo. Si les réponses vides mimo dépassent ~1/jour, envisager le retour V4 Flash ou un nouveau pilote.