Intelligence artificielle

Comment LEMUR rapproche-t-il la recherche à interaction tardive des index vectoriels traditionnels dans txtai ?

Un article de la communauté Hugging Face explique l’intégration de LEMUR à txtai pour convertir des représentations de recherche multivecteurs en vecteurs de taille fixe pouvant être indexés, ainsi que l’ajout d’une option de centrage par la moyenne pour traiter la géométrie des vecteurs de tokens dans certains modèles. Les résultats montrent une amélioration notable lors de tests limités, mais ne suffisent pas à généraliser une supériorité à tous les modèles ou méthodes d’indexation.

2026-08-17
9 min de lecture
9 vues
فريق تحرير certi.news
Comment LEMUR rapproche-t-il la recherche à interaction tardive des index vectoriels traditionnels dans txtai ?

L’intégration de LEMUR dans txtai traite un problème pratique des modèles de recherche à interaction tardive : ces modèles conservent un vecteur pour chaque token de la requête ou du document, ce qui leur confère des détails plus fins qu’une représentation de chaque texte par un seul vecteur, mais complique leur utilisation avec les index de recherche dense traditionnels. txtai propose une voie qui convertit cette représentation multivecteurs en un vecteur de dimension fixe pouvant être recherché au moyen du même type d’index, avec l’ajout d’une option configurable appelée mean centering afin de mieux exploiter les différences directionnelles entre les vecteurs de tokens lorsqu’ils sont fortement similaires.

L’article, publié le 13 août 2026 sur le blog de Hugging Face en tant qu’article communautaire rédigé par Morgan Carr, présente les raisons de cette évolution, les résultats d’expériences précises, ainsi que la manière d’entraîner et de charger un artefact LEMUR dans txtai. Il ne présente pas le résultat comme un classement général entre les techniques de recherche, car les comparaisons se sont limitées à un modèle, trois jeux de données, une seule machine et une recherche exacte.

De plusieurs vecteurs à un vecteur indexable

Dans la recherche à interaction tardive, tous les tokens de la requête sont comparés aux tokens du document au moyen de MaxSim ; la correspondance la plus forte pour chaque token de la requête est conservée, puis ces valeurs sont additionnées. LEMUR, ou Learned Multi-Vector Retrieval, apprend quant à lui un encodage de dimension fixe qui tente d’approximer le résultat de cette interaction tout en conservant la possibilité d’utiliser un index vectoriel traditionnel.

L’artefact LEMUR dans txtai se compose d’un encodeur de caractéristiques, de statistiques de normalisation des sorties et d’un échantillon de vecteurs de tokens. Lors de l’inférence, la requête est convertie en une somme de caractéristiques apprises, tandis que le document est représenté par un ensemble de poids des moindres carrés ordinaires appliqués à l’échantillon stocké. Le produit scalaire entre les deux vecteurs de taille fixe devient une approximation du résultat original de l’interaction tardive.

L’artefact obtenu est propre au jeu de données utilisé pour l’entraînement et doit être entraîné avant le chargement d’un index d’embeddings dans txtai. L’artefact est également enregistré sous la forme de config.json et model.safetensors. Le paramètre epochs=100 active le parcours MLP orienté vers la qualité, tandis que epochs=0 sélectionne des caractéristiques ELM aléatoires déterministes comme solution moins coûteuse.

Le choix des données d’entraînement a été déterminant

Une expérience d’ablation menée sur le jeu de données nfcorpus a montré que la distribution des vecteurs utilisée pour apprendre la transformation des caractéristiques avait davantage d’influence que certains autres choix d’entraînement. Lorsque le MLP a été entraîné sur les vecteurs de tokens de l’encodeur des documents, la valeur NDCG@10 a atteint 0.15870, soit moins que le résultat de 0.19187 obtenu avec l’ELM non entraîné. Avec les vecteurs de l’encodeur des requêtes, le résultat est monté à 0.24868, puis à 0.25534 après avoir sélectionné le nombre d’époques sur la base de la validation.

Selon l’analyse présentée dans l’article, le choix de la distribution d’apprentissage expliquait 93 % de l’amélioration mesurée entre l’expérience utilisant les vecteurs des documents et le résultat final, tandis que le choix du nombre d’époques contribuait à l’amélioration restante de 7 %. C’est pourquoi LemurTrainer définit par défaut learncategory sur query, tout en permettant de choisir data ou de transmettre un jeu d’apprentissage distinct.

Qu’a montré le test comparatif ?

La comparaison a utilisé le modèle colbert-ir/colbertv2.0, une carte NVIDIA GeForce RTX 4080 SUPER, torch 2.13.0+cu130 et une recherche Faiss exacte via IDMap,Flat. Ont été comparées la version MUVERA par défaut d’une largeur de 10 240 dimensions, une version MUVERA réduite à 2 048 dimensions et LEMUR avec un encodage MLP d’une largeur de 2 048 dimensions.

  • Sur nfcorpus, LEMUR a obtenu 0.25524, contre 0.16299 pour MUVERA de même taille et 0.23544 pour MUVERA dans sa taille par défaut.
  • Sur scifact, LEMUR a obtenu 0.54910, contre 0.36757 pour MUVERA réduit et 0.50021 pour la version par défaut.
  • Sur arguana, LEMUR a obtenu 0.42556, contre 0.26280 pour MUVERA réduit et 0.34614 pour la version par défaut.

Cela correspond à une amélioration par rapport à MUVERA de même taille de 56,6 % sur nfcorpus, de 49,4 % sur scifact et de 61,9 % sur arguana. Comparée au vecteur MUVERA par défaut, l’amélioration atteint respectivement 8,4 %, 9,8 % et 22,9 %. Les index LEMUR utilisés pour la mesure occupaient également un cinquième de l’espace des index MUVERA par défaut, car la largeur du vecteur était passée de 10 240 à 2 048 dimensions.

La portée de ces chiffres est toutefois importante : les expériences fiqa et scidocs n’ont pas été menées à terme avec le jeu de données requis, et les mesures reposaient sur un seul modèle, une seule machine et une recherche exacte. txtai utilise une recherche exacte jusqu’à 5 000 lignes, puis passe à un index IVF. Dans l’expérience scifact, l’IVF par défaut a réduit le NDCG@10 de LEMUR de 43 % par rapport à la recherche exacte, contre une baisse de 25 % pour MUVERA. On ne peut donc pas supposer que le résultat de la recherche exacte restera identique à plus grande échelle ou avec une recherche approximative.

Pourquoi mean centering a-t-il été ajouté ?

Lors du passage de ColBERTv2 à lightonai/LateOn, le test a révélé que les vecteurs de tokens présentaient une forte similarité directionnelle. Dans un échantillon de 5 000 paires, la similarité cosinus moyenne entre les vecteurs atteignait 0.9508 et la dispersion de MaxSim était de 0.0559. Après soustraction de la moyenne de l’ensemble et renormalisation, la similarité est descendue à 0.0033 et la dispersion de MaxSim est montée à 0.4772. Il ne s’agit pas en soi d’une mesure de recherche, mais cela indique que le centrage a offert à l’encodeur de dimension fixe un espace directionnel plus vaste à exploiter.

Les tests de recherche ont confirmé que l’avantage dépendait du modèle. Dans la matrice LateOn, le centrage au niveau du batch était plus efficace que sa désactivation ou que l’utilisation de la moyenne de l’ensemble dans les quatre cellules mesurées. Par exemple, le résultat de LEMUR sur nfcorpus est passé de 0.00000 sans centrage à 0.33309 avec un centrage du batch, tandis que sur scifact il est passé de 0.04985 à 0.69016. Cependant, les expériences sur ColBERTv2 ont montré que le centrage pouvait être neutre ou nuire à MUVERA ; il n’a donc pas été présenté comme une option universellement avantageuse.

La règle par défaut des changements intégrés active le centrage du batch lorsque le modèle chargé contient plus d’une couche linéaire torch.nn.Linear. Les modèles comportant zéro ou une seule couche conservent leur comportement précédent, avec la possibilité de remplacer manuellement cette décision. Le centrage intervient après la normalisation des vecteurs de tokens et avant LEMUR ou MUVERA, puis une nouvelle normalisation est effectuée. Il est possible de choisir la portée document, batch ou collection ; la portée collection accepte également une moyenne intégrée ou un fichier Safetensors contenant center.mean.

Qu’est-ce qui change concrètement pour l’utilisateur ?

L’utilisation de LEMUR nécessite une étape d’entraînement distincte avant la création de l’index, et les paramètres des vecteurs lors de l’entraînement doivent être cohérents avec ceux du chargement. L’exemple publié montre l’utilisation de center: true avec un artefact LEMUR et l’emploi de Faiss sur IDMap,Flat lorsque la recherche exacte reste pratique. La version la plus récente de txtai publiée dans l’article est v9.12.0, tandis que les changements intégrés ciblent v9.13.0 ; pour essayer le code antérieur à la version publiée, il est possible d’installer la version master du dépôt GitHub dans un environnement isolé.

La conclusion pratique n’est pas que LEMUR ou le centrage sont supérieurs dans tous les cas, mais que txtai fournit désormais deux outils distincts pour deux problèmes différents : LEMUR pour réduire la représentation de l’interaction tardive à un vecteur fixe, et le centrage pour traiter la géométrie de vecteurs de tokens inadaptée à certains modèles. Des tests plus larges sur différents modèles, jeux de données et index approximatifs configurés restent nécessaires avant de généraliser ces résultats.

Source de l’actualité
Hugging Face Blog
Ouvrir la source originale ↗
ف
Auteur

فريق تحرير certi.news

Dans la même catégorie

À lire également

Voir toutes les actualités