Pour améliorer un RAG, on commence par mesurer, puis on corrige les bugs de la chaîne de traitement, avant de toucher au découpage, à la recherche hybride ou au reranking. Sur un projet réel, l'ordre était : évaluation et petits bugs, retours des utilisateurs test, lecture des documents, découpage, recherche hybride, puis un reranking testé et finalement écarté.
Le reranking faisait passer la note de 89 % à 92 %. Je ne l'ai pas gardé : ce cas d'usage avait aussi besoin de réponses rapides, et trois points ne justifiaient pas l'attente supplémentaire. Cet article suit cet ordre, étape par étape, avec ce que chacune apporte et quand elle devient prioritaire.
En bref
- On ne peut pas améliorer ce qu'on ne mesure pas : le jeu de test passe avant toute technique
- Les bugs de la chaîne de traitement expliquent plus de mauvais résultats que le modèle, et se corrigent vite
- Parsing et chunking viennent avant la recherche hybride, puis le reranking
- Le reranking a donné 89 % à 92 % sur ce cas, sans être retenu : le temps de réponse comptait
- Le rythme : des sprints d'un mois, avec des objectifs et des livrables, l'évaluation au centre
Commencer par les bugs, pas par les techniques avancées
La première amélioration d'un RAG est presque toujours la correction de bugs dans la chaîne de traitement, pas un changement de modèle ni une technique sophistiquée. C'est le constat que je fais en audit, sur une vingtaine de RAG construits, améliorés ou audités, dont une dizaine en production aujourd'hui.
Un RAG basique répond correctement à environ 50 à 70 % des questions. Après les premières corrections, il est fréquent de passer de 30 % à 70 %, de 50 % à 70 %, ou de 20 % à 50 % sur les cas d'usage complexes. Ce sont les plus gros gains du projet, et ils arrivent avant toute technique avancée.
Trois bugs réels, trouvés en audit :
- Deux modèles d'embeddings différents. Un modèle a servi à indexer les documents, un autre à interpréter la question. Les vecteurs ne sont pas comparables : la recherche est faussée sans qu'aucune erreur ne s'affiche.
- Un seul passage récupéré par mégarde. Le système ne remonte qu'un morceau de document au lieu de plusieurs. La réponse manque de contexte dès que l'information est répartie.
- La recherche sur le dernier message seulement. Dans une conversation, « et pour les CDD ? » ne veut rien dire seul. Il faut chercher sur toute la conversation, ou reformuler la question avec son historique.
Aucun de ces défauts ne se voit dans une démonstration. Ils se voient dans les chiffres, à condition d'en avoir. C'est le sujet de notre article sur la façon de mesurer la performance d'un RAG, et c'est pourquoi cette étape commence par l'évaluation : sans jeu de questions et sans pourcentage de bonnes réponses, on corrige à l'aveugle. Si votre assistant déçoit, les quatre causes techniques d'échec d'un RAG donnent l'ordre de diagnostic côté praticien.
Collecter les questions et les retours des utilisateurs test
Les questions des vrais utilisateurs sont la meilleure matière pour améliorer un RAG, parce qu'elles ne ressemblent jamais aux questions imaginées par l'équipe. Dès que des utilisateurs test ont l'outil en main, il faut mettre en place la collecte de leurs questions et de leurs retours.
Dans notre méthode, toutes les questions des utilisateurs pendant la phase de test sont reprises dans l'évaluation. Le jeu de test, qui démarre à 20 à 50 questions dès les deux ou trois premiers jours, s'enrichit donc de cas réels. Une correction qui améliore le jeu initial mais dégrade les questions récentes se voit tout de suite.
Côté produit, un simple pouce levé ou baissé sur chaque réponse, accompagné de la question posée et des passages retrouvés, suffit. Ce n'est pas un chantier lourd. C'est ce qui permet de décider la suite sur des faits.
Parsing puis chunking : lire correctement avant de découper
Un RAG ne peut pas répondre juste à partir d'un document mal lu : le parsing (la lecture des documents) précède le chunking (le découpage en passages), et on les améliore dans cet ordre. Inutile de peaufiner la taille des morceaux si le texte extrait est déjà déformé.
Un corpus bien organisé en docx s'exploite bien. Les tableaux, graphiques et schémas posent problème, de même que les doublons, les documents faits uniquement de schémas et certains PDF délicats. Quand les mauvaises réponses viennent toujours des mêmes documents, c'est ici qu'il faut regarder. Le côté technique (outils d'extraction, comparatifs) est détaillé dans notre article sur l'extraction de documents PDF pour un RAG.
Le chunking vient ensuite : un passage coupé au milieu d'une procédure perd son sens, un passage trop large noie l'information utile. L'arbitrage se fait sur le jeu de test, pas au jugé. Autre levier qui compte autant que le moteur : sourcer les réponses, pour que l'utilisateur puisse vérifier d'où vient l'information. Je le propose presque systématiquement, parce que l'interface et la façon de présenter l'information comptent autant que le moteur.
La recherche hybride, puis le reranking : ce qu'on arbitre
La recherche hybride combine une recherche par mots exacts et une recherche sémantique ; le reranking réordonne ensuite les passages retrouvés. Ce sont deux étapes de recherche, mais elles ne se décident pas de la même façon : la première corrige des oublis, la seconde coûte du temps de réponse.
La recherche hybride aide surtout quand les questions contiennent des termes que la recherche sémantique rate : références, codes erreur, acronymes, noms propres. Dans un corpus technique, c'est souvent un gain net pour un coût de latence faible.
Chez Continental, dont la documentation contient des références de pièces et des codes d'erreur machine, l'ajout de la recherche lexicale a fait passer les réponses correctes de 67 % à 89 %, comme le détaille le cas client Continental. C'est le plus gros saut de cette étape de recherche. Le principe est détaillé dans l'article sur la recherche hybride BM25 et vectorielle.
Le reranking est testé en dernier. Sur ce projet, il faisait passer la note de 89 % à 92 %, après les 67 % à 89 % de la recherche hybride. Mais le cas d'usage avait aussi besoin d'un temps de réponse court, et l'étape de reranking allongeait l'attente. Je ne l'ai pas retenu.
Le critère de décision
Trois points de mieux ne justifient pas toujours un assistant plus lent. Un gain de 89 % à 92 % peut valoir le délai pour un outil de recherche que l'on consulte une fois par jour. Il ne le vaut pas pour un assistant utilisé en plein échange avec un client ou un collègue.
La question à poser avant de lancer un reranking n'est donc pas « combien de points ? » mais « combien de secondes de plus, et pour quel usage ? ». Les techniques de recherche avancée sont passées en revue dans l'article sur l'optimisation d'un système RAG.
Ce qui n'a rien donné, et pourquoi on le dit
En expérimentation, certaines pistes n'apportent rien, et il faut l'écrire plutôt que les garder au catalogue. Le reranking, on l'a vu, a été écarté pour un arbitrage de temps de réponse. Passer en agentic RAG n'a rien donné non plus sur ce que nous avons testé, et d'autres pistes sont dans le même cas.
Un agentic RAG, où un agent décide lui-même de lancer plusieurs recherches, ajoute de la complexité et de la latence. Il se justifie sur des questions qui demandent d'enchaîner plusieurs recherches, pas pour réparer un RAG basique qui répond à côté. La comparaison technique est dans l'article sur l'agentic RAG contre le RAG classique.
Cette honnêteté fait partie de la méthode : si une piste ne bouge pas la note, on la retire. Une architecture plus complexe n'est pas une meilleure architecture.
Le rythme : des sprints d'un mois, l'évaluation au centre
Améliorer un RAG se fait par sprints d'un mois, chacun avec des objectifs précis et des livrables, et l'évaluation au centre. À chaque sprint, la même question : la note a-t-elle monté sur le jeu de test, y compris sur les questions des utilisateurs ?
Je ne promets pas la lune, mais une procédure scientifique, qui a fait ses preuves, avec l'évaluation au centre. Les premiers sprints rapportent le plus (les bugs, les documents mal lus). Les suivants rapportent des gains plus petits, et c'est là qu'on arbitre entre points de qualité, temps de réponse et coût.
Voici l'ordre d'ensemble, avec ce que chaque étape corrige et le moment où elle devient prioritaire :
| Étape | Ce qu'on corrige | Quand c'est prioritaire |
|---|---|---|
| 1. Évaluation et bugs | Erreurs de la chaîne de traitement : embeddings, nombre de passages, historique de conversation | Toujours en premier, avant tout le reste |
| 2. Retours des utilisateurs test | Questions réelles absentes du jeu de test, formulations imprévues | Dès que des utilisateurs touchent l'outil |
| 3. Lecture des documents (parsing) | Tableaux, schémas, PDF mal extraits, doublons | Quand les mauvaises réponses viennent des mêmes documents |
| 4. Découpage (chunking) | Passages coupés au mauvais endroit, contexte perdu | Quand l'information est dans le corpus mais mal retrouvée |
| 5. Recherche hybride | Termes exacts, codes, références que la recherche sémantique rate | Corpus techniques, noms propres, numéros, acronymes |
| 6. Reranking | Ordre des passages retrouvés | Si le temps de réponse n'est pas une contrainte forte |
| 7. Agentic RAG et autres pistes | Questions qui demandent plusieurs recherches enchaînées | Après les étapes précédentes, et seulement si la mesure le justifie |
Si votre assistant plafonne et que vous ne savez pas par quelle étape reprendre, c'est le travail d'un audit RAG et agents IA : mesurer où vous en êtes, trouver les bugs de la chaîne, puis proposer un plan par sprints. Pour les fondamentaux, voir notre guide du RAG en entreprise.
Questions fréquentes sur l'amélioration d'un RAG
Articles recommandés
- Mesurer la performance d'un RAG : le jeu de test et le pourcentage de bonnes réponses, préalables à toute amélioration.
- Maintenir un RAG en production : ce qui se dégrade après la mise en service.
- Optimiser un système RAG : chunking, re-ranking et techniques avancées, côté praticien.
- RAG hybride BM25 et vectoriel : comment combiner les deux recherches.
