Reranking RAG avec Jev : notre usage réel en production

Une question arrive dans l'assistant. L'agent lance deux recherches sémantiques et une recherche par mots-clés. Résultat : 19 extraits, tirés de 8 documents différents. Certains répondent pile à la question, d'autres parlent du bon sujet sans répondre, quelques-uns sont là parce qu'un mot-clé les a accrochés.

Avant le 24 septembre 2026, ces 19 extraits seraient partis tels quels vers le LLM chargé de rédiger la réponse. Depuis, Jev, le modèle de TypeSafe AI, les note un par un avant. Sur cette recherche-là, il en a gardé 8.

Cet article raconte ce reranking RAG tel qu'il tourne chez nous. Où Jev se branche, puis ce que montre sa première journée en production sur les notes attribuées, les extraits gardés, le temps de réponse et le coût.

1. Le problème : trop d'extraits, pas assez de signal

Un RAG d'entreprise sérieux combine plusieurs voies de recherche : sémantique, mots-clés, parfois métadonnées. C'est ce qui lui permet de retrouver aussi bien « travail à distance » que la référence XOD1132 (nous l'avons détaillé dans notre article sur la recherche hybride).

Le revers est mécanique. Chaque voie ramène ses candidats, on fusionne, on dédoublonne, et on se retrouve avec plus d'extraits que le LLM ne peut en exploiter. Dans le lot, il y a des faux positifs (le mot-clé est là, le sujet non), des quasi-doublons (le même paragraphe dans trois documents) et des extraits qui tournent autour du sujet sans répondre à la question.

Le LLM de réponse sait souvent faire le tri seul. Pas toujours. Et quand il le fait, il paie chaque token lu, son attention se dilue, et il lui arrive de citer la mauvaise source. Le reranking est l'étape qui s'intercale entre la recherche et la génération : on note chaque extrait, on réordonne, et on ne garde que le meilleur.

2. Jev, l'IA de TypeSafe qui répond par une probabilité

Jev est sorti le 15 septembre 2026. TypeSafe AI, une société de San Francisco, le présente comme son premier modèle « System One » : un modèle qui ne génère pas de texte. On lui envoie un état (du JSON) et des questions fermées, il renvoie des décisions typées.

Pour notre usage, un seul type de question compte : la question « noul », une question oui/non à laquelle Jev répond par la probabilité que la réponse soit oui, entre 0 et 1.

La question que nous posons pour chaque extrait est la suivante, mot pour mot :

Is this chunk relevant to answer, at least partially, at least one of the search queries?

Deux détails comptent dans cette phrase. « Au moins partiellement », parce qu'un extrait qui apporte la moitié de la réponse doit rester. « Au moins une des requêtes », parce que l'agent lance souvent plusieurs recherches pour une même question, et qu'un extrait utile pour l'une d'elles ne doit pas être écarté parce qu'il ignore les autres.

Côté code, nous avons verrouillé notre intégration de l'IA Jev sur ce seul mode : toute tentative de s'en servir pour du chat, de la complétion, de l'OCR ou des embeddings lève une erreur. Jev fait une chose dans notre plateforme, et une seule.

3. Où Jev se branche dans notre RAG

Jev n'intervient ni à l'ingestion, ni à l'indexation, ni dans le calcul des embeddings. Il agit à la toute fin de la recherche documentaire, sur la liste d'extraits déjà construite, juste avant qu'elle soit transmise au LLM.

Loading diagram…

Le schéma suit une recherche documentaire dans l'assistant : l'agent interroge l'index par le sens et par les mots-clés, les résultats sont fusionnés et regroupés par document, puis Jev note chaque extrait en parallèle. L'agent ne reçoit que les extraits retenus, dans l'ordre de pertinence, et rédige sa réponse à partir d'eux.

Pour chaque extrait candidat, nous envoyons à Jev un état de cette forme :

{
  "semantic_queries": ["délai de préavis en cas de démission d'un cadre"],
  "keyword_queries": ["préavis", "démission", "cadre"],
  "document_name": "Convention collective 2025.pdf",
  "chunk_content": "Article 12. En cas de démission, la durée du préavis est fixée à..."
}

Les appels partent tous en parallèle, un par extrait.

Le couple RAG + Jev se distingue là d'un reranker classique. Jev reçoit à la fois les requêtes sémantiques, les mots-clés et le nom du document, et juge l'extrait au regard de toute la recherche.

Une fois les notes reçues, les extraits les moins pertinents sont écartés, et les documents sont réordonnés selon le meilleur score de leurs extraits. Le LLM de réponse ne voit pas les scores : il reçoit simplement une liste plus courte et mieux ordonnée.

Dernier effet, moins visible : nos statistiques « quels documents ont servi à cette réponse » ne comptent plus que les extraits gardés par Jev. Un document écarté ne gonfle plus artificiellement son taux d'usage.

4. Une note qu'on sait lire, même en recherche par mots-clés

Classer les extraits, la recherche le fait déjà. Nous, on veut savoir autre chose : est-ce qu'on sait répondre ? Parmi ce qui est remonté, y a-t-il de quoi construire une réponse fiable ?

En recherche sémantique, on a déjà un indice. Le score de similarité entre la question et l'extrait se lit assez bien : un extrait très proche a de bonnes chances d'être pertinent, un extrait lointain beaucoup moins.

En recherche par mots-clés, c'est une autre histoire. Le score dépend du nombre d'occurrences, de la rareté des termes, de la longueur de l'extrait. Il sert à classer les résultats d'une même requête entre eux, mais sa valeur absolue ne veut pas dire grand-chose : un score de 12 n'est pas « deux fois plus pertinent » qu'un score de 6, et il ne se compare pas d'une requête à l'autre.

Jev règle ce problème. Il pose la même question à chaque extrait, quelle que soit la voie qui l'a trouvé, et renvoie une probabilité entre 0 et 1 qui se lit de la même manière partout. Un extrait remonté par un mot-clé et un extrait remonté par le sens se retrouvent enfin sur la même échelle : celle de leur utilité pour répondre.

5. Usage de Jev en production : les notes et les extraits gardés

Voici ce que montre la première journée de production, le 24 septembre 2026. Une recherche passée par Jev comptait entre 8 et 20 extraits, 10 en médiane, issus de 5 documents en médiane.

Les notes attribuées

Premier constat : les notes sont plutôt hautes. La note médiane est de 0,80, 70 % des extraits dépassent 0,5, et seuls 2 % tombent sous 0,1. Ces notes hautes disent surtout que la recherche documentaire en amont fait bien son travail, puisque l'essentiel de ce qu'elle remonte est déjà pertinent. Jev n'a plus qu'à écarter ce qui dépasse.

Il ne répond pas pour autant « oui » à tout. Sur plus d'une recherche sur deux, l'écart entre la meilleure et la moins bonne note dépasse 0,5, et c'est cet écart qui permet de trier.

Les extraits gardés

En moyenne, une recherche arrive avec 10,7 extraits et repart avec 7,7. Jev écarte donc un peu plus d'un extrait sur quatre, et ce sont les moins bien notés : ceux qui auraient le plus dilué la réponse.

6. Temps de réponse : ce que Jev ajoute

Tous les appels d'une recherche partent en même temps. La recherche complète ne prend donc guère plus que l'appel le plus lent, et le temps ajouté ne dépend pas du nombre d'extraits : une recherche de 20 extraits n'attend pas plus longtemps qu'une recherche de 8.

Il dépend en revanche de la longueur des extraits : plus un extrait est long, plus Jev met de temps à le lire. Le reranking ajoute donc un délai court à la recherche documentaire. Nous pensons pouvoir encore le réduire, et c'est en cours.

Et si Jev ne répond pas, l'assistant répond quand même : il reçoit la liste complète des extraits, comme avant le 24 septembre.

7. Ce que ça coûte

Jev est facturé sur les tokens d'entrée : 0,042 $ par million de tokens. La sortie, une probabilité, est négligeable.

Sur la première journée, avec des extraits de 1 600 tokens en moyenne, cela donne 0,0007 $ par recherche, soit environ 0,70 $ pour 1 000 recherches.

À ce prix, la facture ne pèse rien. Ce que nous surveillons, c'est le temps ajouté.

Chaque appel est tout de même tracé dans notre monitoring (fournisseur, tâche, tokens, coût, organisation, conversation), comme n'importe quel appel à un LLM.

8. Pourquoi Jev plutôt qu'un autre reranker

Jev n'est pas notre premier essai de reranking. Les solutions que nous avions testées avant lui ne présentaient pas ce rapport entre coût, délai et qualité.

Au-delà des chiffres, la différence tient pour nous à la question. Un reranker classique applique la pertinence qu'il a apprise. Avec Jev, nous l'écrivons : « au moins partiellement », « au moins une des requêtes ». Si demain nous voulons écarter les extraits obsolètes, il suffira de transmettre la date du document et d'ajuster la phrase, sans modèle à réentraîner.

9. Pourquoi Jev n'est actif qu'en politique Worldwide

Chaque organisation cliente choisit sa politique IA : UE uniquement ou Worldwide.

TypeSafe AI est une société américaine. Envoyer des extraits de documents à Jev, c'est transférer du contenu client à un fournisseur hors de l'Union européenne. Nous l'avons donc réservé à la politique Worldwide, comme nos autres fournisseurs non européens.

Concrètement, dans notre table de routage, la tâche « pertinence des extraits » n'existe que pour la politique Worldwide. Une organisation en UE uniquement n'a pas de reranking Jev : sa recherche fonctionne exactement comme avant le 24 septembre. Aucune case à cocher, donc aucun risque de l'oublier : pour ces organisations, la tâche n'existe pas.

C'est le même raisonnement que nous appliquons partout, et que nous avons détaillé dans notre article sur ce qu'il y a derrière le mot « souverain » : la localisation d'un serveur ne suffit pas, il faut regarder qui opère le modèle.

10. Comment nous l'avons validé avant de l'activer

Nous n'avons pas branché Jev en production sur la foi d'une annonce. L'usage réel de Jev a d'abord été simulé hors production :

1. un script relit, dans notre base, de vraies recherches documentaires passées, avec exactement la liste d'extraits que le LLM avait reçue ;
2. il repose à Jev la même question, extrait par extrait ;
3. il produit un rapport (tableur et PDF) qui met côte à côte chaque extrait, sa note et la décision garder / écarter ;
4. ces rapports ont été relus à la main, extrait par extrait, pour vérifier que ce qui était écarté méritait de l'être.

Ces simulations n'alimentent pas le monitoring de production : elles ne faussent ni nos coûts ni nos statistiques. Nos règles de sélection viennent de cette relecture.

Et la mise en production reste réversible : un interrupteur coupe le reranking pour toute la plateforme, sans toucher au code.

L'approche Ask This Guy

Jev montre comment nous intégrons un nouveau modèle : un seul rôle, une place précise dans la chaîne, un plan B s'il ne répond pas, un suivi appel par appel et le respect de la politique IA de chaque client.

Nos clients n'ont rien à configurer. Si leur organisation est en politique Worldwide, leurs recherches documentaires sont filtrées par Jev depuis le 24 septembre. Si elle est en UE uniquement, rien ne change pour eux. La documentation détaille quelles données transitent vers quels fournisseurs.

Questions fréquentes sur le reranking RAG avec Jev

Qu'est-ce que le reranking dans un RAG ?

Le reranking est une seconde étape de tri entre la recherche et la génération. La recherche (sémantique, par mots-clés ou les deux) ramène une liste large de candidats. Le reranker note chacun d'eux par rapport à la question, les réordonne et, dans notre cas, écarte les moins pertinents. Le LLM de réponse travaille ensuite sur un contexte plus court et mieux ordonné.

Jev est-il un LLM ?

Non. Jev ne génère pas de texte. Il reçoit un état structuré et des questions fermées, et renvoie des réponses typées, par exemple une probabilité pour une question oui/non. C'est ce qui le rend adapté au reranking : on ne lui demande pas de rédiger, seulement de décider si un extrait est pertinent.

Jev remplace-t-il la recherche vectorielle ?

Non. Jev n'a pas accès à l'index et ne cherche rien. Il note des extraits que la recherche sémantique et la recherche par mots-clés ont déjà trouvés. Sans une bonne recherche en amont, il n'a rien de bon à garder.

Combien d'extraits Jev garde-t-il ?

Sur notre première journée en production, une recherche arrivait en moyenne avec 10,7 extraits et repartait avec 7,7. Jev écarte donc un peu plus d'un extrait sur quatre, en commençant par les moins bien notés.

Combien coûte Jev pour du reranking ?

Jev est facturé 0,042 $ par million de tokens en entrée. Sur notre première journée en production, avec des extraits de 1 600 tokens en moyenne et 10 extraits par recherche en médiane, cela représente environ 0,0007 $ par recherche, soit 0,70 $ pour 1 000 recherches.

Quel temps de réponse ajoute Jev à un RAG ?

Un délai court. Tous les appels d'une recherche partent en parallèle, si bien que le temps ajouté dépend de la longueur des extraits, pas de leur nombre. Si Jev ne répond pas, l'assistant répond quand même, avec la liste complète des extraits.

Peut-on utiliser Jev avec une exigence de données en Europe ?

TypeSafe AI est une société américaine. Chez Ask This Guy, Jev n'est donc actif que pour les organisations en politique IA Worldwide. Les organisations en politique UE uniquement n'envoient aucun extrait à Jev, et leur recherche documentaire fonctionne sans cette étape de reranking.

---

Conclusion

Une journée de production ne fait pas un bilan définitif, mais elle dit déjà l'essentiel. Jev fait bien ce qu'on lui demande : il écarte plus d'un extrait sur quatre et donne à chaque extrait une note lisible, pour un coût négligeable. Sa limite tient au temps qu'il ajoute à la réponse. C'est là que portera notre prochain travail, et nous publierons les chiffres quand il sera en place.

Si vous voulez voir ce que donne une recherche documentaire filtrée sur vos propres documents, réservez une démo. L'approche complète est sur la page RAG entreprise clé en main.