Un RAG sur votre propre journal : ne jamais résoudre deux fois le même problème
Les problèmes les plus coûteux d'un homelab sont ceux qu'on résout deux fois : vous l'avez réparé en septembre, oublié comment, et passez octobre à le redécouvrir. Un journal règle ça seulement si l'on peut y retrouver les choses. Un RAG (génération augmentée par la recherche) le fait : il retrouve les passages de vos notes les plus proches d'une question, et vous les donne, à vous ou à un agent, avant que quiconque devine.
Un peu d'histoire
La génération augmentée par la recherche (RAG) a été nommée dans un article de 2020 de Facebook AI Research : au lieu d'espérer qu'un modèle se souvienne d'un fait, le chercher dans vos propres documents et donner les passages au modèle avec la question. Un modèle sait ce qu'il a lu pendant son entraînement ; le RAG lui permet de répondre à partir de ce que vous avez écrit hier.
1. L'écrire
Un fichier Markdown par jour, une section par problème : le symptôme, la cause, la réparation, et le piège. Écrivez-le au moment où c'est résolu ; demain, vous aurez oublié le détail qui comptait. Notre règle : un diagnostic qui n'est pas écrit sera payé deux fois.
2. L'indexer automatiquement
Un petit service découpe les notes en morceaux, transforme chaque morceau en vecteur avec un petit modèle d'embedding (le nôtre : e5-small, qui tourne sur un processeur), et répond aux questions avec les morceaux les plus proches. Une unité systemd .path surveille le dossier du journal et réindexe quand un fichier change, environ 70 secondes par passe sur notre petite VM.
3. L'interroger d'abord
Donnez à vos agents un outil qui l'interroge, et faites-en une règle : avant de diagnostiquer quoi que ce soit dans le homelab, on demande au journal. Fermez la route de recherche par un jeton (dans un en-tête, pas dans l'URL) ; laissez le contrôle de santé public, une sonde ne devrait pas avoir besoin d'un secret.
Pièges que nous avons payés
La taille des morceaux. Notre modèle d'embedding lit 512 jetons, environ 1 400 caractères de français. Nos premiers morceaux étaient des sections entières, certaines de 7 000 caractères : seul leur début était indexé, et un incident écrit au caractère 2 719 restait introuvable. Plafonnez les morceaux à environ 1 200 caractères.
L'index vit en mémoire. Notre service chargeait chaque index une fois et le gardait toute sa vie : réindexer mettait à jour le disque, pas les réponses. Redémarrez le service après chaque indexation, dans la même tâche.
L'orphelin. Une vieille copie du service gardait le port. La nouvelle échouait à démarrer, en boucle, et l'orphelin continuait de répondre avec un index de 40 heures : le redémarrage « réussissait », la santé était au vert. Le signe : tous les résultats avaient le même score, 1,0, donc le classement n'était plus que l'ordre des fichiers. Vérifiez qui tient vraiment le port (ss -lntp), et arrêtez l'orphelin par son PID, jamais par un motif de nom.
La mémoire. La réindexation montait à 1 Go sur une VM de 2 Go sans swap, et le système la tuait, à chaque fois, en silence. 2 Go de swap ont réglé le problème sans toucher à la RAM de la VM.
Sources
Utile ? Dites-nous ce qu'il faut mesurer ensuite.