# Rapport Hermes — 2026-06-08_12-30
> Branche : `hermes/daily-work` · Fichiers analysés : 5

---
## Résumé
- ✅ À jour : 5
- ⚠️  À améliorer : 0

## ✅ `admin/ia/litellm.md` — 8/10

**Statut** : à_jour  
**Résumé** : Documentation complète sur la configuration et l'utilisation de LiteLLM comme proxy LLM unifié, avec des informations sur les modèles, les coûts et les configurations système.  

**Problèmes :**
- Le template Ansible manque les modèles CPU (qwen3-1.7b-system et qwen3-1.7b-monitor) nécessaires pour ask-agent
- Les configurations manuelles dans /etc/litellm/config.yaml créent un risque de désynchronisation avec les déploiements automatisés

**Suggestions :**
- Mettre à jour le template Ansible (config.yaml.j2) pour inclure tous les modèles listés dans le document
- Ajouter une note explicite sur la gestion des clés API sensibles (ANTHROPIC_API_KEY) dans le processus de déploiement
- Documenter les commandes hermes-switch dans le contexte des workflows d'automatisation

**État réel connu de Hermes :**  
Le service est opérationnel avec des configurations mixtes (Ansible + modifications manuelles). Les modèles CPU nécessaires à ask-agent sont actifs mais risquent de disparaître après un déploiement standard.

---

## ✅ `admin/ia/llama_server.md` — 8/10

**Statut** : à_jour  
**Résumé** : Document complet sur la configuration des trois instances llama-server sur gpu-01, incluant paramètres modèles, commandes d'administration, métriques et validation API.  

**Problèmes :**
- La section sur les contraintes VRAM mentionne un checkmark ✅ mais ne précise pas si ce seuil est actuellement respecté
- La référence au 'bug parallel' dans Hermes reste ambiguë sans contexte supplémentaire

**Suggestions :**
- Ajouter une section 'Dépannage' avec exemples de résolution des erreurs courantes
- Détaillez les différences configuratives entre les instances CPU (system/monitor)
- Mettre à jour la note sur le parallélisme avec une explication technique du bug

**État réel connu de Hermes :**  
Les instances sont configurées comme décrit, mais la vérification des métriques en temps réel requiert l'inspection des services actifs sur gpu-01

---

## ✅ `admin/ia/rag.md` — 8/10

**Statut** : à_jour  
**Résumé** : Document complet sur l'implémentation RAG de Funk, avec architecture, composants, limitations et procédures de mise à jour.  

**Problèmes :**
- La limitation du modèle Qwen3-8B est mentionnée mais pas résolue : scores de similarité uniformément hauts et tri par pertinence insuffisant
- Les alternatives d'embedding (nomic-embed-text-v1.5, bge-m3) sont suggérées mais sans détails sur leur déploiement complet

**Suggestions :**
- Ajouter une section détaillant la migration vers des modèles d'embedding dédiés avec exemples de configuration complète
- Proposer un script exemple pour vérifier la qualité des embeddings post-indexation
- Mettre en avant les indicateurs de performance à surveiller après re-indexage

**État réel connu de Hermes :**  
Le système RAG est opérationnel avec index de 339 chunks, mais les résultats de recherche souffrent de limitation sémantique liée au modèle Qwen3-8B. La re-indexation fonctionne via Ansible et commande manuelle, mais les améliorations d'embedding restent à implémenter.

---

## ✅ `admin/ia/rocm.md` — 9/10

**Statut** : à_jour  
**Résumé** : Le document ROCm.md est à jour et couvre les vérifications essentielles pour la configuration ROCm sur RX 6700XT, avec des commandes clés et un état opérationnel vérifié le 2026-06-05  

**Problèmes :**
- Manque d'explications contextuelles sur le besoin de HSA_OVERRIDE_GFX_VERSION
- Les commandes de débogage pourraient inclure des descriptions des métriques mesurées

**Suggestions :**
- Ajouter une section expliquant pourquoi HSA_OVERRIDE_GFX_VERSION est nécessaire pour la RX 6700XT
- Compléter les commandes de débogage avec des légendes pour les métriques (ex: gpu_busy_percent, temp1_input)
- Mettre en évidence les commandes critiques dans un tableau

**État réel connu de Hermes :**  
ROCm fonctionne conformément à la documentation : noyau 5.14.0, rocm-smi non disponible (comportement attendu), aucun pod crashé, NFS export fonctionnel, utilisateur ansible dans les groupes video/render

---

## ✅ `admin/incidents.md` — 8/10

**Statut** : à_jour  
**Résumé** : Document complet et structuré avec historique des incidents et résolutions détaillées, mais présente quelques problèmes de format et de clarté.  

**Problèmes :**
- Tableau 'État post-migration' incomplet (ligne 'Espace disponibl' tronquée)
- Terme 'SMART passe' probablement un typo (devrait être 'SMART passed')
- Manque d'explications pour certains paramètres rsync (-aHX --info=progress2)
- Niveaux de sévérité non standardisés (« Important », « Critique », « Warning »)

**Suggestions :**
- Compléter le tableau 'État post-migration' avec les données manquantes
- Standardiser les niveaux de sévérité (ex: Critique/High, Important/Medium, Warning/Low)
- Ajouter une légende pour les acronymes techniques (RAID5, NVMe, XFS)
- Préciser les impacts des erreurs SMART sur la fiabilité des disques
- Ajouter une section « Prévention » pour les incidents récurrents

**État réel connu de Hermes :**  
Le système a successfully migré /srv/data vers NVMe sans perte de données, mais les disques RAID5 restent sous surveillance en raison de défaillances antérieures.

---