Question d'entretien IA n°11 : Comment optimiser le RAG ?

L'optimisation du RAG ne se limite pas à un seul composant, mais constitue un processus d'optimisation de bout en bout. Ci-dessous, je présente des stratégies d'optimisation systématiques à partir de quatre dimensions : côté indexation des données, côté recherche, côté génération et côté évaluation, ainsi que des expériences pratiques à mentionner lors des entretiens.

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

C'est l'aspect le plus négligé mais qui apporte les gains les plus rapides.

Point d'optimisation	Problème observé	Méthode concrète	Indicateur d'effet
Analyse de documents	Les tableaux et organigrammes dans les PDF sont ignorés, ou le texte est mal encodé ou désordonné.	Utiliser de meilleures bibliothèques d'analyse (ex. `unstructured`, mode de conservation de 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 (ex. « sa croissance de revenus cette année » où « sa » perd sa référence) ; un chunk trop large augmente le bruit de recherche.	Expérimenter différentes tailles de chunk (256/512/768 tokens), avec un chevauchement de 10~20% ; pour les longs documents, découper selon les limites sémantiques (paragraphes/titres) plutôt qu'une longueur fixe.	Taux de succès / Fidélité
Ajout de métadonnées	Des segments pertinents sont trouvés, mais on ne peut pas retracer la source ou la date, ou filtrer par domaine.	Ajouter des métadonnées à chaque chunk : `source` (nom du fichier/URL), `timestamp`, `page_num`, `doc_type`. Utiliser des filtres lors de la recherche (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 verticaux (médical, code, juridique).	Utiliser des modèles affinés par domaine (BGE‑large‑zh, GTE‑Qwen2‑7B‑instruct) ; ou affiner son propre modèle d'embedding (avec triplet loss).	MRR@10 en recherche +10~20%

II. Optimisation côté recherche (améliorer la précision de la « consultation »)

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

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

III. 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 modèle faible ne fonctionnera pas.

Point d'optimisation	Problème observé	Méthode concrète	Effet
Ingénierie de prompts	Le LLM ignore le contenu récupéré ou invente des informations.	Donner une instruction claire : « Répondez uniquement à partir des 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 du contexte	Le contenu récupéré 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 conserver les phrases les plus pertinentes avant de les envoyer au LLM.	Réduction du risque de perte d'information
Mise à niveau du modèle LLM	Un petit modèle (7B) ne peut pas effectuer des raisonnements complexes ou retenir un long contexte.	Passer à un modèle plus puissant (GPT‑4o, Claude 3.5 Sonnet, Qwen2.5‑72B).	Amélioration substantielle de la précision du raisonnement
Streaming et citations	L'utilisateur ne peut pas vérifier la crédibilité de la réponse.	Demander au LLM de produire `[citation:1]` correspondant au numéro du document récupéré. Joindre le lien original dans le backend.	Confiance de l'utilisateur + débogabilité
Calibrage du refus de répondre	Le modèle invente quand il ne devrait pas répondre, ou dit « je ne sais pas » quand il devrait répondre.	Définir un seuil de similarité : si la similarité cosinus entre le chunk top‑1 et la question est inférieure à 0,7, inciter le LLM à répondre « Document non pertinent ».	Réduction du taux d'hallucination

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

Pas de métrique, pas d'optimisation.

Point d'optimisation	Méthode	Indicateur
Création d'un jeu d'évaluation	Préparer 100~300 questions utilisateur réelles + réponses de référence + IDs de documents pertinents.	Couvrir différentes difficultés et intentions.
Évaluation automatique	Utiliser RAGAS (Faithfulness, Answer Relevance, Context Recall) ou TruLens.	Trois métriques clés : fidélité, pertinence de la réponse, rappel du contexte.
Évaluation humaine	Tester 20 cas défaillants par semaine, analyser le type d'erreur (échec de recherche / erreur de génération / lacune de la base de connaissances).	Priorisation des améliorations.
Tests A/B	En production, tester différentes stratégies de recherche (ex. BM25 vs recherche hybride) sur des groupes distincts.	Métriques en ligne : satisfaction utilisateur, taux de non‑réponse.

V. Expériences pratiques à mentionner lors des entretiens (points bonus)

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

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

Résumé final : une feuille de route complète pour l'optimisation du RAG

Couche des données ─→ Nettoyage des documents, optimisation du chunking, augmentation des métadonnées, embedding de domaine
Couche de recherche ─→ Recherche hybride, reclassement, réécriture de requêtes, HyDE, ajustement du Top-K
Couche de génération ─→ Renforcement des prompts, exigences d'instructions, compression, citations, seuil de refus
Couche d'évaluation ─→ Ensemble d'évaluation, RAGAS, analyse humaine, expériences A/B