Série d'entretiens AI 11 : Comment optimiser le RAG ?

L'optimisation du RAG ne consiste pas en un ajustement unique, mais en un processus d'optimisation de bout en bout. Ci-dessous, je présente des stratégies d'optimisation systématiques selon quatre dimensions : côté indexation des données, côté recherche, côté génération, côté évaluation, accompagnées d'expériences pratiques pouvant être mentionnées lors d'un entretien.

1. Optimisation côté indexation des données (améliorer la qualité de la « base de connaissances »)

C'est l'aspect le plus souvent négligé mais qui donne les résultats les plus rapides.

Point d'optimisation	Phénomène	Méthode concrète	Indicateur d'effet
Analyse de documents	Les tableaux et diagrammes dans les PDF sont ignorés, ou les caractères sont illisibles, l'ordre est perturbé.	Utiliser une meilleure bibliothèque d'analyse (p. ex. `unstructured`, mode de conservation de la mise en page de `pypdf`) ; pour les tableaux, extraire avec `pandas` puis convertir en Markdown.	Taux de rappel +5~15%
Taille des chunks	Un chunk trop petit perd le contexte (p. ex. le pronom « il » dans « son chiffre d'affaires a augmenté cette année ») ; un chunk trop grand introduit du bruit.	Expérimenter différentes tailles de chunk (256/512/768 tokens), chevauchement de 10~20% ; pour les documents longs, découper selon les frontières sémantiques (paragraphes/titres) plutôt qu'une longueur fixe.	Taux de succès / Fidélité
Ajout de métadonnées	Les passages pertinents sont retrouvés mais on ne peut pas remonter à la source ou à la date, ou on doit filtrer par domaine.	Ajouter des métadonnées à chaque chunk : `source` (nom de fichier/URL), `timestamp`, `page_num`, `doc_type`. Utiliser des filtres lors de la recherche (p. ex. `doc_type == 'legal'`).	Précision du filtrage
Choix du modèle d'embedding	Les embeddings génériques sont médiocres dans des domaines spécialisés (médical, code, juridique).	Utiliser des modèles fine-tunés sur le domaine (BGE‑large‑zh, GTE‑Qwen2‑7B‑instruct) ; ou fine-tuner son propre modèle d'embedding (avec triplet loss).	MRR@10 en recherche +10~20%

2. Optimisation côté recherche (rendre la « consultation » plus précise)

La recherche détermine la qualité des « documents de référence » fournis au LLM.

Point d'optimisation	Phénomène	Méthode concrète	Effet
Recherche hybride	La recherche vectorielle ne peut pas correspondre à des termes précis (p. ex. modèle produit `ABC-123`), la recherche par mots-clés ne comprend pas les synonymes.	Utiliser simultanément la recherche vectorielle (sémantique) et BM25 (mots-clés), fusionner par pondération (p. ex. 0.7vecteur + 0.3BM25) ou par rerank.	Taux de rappel +10~25%
Reclassement (Rerank)	Les premiers résultats retournés par la recherche vectorielle ne sont pas forcément les plus pertinents ; le 10e peut être le meilleur.	Utiliser un modèle cross‑encoder (p. ex. `BGE‑reranker-v2`, Cohere Rerank) pour re‑scorer l'ensemble des candidats (p. ex. les 20 premiers) et prendre le top‑K.	Amélioration significative du taux de succès (surtout top‑1)
Réécriture de requêtes	La question de l'utilisateur est vague ou les références sont floues dans un dialogue multi‑tour (« Quel est son prix ? »).	Utiliser le LLM pour reformuler la question originale sous une forme plus adaptée à la recherche (p. ex. « Quel est le prix de l'iPhone 15 ? ») ; ou compléter avec l'historique de la conversation.	Taux de rappel +5~15%
HyDE	La question est trop courte ou trop abstraite (p. ex. « Parle-moi de la photosynthèse »), la recherche directe est inefficace.	D'abord faire générer au LLM une réponse hypothétique, puis utiliser cette réponse pour rechercher dans les documents.	Adapté aux domaines ouverts, mais pas aux questions factuelles précises
Ajustement du top‑K	Un K trop faible peut manquer des informations clés ; un K trop élevé augmente la consommation de tokens et le bruit.	Expérimenter K=3/5/10, observer l'équilibre entre taux de rappel et fidélité de la réponse.	Compromis efficacité/qualité

3. Optimisation côté génération (permettre au LLM de bien utiliser les documents de référence)

Même avec une bonne recherche, un mauvais prompt ou un mauvais modèle ne donne rien.

Point d'optimisation	Phénomène	Méthode concrète	Effet
Ingénierie des prompts	Le LLM ignore le contenu retrouvé ou invente des informations.	Instruction claire : « Répondez uniquement en vous basant sur les documents de référence fournis ci-dessous. Si les informations sont insuffisantes ou non pertinentes, répondez 'Pas assez d'informations'. » Ajouter des exemples few‑shot montrant comment citer les sources.	Fidélité +20~40%
Compression de contexte	Le contenu retrouvé est trop long (dépasse la fenêtre de contexte du modèle) ou contient beaucoup de bruit.	Utiliser `LLMLingua` ou une compression de contexte sélective pour ne garder que les phrases les plus pertinentes avant de les envoyer au LLM.	Réduction du risque de perte d'information
Mise à niveau du LLM	Un petit modèle (7B) ne peut pas effectuer de raisonnements complexes ou retenir de longs contextes.	Passer à un modèle plus puissant (GPT‑4o, Claude 3.5 Sonnet, Qwen2.5‑72B).	Précision du raisonnement fortement améliorée
Citations en streaming	L'utilisateur ne peut pas vérifier la crédibilité de la réponse.	Faire produire par le LLM `[citation:1]` correspondant au numéro du document de recherche. Joindre le lien source en backend.	Confiance utilisateur + débogabilité
Calibrage du refus de réponse	Le modèle invente des réponses quand il ne devrait pas, ou dit ne pas savoir alors qu'il devrait répondre.	Définir un seuil de similarité : si la similarité cosinus du top‑1 chunk avec la question est inférieure à 0.7, demander au LLM de répondre « Informations non pertinentes ».	Réduction du taux d'hallucination

4. Évaluation et itération (savoir où ajuster)

Sans mesure, pas d'optimisation.

Point d'optimisation	Méthode	Indicateur
Création d'un jeu d'évaluation	Préparer 100 à 300 questions réelles d'utilisateurs + réponses de référence + IDs corrects des documents de recherche.	Couvrir différents niveaux de difficulté et différentes intentions.
Évaluation automatique	Utiliser RAGAS (Faithfulness, Answer Relevance, Context Recall) ou TruLens.	Trois indicateurs clés : fidélité, pertinence de la réponse, rappel du contexte.
Évaluation humaine	Tester 20 cas problématiques chaque semaine, analyser le type d'erreur (échec de recherche / erreur de génération / absence dans la base de connaissances).	Priorisation des améliorations.
Tests A/B	Tester différentes stratégies de recherche en production sur des sous‑ensembles (p. ex. BM25 vs recherche hybride).	Indicateurs en ligne : satisfaction utilisateur, taux de non‑réponse.

5. « Expériences pratiques » à mentionner en entretien (points bonus)

« Dans le projet RAG dont j'étais responsable, le taux de succès de base n'était que de 67%. J'ai fait trois choses :
1. Passer d'un découpage fixe de 1024 à un découpage sémantique dynamique (selon titres + paragraphes), le taux de succès est monté à 74% ;
2. Ajouter une recherche hybride (vecteur + BM25) et un petit modèle de rerank, le taux de succès est monté à 83% ;
3. Optimiser le prompt et imposer la réponse '[Aucune information pertinente trouvée]' , le taux d'hallucination est passé de 22% à moins de 5%.

De plus, nous avons mis en place un pipeline d'évaluation continue, exécutant les scores RAGAS sur 200 questions avant chaque modification pour garantir l'absence de régression. »

Conclusion : Une feuille de route complète pour l'optimisation du RAG

Couche données ─→ Nettoyage des documents, optimisation du chunking, enrichissement des métadonnées, embedding de domaine
Couche recherche ─→ Recherche hybride, rerank, réécriture de requêtes, HyDE, ajustement du top‑K
Couche génération ─→ Renforcement du prompt, instructions de format, compression, citations, seuil de refus
Couche évaluation ─→ Jeu d'évaluation, RAGAS, analyse humaine, tests A/B