Root cause des 24 tool_calls casses sur hermes-nyora : le prompt du job veille ordonnait l'anti-pattern

Instance auteur : Claude Date : 2026-07-27 Tags : [infra, veille, mimo-v2.5, prompt-cron, transverse] Statut : valide

Probleme

24 occurrences de Unrepairable tool_call arguments for terminal — replaced with empty object sur hermes-agent-nyora en 12 jours de logs, systematiquement sur l'ecriture de /opt/data/veille_enrich.json ou /tmp/veille_telegram.md, et systematiquement aux horaires du cron veille (6h/11h/19h UTC). Diagnostic initial (attribue a tort a mimo-v2.5) : voir note du 27/07 sur les benchmarks/fiabilite mimo.

Contexte et contraintes (cause racine reelle)

Le mecanisme de reparation JSON (agent/message_sanitization.py) tente de requilibrer les accolades/crochets manquants, mais echoue quand la coupure tombe en plein milieu d'une chaine de texte (ex: "resu coupe au milieu du mot "resume") -- ce n'est pas un JSON mal forme reparable, c'est une generation tronquee avant la fin. Cause = troncature de sortie, meme famille que le probleme deja documente dans common/generation-chunkee-taches-volumineuses.md (02/07/2026, DeepSeek V4 Flash, hermes-perso).

Le vrai coupable : le prompt du job cron veille-ia-nexum-4ee61494 (jobs.json) instruisait explicitement d'ecrire jusqu'a 20 opportunites, chacune avec des champs "why" et "angle" explicitement sans limite de longueur ("aussi longue que necessaire, pas de limite artificielle"), le tout en UN SEUL heredoc terminal(). C'est l'exact anti-pattern que le skill generation-contenu-volumineux (deja deploye sur les 3 instances depuis le 02/07) est cense empecher -- mais une instruction explicite et precise dans un prompt de tache prime sur un reflexe de skill generique, quel que soit le modele. Le probleme n'etait donc pas une fiabilite intrinseque de mimo-v2.5, mais un conflit entre une regle generale (skill) et une instruction specifique plus forte (prompt du job) qui n'avait jamais ete alignee dessus.

Ce qui NE fonctionne PAS

Tentative	Erreur / limite	Raison
Compter sur le skill generation-contenu-volumineux seul pour corriger le comportement	Echec persistant (24 incidents sur 12 jours)	Une instruction explicite et precise ("utilise un heredoc pour tout ecrire") dans le prompt de la tache prime sur la regle generale du skill
Attribuer le probleme a la fiabilite de mimo-v2.5 et chercher a changer de modele	Aurait masque la vraie cause	N'importe quel modele finit par tronquer 20 analyses detaillees sans limite dans un seul appel -- ce n'est pas specifique a mimo

Solution validee

Prompt du job veille-ia-nexum-4ee61494 (jobs.json de hermes-nyora) modifie : l'etape d'ecriture de veille_enrich.json passe d'un heredoc unique a une construction chunkee explicite --

Un fichier temporaire distinct par opportunite (/tmp/veille_item_NN.json, NN = 01 a 20), un heredoc terminal() separe par item.
Assemblage des fichiers en un seul array JSON via UNE commande Python (json.load par fichier trie, json.dump final) -- jamais un nouvel appel LLM pour la fusion.
Verification du nombre d'objets avant de continuer, puis nettoyage des fichiers temporaires.
Suite du job (ingestion, verification INGEST_OK) inchangee.

Backup de jobs.json avant modif : cron/jobs.json.bak-20260727-1713. Container hermes-agent-nyora redemarre, next_run_at recalcule correctement (19h00 UTC le jour meme) sans intervention manuelle.

Verification

Prochain run reel (19h00 UTC, 27/07) : confirmer dans /opt/data/logs/errors.log l'absence de nouvelle occurrence de Unrepairable tool_call arguments sur ce job, et que veille_enrich.json contient bien autant d'objets que d'opportunites retenues.

References

common/generation-chunkee-taches-volumineuses.md (regle generale dont le prompt du job s'ecartait)
common/veille-nexum-rich-job-20-sources.md (bascule vers la veille riche 20 sources, contexte de l'augmentation de volume)
Note memoire 27/07 : diagnostic initial (a tort) attribue a la fiabilite de mimo-v2.5

4.1 KiB Raw Blame History