RAG für regulierte Branchen: Wie quellenverifizierte KI technisch funktioniert

“Retrieval-Augmented Generation” klingt nach einem Marketingbegriff. Ist es nicht. Es ist die technische Architektur, die den Unterschied zwischen einer halluzinierenden KI und einem System macht, das nachprüfbare Antworten liefert. Für regulierte Branchen ist dieser Unterschied existenziell.

Dieser Artikel erklärt, wie RAG funktioniert, warum es für Rechts- und Compliance-Anwendungen entscheidend ist und welche technischen Entscheidungen die Qualität der Ergebnisse bestimmen.

Das Problem mit reinen Sprachmodellen

Ein grosses Sprachmodell (Large Language Model, LLM) wie GPT-4 oder Claude funktioniert wie eine extrem leistungsfähige Textergänzungsmaschine. Es wurde auf Milliarden von Texten trainiert und kann plausibel klingende Antworten auf nahezu jede Frage generieren.

Das Problem: “Plausibel” ist nicht “korrekt.”

Wenn ein Sprachmodell nach “Art. 336c OR” gefragt wird, generiert es eine Antwort basierend auf den Mustern in seinen Trainingsdaten. Es “liest” den Gesetzestext nicht. Es “erinnert” sich an Texte, die diesem Thema ähnlich waren. Wenn die Trainingsdaten unvollständig waren oder der Gesetzestext sich nach dem Training geändert hat, ist die Antwort falsch, klingt aber korrekt.

In der Programmierung nennt man das eine “Halluzination.” In der Rechtsberatung nennt man das ein “Haftungsrisiko.”

RAG: Die Architektur

Retrieval-Augmented Generation löst dieses Problem durch eine Zwei-Schritte-Architektur:

Schritt 1: Retrieval (Abruf). Bevor das Sprachmodell eine Antwort generiert, sucht das System in einer Datenbank nach relevanten Quelltexten. Diese Datenbank enthält die verifizierten Originaltexte: Gesetze, Gerichtsentscheide, Verordnungen, Rundschreiben.

Schritt 2: Augmented Generation (Erweiterte Generierung). Das Sprachmodell erhält die gefundenen Quelltexte als Kontext und generiert seine Antwort ausschliesslich auf Basis dieser Quellen. Es “erfindet” nichts. Es formuliert, was in den Quellen steht.

Benutzeranfrage: "Kündigungsschutz bei Krankheit"
       |
       v
[Retrieval: Suche in der Datenbank]
       |
       v
Gefunden: Art. 336c OR (Volltext), BGE 148 III 100 (Volltext),
          3 weitere BGer-Entscheide
       |
       v
[Generation: LLM formuliert Antwort auf Basis der Quellen]
       |
       v
Antwort: "Art. 336c Abs. 1 lit. b OR regelt die Sperrfrist
bei Krankheit. Im ersten Dienstjahr beträgt sie 30 Tage..."
+ Quellenverweise

Der entscheidende Punkt: Das Sprachmodell arbeitet mit den Originaltexten, nicht mit seinem Trainingsgedächtnis. Wenn der Gesetzestext gestern geändert wurde und die Datenbank aktualisiert ist, liefert das System die aktuelle Version.

Embeddings: Die Grundlage der semantischen Suche

Die Retrieval-Komponente von RAG basiert auf einem Konzept namens “Embeddings.” Das ist der technisch anspruchsvollste Teil der Architektur.

Was ist ein Embedding? Ein Embedding ist eine mathematische Darstellung eines Textabschnitts als Zahlenvektor. Ein Satz wie “Kündigungsschutz während Krankheit” wird in einen Vektor von z.B. 384 Zahlen umgewandelt. Ein anderer Satz wie “Sperrfrist bei Arbeitsunfähigkeit wegen Krankheit” wird in einen ähnlichen Vektor umgewandelt. Obwohl die Wörter unterschiedlich sind, liegen die Vektoren im mathematischen Raum nahe beieinander, weil die Bedeutung ähnlich ist.

Warum ist das wichtig? Traditionelle Stichwortsuche findet “Kündigungsschutz” nur, wenn das Wort im Dokument vorkommt. Semantische Suche über Embeddings findet auch Dokumente, die “Sperrfrist,” “zeitliche Kündigung,” oder “Schutz des Arbeitnehmers bei Krankheit” enthalten, weil die Bedeutung ähnlich ist.

Das Embedding-Modell. Die Qualität der Embeddings hängt vom verwendeten Modell ab. Für mehrsprachige Rechtstexte in Deutsch, Französisch, Italienisch und Englisch braucht es ein Modell, das alle vier Sprachen versteht. Modelle wie all-MiniLM-L6-v2 oder spezialisierte juristische Embedding-Modelle liefern 384-dimensionale Vektoren, die semantische Ähnlichkeit gut abbilden.

Die Skalierungsfrage. In einer Datenbank mit 2 Millionen Gesetzesartikeln und 1,14 Millionen Gerichtsentscheiden müssen über 3 Millionen Embeddings erzeugt und gespeichert werden. Das ist technisch machbar, aber die Indexierung muss effizient sein.

Vektordatenbanken: Die Suchinfrastruktur

Die Embeddings werden in einer Vektordatenbank gespeichert. Diese Datenbank ist darauf optimiert, den nächstliegenden Vektor (und damit den semantisch ähnlichsten Text) schnell zu finden.

HNSW-Index (Hierarchical Navigable Small World). Der gängigste Index-Typ für Vektordatenbanken. Er organisiert die Vektoren in einer hierarchischen Graphstruktur, die es ermöglicht, in Millisekunden die 5-10 ähnlichsten Vektoren aus Millionen zu finden. Die Parameter m (Anzahl Verbindungen pro Knoten) und ef_construction (Suchbreite beim Aufbau) bestimmen den Kompromiss zwischen Genauigkeit und Geschwindigkeit.

PostgreSQL mit pgvector. Eine Alternative zu eigenständigen Vektordatenbanken. Die PostgreSQL-Extension pgvector ermöglicht die Speicherung und Abfrage von Vektoren direkt in einer relationalen Datenbank. Vorteil: Die Embeddings liegen in der gleichen Datenbank wie die Quelltexte, Metadaten und Verknüpfungen. Kein separates System nötig.

Für eine Rechercheinfrastruktur mit 3+ Millionen Embeddings und dem Bedarf, Vektoren mit relationalem Kontext zu verknüpfen (welcher Gesetzesartikel? Welches Gericht? Welches Datum?), ist pgvector in PostgreSQL eine pragmatische Wahl.

Der Zitationsgraph: Verknüpfungen sichtbar machen

RAG allein reicht nicht. Es liefert relevante Quellen zu einer Frage. Aber es zeigt nicht, wie die Quellen zusammenhängen.

Ein Zitationsgraph macht diese Verbindungen explizit:

• Gerichtsentscheid A zitiert Gerichtsentscheid B
• Gerichtsentscheid A wendet Gesetz C, Art. 336c an
• Gesetz C verweist auf Verordnung D
• Verordnung D wird durch ESTV-Kreisschreiben E interpretiert

In einer Datenbank mit 1,42 Millionen Zitationskanten (Verknüpfungen zwischen Entscheiden und Gesetzen) ergibt sich ein Netzwerk, das zeigt:

• Welche Entscheide sind massgebend? Ein Entscheid, der von 200 nachfolgenden Entscheiden zitiert wird, hat ein anderes Gewicht als einer mit 2 Zitierungen.
• Ist ein Entscheid noch aktuell? Wenn spätere Entscheide den gleichen Gesetzesartikel zitieren, aber zu einem anderen Ergebnis kommen, deutet das auf eine Praxisänderung hin.
• Welche Gerichte urteilen wie? Der Zitationsgraph zeigt, ob kantonale Gerichte die bundesgerichtliche Praxis übernehmen oder davon abweichen.

Technisch wird dieser Graph als gerichteter Graph in der Datenbank abgebildet: Knoten sind Entscheide und Gesetzesartikel, Kanten sind Zitierungsbeziehungen. Abfragen über rekursive SQL-CTEs (Common Table Expressions) ermöglichen die Traversierung des Graphen in Echtzeit.

Datenqualität: Die verborgene Herausforderung

Die technische Architektur ist das Gerüst. Die Datenqualität bestimmt das Ergebnis.

Vollständigkeit. Wenn die Datenbank nur Bundesgerichtsentscheide enthält, aber keine kantonalen Entscheide, liefert das System eine verzerrte Sicht. Kantonale Gerichte produzieren die Mehrheit der Entscheide. Ein System, das sie ausschliesst, ist für die tägliche Praxis unbrauchbar.

Aktualität. Gesetze ändern sich. Verordnungen werden angepasst. FINMA publiziert neue Rundschreiben. Eine Datenbank, die einmal im Jahr aktualisiert wird, liefert veraltete Ergebnisse. Tägliche Synchronisation mit den offiziellen Quellen ist die Mindestanforderung.

Quellentreue. Die Texte in der Datenbank müssen mit den offiziellen Quellen identisch sein. Kein Paraphrasieren, kein Zusammenfassen, kein Kürzen. Der Volltext, wie er auf Fedlex, in der kantonalen Gesetzessammlung oder auf der BGer-Website steht.

Mehrsprachigkeit. Die Schweiz hat vier Landessprachen. Ein Gesetzesartikel existiert in Deutsch, Französisch und Italienisch. Gerichtsentscheide werden in der Verfahrenssprache publiziert. Ein System, das nur Deutsch abdeckt, ist für die Romandie und das Tessin nutzlos.

Strukturierung. Roher Text ist nicht genug. Jeder Gesetzesartikel braucht Metadaten: SR-Nummer, Gesetzesname, Artikelnummer, Absatz, Gültigkeitsdatum. Jeder Gerichtsentscheid braucht: Geschäftsnummer, Gericht, Datum, Rechtsgebiet, Verfahrenssprache. Ohne diese Strukturierung ist eine präzise Abfrage (“alle BGer-Entscheide zu Art. 336c OR seit 2020”) nicht möglich.

Die Pipeline: Vom Scraping zur Antwort

Der Gesamtprozess von der Datenquelle zur Benutzerantwort:

[Offizielle Quellen]
Fedlex, 26 kantonale Portale, BGer, BVGer, FINMA, SHAB
       |
       v
[Scraping und Parsing]
Tägliche Extraktion, strukturierte Speicherung
       |
       v
[Embedding-Generierung]
all-MiniLM-L6-v2 oder vergleichbares Modell
384-dimensionale Vektoren pro Textabschnitt
       |
       v
[PostgreSQL + pgvector]
Quelltexte + Metadaten + Embeddings + Zitationsgraph
       |
       v
[API-Layer]
FastAPI, semantische Suche, Zitationsabfragen
       |
       v
[RAG-Integration]
Relevante Quellen abgerufen, LLM generiert Antwort
       |
       v
[Benutzerantwort mit Quellenverweisen]

Jede Stufe dieser Pipeline muss zuverlässig funktionieren. Ein Fehler beim Scraping (fehlende Entscheide), bei der Embedding-Generierung (schlechte Vektoren) oder bei der Abfrage (irrelevante Ergebnisse) propagiert sich bis zur Benutzerantwort.

Was RAG nicht löst

RAG ist kein Allheilmittel.

Interpretation bleibt Menschenarbeit. Das System findet die relevanten Quellen und zeigt die Verknüpfungen. Aber ob Art. 336c OR im konkreten Einzelfall anwendbar ist, entscheidet der Anwalt, nicht das System.

Lücken in den Quellen bleiben Lücken. Wenn ein kantonales Gericht einen Entscheid nicht veröffentlicht, kann das System ihn nicht finden. RAG macht transparent, was in den Quellen steht. Es kann nicht zeigen, was nicht dort steht.

Ambiguität bleibt. Wenn zwei Bundesgerichtsentscheide zum gleichen Thema zu unterschiedlichen Ergebnissen kommen, kann das System beide anzeigen und die Zitierungshäufigkeit vergleichen. Aber es kann nicht sagen, welcher “richtig” ist.

Fazit: Die Daten sind das Produkt

RAG ist eine Architektur. Embeddings sind eine Technik. Vektordatenbanken sind Infrastruktur. Zitationsgraphen sind Datenstrukturen.

Keines davon ist schwer zu bauen. Die Technologie ist quelloffen, gut dokumentiert und erprobt.

Was schwer aufzubauen ist: die Daten. 27'795 Gesetze aus allen 26 Kantonen und dem Bund. 1,14 Millionen Gerichtsentscheide von 115 Gerichten. 1,42 Millionen Zitationskanten. 27 FINMA-Tabellen. 2,5 Millionen SHAB-Einträge. In vier Sprachen. Täglich aktualisiert.

Die KI-Modelle werden immer besser und immer günstiger. Die Embeddings werden immer präziser. Aber die Daten, die domänenspezifische, verifizierte, vollständige, tagesaktuelle Datengrundlage, das ist der Teil, den man nicht einfach herunterladen kann.

In regulierten Branchen ist die Antwort nur so gut wie die Quelle. RAG stellt sicher, dass die Quelle verifiziert ist. Alles andere ist Technologie.

CTA: [Kontaktieren Sie uns: Erfahren Sie, wie quellenverifizierte KI in der Praxis funktioniert.]