Analysés : litellm.md, llama_server.md, rag.md, rocm.md, incidents.md À améliorer : 0/5 Co-Authored-By: Hermes <hermes@funk.lab>
5.1 KiB
Rapport Hermes — 2026-06-06_19-00
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 détails sur les modèles, coûts et scripts de gestion, mais avec un gap IaC noté.
Problèmes :
- Le template Ansible n'inclut pas les modèles CPU (qwen3-1.7b-system et qwen3-1.7b-monitor) nécessaires aux agents ask-agent
- Le coût des modèles Claude est présenté sous forme de tableau mal formaté
Suggestions :
- Mettre à jour le template Ansible pour inclure les modèles CPU manquants
- Réorganiser le tableau des coûts Claude pour une présentation plus claire
- Ajouter des exemples de requêtes API plus complets pour les modèles Claude
État réel connu de Hermes :
Le service LiteLLM est opérationnel sur storage-01 avec les modèles GPU configurés, mais les modèles CPU sont manuellement ajoutés dans /etc/litellm/config.yaml et ne seront pas déployés via Ansible sur de nouveaux hôtes
✅ admin/ia/llama_server.md — 8/10
Statut : à_jour
Résumé : Document complet sur la configuration et l'utilisation de llama-server sur gpu-01, incluant les trois instances systemd, les métriques Prometheus et les tests API.
Problèmes :
- Manque de section sur la sécurité (firewall, accès API)
- Les métriques Prometheus ne détaillent pas leurs significations
- Aucune mention des dépendances logicielles requises
Suggestions :
- Ajouter une section sur la configuration du firewall pour les ports 1234/1236/1237
- Expliciter les unités des métriques (tok/s, tokens, etc.)
- Inclure la commande pour vérifier les dépendances (ex:
ldd /usr/local/bin/llama-server)
État réel connu de Hermes :
llama-server fonctionne avec les configurations décrites, mais les métriques Prometheus nécessitent une documentation plus détaillée pour une utilisation effective.
✅ admin/ia/rag.md — 7/10
Statut : à_jour
Résumé : Document détaillé sur l'implémentation RAG dans Funk, expliquant l'architecture, les composants et les procédures d'utilisation
Problèmes :
- Utilisation du modèle Qwen3-8B (génératif) pour les embeddings, ce qui présente des limites de discrimination sémantique
- Scores de similarité cosinus uniformément élevés (0.90-0.95) indiquant une pertinence non triée
- Aucune mention des mécanismes de retraitement des embeddings en cas de mise à jour de la documentation
Suggestions :
- Intégrer un modèle d'embedding dédié comme nomic-embed-text-v1.5 ou bge-m3 pour améliorer la précision sémantique
- Ajouter un paragraphe sur la procédure de retraitement des embeddings lors de modifications de la documentation
- Mettre en avant les alternatives techniques pour les utilisateurs souhaitant optimiser les résultats
État réel connu de Hermes :
Le système RAG est actif sur storage-01 avec Qdrant et rag-query, mais les embeddings utilisent un modèle génératif non optimisé pour la recherche vectorielle
✅ admin/ia/rocm.md — 8/10
Statut : à_jour
Résumé : Document complet et structuré sur la configuration ROCm pour RX 6700XT, avec vérifications opérationnelles et commandes de diagnostic clés.
Problèmes :
- Manque d'explications sur l'absence de 'rocm-smi' sur gpu-01
- Commande 'grep HSA' dans /etc/environment pourrait être plus précise (ajouter 'HSA_OVERRIDE')
- Aucune mention des mises à jour ROCm/kernel ou des alternatives si HSA_OVERRIDE échoue
Suggestions :
- Ajouter une section sur les alternatives à HSA_OVERRIDE si la variable échoue
- Mettre en évidence les risques de ne pas avoir 'rocm-smi' disponible
- Ajouter des exemples de sortie attendue pour les commandes clés
- Inclure une note sur la vérification des dépendances RPM/dependencies
État réel connu de Hermes :
ROCm fonctionne avec HSA_OVERRIDE=10.3.0, noyau 5.14.0, aucun crash détecté, accès GPU correct pour 'ansible', ROCm-smi non disponible mais pas critique pour les opérations actuelles
✅ admin/incidents.md — 7/10
Statut : à_jour
Résumé : Document d'historique des incidents bien structuré avec résolutions détaillées, mais manque de prévention future et de complétion des tableaux
Problèmes :
- Tableau 'État post-migration' incomplet (ligne coupée prématurément)
- Aucune mention des mesures préventives ou des leçons apprises
- Absence de classification des incidents par catégories (matériel/logiciel/sécurité)
Suggestions :
- Compléter le tableau d'état post-migration
- Ajouter une section 'Prévention' pour chaque incident
- Structurer les incidents par catégories avec badges visuels
- Ajouter un index chronologique des incidents clés
État réel connu de Hermes :
Le composant /srv/data a été migré vers NVMe avec succès, les données sont maintenant stockées sur un LV XFS stable. Le RAID5 dégradé a été désactivé et les services sont opérationnels.