Multi-vecteurs : les checkpoints -unsupervised s’adaptent mieux

Des expériences sur des jeux médicaux mettent en avant un gain d’adaptation au domaine pour les points de contrôle dits -unsupervised. La gestion explicite des longueurs de documents évite des pertes de NDCG@10 mesurées jusqu’à 0,24 lorsque des passages dépassent largement 512 tokens. MultiVectorEncoder permet d’affiner un checkpoint existant ou d’ajouter une tête fraîche à un backbone, avec un outillage basé sur datasets et le Hub de Hugging Face.

Commencer par un checkpoint -unsupervised, d’après les essais comparatifs

Des tests réalisés sur six configurations initiales, toutes entraînées selon le même protocole sur 25 000 paires question–passage médicales puis évaluées avec 1 000 questions et 50 000 passages, montrent que les checkpoints identifiés par le suffixe -unsupervised présentent une bien meilleure capacité d’adaptation à un domaine inédit que ceux entièrement finalisés. Cette observation a été confirmée pour deux groupes de modèles distincts. Les points de contrôle finalisés ont montré peu de progrès, voire une diminution des performances, quels que soient les taux d’apprentissage examinés. Selon l’explication proposée, leur efficacité tiendrait au fait qu’ils interviennent juste après un pré-entraînement contrastif massif, mais avant un affinement supervisé sur la récupération générale, ce qui permettrait de préserver cet ajustement lors d’un entraînement ultérieur dans le domaine ciblé. En pratique, il est préconisé de privilégier un point de contrôle pré-supervisé lorsqu’il est disponible. Si ce n’est pas le cas, il est recommandé d’utiliser une nouvelle tête de projection associée à un backbone de récupération pré-entraîné robuste, alors qu’un point de départ totalement finalisé s’avère le moins pertinent pour l’adaptation à un nouveau domaine. De plus, une tête nouvellement initialisée sur Alibaba-NLP/gte-modernbert-base a obtenu dans les expériences rapportées une performance à seulement 0,03 point de certains checkpoints existants avec 25 000 paires d’entraînement.

Longs documents : vérifier et lever les troncatures coûteuses

La configuration standard de nombreux modèles de récupération vise des passages courts : des checkpoints ColBERT tronquent fréquemment à 180 ou 300 tokens, des modèles denses populaires à 256 ou 512, en cohérence avec des données de type MS MARCO rarement plus longues. Sur des documents longs, ces limites conduisent à ignorer silencieusement une grande partie du texte avant notation. Dans une évaluation médicale où les passages comptaient en moyenne 941 tokens, la troncature a coûté jusqu’à 0,24 NDCG@10, davantage que l’écart entre architectures. Pour l’ajustement, il est conseillé d’examiner d’abord les longueurs : les passages médicaux cités montent jusqu’à 1 400 tokens et la famille mLateOn peut servir un contexte complet de 8 192 tokens. Si le point de départ limite la longueur, il est possible de désactiver les plafonds par tâche et de revenir à la longueur maximale du tokenizer, à configurer dès le chargement. Un exemple d’initialisation fixe explicitement une longueur maximale de 8 192 tokens pour éviter une troncature non désirée.

Deux voies d’entraînement : affiner un checkpoint ou ajouter une tête fraîche

Adapter un modèle multi-vecteur déjà existant ne nécessite pas de modifier son architecture : chaque checkpoint inclut ses propres marqueurs pour les requêtes et les documents, une tête de projection ainsi qu’une liste de saut de notation, qu’il est en général judicieux de conserver en ne changeant que les éléments requis par les données. Il est également possible de configurer MultiVectorEncoder pour utiliser directement un transformateur de base : dans ce cas, une projection au niveau des tokens est ajoutée et initialisée de façon aléatoire, ce qui implique un entraînement préalable avant toute utilisation. Cette méthode est également compatible avec des backbones d’embedding dense offrant de bonnes performances.

Comment fonctionne l’interaction tardive dans ce pipeline

L’interaction tardive conserve un vecteur par token et évalue la similarité via MaxSim, chaque token de la requête trouvant son meilleur correspondant dans le document avant sommation des scores. Le pipeline ColBERT s’appuie sur un Transformer qui génère des embeddings contextualisés, une projection dense ramenant chaque token à 128 dimensions, un MultiVectorMask sélectionnant les tokens contribuant à la notation et une normalisation au niveau des tokens. En pratique, cet appariement fin retient des signaux que l’agrégation en un seul vecteur tend à lisser, et il répond bien même avec peu de données d’ajustement dans le domaine, au prix d’index plus volumineux.

Données et outillage d’entraînement avec datasets et le Hub

Un entraînement MultiVectorEncoder regroupe un modèle, un jeu de données, une fonction de perte, des arguments d’entraînement et un évaluateur optionnels au sein d’un entraîneur. MultiVectorEncoderTrainer s’appuie sur des objets datasets.Dataset ou datasets.DatasetDict pour l’entraînement et l’évaluation. Les données peuvent provenir du Hugging Face Datasets Hub ou de sources locales en CSV, JSON, Parquet, Arrow ou SQL. De nombreux jeux utilisables directement avec Sentence Transformers sont balisés "sentence-transformers" sur le Hub pour être retrouvés facilement. En construisant son propre entraînement, la longueur des documents peut être définie en fonction des besoins concrets du corpus.