RAG expliqué : faire parler l'IA sur vos données

"On voudrait un ChatGPT qui connaît nos produits, nos process, nos docs internes." C'est la demande n°1 que je reçois. La réponse technique s'appelle RAG — et c'est plus simple que vous ne pensez.

Le problème : les LLM ne connaissent pas vos données

GPT-4, Claude, Mistral... ces modèles sont entraînés sur des données publiques. Ils ne connaissent pas :

• Vos produits et services spécifiques
• Vos procédures internes
• Votre documentation technique
• Vos échanges clients passés

Résultat : si vous demandez "Quel est le délai de livraison pour le produit X ?", le LLM va inventer une réponse (hallucination) ou avouer qu'il ne sait pas.

La solution naïve : le fine-tuning

Première idée : réentraîner le modèle sur vos données. Spoiler : c'est rarement la bonne approche.

Pourquoi ?

• Coût : plusieurs milliers d'euros minimum
• Temps : plusieurs semaines de préparation + entraînement
• Maintenance : à refaire à chaque mise à jour de vos données
• Risque : le modèle peut "oublier" ses capacités générales

Le fine-tuning est pertinent pour modifier le style de réponse, pas pour injecter des connaissances factuelles.

La bonne solution : le RAG

RAG = Retrieval Augmented Generation. L'idée est simple :

1. L'utilisateur pose une question
2. On cherche les documents pertinents dans votre base
3. On envoie question + documents au LLM
4. Le LLM répond en se basant sur les documents fournis

Schéma d'architecture RAG

Question utilisateur
        │
        ▼
┌───────────────────┐
│  Vectorisation    │  ← Transformation en embedding
│  de la question   │
└───────────────────┘
        │
        ▼
┌───────────────────┐
│  Recherche        │  ← Similarité cosinus
│  vectorielle      │
└───────────────────┘
        │
        ▼
┌───────────────────┐
│  Documents        │  ← Top 5-10 chunks pertinents
│  pertinents       │
└───────────────────┘
        │
        ▼
┌───────────────────┐
│  LLM + Contexte   │  ← "Réponds en te basant sur..."
│                   │
└───────────────────┘
        │
        ▼
    Réponse sourcée

Les composants techniques

1. Chunking : découper vos documents

On ne peut pas envoyer un PDF de 200 pages au LLM. Il faut découper en "chunks" de 500-1000 tokens.

Point critique : le découpage doit respecter le sens. Couper au milieu d'une phrase = mauvais résultats. Je recommande un overlap de 10-20% entre chunks.

2. Embeddings : vectoriser le texte

Chaque chunk est transformé en vecteur (liste de nombres) qui capture son "sens". Modèles courants : OpenAI text-embedding-3, Cohere, ou open source (sentence-transformers).

3. Base vectorielle : stocker et chercher

Options populaires :

• Pinecone : managed, simple, cher à l'échelle
• Weaviate : open source, très complet
• Qdrant : open source, performant
• pgvector : extension PostgreSQL, idéal si vous avez déjà Postgres

4. Prompt engineering : guider le LLM

Le prompt est crucial. Exemple de structure que j'utilise :

Tu es un assistant expert de [entreprise].
Réponds uniquement en te basant sur les documents fournis.
Si l'information n'est pas dans les documents, dis-le clairement.

DOCUMENTS :
{chunks pertinents}

QUESTION :
{question utilisateur}

RÉPONSE :

Erreurs courantes à éviter

❌ Trop de documents = confusion

Si vous envoyez 50 chunks au LLM, il va se perdre. Visez 3-7 chunks maximum, les plus pertinents.

❌ Ignorer les métadonnées

Un chunk sans contexte est peu utile. Ajoutez : nom du document source, date, catégorie, auteur.

❌ Pas de feedback loop

Collectez les questions sans réponse satisfaisante. Ce sont vos trous documentaires à combler.

Stack que je recommande en 2025

• Embeddings : OpenAI text-embedding-3-small (rapport qualité/prix)
• Base vectorielle : Qdrant (auto-hébergé) ou Pinecone (managed)
• LLM : Claude 3 Sonnet (contexte long) ou GPT-4 Turbo
• Orchestration : LangChain ou LlamaIndex