Comment fonctionne un chatbot RAG ? Vulgarisation technique pour décideurs

RAG est l'acronyme de Retrieval-Augmented Generation — littéralement « génération augmentée par récupération ». C'est le pattern technique le plus utilisé en 2026 pour brancher un grand modèle de langage (LLM) sur des contenus spécifiques. Cet article est une vulgarisation pour décideurs et chefs de projet : on explique ce qui se passe sous le capot, sans aller dans le code.

Le problème de départ

Les LLM sont entraînés sur des téraoctets de texte public, mais ils ne connaissent pas vos documents internes. Quand vous demandez à ChatGPT « quel est le tarif de votre service ménage à Lyon ? », il n'a aucune idée — vos tarifs n'étaient pas dans son corpus d'entraînement, et son corpus s'arrête de toute façon à une date donnée.

Deux familles de solutions existent :

1. Fine-tuning : ré-entraîner partiellement le modèle sur vos contenus. Lourd, coûteux, et chaque mise à jour de contenu nécessite un nouvel entraînement.
2. RAG : au moment où la question arrive, récupérer les passages pertinents de vos contenus, les injecter dans le prompt envoyé au modèle, et lui demander de répondre en s'appuyant uniquement sur ces extraits. Léger, rapide à mettre à jour, suffisant pour 95 % des cas business.

Mankonnect — comme la majorité des plateformes de chatbot SaaS modernes — utilise le RAG. On va expliquer pourquoi et comment.

Les 4 étapes du pipeline RAG

Quand vous importez un document, et qu'un visiteur pose une question, voici ce qu'il se passe.

Étape 1 — Chunking : découper en morceaux

Un document brut (PDF, Word, page web) est découpé en chunks — des morceaux de texte de taille homogène (généralement 500-1500 caractères, selon le système). Le découpage doit préserver le contexte sémantique : on coupe sur les paragraphes, les titres, les listes, plutôt qu'au milieu d'une phrase.

Pourquoi découper ? Parce qu'on va vouloir retrouver des passages précis, pas « le document qui en parle peut-être ». Si vous laissez tout en un seul bloc, le retrieval n'est plus précis. Si vous découpez trop fin, vous perdez le contexte. Le bon compromis dépend du type de contenu — c'est là qu'un système de chunking intelligent fait la différence.

Étape 2 — Embedding : transformer chaque chunk en vecteur

Chaque chunk est passé dans un modèle d'embedding qui produit un vecteur — un tableau de plusieurs centaines à plusieurs milliers de nombres. Ce vecteur est une représentation numérique du sens du texte.

Propriété fondamentale : deux textes au sens proche ont des vecteurs proches. « Quel est votre tarif horaire pour le ménage ? » et « Combien coûte une heure de ménage ? » auront des vecteurs très voisins — alors qu'une recherche par mots-clés stricts pourrait les considérer comme différents.

Tous ces vecteurs (un par chunk) sont stockés dans une base vectorielle (chez Mankonnect, on utilise l'extension pgvector sur PostgreSQL — robuste, ouvert, transactionnel).

Étape 3 — Retrieval : trouver les chunks pertinents

Quand un visiteur pose une question, on commence par calculer son embedding (avec le même modèle qu'à l'étape 2). On cherche ensuite, dans la base vectorielle, les 3 à 5 chunks dont les vecteurs sont les plus proches du vecteur de la question (proximité mesurée par produit scalaire ou distance cosinus).

On obtient ainsi les passages de votre KB qui parlent du sujet, même s'ils n'utilisent pas exactement les mêmes mots que la question. C'est l'étape qui rend le système robuste au vocabulaire des visiteurs.

Étape 4 — Génération : le modèle répond

On envoie au LLM un prompt structuré qui contient :

• une consigne système (par exemple : « tu es un assistant pour Mankova. Réponds aux visiteurs en t'appuyant uniquement sur les extraits ci-dessous. Si la réponse ne s'y trouve pas, dis-le clairement ») ;
• les chunks récupérés à l'étape 3 ;
• l'historique de conversation (les messages précédents) ;
• la question du visiteur.

Le modèle formule la réponse, qui est renvoyée au widget. Le visiteur la reçoit en moins de 2 secondes, et n'a aucune idée des 4 étapes qui viennent de se dérouler.

Avantages du RAG

• Mise à jour instantanée : ajouter un document à la KB met quelques secondes (ré-embedding + indexation). Pas de ré-entraînement.
• Traçabilité : chaque réponse peut être rattachée aux chunks utilisés. Mankonnect affiche les sources consultées dans le tableau de bord (top documents utilisés en retrieval).
• Coût maîtrisé : on n'envoie au modèle que les chunks pertinents, pas la KB complète. Le coût reste linéaire avec le volume de conversations, pas avec la taille de la KB.
• Hallucinations limitées : avec une consigne stricte (« réponds uniquement à partir des extraits »), le modèle invente moins. Pas zéro, mais beaucoup moins.

Limites et bonnes pratiques

• Si la KB est mauvaise, les réponses sont mauvaises. Le RAG amplifie la qualité de votre KB, mais ne la fabrique pas. Investir dans la KB reste essentiel.
• Le retrieval n'est pas magique : une question très ambiguë (peu d'embedding signal) peut tomber sur des chunks non pertinents. La discipline d'écriture de la KB (titres clairs, formulations explicites) compte.
• Les hallucinations subsistent. Sur des sujets sensibles, prévoir un orchestrateur humain dans la boucle (tickets envoyés au support pour validation).
• Le RAG ne remplace pas une vraie expertise sur des sujets qui demandent un raisonnement complexe (analyse juridique, diagnostic médical, conseil financier). Il complète, il ne remplace pas.

RAG vs fine-tuning, lequel choisir ?

Critère	RAG	Fine-tuning
Mise à jour KB	Quelques secondes	Heures à jours
Coût initial	Faible	Élevé
Coût récurrent	Lié au volume conv.	Lié au modèle hébergé
Traçabilité sources	Native	Nulle
Idéal pour	Q&A factuel, KB qui change	Style, ton, domaine très spécifique

Pour un chatbot Q&A sur des contenus métier, le RAG gagne à tous les coups. Le fine-tuning reste pertinent quand il faut adapter le style du modèle (ton très spécifique, jargon technique pointu) — et même là, beaucoup d'équipes combinent RAG + prompt engineering avant de tenter le fine-tuning.

FAQ technique RAG

Pourquoi le RAG est-il préférable à un fine-tuning du modèle ?

Le fine-tuning entraîne durablement le modèle sur vos contenus, ce qui est lourd, coûteux, et impose de réentraîner à chaque mise à jour de KB. Le RAG injecte les passages pertinents au moment de la requête, donc la KB peut être actualisée en quelques secondes (un PDF mis à jour, une FAQ corrigée) sans toucher au modèle. Pour 95 % des cas business, le RAG est plus simple, plus rapide et bien suffisant.

C'est quoi concrètement un embedding ?

Un embedding est une représentation numérique d'un texte sous forme de vecteur (par exemple un tableau de 1536 nombres). Deux textes au sens proche ont des vecteurs proches (au sens d'un produit scalaire ou d'une distance cosinus). C'est ce qui permet de retrouver « les passages dont le sens est proche de la question », et pas seulement « les passages qui contiennent les mêmes mots-clés ».

Pourquoi découper en chunks plutôt que d'envoyer tout le document ?

Parce que les modèles ont une fenêtre de contexte limitée (souvent 8 à 128 K tokens, pour des coûts qui montent vite avec la taille). Un document de 50 pages dépasse souvent cette limite. Et même quand ça passe, on paie au token : envoyer 50 pages alors que la réponse tient dans 1 paragraphe est gaspilleur. Le chunking + RAG envoie uniquement les morceaux utiles.

Et si la KB ne contient pas la réponse ?

Avec une consigne système bien rédigée (« si tu ne sais pas, dis-le et propose un contact humain »), le modèle reconnaît son ignorance plutôt que d'inventer. Ce n'est jamais 100 % fiable — un modèle peut quand même halluciner — mais c'est dramatiquement plus fiable qu'un usage brut. Mankonnect ajoute aussi des garde-fous : top questions non couvertes visibles dans le tableau de bord pour enrichir la KB ciblée.

Peut-on faire du RAG sans serveur dédié ?

Oui, c'est l'intérêt d'une plateforme SaaS comme Mankonnect : l'infrastructure (vecteurs, embeddings, retrieval, modèle, mise à l'échelle) est gérée pour vous. Vous fournissez les contenus, vous récupérez le widget. Le RAG est dans la plateforme, pas dans votre serveur.

---

Pour aller plus loin : Pourquoi installer un chatbot IA sur son site, ChatGPT vs chatbot personnalisé entreprise, ou les fonctionnalités Mankonnect.