docs(hermes): rapport analyse 2026-06-04_23-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-04_23-30.md

@@ -0,0 +1,116 @@
+# Rapport Hermes — 2026-06-04_23-30
+> Branche : `hermes/daily-work` · Fichiers analysés : 5
+
+---
+## Résumé
+- ✅ À jour : 5
+- ⚠️  À améliorer : 0
+
+## ✅ `admin/ia/litellm.md` — 9/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète et structurée sur la configuration et l'utilisation de LiteLLM, avec des notes clés sur les modèles CPU manquants dans le template Ansible  
+
+**Problèmes :**
+- Le template Ansible litellm/config.yaml.j2 manque les modèles CPU qwen3-1.7b-system et qwen3-1.7b-monitor
+- Le script hermes-switch modifie manuellement le fichier de config sans synchronisation avec le template Ansible
+
+**Suggestions :**
+- Ajouter les modèles CPU dans le template Ansible pour une gestion IaC complète
+- Mettre à jour le script hermes-switch pour utiliser le template Ansible plutôt que des modifications manuelles
+- Ajouter des exemples d'utilisation des modèles CPU dans la documentation
+
+**État réel connu de Hermes :**  
+Les modèles CPU sont ajoutés manuellement dans /etc/litellm/config.yaml, ce qui crée un décalage avec le template Ansible. Un déploiement standard via make apply-storage ne provisionnerait pas ces modèles.
+
+---
+
+## ✅ `admin/ia/llama_server.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur la configuration des trois instances llama-server sur gpu-01, avec paramètres VRAM, API OpenAI, embeddings et métriques Prometheus.  
+
+**Problèmes :**
+- La mention du 'bug parallel' dans la section Performances est ambiguë et nécessite clarification
+- Le calcul VRAM (9GB) ne tient pas compte des overheads système potentiels
+- Aucune mention des restrictions de débit pour les requêtes concurrentes
+
+**Suggestions :**
+- Ajouter un tableau comparatif des métriques CPU/GPU
+- Inclure des exemples de monitoring à long terme (ex: journalctl rotation)
+- Mettre en évidence les prérequis ROCm 7.x spécifiques au RX 6700XT
+
+**État réel connu de Hermes :**  
+Les trois instances fonctionnent correctement avec des métriques exposées. Le modèle GPU utilise 9GB VRAM (avec 12GB disponibles), les embeddings sont activés et les métriques Prometheus sont accessibles via /metrics. Le problème de parallélisme nécessite validation expérimentale.
+
+---
+
+## ✅ `admin/ia/rag.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Documentation complète sur le RAG déployé dans Funk, incluant architecture, composants, modèles d'embedding et procédures d'indexation, mais avec des limitations connues dans la qualité des embeddings.  
+
+**Problèmes :**
+- Les embeddings générés par Qwen3-8B présentent une discrimination sémantique limitée (scores cosinus uniformément élevés)
+- Aucune procédure détaillée pour déployer des modèles d'embedding alternatifs (nomic-embed-text-v1.5, bge-m3)
+- Le processus manuel d'indexation nécessite des commandes ssh/rsync potentiellement fragiles
+- Aucune mention des retards d'ingestion (5-10 minutes pour 339 chunks)
+
+**Suggestions :**
+- Ajouter une section détaillant la migration vers des modèles d'embedding spécialisés (ex: nomic-embed-text-v1.5)
+- Inclure un exemple concret de script pour surveiller la fin de l'ingestion (via Ansible ou cron)
+- Mettre en avant les alternatives aux embeddings GPU (CPU avec pooling mean)
+- Ajouter un avertissement sur les risques de surcharge du GPU lors de l'ingestion massique
+
+**État réel connu de Hermes :**  
+Le système RAG est opérationnel mais subit des limitations connues dans la qualité des embeddings. L'indexation automatisée via Ansible fonctionne, mais les alternatives de modèles d'embedding restent à implémenter.
+
+---
+
+## ✅ `admin/ia/rocm.md` — 8/10
+
+**Statut** : à_jour  
+**Résumé** : Document complet sur la configuration ROCm pour RX 6700XT avec vérifications clés, mais manque de contexte technique et de mises à jour sur les outils modernes  
+
+**Problèmes :**
+- Aucune explication sur le pourquoi de HSA_OVERRIDE_GFX_VERSION=10.3.0
+- Commandes ssh g01 pourraient être obsolètes (nom de la machine ?)
+- Manque de vérification des pilotes AMD propriétaires
+- Pas de mention des erreurs courantes (ex: 'rocminfo: command not found')
+- Absence de conseils pour les utilisateurs non-root
+
+**Suggestions :**
+- Ajouter une section expliquant le besoin de HSA_OVERRIDE_GFX_VERSION
+- Mettre à jour les commandes pour utiliser le hostname actuel (gpu-01)
+- Inclure des vérifications pour les pilotes AMD propriétaires
+- Ajouter un exemple de sortie attendue pour rocminfo
+- Proposer des commandes pour vérifier les permissions sudo
+
+**État réel connu de Hermes :**  
+null
+
+---
+
+## ✅ `admin/incidents.md` — 7/10
+
+**Statut** : à_jour  
+**Résumé** : Document bien structuré avec historique des incidents et résolutions détaillées, mais présente quelques incohérences de format et de consistance.  
+
+**Problèmes :**
+- Incohérence entre la gravité 'Important' et 'Critique' pour l'incident du 2026-05-29
+- Tableau d'État post-migration incomplet (ligne 'Espace disponibl' tronquée)
+- Format markdown incohérent entre le tableau d'index et les sections détaillées
+- Absence de note sur les mesures préventives ou les leçons apprises
+
+**Suggestions :**
+- Standardiser les niveaux de gravité (Important/Critique/Warning) entre l'index et les sections détaillées
+- Compléter le tableau d'État post-migration avec les métriques d'espace disque
+- Ajouter une section 'Leçons apprises' ou 'Mesures préventives' pour chaque incident
+- Normaliser le format des tableaux (alignement des colonnes, syntaxe markdown)
+- Ajouter des notes explicatives pour les commandes critiques comme 'mdadm --manage'
+
+**État réel connu de Hermes :**  
+Le composant /srv/data a été migré vers le NVMe avec succès. Le RAID5 original est maintenant en mode dégradé. Les services sont opérationnels avec les configurations mises à jour.
+
+---
+