Mehrsprachiges RAG: Dokumente und Fragen in unterschiedlichen Sprachen

Mehrsprachiges RAG bedeutet, dass eine Wissensdatenbank Fragen in einer Sprache beantwortet, selbst wenn die zugrunde liegenden Dokumente in einer anderen Sprache verfasst sind, etwa eine deutsche Frage zu französischen Lieferverträgen oder eine englische Frage zu deutschen Handbüchern. Die Lösung kombiniert drei Bausteine: mehrsprachige Embeddings oder Übersetzung zur Abfragezeit für die Cross-lingual-Suche, sprachspezifisches Stemming für die Volltextsuche und systematische Qualitätschecks, damit die Antworten in jeder Sprache gleich zuverlässig bleiben.

Wofür brauchen Sie mehrsprachiges RAG überhaupt?

Sobald ein Unternehmen über eine Sprachgrenze hinweg arbeitet, entsteht fast automatisch ein mehrsprachiger Dokumentenbestand: die Zentrale schreibt auf Deutsch, die Tochtergesellschaft in Lyon auf Französisch, das Support-Team in Warschau auf Polnisch, und die Geschäftsführung erwartet Berichte auf Englisch. Eine klassische Volltextsuche findet in diesem Fall nur Dokumente, die exakt die Wörter der Suchanfrage enthalten, also nichts, wenn Frage und Dokument in unterschiedlichen Sprachen verfasst sind. Mehrsprachiges RAG löst genau dieses Problem, indem es Bedeutung statt bloßer Wortform abgleicht.

• Konzerne und Mittelständler mit Niederlassungen in mehreren EU-Ländern, deren interne Richtlinien je Standort in der Landessprache vorliegen
• Kanzleien und Steuerberatungen, die mit EU-Recht in mehreren Amtssprachen arbeiten
• Support-Teams, die Kundenanfragen in der Sprache des Kunden beantworten, aber nur ein englisches Produkthandbuch pflegen
• Exportorientierte Hersteller mit technischen Dokumentationen in Deutsch, Englisch und der Sprache des Zielmarkts
• Agenturen und Berater, die Fachwissen an eine internationale Kundschaft verkaufen möchten

Der gemeinsame Nenner: Die Dokumente wachsen organisch in mehreren Sprachen, aber die Nutzer wollen nicht erst raten, in welcher Sprache sie fragen müssen. Wer bereits mit semantischer Suche vertraut ist, kennt das Prinzip: Statt Schlüsselwörter zu vergleichen, vergleicht das System Bedeutungsnähe. Mehrsprachiges RAG erweitert dieses Prinzip über Sprachgrenzen hinweg.

Die drei Strategien für Cross-lingual Retrieval

Es gibt im Wesentlichen drei technische Wege, um Fragen und Dokumente in unterschiedlichen Sprachen zusammenzubringen. In der Praxis werden sie häufig kombiniert.

1. Mehrsprachige Embeddings

Multilinguale Embedding-Modelle bilden Texte aus unterschiedlichen Sprachen in denselben Vektorraum ab, sodass ein deutscher Satz und seine französische Übersetzung rechnerisch nah beieinanderliegen. Wie das genau funktioniert, erklärt der Beitrag Embeddings einfach erklärt. Der Vorteil: keine separate Übersetzung nötig, die semantische Suche funktioniert direkt. Der Nachteil: Bei seltenen Sprachpaaren oder sehr fachspezifischem Vokabular (Rechtstermini, Maschinenbezeichnungen) ist die Trennschärfe geringer als bei einsprachiger Suche.

2. Übersetzung zur Abfragezeit (Query Translation)

Hier wird die Frage des Nutzers vor der Suche automatisch in die Sprache (oder Sprachen) der Dokumente übersetzt, die Suche läuft dann einsprachig, und erst die finale Antwort wird wieder in die Sprache des Nutzers zurückübersetzt. Das hat den Vorteil, dass die eigentliche Retrieval-Logik (Stemming, Volltextsuche) pro Sprache optimal bleibt. Der Nachteil: Übersetzungsfehler bei Fachbegriffen pflanzen sich fort, und bei Dokumenten in mehreren Sprachen muss die Frage gegebenenfalls in mehrere Sprachen gleichzeitig übersetzt werden.

3. Vorab-Übersetzung der Dokumente

Alternativ lassen sich alle Dokumente bereits bei der Indexierung in eine gemeinsame Zielsprache (meist Englisch) übersetzt und zusätzlich zum Original gespeichert werden. Das vereinfacht die Suche erheblich, verdoppelt aber den Speicher- und Pflegeaufwand und bedeutet, dass bei jeder Dokumentenänderung die Übersetzung erneuert werden muss.

In der Praxis fahren die meisten produktiven Systeme hybrid: mehrsprachige Embeddings für die semantische Komponente, kombiniert mit sprachspezifischer Volltextsuche auf dem Originaltext. Genau diese Kombination aus Volltext und semantischer Erweiterung nennt man Hybrid Search, und sie ist auch der Grund, warum Kopik bei der Indexierung beide Suchmechanismen gleichzeitig aufbaut, statt sich auf nur einen zu verlassen.

Sprachspezifisches Stemming und Tokenisierung

Die semantische Suche ist nur die halbe Miete. Die Volltextsuche (BM25 und Verwandtes) braucht pro Sprache eigene Regeln, um Wortformen zu normalisieren. Deutsch stellt dabei eine besondere Herausforderung dar wegen zusammengesetzter Wörter: „Reisekostenabrechnung” muss im Index auch über „Reisekosten” oder „Abrechnung” gefunden werden können, was eine Kompositazerlegung erfordert. Französisch braucht korrektes Handling von Akzenten und Elisionen (l'entreprise vs. la entreprise), und slawische Sprachen wie Polnisch oder Tschechisch haben eine deutlich komplexere Flexion als Englisch.

• Deutsch: Kompositazerlegung, Umlaut-Normalisierung (ü/ue, ö/oe, ä/ae)
• Französisch: Akzente, Apostroph-Elisionen, Geschlechtsformen
• Englisch: einfache Stemming-Regeln, aber viele Homonyme
• Polnisch/Tschechisch: starke Flexion, Stemmer müssen Deklinationsfälle abdecken

Wenn ein System nur einen generischen, englisch-zentrierten Stemmer für alle Sprachen verwendet, sinkt die Trefferquote in anderen Sprachen spürbar, selbst wenn die semantische Suche im Hintergrund noch funktioniert. Das Thema Chunking spielt hier ebenfalls hinein: Zu grobe oder zu feine Textabschnitte wirken sich in jeder Sprache unterschiedlich aus, mehr dazu in Chunking-Strategien für RAG.

Qualitätschecks: Wie Sie messen, ob die mehrsprachige Suche wirklich funktioniert

Mehrsprachiges RAG lässt sich nicht an einem einzigen Testset validieren. Jede Sprachkombination (Frage-Sprache zu Dokument-Sprache) verhält sich anders und muss separat geprüft werden. Der allgemeine Rahmen für RAG-Evaluierung gilt auch hier, siehe RAG-System evaluieren, nur dass Sie ihn pro Sprachpaar wiederholen.

1. Erstellen Sie ein Testset mit 20-30 Frage-Antwort-Paaren je relevantem Sprachpaar, idealerweise von Muttersprachlern formuliert
2. Messen Sie Trefferquote (Recall) und Genauigkeit der zitierten Passagen getrennt für jede Sprachkombination
3. Prüfen Sie gezielt Fachbegriffe und Eigennamen, da diese bei Übersetzung am häufigsten verloren gehen
4. Lassen Sie Muttersprachler die generierten Antworten auf Natürlichkeit und fachliche Korrektheit prüfen, nicht nur auf Grammatik
5. Wiederholen Sie die Checks nach jedem Modellwechsel, da sich die Cross-lingual-Qualität zwischen Embedding-Versionen deutlich unterscheiden kann

Praxisbeispiel: ein Hersteller mit Dokumenten in vier Sprachen

Stellen Sie sich einen mittelständischen Maschinenbauer vor, der Betriebsanleitungen auf Deutsch verfasst, aber Kunden in Frankreich, Polen und Großbritannien beliefert. Statt für jede Sprache eine separate Wissensdatenbank zu pflegen, lassen sich alle Originaldokumente in einer einzigen Basis zusammenführen. Über /dashboard/bases/new laden Sie die PDFs und Word-Dateien hoch, unabhängig von ihrer Sprache, und Kopik übernimmt Extraktion, Chunking und Indexierung für die hybride Suche. Ein polnischer Servicetechniker kann dann auf Polnisch fragen und erhält eine Antwort mit Zitat aus dem deutschen Originaldokument, während die Basis intern weiterhin konsistent bleibt. Wer die Wissensdatenbank zusätzlich extern anbieten möchte, kann sie öffentlich listen und im Katalog sichtbar machen, oder sie privat halten und nur über API-Schlüssel oder einen MCP-Server intern anbinden, wie in Claude, Cursor oder ChatGPT mit einer Wissensdatenbank verbinden beschrieben.

Datenschutz und regulatorische Fragen bei automatischer Übersetzung

Sobald eine Übersetzungs-API im Spiel ist, verlassen Fragetexte und möglicherweise sensible Dokumentenauszüge Ihre ursprüngliche Infrastruktur. Das ist datenschutzrechtlich nicht automatisch problematisch, muss aber geprüft werden: Wo liegt der Serverstandort des Übersetzungsdienstes, gibt es eine Auftragsverarbeitungsvereinbarung, und werden Inhalte zum Training weiterverwendet? Eine strukturierte Vorgehensweise dazu finden Sie in DSGVO und RAG: Checkliste. Wer eine mehrsprachige RAG-Anwendung öffentlich oder gegenüber Mitarbeitenden einsetzt, sollte zudem die Einordnung nach dem EU AI Act prüfen, siehe EU AI Act und RAG-Assistenten.

Checkliste zum Einstieg in mehrsprachiges RAG

• Welche Sprachpaare kommen im Alltag wirklich vor? Nicht für hypothetische Fälle optimieren
• Nutzt die Suche mehrsprachige Embeddings, Query Translation oder beides kombiniert?
• Ist das Volltext-Stemming pro Sprache konfiguriert, nicht nur ein generischer englischer Stemmer?
• Gibt es getrennte Testsets und Kennzahlen je Sprachpaar?
• Wurde geprüft, wo Übersetzungsdienste Daten verarbeiten und ob ein AV-Vertrag vorliegt?
• Werden Fachbegriffe und Eigennamen stichprobenartig von Muttersprachlern kontrolliert?

Fazit

Mehrsprachiges RAG ist kein Sonderfall, sondern für jedes international tätige Team mittelfristig der Normalfall. Die technische Grundlage, mehrsprachige Embeddings für die semantische Komponente und sprachspezifisches Stemming für die Volltextsuche, lässt sich heute fertig beziehen, statt selbst gebaut zu werden. Wer die Qualität sauber pro Sprachpaar misst und die regulatorischen Punkte früh klärt, spart sich spätere Überraschungen. Weitere technische Details zur Anbindung finden Sie in den Entwickler-Dokumenten.