Le RAG (Retrieval-Augmented Generation) est une architecture qui combine une recherche dans une base de connaissances et la génération de réponse par un LLM. Le principe : au lieu de demander à GPT de répondre depuis sa mémoire (avec un risque d'hallucination), on récupère d'abord les passages pertinents dans VOS données, puis on les donne au modèle qui rédige une réponse sourcée.

En 2026, le RAG est devenu l'architecture par défaut pour brancher un LLM sur une base de connaissances métier. Les cas d'usage typiques : assistant interne sur la documentation produit, support client automatisé sur la knowledge base, recherche sémantique dans des contrats juridiques, copilote commercial sur l'historique CRM.

La raison du succès : un RAG bien construit délivre des réponses 5-10x plus fiables qu'un LLM seul, avec sources citées, à un coût marginal. Et surtout, il évolue avec vos données — vous n'avez pas besoin de réentraîner un modèle à chaque mise à jour.

Un RAG no-code se décompose en deux pipelines distincts :

**Pipeline d'ingestion** (asynchrone, schedulé) : 1. Récupération des documents source (Notion, Drive, base SQL, etc.) 2. Chunking : découpage en morceaux de 500-800 tokens 3. Embedding : conversion de chaque chunk en vecteur via OpenAI ou Cohere 4. Stockage dans une vector DB (Pinecone, Qdrant, pgvector)

**Pipeline de requête** (synchrone, à chaque question) : 1. Embedding de la question utilisateur 2. Recherche des N chunks les plus similaires (cosine similarity) 3. Optionnel : re-ranking pour ne garder que les 3-5 meilleurs 4. Envoi de la question + chunks à GPT/Claude 5. Génération de la réponse avec sources citées

En no-code, n8n est le meilleur orchestrateur en 2026 grâce à ses nœuds natifs vector store, embeddings et AI Agent. Make peut le faire aussi mais avec plus de modules custom.

Le chunking est l'étape la plus critique du RAG. Un mauvais chunking ruine la qualité du retrieval, peu importe la qualité du modèle.

**Trois règles essentielles :**

1. **Découpage sémantique, pas mécanique.** Découper tous les 500 tokens sans regard du contenu coupe au milieu d'un paragraphe ou d'une idée. Préférez un découpage sur les frontières naturelles : titres H2/H3, paragraphes, sections logiques.

2. **Taille adaptée au cas d'usage.** Pour des FAQ ou docs courts : 200-400 tokens. Pour des contrats ou docs longs : 800-1200 tokens. Trop petit = manque de contexte. Trop grand = bruit qui dilue la pertinence.

3. **Overlap entre chunks.** Ajoutez 10-15% de chevauchement entre chunks adjacents. Évite de couper une information critique pile à la frontière.

**Métadonnées riches** : enrichissez chaque chunk avec title, section, source_url, last_modified, author. Souvent ces métadonnées sont plus utiles que le contenu pour filtrer la recherche.

**Pièges à éviter :** ne pas chunker les tableaux (les garder entiers), ne pas ignorer les listes (préserver la structure), ne pas dupliquer des chunks identiques (déduplication par hash).

Le marché s'est ouvert. Quatre options dominantes en 2026 :

**Pinecone** — la référence managée. Simple, performante, scalable. Cher dès qu'on dépasse 1M de vecteurs. Idéale pour démarrer sans gérer l'infra.

**Qdrant** — open source, self-host ou cloud managé. Performances excellentes, support hybrid search natif. Le choix qui monte vite côté tech-friendly.

**Weaviate** — hybride avec hybrid search et modules ML intégrés. Bonne option si vous voulez du tout-en-un.

**pgvector** (extension PostgreSQL) — gratuit, intégré à votre base SQL existante. Suffisant pour < 1M documents et bien plus simple à opérer si vous avez déjà PostgreSQL. Notre choix par défaut pour les PME en 2026.

**Critères de choix** : volume (< 100k → pgvector, 100k-10M → Qdrant ou Pinecone, > 10M → Pinecone enterprise), souveraineté (Qdrant ou pgvector self-host pour RGPD strict), équipe (managé si pas d'ops, self-host si oui).

**Hybrid search** : combinez recherche vectorielle (similarité sémantique) ET recherche lexicale (BM25 sur les mots-clés). Le sémantique trouve les concepts proches, le lexical trouve les correspondances exactes. La combinaison double la précision dans 80% des cas. Natif sur Weaviate, Qdrant, Elasticsearch.

**Re-ranking** : récupérez 20 chunks par similarité vectorielle, puis re-rankez avec un cross-encoder (Cohere Rerank, Jina Rerank) pour ne garder que les 3-5 meilleurs avant de les envoyer au LLM. Gain de précision : +30 à +50%, coût marginal (0.001-0.002$ par requête).

**Filtrage par métadonnées** : avant la recherche vectorielle, filtrez par date, source, département, droits d'accès. Réduit drastiquement le bruit et accélère le retrieval.

**Multi-query expansion** : pour les questions complexes, demandez à GPT de générer 3 reformulations de la question, faites une recherche pour chaque, et agrégez les résultats. +20-30% de rappel sur les questions ambiguës.

Le prompt envoyé au LLM est aussi critique que le retrieval. Trois règles :

**1. Forcer la sourcing.** Instruction explicite : "Tu réponds UNIQUEMENT avec les sources fournies. Si la réponse n'y est pas, dis 'Je ne sais pas'. Cite chaque affirmation avec [Source N]."

**2. Donner le format de sortie.** "Format : réponse en 3 phrases max + liste des sources cliquées avec URLs."

**3. Mentionner le contexte business.** "Tu es l'assistant interne de l'équipe support de [entreprise]. Ton de réponse : professionnel mais accessible."

**Choix du modèle** : GPT-4o-mini suffit pour 80% des cas RAG (les chunks contiennent déjà la réponse, le modèle ne fait que la formuler). GPT-4o ou Claude 3.5 Sonnet pour les cas qui demandent un vrai raisonnement (juridique, finance).

**Coût type** : avec GPT-4o-mini, 4 chunks injectés et 200 tokens de sortie : ~0.001€ par requête.

Le RAG est un système qui se dégrade silencieusement si vous ne le surveillez pas. Trois métriques à tracker dès le jour 1 :

**1. Taux de réponse correcte** : construisez un dataset d'évaluation de 50-200 questions avec réponses attendues. Mesurez chaque mois. Objectif : >85%.

**2. Taux d'hallucination** : pourcentage de réponses contenant une info absente des sources. Objectif : <3%. Détectable via grading LLM (Claude juge la réponse de GPT) ou échantillonnage humain.

**3. Coût et latence** : tokens consommés par requête, temps de réponse P50/P95. Doit rester stable.

**Feedback loop utilisateur** : ajoutez 👍/👎 sur chaque réponse. Stockez les 👎 pour analyse et amélioration du retrieval (souvent le problème vient des chunks récupérés, pas du modèle).

Sans évaluation, votre RAG va se dégrader avec l'ajout de nouvelles données et personne ne le verra. C'est l'erreur n°1 en production.