RAG für deutsche Rechtstexte: Wenn Halluzination keine Option ist

TL;DR

• Problem mit Konsequenzen: Deutsche Rechtstexte (SGB II/III/X) sind dicht, querverwiesen und gnadenlos. Generische LLMs halluzinieren Paragrafennummern, die es nicht gibt. Falsche Antworten können Menschen ihre Leistungen kosten.
• Ansatz: RAG mit mehrsprachigen Embeddings (BKS-Fragen → deutsches Korpus), paragraf-bewusstes Chunking, das §§-Querverweise erhält, und Citation-Forced Generation, die ohne belegbare Quelle keine Antwort gibt.
• Was es trägt: Eine Evaluation-Harness mit 50+ Golden Questions und expliziter Failure-Mode-Erfassung. Ohne diese Harness ist das System nur Bauchgefühl.

Kontext

Rund 1,3 Millionen Menschen mit Wurzeln auf dem Balkan leben in Deutschland — viele navigieren das Sozialsystem in einer Sprache, die sie nicht vollständig lesen. Typisches Szenario: Ein Brief vom Jobcenter mit Sieben-Tage-Frist, in formalem Amt-Deutsch, mit Verweis auf Paragraphen des SGB II oder SGB III, die selbst Muttersprachler schwer entschlüsseln. Fehler haben reale Folgen — gestrichene Leistungen, verpasste Termine, verlorene Widersprüche.

KlarAmt ist ein Werkzeug für genau diese Lücke. Anfragen erfolgen auf BKS (Bosnisch/Kroatisch/Serbisch). Das System ruft relevante Paragraphen aus dem deutschen Sozialrecht ab und liefert eine Antwort mit nachprüfbaren Quellen — in formalem Amt-Deutsch.

Die technische Herausforderung ist nicht "einen Chatbot bauen." Sie lautet: "ein Retrieval-System über Rechtstexte bauen, bei dem jede Antwort nachprüfbar sein muss, die Sprache des Nutzers nicht die Sprache des Korpus ist, und eine falsche Antwort reale Kosten hat."

Problem

Generische LLMs halluzinieren Paragrafennummern. Frage ChatGPT "was sagt §7 SGB II zu den Pflichten der Leistungsberechtigten?" und du bekommst plausibel klingenden, aber oft falschen Text. Paragrafen werden erfunden. Verweise zeigen auf Paragrafen, die es nicht gibt. In einer Domäne, in der Zitate zählen, ist das unbrauchbar.

Rechtstexte wehren sich gegen naives Chunking. Deutsches Sozialrecht ist ein Graph. §7 verweist auf §11. §11 verweist auf §20. Chunke nach Tokens und du verlierst die Verweiskette. Chunke nach Paragraf und du verlierst Kontext, der in §§-Querverweisen steckt.

Die Sprache des Nutzers ist nicht die Sprache des Korpus. Fragen kommen auf BKS. Das Korpus ist Deutsch — genauer: formales Juristendeutsch. Ein einsprachiger Retriever scheitert, sobald die Frage "pomoć" (Hilfe) verwendet und das Korpus "Leistung".

Ohne Evaluation ist Fehler unsichtbar. Ohne Eval-Harness weißt du nicht, ob das System funktioniert. Du hast Bauchgefühl. In einer Domäne mit Konsequenzen ist Bauchgefühl fahrlässig.

Vorgehen

Korpus-Ingestion mit paragraf-bewusstem Chunking. Die Ingestion-Pipeline parst SGB II, SGB III und SGB X von gesetze-im-internet.de, erhält Paragrafen-Grenzen und speichert §§-Querverweise als Metadaten. Jeder Chunk trägt seine Paragrafennummer, sein Eltern-Gesetz und eine Liste referenzierter Paragrafen — Retrieval kann so Kontext nachladen, wenn ein Chunk einen anderen referenziert.

Mehrsprachige Retrieval. Mehrsprachige Sentence-Transformers-Modelle (mehrere getestet, Auswahl nach Eval-Ergebnissen) bringen BKS-Fragen und deutsche Paragrafen in einen gemeinsamen Vektorraum. Hybrid-Retrieval kombiniert dichte Vektoren mit Keyword-Matching auf juristischer Terminologie (§§-Nummern, feste Fachbegriffe, die sich vorhersagbar übersetzen).

Citation-Forced Generation. Das Prompt-Template ist streng: das Modell bekommt die gefundenen Paragrafen als Kontext und muss für jede Aussage mindestens eine Quelle zitieren. Trägt kein gefundener Paragraf die Antwort, muss das Modell "Ich weiß es nicht — bitte an eine Rechtsanwältin/einen Rechtsanwalt wenden" sagen. Kein Ausweichen. Keine plausibel klingende Prosa ohne Quelle.

Eval-Harness als First-Class-Infrastruktur. 50+ Golden Questions mit erwarteten Quellparagrafen und akzeptablen Antwortformen. Metriken: Precision@5 und Recall@5 auf der Retrieval, Faithfulness (hat jede Aussage eine Quelle?) und "No-Source"-Compliance (verweigert das System korrekt, wenn es nicht antworten sollte?). Die Harness läuft bei jeder Korpus-Änderung, jedem Prompt-Change, jedem Modellwechsel.

Produktionsarchitektur. FastAPI-Backend, Next.js-Frontend, PostgreSQL für Session-State, ChromaDB für Vektoren. Bewusst langweilig gehalten — hier zählt Zuverlässigkeit mehr als Neuheit.

Ergebnisse

• Quellenbindung funktioniert. Jede Antwort führt zurück zu einem nachprüfbaren SGB-Paragrafen auf gesetze-im-internet.de — oder das System verweigert. Nutzer klicken auf ein Zitat und landen auf genau dem gesetzlichen Paragrafen.
• Retrieval-Qualität messbar und verbesserbar. Die Eval-Harness macht aus "hat die Änderung geholfen?" eine Zahl. Precision@5 liegt durch Hybrid-Retrieval + Re-Ranking deutlich über einer reinen Dense-Baseline (repräsentativ).
• Bekannte Failure-Modes dokumentiert. Ironie in Fragen, kürzlich geänderte Paragrafen, Fragen, die Alltagsverstand statt Gesetz brauchen — diese Fehlermodi sind katalogisiert, und Nutzer sehen explizite Warnungen.

Stack / Rahmenbedingungen

Stack: Python, FastAPI, ChromaDB (Vektoren), Sentence Transformers für mehrsprachige Embeddings, OpenAI- und Anthropic-Modelle (beide evaluiert; die Domäne entscheidet), Next.js-Frontend, PostgreSQL für Session-State.

Rahmenbedingungen: Ein-Entwickler-Projekt, null Toleranz für selbstbewusste Halluzination, Anforderung mehrsprachiger Retrieval und echte Nutzer mit echten Konsequenzen.

Entscheidungen & Abwägungen

• Hybrid-Retrieval statt reinem Dense. Dense allein verfehlte zitat-lastige Anfragen, bei denen exakte Paragrafennummern zählen. Hybrid ist mehr Code, aber deutlich bessere Eval-Zahlen.
• Langweiliger Produktions-Stack. Keine LangChain-Orchestrierungs-Suppe. FastAPI plus wenige gut verstandene Komponenten. Einfacher zu debuggen um 3 Uhr morgens, wenn etwas bricht.
• Verweigerung statt Absicherung. Das Prompt erzwingt "Ich weiß es nicht", wenn Retrieval scheitert, statt das Modell plausibel klingend raten zu lassen. Nutzer verlieren etwas Komfort, gewinnen viel Vertrauen.
• Eval-Harness vor UI-Politur. Die Harness stand vor dem Frontend. Andersherum hätte ich ein Produkt ausgeliefert, das ich nicht messen kann.

Was ich anders machen würde

Eval-Harness ab Tag eins. Ich habe Retrieval und Generation zuerst gebaut und die Harness nachgezogen. Richtiger wäre gewesen, mit den Golden Questions zu starten — sie formen jede nachgelagerte Entscheidung.

Aggressivere Negativbeispiele. Die Harness hatte "erwartete richtige Antworten", war anfangs aber schwach bei "erwarteten Verweigerungen". Explizite No-Source-Fragen haben mehrere Overconfidence-Bugs gefangen.

Früher in einen juristischen Review-Loop investieren. Jede produktive Antwort sollte idealerweise von jemandem geprüft werden, der deutsches Recht beruflich liest. Das ist noch eine Lücke — ein strukturierter Feedback-Kanal mit einer Anwältin ist der nächste Meilenstein.

Die tiefere Lektion: Reliability-Engineering endet nicht an der Plattform. Eval-Harnesses, Failure-Mode-Analyse, explizite Refusal-Patterns — das sind dieselben Disziplinen, die ich seit 15 Jahren auf verteilte Systeme anwende, jetzt auf LLMs angewendet. Das Substrat ist neu; die Strenge nicht.