- Un chatbot RAG, c'est un assistant qui répond à partir de TA doc, pas de ses souvenirs.
- Sur Copyboost, j'ai monté le pipeline complet : je découpe la doc en morceaux, je calcule leurs embeddings, je les range dans pgvector, et à chaque question, je récupère les bons morceaux pour laisser Claude Haiku répondre dessus.
Lecture complète : 7 min
Un chatbot RAG, c’est un assistant qui répond à partir de TA doc, pas de ses souvenirs. Sur Copyboost, j’ai monté le pipeline complet : je découpe la doc en morceaux, je calcule leurs embeddings, je les range dans pgvector, et à chaque question, je récupère les bons morceaux pour laisser Claude Haiku répondre dessus.
Au début, le chatbot de Copyboost racontait n’importe quoi. Je lui posais une question sur une fonctionnalité précise, et il inventait une réponse plausible mais fausse. Le problème classique : un modèle de langage répond avec ce qu’il a appris, pas avec ce que MOI je sais de mon produit.
Je build avec Claude Code, sans avoir appris à coder à l’école. J’ai donc dû comprendre la mécanique du RAG pour la monter pour de vrai, pas juste recopier un tuto. RAG veut dire Retrieval Augmented Generation : on récupère d’abord les bons morceaux de doc, puis on génère une réponse ancrée dessus.
Voici le pipeline réel qui tourne sur Copyboost, brique par brique.
Un chatbot RAG, c’est quoi et pourquoi j’en ai monté un
Un chatbot RAG répond en deux temps. D’abord il va chercher les passages de ta doc qui correspondent à la question. Ensuite il rédige sa réponse à partir de ces passages, et seulement eux. Résultat : il colle à ton produit au lieu d’improviser à partir de connaissances générales.
La différence est simple. Un modèle de langage seul répond avec ce qu’il a vu pendant son entraînement. Il ne connaît ni ta doc, ni tes prix, ni tes réglages. Quand il ne sait pas, il comble le trou avec une réponse crédible, et c’est là qu’il se trompe.
Le RAG corrige ça en ajoutant une étape de recherche avant la rédaction. Tu donnes au modèle les bons extraits de ta doc, puis tu lui demandes de répondre uniquement à partir d’eux. Sur Copyboost, ça veut dire des réponses qui parlent vraiment de Copyboost.
Voici ce que le RAG change, posé à plat :
| Critère | Sans RAG | Avec RAG |
|---|---|---|
| Source de la réponse | Mémoire d’entraînement du modèle | Ta doc, récupérée à la question |
| Quand il ne sait pas | Il invente une réponse crédible | Il s’appuie sur tes extraits |
| Mise à jour du savoir | Figée à l’entraînement | Tu changes la doc, il suit |
| Lien avec ton produit | Générique | Collé à ton cas |
Le pipeline RAG de Copyboost, étape par étape
Le pipeline tient en deux phases. La phase de préparation, faite une fois : je découpe la doc, je calcule les embeddings, je range les vecteurs. La phase de réponse, jouée à chaque question : je calcule l’embedding de la question, je cherche les morceaux proches, je les passe à Haiku qui rédige.
Déroulé concret, dans l’ordre :
- Je découpe la doc en chunks, des morceaux courts qui tiennent sur une idée.
- Je calcule l’embedding de chaque chunk, sa version chiffrée.
- Je stocke ces vecteurs dans pgvector, dans la base Postgres de Copyboost.
- À la question d’un utilisateur, je calcule son embedding de la même façon.
- Je cherche dans pgvector les chunks dont le vecteur est le plus proche.
- J’injecte ces chunks dans le prompt envoyé à Claude Haiku.
- Haiku rédige la réponse en s’appuyant sur ces extraits, pas sur sa mémoire.
Chaque étape a un rôle précis. Si une seule manque, la chaîne casse. Pas d’embedding, pas de recherche. Pas de recherche, pas de contexte. Pas de contexte, le modèle improvise de nouveau.
Les briques du RAG et le rôle de chacune
Cinq briques font tourner ce chatbot. Les chunks découpent la doc. Les embeddings la traduisent en vecteurs. pgvector range ces vecteurs et les compare. La recherche par similarité sort les plus proches de la question. Claude Haiku rédige la réponse finale. Chacune fait une chose, et le pipeline les enchaîne.
| Brique | Son rôle dans le RAG |
|---|---|
| Chunks | Découpent la doc en morceaux courts et ciblés |
| Embeddings | Traduisent chaque morceau en vecteur de nombres |
| pgvector | Range les vecteurs dans Postgres et les compare vite |
| Recherche par similarité | Sort les morceaux les plus proches de la question |
| Claude Haiku | Rédige la réponse à partir des morceaux retenus |
Un mot sur le choix de Haiku. Anthropic décline plusieurs modèles Claude, du plus léger au plus lourd. Pour ce rôle, répondre sur des extraits déjà fournis, je n’ai pas besoin du plus gros cerveau. Haiku est le modèle rapide et économique de la gamme, et il suffit largement à reformuler un contexte clair.
La requête de similarité dans pgvector
Le coeur de la recherche, c’est une requête SQL dans pgvector. L’extension ajoute un type vecteur à Postgres et un opérateur de distance, noté avec des chevrons. Tu demandes les lignes dont le vecteur est le plus proche de celui de la question, tu les tries par distance, et tu gardes les premières.
pgvector est une extension de PostgreSQL. Comme Copyboost tourne sur Supabase, qui est du Postgres managé, je l’active en une ligne et mes vecteurs vivent dans la même base que le reste. Si le mot Supabase est flou pour toi, j’en ai fait un guide Supabase pour débutant.
select contenu
from documents
order by embedding <=> :question_vecteur
limit 5;Trois choses à lire ici. L’opérateur chevron mesure la distance entre deux vecteurs : plus elle est petite, plus le sens est proche. Le tri remonte les morceaux les plus pertinents en haut. Le limit garde seulement les cinq meilleurs, ceux que je passe ensuite à Haiku.
Ce qui a coincé quand j’ai monté ce chatbot
Le pipeline a l’air propre sur le papier. En vrai, le premier qui m’a planté, c’est le découpage. Mes chunks étaient trop gros : la recherche remontait des passages à moitié hors sujet, et Haiku se noyait dans le bruit. Trop petits, à l’inverse, et l’idée se coupait en deux.
J’ai testé en posant toujours les mêmes questions et en lisant les morceaux récupérés. Quand la réponse dérapait, je regardais quels chunks étaient remontés. Neuf fois sur dix, le problème venait du découpage, pas du modèle.
J’ai resserré la taille des chunks et ajouté un léger chevauchement entre eux. Une idée à cheval sur deux morceaux n’est ainsi jamais coupée net. J’ai aussi nettoyé la doc source, parce qu’un texte mal structuré donne des embeddings flous.
Résultat : les morceaux remontés sont devenus nettement plus pertinents, et les réponses ont arrêté de partir en vrille. Le vrai travail du RAG n’est pas dans le modèle, il est dans la préparation des données. Je l’ai appris en montant le pipeline avec Claude Code, pas dans un cours. Le sujet rejoint ce que la doc des API Gemini et Claude ne dit pas vraiment.
Ce que le RAG change pour un chatbot de SaaS
Trois choses à retenir. Un chatbot RAG répond à partir de ta doc, pas de la mémoire générale du modèle, et c’est ça qui le rend fiable sur ton produit. Le pipeline n’a rien de magique : découper, vectoriser, ranger, chercher, générer. Et le vrai levier de qualité n’est pas le modèle, mais la propreté de la doc que tu lui donnes à lire.
Monter ce pipeline m’a appris plus sur mon produit que sur l’IA. La prochaine question que je me pose : jusqu’où automatiser la mise à jour des chunks quand la doc bouge ? Et toi, ton chatbot répond sur tes données, ou il improvise encore ?
Dernière mise à jour : juin 2026
Discussion