2026¶

RAG hybride BM25 + vectoriel : implémentation

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.

Agentic RAG vs RAG classique : quand basculer ?

Votre RAG ne suffit plus. Vraiment ?

On en parle partout. L'Agentic RAG. Le RAG agentique. Le futur du RAG.

Et comme d'habitude avec les tendances IA, on a l'impression que si vous n'êtes pas encore passé à l'Agentic RAG, vous êtes en retard. Que votre RAG "classique" est dépassé. Qu'il faut tout refaire.

Je vais vous dire ce que j'en pense vraiment : ce n'est pas aussi simple, et la plupart des projets n'ont pas besoin d'Agentic RAG.

Mais, car il y a toujours un mais, l'Agentic RAG répond à des problèmes réels que le RAG classique ne peut tout simplement pas résoudre. Et si vous tombez sur ces problèmes, vous en aurez besoin.

Alors dans cet article, je vais faire simple : ce qu'est vraiment l'Agentic RAG, en quoi il diffère du RAG classique, et surtout, comment décider si vous en avez besoin ou pas.

RAG BTP : automatiser les réponses aux appels d'offres

Le RAG appliqué à la rédaction : bien plus qu'un chatbot Question-Réponse

Quand on parle de RAG (Retrieval-Augmented Generation), la plupart des gens pensent à un chatbot qui répond à des questions sur des documents internes. C'est le cas d'usage classique, celui qu'on voit dans tous les tutos.

Mais le RAG peut faire bien plus que ça. Quand il est bien intégré dans un workflow métier, le RAG devient un moteur de rédaction contextuelle. Il ne se contente pas de retrouver l'information : il la comprend, la structure, et produit un texte professionnel prêt à être validé par un humain.

Je vais illustrer ça avec un cas concret qu'on a réalisé récemment : l'automatisation de la rédaction d'appels d'offres pour un acteur du BTP.

IA et rapports de sinistre : 80% de temps gagné

La façon dont on intègre l'IA, c'est ce qui fait la différence

Quand on travaille dans l'IA, le plus important souvent ce n'est pas quel modèle on utilise ou quelle dernière techno à la mode est la plus performante.

Le plus important, c'est comment on intègre l'IA dans un workflow déjà existant.

A chaque nouveau projet, il y a deux défis. Le premier, c'est de réussir à atteindre de bonnes performances avec mes algorithmes d'IA pour résoudre une problématique donnée. Le deuxième, c'est l'intégration : comment je mets à disposition cet algorithme pour qu'il soit utilisé et qu'il soit utile. Car trop souvent, des projets IA tombent dans l'oubli parce qu'ils ne sont pas exploitables, ou qu'ils ne s'intègrent pas bien dans le travail quotidien des employés (j'en parle dans les 5 erreurs que tout le monde fait avec le RAG, mais le constat dépasse largement le RAG).

Je vais illustrer ça avec un cas concret qu'on a réalisé récemment : l'automatisation de rapports de sinistre pour un acteur de l'expertise bâtiment et menuiserie.

Les 5 erreurs les plus fréquentes 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.

RAG vs Long Context LLM : le RAG est-il 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.

4 causes techniques d'échec d'un RAG (et correctifs)

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.

AI Engineer : le nouveau rôle du data scientist en IA générative

AI Engineer : qui c'est, et pourquoi le terme existe

Un AI engineer, c'est celui qui intègre des modèles d'IA générative en production sans les entraîner lui-même. Il part de modèles existants, des LLM accessibles par API ou en open source, et son travail consiste à les transformer en quelque chose d'utile et de fiable : un RAG, un agent, une chaîne de traitement qui tient en production. C'est un rôle qui n'existait pas vraiment il y a trois ans.

Je suis Anas Rabhi, data scientist freelance, et c'est de plus en plus comme ça que je décris ce que je fais. C'est surtout une nouvelle appellation. En data science, le rôle a toujours bougé selon les capacités de chacun et selon ce dont l'entreprise avait besoin : la même personne a pu être appelée data scientist, ingénieur IA, machine learning engineer, parfois les trois. « AI engineer » est la dernière de ces étiquettes, celle qui colle au travail qu'on fait depuis l'arrivée de l'IA générative. Cet article explique ce qu'elle recouvre, pourquoi elle est apparue, et en quoi elle diffère du data scientist et du ML engineer.

Réussir un projet IA : ce qui se joue avant le code

Réussir un projet IA se décide avant la première ligne de code

Ce qui fait qu'un projet IA fonctionne se décide bien avant de toucher au moindre bout de code. Pas dans le choix du modèle, pas dans le framework, pas dans le pipeline. Dans le cadrage : la problématique métier, l'objectif et sa mesure, la donnée réelle, la question de savoir si l'IA est même nécessaire, et l'utilisateur qui devra s'en servir.

Avec le temps, j'ai fini par passer le plus clair de mon énergie sur ce qui vient avant l'IA. Pas sur l'IA elle-même. C'est contre-intuitif quand on est ingénieur, mais c'est là que se joue la différence entre un projet qui tient et un projet qui finit dans un tiroir.

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.