Glance : un seul modèle de 9B sélectionne lui-même les passages pour le RAG et dépasse le reranker

Un pipeline RAG classique garde deux modèles en mémoire. Un reranker trie d'abord les passages remontés par la recherche, puis un générateur lit les meilleurs et rédige la réponse. Les chercheurs du projet airun-ai proposent Glance : le générateur évalue lui-même les passages, et aucun reranker séparé n'est nécessaire.

Ils ont ajouté à un modèle de 9 milliards de paramètres gelé un adaptateur LoRA (un petit ensemble de poids affinés) et une « tête de pointage » de 256 dimensions. Chaque surcouche de ce type, ajoutée comme une « compétence », occupe environ 0,1 Gio. Il s'agit pour l'instant de résultats préliminaires : les tests portent sur deux jeux de données de recherche, un jeu de questions-réponses et une seule famille de modèles.

Une passe au lieu de vingt

Un cross-encoder classique (par exemple bge-reranker-v2-m3) encode chaque paire « requête — passage » séparément. Avec 20 candidats, cela fait 20 passes. Glance fonctionne autrement.

• Le modèle lit une seule fois tous les candidats et conserve un cache interne (prefill).
• De ce cache partent de courtes sondes d'environ 30 tokens : « Le passage N contient-il une information répondant à la requête ? »
• Les sondes ne se voient pas entre elles, mais chacune voit tous les passages et peut les comparer.
• La tête de pointage convertit l'état du modèle sur la sonde en score de pertinence. Aucun texte n'est généré.

Il existe aussi une variante, Glance-Activated. L'adaptateur n'y est activé que sur les tokens des sondes, les passages sont encodés avec les poids de base et la réponse se poursuit depuis le cache initial. Dans le mode principal, les passages sélectionnés (environ 1 500 tokens) sont relus avec l'adaptateur désactivé.

Le modèle de base, MiMo-V2.6-Distill-Qwen-9B de Xiaomi, est hybride : les couches d'attention linéaire Gated DeltaNet et d'attention classique alternent selon un rapport de 3:1. Les couches linéaires possèdent un état séquentiel unique, ce qui empêche d'assembler dans un ordre arbitraire les caches de passages individuels. Les auteurs ont donc choisi de copier les branches à partir de la fin du contexte commun, une méthode exacte.

Ce que montrent les mesures

L'évaluation repose sur le nDCG@10 : plus les documents pertinents sont haut dans les dix premiers résultats, plus la valeur se rapproche de 1. Les rerankers triaient le top 20 de BM25 (recherche textuelle classique).

• Sans entraînement sur des données de recherche, l'adaptateur obtient sur SciFact (affirmations scientifiques) 0,715, contre 0,729 pour vingt appels séparés du même modèle. Il est en revanche 3,6 fois plus rapide. Le cross-encoder obtient 0,721 sur SciFact.
• Sur NFCorpus (textes médicaux), le même mode atteint 0,341 contre 0,326 pour le cross-encoder. Les auteurs supposent que la comparaison des passages entre eux y contribue.
• Après 39 minutes d'entraînement sur MS MARCO (4000 requêtes, un GPU B200, pic de 21 Gio), le résultat monte à 0,741 sur SciFact et 0,345 sur NFCorpus. L'écart avec le cross-encoder est de 0,020 et 0,019. La significativité n'a pas été testée sur ces jeux de données, et les auteurs jugent indicatif tout écart inférieur à 0,02.

Sur HotpotQA (des questions dont la réponse exige de rassembler des faits issus de deux passages), les chercheurs ont retenu 300 questions de 10 passages chacune. Le cross-encoder retrouve plus souvent les bons passages : le rappel dans le top 2 est de 0,863 contre 0,762. Mais les réponses fondées sur la sélection de Glance sont meilleures : F1 de 0,718 contre 0,683 pour l'adaptateur non entraîné, et cet écart n'est pas statistiquement significatif.

Le résumé de l'article annonce un gain de +0,045 F1 pour la version affinée. Si l'on laisse l'adaptateur activé aussi pendant la réponse, le F1 monte à 0,757, soit 0,032 de moins que le plafond obtenu avec les deux passages de référence. Les réponses deviennent plus courtes (2,5 mots contre 3,1), ce qui convient mieux au format de HotpotQA.

Où la méthode atteint son plafond

L'avantage principal apparaît sur les longues listes de candidats. L'adaptateur affiné continue de s'améliorer jusqu'à 200 candidats (43 400 tokens) : le nDCG@10 est de 0,717 contre 0,659 pour le cross-encoder sur les mêmes 100 requêtes SciFact. Avec 100 candidats, l'écart est de 0,060 et le temps de 1,05 s par requête. L'adaptateur non entraîné se dégrade sur les grandes tailles, et sa qualité tombe à 0,505 à 65 000 tokens.

Le prix à payer :

• La mémoire croît plus vite que la longueur du contexte, de 15 à 56 Gio, car chaque sonde copie le cache d'attention.
• 200 candidats ne tiennent pas dans un seul appel : ils sont traités par lots, ce qui prend 15,8 s par requête.
• Regrouper plusieurs requêtes dans un même appel n'accélère pas le traitement : le débit chute de 2,87 à 1,57 requête par seconde.
• Le cross-encoder reste nettement plus rapide : 31–60 ms par requête contre environ 410–420 ms pour Glance entraîné sur B200.

Les auteurs proposent un cache par blocs commun, sans copies, qui rendrait la mémoire linéaire et permettrait de passer à des contextes de l'ordre de 128 000 tokens.

À qui cela peut servir

Le principal gain de Glance concerne la mémoire. Si un serveur héberge déjà un gros modèle pour générer les réponses, il n'a plus besoin de garder un second reranker : il peut commuter les adaptateurs à la demande. Les sorties restent identiques à celles que produirait chaque modèle chargé séparément. Pour les systèmes où la latence de quelques dizaines de millisecondes prime, un cross-encoder spécialisé reste plus avantageux. En revanche, pour classer des centaines de candidats ou choisir le contexte que le générateur utilise réellement, l'approche mérite d'être testée. Les adaptateurs et le code sont disponibles sur Hugging Face, dans le dépôt airun-ai/GlanceRAG-MiMo-9B-Reranker.