Von 60 auf über 90 Prozent: Embedding-Fine-Tuning für juristische Recherche

Juristische Fragen lassen sich nicht zuverlässig beantworten, indem man einige PDFs in eine Vektordatenbank lädt und das nächste Sprachmodell darüber schreiben lässt. Die entscheidende Vorarbeit findet davor statt: Sind die relevanten Entscheidungen überhaupt im Korpus? Findet die Suche bei einer konkreten Fachfrage die richtigen Urteile? Und bewerten praktizierende Juristen das Ergebnis genauso wie eine technische Metrik?

Für eine große deutsche Kanzlei habe ich ein internes Recherche- und Antwortsystem entwickelt, das veröffentlichte deutsche Gerichtsentscheidungen erschließt. Der Korpus umfasste unter anderem Entscheidungen des Bundesgerichtshofs und verschiedener Oberverwaltungsgerichte. Zwei Rechtsanwälte arbeiteten an den Referenzfällen und der fachlichen Bewertung mit.

Die erste messbare Version erreichte in dieser projektspezifischen, anwaltlich bewerteten Prüfung ungefähr 60 Prozent. Nach dem Aufbau besserer Trainingsdaten und einem langen iterativen Fine-Tuning- und Evaluationsprozess lag das Ergebnis bei über 90 Prozent. Diese Zahl ist kein allgemeiner Legal-AI-Benchmark. Sie beschreibt die im Projekt verwendete Aufgabenstellung und Bewertungsmethode. Gerade deshalb ist sie wertvoll: Sie wurde nicht aus einer öffentlichen Leaderboard-Zahl übernommen, sondern am vorgesehenen juristischen Arbeitsablauf gemessen.

Das eigentliche Produkt begann beim Korpus

Ohne vollständige und sauber verarbeitete Quellen kann Retrieval keine belastbare Antwortgrundlage liefern. Gerichtsentscheidungen liegen jedoch nicht als einheitlicher Trainingsdatensatz bereit. Veröffentlichungswege, Metadaten, HTML-Strukturen und Dokumentformate unterscheiden sich. Entscheidungen können aktualisiert, an mehreren Stellen referenziert oder mit unterschiedlich detaillierten Leitsätzen versehen sein.

Deshalb war Crawling ein Kernbestandteil des Systems und keine einmalige Importaufgabe. Für die ausgewählten Gerichte und Quellen mussten Crawler:

• neue veröffentlichte Entscheidungen erkennen,
• Dokumente und Metadaten reproduzierbar abrufen,
• Gericht, Datum, Aktenzeichen und Dokumenttyp normalisieren,
• Dubletten und alternative Fundstellen zusammenführen,
• Volltexte in stabile Abschnitte zerlegen,
• Fehler, Lücken und strukturelle Änderungen sichtbar machen.

„Alle Fälle finden“ bedeutete im Projekt nicht, jede jemals in Deutschland ergangene Entscheidung zu besitzen. Gemeint war eine überprüfbare Abdeckung der relevanten öffentlich zugänglichen Quellen im definierten fachlichen und gerichtlichen Scope. Diese Einschränkung ist wichtig: Ein System darf fehlende Quellen nicht durch selbstsichere Formulierungen verdecken.

Die Datenpipeline speicherte deshalb Herkunft und Abrufstatus zusammen mit dem Inhalt. So blieb später nachvollziehbar, ob ein Urteil tatsächlich nicht passte oder im Korpus fehlte. Für juristische Recherche ist dieser Unterschied elementar.

Eine Antwortmaschine besteht zuerst aus Suche

Das generative Modell ist für Nutzer am sichtbarsten, aber Retrieval bestimmt, welche Evidenz es überhaupt sehen kann. Liegt die richtige Entscheidung nicht unter den ersten Treffern, helfen ein besserer Prompt und ein eloquenteres Sprachmodell nur begrenzt. Im schlimmsten Fall formuliert das System eine plausible Antwort auf Grundlage der falschen Fälle.

Der technische Ablauf wurde deshalb getrennt betrachtet:

1. Die Fachfrage wird für Retrieval aufbereitet.
2. Ein Embedding-Modell ordnet Frage und Entscheidungsabschnitte in einem Vektorraum an.
3. Filter begrenzen beispielsweise Gericht, Zeitraum oder Dokumentklasse, wenn die Aufgabe es verlangt.
4. Die relevantesten Kandidaten werden gegebenenfalls erneut bewertet.
5. Erst danach erhält das Antwortmodell die ausgewählten Quellen.
6. Die Oberfläche zeigt Antwort und konkrete Fundstellen gemeinsam.

Diese Trennung machte Fehler diagnostizierbar. Wenn eine Antwort falsch war, ließ sich prüfen, ob die relevante Entscheidung fehlte, das Embedding sie nicht hoch genug rangierte, ein späterer Schritt sie verdrängte oder das Sprachmodell die richtige Quelle falsch interpretierte.

Zwei Rechtsanwälte machten aus Beispielen Trainingsdaten

Automatisch erzeugte Fragen hätten schnell Volumen geliefert, aber nicht zuverlässig die Denkweise des späteren Nutzers abgebildet. Juristische Fragen enthalten verkürzte Sachverhalte, Fachbegriffe, implizite Zuständigkeiten und Nuancen, die in einem synthetischen Datensatz leicht zu glatt werden.

Die Zusammenarbeit mit zwei Rechtsanwälten schuf stattdessen fachlich belastbare Referenzen. Für repräsentative Fragen wurde bewertet, welche Entscheidungen relevant waren und ob die gefundenen Quellen eine tragfähige Antwort ermöglichten. Unklare Bewertungen waren kein nutzloses Rauschen. Sie zeigten Fälle, in denen die Aufgabe, der Korpus oder das gewünschte Ergebnis genauer definiert werden musste.

Aus dieser Arbeit entstanden unterschiedliche Datentypen:

• Frage und passende Entscheidung beziehungsweise Passage als positives Paar,
• ähnlich klingende, aber fachlich unpassende Entscheidungen als Negativbeispiele,
• besonders schwer unterscheidbare Kandidaten als Hard Negatives,
• zurückzuhaltende Fragen, für die der Korpus keine belastbare Grundlage bot,
• ein getrennt gehaltener Evaluationsbestand für den ehrlichen Vergleich.

Das Embedding-Modell lernte damit nicht „deutsches Recht“ im abstrakten Sinn. Es lernte eine engere und prüfbare Aufgabe: Für Fragen aus diesem Arbeitskontext sollten fachlich relevante veröffentlichte Entscheidungen näher liegen als semantisch ähnliche, aber unpassende Texte.

Warum das Ausgangsmodell bei ungefähr 60 Prozent lag

Ein allgemeines deutsches oder mehrsprachiges Embedding-Modell versteht bereits viele sprachliche Ähnlichkeiten. Juristische Relevanz folgt aber nicht immer der stärksten Wortähnlichkeit. Zwei Urteile können dieselben Begriffe verwenden und unterschiedliche Rechtsfragen entscheiden. Umgekehrt kann eine einschlägige Entscheidung andere Formulierungen als die Anfrage benutzen.

Die erste Evaluation zeigte genau diese Lücke. Das System fand oft thematisch verwandte Dokumente, aber nicht zuverlässig die von den Anwälten erwarteten Fälle. Eine reine Vergrößerung der Ergebnismenge hätte den Recall möglicherweise erhöht, zugleich aber mehr irrelevanten Kontext an das Antwortmodell übergeben. Das Ziel war nicht „irgendwo in den ersten hundert Treffern“, sondern eine praktisch nutzbare Rangfolge.

Öffentliche Benchmarks helfen bei der Vorauswahl eines Basismodells, ersetzen aber keinen eigenen Retrieval-Test. Schon der MTEB-Benchmark zeigt, dass Modelle je nach Aufgabe sehr unterschiedlich abschneiden und kein Verfahren alle Embedding-Aufgaben dominiert. Juristische Recherche in deutscher Sprache ist wiederum spezifischer als die Durchschnittsleistung eines allgemeinen Benchmarks.

Der Weg von 60 auf über 90 Prozent

Die Verbesserung entstand nicht durch einen einzelnen magischen Hyperparameter. Sie war das Ergebnis einer Schleife aus Datenanalyse, Training, Retrieval und fachlicher Bewertung.

Nach jedem Lauf wurden nicht nur falsche Ergebnisse gezählt. Wir untersuchten, welche Art von Fehler vorlag:

• War die richtige Entscheidung im Korpus vorhanden?
• War die Frage zu allgemein oder enthielt sie den entscheidenden Sachverhalt?
• Stand ein lexikalisch ähnlicher, fachlich falscher Fall vor dem richtigen Treffer?
• Wurde ein relevantes längeres Urteil ungünstig segmentiert?
• Erzeugten Gericht oder Zeitraum ein nützliches Filtersignal?
• Enthielt das Training widersprüchliche positive und negative Beispiele?

Besonders wertvoll waren Hard Negatives: Entscheidungen, die sprachlich und thematisch nah wirkten, von den Anwälten für die konkrete Frage aber als unpassend bewertet wurden. Sie zwingen ein Modell, feinere Grenzen als bloße Stichwortähnlichkeit zu lernen. Die heutige Sentence-Transformers-Dokumentation zu Hard-Negative-Mining beschreibt genau dieses Datenformat und die Möglichkeit, nahe Kandidaten als Trainingsmaterial zu gewinnen.

Trainings-, Entwicklungs- und Testfälle blieben getrennt. Andernfalls hätte das Modell dieselben Fragen oder nahezu identische Entscheidungen während des Trainings sehen können und die vermeintliche Verbesserung wäre Datenleckage statt Generalisierung gewesen. Die über 90 Prozent wurden gegen zurückgehaltene, fachlich bewertete Fälle gemessen.

Kleine Hardware war kein Ausschlusskriterium

Das Projekt entstand in einer frühen GPT-4-Ära und lief für Datenaufbereitung, Experimente und Fine-Tuning auf vergleichsweise kleiner lokaler Hardware. Das war möglich, weil nicht das gesamte generative System von Grund auf trainiert wurde. Ein vorhandenes deutschsprachig geeignetes Embedding-Modell wurde auf eine konkrete Retrieval-Aufgabe angepasst.

Kleine Hardware erzwingt Disziplin:

• Modellgröße und Sequenzlänge werden nach der Aufgabe gewählt.
• Batches, Gradient Accumulation und Zwischenspeicherung werden auf verfügbaren Speicher abgestimmt.
• Embeddings und Kandidatenlisten werden wiederverwendet, statt jeden Vergleich neu zu berechnen.
• Erst kleine Experimente prüfen Daten und Loss, bevor ein langer Lauf startet.
• Jeder Checkpoint wird gegen denselben Evaluationsbestand verglichen.

Die Sentence-Transformers-Trainingsdokumentation bildet diesen Ansatz heute mit fertigen Trainern, Evaluatoren und unterschiedlichen Loss-Funktionen wesentlich komfortabler ab. Auch Basismodelle, mehrsprachige Embeddings, Hard-Negative-Werkzeuge und effiziente Trainingsverfahren haben sich seitdem weiterentwickelt.

Ich erwarte deshalb, dass sich derselbe Anwendungsfall heute mit besseren Startmodellen und Werkzeugen schneller und wahrscheinlich noch leistungsfähiger umsetzen ließe. Das ist jedoch eine Hypothese, keine rückwirkend gemessene Kennzahl. Belastbar wäre sie erst, wenn moderne Kandidaten gegen denselben von Anwälten bewerteten Testbestand antreten.

Warum über 90 Prozent nicht „automatisch rechtssicher“ bedeutet

Der Projektscore bewertete, ob das System für die definierten Fragen die fachlich passenden Fälle und eine brauchbare Recherchegrundlage lieferte. Er besagt nicht, dass jede erzeugte juristische Aussage korrekt ist, jede deutsche Entscheidung erfasst wurde oder eine anwaltliche Prüfung entfallen kann.

Das produktive System behielt deshalb mehrere Grenzen:

• Fundstellen blieben neben der Antwort sichtbar.
• Nutzer konnten die zugrunde liegende Entscheidung öffnen.
• Fehlende Evidenz sollte nicht durch freie Generierung ersetzt werden.
• Zugriff und Verarbeitung entsprachen dem internen Nutzungskontext.
• Fachliche Bewertung und Freigabe verblieben bei Rechtsanwälten.

Genau diese Trennung macht ein solches System professionell. Das Embedding-Modell beschleunigt die Auswahl relevanter Quellen. Es trifft keine rechtlich verbindliche Entscheidung.

Vom Experiment zum internen Werkzeug

Nach der Modellverbesserung blieb noch klassische Produktarbeit: Crawler mussten überwacht, neue Entscheidungen indexiert, Fehler protokolliert und Zugriffsrechte durchgesetzt werden. Modellversion, Index und Korpusstand mussten zusammenpassen. Eine neue Datenquelle oder Segmentierungsregel durfte nicht unbemerkt die bisherige Qualität verschlechtern.

Das Ergebnis wird heute intern in einer großen deutschen Kanzlei verwendet. Aus Vertraulichkeitsgründen nenne ich weder die Kanzlei noch interne Fragen, Falldaten oder konkrete Modellartefakte. Öffentlich belegbar bleibt aber die technische und methodische Arbeit: Quellenbeschaffung, Datenpipeline, fachanwaltlich kuratierte Trainings- und Testdaten, Fine-Tuning, messbare Retrieval-Verbesserung und Integration in ein nutzbares System.

Der allgemeine Ablauf für laufende Qualitätskontrolle ist im Beitrag RAG-Systeme mit echten Evals prüfen beschrieben. Dieses Projekt liefert den konkreten Beleg dafür, warum genau diese Trennung aus Retrieval, Antwort und fachlicher Bewertung notwendig ist.

Fazit

Der wichtigste Modellfortschritt dieses Projekts begann nicht mit größerer Hardware. Er begann mit einem kontrollierten Korpus und zwei Rechtsanwälten, die Relevanz in prüfbare Trainings- und Evaluationsdaten übersetzten. Dadurch stieg die projektspezifische, fachlich bewertete Qualität von ungefähr 60 auf über 90 Prozent.

Das ist die Art von AI-Projekt, die ich als AI- und LLM-Freelancer umsetze: Datenquellen erschließen, Qualität messbar machen, Modelle gezielt anpassen und das Ergebnis in einen sicheren produktiven Ablauf integrieren. Wer eine fachspezifische Suche, ein internes Antwortsystem oder ein bestehendes RAG-System mit schwachem Retrieval verbessern möchte, kann den Anwendungsfall vertraulich beschreiben.