RAG : comment un agent IA apprend vos données

Vos équipes passent 2h par jour à chercher des réponses dans des PDFs, des pages Notion et des wikis Confluence. Vous avez essayé ChatGPT. Il invente des réponses parce qu'il ne connaît pas vos données internes. Le problème n'est pas le modèle. C'est l'absence de contexte.

Le RAG -- Retrieval Augmented Generation -- résout exactement ce problème. Au lieu de tout mémoriser, l'IA cherche dans vos documents au moment de répondre. Pas de formation coûteuse du modèle. Pas d'hallucinations sur vos données métier. Juste une recherche intelligente couplée à la génération de texte.

Chez Algomax, nous avons déployé des systèmes RAG pour des entreprises de 20 à 500 employés. Cet article vous explique comment ça fonctionne, ce que ça coûte, et surtout où ça coince.

Pourquoi pas simplement entraîner le modèle ?

La question revient à chaque appel découverte. "On ne peut pas juste donner nos documents à GPT pour qu'il apprenne ?"

Techniquement, oui. Ça s'appelle le fine-tuning. Et dans 90 % des cas, c'est la mauvaise approche pour des données d'entreprise. Voici pourquoi.

Le fine-tuning modifie les poids du modèle. Vous payez l'entraînement (plusieurs centaines de dollars par session), vous attendez des heures, et dès que vos documents changent, vous recommencez. Pour une base de connaissances qui évolue chaque semaine, c'est un gouffre.

Le RAG ne modifie rien dans le modèle. Il ajoute une étape de recherche avant la génération. Vos documents sont indexés dans une base de données vectorielle. Quand un utilisateur pose une question, le système retrouve les passages pertinents et les injecte dans le prompt. Le modèle répond en s'appuyant sur ces extraits.

Les avantages concrets :

• Mise à jour instantanée. Un nouveau document ? Il est indexé en quelques secondes et disponible immédiatement.
• Traçabilité. Chaque réponse peut citer sa source. Vous savez d'où vient l'information.
• Coût prévisible. L'indexation coûte environ 0,10 $ par million de tokens. Indexer 10 000 pages de documentation revient à moins de 5 $.
• Pas de dégradation. Le fine-tuning peut dégrader les capacités générales du modèle. Le RAG n'y touche pas.

Le fine-tuning reste pertinent pour modifier le style ou le comportement du modèle. Mais pour connecter une IA à vos données, le RAG est plus rapide, moins cher et plus fiable.

Comment ça fonctionne, étape par étape

Derrière le terme RAG, il y a un pipeline en six étapes. Aucune n'est optionnelle.

1. Ingestion des documents

Première étape : collecter vos données. PDFs, pages Notion, articles Confluence, tickets Zendesk, emails archivés, fichiers Google Docs. Chaque source nécessite un connecteur spécifique pour extraire le texte brut.

C'est souvent la partie la plus sous-estimée. Un PDF scanné sans OCR ne contient aucun texte exploitable. Un export Confluence mal formaté perd ses tableaux. Nous passons typiquement 30 % du temps projet sur cette étape.

2. Découpage en chunks

Un document de 50 pages ne rentre pas dans le contexte d'un LLM. Il faut le découper en morceaux -- des "chunks" -- de taille exploitable.

La taille standard : entre 500 et 1 500 tokens par chunk. Trop petit, vous perdez le contexte. Trop grand, vous diluez la pertinence de la recherche. Nous utilisons un découpage avec chevauchement (overlap de 10-15 %) pour éviter de couper une idée en deux.

Le découpage intelligent tient aussi compte de la structure : titres, paragraphes, listes. Un chunk qui commence au milieu d'une phrase est un chunk inutile.

3. Transformation en embeddings

Chaque chunk est converti en un vecteur numérique -- une liste de 1 536 nombres (avec le modèle text-embedding-3-small d'OpenAI, par exemple). Ces vecteurs capturent le sens sémantique du texte.

Deux phrases qui disent la même chose avec des mots différents auront des vecteurs proches. "Notre politique de remboursement" et "comment se faire rembourser" pointent vers la même zone dans l'espace vectoriel.

Le coût est négligeable : environ 0,02 $ pour un million de tokens avec les modèles récents. Indexer toute la documentation d'une PME coûte rarement plus de 1 $.

4. Stockage dans une base vectorielle

Les vecteurs sont stockés dans une base de données spécialisée. Pas MySQL. Pas PostgreSQL (bien que pgvector existe). Une base conçue pour la recherche de similarité sur des vecteurs à haute dimension.

Les options que nous utilisons chez Algomax :

• Pinecone : hébergé, simple à déployer, 20 $/mois pour démarrer. Idéal pour un premier projet.
• Qdrant : open source, auto-hébergeable, plus de contrôle. Nous le recommandons quand les données sont sensibles.
• pgvector : extension PostgreSQL, pratique si vous voulez tout garder dans une seule base. Performances acceptables jusqu'à quelques centaines de milliers de chunks.

Pour une base de connaissances de 5 000 à 50 000 documents, comptez entre 20 et 100 $ par mois d'hébergement vectoriel.

5. Recherche (retrieval)

Quand un utilisateur pose une question, elle est convertie en vecteur avec le même modèle d'embedding. La base vectorielle retourne les 3 à 10 chunks les plus proches sémantiquement.

C'est ici que la qualité se joue. Un bon retrieval retourne les passages réellement pertinents. Un mauvais retrieval noie le modèle dans du bruit.

Nous ajoutons souvent une étape de re-ranking : un second modèle, plus petit, qui reclasse les résultats par pertinence. Le gain est mesurable -- on passe typiquement de 70 % à 85 % de pertinence sur les 3 premiers résultats.

6. Génération de la réponse

Les chunks récupérés sont injectés dans le prompt du LLM avec la question de l'utilisateur. Le modèle génère une réponse en s'appuyant sur ces extraits.

Le prompt est structuré pour forcer le modèle à citer ses sources et à dire "je ne sais pas" quand l'information n'est pas dans les documents fournis. Sans cette contrainte, le modèle invente. Avec elle, le taux d'hallucination sur les données internes tombe sous les 5 %.

Exemple concret : un bot FAQ sur vos documents internes

Un de nos clients -- une entreprise SaaS de 80 personnes -- avait 400 pages de documentation produit réparties entre Notion et Google Docs. Leur équipe support répondait aux mêmes questions 15 fois par jour.

Nous avons déployé un agent IA sur mesure connecté à leur base documentaire. Le pipeline :

1. Connecteurs Notion et Google Docs avec synchronisation toutes les 15 minutes
2. Découpage en chunks de 800 tokens avec overlap de 100 tokens
3. Embeddings via text-embedding-3-small d'OpenAI
4. Stockage dans Qdrant auto-hébergé (données sensibles)
5. Re-ranking avec Cohere Rerank
6. Génération avec Claude d'Anthropic

Résultat : 73 % des questions support traitées sans intervention humaine. Le bot cite systématiquement la page source. Quand il ne trouve pas la réponse, il escalade vers un humain au lieu d'inventer.

Le projet a pris 3 semaines. Le coût d'exploitation : environ 150 $/mois tout compris (embeddings + vector DB + API LLM). C'est le même principe que pour automatiser un service client avec un agent IA, mais appliqué à la documentation interne.

Notre stack technique

Chez Algomax, nous construisons les pipelines RAG en Node.js/TypeScript. Le choix est pragmatique : c'est le même langage que le reste de l'application de nos clients, ce qui simplifie la maintenance.

• LLM : Claude (Anthropic) ou GPT-4o (OpenAI) selon le cas d'usage. Claude excelle sur les documents longs. GPT-4o est plus rapide pour les réponses courtes.
• Embeddings : text-embedding-3-small d'OpenAI pour le rapport qualité/prix. text-embedding-3-large quand la précision justifie le surcoût.
• Vector DB : Qdrant pour les projets sensibles, Pinecone pour les déploiements rapides.
• Orchestration : LangChain ou appels directs aux APIs selon la complexité. Nous évitons LangChain quand le pipeline est simple -- c'est une abstraction qui ajoute de la complexité sans bénéfice sur les cas basiques.

Les limites que personne ne mentionne

Le RAG n'est pas magique. Voici ce qui coince en production.

La qualité dépend de vos données. Si votre documentation est obsolète, contradictoire ou mal structurée, le RAG va fidèlement retourner des informations obsolètes, contradictoires ou mal structurées. Garbage in, garbage out. Nous recommandons un audit de la base documentaire avant tout déploiement.

Le chunking est un compromis permanent. Des chunks courts améliorent la précision de la recherche mais perdent le contexte. Des chunks longs gardent le contexte mais diluent la pertinence. Il n'y a pas de taille universelle -- chaque base documentaire nécessite des tests.

Les requêtes multi-hop sont difficiles. "Quel client a le contrat le plus élevé dans la région Ouest et quand expire-t-il ?" Cette question nécessite de croiser plusieurs documents. Le RAG basique ne sait pas faire ça. Il faut ajouter des agents avec des étapes de raisonnement, ce qui complexifie le système.

Le multilingue reste un défi. Les embeddings fonctionnent mieux en anglais. Une base documentaire en français avec des termes techniques spécifiques à votre industrie donnera des résultats moins précis. Les modèles multilingues progressent, mais l'écart existe encore.

La latence s'additionne. Embedding de la question (50 ms) + recherche vectorielle (100 ms) + re-ranking (200 ms) + génération LLM (1-3 s). Comptez 2 à 4 secondes pour une réponse complète. C'est acceptable pour un chatbot, moins pour une API temps réel.

Quand le RAG ne suffit pas

Le RAG excelle pour retrouver et synthétiser de l'information existante. Il atteint ses limites quand vous avez besoin de :

• Raisonnement complexe sur des données structurées (utilisez SQL + LLM)
• Calculs à partir de vos données (le LLM n'est pas une calculatrice fiable)
• Actions dans vos systèmes (il faut un agent avec des outils, pas juste du RAG)
• Analyse de tendances sur des séries temporelles (utilisez des outils analytiques classiques)

Dans ces cas, le RAG devient un composant d'une architecture plus large, pas la solution complète.

Par où commencer

Si vous envisagez un système RAG pour votre entreprise, commencez par trois questions :

1. Vos documents sont-ils numériques et à jour ?
2. Les questions de vos utilisateurs trouvent-elles réponse dans ces documents ?
3. Le volume de questions justifie-t-il l'investissement (même modeste) ?

Si oui aux trois, un premier prototype est déployable en une à deux semaines. Nous proposons des agents IA sur mesure qui intègrent le RAG comme brique de base. Le plus dur n'est pas la technologie. C'est la qualité de vos données.