Embedding-Modelle mit Fachdaten fine-tunen: vom Expertenurteil zum Trainingspaar

Ein Embedding-Modell zu fine-tunen klingt zunächst wie eine Modellaufgabe. In produktiven Suchsystemen ist es vor allem eine Daten- und Bewertungsaufgabe. Der Trainingslauf ist erst sinnvoll, wenn klar ist, welche Texte für welche Anfrage nah beieinanderliegen sollen, welche scheinbar ähnlichen Dokumente gerade nicht passen und wie eine Verbesserung unabhängig gemessen wird.

Diese Unterscheidung ist wichtig, weil ein allgemeines Leaderboard nicht die Fachaufgabe eines Unternehmens repräsentiert. Produktsuche, Support, Patentrecherche und juristische Fallrecherche können dasselbe Embedding-Modell verwenden und dennoch völlig unterschiedliche Fehler erzeugen. Fine-Tuning lohnt sich, wenn diese Fehler mit domänenspezifischen Beispielen präziser beschrieben werden können.

In einem meiner Projekte entstand so ein internes Antwortsystem für eine große deutsche Kanzlei. Zwei Rechtsanwälte bewerteten Fragen und relevante Gerichtsentscheidungen. Ein deutschsprachig geeignetes Basismodell startete in der projektspezifischen Bewertung bei ungefähr 60 Prozent; nach Datenarbeit und iterativem Fine-Tuning lag die fachlich bewertete Qualität bei über 90 Prozent. Dieser Beitrag erklärt die übertragbare Methode hinter diesem Ergebnis.

Fine-Tuning beginnt mit einer Retrieval-Definition

„Ähnliche Texte finden“ ist für ein Training zu ungenau. Zuerst muss feststehen, welche beiden Objekttypen verglichen werden. Bei einer asymmetrischen Suche steht auf einer Seite eine kurze Frage, auf der anderen ein längerer Dokumentabschnitt. Bei Duplikaterkennung sind beide Seiten ähnlich aufgebaut. Diese Aufgaben benötigen nicht zwingend dieselbe Modellkonfiguration oder Evaluation.

Eine brauchbare Definition beantwortet:

• Was ist die Eingabe des Nutzers?
• Was ist die kleinste sinnvoll auffindbare Einheit?
• Kann eine Frage mehrere richtige Dokumente besitzen?
• Welche Treffer müssen unter den ersten Ergebnissen stehen?
• Welche Metadaten dürfen vor oder nach der Vektorsuche filtern?
• Welche fachlich ähnlichen Treffer wären trotzdem falsch?

Im juristischen System sollte eine Frage relevante Entscheidungen finden, nicht nur Texte mit denselben Rechtsbegriffen. Das machte die Aufgabe asymmetrisch: kurze, fallbezogene Fragen mussten gegen längere, formal geschriebene Entscheidungen gerankt werden.

Der MTEB-Benchmark trennt Retrieval, semantische Textähnlichkeit, Clustering, Reranking und weitere Aufgaben bewusst. Seine Ergebnisse zeigen zugleich, dass kein einzelnes Embedding-Verfahren jede Aufgabenart dominiert. Ein hoher allgemeiner Score ist deshalb eine Kandidatenauswahl, keine Produktabnahme.

Ein Gold Set vor den Trainingsdaten bauen

Bevor Beispiele zum Training verwendet werden, braucht das Projekt einen kleinen unangetasteten Testbestand. Sonst steigt der Score allein deshalb, weil das Modell die bekannten Fragen besser wiedererkennt. Der Gold-Datensatz sollte aus realen oder realitätsnahen Anfragen bestehen und von den Fachpersonen bewertet werden, die später auch die Qualität verantworten.

Ein Fall kann folgende Informationen enthalten:

Der Testbestand wird versioniert und nicht nebenbei als Trainingsmaterial wiederverwendet. Bei kleinen Datensätzen sollte außerdem vermieden werden, dass Varianten desselben Falls auf Training und Test verteilt werden. Sonst erkennt das Modell Formulierungen oder nahezu identische Dokumente wieder, ohne auf neue Fälle zu generalisieren.

Im Kanzleiprojekt war die Bewertung durch zwei Rechtsanwälte besonders wertvoll. Sie machte sichtbar, wo technische Ähnlichkeit und juristische Relevanz auseinanderliefen. Wenn Fachleute uneinig waren, wurde nicht automatisch ein Mehrheitslabel erzeugt. Zuerst musste geklärt werden, ob mehrere Entscheidungen vertretbar waren oder die Frage zu wenig Kontext enthielt.

Positive Paare sind der Anfang, nicht der ganze Datensatz

Das einfachste Trainingsformat verbindet eine Anfrage mit einem passenden Text:

{
  "query": "Welche Anforderungen gelten in diesem Fall?",
  "positive": "Relevanter, öffentlich verfügbarer Entscheidungsabschnitt"
}

Solche Paare lehren das Modell, passende Inhalte zusammenzuführen. Sie sagen jedoch noch wenig darüber, welche Verwechslungen im Produkt teuer sind. Werden nur leicht erkennbare positive Paare verwendet, verbessert sich der Trainings-Loss, während die Rangfolge schwieriger Kandidaten nahezu unverändert bleiben kann.

Positive Daten sollten die echte Verteilung nicht blind kopieren. Häufige Themen würden sonst seltene, aber wichtige Anfragen überdecken. Sinnvoller sind Fallgruppen: häufige Standardfragen, seltene Spezialfragen, kurze und lange Anfragen, mehrere relevante Dokumente sowie Fälle ohne belastbaren Treffer.

Auch die Dokumentaufteilung gehört in die Datenentscheidung. Ein vollständiges Urteil kann zu lang und thematisch vielfältig sein; ein einzelner Satz verliert möglicherweise Begründung und Kontext. Segmentierungsstrategie, Überschriften, Leitsatz und Metadaten werden deshalb zusammen mit dem Modell evaluiert.

Hard Negatives tragen das Fachwissen

Ein Hard Negative ist ein Dokument, das zur Anfrage ähnlich aussieht und vom Basismodell weit oben gerankt wird, fachlich aber nicht die richtige Antwortgrundlage darstellt. Genau hier liegt oft der größte Wert von Expertenfeedback.

Für die juristische Recherche konnten zwei Entscheidungen dasselbe Gesetz, ähnliche Begriffe oder benachbarte Sachverhalte behandeln und trotzdem unterschiedliche Rechtsfragen beantworten. Ein zufällig ausgewähltes negatives Dokument wäre für das Modell zu leicht gewesen. Der ähnlich klingende falsche Fall markierte dagegen die fachliche Grenze, die es lernen sollte.

Ein Trainingsbeispiel wird damit zum Triplet:

{
  "anchor": "Fachfrage aus dem vorgesehenen Arbeitsablauf",
  "positive": "Von Fachleuten als relevant bewertete Passage",
  "negative": "Ähnliche, aber für diese Frage unpassende Passage"
}

Hard Negatives können aus den Fehlerrängen des aktuellen Modells gewonnen und anschließend fachlich geprüft werden. Die Sentence-Transformers-Funktion für Hard-Negative-Mining unterstützt die Suche nach nahen Kandidaten und verschiedene Ausgabeformate für Paare und Triplets.

Automatisches Mining darf positive Dokumente nicht versehentlich als negativ markieren. Bei Fragen mit mehreren vertretbaren Quellen ist diese Gefahr besonders groß. Deshalb braucht die Auswahl Abstandsregeln, bekannte Positivlisten und Stichproben durch Fachpersonen.

Loss und Batch müssen zum Datenformat passen

Die Loss-Funktion definiert, welche geometrische Beziehung das Modell optimiert. Für Anfrage-Dokument-Paare werden häufig kontrastive Verfahren eingesetzt: Das positive Dokument soll näher an der Anfrage liegen als andere Dokumente im Batch oder ausdrücklich gelieferte Negativbeispiele.

Dabei sind drei praktische Probleme wichtig:

• Kleine Batches liefern weniger implizite Negativbeispiele.
• Größere Batches erhöhen Speicherbedarf und können falsche Negative enthalten.
• Sehr aggressive Hard Negatives können Training destabilisieren oder zulässige Alternativen auseinanderdrücken.

Die aktuelle Sentence-Transformers-Übersicht zu Loss-Funktionen beschreibt unter anderem Multiple Negatives Ranking Loss, gecachte Varianten und den Umgang mit expliziten Hard Negatives. Die richtige Auswahl folgt trotzdem aus Datenformat und Hardware, nicht aus einem pauschalen Rezept.

Ein kleiner Probelauf sollte zuerst beweisen, dass Daten geladen, Tokenlängen verstanden und Metriken korrekt berechnet werden. Erst danach lohnt ein langer Trainingslauf. Ein perfekter Trainings-Loss bei stagnierendem Test-Retrieval ist kein Fortschritt.

Retrieval mit mehreren Metriken bewerten

„Accuracy“ ist bei Suche erklärungsbedürftig. Je nach Projekt kann gemeint sein, dass mindestens ein relevanter Treffer in den Top-k vorkommt, dass der erste Treffer relevant ist oder dass Fachleute die gesamte Ergebnisliste als brauchbar bewerten.

Deshalb sollte ein Report den projektspezifischen Score mit technischen Metriken ergänzen:

• Recall@k: Wie viele erwartete relevante Dokumente erscheinen unter den ersten k Treffern?
• Precision@k: Welcher Anteil dieser Treffer ist tatsächlich relevant?
• MRR: Wie früh erscheint der erste relevante Treffer?
• nDCG: Wie gut entspricht die Rangfolge abgestuften Relevanzurteilen?
• Abstention-Qualität: Bleibt das System bei nicht belegbaren Fragen kontrolliert?

Im Kanzleiprojekt war das Urteil der Rechtsanwälte die maßgebliche Produktmetrik. Die Steigerung von ungefähr 60 auf über 90 Prozent bezeichnet diesen projektspezifischen Bewertungsrahmen, nicht die allgemeine Rechtsrichtigkeit eines Modells. Technische Einzelmetriken halfen dabei, Veränderungen zu erklären, konnten das Fachurteil aber nicht ersetzen.

Auswertungen sollten außerdem nach Fallgruppe aufgeteilt werden. Ein starker Durchschnitt kann verdecken, dass ein seltenes, aber geschäftskritisches Thema schlechter wurde. Ein neues Modell wird nur freigegeben, wenn die vereinbarten Kernbereiche ihre Mindestqualität halten.

Korpus, Modell und Index gemeinsam versionieren

Ein fein abgestimmtes Modell bleibt nicht automatisch gut, wenn sich die Daten ändern. Neue Dokumente, eine andere Segmentierung oder korrigierte Metadaten verändern die Kandidatenmenge. Deshalb gehören mindestens vier Versionen zu jedem reproduzierbaren Lauf:

• Rohquellen und Abrufstand,
• normalisierter Korpus und Segmentierungslogik,
• Modell-Checkpoint und Kodierungsparameter,
• Index sowie verwendete Filterkonfiguration.

Wenn neue Inhalte regelmäßig gecrawlt werden, benötigt die Pipeline Qualitätskontrollen: unerwartet wenige Dokumente, leere Volltexte, geänderte HTML-Strukturen, ungewöhnliche Dublettenraten oder fehlende Metadaten. Ein Modelltraining kann eine kaputte Quelle nicht reparieren.

Auch Embeddings müssen bei relevanten Modell- oder Vorverarbeitungsänderungen neu erzeugt werden. Query und Dokumente müssen mit kompatibler Modellversion und den vorgesehenen Präfixen beziehungsweise Prompts kodiert sein. Mischindizes erzeugen Fehler, die wie schlechte Modellqualität aussehen.

Kleine Hardware sinnvoll einsetzen

Domänenspezifisches Fine-Tuning braucht nicht automatisch einen großen GPU-Cluster. Entscheidend sind Modellgröße, Sequenzlänge, Batchstrategie und die Menge der wirklich nützlichen Daten. Im beschriebenen Rechtsprojekt liefen die Experimente auf vergleichsweise kleiner Hardware, obwohl die heute verfügbaren komfortablen Werkzeuge und starken Embedding-Basismodelle noch nicht in derselben Form existierten.

Für begrenzte Hardware helfen:

• ein kompaktes Basismodell mit passender Sprache,
• Mixed Precision, wenn Modell und Hardware sie zuverlässig unterstützen,
• Gradient Accumulation oder gecachte kontrastive Losses,
• vorab berechnete Kandidaten für die Datenanalyse,
• kurze Pilotläufe vor vollständigen Epochen,
• frühes Stoppen nach der echten Eval-Metrik.

Größere Hardware kann mehr Modelle und Parameterkombinationen parallel testen. Sie ersetzt keine Fachlabels. In vielen Projekten ist eine weitere Stunde mit einem Domänenexperten wertvoller als ein weiterer ungerichteter Trainingslauf.

Wann Fine-Tuning nicht die erste Maßnahme ist

Nicht jedes schwache Retrieval benötigt ein angepasstes Modell. Zuerst sollte geprüft werden, ob das relevante Dokument im Korpus liegt, ob Filter korrekt funktionieren und ob die Segmentierung den gesuchten Inhalt zusammenhält. Häufig verbessern eine lexikalische Hybrid-Suche, bessere Metadaten oder ein Reranker das Ergebnis schneller.

Fine-Tuning ist besonders plausibel, wenn:

• dieselben fachlichen Verwechslungen wiederholt auftreten,
• genügend von Experten bewertete Paare oder Triplets vorhanden sind,
• ein stabiler Eval-Bestand die Verbesserung belegen kann,
• Datenschutz oder Betrieb ein eigenes kompaktes Modell begünstigen,
• und der erwartete Nutzen den Datenpflegeaufwand rechtfertigt.

Es ist weniger plausibel, wenn der Korpus ständig fundamental wechselt, nur wenige unklare Beispiele existieren oder die eigentliche Ursache in fehlenden Dokumenten liegt. Dann sollte zuerst das Informationssystem repariert werden.

Der produktive Kreislauf

Nach der ersten Freigabe beginnt ein kontrollierter Kreislauf. Fachnutzer markieren schlechte oder fehlende Treffer. Nach Bereinigung und Prüfung werden geeignete Fälle zu neuen Evals oder Trainingsbeispielen. Ein Challenger-Modell tritt gegen die produktive Version an. Nur eine nachvollziehbare Verbesserung führt zu einem neuen Index.

Die Antwortgenerierung wird separat bewertet. Ein verbessertes Embedding kann relevantere Quellen liefern, während ein Sprachmodell sie weiterhin falsch zusammenfasst. Umgekehrt kann eine schönere Antwort schlechtes Retrieval verdecken. Der Beitrag RAG-Systeme mit echten Evals prüfen beschreibt diese zweite Qualitätsachse ausführlich.

Fazit

Embedding-Fine-Tuning übersetzt Fachwissen in eine messbare Rangfolge. Positive Paare zeigen, was zusammengehört. Hard Negatives markieren die schwierigen fachlichen Grenzen. Ein unangetasteter, von Experten bewerteter Testbestand entscheidet, ob das Modell wirklich generalisiert.

Das Projekt für die deutsche Kanzlei zeigt, wie groß dieser Effekt sein kann: von ungefähr 60 auf über 90 Prozent im definierten anwaltlichen Bewertungsrahmen, umgesetzt auf kleiner Hardware und später in einem internen Werkzeug produktiv genutzt. Als AI- und LLM-Freelancer verbinde ich dafür Crawling, Datenpipelines, Training, Evals und Produktintegration. Wer ein Embedding-Modell mit eigenen Fachdaten anpassen oder zunächst die sinnvollste Verbesserungsstufe finden möchte, kann den Anwendungsfall unverbindlich schildern.