RAG¶

Reranker RAG : Cohere, BGE, Jina, Voyage comparés

Le retrieval hybride récupère les bons chunks. Le reranker les met dans le bon ordre.

Vous avez implémenté un retrieval hybride BM25 + vectoriel. Votre recall@10 est correct. Pourtant, le LLM produit des réponses médiocres : l'information pertinente est bien dans les 10 chunks remontés, mais elle est au rang 8 ou 9. Le LLM l'ignore ou la dilue dans le bruit des chunks du dessus.

C'est le problème que le reranker résout. Pas le recall, la précision. Pas "trouver", mais "mettre en premier ce qui compte".

Dans cet article, je compare les quatre rerankers les plus utilisés en production (Cohere, BGE, Jina, Voyage) avec les arrivants notables de 2025-2026, les chiffres de benchmark publics, les prix réels, et une recommandation directe par profil de projet.

Sécuriser un RAG : injection, fuites de données, RBAC

Sécuriser un RAG, c'est plus simple qu'un audit de sécurité classique, et plus difficile qu'on le croit

Un RAG en production, c'est trois composants qui s'enchaînent : un retriever qui cherche dans vos documents, un contexte injecté dans un prompt, un LLM qui génère une réponse. Chacun de ces trois maillons est un vecteur d'attaque distinct. Ignorer l'un des trois, et votre système est vulnérable, même si les deux autres sont parfaitement sécurisés.

La bonne nouvelle : la moitié des garde-fous ne coûtent rien. La mauvaise : l'autre moitié demande une vraie refonte architecturale si vous n'y avez pas pensé dès le début.

LLM-as-a-judge : quand l'utiliser, avec le coût réel en €

Ce qu'est un LLM-as-a-judge, en une phrase citable

Un LLM-as-a-judge, c'est un second modèle de langage qui évalue la sortie d'un premier modèle selon une grille de critères explicites : pertinence, fidélité aux sources, complétude, ton. Il produit un score et une justification. C'est tout.

Ce mécanisme est utile. Mais il est cher, lent, et biaisé si on l'applique sans discernement. La question n'est pas "est-ce que je dois utiliser un juge LLM" mais "à quel endroit de mon pipeline, à quelle fréquence, avec quel modèle".

La règle que j'applique sur mes missions : les tests déterministes d'abord, le juge LLM en dernier recours, jamais dans la boucle de développement rapide.

Construire un dataset d'évaluation RAG en 30 minutes

Un dataset imparfait bat l'absence totale de mesure

Pas besoin de semaines d'annotation ou d'un expert métier disponible dès la première heure. En 30 minutes, vous pouvez générer un dataset de départ exploitable directement depuis vos chunks, mesurer le recall@k, et lancer un premier cycle d'amélioration.

Ce dataset sera imparfait. C'est normal et c'est acceptable. L'objectif n'est pas la perfection : c'est d'avoir une mesure reproductible plutôt que le vide. Un recall@5 de 0.71 mesuré sur 50 questions synthétiques vous dit déjà infiniment plus que "ça marche à peu près en démo".

La méthode que je décris ici se déroule en quatre étapes : générer les questions depuis vos chunks, calculer le recall@k, itérer sur le retrieval (hill climbing), et intégrer les retours "pas pertinent" comme hard negatives pour le reranker. Pour les métriques de génération (faithfulness, answer relevancy, context recall) et le choix entre RAGAS, DeepEval et TruLens, voir Évaluer un RAG en production : métriques et RAGAS.

7 mauvais réflexes RAG et comment les corriger

Introduction

Quand un projet RAG patine, ce n'est presque jamais à cause d'une techno manquante. C'est à cause d'un enchaînement de réflexes contre-productifs que les équipes adoptent sans s'en rendre compte. On retouche le prompt alors que le problème est dans le retrieval. On juge "ça marche" sur quatre essais à la main. On empile les techniques avancées avant d'avoir compris où ça bloque.

Après une vingtaine de projets RAG en mission ou en audit, je retrouve toujours les mêmes 7 réflexes. Ce ne sont pas des erreurs techniques, ce sont des biais cognitifs. Mais ils sabotent les performances aussi sûrement qu'un mauvais chunking. Voici la liste, et à chaque fois le réflexe à substituer.

Long context vs RAG en 2026 : quand utiliser quoi ?

Introduction

À chaque sortie d'un modèle avec une fenêtre contextuelle plus grande, le débat revient : « le RAG, c'est fini, on met tout dans le contexte ». En 2026, Gemini 3.1 Pro pousse jusqu'à 2 millions de tokens, Claude et GPT tiennent le 1M. La question est légitime.

Mais sur le terrain, ce n'est pas si simple. J'ai vu des équipes brûler des milliers d'euros en API en pensant qu'elles « simplifiaient » leur stack en virant le RAG. J'ai vu aussi des équipes monter un RAG pour répondre à des questions sur 3 pages de doc. Dans les deux cas, on utilise le mauvais outil pour le problème.

Parsing PDF pour RAG : extraire vraiment la donnée

Le parsing, première cause d'échec des RAG en entreprise

Sur 10 RAG qui ne fonctionnent pas en entreprise, 8 ont un problème de parsing en amont. Pas de modèle, pas de prompt, pas de retriever. Juste un PDF mal lu au départ.

C'est le constat que je fais sur presque tous les projets que j'accompagne. Une entreprise investit des semaines à choisir son modèle de langage, à configurer sa base vectorielle, à affiner ses prompts... et le système répond à côté. Parce que le document source a été mal lu dès le début.

Le parsing (l'extraction structurée des données depuis un document) est l'étape la plus sous-estimée du RAG. Si la récupération d'informations depuis vos fichiers est approximative, peu importe la sophistication du reste du pipeline : vous construisez sur du sable. Un tableau mal extrait, des colonnes confondues, un schéma technique ignoré... et votre LLM génère des réponses fausses avec une confiance absolue.

Dans cet article, je vais vous montrer pourquoi cette structuration des documents est si difficile, comment les 4 grands outils du marché se comparent vraiment, et ce que j'ai appris sur deux projets très différents : des documentations d'usine chez Continental, et un site e-commerce avec des milliers de fiches produit.

Évaluer un RAG en production : métriques et RAGAS

80% des RAG que j'audite n'ont pas de système d'évaluation

C'est un chiffre que j'aurais aimé pouvoir citer avec une source académique. Mais il vient directement du terrain : sur les projets RAG en production que j'ai eu à auditer ces deux dernières années, environ 8 sur 10 n'ont aucun système d'évaluation structuré en place.

Le scénario est toujours le même. Le projet a été livré. L'équipe a "vérifié à la main" sur 10 ou 15 questions pendant la recette. Les retours utilisateurs semblent corrects. Et plus personne ne mesure rien.

Le coût caché de cette absence est massif. Vous ne savez pas si le RAG dérive après une mise à jour des documents. Vous ne savez pas si un changement de modèle d'embeddings a cassé quelque chose. Vous ne savez pas si les améliorations que vous apportez apportent vraiment un gain, ou si elles compensent juste une régression ailleurs. Vous optimisez à l'aveugle.

C'est le sujet numéro un qui sépare un RAG POC d'un RAG production mature. Un POC, ça "marche". Un système production, ça se mesure, ça se surveille, et ça s'améliore de façon contrôlée. Cet article couvre les métriques RAG qui comptent, les frameworks d'évaluation (RAGAS, DeepEval, TruLens), comment construire un dataset d'évaluation solide, et comment mettre en place une évaluation continue en production.

Optimiser un RAG : 8 techniques aux gains mesurés

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 RAG : quelle stratégie choisir en 2026 ?

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.