Tout Bitcoiner qui a déjà contemplé un ERROR_TEMP_TOO_HIGH clignotant sur une hashboard à 2 h du matin connaît la routine : basculer vers un moteur de recherche, patauger dans les fils de forum, et espérer que quelqu’un avec la même version de firmware a déjà résolu le problème. Le problème, c’est que la réponse est dispersée dans une douzaine de PDF, une pile de manuels fabricant et quelques centaines de pages de codes d’erreur — rien n’est consultable en un seul endroit, et le tout fuit vos requêtes vers le service cloud dans lequel vous les avez tapées. Une configuration RAG self-hosted règle les deux problèmes d’un coup. Vous pointez une IA locale vers votre propre corpus de documentation de mineurs et posez des questions en langage courant, et elle répond à partir de vos documents — entièrement hors ligne, sans compte, sans télémétrie, sans facture mensuelle.
Ce guide détaille une configuration RAG locale pratique, entièrement construite sur du matériel que vous contrôlez : embeddings locaux, une vector database locale, et un model local servi par Ollama. L’exemple concret est le type de corpus qu’un foyer de minage accumule déjà — manuels fabricant, journaux de changements de firmware, et références de codes d’erreur. À la fin, vous pourrez discuter avec vos documents hors ligne, et vous comprendrez exactement le rôle de chaque pièce mobile afin de pouvoir remplacer n’importe quel élément par l’outil de votre choix. C’est le compagnon « connaissance documentaire » de l’exécution d’un LLM hors ligne en général; si vous n’avez pas encore installé un model local, commencez par notre guide d’installation d’Ollama en 10 minutes et revenez.
Ce que « RAG » signifie vraiment (en langage courant)
RAG signifie retrieval-augmented generation. Enlevez le jargon et c’est un tour en deux étapes. D’abord, le retrieval : lorsque vous posez une question, le système cherche dans vos documents les quelques passages les plus pertinents. Ensuite, la génération : il remet ces passages à un language model avec votre question et lui dit, en substance, « réponds à cela en utilisant uniquement le texte ci-dessous. » Le model rédige une réponse fluide, mais les faits viennent de vos fichiers plutôt que de ce que le model a mémorisé pendant l’entraînement.
Cette distinction compte énormément pour le travail de minage. Un model généraliste n’a aucune idée quel code de panne PSU correspond à quelle carte sur votre build de firmware spécifique. Il inventera volontiers quelque chose de plausible — la redoutable hallucination. Le RAG ancre la réponse dans le texte réel du manuel, de sorte que le model cesse de deviner et commence à citer. Cela signifie aussi que vous pouvez mettre à jour la connaissance instantanément : déposez une nouvelle note de version de firmware dans le dossier, ré-indexez, et l’assistant la connaît. Pas de réentraînement, pas de ferme de GPU, pas d’attente.
Surtout, rien de tout cela n’exige d’envoyer vos documents quelque part. Tout le pipeline — transformer le texte en vectors consultables, les stocker, et exécuter le model qui les lit — se déroule sur votre propre machine. C’est le gain de souveraineté : votre base de connaissances reste aussi privée que votre seed phrase. C’est le même principe de possession de vos données qui traverse tout ce que l’on trouve dans notre hub de souveraineté.
Les quatre parties d’un pipeline RAG local
Une stack RAG self-hosted n’est que quatre composants câblés ensemble. Comprenez-les et vous pourrez la construire avec les outils que vous voulez.
- Le loader/chunker — lit vos PDF, manuels et fichiers texte et les découpe en passages de taille digeste (typiquement 300–800 mots chacun). Les models ne peuvent « voir » qu’une fenêtre limitée de texte à la fois, donc on leur donne des chunks, pas des livres entiers.
- Le model d’embedding — convertit chaque chunk en un vector, une longue liste de nombres qui capture son sens. Deux passages sur des cartes en surchauffe se retrouvent proches dans cet espace de nombres même s’ils utilisent des mots différents. C’est la partie qui fait que la recherche comprend le sens, et pas seulement les mots-clés.
- La vector database — stocke ces vectors et trouve les correspondances les plus proches de votre question en millisecondes. C’est votre « vector database » locale, et elle peut n’être qu’un seul fichier sur le disque.
- Le language model — le LLM local, servi par Ollama, qui lit les chunks récupérés et rédige la réponse.
Les trois premiers construisent l’index consultable une seule fois, à l’avance. Le quatrième s’exécute chaque fois que vous posez une question. Garder ce modèle mental clair est ce qui rend le tout facile à déboguer plus tard.
Choisir vos pièces locales
Vous avez de vrais choix à chaque couche, et tous peuvent tourner sur un ordinateur de bureau modeste avec un seul GPU grand public — ou même en CPU seul si vous êtes patient. Voici une stack par défaut raisonnable et les compromis.
| Couche | Défaut raisonnable | Pourquoi | Option plus légère / plus lourde |
|---|---|---|---|
| Embeddings (locaux) | nomic-embed-text via Ollama | Tourne en local via le même Ollama que vous utilisez déjà; petit et rapide | all-MiniLM (plus léger) / mxbai-embed-large (plus lourd, meilleur recall) |
| Vector store (local) | Chroma (fichier unique, adossé à SQLite) | Zéro serveur à faire tourner; vit dans un dossier que vous pouvez sauvegarder | Fichier plat FAISS (plus léger) / Qdrant (plus lourd, multi-utilisateurs) |
| Model de génération | Un model instruct de classe 8B dans Ollama | Tient dans ~6–8 Go de VRAM en quantification Q4; assez bon pour résumer le texte récupéré | Model 3B (compatible CPU) / 14B+ (meilleur raisonnement, plus de VRAM) |
| Orchestration | Un script Python d’environ 60 lignes, ou la fonction document intégrée d’Open WebUI | Contrôle total vs. interface graphique sans code | — |
Si le model lui-même est la partie qui vous laisse hésitant, notre décryptage de la quantification GGUF et Q4/Q8/fp16 explique pourquoi un model 8B en Q4 est le point idéal pour un labo maison, et notre comparaison de runners couvre pourquoi Ollama est l’épine dorsale la plus simple pour ce type de projet.
Le construire : le jeu de données concret
La raison pour laquelle ce guide utilise la documentation des mineurs, c’est que D-Central maintient déjà exactement le type de corpus pour lequel le RAG a été conçu : une bibliothèque structurée de 650+ codes d’erreur Antminer documentés, des manuels fabricant et des notes de firmware couvrant toute la gamme Bitmain et des concurrents. C’est un premier jeu de données parfait parce qu’il est dense en texte, plein de numéros de modèles et de chaînes de panne, et véritablement pénible à chercher à la main. Vous pouvez assembler votre propre version à partir des manuels fournis avec votre matériel plus les notes de version sauvegardées — les mêmes fichiers que vous perdriez autrement dans un dossier de téléchargements.
Étape 1 — rassembler et nettoyer
Déposez chaque PDF, manuel et .txt pertinent dans un seul dossier. Retirez tout ce qui n’est que pure prose standard (avis juridiques, en-têtes répétés) pour que l’index reste focalisé. Les déchets dans le corpus deviennent des déchets dans les réponses.
Étape 2 — découper en chunks et embedder
Passez chaque document dans le loader pour le découper en chunks qui se chevauchent, puis envoyez chaque chunk au model d’embedding. Un petit chevauchement (disons 10–15 %) entre chunks consécutifs empêche qu’une réponse soit coupée en deux à la frontière d’un chunk. Le vector de chaque chunk va dans Chroma avec une note indiquant de quel document et quelle page il provient — c’est cette métadonnée qui permet à l’assistant de citer sa source.
Étape 3 — brancher le retrieval et la génération
Pour une question, embeddez la requête avec le même model d’embedding, demandez à Chroma les trois à cinq chunks les plus proches, et glissez-les dans un template de prompt : une courte instruction système (« réponds uniquement à partir du context ci-dessous; s’il n’y est pas, dis-le »), les chunks récupérés, et la question de l’utilisateur. Envoyez cela à votre model Ollama et streamez la réponse.
Étape 4 — le faire répondre honnêtement
La ligne la plus importante de toute la construction est l’instruction disant au model de refuser lorsque les documents ne contiennent pas la réponse. Sans elle, le RAG hallucine encore sur les trous. Avec elle, votre assistant dit « ce code de panne n’est pas dans les manuels chargés » — ce qu’un outil souverain doit faire exactement au lieu de bluffer.
Pourquoi un RAG hors ligne bat un chatbot cloud pour le travail de minage
Il est légitime de se demander pourquoi s’en donner la peine, quand un assistant cloud répond déjà aux questions. Trois raisons se démarquent pour ce public.
Confidentialité. Votre historique d’entretien, vos versions de firmware, les particularités de votre installation — rien de tout cela ne devrait servir de données d’entraînement pour un tiers. Un pipeline local garde le corpus entier et chaque requête sur votre propre disque. C’est la même logique que de faire tourner votre propre node plutôt que de faire confiance à un explorateur de blocs.
Exactitude sur votre matériel. Un model cloud répond à partir d’une moyenne générique d’internet. Votre RAG répond à partir du manuel exact pour la révision exacte de carte que vous possédez. Quand une mauvaise réponse signifie une hashboard grillée, cette spécificité vaut la peine d’être construite. Couplez-le à notre LLM hors ligne qui lit les journaux de vos mineurs et vous avez un assistant de diagnostic en boucle fermée qui ne rappelle jamais la maison.
Résilience. Quand le FAI tombe ou que l’API dont vous dépendez change ses tarifs du jour au lendemain, votre assistant hors ligne continue de fonctionner. Les plebs qui self-hostent sont ceux encore en ligne quand l’option pratique s’éteint. L’argument plus large pour posséder toute la stack — pas seulement le model — est détaillé dans Own Your Compute.
Une note sur l’exactitude et l’humilité
Le RAG réduit l’hallucination de façon spectaculaire, mais ne l’élimine pas. Le model peut encore mal lire un tableau ou recoudre deux chunks sans rapport. Traitez la sortie comme une première ébauche rapide d’un stagiaire très bien lu, pas comme parole d’évangile — vérifiez toute correction contre la page réelle du manuel qu’il cite avant d’agir sur un mineur en production. Tout l’intérêt de conserver les métadonnées de source, c’est que vous pouvez vérifier. Et comme chaque outil de l’espace IA open source, ce pipeline se dresse sur les épaules des chercheurs de models d’embedding, des auteurs de vector databases, et de la communauté des runners locaux qui ont rendu tout cela possible sur du matériel domestique.
D’un index personnel à une stack souveraine
Un assistant local conscient des documents est une couche de plus décentralisée : vous possédez les données, l’index, le model, et la machine sur laquelle il tourne. C’est le prochain node naturel après un LLM local, aux côtés du maillage réseau, de votre propre identité Nostr, et des paiements self-hosted dans une stack qui ne dépend de la permission de personne. Si vous voulez que toute cette stack soit reproductible — reconstruisible à partir d’une seule config déclarative — NixOS pour les Bitcoiners souverains montre le patron. La même philosophie anime DCENT_OS, notre firmware open source pour le matériel Antminer industriel — construit en Rust, GPL-3.0, avec une cible de frais de développement obligatoires de 0 %, actuellement en bêta publique active sur le S9 et le S19j Pro avec le support S19/S21 à venir, et construit ouvertement sur les épaules de Braiins OS+, VNish et LuxOS. Posséder votre firmware et posséder votre base de connaissances, c’est le même combat depuis deux directions.
Questions fréquemment posées
Ai-je besoin d’un GPU puissant pour faire tourner un RAG local?
Non. La moitié retrieval (embeddings plus la vector database) est assez légère pour tourner sur CPU. La moitié génération est la partie exigeante, et un model de classe 8B en quantification Q4 tient confortablement dans environ 6–8 Go de VRAM. Un model 3B tournera sur CPU seul si vous tolérez des réponses plus lentes, donc même un ordinateur de bureau modeste suffit pour commencer.
En quoi est-ce différent de simplement coller un manuel dans un chatbot?
Coller fonctionne pour un seul document court, mais vous heurtez vite les limites de context et vous re-collez à chaque session. Le RAG indexe toute votre bibliothèque une fois, puis récupère seulement les quelques passages pertinents pour chaque question — donc vous pouvez interroger des centaines de manuels à la fois, l’assistant cite sa source, et rien ne quitte votre machine.
L’assistant peut-il rester à jour quand le firmware change?
Oui, et à peu de frais. Parce que la connaissance vit dans l’index vector plutôt qu’à l’intérieur des poids du model, vous ne réentraînez jamais rien. Déposez une nouvelle note de version dans le dossier du corpus, relancez l’étape chunk-and-embed, et l’assistant connaît immédiatement la mise à jour.
Mes données sont-elles vraiment privées avec cette configuration?
Si chaque composant est local — embeddings locaux, un vector store local, et un model Ollama — alors oui, aucun document ni aucune requête ne quitte jamais votre matériel. La seule façon de faire fuiter des données est d’échanger délibérément vers une API cloud d’embedding ou de génération, ce qui anéantit le but.
Construisez-le, puis construisez par-dessus
Un RAG self-hosted sur la documentation de vos mineurs est un projet de fin de semaine qui paie à chaque fois que le matériel se comporte mal : des réponses instantanées, privées et citées en source à partir de la documentation que vous possédez déjà. Commencez avec un model local et faites croître l’index à partir de là. Si vous voulez aller jusqu’au bout et posséder aussi la couche firmware — le code qui tourne sur le mineur lui-même, pas seulement l’IA qui lit son manuel — rejoignez la liste d’attente de la bêta publique DCENT_OS et aidez à construire le premier firmware open source destiné au matériel Antminer industriel. Une couche de plus décentralisée, à chaque fois.
