Un RAG classique repart des documents bruts à chaque question. Le RAG correctif, le modèle Jev et le LLM Wiki proposent chacun une autre façon de travailler. Une étude récente sur le « plafond de rappel » rappelle une règle en amont de tout cela : on ne reclasse pas ce qu'on n'a pas retrouvé.

L'enjeu n'est pas de demander à un modèle de tout refaire à chaque appel, mais d'organiser une fois, de mesurer ce que la recherche retrouve, de décider vite sur les questions fermées et de vérifier chaque étape.

Le RAG et ses trois limites

Un RAG (génération augmentée par recherche) découpe les documents en morceaux (chunking) et les transforme en vecteurs (embeddings) stockés dans une base vectorielle. La question est elle aussi convertie en vecteur. La recherche par K plus proches voisins sélectionne les morceaux les plus proches selon la similarité cosinus. Le LLM (grand modèle de langage) s'appuie ensuite sur ces morceaux pour répondre.

Trois problèmes se posent. Une question mal formulée oriente mal la recherche. Des morceaux hors sujet peuvent être transmis au modèle. Enfin, le LLM hallucine quand sa réponse ne s'appuie pas sur les morceaux retrouvés.

Plusieurs techniques y répondent. La reformulation multi-requête lance plusieurs recherches avec des variantes de la question. HyDE cherche avec une réponse hypothétique rédigée par le LLM : elle a la forme et la longueur d'un vrai document, alors que la question brute est plus courte. Le reclassement se fait en deux temps : une recherche vectorielle rapide sélectionne une cinquantaine de candidats, puis un cross-encoder, qui lit ensemble la question et chaque morceau, les reclasse. Le RAG correctif, lui, vérifie que les morceaux sont pertinents et que la réponse s'appuie bien sur eux. Sinon, il reformule la question ou régénère la réponse.

Le plafond de rappel

L'étude de Zhaohui Wang, acceptée à la conférence CIKM 2026, porte sur la recommandation : une recherche sélectionne K candidats parmi des millions d'articles, puis un LLM les reclasse.

flowchart LR
  A["Millions d'articles"] --> B["Recherche : K candidats"]
  B --> C["Reclassement par LLM"]
  C --> D["10 premiers"]
  A -.->|"non retrouvé"| X["Perdu : aucun reclasseur ne le rattrape"]

Beaucoup d'évaluations utilisent un protocole « oracle » : le bon article est garanti dans la liste, soit injecté parmi les candidats, soit comparé à des articles tirés au hasard. Sur trois jeux de données Amazon, ce protocole surestime de 92 à 95 % la NDCG@10, un score de qualité des dix premières places.

En conditions réelles, le rappel (recall, la part des éléments pertinents présents parmi les candidats) n'atteint que 2 à 19 % à K = 100, sur huit jeux de données dans trois domaines. L'auteur démontre une borne : sous évaluation leave-one-out, où un élément pertinent est mis de côté pour le test, E[NDCG@k] ≤ Recall@|W|, W étant la liste de candidats du reclasseur. Autrement dit, aucun reclasseur ne place en tête un élément absent de sa liste.

Ce qui a été testé Résultat sur les principaux jeux Amazon
Consignes (prompts), modèles couvrant un facteur 168 en nombre de paramètres, ajustement LoRA, reclasseurs supervisés Aucun ne bat de façon significative le filtrage collaboratif, qui recommande ce qu'ont aimé des utilisateurs aux goûts proches.
Donner au LLM les scores du filtrage collaboratif Le LLM recopie surtout leur ordre.
Recherche qui tient compte du texte Le rappel monte sur un jeu de données, le résultat final non.

L'auteur propose RAEP (protocole d'évaluation tenant compte du rappel) : mesurer d'abord le rappel de la recherche, puis ne comparer les reclasseurs que là où le plafond laisse de la marge. Sa conclusion : quand le rappel est faible, améliorer la recherche compte plus que sophistiquer le reclasseur. Il précise que cela peut ne pas valoir en production, avec un meilleur rappel, des signaux plus riches ou un retour des utilisateurs en ligne.

L'étude ne porte pas sur le RAG documentaire. Mais la borne vaut pour toute chaîne en deux temps : le cross-encoder ne remonte qu'un morceau déjà présent parmi les cinquante candidats. Il faut donc mesurer le rappel de la recherche avant d'investir dans le reclassement ou dans un modèle plus gros. Et une évaluation qui injecte le bon morceau dans les candidats flatte le système.

Jev, une décision calibrée

Diogo Almeida, co-inventeur du RLHF chez OpenAI et cofondateur de TypeSafe AI, dit : « nous avons mis la main sur quelque chose d'exceptionnel et pourtant ce n'est pas utile ». Jev est un « système 1 », rapide et intuitif selon Kahneman. Il repose sur les Transformers, mais ne génère pas de texte. Choice, Score et Noul renvoient des décisions au format défini, accompagnées d'une probabilité calibrée, c'est-à-dire ajustée pour correspondre au taux réel de bonnes réponses. Jev est entraîné sur des données synthétiques par RLCD, un apprentissage par renforcement pour décision calibrée.

Chiffre annoncé Réserve
Latence : 70 à 500 millisecondes, contre 3 à 9 secondes pour un LLM classique. TypeSafe reconnaît que la démonstration à 0,114 s contre 8,566 s pour GPT-5.6 Terra était volontairement simplifiée.
Prix : 0,042 dollar par million de jetons en entrée, sortie gratuite, contre 2 et 12 dollars par million pour GPT-5.6 Terra. TypeSafe ne peut pas prouver que son prix n'est pas subventionné.
Adoption : près de 13 % des équipes payantes sur la passerelle Vercel en 24 heures, un record. Rien ne dit que cette adoption durera. Les évaluations restent internes, et TypeSafe présente lui-même ses chiffres « 193,6× plus rapide, 444,6× moins cher », arrondis par Vercel à 194×/445×, comme une fourchette haute.

Le « 0 % d'hallucination » est garanti par le format de sortie : ce n'est pas une mesure d'exactitude. The Register juge la comparaison avec un LLM inéquitable, puisque Jev ne produit pas de langage.

Chez SynapxLab

Notre recherche « par notion » sur dictionnaire.synapx.fr (174 708 mots) est un RAG. Elle utilise des embeddings bge-m3, calculés en local, en 1 024 dimensions, sur les définitions. La requête « outil pour couper le bois » renvoie xylocope, guillaume et frison. Faute de GPU, nous avons testé le reclassement par cross-encoder et la fusion par RRF des recherches par mots et par vecteurs. Les deux dégradaient le premier résultat : nous les avons écartés.

Ce constat va dans le sens de l'étude, mais il ne la confirme pas : nous n'avons jamais mesuré notre rappel. Nous ignorons donc si l'échec venait d'une bonne définition absente des candidats ou du reclasseur lui-même. La prochaine étape est de constituer un petit jeu de questions dont on connaît les bons mots, de mesurer le rappel à K = 50 et K = 100, puis seulement de tester HyDE, qui agit sur la recherche et donc sur le plafond. Rien de cela n'est encore fait.

Nos vecteurs ne sont pas des décisions. bge-m3 mesure une distance entre deux textes, sans qu'aucune question soit posée. Une probabilité calibrée, elle, répond à une question définie à l'avance. Un « Jev de poche » pourrait combler cet écart dans un micro-service. Le mot et sa définition deviennent un vecteur. Une régression logistique lui attribue une note. Une calibration de Platt ou isotonique transforme cette note en probabilité. Un seuil à 0,95 décide s'il faut appliquer le résultat ou le soumettre à un humain. Les données existent déjà : 34 180 domaines sur 260 possibles, 30 621 notes de qualité, environ 600 registres arbitrés à la main. Le premier chantier consisterait à attribuer un domaine aux 32 228 mots créés le 22 septembre 2026 qui n'en ont pas. Rien de cela n'est encore fait non plus.

flowchart LR
  A["Vecteur bge-m3"] --> B["Régression logistique"]
  B --> C["Calibration"]
  C --> D{"Seuil 0,95"}
  D -->|"≥ 0,95"| E["Appliquer"]
  D -->|"< 0,95"| F["Relecture humaine"]

Le LLM Wiki

Andrej Karpathy propose de ne plus repartir des documents bruts à chaque question. Le modèle rédige et tient à jour un wiki tiré des sources. Chaque nouvelle source l'enrichit, et les contradictions y sont notées. Un petit fichier de règles garde l'ensemble cohérent. Ce wiki ne remplace pas les sources : mieux vaut les conserver et relire ce que le modèle produit. Pour une question isolée, il coûte aussi plus cher qu'un RAG. C'est déjà ainsi que nous suivons l'état d'un projet : fichier d'état, déclarations de session et mémoire de faits datés, relus par un humain.

Ces approches se complètent, dans l'ordre. Le wiki et l'indexation organisent le savoir. La recherche retrouve, et son rappel se mesure avant tout reclassement. Jev ou un classifieur calibré tranchent les questions fermées. Le RAG correctif et le seuil humain contrôlent le résultat. Chez nous, la mesure du rappel, HyDE et le classifieur calibré restent à construire et à prouver.

Pour aller plus loin