Legal AI Knowledge Base mit Docling: Lehren aus der Praxis

Wie man eine juristische Wissensbasis baut, deren Antworten sich belegen lassen: Parsing mit Docling, Chunking entlang von Paragraph und Absatz, Zitat-Metadaten und die Checks, die nach jedem Ingest laufen sollten.

Bei Erst Recht bauen wir eine KI-Plattform für rechtliche Ersteinschätzungen nach deutschem Recht. Ein Baustein ist eine Retrieval-gestützte Wissensbasis, und juristische PDFs überführen wir mit Docling in Markdown. Diesen Beitrag habe ich grundlegend überarbeitet. Statt eines Werkstattberichts steht hier eine Checkliste für juristische Wissensbasen, aus Praxis und Primärquellen zusammengetragen.

Warum juristische Texte anders sind

Eine Rechts-KI ist nur so gut wie ihre Belege. Ein Treffer „irgendwo im BGB“ reicht nicht. Die Antwort muss auf Norm, Absatz und Satz zeigen, bei Urteilen auf Gericht, Datum, Aktenzeichen und Randnummer. Drei Eigenschaften machen das schwer:

• Tiefe Hierarchie: Gesetz, Abschnitt, Paragraph, Absatz, Satz, Nummer. Ein Absatz ohne seinen Paragraphen ist als Beleg wertlos.
• Dichte Abkürzungen: „Abs.“, „S.“, „Nr.“, „i.V.m.“, „a.F.“. Jeder naive Satzsplitter stolpert darüber.
• Verweisketten: Normen verweisen auf Normen, Urteile zitieren Urteile. Ein Chunk ohne Kontext reißt die Kette ab.

Wer das ignoriert, bekommt eine Suche, die ähnliche Wörter findet, aber keine Fundstelle liefert.

Die Pipeline im Überblick

Vom PDF bis zur semantischen Suche sind es fünf Stationen. Die Domänenlogik in der Mitte entscheidet, ob am Ende zitierfähige Chunks stehen:

Parsing: Docling statt reiner Textextraktion

Docling stammt aus der Gruppe „AI for Knowledge“ von IBM Research Zürich, steht unter MIT-Lizenz und wird heute von der LF AI & Data Foundation gehostet. Es ist keine „bessere OCR“, sondern eine Pipeline für Dokumentverständnis:

Drei Entscheidungen lohnen sich vor dem ersten Lauf:

• OCR nur, wo nötig. Digital erzeugte PDFs haben eine Textebene, Scans nicht. Docling unterstützt mehrere OCR-Engines, darunter EasyOCR, Tesseract und RapidOCR. Entscheide pro Dokumentquelle, nicht pauschal.
• Tabellenerkennung an. Fristen-, Gebühren- und Übersichtstabellen sind in juristischen Unterlagen häufiger, als man denkt. Docling hat dafür ein eigenes Tabellenmodell mit einem schnellen und einem genauen Modus.
• Markdown zum Prüfen, DoclingDocument zum Chunken. Der Markdown-Export ist ideal, um Ergebnisse mit dem Auge zu prüfen. Für das Chunking ist das strukturierte DoclingDocument die bessere Basis, denn es kennt Hierarchie und Herkunft jedes Elements, inklusive Seite.

Strukturbewusstes Chunking

Gesetze: strukturiert holen statt parsen

Für Bundesrecht ist das PDF ein Umweg. Gesetze im Internet bietet die Gesetze als XML-Download an. Die DTD gliedert in norm-Elemente mit Metadaten wie Abkürzung (jurabk), Einzelbezeichnung (enbez), Titel, Gliederungseinheit und Standangabe. Der Normtext steht in Absatz-Elementen (P).

Daraus ergibt sich das Chunking fast von selbst: ein Chunk pro Absatz, nummerierte Aufzählungen bleiben beim Absatz, die Sätze werden als Positionen im Chunk vermerkt. So kann ein Chunk für eine Norm aussehen:

{
  "quelle": "gesetz",
  "gesetz": "BGB",
  "norm": "§ 626",
  "titel": "Fristlose Kündigung aus wichtigem Grund",
  "absatz": 1,
  "gliederung": "…",
  "stand": "…",
  "text": "Das Dienstverhältnis kann von jedem Vertragsteil …"
}

Zwei Dinge spart man sich später teuer. Erstens die Fassung: Gesetze ändern sich, also wird der Stand gespeichert, und bei einer Aktualisierung ersetzt der neue Chunk den alten, statt neben ihm zu landen. Sonst stehen zwei Fassungen derselben Norm im Index. Zweitens die Verweise: Steht im Absatz „i.V.m.“ eine andere Norm, gehört sie als Metadatum an den Chunk. Dann kann das Retrieval die verwiesene Norm gezielt nachladen.

Urteile: entlang der Urteilsstruktur

Zivilurteile folgen einer gesetzlichen Gliederung: § 313 ZPO verlangt unter anderem Urteilsformel, Tatbestand und Entscheidungsgründe. Daran lässt sich schneiden: Chunks entstehen innerhalb dieser Abschnitte, nie über ihre Grenzen hinweg. Leitsätze, wo vorhanden, werden eigene Chunks, und Randnummern dienen als Anker für das Zitat.

Besonders wichtig ist die Grenze zwischen Tatbestand und Entscheidungsgründen. Der Tatbestand gibt laut § 313 ZPO die erhobenen Ansprüche und die vorgebrachten Angriffs- und Verteidigungsmittel wieder, die Entscheidungsgründe die Erwägungen des Gerichts. Landen beide im selben Chunk, zitiert das Modell im Zweifel den Vortrag einer Partei als Rechtsauffassung des Gerichts.

In die Metadaten gehören Gericht, Datum, Aktenzeichen und, wo vergeben, der European Case Law Identifier. Laut Bundesverwaltungsgericht besteht der ECLI aus Länderkennung, Gericht, Jahr und lokalem Identifikator. Teilnehmen in Deutschland das Bundesverfassungsgericht, die obersten Bundesgerichte, das Bundespatentgericht und die Gerichte der Länder. Damit ist jede Entscheidung mit ECLI eindeutig adressierbar.

Alles andere: Docling-Chunker

Für Aufsätze, Merkblätter oder Verträge bringt Docling eigene Chunker mit. Der HybridChunker schneidet entlang der Dokumentstruktur, teilt zu lange Abschnitte, fasst zu kurze mit gleichen Überschriften zusammen und berücksichtigt dabei den Tokenizer. contextualize() stellt jedem Chunk seine Überschriften voran, und die Metadaten verweisen auf die Dokumentelemente samt Seitenzahl. Ein neutrales Beispiel:

from docling.document_converter import DocumentConverter
from docling.chunking import HybridChunker

doc = DocumentConverter().convert("merkblatt.pdf").document
chunker = HybridChunker()

for chunk in chunker.chunk(dl_doc=doc):
    text = chunker.contextualize(chunk=chunk)  # Überschriften + Text fürs Embedding
    pfad = chunk.meta.headings                  # Gliederungspfad
    seiten = {p.page_no for item in chunk.meta.doc_items for p in item.prov}

Die Docling-Doku empfiehlt, für Chunker und Embedding-Modell denselben Tokenizer zu verwenden. Wer zusätzlich nach Sätzen trennt, braucht eine Liste juristischer Abkürzungen, sonst endet ein Chunk mitten in einer Normangabe.

Zitat-Metadaten: Das Zitat ist ein Feld

Zitierbarkeit ist eine Eigenschaft der Daten, nicht des Prompts. Jeder Chunk sollte mitbringen:

• Fundstelle: Gesetz, Paragraph, Absatz, Satz oder Gericht, Datum, Aktenzeichen, ECLI, Randnummer.
• Gliederungspfad: die Überschriften von oben bis zum Chunk, nicht nur die letzte.
• Stand: welche Fassung des Gesetzes, welches Datum der Entscheidung.
• Herkunft: Dokument, Seite, Link auf die Quelle.
• Kontrolliertes Vokabular: Rechtsgebiete und Dokumenttypen aus einer festen Liste, beim Ingest validiert. Sonst liefert ein Filter mit Tippfehler still nichts.

Die Metadaten gehören mit in den Kontext, damit das Modell zitieren kann. Und sie gehören in eine Prüfung nach der Generierung: Jeder Paragraph in einer Antwort sollte sich gegen den Normindex auflösen lassen. Was sich nicht auflösen lässt, wird markiert, nicht ausgeliefert. Ein erfundener Paragraph ist bei einer Rechts-KI das teuerste Fehlerbild (mehr zu Halluzinationen und Kalibrierung).

Qualitätschecks nach jedem Ingest

Parser und Chunker liefern fast immer etwas. Ob es das Richtige ist, zeigt erst die Kontrolle:

1. Nachzählen. Dokumente rein, Dokumente mit mindestens einem Chunk raus. Jede Datei ohne Chunks gehört in einen Report, nicht in eine Log-Zeile.
2. Stichproben gegen das Original. Zufällige Chunks neben die PDF-Seite legen: Stimmen Überschriften, Tabellen und Lesereihenfolge?
3. Wiederkehrende Zeilen finden. Was auf vielen Seiten identisch auftaucht, ist meist Kopf- oder Fußzeile und gehört vor dem Embedding entfernt.
4. Zeichenhygiene. Zeichen aus dem Private-Use-Bereich von Unicode (oft aus Symbolschriften), Silbentrennung am Zeilenende, Ligaturen.
5. Metadaten-Vollständigkeit. Wie viele Chunks haben keinen Gliederungspfad, keine Seite, keine Fundstelle? Häufige Titel ohne Elternknoten, etwa „Tatbestand“, zeigen verlorene Hierarchie.
6. Abkürzungs-Enden. Chunks, die auf „Abs.“ oder „Nr.“ enden, verraten einen Satzsplitter ohne juristisches Wörterbuch.

Retrieval überwachen

• Health-Check mit echter Anfrage. Nicht nur prüfen, ob die Collection existiert, sondern eine bekannte Testfrage einbetten und den erwarteten Treffer verlangen.
• Leere Ergebnisse messen. Anteil der Anfragen ohne Treffer oder unter der Score-Schwelle, aufgeschlüsselt nach Filterwert. Ein Filter, der nie trifft, ist ein Bug.
• Hybride Suche. Bei „§ 626 BGB“ zählt der exakte Treffer. Gängige Vektordatenbanken bieten dafür Volltext-Filter und hybride Suche aus Dense- und Sparse-Vektoren.
• Modell-Lebenszyklus. Anbieter kündigen Embedding-Modelle ab. Den Modellnamen am Vektor speichern und den kompletten Re-Index als geplanten Vorgang behandeln, nicht als Notfall.
• Golden Set. Echte Fragen mit erwarteten Fundstellen. Gemessen wird, ob die richtigen Chunks oben landen und ob Antworten mit Retrieval besser sind als ohne. Wie wir systematisch evaluieren, beschreibe ich in der Suche nach dem besten Modell für rechtliche Analysen.

Wann sich der Aufwand nicht lohnt

• Der Korpus ist klein. Passt er ins Kontextfenster, gehört er in den Prompt, nicht in eine Vektordatenbank.
• Es geht nur um Normtext. Dann direkt das XML verarbeiten. PDF-Parsing ist hier ein Umweg.
• Die Scans sind schlecht. Dann ist zuerst die Texterkennung das Projekt, nicht das Chunking.
• Niemand misst. Ohne Golden Set ist RAG zusätzliche Latenz und Komplexität ohne Beleg, dass es hilft.

Fazit

Docling löst das Parsing-Problem gut. Die eigentliche Arbeit kommt danach: die Struktur bis in den Chunk tragen, Fundstellen als Metadaten führen, nach jedem Ingest nachzählen und das Retrieval überwachen. Zitierbarkeit entsteht beim Ingest, nicht im Prompt.

Erst Recht macht rechtliche Ersteinschätzungen mit KI zugänglich. Unser Multi-Agent-System analysiert Ihre Situation und zeigt konkrete nächste Schritte.

Verwendete Tools:

Arbeiten Sie an einem ähnlichen Problem? Große Dokumentenbestände für RAG aufbereiten? Schreiben Sie mir, ich helfe gerne bei der Architektur oder Implementierung.