Configuration locale de LLM : comment utiliser RAG et un modèle d'embedding pour arrêter de gaspiller du contexte

Les LLM locaux sont fantastiques, et ils continuent de s'améliorer à un rythme stupéfiant. J'ai des raisons non négociables de préférer une configuration locale plutôt que de dépendre des géants du cloud comme Claude ou ChatGPT. Pour cette raison, j'ai essayé sans relâche d'intégrer des modèles locaux dans mon flux de travail quotidien réel.

Mais comme toute personne qui a essayé vous le dira, la voie du bricolage comporte des mises en garde et des inconvénients distincts.

Le plus grand obstacle absolu est la fenêtre de contexte. Pour obtenir de meilleures réponses d'un LLM, nous devons lui fournir plus de contexte. Mais le contexte est coûteux. Et dès que la fenêtre de contexte commence à se remplir, le modèle commence à se détériorer tant en vitesse qu'en qualité. Alors, que sommes-nous censés faire ?

Le problème, j'ai réalisé, n'était pas le LLM lui-même. Le problème était que j'utilisais le LLM pour un travail pour lequel il n'était jamais destiné. Et la solution était un petit modèle que j'avais complètement ignoré.

Les LLM et le problème du contexte

C'est vraiment cher

La moitié de notre expérience avec un modèle de langage dépend de ce que nous lui présentons. Si nous lui donnons une invite vague et mince, nous obtenons une réponse vague et mince. Pour de meilleures réponses, nous devons donner au LLM plus de contexte.

Le problème est que le contexte est coûteux. Sur un modèle cloud, plus de contexte signifie plus de tokens, et plus de tokens signifie des coûts plus élevés. Localement, cela signifie une inférence plus lente, car chaque token dans cette fenêtre de contexte doit être traité pendant la génération. Pour un modèle local en particulier, cela importe encore plus.

Nous travaillons déjà avec des machines plus petites et des contraintes plus strictes. Déverser des documents entiers dans la fenêtre de contexte à chaque fois que vous posez une question dégrade activement l'expérience. Le modèle dépense trop d'énergie à transporter des informations, plutôt qu'à raisonner réellement avec les parties qui comptent.

Un modèle d'intégration est ce qui m'a permis de réparer cela.

Modèles d'intégration

Les guerriers méconnus des LLM locaux

Le petit modèle en question est un modèle d'intégration. Les modèles d'intégration existent en différentes tailles, mais comparé à un LLM, ils sont vraiment minuscules. Ce que fait un modèle d'intégration est légèrement abstrait, mais je vais faire de mon mieux pour l'expliquer.

Un modèle d'intégration prend un morceau de texte et le convertit en une longue liste de nombres. Cette liste s'appelle un vecteur, et elle représente le sens du texte dans un espace mathématique.

Deux phrases qui signifient approximativement la même chose produiront des vecteurs proches les uns des autres dans cet espace. Deux phrases qui n'ont rien à voir l'une avec l'autre seront éloignées.

Ce n'est pas une recherche par mot-clé. Le modèle ne se soucie pas des mots-clés exacts de la même manière qu'une boîte de recherche normale. Le modèle d'encodage comprend la similarité sémantique.

Si mon explication et mon tableau n'ont toujours pas suffi, le court métrage YouTube ci-dessous rend justice au sujet :

Ce modèle s'appelle RAG

RAG ou génération augmentée par récupération. L'idée est qu'au lieu d'intégrer toutes vos connaissances dans le modèle lui-même, vous les gardez à l'extérieur, dans une base de données vectorielle, et ne récupérez que les éléments pertinents au moment où vous en avez besoin. Le travail du modèle reste concentré sur ce pour quoi il est bon, c'est-à-dire générer une réponse.

Tout d'abord, un embedding traite vos documents et convertit chaque segment de texte en un vecteur. Ces vecteurs sont stockés dans une base de données dédiée (quelque chose comme ChromaDB ou Qdrant, qui s'exécutent tous deux localement sur votre machine). Cette étape ne se produit qu'une seule fois.

Ensuite, lorsque vous posez une question, le même modèle d'intégration convertit votre requête en un vecteur également. La base de données effectue une recherche de similarité et met en avant les morceaux qui sont les plus proches en signification de ce que vous avez demandé. Ces morceaux sont transmis à votre LLM comme contexte, en plus de la question originale. Le LLM s'occupe de l'interprétation.

Vous en avez déjà bénéficié sans le savoir. NotebookLM, l'assistant de recherche de Google, vous permet d'y déposer gratuitement des milliers et des milliers de mots de sources. Google est-il exceptionnellement généreux avec les jetons ?

Non. C'est l'embedding qui fonctionne. Il ne charge pas toutes vos sources dans le modèle à chaque requête — il ne récupère que ce qui est pertinent, de manière économique et instantanée. Le gros du travail est délégué à un processus qui coûte presque rien à faire fonctionner.

Ma configuration locale avec un modèle d'intégration

Le vôtre peut être très différent, bien sûr

Le cas d'utilisation le plus immédiat pour un LLM local concerne vos documents. Pour cela, vous pouvez déjà démontrer l'idée dans LM Studio, l'interface LLM locale populaire, sans beaucoup de configuration. LM Studio est déjà livré avec RAG intégré. C'est de cela dont parlent les notifications « modèle d'intégration mis à jour ». Dans une nouvelle conversation avec votre LLM, assurez-vous que le MCP RAG est activé, puis téléchargez vos documents. C'est à peu près tout.

Je voulais intégrer de manière persistante mes entrées de journal Obsidian, et cela n'était pas assez persistant. Pour quelque chose de plus permanent, je recommande de télécharger un modèle d'intégration et de l'héberger avec votre LLM.

À partir de là, vous avez des options. Vous pouvez utiliser une application pré-construite comme OpenNotebook, qui est essentiellement un clone auto-hébergé de NotebookLM, puis la connecter au modèle LLM et au modèle d'intégration que vous avez hébergé. À partir de là, vous téléchargez vos sources et les utilisez dans cette application.

Mais encore une fois, cela nécessite que vous utilisiez OpenNotebook pour les requêtes. Je voulais plus de flexibilité.

Donc, j'ai configuré Qdrant comme base de données vectorielle. C'est très facile à configurer (merci, Docker). Ensuite, avec un simple script Python, je peux interagir avec le modèle d'embedding et lui faire intégrer mes fichiers dans la base de données Qdrant.

De là, j'ai tout intégré dans un serveur MCP, l'ai connecté à OpenClaw, et c'était tout. Maintenant, mon agent peut récupérer le contexte pertinent sans tout épuiser. Le bon côté d'un serveur MCP est que je peux le brancher à presque toutes les autres interfaces d'IA. Claude Code, Codex et Antigravity prennent tous en charge les serveurs MCP.

L'intégration va bien au-delà des simples « documents »

Utilisez-le pour une expérience persistante

Markdown est le langage de programmation de 2026. Les grands modèles de langage prennent le langage en entrée puis produisent du langage en sortie. Les mots sont le langage de programmation.

Si vous avez votre propre agent IA, alors un modèle d'intégration est nécessaire pour une mémoire persistante. L'alternative consiste à envoyer chaque conversation passée comme contexte dans chaque nouveau message. De toute évidence, cela n'est pas faisable à grande échelle. C'est lent, cela dépasse les limites de jetons et cela rend l'expérience pire. Le modèle d'intégration est ce qui permet au système d'être sélectif.

Ainsi, le flux de travail peut être quelque chose comme ceci : OpenClaw, ou l'agent que vous utilisez, garde un enregistrement des conversations en Markdown. Ces fichiers sont intégrés dans une base de données vectorielle avec un modèle d'intégration. Chaque fois qu'OpenClaw a besoin d'accéder aux discussions passées, sa mémoire, il peut interroger la base de données vectorielle et obtenir exactement ce qu'il doit se rappeler.

C'est presque exactement ainsi que fonctionne la mémoire humaine. Vous ne commencez pas une conversation avec votre meilleur ami en vous présentant, en lui disant votre nom, puis en énumérant tout ce que vous avez déjà fait ensemble (sauf si vous voulez faire un point !) Non. Ces événements sont déjà là. Ils sont rappelés lorsque c'est nécessaire.

Je l'ai utilisé pour mon journal, et cela a été un progrès majeur pour faire fonctionner un LLM local avec mon coffre Obsidian. Quel que soit votre cas d'utilisation, je vous suggère de mettre en place le pipeline. Une fois que le LLM cesse de porter chaque morceau de contexte sur lui et commence à ne récupérer que ce qui compte, toute l'expérience change.