Aller au contenu

RAG

Optimiser son RAG : les 8 techniques qui font vraiment la différence

Vous optimisez probablement dans le mauvais sens

Quand un RAG ne fonctionne pas bien, voici ce que font 90% des équipes : elles changent le prompt.

On reformule les instructions, on essaie différents modèles, on ajuste la température. Et parfois ça aide un peu. Mais le plus souvent, le problème n'est pas là.

Jason Liu, l'un des experts RAG les plus suivis, a une formulation que j'ai trouvée juste : "Avant de toucher à quoi que ce soit, atteignez 97% de recall en retrieval."

97% de recall, ça veut dire que dans 97 cas sur 100, le chunk qui contient la bonne réponse est bien dans les résultats que vous passez au LLM. Si vous n'êtes pas là, le meilleur prompt du monde ne changera rien. Le LLM ne peut pas inventer une information qui n'est pas dans son contexte.

Le vrai ordre d'optimisation d'un RAG, c'est : mesurer d'abord, puis retrieval, puis génération. Pas l'inverse.


Chunking optimal pour votre RAG : quelle stratégie choisir ?

Le chunking que vous utilisez probablement est le pire testé

Je vais commencer par un résultat qui m'a surpris quand je l'ai vu.

Chroma Research a publié un benchmark comparant toutes les stratégies de chunking courantes. Ils ont testé les paramètres par défaut d'OpenAI Assistants : 800 tokens, 400 tokens d'overlap. Leur verdict est sans appel, c'est la configuration avec la précision la plus basse de tous les tests. 1.4% de précision. Leur commentaire exact : "particularly poor recall-efficiency tradeoffs".

Ce sont les paramètres que des dizaines de milliers de projets utilisent en ce moment, souvent parce que c'est ce que suggère le quick start de LangChain ou LlamaIndex.

Et pendant ce temps, des configurations 4x plus simples (200 tokens, zéro overlap) font 3.7x mieux en précision.

Le chunking, c'est la décision sur laquelle la plupart des équipes passent le moins de temps. Et pourtant, c'est probablement celle qui a le plus d'impact sur la qualité de votre RAG.


RAG hybride BM25 + vectoriel : comment l'implémenter

Votre RAG vectoriel rate des questions que vous ne voyez pas

C'est une remarque que j'entends souvent sur les projets RAG : "Ça marche bien en général, mais parfois il ne trouve rien sur des questions pourtant simples."

Exemple concret : "Quelle est la procédure ISO-27001 pour les accès distants ?" → 0 résultat pertinent.

Le vectoriel encode le sens. Mais quand la question contient un identifiant exact (une norme, un code produit, un acronyme métier), l'encodage sémantique rate complètement.

C'est ce qu'on appelle le vocabulary mismatch. Et c'est le problème que le hybrid search résout.


Les 5 erreurs que tout le monde fait avec le RAG

Introduction

Depuis 2023, j'ai réalisé une dizaine de projets RAG moi-même, et j'en ai dirigé une autre dizaine avec des équipes. Certains se sont très bien passés, d'autres un peu moins, mais on a toujours essayé d'apprendre et se corriger tout au long du projet. Avec le recul, je retrouve toujours les mêmes erreurs, que ce soit chez moi au début, chez des clients, ou chez des confrères. Ce ne sont pas des erreurs techniques (j'en parle dans cet article), mais des erreurs de posture, d'approche et de méthode.

Ce sont des erreurs qu'on fait tous au moins une fois. L'idée ici, c'est de les poser clairement pour éviter de les répéter.


Le RAG est-il vraiment fini ?

Introduction : le RAG, une méthode magique ?

À chaque sortie d'un nouveau modèle avec une fenêtre contextuelle plus grande, on annonce le RAG comme dépassé. Pourtant, le RAG est né d'un besoin très concret : on ne peut pas donner un document de 400 ou 500 pages à un LLM et lui poser des questions dessus.

En entreprise, on a souvent des dizaines (voire des centaines) de fichiers. Le RAG apporte une réponse simple : construire une base documentaire avec des petits morceaux (chunks) de documents, puis fournir dynamiquement les morceaux pertinents à l'IA à chaque question.


Les 4 causes techniques d'échec d'un RAG (et comment les corriger)

Introduction

Un RAG "basique" est rapide à mettre en place, mais il plafonne souvent entre 50 et 70 % de bonnes réponses. En entreprise, ce n'est pas suffisant pour un usage fiable.

Si tu cherches plutôt une méthode d'analyse d'erreur pour prioriser les actions d'amélioration, l'article dédié est ici :
Mon RAG ne marche pas : pourquoi l’analyse d’erreur change tout

Si tu veux d'abord comprendre pourquoi le RAG reste utile malgré les grandes fenêtres contextuelles, j'ai un article dédié :
Le RAG est-il vraiment fini ?

Ici, on se concentre sur l'autre question : pourquoi un RAG ne répond pas correctement, et comment l'améliorer.


Comment améliorer le RAG

Souvent, pour améliorer une application d'IA comme un RAG ou un agent, il est plus judicieux de se concentrer sur l'analyse fine des erreurs plutôt que de céder à la tentation d'ajouter systématiquement de nouveaux outils. Voyons pourquoi cette approche pragmatique est souvent la plus efficace — et surtout, comment la mettre en place concrètement avec les bons outils de mesure.