Vous avez déployé un système RAG (assistant IA sur vos documents) mais les réponses sont parfois hors sujet, incomplètes ou imprécises ? Avant de remettre en question toute l'architecture, regardez deux paramètres souvent négligés : le chunking (découpage des documents) et le modèle d'embedding (transformation en vecteurs). Ce guide vous explique, en termes accessibles, comment ces deux leviers peuvent transformer un RAG médiocre en outil performant.
Réponse directe
Pour améliorer un RAG, commencez par le chunking : chunks de 500-1000 tokens avec 10-20% d'overlap, en respectant la structure du document. Ensuite, testez différents modèles d'embedding (text-embedding-3-small, BGE, E5) sur vos données réelles.
Comprendre le RAG en 2 minutes (pour les non-techniciens)
Avant d'entrer dans les détails, rappelons comment fonctionne un RAG :
- Préparation : vos documents (PDF, Word, etc.) sont découpés en morceaux (chunks) et convertis en représentations numériques (embeddings)
- Recherche : quand un utilisateur pose une question, le système cherche les morceaux les plus pertinents
- Génération : l'IA génère une réponse en s'appuyant sur ces morceaux
L'analogie simple : imaginez un bibliothécaire qui découpe vos livres en fiches, les classe par thème, puis retrouve les fiches pertinentes quand vous posez une question. Si les fiches sont mal découpées (moitié d'une phrase sur chaque fiche) ou mal classées, le bibliothécaire ne pourra pas vous aider correctement.
Le chunking, c'est la qualité du découpage. L'embedding, c'est la qualité du classement.
Pourquoi le chunking est-il si important ?
Le chunking détermine ce que le RAG peut "retrouver". C'est souvent LA différence entre un RAG qui fonctionne et un RAG qui frustre les utilisateurs.
Les symptômes d'un mauvais chunking
- Réponses incomplètes : l'IA commence à répondre mais il manque des informations clés
- Réponses hors sujet : l'IA répond à côté de la question
- Incohérences : l'IA mélange des informations de différentes sections
- "Je ne trouve pas l'information" : alors que vous savez qu'elle existe dans les documents
Les erreurs classiques de chunking
- Chunks trop petits (< 200 tokens) : le contexte est perdu. Une phrase isolée comme "Le délai est de 30 jours" n'a pas de sens sans savoir de quel délai on parle.
- Chunks trop grands (> 2000 tokens) : trop de bruit. Le modèle reçoit 2 pages de texte dont seulement 3 lignes sont pertinentes, et se perd dans l'information.
- Découpage au milieu des phrases : "Les conditions de retour sont les suivantes :" sur un chunk, et la liste des conditions sur le chunk suivant.
- Ignorer la structure du document : mélanger l'introduction et la conclusion dans le même chunk parce que le découpage est purement mécanique.
Stratégies de chunking
Il existe plusieurs approches pour découper vos documents. Le choix dépend du type de contenu et de vos contraintes.
1. Chunking par taille fixe (le plus courant)
Le plus simple : découper tous les X tokens (ou caractères). C'est l'approche par défaut de la plupart des outils.
from langchain.text_splitter import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
chunk_size=1000, # ~250 tokens
chunk_overlap=200, # 20% d'overlap
separators=["\n\n", "\n", ". ", " "]
)
chunks = splitter.split_text(document)
Recommandation pour les dirigeants : demandez à votre équipe technique de configurer des chunks de 500-1000 tokens avec 10-20% d'overlap (chevauchement entre chunks pour ne pas couper les idées). C'est un bon point de départ.
Qu'est-ce que l'overlap ? C'est le fait de faire "déborder" chaque chunk sur le suivant. Si chunk 1 se termine par "...les conditions de retour sont les suivantes", le chunk 2 commence par "les conditions de retour sont les suivantes : 30 jours...". Ainsi, le contexte n'est pas perdu.
2. Chunking sémantique (plus intelligent)
Au lieu de découper mécaniquement tous les 1000 caractères, on respecte la structure du document : titres, sections, paragraphes.
- Documents Word/Markdown : découper par titres (Titre 1, Titre 2, etc.)
- PDF structurés : utiliser des outils comme Unstructured ou PyMuPDF qui détectent les sections
- Pages web : découper par balises HTML structurantes
Avantage : chaque chunk contient une unité de sens complète (une section, une procédure, un article).
Inconvénient : plus complexe à mettre en place, dépend de la qualité de la structure du document.
3. Chunking par phrase/paragraphe
Respecte les frontières naturelles du texte : on ne coupe jamais au milieu d'une phrase. Utile pour les documents bien rédigés avec des paragraphes courts.
4. Chunking hybride (notre recommandation)
La combinaison des approches : respecter la structure du document (sections, paragraphes) + limite de taille maximale + overlap.
En pratique : "Découpe par section, mais si une section fait plus de 1000 tokens, subdivise-la par paragraphe. Et garde toujours 100 tokens de chevauchement."
Comment choisir ?
| Type de document | Stratégie recommandée |
|---|---|
| FAQ, Q&R | 1 chunk = 1 question-réponse |
| Manuels techniques structurés | Chunking sémantique par section |
| Contrats, documents légaux | Chunking par article/clause |
| Emails, notes non structurées | Taille fixe avec overlap |
| Mélange de formats | Hybride adapté par type |
Les embeddings : le "classement" de vos documents
Une fois vos documents découpés en chunks, il faut les "classer" pour pouvoir les retrouver. C'est le rôle des embeddings.
Qu'est-ce qu'un embedding ? (explication simple)
Un embedding, c'est une représentation numérique du sens d'un texte. Imaginez que chaque chunk reçoive une "adresse" dans un espace à plusieurs dimensions, où les textes au sens similaire ont des adresses proches.
Exemple concret :
- "Comment retourner un produit ?" et "Quelle est la procédure de retour ?" auront des embeddings très proches (même sens)
- "Comment retourner un produit ?" et "Heures d'ouverture du magasin" auront des embeddings éloignés (sens différent)
Quand un utilisateur pose une question, sa question est aussi convertie en embedding, et le système cherche les chunks dont les embeddings sont les plus proches.
Pour le dirigeant : le choix du modèle d'embedding est un paramètre technique que votre équipe doit optimiser. Ce qu'il faut retenir : un mauvais modèle d'embedding = des résultats de recherche non pertinents, même avec un bon chunking.
Modèles populaires en 2025
| Modèle | Dimensions | Usage |
|---|---|---|
| OpenAI text-embedding-3-small | 1536 | API cloud, excellent rapport qualité/prix |
| OpenAI text-embedding-3-large | 3072 | Meilleure qualité, plus coûteux |
| BGE-large-en-v1.5 | 1024 | Open-source, déploiement local |
| E5-large-v2 | 1024 | Open-source, très bon en multilingue |
| CamemBERT / FlauBERT | 768 | Français spécifique |
Comment choisir ?
- Cloud + simplicité : OpenAI text-embedding-3-small
- On-prem / souveraineté : BGE ou E5 (déployables localement)
- Français uniquement : tester CamemBERT vs E5-multilingual
Attention
Ne changez pas de modèle d'embedding après avoir indexé vos documents ! Les vecteurs ne sont pas compatibles entre modèles. Changement de modèle = ré-indexation complète.
Bonnes pratiques d'optimisation
1. Ajoutez des métadonnées aux chunks
Titre du document, section, date, auteur... Ces métadonnées permettent de filtrer et d'améliorer la pertinence.
2. Testez avec des questions réelles
Créez un jeu de 20-50 questions représentatives et mesurez :
- Le bon chunk est-il dans le top 3 des résultats ?
- Le LLM génère-t-il la bonne réponse ?
3. Utilisez le reranking
Un modèle de reranking (Cohere Rerank, BGE-reranker) réordonne les résultats de la recherche vectorielle pour améliorer la précision.
4. Combinez recherche vectorielle et BM25
La recherche hybride (vecteurs + mots-clés) donne souvent de meilleurs résultats que le vectoriel seul.
Exemple d'amélioration réelle
Pour illustrer l'impact concret de ces optimisations, voici un cas réel sur un projet RAG juridique pour un cabinet d'avocats suisse :
Contexte
Le cabinet disposait de 2'000 documents (jurisprudences, modèles de contrats, notes internes). L'assistant IA initial donnait des réponses décevantes : souvent hors sujet ou incomplètes.
Diagnostic
- Chunks de 2000 tokens (trop grands) sans overlap
- Découpage mécanique ignorant la structure des documents juridiques
- Modèle d'embedding généraliste, pas adapté au français juridique
Optimisations appliquées
- Chunks de 800 tokens avec 15% d'overlap
- Chunking par article/section pour les textes de loi
- Ajout de métadonnées (type de document, date, juridiction)
- Test de 3 modèles d'embedding, sélection du meilleur sur un jeu de 50 questions
Résultats
| Métrique | Avant | Après |
|---|---|---|
| Taux de bonnes réponses | 45% | 78% |
| Réponses "hors sujet" | 28% | 8% |
| Satisfaction utilisateurs | 5.2/10 | 7.8/10 |
Temps d'optimisation : 3 jours de travail. Impact : transformation d'un outil inutilisable en assistant réellement adopté par les juristes.
Checklist d'optimisation pour votre RAG
Si votre RAG ne donne pas satisfaction, voici les points à vérifier dans l'ordre :
- Taille des chunks : sont-ils entre 500 et 1000 tokens ?
- Overlap : y a-t-il un chevauchement de 10-20% entre chunks ?
- Structure respectée : le découpage suit-il la logique du document ?
- Métadonnées : les chunks portent-ils des informations utiles (titre, date, type) ?
- Modèle d'embedding : a-t-il été testé sur vos données réelles ?
- Jeu de test : avez-vous 30-50 questions types pour mesurer la qualité ?
Ce que vous pouvez demander à votre équipe technique
En tant que dirigeant, voici les questions concrètes à poser :
- "Quelle est la taille moyenne de nos chunks et pourquoi ce choix ?"
- "Avons-nous testé différentes configurations de chunking ?"
- "Quel modèle d'embedding utilisons-nous et l'avons-nous comparé à d'autres ?"
- "Comment mesurons-nous la qualité des réponses ?" (il faut un jeu de test)
- "Que se passe-t-il quand l'IA ne trouve pas l'information ?"
"Le chunking est souvent négligé parce que c'est 'juste du découpage'. En réalité, c'est là que se joue 50% de la qualité d'un RAG. Un bon chunking avec un modèle moyen battra toujours un mauvais chunking avec le meilleur modèle du marché."