RAG-Retrieval : entraîner embedding, ColBERT et reranker dans un seul dépôt

Trois familles de modèles, un seul dépôt d'entraînement

Un pipeline de récupération RAG utile combine en général un modèle d'embedding pour le rappel initial, éventuellement un modèle à interaction tardive pour affiner, et un reranker pour réordonner les candidats. Ces trois briques ont des formats d'entrée, des fonctions de perte et des boucles d'entraînement différents. Le README de RAG-Retrieval annonce justement couvrir l'entraînement des trois, avec la mention « end-to-end code for training, inference, and distillation ». Le public visé n'est donc pas celui qui assemble un RAG avec LangChain, mais celui qui possède déjà un jeu de paires requête/document et veut spécialiser un modèle open source sur son domaine. Le dépôt cite la compatibilité avec bge, bce et gte, ce qui indique une cible concrète : les modèles que l'on télécharge sur Hugging Face et que l'on veut améliorer sans réécrire une boucle d'entraînement depuis zéro.

Ce que contient réellement l'arborescence

Le point d'entrée de l'entraînement n'est pas un script unique mais un répertoire par type de modèle. Le README donne l'exemple du sous-dossier rag_retrieval/train/embedding, et précise que les autres familles suivent la même organisation, chacune avec son propre README. C'est un choix de conception assumé, cohérent avec la revendication d'un code « simple and understandable » que l'on peut modifier. La conséquence pratique est qu'il n'existe pas de configuration centrale : chaque type de modèle a ses propres scripts et ses propres arguments. Pour un lecteur qui cherche un point d'entrée unique, c'est un obstacle. Pour celui qui veut modifier une fonction de perte précise sans toucher au reste, c'est au contraire plus lisible qu'un fichier de configuration géant avec des branches conditionnelles partout.

Mise en route : deux chemins distincts

L'installation se fait en deux temps selon l'usage. Pour l'entraînement, le README propose de créer un environnement conda en Python 3.8, de l'activer, puis d'installer les dépendances avec pip install -r requirements.txt. Il ajoute une recommandation explicite : installer manuellement une version de torch compatible avec le CUDA local avant cette étape, afin d'éviter que pip ne tire une version incompatible. C'est un avertissement récurrent dans l'écosystème, et le fait qu'il figure en commentaire dans le bloc d'installation indique que le problème a été rencontré. Pour la seule inférence de reranking, la voie est plus légère : pip install rag-retrieval, sans cloner le dépôt. Le lancement d'un entraînement se fait ensuite en entrant dans le sous-dossier concerné et en exécutant le script fourni, par exemple cd ./rag_retrieval/train/embedding puis bash train_embedding.sh. Le README racine ne détaille pas les arguments de ce script : il renvoie aux README de chaque sous-dossier, qu'il faut donc ouvrir avant de lancer quoi que ce soit.

La bibliothèque rag-retrieval et l'extension par héritage

La partie inférence est publiée séparément sur PyPI sous le nom rag-retrieval. Le README la présente comme une interface unifiée pour appeler différents modèles de classement, avec deux catégories prises en charge : les Cross Encoder Reranker et les rerankers basés sur des LLM decoder-only. Deux détails de conception méritent l'attention. D'abord, la gestion des documents longs propose deux logiques : troncature à la longueur maximale, ou découpage avec conservation du score maximal. Ce second mode change le coût de calcul, puisqu'il évalue plusieurs segments par document. Ensuite, l'extension passe par l'héritage : il faut dériver de BaseReranker et implémenter les fonctions rank et compute_score. C'est une API étroite, donc facile à satisfaire, mais elle suppose de connaître la signature exacte de ces deux méthodes, information qui se trouve dans le tutoriel lié depuis le README et non dans le README lui-même.

Distillation et réduction de dimension : ce que le dépôt ajoute vraiment

Deux fonctionnalités distinguent RAG-Retrieval d'un simple script de fine-tuning. La première est la distillation, présentée comme le transfert d'un grand modèle vers un plus petit, l'exemple cité étant un LLM de 0,5 milliard de paramètres ou un BERT-base. Le dépôt revendique la distillation à la fois pour les modèles d'embedding et pour les rerankers. La seconde concerne l'embedding : l'implémentation de la perte MRL, renvoyant à l'article Matryoshka Representation Learning, qui permet de réduire la dimension des vecteurs produits. Ces deux briques répondent à des contraintes de production réelles, la taille du modèle et le coût de stockage des vecteurs. Le tableau de résultats du README illustre le compromis : rag-retrieval-reranker est annoncé à 0,41 Go contre 1,11 Go pour bge-reranker-base et bce-reranker-base_v1, avec une moyenne sur quatre jeux de données qui n'est pas renseignée dans l'extrait disponible. Impossible donc de conclure sur la qualité relative à partir de ce seul tableau.

Multi-GPU, mais pas de recette de déploiement

Le dépôt mentionne deepspeed et fsdp comme stratégies d'entraînement multi-GPU. C'est une information utile mais incomplète : rien dans le README ne précise comment ces stratégies sont sélectionnées, ni quelles contraintes de version elles imposent. Un utilisateur sur une seule carte n'a pas à s'en préoccuper. Un utilisateur qui veut répartir un entraînement devra chercher la configuration dans les sous-dossiers. Autre angle mort : le dépôt ne traite ni l'indexation, ni le découpage des documents, ni l'orchestration de la génération. Il s'arrête à la frontière du modèle de récupération. C'est un périmètre cohérent, mais il faut le savoir avant de l'adopter en croyant trouver une solution RAG complète.

Face à Sentence Transformers et aux scripts maison

L'alternative la plus directe pour l'embedding est Sentence Transformers, qui fournit une boucle d'entraînement stable, une documentation étendue et une large base d'utilisateurs. La différence d'approche est nette : Sentence Transformers privilégie une API unique et des classes de perte standardisées, tandis que RAG-Retrieval expose des sous-dossiers séparés par famille de modèles, avec l'objectif affiché de rester facile à modifier. Si vous voulez entraîner un bge avec une perte standard, Sentence Transformers est le chemin le plus court. Si vous voulez implémenter une perte de distillation ou une variante de MRL, la structure de RAG-Retrieval vous évite de contourner une abstraction conçue pour un autre usage. Pour l'inférence de reranking, la bibliothèque rag-retrieval se place face à des appels directs à transformers : elle apporte une interface commune entre Cross Encoder et LLM decoder-only, ce qui a de la valeur seulement si vous comptez changer de modèle de classement sans réécrire votre code d'appel.

Licence, maintenance et ce qu'il reste à vérifier

Le dépôt est publié sous licence MIT, ce qui autorise la modification et la redistribution, y compris dans un produit commercial, à condition de conserver la mention de copyright et le texte de la licence. Cela ne dit rien du statut des modèles que vous entraînez avec ce code : les poids de bge, bce ou gte ont leurs propres conditions, qu'il faut consulter séparément. Aucune information sur un quelconque support n'est fournie. Sur la maintenance, le dépôt n'est pas archivé et le dernier push est daté du 28 août 2026. La seule release listée, rag_retrieval_only_train (RAG-Retrieval v0.1), remonte à mai 2024, ce qui suggère que le dépôt avance par commits plutôt que par versions étiquetées. Concrètement, cela signifie qu'un git clone vous donnera un état non versionné : épinglez un commit précis si vous intégrez ce code dans une chaîne de build reproductible. Le README signale aussi que le dépôt d'origine est NLPJCL/RAG-Retrieval alors que le sujet analysé ici est NovaSearch-Team/RAG-Retrieval, écart qu'il vaut mieux clarifier avant de choisir votre source de clonage.

Conclusion éditoriale

Adoptez RAG-Retrieval si vous devez ajuster un modèle de récupération déjà choisi et que vous acceptez d'entrer dans les sous-dossiers pour lire la configuration. Passez votre chemin si vous cherchez un pipeline RAG clé en main : ce dépôt ne couvre ni le découpage des documents, ni l'index, ni la génération. Avant de vous engager, vérifiez que le fichier train_embedding.sh de votre type de modèle correspond bien à votre version de torch et de CUDA, puis inspectez les arguments de configuration, car rien dans le README racine ne documente les clés attendues.

Sources officielles

1. Issues
2. License: MIT
3. NovaSearch-Team/RAG-Retrieval on GitHub
4. README
5. Releases