RAG : brancher ta propre base de connaissances sur une IA

C'est le problème que RAG vient régler. Retrieval-Augmented Generation : au lieu de laisser le modèle puiser uniquement dans ce qu'il a appris pendant son entraînement, tu lui fournis des extraits de tes propres documents au moment de la requête. Le modèle ne devine plus, il lit.

Le principe tient en trois temps. Tu poses une question. Le système cherche dans ta base les passages les plus proches de cette question. Ces passages sont collés dans le prompt, et le modèle rédige une réponse à partir d'eux.

Ce qui change tout, c'est la recherche. Elle n'est pas lexicale. Elle est sémantique.

Un modèle d'embedding transforme chaque morceau de texte en un vecteur de plusieurs centaines de dimensions. Deux textes qui parlent de la même chose sans partager un seul mot se retrouvent proches dans cet espace. Tu cherches « mes notes sur la réunion de mardi » et le système retrouve un paragraphe qui commence par « compte rendu du 14 ». Aucun mot commun.

Pour stocker ces vecteurs et les interroger vite, il faut une base vectorielle. Qdrant, Chroma, pgvector, Milvus. Chacune a ses compromis.

Qdrant s'écrit en Rust, se lance en binaire unique ou en conteneur, et gère bien les filtres combinés à la recherche vectorielle. Chroma vise le prototype : trois lignes de Python et tu as une base persistante sur disque. pgvector n'est pas une base à part, c'est une extension PostgreSQL. Si tu as déjà un Postgres en production, tu ajoutes une colonne de type `vector` et tu ne maintiens rien de plus.

Le coût de ce choix est réel. Une base vectorielle dédiée, c'est un service de plus à superviser, sauvegarder, mettre à jour. pgvector, c'est moins de pièces mobiles mais des performances qui plafonnent plus tôt quand le volume monte. Personne ne te dira où se situe ce plafond pour ton usage, parce qu'il dépend de tes données.

Une fois la base en place, il reste à découper les documents. C'est l'étape que tout le monde bâcle.

Découper tous les 512 tokens avec un chevauchement de 50 fonctionne, mais coupe les phrases en deux et sépare les tableaux de leurs titres. Découper par section garde le sens intact mais produit des morceaux de tailles très inégales. Il n'y a pas de bonne réponse universelle. Il y a une réponse qui marche sur tes documents, et tu ne la trouveras qu'en regardant ce que la recherche te renvoie.

Un chunk, c'est l'unité que tu vas récupérer et coller dans le prompt. Trop petit, il manque le contexte. Trop grand, il noie le signal et consomme ta fenêtre de contexte.

Vient ensuite le modèle qui produit la réponse. C'est là que le paysage se sépare en deux.

D'un côté, les services en ligne. Tu envoies ton contexte et ta question à un serveur que tu ne contrôles pas. La qualité est souvent au rendez-vous, l'infrastructure ne te coûte rien à maintenir, et tu n'as pas besoin de GPU. Le prix, c'est que chaque document que tu interroges sort de chez toi.

De l'autre, le local. LM Studio, par exemple, fait tourner un modèle sur ta machine et propose un mode « Chat with your documents » qui indexe un dossier et répond à partir de son contenu. Rien ne quitte le disque. Le coût, c'est le matériel, et surtout le temps que tu passes à régler ce qui ne marche pas.

Cette frontière n'est pas idéologique. Elle dépend de ce que tu indexes.

Des notes personnelles, des comptes rendus internes, des dossiers clients : le local a un argument difficile à contourner. Une fois que le document est parti sur un serveur tiers, tu ne sais plus où il est.

De la documentation publique, des articles scientifiques, des manuels : le service en ligne fait le travail correctement et te fait gagner des semaines. Refuser cette option par principe coûte cher en énergie pour un gain de confidentialité nul, puisque l'information est déjà publique.

Le local a un autre attrait, moins avoué : il ne tombe pas quand ta connexion tombe. Et il ne change pas de prix du jour au lendemain parce qu'un fournisseur a revu sa grille.

Mais il faut être honnête sur ce que « local » implique. Un modèle qui tourne sur ta machine, c'est un modèle que tu dois choisir, quantifier, charger, et dont tu dois accepter la lenteur. Une transcription de réunion de deux heures sur GPU, c'est quelques minutes. Sur CPU, c'est une après-midi. Personne ne te prévient de ça avant que tu aies investi dans le matériel.

Loomfy illustre bien cette approche : enregistrement et transcription en local, accélération Vulkan, distinction des locuteurs, résumés générés sur place. L'audio ne sort jamais de la machine. Le confort est réel. La contrepartie, c'est une configuration qui n'a rien de plug-and-play, et des résultats qui varient selon la qualité de l'enregistrement.

Ces deux mondes ne sont pas étanches. Tu peux indexer en local et interroger un service distant pour la génération. Tu peux faire l'inverse. Tu peux commencer en local pour prototyper et basculer plus tard. Rien ne t'oblige à trancher une fois pour toutes.

Ce qui compte, au fond, c'est de savoir ce que tu mets dans la base.

Une base de connaissances n'est utile que si elle est propre. Des PDF scannés sans OCR, des exports de messagerie en désordre, des doublons en trois versions : le système te renverra fidèlement ce désordre, avec l'aplomb d'un modèle qui ne doute pas. RAG ne trie pas tes documents à ta place. Il lit ce que tu lui donnes.

Un point qu'on oublie souvent : les métadonnées. Indexer un document sans sa date, son auteur ou sa source, c'est se priver de la possibilité de filtrer. « Qu'est-ce qui a changé depuis janvier » devient une question à laquelle ton système ne peut pas répondre, même s'il a tous les documents. Ajoute les métadonnées au moment de l'indexation, pas après. Les rajouter plus tard veut dire tout réindexer.

Il y a aussi la question de la mise à jour. Une base vectorielle n'est pas un wiki. Quand un document change, il faut retrouver ses anciens chunks et les remplacer. Si tu ne prévois pas cet identifiant dès le départ, tu te retrouves avec deux versions du même document dans l'index, et le modèle ne saura pas laquelle croire. Il choisira peut-être la mauvaise, sans te le dire.

Sur la qualité des réponses, une chose est sûre : le modèle ne peut pas citer ce qu'il n'a pas reçu. Si la recherche te renvoie cinq chunks et que le bon n'est pas dedans, la réponse sera fausse ou vide. Tout le travail se joue donc en amont, dans le découpage et la recherche, pas dans le modèle. Un bon modèle avec une mauvaise recherche produit des réponses confiantes et fausses. Un modèle moyen avec une bonne recherche produit des réponses utiles.

C'est contre-intuitif, parce qu'on passe son temps à comparer les modèles et presque jamais les stratégies de découpage.

Pour tester si ta base tient la route, il n'y a qu'une méthode : pose les questions auxquelles tu connais déjà la réponse. Si le système retrouve le bon passage, la recherche fonctionne. S'il te sort un chunk voisin mais pas le bon, ton découpage est à revoir. S'il ne trouve rien, ta requête et tes documents ne se parlent pas dans le même espace sémantique, ce qui arrive plus souvent qu'on ne le croit avec du vocabulaire très spécialisé.

Les modèles d'embedding génériques ne connaissent pas le jargon de ton domaine. Un acronyme interne, un nom de projet, une référence à un outil maison : le vecteur ne capte rien d'utile. Dans ce cas, il faut soit enrichir les chunks avec des définitions, soit accepter que la recherche par mots-clés reste nécessaire en complément. La recherche hybride, vecteurs plus BM25, existe exactement pour ça.

Reste la question du coût, au sens large.

Chaque requête envoie des chunks au modèle. Plus tu indexes, plus tu as de chances de trouver, mais plus tu consommes de fenêtre de contexte et de temps de calcul. Un index de dix mille documents ne tient pas dans un prompt. Un index de vingt chunks bien choisis, oui. Le travail consiste à faire le tri avant, pas à tout envoyer en espérant que le modèle s'y retrouve.

Le reranking aide. Un premier passage récupère cinquante candidats, un second modèle les reclasse et n'en garde que cinq. Ça coûte un appel de plus et ça améliore nettement la précision. Sur un usage intensif, c'est souvent le meilleur rapport qualité-prix de toute la chaîne.

Maintenant, la vraie question : est-ce que tu en as besoin.

Si tu poses trois questions par semaine à un modèle sur des documents publics, RAG est une complication inutile. Copie le passage pertinent dans le prompt et continue ta journée.

Si tu as une masse de documents qui bougent, que tu veux interroger souvent, et que la réponse doit citer sa source, alors RAG devient rentable. Pas avant.

Et si ces documents sont sensibles, la version locale cesse d'être un choix technique pour devenir une contrainte que tu t'imposes. Ce qui est plus lourd à mettre en place, mais plus simple à justifier le jour où on te demande où sont passées les données.

Le reste dépend de ce que tu as dans tes dossiers, de la patience que tu as pour régler une chaîne de traitement, et de ce que tu es prêt à laisser sortir de ta machine.