Le reranker menteur

Chapitre 3 — Le reranker menteur

Dans le jargon technique du RAG, il y a une figure clé, peu glamour et peu racontée : le reranker. Imaginez la recherche d'entreprise comme l'entrée d'une discothèque. La base de données vectorielle est le portier : il regarde rapidement la foule et fait entrer trente candidats qui, à première vue, ressemblent à ce que vous cherchez. Le reranker est le videur : il prend ces trente personnes, les examine attentivement, en sélectionne cinq — ceux que le LLM lira réellement pour construire la réponse — et renvoie les vingt-cinq autres. C'est une fonction petite mais énorme : s'il se trompe, tout le monde se trompe. Si le videur ne sait pas lire les visages, le lieu se remplira des mauvaises personnes et personne ne comprendra jamais pourquoi la soirée s'est mal passée.

En 2025, plusieurs services cloud sont apparus sur le marché offrant des rerankers sous forme d'API. Vous envoyez une question et une liste de documents, ils vous renvoient des scores. Pratique, évolutif, pas de GPU à acheter, pas de modèles à télécharger. Un célèbre fournisseur européen de modèles — sans citer de noms, mais vous savez quels noms nous évitons — exposait un modèle prometteur de la famille Qwen, de quatre milliards de paramètres, étiqueté « Reranker ». Le prix était raisonnable, la latence acceptable. N'importe qui, à ce moment précis de l'histoire, l'aurait choisi. Beaucoup l'ont choisi.

Sauf que les scores étaient incorrects. Pas "légèrement" incorrects, comme cela peut arriver à n'importe quel modèle : incorrects structurellement. Des documents manifestement pertinents obtenaient 0,2, des documents hors sujet obtenaient 0,8. Les premiers soupçons, comme toujours dans ces cas, se sont portés sur les coupables habituels : le modèle d'embedding, le chunking, la formulation de la requête, le prétraitement des documents. Des semaines d'enquêtes sur de fausses pistes. Ce n'est qu'en comparant systématiquement les réponses du reranker cloud à celles d'un reranker local de référence — la même entrée, les mêmes documents, les scores côte à côte sur une feuille Excel — que la vérité inconfortable est apparue : le modèle exposé via l'API était cassé. Peut-être une erreur de déploiement, peut-être une mauvaise version chargée par erreur, peut-être un bug dans la sérialisation des scores. Le fournisseur ne l'a jamais admis formellement. Le problème, cependant, a simplement disparu un jour, après une mise à jour silencieuse et aucune modification des notes.

L'objet de cette histoire n'est pas « les services cloud se trompent » — tout le monde se trompe, même les modèles locaux se trompent. Le point est plus subtil : dans un RAG sérieux, le reranker est une pièce à laquelle vous devez pouvoir regarder à l'intérieur. Si c'est une boîte noire payante, et si ses sorties sont des nombres qui semblent plausibles même lorsqu'ils sont aléatoires — et les scores d'un reranker semblent toujours plausibles, car ce sont des nombres entre zéro et un avec quelques décimales —, vous n'avez aucun moyen de comprendre ce qui ne va pas dans votre système. Et comme le reranker est « vers la fin » de la chaîne de traitement, son erreur contamine chaque évaluation en amont : la recherche semble lente, la requête erronée, les embeddings pauvres. En réalité, c'est le videur qui ne sait pas lire les visages, et vous remettez en question les vitres de la porte.

Le choix contre-courant de certaines équipes, ces derniers mois — au lieu d'aller vers davantage de cloud, de revenir en arrière — a été de ramener le reranker à la maison. Un modèle open source de la famille BGE, pas gigantesque, exécuté sur GPU local (même sur Apple Silicon, avec quelques précautions concernant les pilotes). Plus de travail de gestion, c'est vrai. Mais la possibilité de mener des expériences contrôlées, de comprendre quand il se trompe, de comparer les versions, de conserver un historique. Et — non négligeable — de ne pas verser à l'API une fraction de centime pour chaque recherche utilisateur. Fraction qui, multipliée par des dizaines de milliers de requêtes par mois, cesse rapidement d'être une fraction et devient une ligne de budget.

Quand un composant est si critique que son dysfonctionnement corrompt toute votre capacité à mesurer le reste, alors le déléguer à une boîte noire n'est pas de l'efficacité. C'est un acte de foi. Et les actes de foi, en production, se paient à intérêts composés.