RAG Expliqué pour les Founders : Comment Donner du Contexte Métier à un LLM

Vous avez essayé ChatGPT pour votre business. C'est impressionnant — jusqu'à ce que vous lui posiez des questions sur VOS clients, VOS produits, VOS processus internes. Là, il se met à inventer. Des noms faux, des données qui n'existent pas, des politiques que vous n'avez jamais eues. Il hallucine parce qu'il n'a pas vos données.

Ce n'est pas un bug. C'est une limitation fondamentale. GPT-4o, Claude 3.5, Llama 3.1 — tous les LLMs ont un savoir général énorme mais zéro connaissance de votre entreprise. Ils ne savent pas qui sont vos clients, ce que dit votre documentation interne ni quelles sont vos politiques de retour.

La bonne nouvelle : il existe une solution qui ne nécessite pas de réentraîner un modèle. Ça s'appelle RAG. Et c'est probablement la technique d'IA la plus pertinente pour votre startup en ce moment.

Le problème : un LLM généraliste ne connaît pas votre business

Pensez à un LLM comme un employé extrêmement intelligent qui sait un peu de tout mais qui vient d'arriver dans votre entreprise. Il sait coder, écrire, analyser des données — mais il n'a pas accès à votre wiki interne, votre CRM, vos contrats ni votre base de connaissances.

Si vous lui demandez "quelle est notre politique de remboursement pour les clients enterprise ?", il va inventer une réponse qui semble plausible. Non pas parce qu'il est malhonnête, mais parce qu'il n'a pas d'autre choix. Il comble les lacunes avec des probabilités, pas des faits.

Le fine-tuning (réentraîner le modèle avec vos données) semble être la solution évidente, mais il a des problèmes sérieux : c'est cher, ça nécessite une expertise spécialisée, les données deviennent obsolètes rapidement et il faut répéter le processus à chaque fois que vos informations changent.

C'est là qu'intervient RAG.

Qu'est-ce que RAG et pourquoi c'est important

RAG (Retrieval-Augmented Generation) est une technique qui donne au LLM accès à vos documents au moment de répondre à une question. Vous ne réentraînez pas le modèle. À la place, vous lui passez l'information pertinente comme contexte en même temps que la question de l'utilisateur.

C'est comme donner à ce nouvel employé accès aux archives de l'entreprise avant qu'il ne réponde à chaque question. Le modèle reste le même, mais il a maintenant des données réelles sur lesquelles travailler.

Le concept est simple. L'implémentation a des subtilités, mais ce n'est pas sorcier. N'importe quelle équipe d'ingénierie senior peut construire un système RAG fonctionnel en quelques semaines.

Comment fonctionne RAG : les 3 étapes

Étape 1 : Indexez vos données

Prenez les documents que vous voulez que le LLM puisse consulter : PDF, wikis, bases de données, emails, documentation technique, tickets de support. Tout ce qui est pertinent.

Chaque document est divisé en chunks (fragments). Un chunk peut être un paragraphe, une section, une page — ça dépend de votre cas d'usage. Ensuite, chaque chunk est converti en un embedding : une représentation numérique (un vecteur) qui capture le sens sémantique du texte.

Vous n'avez pas besoin de comprendre les mathématiques derrière les embeddings. L'important est que deux textes avec un sens similaire auront des embeddings proches. "Politique de retour pour les clients premium" et "remboursement pour les comptes enterprise" auront des vecteurs similaires, même s'ils utilisent des mots différents.

Étape 2 : Stockez les embeddings

Ces vecteurs sont stockés dans une base de données vectorielle. Les options les plus courantes :

• Pinecone : managed, facile pour démarrer, scale bien.
• Weaviate : open source, très flexible.
• Qdrant : open source, excellentes performances.
• pgvector : extension de PostgreSQL. Si vous utilisez déjà Postgres, vous pouvez démarrer sans ajouter de nouvelle infrastructure.

Pour la plupart des startups, pgvector est l'option la plus pragmatique. Vous avez déjà PostgreSQL. Ajouter une extension est bien plus simple que gérer une nouvelle base de données.

Étape 3 : Requêtes en temps réel

Quand un utilisateur pose une question :

1. La question est convertie en embedding (même processus que pour les documents).
2. Les chunks les plus similaires sont recherchés dans la base de données vectorielle — les fragments de vos documents dont le sens est le plus proche de la question.
3. Ces chunks sont injectés dans le prompt du LLM comme contexte : "En te basant sur les informations suivantes, réponds à la question de l'utilisateur : [chunks pertinents]".
4. Le LLM génère une réponse en utilisant VOS données, pas ses connaissances générales.

Le résultat : des réponses fondées sur l'information réelle de votre entreprise. Pas d'hallucinations. Pas d'inventions.

Quand implémenter RAG a du sens

RAG n'est pas la solution à tout, mais c'est la bonne solution pour de nombreux cas d'usage courants dans les startups :

• Bases de connaissances internes : des employés qui consultent la documentation, les processus, les politiques.
• Chatbots de support client : des réponses basées sur votre documentation réelle, pas sur les connaissances générales du modèle.
• Recherche dans les documents : trouver de l'information pertinente dans des milliers de documents juridiques, techniques ou financiers.
• Requêtes de conformité : répondre à des questions réglementaires en utilisant votre documentation de conformité.
• Sales enablement : donner à votre équipe commerciale des réponses précises sur les produits, les prix et les comparatifs avec la concurrence.

Le pattern commun : vous avez un corpus de documents que vos utilisateurs (internes ou externes) doivent consulter, et vous voulez une interface conversationnelle qui donne des réponses précises.

Quand RAG n'est PAS suffisant

Il y a des limites. Il est important de les connaître avant de commencer :

• Quand vous avez besoin que le modèle apprenne de nouveaux patterns. RAG donne du contexte, pas de l'apprentissage. Si vous avez besoin que le modèle classifie des tickets de support selon des catégories spécifiques à votre entreprise, vous aurez peut-être besoin de fine-tuning.
• Quand les données changent en temps réel. RAG fonctionne bien avec des documents mis à jour périodiquement (quotidiennement ou hebdomadairement). Si vous avez besoin de données à la seconde — cotations boursières, inventaire en temps réel — vous avez besoin d'un pipeline de streaming, pas seulement de RAG.
• Quand la précision doit être de 100 %. RAG améliore énormément la précision, mais ne la garantit pas à 100 %. Pour les décisions médicales, les avis juridiques contraignants ou les décisions financières à haut risque, vous avez besoin d'une validation humaine dans la boucle.

Erreurs courantes à éviter

J'ai vu ces erreurs se répéter dans presque toutes les équipes qui implémentent RAG pour la première fois :

Des chunks trop grands. Si chaque chunk est un document entier de 20 pages, vous injectez beaucoup de bruit dans le prompt. Le LLM reçoit trop d'information non pertinente et la qualité de la réponse baisse. Des chunks de 200-500 tokens sont généralement un bon point de départ.

Des chunks trop petits. L'extrême opposé : des fragments d'une seule phrase perdent le contexte. Si un chunk dit "la limite est de 30 jours" mais ne précise pas "pour les remboursements de clients enterprise", la réponse sera incomplète. Vous avez besoin d'un équilibre entre spécificité et contexte.

Pas de pipeline d'évaluation. Vous implémentez RAG, "ça marche", et vous le mettez en production. Mais comment savez-vous si le système trouve vraiment les bons documents ? Comment mesurez-vous si les réponses sont précises ? Vous avez besoin de métriques : relevance score, faithfulness, answer correctness. Sans évaluation, vous volez à l'aveugle.

Pas de filtrage par pertinence. Parfois la base de données vectorielle renvoie les chunks "les plus similaires", mais aucun n'est vraiment pertinent. Si le score de similarité est bas, il vaut mieux que le système dise "je n'ai pas d'information à ce sujet" plutôt que de forcer une réponse avec des données tangentiellement liées.

Compter sur le LLM pour dire "je ne sais pas". Les LLMs sont extrêmement mauvais pour dire "je ne sais pas". Même avec du contexte RAG, si la réponse n'est pas dans les documents, beaucoup de modèles essaieront quand même de répondre. Vous avez besoin de guardrails explicites dans votre système pour gérer ces cas.

Build vs buy : la décision pratique

Vous avez deux chemins :

Frameworks existants : LangChain et LlamaIndex sont les plus populaires. Ils vous donnent des composants pré-construits pour le chunking, l'embedding, la retrieval et la génération. Ils accélèrent le développement initial, mais ajoutent des dépendances et parfois de l'abstraction inutile.

Pipeline custom : vous construisez chaque composant séparément. Plus de travail initial, mais un contrôle total. Pour des cas d'usage simples (un chatbot sur votre documentation), un pipeline custom avec pgvector et l'API d'OpenAI ou d'Anthropic peut être plus simple qu'un framework.

Ma recommandation : commencez avec un pipeline simple et custom. Si la complexité augmente (sources de données multiples, re-ranking avancé, hybrid search), alors évaluez un framework. Ne commencez pas par la solution la plus complexe.

Qui devrait construire votre système RAG

RAG est conceptuellement simple mais les détails d'implémentation comptent énormément. Stratégie de chunking, sélection du modèle d'embedding, tuning de la retrieval, prompt engineering, évaluation — chaque décision affecte la qualité du résultat final.

Vous n'avez pas besoin d'une équipe de chercheurs en IA. Vous avez besoin d'ingénieurs senior qui ont construit des systèmes RAG en production et qui savent où sont les pièges. Qui ont itéré sur des stratégies de chunking, testé différents modèles d'embedding et construit de vrais pipelines d'évaluation.

Chez Conectia, les ingénieurs que nous validons pour les projets d'IA ont travaillé sur de véritables implémentations de RAG — pas des démos ou des tutoriels. Ils connaissent la différence entre un prototype qui fonctionne dans un notebook et un système qui fonctionne en production avec de vraies données, à l'échelle, et avec des utilisateurs qui posent des questions qui n'étaient pas dans le plan initial.

Si vous évaluez RAG pour votre produit, la différence entre un bon résultat et une mauvaise expérience utilisateur tient à l'expérience de l'équipe qui le construit. Un ingénieur senior avec de l'expérience en RAG peut vous faire gagner des mois d'itération et des erreurs que quelqu'un a déjà commises avant.

---

Vous voulez implémenter RAG dans votre produit mais vous n'avez pas l'équipe avec l'expérience en production ? Parlez à un CTO — nous vous connectons avec des ingénieurs senior qui ont déjà construit de vrais systèmes RAG, prêts à s'intégrer en 72 heures.