infra+garde-fou: fix routing vision text-only + protocole anti-hallucination benchmarks (27/07/2026)

This commit is contained in:
2026-07-27 15:15:03 +00:00
parent 5b54dafd88
commit e9050da161
4 changed files with 125 additions and 0 deletions
+4
View File
@@ -156,3 +156,7 @@
- [hermes-tt/mail-o365-recherche-scroll-virtualisation.md](hermes-tt/mail-o365-recherche-scroll-virtualisation.md) — liste OWA virtualisee limitee a 5-7 mails montes, fix par accumulation ArrowDown progressif (read_listbox_items), + endpoints /search* (recherche precise dans toute la boite), skill mail-o365-tt.md complete (24/07/2026) - [hermes-tt/mail-o365-recherche-scroll-virtualisation.md](hermes-tt/mail-o365-recherche-scroll-virtualisation.md) — liste OWA virtualisee limitee a 5-7 mails montes, fix par accumulation ArrowDown progressif (read_listbox_items), + endpoints /search* (recherche precise dans toute la boite), skill mail-o365-tt.md complete (24/07/2026)
- [hermes-nyora/iakifech-ep2-subtitle-desync-freeze-postmortem.md](hermes-nyora/iakifech-ep2-subtitle-desync-freeze-postmortem.md) — Sous-titres moneyprinterturbo calés sur edge-tts non regénérés apres swap voix ElevenLabs (desync ~0,57s), freeze+silence fin (body 75,57s vs voix 79,49s, ~18s ecart non explique), logo confirme present et correct (24/07/2026) - [hermes-nyora/iakifech-ep2-subtitle-desync-freeze-postmortem.md](hermes-nyora/iakifech-ep2-subtitle-desync-freeze-postmortem.md) — Sous-titres moneyprinterturbo calés sur edge-tts non regénérés apres swap voix ElevenLabs (desync ~0,57s), freeze+silence fin (body 75,57s vs voix 79,49s, ~18s ecart non explique), logo confirme present et correct (24/07/2026)
- [common/baserow-rotation-casse-containers-standalone.md](common/baserow-rotation-casse-containers-standalone.md) — Rotation mot de passe admin Baserow casse les containers standalone non supervises (JWT admin code en dur) ; fix = Database API Token statique par scope, cas dashboard-terrain corrige (25/07/2026) - [common/baserow-rotation-casse-containers-standalone.md](common/baserow-rotation-casse-containers-standalone.md) — Rotation mot de passe admin Baserow casse les containers standalone non supervises (JWT admin code en dur) ; fix = Database API Token statique par scope, cas dashboard-terrain corrige (25/07/2026)
- [common/vision-auxiliaire-routing-text-only-modeles.md](common/vision-auxiliaire-routing-text-only-modeles.md) -- auxiliary.vision `auto` casse sur modeles text-only (deepseek-v4-flash), route explicite vers google/gemini-2.5-flash via bifrost-proxy, applique hermes-perso + hermes-tt (27/07/2026)
- [common/anti-hallucination-benchmarks-recherche-chiffree.md](common/anti-hallucination-benchmarks-recherche-chiffree.md) -- Garde-fou anti-invention sur rapports chiffres : chiffre = page lue en entier ou "non verifie", verifier variante exacte du modele avant attribution (27/07/2026)
+9
View File
@@ -168,3 +168,12 @@ Une réponse "success" d'un outil de modification (update_workflow, edit de jobs
**Cause ici** : `/usr/lib/python3.8/site-packages` (`0700 root:root`) contenait une stack data-science/Streamlit complète (pandas, numpy, pyarrow, pillow, altair, jupyter) installée à la main début 2026 dans le Python système de base — pas un paquet Package Center, aucun process actif, aucun lien avec le stack actuel. Prototype abandonné. **Cause ici** : `/usr/lib/python3.8/site-packages` (`0700 root:root`) contenait une stack data-science/Streamlit complète (pandas, numpy, pyarrow, pillow, altair, jupyter) installée à la main début 2026 dans le Python système de base — pas un paquet Package Center, aucun process actif, aucun lien avec le stack actuel. Prototype abandonné.
**Fix** : `sudo rm -rf /usr/lib/python3.8/site-packages/* /usr/etc/jupyter /usr/share/jupyter` → 2,1 Go → 1,7 Go utilisés, 113 Mo → 529 Mo disponibles (95% → 77%). Diagnostic fait en lecture seule par Best0f (sans sudo), suppression exécutée par Nabil (le mot de passe sudo Best0f n'est jamais transmis à un agent). Runbook détaillé : common/partition-systeme-nas-du-vs-df-permissions.md. **Fix** : `sudo rm -rf /usr/lib/python3.8/site-packages/* /usr/etc/jupyter /usr/share/jupyter` → 2,1 Go → 1,7 Go utilisés, 113 Mo → 529 Mo disponibles (95% → 77%). Diagnostic fait en lecture seule par Best0f (sans sudo), suppression exécutée par Nabil (le mot de passe sudo Best0f n'est jamais transmis à un agent). Runbook détaillé : common/partition-systeme-nas-du-vs-df-permissions.md.
## REGLE CRITIQUE -- Anti-invention sur chiffres de recherche/benchmarks (2026-07-27)
Avant de presenter un chiffre (benchmark, prix, score) dans un rapport : le chiffre doit venir d'une page reellement lue en entier, pas d'un snippet de recherche. Si un fetch demande ne renvoie qu'une coquille vide (page JS, < 500 caracteres utiles) -> le dire explicitement, ne jamais compenser en silence par une recherche generique. Verifier le nom EXACT de la variante (Pro/Max/Flash/base) avant d'attribuer un chiffre -- deux benchmarks avec un score identique = signal d'hallucination a corriger avant envoi, jamais a ignorer. Detail complet : common/anti-hallucination-benchmarks-recherche-chiffree.md.
## FIX -- auxiliary.vision mal route sur modeles text-only (2026-07-27)
`auxiliary.vision.provider: auto` resout vers le modele principal -- casse systematiquement sur deepseek-v4-flash (text-only). Toute instance avec un modele principal text-only DOIT router `auxiliary.vision` explicitement vers `google/gemini-2.5-flash` via bifrost-proxy (meme base_url/api_key que le modele principal). Applique sur hermes-perso et hermes-tt le 27/07/2026. Detail : common/vision-auxiliaire-routing-text-only-modeles.md.
@@ -0,0 +1,53 @@
# Anti-invention sur rapports chiffres (benchmarks, comparatifs, recherche)
**Instance auteur** : Claude (diagnostic hermes-nabil, VPS Contabo)
**Date** : 2026-07-27
**Tags** : [recherche, hallucination, benchmarks, transverse, garde-fou]
**Statut** : valide
---
## Probleme
hermes-nabil a produit un comparatif chiffre MiMo-V2.5 vs DeepSeek V4 Flash presente avec une confiance totale, a la demande de Nabil qui envisageait de migrer les 3 instances Hermes vers mimo-v2.5 sur cette base. Plusieurs chiffres de benchmarks de code agentique (SWE-bench Pro, Terminal-Bench 2.0) etaient inventes -- DeepSeek V4 Flash affichait 49,1% identique sur deux benchmarks differents (signature classique d'hallucination), et les chiffres cites pour MiMo-V2.5 (base) correspondaient en realite a MiMo-V2.5-Pro, une variante differente.
## Contexte et contraintes
Retrace via /data/logs/agent.log sur le VPS :
1. hermes-nabil a fetche le lien OpenRouter demande -- mais la page se rend en JavaScript, le fetch n'a recupere que ~6500 caracteres de coquille vide (nav/footer), aucune donnee de benchmark.
2. Faute de donnee exploitable, il a lance 2 recherches web generiques (Tavily) et n'a fetche aucune page complete ensuite -- synthese faite uniquement sur des snippets de resultats de recherche.
3. Les requetes ne distinguaient pas explicitement base vs Pro -- les articles qui dominent le web sur ce sujet parlent presque tous de MiMo-V2.5-Pro, d'ou la confusion.
4. Le rapport final ne signalait a aucun moment cette incertitude -- presente comme une donnee croisee et fiable ("base sur la page OpenRouter + toutes les sources croisees").
## Ce qui NE fonctionne PAS
| Tentative | Erreur obtenue | Raison de l'echec |
|-----------|----------------|-------------------|
| Fetch direct d'une page de comparaison OpenRouter | Coquille vide (~6-7K car., JS-rendu) | Le contenu reel (tableau de benchmarks) est genere cote client, invisible a un fetch simple |
| Compenser par une recherche web generique sans fetch de page complete | Chiffres plausibles mais faux (mauvaise variante de modele) | Les snippets de recherche ne portent pas la precision necessaire pour distinguer les variantes (Pro/base/Max) |
| Faire confiance a un rapport chiffre sans verifier la source exacte par ligne | Migration complete envisagee sur base fausse | Aucun garde-fou empechant la presentation de chiffres non verifies comme des faits |
## Solution validee -- Regle a appliquer par toutes les instances
Pour toute affirmation chiffree (score, benchmark, prix, statistique) dans un rapport de comparaison ou de recherche :
1. Un chiffre n'est inclus que s'il provient d'une page reellement lue en entier (fetch reussi avec contenu substantiel -- pas un snippet de moteur de recherche). Si le fetch d'une URL demandee echoue ou ne renvoie qu'une coquille (page JS, mur d'auth, contenu utile < ~500 caracteres) -> le signaler explicitement a l'utilisateur au lieu de compenser silencieusement par une recherche generique.
2. Verifier le nom exact du modele/produit dans la source avant d'attribuer un chiffre -- ne jamais assumer qu'un chiffre trouve sous un nom voisin (ex. MiMo-V2.5-Pro) s'applique a la variante demandee (ex. MiMo-V2.5). Les suffixes (Pro, Max, Flash, Lite, Mini, Omni) changent la donnee.
3. Un chiffre non confirme par au moins une source citable et verifiable est marque "non verifie" plutot que presente comme un fait etabli -- jamais de silence sur l'incertitude.
4. Avant d'envoyer un tableau chiffre : relire chaque ligne et verifier qu'on peut citer la source exacte (URL) pour ce chiffre precis. Si non -> l'omettre ou le marquer explicitement.
5. Interdiction de compenser un manque de donnees par une inference plausible non signalee -- un tableau incomplet mais honnete vaut mieux qu'un tableau complet et faux.
## Verification
A la prochaine demande de comparatif chiffre (n'importe quelle instance) : verifier que chaque chiffre du rapport final est tracable a une page effectivement lue, et que les variantes de modele/produit sont nommees explicitement et verifiees.
## Pieges specifiques
- Une page qui se rend en JavaScript (SPA moderne : OpenRouter, la plupart des dashboards) ne donne jamais son contenu reel a un fetch simple -- le signaler plutot que d'improviser une compensation.
- Un ton de "confiance totale" n'est pas un signal de fiabilite -- c'est independant de si la donnee est verifiee.
- Deux benchmarks differents affichant exactement le meme score est un signal d'hallucination a ne jamais ignorer.
## References
- Incident declencheur : comparatif MiMo-V2.5 vs DeepSeek V4 Flash, hermes-nabil, 26/07/2026
- common/vision-auxiliaire-routing-text-only-modeles.md (fix connexe decouvert dans la meme investigation)
@@ -0,0 +1,59 @@
# Vision auxiliaire mal routee sur modeles text-only (auto -> echec silencieux)
**Instance auteur** : Claude (diagnostic multi-instance, hermes-perso + hermes-tt)
**Date** : 2026-07-27
**Tags** : [infra, vision, bifrost, config, transverse]
**Statut** : valide
---
## Probleme
`vision_analyze` echouait systematiquement sur hermes-perso (contexte : extraction guide d'orientation universitaire, screenshots de verification) avec une erreur `400 - Upstream request failed` (parfois 404 selon le provider), empechant toute verification visuelle avant livraison -- alors que cette verification est une regle etablie (post-incident IAKifech Ep2 : jamais de validation sur metriques seules).
## Contexte et contraintes
Config `auxiliary.vision.provider: auto` dans `config.yaml` de chaque instance Hermes. `auto` resout vers le modele principal configure pour l'instance (`model.default`). Sur hermes-perso et hermes-tt, ce modele principal est `deepseek-v4-flash` -- un modele **text-only** (confirme OpenRouter : Text-only, no vision/image input). Toute image envoyee a ce provider echoue par construction, pas par bug transitoire.
hermes-nyora et hermes-nabil tournent sur `mimo-v2.5`, natif omnimodal -- `auto` fonctionne correctement pour ces deux-la, ce qui a masque le probleme puisqu'il ne touchait que 2 instances sur 4.
## Ce qui NE fonctionne PAS
| Tentative | Erreur obtenue | Raison de l'echec |
|-----------|----------------|-------------------|
| Laisser `auto` par defaut | `400 Upstream request failed` / `404` sur toute image | `auto` pointe vers le modele principal, ici text-only |
| Ne rien configurer et esperer un fallback automatique | Meme erreur, aucun fallback vision dans la structure `auxiliary.vision` (pas de liste, contrairement a `fallback_providers` du modele principal) | La structure de config n'a qu'un seul provider/model pour vision, pas de chaine de fallback |
## Solution validee
Router explicitement `auxiliary.vision` vers un modele multimodal via Bifrost, avec les memes identifiants que le modele principal (meme base_url/api_key, provider custom) :
```yaml
auxiliary:
vision:
provider: custom
model: google/gemini-2.5-flash
base_url: http://bifrost-proxy/v1
api_key: bfk-0cd1fba7d440ca2eefd30b28a7349b7d28422dcbc49e982d
timeout: 120
download_timeout: 30
```
Applique sur `hermes-perso` et `hermes-tt` (fichiers `config.yaml`, backup `.bak-20260727` conserve a cote). Containers redemarres (`docker restart`) pour charger la nouvelle config -- `config.yaml` n'est lu qu'au demarrage, jamais a chaud (meme piege que `jobs.json`, cf. regle cron dans PROTOCOL-INFRA.md).
`hermes-nyora` et `hermes-nabil` laisses en `auto` : leur modele principal gere nativement la vision, pas de changement necessaire pour l'instant.
## Verification
Prochaine tache impliquant une image sur hermes-perso ou hermes-tt : confirmer dans les logs (`/opt/data/logs/errors.log` ou `agent.log`) que l'appel vision affiche `provider=custom` et `model=google/gemini-2.5-flash` dans `routing_info`, plus aucune trace de `deepseek-v4-flash` sur un appel vision.
## Pieges specifiques
- `config.yaml` n'est pas recharge a chaud -- toujours redemarrer le container apres modification, quel que soit le champ touche.
- Verifier ce meme champ sur toute future instance Hermes creee avec un modele principal text-only -- le defaut `auto` est un piege qui ne se revele qu'a l'usage (premier envoi d'image).
- Le Gemini utilise ici (`google/gemini-2.5-flash`) est deja configure comme provider dans `bifrost-proxy/models.json` -- pas de nouvelle cle a creer.
## References
- Incident declencheur : diagnostic hermes-perso, tache orientation universitaire Yesmine (27/07/2026)
- common/bifrost-vk-incidents.md, common/hermes-vers-bifrost-bifrost-proxy.md