1. Ziel der Vektorisierung

Ziel ist es, hochgeladene Dokumente so zu transformieren, dass:

  • sie semantisch durchsuchbar sind
  • nicht nur Schlüsselwort-basiert

  • sondern kontext- und bedeutungsbasiert

Die Vektorisierung bildet Textabschnitte in numerische Vektoren im n-dimensionalen Raum ab.

Beispiel:

Ein Embedding-Modell nimmt einen Textabschnitt (Chunk) und erzeugt daraus eine Zahlenliste:

"Art. 32 DSGVO – Sicherheit der Verarbeitung"

wir zu: [0.0124, -0.9931, 0.4412, ..., -0.1177]

Diese Liste kann z. B. 768, 1024 oder 1536 Dimensionen haben.

Das heißt:

  • Jeder Text wird zu einem Punkt in einem n-dimensionalen Vektorraum.

  • n ist die Dimensionalität des Embedding-Modells.

1.1 Was repräsentieren diese Zahlen?

Die einzelnen Zahlen sind keine „Wörter“.

Sie kodieren:

  • semantische Beziehungen

  • syntaktische Strukturen

  • Kontext

  • thematische Nähe

  • implizite Bedeutungen

Wichtig:

Die Bedeutung entsteht nicht aus einer einzelnen Dimension,

sondern aus der relativen Position des gesamten Vektors im Raum.

1.2 Warum n-dimensional?

Weil Sprache hochkomplex ist.

Ein einzelnes Wort kann gleichzeitig:

  • juristisch sein

  • personenbezogen

  • normativ

  • verpflichtend

  • sicherheitsrelevant

  • europarechtlich

Diese semantischen Eigenschaften werden als unabhängige Richtungen im Raum modelliert.

Je mehr Dimensionen:

  • desto feinere semantische Trennung möglich

  • aber desto höher Speicher- und Rechenaufwand

1. 3 Wie entsteht semantische Nähe?

Zwei Texte sind ähnlich, wenn ihre Vektoren „nah“ beieinander liegen.

Gemessen wird typischerweise mit:

Cosine Similarity (Definition des Systems)

  • Wert nahe 1 → sehr ähnlich

  • Wert nahe 0 → unähnlich

  • Wert nahe -1 → gegensätzlich

Beispiel:

Frage:

„Welche Pflichten bestehen bei Datenlöschung?“

Treffer:

„Recht auf Löschung nach Art. 17 DSGVO“

Auch wenn „Pflichten“ ≠ „Recht“, erkennt das Modell semantische Nähe

1.4 Unterschied zu klassischer Volltextsuche

Volltext

  • basiert auf Wortgleichheit

  • TF-IDF

  • exakte Token-Übereinstimmung

Problem:

  • Paraphrasen werden schlecht erkannt

  • juristische Synonyme gehen verloren

Vektorsuche

  • basiert auf Bedeutungsnähe

  • funktioniert bei Umformulierungen

  • erkennt konzeptuelle Zusammenhänge

Beispiel:

„technische und organisatorische Maßnahmen“≈„Sicherheitsvorkehrungen nach Art. 32 DSGVO“

1.5 Warum Chunking vor der Vektorisierung?

Ein komplettes Gesetz als ein Vektor wäre:

  • zu grob

  • kontextuell ungenau

  • Retrieval unpräzise

Durch Chunking:

  • Jeder Abschnitt bekommt einen eigenen Vektor.

  • Retrieval wird granular.

  • Kontext bleibt beherrschbar.

Beispiel:

angenommen:

  • Embedding-Modell erzeugt 1024 Dimensionen.

  • Dokument hat 300 Chunks.

Dann speichere ich:

300 x 1024  Werte

Das ist eine Matrix:

Bei einer Anfrage:

  • Query-Vektor 

  • Ähnlichkeit wird gegen jede Zeile berechnet.

  • Qdrant liefert die Top-k ähnlichsten.

1.6 Warum diese Methode für juristische Dokumente sinnvoll ist

Juristische Sprache:

  • enthält Synonyme

  • implizite Verweise

  • systematische Struktur

Beispiel:

Art. 32 DSGVO spricht von:

  • „Vertraulichkeit“

  • „Integrität“

  • „Belastbarkeit“

Eine Frage nach „Zugriffskontrolle“ wird trotzdem korrekt gematcht.

Das ist mit Keyword-Suche kaum möglich.

2. Sicherheit von Emeddings

Embeddings sind:

  • numerische Repräsentationen von Text

  • hochdimensionale Vektoren

  • nicht direkt menschenlesbar

  • aber informationshaltig

Wichtig:

Ein Embedding ist keine Anonymisierung, sondern eine Transformation.

2.1 Welche Informationen enthalten Embeddings?

Embeddings kodieren:

  • semantische Struktur

  • kontextuelle Bedeutung

  • thematische Nähe

  • implizite Zusammenhänge

Nicht enthalten sind:

  • Originalformatierung

  • Metadaten außerhalb des Chunks

  • Dateistruktur

  • direkte Tokenfolge

Aber:

Sie enthalten genügend Information, um:

  • semantische Rekonstruktion zu ermöglichen

  • Rückschlüsse auf Themen zu ziehen

2.2 Risikoanalyse

Theoretisch möglich:

  • Modell-Inversion-Angriffe

  • Approximate Text Reconstruction

  • Membership Inference

Realistisch betrachtet:

  • Vollständige Rekonstruktion ist extrem schwierig

  • Besonders bei modernen Embedding-Modellen

  • Aber Teilinformationen können inferiert werden

3. Zusammenfassung

Die Vektorisierung wandelt Textabschnitte in hochdimensionale numerische Repräsentationen um, die die semantische Bedeutung kodieren. Mithilfe dieser Repräsentationen ist eine bedeutungsbasierte Ähnlichkeitssuche mittels Cosine Similarity möglich. Dadurch wird eine robuste juristische Dokumentensuche ermöglicht, die auch bei Paraphrasen und konzeptuellen Umformulierungen zuverlässig funktioniert. Allerdings wächst die Vektorendatenbank schnell an. Bei mir wird eine SQLite-DB verwendet. Allein die Vektorisierung der DSGVO, des BDSG, des TDDDSG und einiger Richtlinien benötigt etwa 18 GB. Außerdem musste ich mit Metadaten arbeiten, damit Paragrafen und Artikel ordnungsgemäß erkannt werden und die Priorisierung der Gesetze und Richtlinien korrekt erfolgt. Ich habe dazu Anker gesetzt, die die Gewichtung vorab beeinflussen. Damit das funktioniert, habe ich Folgendes eingeführt: Die Anker werden aus dem Titel der Dokumente gewonnen. Beispiel:
Dateiname-Regeln (wichtig für Doctype/Issuer/Normen)
Empfohlenes Schema (mit Jahr):
<doctype>_<issuer>_<docref>_<topic>_<year>_<title>.pdf
Alternatives Schema (ohne Jahr):
<doctype>_<issuer>_<docref>_<topic>_<title>.pdf
doctype: gesetz, urteil, leitlinie, richtlinie, vorlage Wird intern normalisiert zu: law, case, guideline, policy_internal, template.
Beispiele:
  • gesetz_EU_DSGVO_datenschutz_2016_Art-13-DSGVO-Informationspflichten.pdf
  • gesetz_DE_BDSG_datenschutz_2019_Para-26-BDSG-Beschaeftigtendaten.pdf
  • leitlinie_DSK_Orientierungshilfe_datenschutz_2022_TOMs-und-Art-32.pdf
  • urteil_EU_EuGH_datenschutz_2023_Auskunft-und-Kopie.pdf
  • richtlinie_INTERNAL_Loeschkonzept_datenschutz_2024_Loeschkonzept-v1.pdf
Tipp: Für Normanker nutze im title am Anfang Art-XX oder Para-XX, damit anchor_key sauber erkannt wird.

3.1 Zur Sicherheit und Datenschutz.

Die Datenbank muss gut geschützt sein, da es datenschutzrechtliche Bedenken gibt (siehe Punkt 2). Das ist ein Grund, keine KI eines Drittherstellers für ein RAG-System zu verwenden. Des Weiteren muss ein entsprechender Zugriffsschutz vorhanden sein. Es bleibt die Frage, ob man ein KI System auch dazu motivieren kann eine Auswertung der Datenbank vorzunehmen (Prompt-Injection).
without
https://digitaleserbe.net/wp-content/themes/hazel/
https://digitaleserbe.net/
#c1c1c1
style2
scroll
Laden...
/homepages/44/d18949504/htdocs/clickandbuilds/DigitalesErbeFimberger/
#
on
none
loading
#
Sort Gallery
on
no
off
off
off