Améliorer un RAG : vérifier ce qu’il lit avant de changer de modèle

La question porte sur le délai de restitution des locaux prévu au cahier des charges. L’assistant documentaire répond vite, cite l’article, donne un nombre de jours. La réponse est claire, bien tournée, et fausse : elle sort de la version de 2023 du document, remplacée depuis par une version qui raccourcit ce délai. Le réflexe habituel consiste alors à changer de modèle, ou à attendre le suivant. Le nouveau modèle lit le même mauvais extrait, et rédige la même erreur avec un peu plus d’élégance.

Dans un assistant qui interroge les documents de l’entreprise, le modèle de langage n’est que le dernier maillon. Avant lui, une recherche choisit les passages qu’il aura le droit de lire. C’est la logique du RAG, l’une des quatre façons d’alimenter une IA avec ses propres données, et c’est souvent là que se joue la justesse d’une réponse.

La mauvaise réponse vient d’un mauvais extrait

Le fonctionnement tient en deux temps. D’abord, une recherche parcourt la base documentaire et ramène les passages qui semblent répondre à la question. Ensuite, le modèle rédige sa réponse à partir de ces seuls passages. S’il reçoit le bon article du bon contrat, il a toutes les chances de répondre juste. S’il reçoit l’ancienne version, une clause voisine ou un document hors sujet, il rédige avec la même assurance une réponse fausse, et rien dans le texte ne permet de le deviner.

La première recherche est rapide mais grossière. Elle compare la question à des milliers de passages et en retient quelques dizaines qui « ressemblent » à la demande. Le second tri, que les spécialistes appellent reranking, reprend ces candidats un par un, les relit au regard de la question exacte et les reclasse. Seuls les mieux classés partent vers le modèle.

Le gain est loin d’être marginal. Anthropic a mesuré, en 2024, la part des passages pertinents que la recherche laissait hors des vingt premiers résultats. Selon ses tests, ce taux d’échec passait de 5,7 % à 2,9 % en améliorant la recherche elle-même, puis à 1,9 % en ajoutant un second tri : 67 % d’échecs en moins au total. Un modèle plus puissant n’aurait rien changé à ces chiffres, puisqu’il ne voit que ce qu’on lui transmet. Ce mécanisme est aussi ce qui rend l’agent aussi bon que le contexte qu’on lui donne, ni plus, ni moins.

Ce que change Rerank 5, et ce qu’il ne change pas

Cohere a sorti le 21 octobre Rerank 5, la nouvelle version de son modèle de second tri, en deux variantes : Pro, qui privilégie la qualité du classement, et Fast, qui privilégie la vitesse et le coût. Quatre points intéressent une entreprise qui exploite ses propres documents.

Il ne transmet que les passages utiles. Avec l’option Context Focus, le modèle ne se contente plus de classer des documents entiers : il repère, à l’intérieur de chacun, les passages qui répondent à la question. Selon Cohere, retirer la moitié du contexte envoyé au modèle de langage ne coûte que 2 points de qualité de réponse, et retirer les trois quarts en coûte 7. Moins de texte transmis, c’est une facture d’API plus légère et moins de bruit pour le modèle qui rédige.

Il est évalué en français. Le français fait partie des langues mises en avant dans les tests de l’éditeur, avec un score de classement de 90,5 pour la version Pro et de 88,6 pour Fast. Le prix affiché est de 0,05 dollar par million de tokens pour Pro et de 0,02 dollar pour Fast.

Il peut tourner chez soi. Rerank 5 est disponible par l’API de Cohere, sur Microsoft Foundry et sur Amazon SageMaker, et Cohere propose un déploiement dans le cloud privé de l’entreprise ou sur ses propres serveurs. Le point compte quand les documents interrogés sont des contrats, des dossiers RH ou des réponses à appel d’offres.

Ses scores se lisent comme des probabilités. Un score de 0,7 correspond désormais, selon Cohere, à environ 70 % de chances que le document soit utile. Cela permet de fixer un seuil : sous une certaine note, l’assistant répond qu’il n’a pas trouvé de source fiable au lieu d’improviser à partir d’un passage douteux. Pour un assistant de support ou de réponse commerciale, cette capacité à dire « je ne sais pas » vaut souvent plus qu’un point de précision.

Reste la réserve habituelle : ces chiffres sont ceux de l’éditeur, mesurés sur ses propres jeux de tests. Ils indiquent une tendance, pas le résultat qu’on obtiendra sur une base documentaire précise. Seul un test sur ses propres documents le dira.

Le test des vingt questions

Ce test se monte en une journée, et il tranche la question avant tout changement de modèle ou de fournisseur. Il repose sur une idée : juger séparément ce que la recherche a trouvé et ce que le modèle a répondu.

Le test des vingt questions, en quatre temps

1

Vingt vraies questions

Tickets, questions d’acheteurs, clauses : la réponse et sa source notées par un expert.

2

Ce que la recherche trouve

Le bon document est-il dans les trois premiers extraits ?

3

Ce que le modèle répond

Juste, partielle ou fausse, et le temps qu’il a fallu pour vérifier.

4

Avec le second tri

Mêmes questions, reranking activé : on compare les deux séries.

Les vingt questions doivent venir du terrain : des tickets de support réels, des questions posées par des acheteurs dans des appels d’offres passés, des demandes internes sur des clauses de contrat. Pour chacune, quelqu’un qui connaît le sujet note la bonne réponse et le document qui la contient. C’est le seul travail long, et il sert ensuite à chaque évolution de l’assistant.

La lecture des résultats est souvent instructive. Si le bon document arrive rarement dans les trois premiers extraits, le problème est la recherche, et le second tri a toutes les chances d’aider. Si le bon document est bien là mais que la réponse reste fausse, c’est la rédaction qui pèche, et un autre modèle ou une meilleure consigne peut se justifier. Le temps de vérification, enfin, dit si l’assistant fait gagner du temps ou s’il déplace simplement le travail vers celui qui relit.

Trois vérifications avant de changer de modèle

Le second tri améliore le classement de ce qui existe dans la base. Il ne répare pas une base mal tenue. Trois défauts reviennent dans la plupart des projets, et aucun ne se corrige en changeant d’outil.

Les doublons et les versions périmées. Quand trois versions d’une même procédure cohabitent dans la base, la recherche n’a aucun moyen de savoir laquelle fait foi. Archiver les anciennes, ou indiquer la date de validité de chaque document dans ses métadonnées, règle une bonne part des réponses « presque justes ».

Le découpage des documents. Avant d’être indexé, chaque document est coupé en fragments. Un tableau tranché en deux, une clause séparée du titre qui lui donne son sens, une annexe coupée de son contrat : le passage remonte, mais il ne veut plus rien dire seul. Relire une dizaine de fragments pris au hasard suffit à repérer le problème.

Les références exactes. La recherche « par le sens », celle des systèmes récents, comprend les reformulations mais rate volontiers les codes : une référence produit, un numéro d’article, le nom d’un lot. Lui adjoindre une recherche classique par mots-clés, comme dans les tests d’Anthropic, rattrape ces cas.

Un assistant qui se trompe donne l’impression d’un modèle qui ne comprend pas. Dans la plupart des cas, il a compris la question et lu le mauvais document. Vérifier ce qu’il lit avant de juger ce qu’il écrit, c’est aussi refuser de se laisser convaincre par une réponse bien tournée, le travers qui produit le workslop, ces documents IA bien faits mais creux.