RAG-Retrieval: Fine-Tuning für Embedding, ColBERT und Reranker in einem Repository

Welches Problem das Repository adressiert

Retrieval in RAG-Systemen besteht selten aus einem einzigen Modell. Üblich sind drei Stufen: ein Embedding-Modell für das erste Abrufen, ein Late-Interaction-Modell wie ColBERT für feinere Ähnlichkeitsberechnung und ein Reranker, der die Kandidatenliste neu sortiert. Jede Stufe hat eigene Trainingsskripte, eigene Verlustfunktionen und eigene Datenformate. RAG-Retrieval setzt genau dort an und will diese drei Modelltypen in einem Repository vereinheitlichen, statt für jede Stufe ein separates Projekt zu pflegen. Die Zielgruppe sind laut README Entwickler, die Retrieval-Modelle auf eigenen Daten nachtrainieren oder größere Modelle in kleinere destillieren wollen. Das ist ein engerer Kreis als bei Bibliotheken, die nur Inferenz anbieten. Wer lediglich einen vortrainierten Reranker aufrufen möchte, braucht den Trainingscode nicht.

Drei Modellfamilien, drei Trainingspfade

Die Architektur des Repositories folgt der Modelltypologie, nicht einer gemeinsamen Abstraktion. Unter rag_retrieval/train/ liegen getrennte Unterverzeichnisse für Embedding, ColBERT und Reranker, jedes mit eigenem Einstiegsskript. Das README nennt für Embedding das Beispiel train_embedding.sh und verweist für die übrigen Typen auf die jeweiligen Unterverzeichnisse. Ein einheitliches Trainer-Interface gibt es nicht, und das ist eine bewusste Entscheidung: Das README beschreibt den Stil als einfach und nachvollziehbar, mit dem Ziel, Änderungen am Code zu erleichtern. Der Preis dafür ist, dass eine Anpassung der Datenaufbereitung für alle drei Typen an drei Stellen erfolgen muss. Wer eine gemeinsame Konfigurationsschicht erwartet, wird sie nicht finden. Die Kompatibilität reicht laut README über die mitgelieferten Modelle hinaus: bge, bce und gte werden namentlich als Familien genannt, die sich fine-tunen lassen.

Destillation als eigener Arbeitsablauf

Neben dem Fine-Tuning beschreibt das README die Destillation als zweiten Schwerpunkt. Gemeint ist der Transfer von einem großen Modell in ein kleineres, wobei als Zielgrößen ein LLM mit 0,5 Milliarden Parametern oder BERT-base genannt werden. Das ist für den Betrieb relevant, weil ein Reranker mit 0,41 GB Modellgröße deutlich weniger Speicher belegt als ein Basismodell mit 1,11 GB. Die Tabelle im README vergleicht bge-reranker-base, bce-reranker-base_v1 und ein Modell namens rag-retrieval-reranker auf vier Reranking-Aufgaben. Auffällig ist, dass das kleinste Modell in der Tabelle bei CMedQAv1 und CMedQAv2 die höchsten Werte erreicht, während es bei MMarcoReranking hinter beiden Basismodellen liegt. Die Durchschnittsspalte ist für die dritte Zeile leer, ein Gesamtwert lässt sich daraus also nicht ableiten. Wer die Tabelle als Beleg für generelle Überlegenheit liest, überinterpretiert sie. Sie zeigt eher, dass Destillation auf bestimmte Domänen wirkt und auf andere nicht.

Inferenz über die rag-retrieval-Bibliothek

Für die Vorhersage trennt das Projekt den Trainingscode von einer eigenen PyPI-Bibliothek. Installiert wird sie mit pip install rag-retrieval, und das README empfiehlt, torch vorher manuell in einer zum lokalen CUDA passenden Version zu installieren, um Konflikte mit der automatisch gezogenen Version zu vermeiden. Die Bibliothek deckt laut README Cross-Encoder-Reranker und Decoder-Only-LLM-Reranker ab. Für lange Dokumente nennt sie zwei Strategien: Abschneiden auf die maximale Länge oder Aufteilen und Übernahme des höchsten Teil-Scores. Erweiterbar ist das Ganze über die Klasse BaseReranker, von der neue Modelle erben und die Methoden rank und compute_score implementieren müssen. Das ist ein schmaler Vertrag, und er erklärt, warum die Bibliothek klein bleibt. Wer ein Ranking-Modell mit ungewöhnlichem Ausgabeformat einbindet, muss die Score-Normalisierung selbst übernehmen.

Installation und erster Trainingslauf

Die Trainingsumgebung wird laut README über conda angelegt, mit python=3.8, gefolgt von pip install -r requirements.txt. Der Hinweis auf manuelles torch-Installieren steht direkt daneben und ist ernst zu nehmen: Die requirements-Datei pinnt torch offenbar nicht auf eine bestimmte CUDA-Variante. Nach der Installation wechselt man in das Unterverzeichnis des gewünschten Modelltyps, etwa cd ./rag_retrieval/train/embedding, und startet bash train_embedding.sh. Für die anderen Typen gilt dasselbe Muster in deren Verzeichnissen. Konkrete Konfigurationsschlüssel nennt das Haupt-README nicht, es verweist auf die README-Dateien in den Unterverzeichnissen. Wer die Trainingsparameter, Lernraten oder Datenpfade sucht, muss diese Dateien lesen. Für Mehr-GPU-Setups nennt das README deepspeed und fsdp als unterstützte Strategien, ohne ein Beispielskript zu zeigen.

Wo das Projekt an Grenzen stößt

Die größte Einschränkung liegt in der Dokumentationsstruktur. Das Haupt-README beschreibt die Installation, die Verzeichnislogik und die Ergebnislage, überlässt aber alles Operative den Unterverzeichnissen. Wer den Code evaluieren will, ohne vorher mehrere Dateien zu lesen, bekommt kein vollständiges Bild. Dazu kommt die Python-3.8-Vorgabe, die in Umgebungen mit neueren Interpretern Anpassungen erzwingt. Ein weiterer Punkt: Das Projekt ist auf Retrieval-Training spezialisiert und deckt weder Chunking noch Vektordatenbanken noch die Generierungsseite ab. Wer eine komplette RAG-Pipeline sucht, wird hier nur ein Segment finden. Und die Destillation ist kein Selbstläufer. Die Ergebnistabelle zeigt einen klaren Domäneneffekt, aus dem sich keine allgemeine Aussage über den Nutzen für eigene Daten ableiten lässt.

Abgrenzung zu Sentence-Transformers

Der naheliegende Vergleich ist Sentence-Transformers, das ebenfalls Fine-Tuning für Embedding- und Cross-Encoder-Modelle anbietet. Der Unterschied liegt im Umfang. Sentence-Transformers konzentriert sich auf Embedding- und Reranker-Modelle auf BERT-Basis und bietet eine einheitliche Trainer-API mit vielen Verlustfunktionen. RAG-Retrieval deckt zusätzlich ColBERT als Late-Interaction-Modell ab und behandelt Destillation als eigenen Arbeitsablauf mit explizitem Bezug auf die Stella-Methode. Dafür fehlt die gemeinsame Abstraktion: Wer bei Sentence-Transformers einen Trainer konfiguriert, findet bei RAG-Retrieval drei getrennte Skripte. Die Wahl hängt davon ab, ob ColBERT oder LLM-basierte Reranker im eigenen Stack vorkommen. Wenn nicht, ist der zusätzliche Umfang eher Ballast.

Wartung, Lizenz und was vor dem Einsatz zu klären ist

Das Repository steht unter MIT-Lizenz, was die kommerzielle Nutzung und Modifikation erlaubt, solange der Lizenztext und der Urheberrechtshinweis erhalten bleiben. Rechtliche Beratung ist das nicht, und bei Modellen, die selbst unter anderen Bedingungen veröffentlicht wurden, können zusätzliche Bedingungen gelten. Die letzte Aktualisierung liegt laut Repository-Angaben im August 2026, die einzige gelistete Release trägt den Namen rag_retrieval_only_train und stammt vom Mai 2024. Das deutet auf einen Codebestand hin, der sich weiterentwickelt, während die Release-Kennzeichnung zurückbleibt. Wer auf reproduzierbare Versionen angewiesen ist, sollte einen Commit-Hash pinnen statt einem Branch zu folgen. Vor dem ersten Produktiveinsatz sind zwei Dinge zu prüfen: ob die README-Dateien in rag_retrieval/train/embedding und den Schwesterverzeichnissen die eigenen Datenformate abdecken, und ob die installierte torch-Version zur CUDA-Version der Zielmaschine passt. Beides lässt sich vor dem Training klären, beides ist im Haupt-README nicht abschließend beantwortet.

Redaktionelles Fazit

Wer bereits eine RAG-Pipeline betreibt und sein Retrieval-Modell auf eigene Daten nachtrainieren will, findet hier einen zusammenhängenden Codebestand für drei Modellfamilien. Wer nur einen fertigen Reranker per API aufrufen möchte, ist mit der rag-retrieval-Bibliothek allein besser bedient und braucht das Trainings-Repository nicht. Vor dem ersten Trainingslauf sollte man prüfen, ob die Unterverzeichnisse unter rag_retrieval/train/embedding eine eigene README mit den erwarteten Datenformaten enthalten, denn das Haupt-README verweist dafür ausdrücklich auf diese Dateien.

Offizielle Quellen

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