docs(hermes): rapport analyse 2026-06-09_07-30 — 5 fichiers

Analysés : litellm.md, llama_server.md, rag.md, rocm.md, incidents.md
À améliorer : 0/5

Co-Authored-By: Hermes <hermes@funk.lab>

admin/hermes/builtin/2026-06-09_07-30.md

@@ -0,0 +1,108 @@
+# Rapport Hermes — 2026-06-09_07-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 avec des modèles locaux et cloud, mais avec des incohérences de mise en forme et des lacunes dans la gestion IaC.  
+
+**Problèmes :**
+- La table des coûts Claude contient des caractères `$` non échappés
+- Le modèle `qwen3-1.7b-system`/`:1236` et `qwen3-1.7b-monitor`/`:1237` sont manuellement ajoutés dans `/etc/litellm/config.yaml` alors que le template Ansible ne les inclut pas
+- La section 'Switch rapide avec hermes-switch' manque d'explication sur les effets secondaires des modifications de config.yaml
+- La mention des modèles CPU dans le flux de routing est redondante avec la section des modèles disponibles
+
+**Suggestions :**
+- Corriger la mise en forme de la table des coûts Claude avec des backticks pour les prix
+- Ajouter des remarques dans le template Ansible pour expliquer l'ajout manuel des modèles CPU
+- Ajouter une note de sécurité sur les risques des modifications directes de config.yaml
+- Mettre en évidence les différences entre les modèles CPU/GPU dans la section des modèles disponibles
+
+**État réel connu de Hermes :**  
+Les modèles CPU sont fonctionnels via des ajouts manuels, mais les nouveaux nœuds déployés via Ansible manquent de ces configurations, créant une incohérence entre les serveurs
+
+---
+
+## ✅ `admin/ia/llama_server.md` — 9/10
+
+**Statut** : ok  
+**Résumé** : Documentation complète sur la configuration et les performances du llama-server sur gpu-01, avec des instructions opérationnelles et des métriques détaillées.  
+
+**Problèmes :**
+- La mention du 'bug parallel' reste vague sans détails supplémentaires
+- Le calcul VRAM ne montre pas de marges de sécurité pour des mises à jour de modèle
+
+**Suggestions :**
+- Ajouter des étapes de vérification des dépendances ROCm
+- Mettre à jour les exemples de test avec des payloads plus représentatifs
+- Inclure des notes sur la gestion des erreurs courantes (ex: débordement de VRAM)
+
+**État réel connu de Hermes :**  
+Le composant est actif avec des métriques cohérentes. Le modèle Qwen3-8B occupe ~9GB VRAM sans surcharge, les services systemd répondent correctement aux requêtes API.
+
+---
+
+## ✅ `admin/ia/rag.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète du système RAG avec architecture, composants, modèles et procédures de mise à jour, mais avec des limites connues dans l'embedding sémantique.  
+
+**Problèmes :**
+- Utilisation du modèle Qwen3-8B (génératif) pour les embeddings, ce qui entraîne une perte de discrimination sémantique
+- Résultats de recherche non triés par pertinence réelle en raison de la uniformité des scores cosinus (0.90-0.95)
+- Aucune mention des risques de surchargement des embeddings via le fichier incidents.md
+
+**Suggestions :**
+- Migrer vers un modèle d'embedding dédié comme nomic-embed-text-v1.5 ou bge-m3
+- Ajouter un filtre de longueur/max_tokens dans rag-ingest pour éviter les surchargeurs
+- Implémenter un système de pondération dynamique des scores cosinus
+
+**État réel connu de Hermes :**  
+Système RAG opérationnel avec index de 339 chunks, mais nécessite une migration vers des modèles d'embedding spécialisés pour améliorer la recherche sémantique
+
+---
+
+## ✅ `admin/ia/rocm.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Le document ROCm.md est complet et structuré, couvrant les vérifications de base, les variables d'environnement, les modules kernel, les dépôts AMD et les étapes de débogage. L'état actuel du composant est conforme sans divergences détectées.  
+
+**Problèmes :**
+- Manque de vérification des versions spécifiques de ROCm et du noyau
+- Aucune mention des erreurs potentielles lors de la configuration des groupes utilisateur
+- Absence de conseils pour gérer les cas d'erreur lors des tests OpenCL
+
+**Suggestions :**
+- Ajouter une vérification des versions ROCm et du noyau pour garantir la compatibilité
+- Inclure des exemples de messages d'erreur courants lors de la configuration des groupes utilisateur
+- Ajouter des étapes de débogage pour les cas où clinfo ou rocminfo retourne des erreurs
+
+**État réel connu de Hermes :**  
+ROCm est correctement configuré sur gpu-01 avec HSA_OVERRIDE_GFX_VERSION=10.3.0. Le noyau 5.14.0-687.5.3.el9_8.x86_64 est compatible. Aucun crash de pod signalé, NFS export fonctionnel, configuration ROCm conforme.
+
+---
+
+## ✅ `admin/incidents.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document d'historique des incidents complet et bien structuré, avec résolutions détaillées pour les incidents critiques.  
+
+**Problèmes :**
+- La section 'État post-migration' est incomplète (l'espace disponible n'est pas quantifié)
+- Manque une conclusion synthétique sur les leçons apprises ou mesures préventives
+
+**Suggestions :**
+- Ajouter la capacité disque disponible post-migration dans la section 'État post-migration'
+- Inclure une section 'Mémoires' avec les mesures préventives dérivées des incidents
+- Ajouter des badges visuels pour les niveaux de sévérité (✅/⚠️/❌)
+
+**État réel connu de Hermes :**  
+Migration RAID5 → NVMe réussie, mais la quantification de l'espace disque disponible reste à compléter
+
+---
+