Embeddings für die polnische Sprache: Wie wählt man ein Modell für RAG aus

Ein Unternehmen aus der Branche professioneller Dienstleistungen implementierte RAG für 4.000 Verträge und interne Verfahren. Erste Tests mit einem beliebten Cloud-Modell ergaben einen recall@5 von 58%. Nach dem Wechsel zu lokal betriebenem BGE-M3 stieg der Recall auf 79%. Der Unterschied hatte einen einzigen Grund: die polnische Flexion. Das Wort „zamówienia“ im Genitiv und „zamówienie“ im Nominativ sind für ein einfaches Modell zwei verschiedene Token, für BGE-M3 zwei nahe beieinander liegende Punkte im Vektorraum.

Polnisch hat eine reiche Flexion: Substantive werden in 7 Fällen dekliniert, Verben nach Personen, Zahlen und Genera konjugiert. Ein Begriff erscheint in Dokumenten als „dostawca“, „dostawcy“, „dostawcą“, „dostawcy“ (Pl.). Modelle, die hauptsächlich auf Englisch trainiert wurden, behandeln jede Form als separaten Token und lernen nur die Formen, die sie häufig genug im Korpus gesehen haben.

Dazu kommen diakritische Zeichen. Nutzer suchen oft „zlecenie“ statt „zlecenie“ oder „wez“ statt „weź“. Ein gutes Modell für Polnisch sollte beide Formen nahe beieinander im Vektorraum platzieren, nicht als verschiedene Wörter behandeln.

Ein dritter Punkt sind gemischtsprachige Dokumente. Verträge, ISO-Verfahren, Geschäftskorrespondenz enthalten englische Begriffe (compliance, vendor, deliverable), Abkürzungen (NDA, SLA, KPI) und polnische Sätze. Ein monolinguales Modell für Polnisch kennt diese Begriffe möglicherweise nicht im englischen Kontext. Ein multilinguales Modell kommt besser zurecht, da es beide Sprachen im selben Satz gesehen hat.

Bei der Auswahl eines Modells sind fünf Parameter zu prüfen.

Multilingualität mit umfangreichem slawischen Korpus. Nicht jedes „multilinguale“ Modell wurde im gleichen Verhältnis auf Polnisch trainiert. BGE-M3 und multilingual-e5-large verfügen über einen dokumentierten europäischen Korpus. Modelle auf Basis von mBERT oder einer älteren Version von LaBSE schnitten bei polnischer Flexion schlechter ab.

Vektordimension und Speicher. Eine höhere Dimension (1536 vs. 768) führt nicht immer zu besseren Ergebnissen, erfordert aber mehr RAM in der Vektordatenbank. Bei 100.000 Fragmenten mit 1024 Dimensionen belegt ein HNSW-Index etwa 400-500 MB. Bei 1536 Dimensionen sind es 600-800 MB.

Kontextlänge des Modells. Ein Embedding wandelt ein ganzes Fragment in einen Vektor um. Wenn das Modell nur 512 Token (ca. 350 Wörter) unterstützt, während deine Dokumente Seiten aus Verträgen umfassen, gehen Informationen aus dem hinteren Teil des Fragments verloren. BGE-M3 unterstützt bis zu 8192 Token im ColBERT-Modus, standardmäßig 512. E5-large: 512. Für lange Dokumente ist dann die Strategie des Chunkings entscheidend.

Self-Hosting und RODO. Wenn du Verträge, Personaldaten oder Geschäftskorrespondenz verarbeitest, ist Self-Hosting die Standardwahl. Ein lokales Modell (über Ollama oder direkten ONNX-Server) sendet keine Dokumentenfragmente an externe APIs. Das ist keine Frage der Präferenz, sondern Grundlage für die Einhaltung von RODO Art. 28 (Auftragsverarbeitungsvertrag).

Geschwindigkeit der Indizierung. Bei 50.000 Fragmenten benötigt ein auf dem CPU-Server laufendes Modell (z. B. BGE-M3 über Ollama) 40-90 Minuten für die erste Indizierung. Ein Cloud-API-Modell: 5-15 Minuten. Für inkrementelles Re-Indizieren ist der Unterschied geringer, sollte aber in der Architektur berücksichtigt werden.

Praktische Schlussfolgerungen: Bei Projekten mit RODO und gemischten Dokumenten ist lokal betriebenes BGE-M3 die erste Wahl. Bei Projekten ohne personenbezogene Daten und mit Bedarf an schnellem Start verkürzt text-embedding-3-small über API die Implementierungszeit um 2-4 Wochen. PL-only-Modelle kommen nur bei rein polnischsprachigen Indizes ohne englische Terminologie infrage.

Eine Bewertung anhand öffentlicher Benchmarks (MTEB, BEIR) sagt wenig darüber aus, wie sich das Modell bei deinen Verträgen oder ISO-Verfahren verhält. Du benötigst einen eigenen Golden Set.

Erstelle einen Satz von 50-100 Paaren: eine repräsentative Frage für reale Nutzeranfragen + eine Liste von 3-5 Dokumenten, die in den Ergebnissen erscheinen sollten. Sammle Fragen von tatsächlichen Nutzern des Systems, erfinde sie nicht am Schreibtisch.

Miss anschließend zwei Metriken:

Recall@5 — wie viele der erwarteten Dokumente in den Top 5 Ergebnissen erscheinen. Ein gutes Ergebnis für Unternehmensdokumente: 70-80%. Unter 60% ist das Modell ohne hybride Unterstützung durch BM25 ungeeignet.

MRR (Mean Reciprocal Rank) — wie hoch in der Ergebnisliste das erste relevante Dokument erscheint. Je höher, desto weniger Kontext muss an das generative Modell gesendet werden, was die Token-Kosten senkt.

Die Evaluation lohnt sich für zwei bis drei Modelle parallel: Indiziere denselben Satz von Fragmenten, frage mit demselben Satz von Fragen ab und vergleiche die Zahlen. Tools dafür: RAGAS (Open Source, Python) oder ein eigener Skript zur Berechnung von Recall und MRR in 50 Codezeilen.

Das beschriebene Evaluationsmuster wird detailliert im Artikel über RAG-Evaluation behandelt.

Nach der Modellauswahl sieht der Pipeline wie folgt aus.

Dokumentenparsing: PDF, DOCX, E-Mails durch OCR oder nativen Parser. Entfernung von Kopf- und Fußzeilen. Bei Verträgen lohnt es sich, nummerierte Abschnitte als separate Fragmente zu extrahieren.

Chunking: 300-600 Token pro Fragment mit 10-15% Überlappung. Bei langen Vertragsklauseln reduziert eine Überlappung von 20% das Risiko von Kontextverlust an den Fragmentgrenzen. Details beschreiben wir im Artikel über Datenvorbereitung für KI.

Embeddings: Übergabe der Fragmente an das Modell (lokal oder über API), Speicherung der Vektoren in einer Vektordatenbank (Qdrant, pgvector).

Suche: Bei einer Nutzeranfrage Berechnung des Embeddings der Anfrage, Durchführung einer ANN-Suche, optional Kombination mit BM25 (hybride Suche), Filterung durch Reranker.

Antwortgenerierung: Übergabe der Top 3-5 Fragmente als Kontext an das LLM. Überprüfung, ob die Antwort im Kontext verankert ist (faithfulness).

Eine vollständige Erläuterung der semantischen Suche im Unternehmen findest du im Artikel Semantische Suche und Embeddings im Unternehmen.

BGE-M3 wurde auf einem multilingualen Korpus trainiert, der slawische Sprachen, einschließlich Polnisch, umfasst. In Tests mit polnischen juristischen und technischen Dokumenten erreicht es einen recall@5, der 10-20 Prozentpunkte höher liegt als bei Modellen, die ausschließlich auf Englisch oder älterem mBERT basieren. Der Unterschied ist besonders bei Abfragen in Kasusformen (Genitiv, Instrumental) sichtbar, die Nutzer natürlich eingeben, während das Dokument die Nominativform enthält.

Wenn dein Index ausschließlich polnische Dokumente ohne englische Terminologie enthält und dir höchste Präzision bei einfachen faktografischen Abfragen wichtig ist. PL-only-Modelle (z. B. sdadas/Polish-RoBERTa-base-finetuned-polish-question-answering) können bei rein polnischem Text leicht bessere Ergebnisse liefern. Bei gemischten Dokumenten PL/EN oder Korrespondenz mit englischen Abkürzungen verschwindet der Vorteil schnell.

Auf einem typischen Server mit 16 GB RAM und CPU (ohne GPU) dauert die Indizierung von 10.000 Fragmenten mit je 400 Token 15-30 Minuten. Bei 50.000 Fragmenten: 60-90 Minuten. Die Berechnung der Embeddings erfolgt einmal; nachfolgende Abfragen sind schnell (einige Millisekunden). Wenn dir eine schnellere erste Indizierung wichtig ist, lohnt sich ein Server mit GPU oder eine Cloud-API (für Daten, die nicht unter RODO fallen).

Ja, aber jede Sammlung muss konsequent dasselbe Modell während der Indizierung und Abfrage verwenden. Das Mischen von Modellen in einem Index ist unzulässig: Vektoren aus verschiedenen Modellen sind geometrisch nicht vergleichbar. Wenn du das Modell wechseln möchtest, musst du die gesamte Sammlung neu indizieren. Daher sollte die Entscheidung für ein Modell vor dem Aufbau eines produktiven Indexes fallen.

Wenn deine Dokumente personenbezogene Daten enthalten (Namen, PESEL-Nummern, Adressen in Korrespondenz), erfordert deren Übermittlung an eine externe Embedding-API einen Auftragsverarbeitungsvertrag mit dem Anbieter (Art. 28 RODO) und eine DPIA bei hohem Risiko. Self-Hosting des Modells lokal eliminiert dieses Problem: Dokumentenfragmente verlassen nie deine Infrastruktur. Vor der Implementierung solltest du auch die Bewertung der KI-Bereitschaft deiner Organisation prüfen.