Oui, c'est possible, mais il y a une information importante à prendre en compte : le contexte.
C'est la fenêtre sur laquelle le LLM peut travailler (historique, longueur du prompt, ce qu'on passe en paramètre...).
Cette fenêtre est glissante, ce qui signifie que le LLM ne se souvient pas de ce qu'il y avait avant lorsque le contexte est trop grand.
Llama3, toutes les versions, c'est 8k tokens (8192 tokens).
Mixtral 8x7b, c'est 32k tokens
Mixtral 8x22b, c'est 68k tokens.
On peut augmenter la fenêtre de contexte avec le fine-tuning, mais plus la fenêtre de contexte est grande, plus le modèle a besoin de RAM pour travailler. Donc, le contexte est un compromis.
Le problème du fichier de log, c'est sa taille : si il est trop gros, il ne se souviendra pas du début et notamment des instructions qui sont passées. Il faudra donc faire régulièrement un log-rotate, ou nettoyer en enlevant ce qui n'est pas pertinent, ou prendre les 20 dernières lignes, par exemple, et envoyer régulièrement le bout de log au LLM.
Ensuite, il suffit de le prompter, genre : Tu es un spécialiste de l'analyse de log sous Linux, les logs n'ont aucun secret pour toi. Dans le contexte, il y a le log, fais-moi une analyse et remonte-moi si tu vois un problème pour l'exploitation de la machine.
J'ai fait l'exercice sur une de mes machines, ce n'est pas très pertinent ; je met sa réponse ci-dessous. Je préfère la supervision qui fait mieux le boulot.
Réponse du LLM (Mixtral 8x7b)
Ce journal semble provenir d'un serveur de messagerie Postfix qui traite et livre des messages électroniques. Voici ce que je peux déduire des entrées de journal fournies :
La première entrée montre qu'un message électronique avec l'ID 45BC8325AF2 a été reçu par postfix/cleanup pour livraison. Il fait 821 octets et est adressé à backupemail@docker-media.localdomain.
La deuxième entrée indique que le message a été accepté dans la file d'attente Postfix (nrcpt=1) avec l'état "file active".
Dans la troisième entrée, postfix/local tente de livrer localement mais échoue en raison d'une erreur lors de l'écriture dans le fichier du répertoire de messagerie pour l'utilisateur backupemail : "cannot update mailbox /var/mail/backupemail for user backupemail. error writing message: File too large" (dsn=5.2.2).
La quatrième entrée montre que la notification d'erreur de livraison a été générée avec l'ID 4B9B9325AF3, qui est envoyé à l'expéditeur d'origine du message bounce. Cela fait partie des pratiques standard de Postfix lorsqu'un e-mail ne peut pas être livré avec succès.
Dans les cinquième et sixième entrées, postfix/qmgr supprime les deux messages (IDs 45BC8325AF2 et 4B9B9325AF3) de la file d'attente après leur traitement.
Le journal montre également des activités planifiées par cron à 14:23:01, 15:23:01 et 15:30:01 (CRON[xxxxx]). Il semble qu'un script situé dans /opt/IMAPbackup soit exécuté par l'utilisateur backupemail.
La dernière entrée montre une erreur de dockerd liée à l'impossibilité de fermer stdin pour le processus d74bc6b1b294b33c4ae7df99ac9c3f0b852ad64e9545c566f564f1fa10b752b0. Ce message d'erreur n'est pas lié aux entrées de journal Postfix et peut être un problème distinct qui doit être enquêté séparément.
En résumé, il semble qu'il y ait eu un e-mail adressé à backupemail@docker-media.localdomain qui n'a pas pu être livré en raison d'une limitation de taille du fichier sur /var/mail/backupemail. Le serveur de messagerie a généré une notification d'erreur et supprimé les deux messages de la file d'attente. De plus, certaines tâches planifiées ont été exécutées par l'utilisateur backupemail à 15:30:01, mais elles ne semblent pas avoir causé de problèmes avec la livraison Postfix.
[^] # Re: L'apprentissage des logs ?
Posté par Ecran Plat (site web personnel) . En réponse au journal LLM auto-hébergés ou non : mon expérience. Évalué à 2.
Oui, c'est possible, mais il y a une information importante à prendre en compte : le contexte.
C'est la fenêtre sur laquelle le LLM peut travailler (historique, longueur du prompt, ce qu'on passe en paramètre...).
Cette fenêtre est glissante, ce qui signifie que le LLM ne se souvient pas de ce qu'il y avait avant lorsque le contexte est trop grand.
On peut augmenter la fenêtre de contexte avec le fine-tuning, mais plus la fenêtre de contexte est grande, plus le modèle a besoin de RAM pour travailler. Donc, le contexte est un compromis.
Le problème du fichier de log, c'est sa taille : si il est trop gros, il ne se souviendra pas du début et notamment des instructions qui sont passées. Il faudra donc faire régulièrement un log-rotate, ou nettoyer en enlevant ce qui n'est pas pertinent, ou prendre les 20 dernières lignes, par exemple, et envoyer régulièrement le bout de log au LLM.
Ensuite, il suffit de le prompter, genre : Tu es un spécialiste de l'analyse de log sous Linux, les logs n'ont aucun secret pour toi. Dans le contexte, il y a le log, fais-moi une analyse et remonte-moi si tu vois un problème pour l'exploitation de la machine.
J'ai fait l'exercice sur une de mes machines, ce n'est pas très pertinent ; je met sa réponse ci-dessous. Je préfère la supervision qui fait mieux le boulot.
Réponse du LLM (Mixtral 8x7b)
Ce journal semble provenir d'un serveur de messagerie Postfix qui traite et livre des messages électroniques. Voici ce que je peux déduire des entrées de journal fournies :
En résumé, il semble qu'il y ait eu un e-mail adressé à backupemail@docker-media.localdomain qui n'a pas pu être livré en raison d'une limitation de taille du fichier sur /var/mail/backupemail. Le serveur de messagerie a généré une notification d'erreur et supprimé les deux messages de la file d'attente. De plus, certaines tâches planifiées ont été exécutées par l'utilisateur backupemail à 15:30:01, mais elles ne semblent pas avoir causé de problèmes avec la livraison Postfix.