docs(hermes): rapport analyse 2026-06-06_22-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>
This commit is contained in:
Hermes Bot 2026-06-06 22:33:01 +02:00
parent 4c4f3cce84
commit 1b8bcbeb1a

View file

@ -0,0 +1,107 @@
# Rapport Hermes — 2026-06-06_22-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 informations sur les modèles, coûts et gaps IaC, mais nécessite des mises à jour sur les templates Ansible.
**Problèmes :**
- Le template Ansible ne comprend pas les modèles CPU (qwen3-1.7b-system et qwen3-1.7b-monitor) nécessaires pour ask-agent
- La table des coûts Claude présente des incohérences de format (caractères étranges)
- Manque de détails sur la gestion des clés API et la sécurité des configurations
**Suggestions :**
- Mettre à jour le template Ansible pour inclure les modèles CPU manuellement ajoutés
- Corriger le format de la table des coûts Claude
- Ajouter une section sur la sécurisation des clés API et les bonnes pratiques de gestion
- Documenter les étapes pour déployer les modèles CPU via le script hermes-switch
**État réel connu de Hermes :**
Le service LiteLLM fonctionne correctement avec les modèles GPU, mais les modèles CPU sont ajoutés manuellement. Le template Ansible reste incomplet et pourrait causer des erreurs de déploiement sans les ajustements nécessaires.
---
## ✅ `admin/ia/llama_server.md` — 9/10
**Statut** : à_jour
**Résumé** : Documentation complète sur la configuration et les performances des instances llama-server sur gpu-01, avec des tests API et des métriques Prometheus.
**Problèmes :**
- La description des métriques Prometheus est incomplète (phrase coupée au milieu)
- Aucune mention des dépendances logicielles requises (ex: ROCm 7.x, llama.cpp)
**Suggestions :**
- Ajouter une section sur la configuration des dépendances logicielles
- Compléter la description des métriques Prometheus
- Ajouter un avertissement sur la gestion de la VRAM (9GB utilisés sur 12GB)
**État réel connu de Hermes :**
Les instances sont opérationnelles avec des performances conformes aux spécifications. Les métriques Prometheus sont disponibles grâce au flag --metrics, mais la documentation reste incomplète sur certains aspects.
---
## ✅ `admin/ia/rag.md` — 7/10
**Statut** : à_jour
**Résumé** : Documentation complète sur le système RAG de Funk, expliquant l'architecture, les composants, les modèles d'embedding et les procédures de mise à jour. Contient des limitations connues et des suggestions d'amélioration.
**Problèmes :**
- Les étapes de déploiement des modèles alternatifs (nomic-embed-text-v1.5, bge-m3) manquent de détails pratiques pour la configuration complète
- Le processus manuel de mise à jour nécessite des commandes ssh/rsync qui peuvent être source d'erreurs
- La limitation du modèle Qwen3-8B est documentée, mais pas de comparaison quantitative avec des modèles dédiés
**Suggestions :**
- Ajouter un exemple concret de déploiement du modèle nomic-embed-text-v1.5 avec les paramètres exacts
- Proposer un script automatisé pour la synchronisation et l'ingestion manuelle
- Inclure un tableau comparatif des performances entre les modèles d'embedding
- Mettre en avant les risques liés à l'utilisation d'un modèle génératif pour les embeddings
**État réel connu de Hermes :**
Le système RAG est opérationnel avec la collection funk-docs (339 chunks), mais les résultats de recherche souffrent de perte de pertinence en raison des limites du modèle Qwen3-8B. La procédure ansible est fonctionnelle mais la documentation des alternatives reste incomplète.
---
## ✅ `admin/ia/rocm.md` — 9/10
**Statut** : à_jour
**Résumé** : Le document ROCm.md est complet et à jour, couvrant les vérifications clés pour le setup ROCm sur RX 6700XT avec des commandes opérationnelles et des conseils précis.
**Problèmes :**
- Manque une vérification explicite de la version ROCm installée via 'rocminfo' dans les tests de base
**Suggestions :**
- Ajouter une section sur la validation des pilotes ROCm avec 'rocminfo | grep 'ROCk''
- Mettre en évidence les commandes critiques dans un tableau pour rapidité d'accès
- Ajouter un rappel sur la nécessité de 'HSA_OVERRIDE_GFX_VERSION=10.3.0' dans les scripts d'automatisation
**État réel connu de Hermes :**
ROCm configuré correctement avec noyau 5.14.0, variables d'environnement correctes, modules amdgpu chargés, aucun incident signalé
---
## ✅ `admin/incidents.md` — 8/10
**Statut** : à_jour
**Résumé** : Document bien structuré avec résolution détaillée pour l'incident de migration, mais présentant des incohérences de formatage et des lacunes d'information pour d'autres incidents.
**Problèmes :**
- Ligne de séparation du tableau d'index avec un pipe supplémentaire
- Manque de détails sur les résolutions pour les incidents antérieurs (2026-05-27, 2026-05-14, etc.)
- Incohérence dans la catégorisation des niveaux de sévérité (ex: 'Critique' vs 'Important')
**Suggestions :**
- Corriger le formatage du tableau d'index
- Ajouter des sections détaillées pour les autres incidents mentionnés dans l'index
- Standardiser les niveaux de sévérité avec des termes cohérents (ex: 'Critique', 'Majeur', 'Moyen', 'Mineur')
**État réel connu de Hermes :**
Le composant /srv/data a été migré vers un LV NVMe (XFS) après résolution des erreurs RAID, avec des mesures de prévention contre les erreurs d'interface SATA
---