"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

  • Embeddings : OpenAI text-embedding-3-small (rapport qualité/prix imbattable) ou voyage-3 / jina-v3 si vous voulez tester du multilingue plus poussé. Modèle français à considérer pour les cas RGPD : bge-multilingual-gemma2 auto-hébergé.
  • Base vectorielle :
    • pgvector sur PostgreSQL si vous avez déjà Postgres (90% des cas, mon premier choix)
    • Qdrant ou Weaviate si vous voulez du dédié, auto-hébergeable
    • LanceDB pour les petits projets embarqués
  • LLM : Claude 3.5 Sonnet ou Claude 4 (contexte long, qualité) ; GPT-4o (intégration) ; Mistral Medium 3 (souveraineté) ; DeepSeek-V3 via provider managé (coût/perf).
  • Re-ranking (étape souvent oubliée mais cruciale) : Cohere Rerank ou bge-reranker-v2 auto-hébergé. Vous récupérez 20 chunks par similarité, le re-ranker garde les 5 vraiment pertinents.
  • Orchestration : LangChain et LlamaIndex restent les références, mais en 2026 j\'écris de plus en plus le code de pipeline RAG sans framework (juste OpenAI/Anthropic SDK + quelques fonctions utilitaires). Plus simple à débugger, plus performant.
  • Évaluation : Ragas, DeepEval ou un petit harness maison avec 30-50 questions/réponses de référence. Ne pas négliger cette étape.
Projet RAG en vue ? Je propose des POC en 2-3 semaines : on teste sur un échantillon de vos docs, on mesure la qualité des réponses, et on décide ensemble si ça vaut le coup d'industrialiser.

Cet article vous a été utile ?