Résumé Technique : LightRetriever

Problématique

Les systèmes actuels de recherche de texte basés sur les grands modèles de langage (LLM) emploient généralement des architectures de double encodeur symétriques, où les documents et les requêtes sont tous deux traités par des LLM profondément paramétrés pour générer des représentations denses ou creuses. Bien que cette approche améliore considérablement les capacités de recherche grâce à une modélisation contextuelle profonde, elle introduit un goulot d'étranglement critique lors du déploiement en ligne. Les documents peuvent être pré-encodés et indexés hors ligne, mais les requêtes de recherche arrivent en temps réel et nécessitent un encodage immédiat. Servir un LLM de taille complète pour l'inférence de requêtes sur des serveurs en ligne (par exemple, des GPU A800) entraîne une latence élevée, un faible débit et une consommation de ressources excessive. L'article pose une tension fondamentale : si les documents bénéficient d'un calcul intensif pré-calculé, les encodeurs de requêtes doivent opérer sous des contraintes en ligne strictes, pourtant les méthodes existantes forcent les requêtes à subir la même modélisation profonde et coûteuse que les documents.

Méthodologie : LightRetriever

Les auteurs proposent LightRetriever, une nouvelle architecture de recherche hybride qui brise explicitement la symétrie entre les encodeurs de documents et de requêtes. L'idée centrale est que, si les documents nécessitent toute la puissance de modélisation des LLM, les requêtes n'ont pas besoin d'un traitement aussi lourd pour atteindre de solides performances de recherche. L'architecture déplace la majeure partie du coût de modélisation vers le côté document tout en réduisant le côté requête à une opération extrêmement légère.

1. Architecture Asymétrique

• Côté Document : Conserve un encodeur LLM de taille complète ($Enc_d$) pour l'encodage dense et creux. Les documents sont pré-calculés hors ligne.
• Côté Requête : Élimine l'inférence Transformer profonde lors du service en ligne. L'encodeur de requête ($Enc_q$) est réduit à un simple mécanisme de recherche d'incorporation (embedding lookup).

2. Mécanisme de Recherche Dense

Pour la recherche dense, LightRetriever utilise un processus en trois étapes :

• Entraînement : Un LLM de taille complète est utilisé pour entraîner le système. Pour un jeton de requête $t_i$ donné (précédé d'une instruction de tâche), le modèle génère une représentation par jeton $v^{den}_{t_i} = Enc_q(Inst; t_i)$. Le vecteur de requête dense final $v^{den}_q$ est calculé en faisant la moyenne de ces vecteurs de jetons :
  $$v^{den}_q = \frac{1}{n} \sum_{i=0}^{n-1} v^{den}_{t_i}$$
  Le système est optimisé à l'aide d'une perte contrastive (Équation 2) pour aligner les vecteurs de requête et les vecteurs de documents pertinents.
• Mise en cache : Étant donné que les jetons de requête n'interagissent pas profondément entre eux pendant l'inférence, les vecteurs de jetons sont susceptibles d'être mis en cache. Avant le service, le système pré-calcule les plongements de jetons pour l'ensemble du vocabulaire ($V$) du LLM et les stocke dans une matrice de recherche d'incorporation unique $E$ (forme $[V, H]$).
• Service en Ligne : Lors de l'inférence, la requête est tokenisée, et le vecteur dense est généré en effectuant une recherche dans les incorporations mises en cache pour chaque jeton et en faisant leur moyenne. Cela remplace la passe avant d'un grand Transformer par une opération de recherche d'incorporation et de moyenne, ne nécessitant qu'une couche d'incorporation résidente en RAM.

3. Mécanisme de Recherche Creuse

Pour la recherche creuse, le côté requête est encore plus léger :

• Encodage de la Requête : Le vecteur de requête creuse $v^{spr}_q$ est un vecteur basé sur les termes, non apprenable, dérivé directement de la tokenisation, où la valeur pour un jeton $t$ est simplement son compte dans la requête. Aucun encodeur n'est nécessaire.
• Encodage du Document : Le document est traité par le LLM complet. Les états cachés de la dernière couche sont projetés vers l'espace du vocabulaire via la tête de modélisation du langage du modèle. Pour induire la parcimonie (sparsity), une activation ReLU et une fonction de saturation logarithmique sont appliquées, suivies d'un max-pooling sur la longueur de la séquence.
• Scoring Hybride : Les scores denses et creux sont interpolés linéairement pour produire le classement de recherche final.

Principales Contributions

1. Vitesse d'Inférence de Requête Extrême : En remplaçant la modélisation profonde de la requête par une recherche d'incorporation, LightRetriever atteint une accélération de 1000x de l'encodage de requête par rapport au service d'un modèle complet Llama-8b sur un GPU A800.
2. Amélioration du Débit : L'architecture permet une augmentation de 10x du débit de recherche de bout en bout (Requêtes Par Seconde).
3. Maintien de la Performance : Malgré la réduction drastique du calcul du côté requête, la méthode conserve environ 95 % de la performance de recherche des chercheurs complets symétriques basés sur les LLM à travers divers benchmarks.
4. Généralisation : L'approche est validée sur divers modèles de fondation (Llama-1B/3B/8B, Qwen-1.5B/3B/7B) et tâches de recherche (BeIR, CMTEB), démontrant sa robustesse sans nécessiter de changements architecturaux spécifiques à la tâche.

Résultats Expérimentaux

L'article évalue LightRetriever sur 15 tâches anglaises de BeIR et 8 tâches chinoises de CMTEB Retrieval.

• Vitesse : Sur un benchmark de 65 536 requêtes contre 1M de passages, LightRetriever a réduit le temps de recherche total de bout en bout de ~119s (Full-Llama8b) à ~9,36s, atteignant un débit de 6 999 QPS contre 549 QPS pour le modèle complet.
• Efficacité :
  • LightRetriever-Llama3.1-8b a obtenu un nDCG@10 de 54,4 sur BeIR et 63,0 sur CMTEB-R.
  • Cela représente une dégradation modeste de -2,4 et -4,6 points respectivement par rapport à la ligne de base symétrique complète Llama3.1-8b (56,8 et 67,6), tout en évitant le coût lourd de l'inférence de requête.
  • La méthode surpasse d'autres lignes de base efficaces comme BGE-m3 (49,6 sur BeIR) et se rapproche des performances d'E5-Mistral et LLM2Vec.
• Études d'Ablation :
  • Supprimer l'encodeur de document complet (léger symétrique) a provoqué de sévères chutes de performance (ex: -13,8 sur BeIR), confirmant la nécessité d'une modélisation profonde du document.
  • Utiliser uniquement un sac d'incorporations (embedding bag) pour l'entraînement de la requête (sans le Transformer complet) a également entraîné une perte de performance significative (-11,2 sur BeIR), indiquant que la modélisation profonde est essentielle durant la phase d'entraînement pour apprendre des représentations efficaces, même si elle est abandonnée lors de l'inférence.

Signification et Revendications

L'article affirme que LightRetriever offre un paradigme évolutif pour les scénarios de recherche sensibles à la latence et à haut débit. Il répond à l'inefficacité pratique du déploiement de géants LLM pour l'encodage de requêtes en temps réel sans sacrifier les avantages de compréhension sémantique de la recherche basée sur les LLM. Les auteurs soulignent que leur travail transfère la charge de calcul du côté de la requête en ligne vers le côté du document hors ligne, permettant aux systèmes de tirer parti de la puissance des grands modèles tout en maintenant la réactivité requise pour les moteurs de recherche de production. La méthode est présentée comme la première à traiter explicitement le goulot d'étranglement de l'efficacité en ligne sur le côté requête des chercheurs basés sur les LLM grâce à ce découplage extrême.