Arrêtez de changer de LLM : votre problème est ailleurs

Dans un système RAG, le modèle n’est presque jamais le maillon faible. Retour de terrain sur ce qui fait réellement la qualité des réponses.

Le réflexe du changement de modèle

Quand un assistant IA répond mal, la première réaction est presque toujours la même :

Il faut essayer un modèle plus récent.

On change de modèle. Les réponses changent de style. Elles restent fausses.

Sur LEGIBUS, j’ai fini par considérer cette envie comme un signal d’alerte. Elle indique qu’on n’a pas encore regardé au bon endroit.

Un modèle ne répond qu’avec ce qu’on lui donne

Dans une architecture RAG, le modèle ne sait rien de vos documents.

Il reçoit quelques extraits, sélectionnés par un moteur de recherche, et rédige une réponse à partir de ces extraits.

Si les bons passages ne sont pas dans le lot, aucun modèle ne les inventera correctement.

Avant d’accuser la génération, je pose donc toujours la même question :

Le passage qui contient la réponse faisait-il partie de ce que le modèle a reçu ?

Le test que nous avons fait sur LEGIBUS

Pour trancher, nous avons comparé deux pistes :

changer de modèle, en passant à un modèle nettement plus gros et plus puissant
garder le modèle et ajouter un reranker entraîné sur le droit, qui reclasse les sources et limite celles qui sont envoyées au LLM

Le résultat est sans appel.

Avec le gros modèle, les réponses sont moins mauvaises qu’avant. Mais le modèle prend beaucoup de libertés, et les sources deviennent secondaires.

Avec le reranker, une grande partie du bruit disparaît, et le taux de réussite atteint environ 98 % sur un panel de 1 500 questions, d’après une étude menée par le CITC.

Le gain ne venait pas du modèle. Il venait de ce qu’on lui donnait à lire.

Le découpage : là où tout se joue

Avant d’être indexé, un document est découpé en morceaux.

C’est une étape qu’on règle une fois, par défaut, et qu’on oublie. C’est pourtant elle qui décide de ce que le système pourra retrouver.

Un texte juridique illustre bien le problème :

un article de loi n’a de sens qu’avec son intitulé et sa place dans le code
une exception se trouve souvent trois alinéas après la règle
un renvoi vers un autre article ne veut rien dire sans cet autre article

Découper tous les 500 caractères, c’est séparer la règle de son exception.

Le bon découpage suit la structure du document, pas un compteur.

La qualité documentaire

On ne peut pas retrouver ce qui n’a pas été correctement lu.

Dans un projet réel, une partie importante des sources arrive sous forme de PDF scannés, de tableaux, de documents à deux colonnes ou de textes dont une version abrogée traîne encore dans le corpus.

Chacun de ces cas produit des erreurs silencieuses :

une reconnaissance de caractères approximative
un tableau transformé en bouillie de mots
deux versions contradictoires du même texte, toutes deux indexées.

Le système ne signale rien. Il répond simplement à côté.

Deux étapes et demie pour lire un document

Sur LEGIBUS, la lecture d’un document se fait en deux étapes et demie.

Étape 1 : un OCR classique. Une bibliothèque Python, rapide et efficace, mais limitée dès qu’il y a des images.

La demi-étape : une estimation du risque. Un modèle de vision évalue rapidement si l’OCR précédent a pu échouer. Y a-t-il des images ? Des tableaux complexes ?

Étape 2 : un OCR par IA, seulement si nécessaire. Quand le risque est avéré, un second OCR, fondé sur un modèle d’IA, relit le document, compare son résultat au premier et le complète.

La plupart des documents s’arrêtent à la première étape. Le traitement lourd est réservé à ceux qui en ont besoin.

Plus de contexte n’est pas mieux

Une tentation courante consiste à donner davantage d’extraits au modèle, en se disant qu’il fera le tri.

J’ai constaté l’inverse : chaque extrait hors sujet dilue les bons, et la réponse devient floue.

Un exemple m’a marqué. Sur une question concernant un site e-commerce, une vingtaine de jurisprudences pouvaient remonter. Certaines provenaient d’affaires concernant des pêcheurs. Ne me demandez pas pourquoi.

Le LLM s’appuyait quand même dessus, tout en précisant qu’elles n’avaient pas de rapport avec l’affaire.

Le modèle ne se trompait pas vraiment. Il faisait de son mieux avec ce qu’on lui avait fourni.

La correction n’était donc pas à chercher dans le modèle, mais dans tout ce qui l’encadre : nous avons renforcé notre harnais, c’est-à-dire la sélection et le filtrage des sources avant qu’elles ne lui parviennent.

Sans évaluation, on ne fait que deviner

Tout ce qui précède repose sur une condition : pouvoir mesurer.

Sans jeu de questions de référence, chaque réglage est jugé à l’impression. On corrige un cas, on en casse trois autres, et personne ne le voit.

Un dispositif minimal suffit pour commencer :

quelques dizaines de questions réelles, avec la réponse attendue et sa source
une mesure séparée pour la recherche et pour la génération
une exécution à chaque changement de découpage, d’index ou de prompt

C’est cette séparation qui change tout. Elle dit immédiatement où chercher.

Le test décrit plus haut n’a été concluant que pour cette raison : les deux pistes ont été jugées sur le même panel de questions, pas à l’impression.

Citer ses sources, ou se taire

Dans un domaine comme le droit, une réponse sans source n’a aucune valeur.

Obliger le système à citer le passage sur lequel il s’appuie a deux effets :

l’utilisateur peut vérifier en quelques secondes
une réponse impossible à sourcer devient visible, et peut être refusée

Un assistant qui sait dire « je n’ai pas trouvé » inspire plus confiance qu’un assistant qui a toujours une réponse.

Alors, quand changer de modèle ?

Il existe de bonnes raisons de le faire :

la recherche ramène les bons passages, et la réponse reste mal rédigée
le modèle ne suit pas les consignes de citation
le coût ou le temps de réponse ne sont plus tenables

Mais c’est la dernière étape, pas la première.

Conclusion

Le modèle est la partie la plus visible d’un système RAG, et la plus facile à remplacer.

C’est précisément pour cela qu’on s’y attarde trop.

Le travail utile est ailleurs, et il est moins spectaculaire : lire correctement les documents, les découper selon leur sens, filtrer ce que la recherche ramène, et mesurer le résultat.

Avant de demander :

« Quel modèle devrions-nous utiliser ? »

Je propose de commencer par :

« Savons-nous ce que notre système donne réellement à lire au modèle ? »