Étude et démonstrateur

Une aiguille chez Jules Verne

Christophe Cosnefroy ·

L’aiguille dans la botte de foin, partie 1 sur 7. Pourquoi retrouver une phrase dans un grand corpus reste difficile sur son propre matériel.

La série

  1. Une aiguille chez Jules Verne ← vous êtes ici
  2. Grand contexte : tout lire d’un coup
  3. RAG : le bibliothécaire et son catalogue
  4. Recherche hybride : quand les mots exacts comptent
  5. Recherche agentique : laisser le modèle chercher
  6. RLM : le modèle qui écrit sa propre recherche
  7. Le verdict : quelle architecture, pour quelle botte de foin

Le problème de toutes les entreprises

Quelque part dans les documents de votre entreprise, une phrase répond à la question du jour.

Une clause du contrat numéro 412. Un code d’erreur dans un rapport d’incident vieux de trois ans. Une posologie dans un manuel technique de 600 pages. La tolérance d’une pièce, enfouie dans le cahier des charges d’un fournisseur.

Les documents sont trop longs à lire, trop nombreux pour être fouillés à la main, et la réponse est minuscule. C’est l’aiguille dans la botte de foin. C’est aussi l’une des demandes que j’entends le plus souvent quand les entreprises parlent d’IA : « Est-ce qu’elle peut retrouver des choses dans nos documents ? »

La réponse honnête : cela dépend de l’architecture. Il y a plusieurs façons de construire ce service ; elles n’échouent pas de la même manière, et ces différences comptent bien plus que le choix du modèle.

Cette série en compare cinq, sur les mêmes données, sur la même machine, avec le même modèle.

Pourquoi ne pas passer par le cloud ?

Les modèles de pointe dans le cloud ont des fenêtres de contexte d’un million de tokens ou plus. Sur le test classique de l’aiguille dans la botte de foin, ils frôlent les 100 %. Pour beaucoup d’usages, la discussion s’arrête là.

Mais beaucoup d’entreprises ne peuvent pas, ou ne veulent pas, envoyer leurs documents à un modèle dans le cloud. Contrats, dossiers médicaux, savoir-faire industriel, tout ce qui relève d’une clause de confidentialité. Pour elles, la question devient : que peut-on faire sur un matériel que l’on possède ?

Cela change tout :

  • Des modèles plus petits. Des modèles ouverts qui tiennent sur une seule machine, en général quantifiés (compressés) pour tenir en mémoire.
  • Des fenêtres plus petites, en pratique. Le modèle accepte peut-être 262 000 tokens, mais la mémoire et la vitesse décident de ce qui est utilisable.
  • De vrais coûts. Chaque seconde de calcul est la vôtre. Six minutes pour lire un document, ce n’est pas une abstraction : c’est votre machine, occupée.

Les scores quasi parfaits du cloud disent peu de chose de cette situation. Alors je l’ai mesurée.

Les cinq architectures

Imaginez vos documents comme une bibliothèque, et l’aiguille comme une phrase glissée dans un livre. Chaque architecture est une façon différente de la retrouver.

Architecture En termes de bibliothèque Force attendue Faiblesse attendue
Grand contexte Le lecteur mémorise tous les livres d’un coup, puis répond Voit tout, rien à construire Limité par la mémoire ; lent à « lire » ; l’attention se dilue au milieu
RAG (Retrieval Augmented Generation) Un bibliothécaire doté d’un catalogue par le sens tend les pages les plus proches Rapide, s’adapte à toutes les tailles Rate les aiguilles formulées autrement que la question
Recherche hybride Le même bibliothécaire, avec un second index par mots exacts, puis une seconde vérification des meilleures pages Attrape aussi les noms et codes exacts Toujours en un seul coup : mauvaises pages en entrée, mauvaise réponse en sortie
Recherche agentique Le lecteur parcourt les rayons, cherche, ouvre les livres et décide quand s’arrêter Adapte sa stratégie à la question Dépend du jugement du modèle ; peut tourner en rond ou abandonner
RLM (Recursive Language Models) Le lecteur écrit de petits programmes pour découper la bibliothèque et confie des morceaux à des copies de lui-même Traite des volumes bien plus grands que sa mémoire Exige un code fiable ; plus difficile à sécuriser et à déboguer

Deux questions les distinguent :

  1. Quand le travail a-t-il lieu ? À l’indexation (RAG, recherche hybride : on prépare la bibliothèque à l’avance) ou au moment de la question (grand contexte, recherche agentique, RLM : le modèle travaille quand on lui demande).
  2. Qui décide où chercher ? Un pipeline conçu par un ingénieur (RAG, hybride) ou le modèle lui-même (recherche agentique, RLM).

Le grand contexte est à part : personne ne décide où chercher, puisque le modèle regarde tout.

Le banc d’essai

Une machine

Un ASUS Ascent GX10 : une puce NVIDIA GB10, 128 Go de mémoire partagée entre le processeur et le GPU. C’est le genre de machine qu’une petite entreprise, ou un service, peut acheter et faire tourner dans un bureau.

Un modèle

Le même modèle pour les cinq architectures, avec les mêmes réglages. Sinon, la comparaison mesure des modèles, pas des architectures. Pour cette série : Qwen3.8-27B, un modèle ouvert quantifié en NVFP4, servi par vLLM.

Certaines architectures ont besoin d’un second modèle, bien plus petit, pour construire leur index. Pour le RAG et la recherche hybride, c’est Qwen3-Embedding-0.6B. Le modèle qui lit et qui répond est toujours le même.

Une botte de foin : Jules Verne

Le corpus, c’est l’œuvre de Jules Verne en français. Il existe en quatre tailles imbriquées, de quelques chapitres à 33 romans :

Palier Contenu Taille approx.
T1 Premiers chapitres de Vingt mille lieues sous les mers 26 000 tokens
T2 Le roman entier 236 000 tokens
T3 7 romans ~1,1 million de tokens
T4 33 romans ~5 millions de tokens

Chaque palier contient le précédent. Vingt mille lieues se trouve au milieu de T3 (de 33 % à 54 % du texte) et près du début de T4 (de 8 % à 13 %), entouré d’autres romans.

Entre T2 et T3, le grand contexte devient impossible sur cette machine : la bibliothèque ne tient tout simplement plus. L’endroit où chaque architecture casse est le résultat phare de la série.

Des aiguilles impossibles à tricher

Un roman célèbre pose un problème : le modèle l’a probablement lu. Demandez-lui qui commande la frégate lancée à la poursuite du monstre marin, il risque de répondre « Farragut » de mémoire, sans lire le texte que vous lui avez donné. Cela ressemblerait à une recherche réussie et ne prouverait rien.

Alors au lieu d’ajouter des phrases, je modifie des faits déjà présents dans le livre, partout où ils apparaissent. Farragut devient Whitcombe. Le Maelström devient le Corryvreckan. 1866 devient 1858.

Chaque réponse a alors un sens précis :

  • le fait modifié : le modèle a lu le texte ;
  • le fait d’origine : le modèle a répondu de mémoire et ignoré le texte ;
  • les deux : il a lu le texte mais n’a pas su lâcher ce qu’il savait ;
  • « not found » : il a cherché et abandonné, ce qui vaut mieux qu’inventer.

Avant chaque test, chaque question est aussi posée sans aucun texte, pour enregistrer ce que le modèle sait de mémoire. Cette référence indique si une bonne réponse signifie « l’a trouvé » ou « a surmonté ce qu’il savait ». Sans le texte, le modèle n’a jamais donné une seule réponse modifiée.

Quand la bibliothèque grandit, les pièges aussi

Les autres romans ont soulevé une question que je n’avais pas anticipée : que se passe-t-il quand un autre livre parle de la même chose ?

Verne réutilise sa propre matière. L’Île mystérieuse raconte à nouveau la fin du capitaine Nemo, y compris la frégate qui a traqué le Nautilus. Mistress Branican évoque les récifs où se sont perdus les navires de La Pérouse. Quand un autre livre parle du même fait, je le modifie là aussi, pour que la bibliothèque raconte une histoire cohérente.

Quand il s’agit d’une autre chose portant le même nom, je n’y touche pas. Un autre roman a son propre navire nommé Scotia ; d’autres mentionnent un 21 mars, une année 1866, la baie de Vigo en passant. Ceux-là restent tels que Verne les a écrits.

C’est réaliste. Dans les archives d’une vraie entreprise, le même nom désigne des choses différentes selon les documents, et un bon système doit savoir les distinguer. C’est aussi là que se produisent certains des échecs les plus intéressants, comme le montre la partie 3.

Ce qui est mesuré

Pour chaque réponse :

  • juste ou non, et si elle vient du texte ou de la mémoire ;
  • le temps total, et pour le grand contexte, le temps jusqu’au premier mot, parce que c’est là qu’est son coût : lire tout le texte avant de répondre ;
  • les tokens lus et écrits ; le compte des tokens écrits inclut le raisonnement du modèle ;
  • pour les architectures qui cherchent, si le bon passage est arrivé jusqu’au modèle, ce qui distingue « ne l’a pas trouvé » de « l’a trouvé mais mal lu » ;
  • le nombre d’appels au modèle et aux outils (pour la recherche agentique et RLM).

Pour chaque architecture : le coût de préparation (construire un index) et les modes d’échec, parce que la façon dont un système échoue compte autant que la fréquence.

Le bruit

Chaque question est posée plusieurs fois, avec les mêmes réglages, et les résultats sont regroupés.

J’ai appris pourquoi à mes dépens. J’ai lancé deux fois la même configuration RAG, sur le même index, avec trois répétitions par question. Sur les 15 questions dont le texte n’avait pas changé entre les deux passages, elle a obtenu 76 % la première fois et 67 % la seconde. Avec trois répétitions par question, un écart de 10 points peut relever du pur hasard. Les chiffres de cette série sont donnés avec la taille de leur échantillon, et les écarts plus petits que le bruit ne sont pas présentés comme des résultats.

Trois règles que je m’impose

Tout identique, sauf l’architecture. Même modèle, mêmes réglages, même consigne, même format de réponse. Si une option a droit à une meilleure consigne, la comparaison ne vaut plus rien.

Les données de test sont du code. Les aiguilles sont produites par des scripts, versionnées et vérifiées avant chaque passage. Une modification ratée du texte produirait un résultat qui ressemble à une découverte.

Publier le bruit. Un résultat qui change d’un lot à l’autre est donné avec son intervalle, pas comme un chiffre unique.

La suite

La partie 2 commence par l’architecture la plus simple de toutes : le grand contexte. Mettre tout le roman dans une seule consigne, 236 000 tokens, et poser la question.

Petite révélation : cela marche mieux que je ne l’imaginais ; ce n’est pas uniforme d’un bout à l’autre du livre, et quand cela échoue, cela échoue de la façon qu’on souhaiterait.