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

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

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

**Statut** : à_jour  
**Résumé** : Documentation complète sur la configuration et l'utilisation de LiteLLM, avec des lacunes dans la gestion des modèles CPU via Ansible  

**Problèmes :**
- Le template Ansible manque les modèles CPU (qwen3-1.7b-system et qwen3-1.7b-monitor) nécessaires à ask-agent
- La colonne 'Coût' dans le tableau des modèles a un format incohérent (dash au lieu de chiffre)
- La phrase 'Utilisation courante' manque de précision
- Formatage des tableaux mal aligné
- L'absence de gestion des erreurs dans la validation API

**Suggestions :**
- Mettre à jour le template Ansible pour inclure les modèles CPU
- Corriger le formatage des tableaux et remplir les champs de coût
- Ajouter des exemples de gestion d'erreurs dans la validation API
- Préciser les instructions pour le déploiement des modèles CPU
- Ajouter une section dédiée aux problèmes courants et solutions

**État réel connu de Hermes :**  
Le service LiteLLM est opérationnel avec les modèles GPU, mais les modèles CPU ne sont pas déployés via Ansible. Le script hermes-switch permet le basculement manuel, mais cela représente un gap IaC.

---

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

**Statut** : ok  
**Résumé** : Documentation complète sur la configuration et les performances de llama-server sur gpu-01, avec des commandes de gestion et des métriques détaillées.  

**Problèmes :**
- La section des métriques Prometheus manque une explication sur la configuration requise du flag --metrics dans le service systemd
- Le calcul VRAM mentionné (~9GB) ne tient pas compte des autres processus en cours sur la carte graphique

**Suggestions :**
- Ajouter une vérification de la configuration des métriques Prometheus dans la section 'Service systemd'
- Mettre à jour la note sur l'utilisation VRAM avec des instructions pour mesurer la consommation réelle via nvidia-smi
- Ajouter un avertissement sur le bug de parallélisme mentionné dans la section des performances

**État réel connu de Hermes :**  
Le composant est correctement documenté, mais les métriques Prometheus nécessitent une configuration supplémentaire pour être activées. La gestion des ressources VRAM pourrait être améliorée avec des outils de surveillance.

---

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

**Statut** : à_jour  
**Résumé** : Documentation complète sur le RAG de Funk, expliquant l'architecture, les composants et les limitations actuelles du système.  

**Problèmes :**
- Utilisation d'un modèle génératif (Qwen3-8B) pour les embeddings, ce qui entraîne une perte de discrimination sémantique
- Scores de similarité cosinus uniformément élevés (0.90-0.95) indiquant une faible pertinence réelle des résultats
- Manque de détails sur l'état actuel de l'index et des performances réelles

**Suggestions :**
- Déployer un modèle d'embedding dédié comme nomic-embed-text-v1.5 ou bge-m3 pour améliorer la recherche sémantique
- Mettre à jour les instructions d'indexation avec des exemples concrets de retraitement de documents
- Ajouter des benchmarks de performance avant/après migration vers un modèle d'embedding dédié

**État réel connu de Hermes :**  
Le système utilise actuellement Qwen3-8B pour les embeddings via llama-server (port 1234). L'index est mis à jour via Ansible ou manuellement, mais les résultats de recherche souffrent de perte de pertinence en raison des limitations du modèle.

---

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

**Statut** : à_jour  
**Résumé** : Documentation complète sur la configuration ROCm pour RX 6700XT avec vérifications opérationnelles et commandes de debug  

**Problèmes :**
- Absence de mention des nouvelles versions ROCm disponibles (>=5.14.0-687.5.3.el9_8)
- Aucune indication sur la configuration des profils CUDA/ROCm pour les conteneurs
- Les commandes 'rocm-smi' ne sont pas disponibles sur gpu-01 (état documenté mais non expliqué)

**Suggestions :**
- Ajouter une section sur la vérification des pilotes ROCm avec 'rocminfo -v'
- Inclure des exemples de configurations pour les applications GPU (llama-server, Qwen3)
- Mettre en évidence les différences entre ROCm 5.14 et les versions antérieures
- Ajouter des conseils sur la surveillance à long terme (Prometheus/Grafana intégration)

**État réel connu de Hermes :**  
ROCm 5.14.0 installé, amdgpu module chargé, HSA_OVERRIDE_GFX_VERSION=10.3.0 actif, aucune erreur détectée dans les logs, configuration conforme aux spécifications RX 6700XT (gfx1031)

---

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

**Statut** : à_jour  
**Résumé** : Document d'historique des incidents complet et structuré avec résolutions détaillées, mais manque d'informations sur l'état post-résolution des composants  

**Problèmes :**
- La section 'État post-migration' est incomplète (manque l'état des autres composants)
- Certains incidents (AlertManager, nftables) ont des résolutions incomplètes
- Format des tables est incohérent entre l'index et les sections détaillées
- Aucune mention des mesures préventives ou corrections à long terme

**Suggestions :**
- Ajouter un tableau récapitulatif des états post-résolution pour chaque incident
- Compléter les résolutions avec des vérifications post-corrections (ex: tests, monitoring)
- Standardiser le format des tables avec des colonnes identiques pour chaque incident
- Inclure une section 'Prévention' pour chaque incident majeur

**État réel connu de Hermes :**  
Le système utilise désormais NVMe pour /srv/data, les composants critiques sont restaurés, mais des supervisions continues sont nécessaires pour éviter les récidives

---

