🔥 RAG 2026 : chunking, recherche hybride & évaluation
RAG 2026 : votre application répond à côté ? Découvrez chunking RAG, recherche hybride et évaluation RAG fiable pour sécuriser vos données IA.
Votre application RAG se trompe ? Vérifiez d'abord ce qui se passe avant le modèle
Une application RAG peut produire une réponse fausse même quand le modèle choisi est très bon. Dans la plupart des cas, le vrai souci se cache ailleurs : un PDF mal extrait, un tableau aplati, un découpage qui sépare une définition de son contexte, ou un passage pertinent qui n'arrive simplement jamais dans le prompt. Et dans ces situations, changer de modèle revient souvent à optimiser... la mauvaise pièce.
En entreprise, ce n'est pas juste une question de qualité perçue. Un assistant RH peut exposer une règle réservée à certains salariés. Un outil de support peut citer une procédure obsolète. Une équipe produit peut perdre du temps à corriger des réponses dont la source n'a jamais été retrouvée. Donc la bonne question n'est pas « ajoutez plus de contexte ». La bonne question, c'est : à quelle étape le système échoue, exactement ?
Ce guide propose une méthode de travail pragmatique : constituer un jeu de questions de référence, fiabiliser les documents, tester le chunking, combiner recherche sémantique et lexicale, puis mesurer séparément la récupération et la génération. Pas besoin d'une « architecture parfaite sur le papier ». L'objectif, c'est un pipeline observable, sécurisé, et assez stable pour être amélioré sans bricoler à l'aveugle.
Pourquoi une application RAG échoue souvent avant le modèle
Un système de génération augmentée par récupération (RAG) récupère des passages dans un corpus, puis les donne à un modèle pour produire une réponse. La chaîne a plusieurs points de rupture : le document n'est pas ingéré, le passage est mal découpé, le moteur le classe trop bas, le contexte fourni est incomplet, ou le modèle comprend mal ce qu'il reçoit.
La distinction est utile. Si le bon passage n'est pas dans les résultats de recherche, demander au modèle de « mieux répondre » ne changera rien. Si le passage est bien présent mais que la réponse le déforme, le problème vient plutôt du prompt, du modèle, ou du format de sortie. Dans tous les cas, le plus efficace est d'observer chaque étape, plutôt que de juger uniquement la réponse finale.
Les travaux de Barnett et de ses coauteurs sur plusieurs cas d'usage RAG identifient sept types d'échec, du contenu manquant jusqu'à la réponse incomplète ou au mauvais niveau de précision. Beaucoup surviennent avant que le modèle voie quoi que ce soit. Et en exploitation, on apprend encore autre chose : un test fait au moment de la conception ne suffit pas si les documents, les utilisateurs et les questions changent.
Augmenter le nombre de passages récupérés n'est pas une solution « automatique ». L'étude Lost in the Middle montre que certains modèles exploitent moins bien une information quand elle est placée au milieu d'un long contexte. Elle observe aussi que passer de 20 à 50 documents n'apporte pas toujours plus qu'un gain marginal. En pratique, un gros prompt peut coûter plus cher, augmenter la latence et noyer la preuve utile.
Le bon diagnostic commence par une question simple : le système a-t-il retrouvé le bon contenu, l'a-t-il transmis au bon utilisateur, puis l'a-t-il utilisé correctement ?
Construire le pipeline en sept Ă©tapes
1. Constituer un jeu de questions de référence
Avant de régler le moteur de recherche, listez les questions auxquelles le système doit répondre et identifiez les documents pertinents. Ajoutez aussi les cas où le système ne doit pas répondre : question hors périmètre, information absente, ou document interdit à l'utilisateur.
Un premier jeu de 50 à 100 questions réelles est un bon point de départ. Complétez avec des questions issues des journaux d'utilisation, des cas difficiles, et des formulations que les équipes utilisent vraiment. Les questions générées automatiquement à partir des documents peuvent aider, mais elles sont souvent plus faciles que les requêtes réelles - et donnent parfois l'impression d'un système meilleur qu'il ne l'est.
Versionnez ce jeu : code, version du corpus, règles d'accès associées. Si les règles RH changent ou si une documentation disparaît, certaines annotations deviennent vite obsolètes. Sans cette discipline, comparer deux évaluations revient parfois à comparer deux jeux différents.
CAS_TEST = [
{
"question": "Combien de jours de congé parental pour les prestataires ?",
"groupes": ["prestataires"],
"docs_attendus": ["politique-rh-2026"],
"docs_interdits": [],
},
{
"question": "Quelle est la grille salariale des ingénieurs seniors ?",
"groupes": ["tous-salaries"],
"docs_attendus": [],
"docs_interdits": ["grilles-confidentielles"],
},
]
2. Extraire et nettoyer les documents
Beaucoup d'échecs viennent déjà de l'ingestion. Une extraction « texte uniquement » peut casser la structure d'un tableau, ignorer le contenu d'une image, ou mélanger titres et pieds de page. Pour les documents complexes, testez l'extraction sur un échantillon représentatif avant d'indexer des milliers de fichiers.
Gardez les éléments utiles dans une forme exploitable : titres, listes, tableaux. Évitez aussi les répétitions qui polluent les résultats, par exemple les mentions légales en pied de page, et ne gardez pas plusieurs versions contradictoires de la même procédure. Chaque passage devrait conserver des métadonnées concrètes : identifiant du document, date, propriétaire, version et règles d'accès.
Et oui, la déduplication compte. Des copies presque identiques peuvent monopoliser les premières positions et rendre les évaluations difficiles à lire. Si un passage « attendu » semble manquer, commencez donc par vérifier ce qui est réellement indexé, pas seulement ce qui est présent dans le fichier d'origine.
3. DĂ©couper le contenu sans perdre son sens
Le chunking sert à découper un document en passages adaptés à l'indexation et à la recherche. On en a besoin quand le document dépasse la limite d'entrée pour les embeddings, mais aussi quand un long texte serait représenté par un seul vecteur (et donc mal « résumé » pour la recherche).
Il n'y a pas une taille universelle. Une recommandation qu'on voit souvent tourne autour de 512 jetons avec 25 % de chevauchement, mais les valeurs par défaut des bibliothèques et des plateformes changent beaucoup. Et selon l'outil, « 512 » peut vouloir dire des caractères... ou des jetons. Si vous recopiez sans vérifier et sans mesurer, vous risquez juste de verrouiller une mauvaise décision.
Commencez par conserver les frontières sémantiques : titres, sections, étapes d'une procédure, blocs de code. Ajoutez ensuite du chevauchement seulement si ça évite de séparer une idée de son explication. Trop de chevauchement crée des passages trop proches, augmente le coût de stockage, et augmente le risque de retrouver « la même » information plusieurs fois.
Pour comparer les tailles, créez plusieurs index distincts, relancez les mêmes questions réalistes, puis comparez les résultats. Ne modifiez pas en même temps la taille des passages, le modèle d'embeddings et les paramètres de recherche : sinon, vous ne saurez pas quelle modification a causé l'effet observé.
4. Indexer en gardant une trace des embeddings
Un index vectoriel associe chaque passage à une représentation numérique. Les vecteurs produits par deux modèles d'embeddings différents ne sont pas interchangeables, même si la dimension est la même. Donc : stockez le nom et la version du modèle avec les données indexées, et assurez-vous que les requêtes utilisent le même modèle que les documents.
PostgreSQL avec l'extension pgvector est une option pratique quand vos données et votre application sont déjà dans cet écosystème. La recherche exacte peut servir de référence, mais elle devient vite lente à grande échelle. Un index approximatif comme HNSW accélère les requêtes au prix d'un compromis sur le rappel : mesurez avant de choisir.
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE passages (
id bigserial PRIMARY KEY,
document_id text NOT NULL,
titre text,
contenu text NOT NULL,
groupes_autorises text[] NOT NULL,
modele_embedding text NOT NULL,
embedding vector(1536) NOT NULL
);
La dimension de l'exemple doit correspondre au modèle retenu. Et si vous passez à un nouveau modèle d'embeddings, prévoyez de recalculer les vecteurs du corpus : mélanger anciens et nouveaux vecteurs dans le même espace de recherche n'est généralement pas une « migration fiable ».
5. Combiner recherche lexicale et recherche vectorielle
La recherche vectorielle retrouve des passages proches par le sens, même si les mots ne sont pas identiques. La recherche lexicale est souvent plus efficace pour les numéros de produit, les noms propres, les références réglementaires ou des dates précises. Dans un corpus métier, les deux approches se complètent.
La recherche hybride exécute les deux recherches, puis fusionne les classements. Une approche courante est le Reciprocal Rank Fusion (RRF) : chaque résultat reçoit un score basé sur son rang dans chaque liste (1 / (rang + k)). Comme ça, on évite de comparer des scores issus de moteurs différents. Et surtout : appliquez les filtres d'accès dans chaque branche de recherche, pas après la génération.
Ensuite, récupérez par exemple une vingtaine de candidats, puis utilisez un reranker pour les réordonner. Le reranking compare plus finement la question et chaque passage. Dans la plupart des cas, il vaut mieux envoyer au modèle final quelques passages vraiment pertinents plutôt qu'un grand nombre de résultats « moyens ».
6. Générer avec des sources et une règle d'abstention
Le prompt doit dire clairement que la réponse s'appuie uniquement sur les passages fournis, demander des citations, et expliquer quoi faire quand l'information manque. Dire « je ne trouve pas cette information dans les documents » fait partie du produit : ce n'est pas un échec à masquer.
Associez chaque extrait à son identifiant de document et à son titre. Demandez au modèle de distinguer ce qui est présent dans les sources de ce qui relève d'une déduction. Testez aussi les questions sans réponse attendue. Enfin, traitez les documents récupérés comme non fiables : une instruction malveillante dans un fichier ne doit pas pouvoir remplacer les consignes du système.
7. Mesurer avant de mettre en production
À chaque modification, comparez le système au jeu de référence. Le but est de savoir si l'amélioration vient du parsing, du découpage, de la recherche, ou de la génération. C'est une boucle d'évaluation simple : mesurer, modifier une étape, mesurer à nouveau, puis décider si ça mérite d'être déployé.
Évaluer la recherche et les réponses séparément
La qualité de la réponse finale ne suffit pas pour savoir où le problème se situe. Si la réponse est fausse, le système peut avoir récupéré les mauvais passages... ou le modèle peut avoir mal utilisé les bons. Il faut donc suivre deux familles de mesures.
Mesurer la récupération
Le rappel à k indique si les documents pertinents apparaissent dans les k premiers résultats. Le MRR (Mean Reciprocal Rank) valorise la position du premier résultat pertinent : un document au tout début compte davantage qu'un document classé loin derrière.
Ces indicateurs répondent à des questions différentes. Le rappel dit si le système retrouve l'information attendue ; le MRR aide à comprendre si elle arrive assez tôt pour être exploitée. Ajoutez aussi un contrôle explicite des fuites de permissions : une seule donnée interdite retournée est un incident, pas un « bruit » à compenser par ailleurs.
Les seuils doivent venir de votre contexte. Un rappel minimal de 0,85 ou un MRR de 0,6 peut être un repère technique, mais ce ne sont pas des standards universels. Un assistant juridique n'a pas les mêmes exigences qu'une recherche interne exploratoire.
Mesurer la réponse générée
Des métriques comme celles proposées par RAGAS aident à séparer plusieurs dimensions :
- Fidélité : les affirmations de la réponse sont-elles soutenues par le contexte récupéré ?
- Précision du contexte : les passages pertinents sont-ils classés avant les passages inutiles ?
- Rappel du contexte : le contexte couvre-t-il les informations nécessaires à la réponse attendue ?
- Pertinence de la réponse : la réponse traite-t-elle la question posée ? Attention : ça ne garantit pas l'exactitude factuelle.
Les évaluations automatiques accélèrent les comparaisons, mais elles ne remplacent pas entièrement la revue humaine. Pour les cas à fort impact (rémunération, conformité, décisions d'accès), gardez des scénarios annotés par des personnes compétentes et regardez les erreurs réelles.
Intégrez les tests de récupération dans l'intégration continue, et enrichissez progressivement le jeu de référence avec des questions issues de la production. Une modification qui améliore la moyenne mais provoque une fuite de données ou dégrade un cas critique ne doit pas passer comme « gagnante ».
Sécuriser et faire évoluer le système
Les permissions doivent s'appliquer avant le prompt
Ne comptez pas sur le modèle pour masquer ce qu'un utilisateur ne doit pas lire. Les contrôles doivent intervenir côté récupération, idéalement via des politiques d'accès appliquées partout de façon cohérente. Avec PostgreSQL, la sécurité au niveau des lignes peut être préférable à un filtre ajouté « à la main » dans chaque requête ; le bon choix dépend de votre architecture et du coût de latence.
Cette règle s'applique aussi aux applications multi-utilisateurs : assurez-vous que les filtres sont actifs sur chaque chemin de recherche, y compris le reranking, le cache et les traitements asynchrones. Si un passage interdit quitte la base et arrive dans le contexte du modèle, il est déjà trop tard.
Le RAG n'est pas une protection complète contre les attaques
Un document externe peut contenir des instructions destinées à manipuler le modèle. Le fait qu'il soit récupéré via un système RAG ne neutralise pas ce risque. L'OWASP Top 10 pour les applications LLM pointe notamment l'injection de prompt, la divulgation d'informations sensibles, les faiblesses des vecteurs et des embeddings, ainsi que la consommation non maîtrisée.
Concrètement : appliquez le principe du moindre privilège, séparez les sources externes des instructions du système, limitez les actions accessibles au modèle, et prévoyez une validation humaine pour les opérations sensibles. Ajoutez aussi des quotas et des limites de débit : sans garde-fous, un assistant peut créer des coûts imprévus.
Et prévoyez la maintenance du corpus : ajouts, modifications et suppressions doivent être répercutés dans l'index. Surveillez l'ancienneté des documents indexés, et vérifiez qu'une suppression dans le référentiel entraîne bien la suppression des passages correspondants.
Choisir un prestataire sur la méthode, pas sur la promesse
Une équipe externe peut être pertinente si vous n'avez pas les compétences pour gérer l'ingestion, les permissions et l'évaluation. Des entreprises comme Dev Technosys, Excellent Webworld, SCAND, Uvik Software ou Kanerika proposent publiquement des offres autour du RAG. Les informations sur la taille d'équipe, les certifications et la méthode sont souvent déclaratives : vérifiez directement, surtout si des données sensibles sont concernées.
Pour comparer les propositions, demandez un prototype évalué sur vos documents et vos questions, une démonstration des filtres d'accès, des critères de réussite, et un plan de maintenance. Clarifiez aussi qui possède les jeux de tests, les données indexées et le code livré. Le choix du fournisseur doit arriver après la capacité à mesurer : une belle démo ne prouve pas que ça tiendra en production.