Unsere Bewerber sprechen Deutsch, Polnisch, Türkisch, Rumänisch, Russisch, Ukrainisch, Bulgarisch, Kroatisch, Englisch, Arabisch, Spanisch und Portugiesisch. Jeder dieser Bewerber erwartet Antworten in seiner Sprache, mit kulturellen Konventionen, die in den jeweiligen Markt passen. Das ist nicht „ein Übersetzer". Das ist Architektur.
Was die Anforderung wirklich heißt
Mehrsprachig bedeutet im Recruiting nicht „den Text mit DeepL übersetzen". Es bedeutet:
- Eingehende Nachrichten in beliebiger Sprache verstehen, auch wenn sie in lateinischer Tastatur Türkisch oder mit kyrillischen Buchstaben geschrieben sind.
- Die Antwort in der vom Bewerber bevorzugten Sprache formulieren, mit kulturell angemessenen Anredeformen.
- Den Übergang zum Recruiter (der zumeist nur Deutsch oder Englisch spricht) sauber moderieren.
- Die Konversation für die Auswertung übersetzen und gleichzeitig das Original protokollieren.
Schritt 1: Sprach-Routing
Jede eingehende Nachricht passiert ein kleines Klassifikationsmodell, das in unter 50 Millisekunden die wahrscheinlichste Sprache bestimmt. Das Modell läuft lokal, ohne externe Calls, und ist auf die 12 Sprachen unseres Use Cases optimiert. Bei Mischsprachen (häufig: Deutsch + Polnisch in einer Nachricht) gewinnt die dominante Sprache, der Rest wird im Kontext erhalten.
Schritt 2: Das Basismodell
Wir nutzen ein finegetuntes Llama-3-Modell als Basis. Der Vorteil gegenüber spezialisierten pro-Sprache-Modellen: ein Modell kennt die Konversationslogik des Use Cases. Der Nachteil: die Sprachqualität in Randsprachen (Bulgarisch, Kroatisch) ist um 5 bis 7 Prozentpunkte niedriger als in den Hauptsprachen.
Wir messen pro Sprache die Conversion-Rate vom Erstkontakt zum gebuchten Termin als Proxy für Qualität. Auf Basis dieser Zahl entscheiden wir, ob wir in einer Sprache investieren oder nicht.
Schritt 3: Sprach-Adapter
Für Polnisch, Türkisch und Rumänisch (zusammen 38 % unseres Traffics) haben wir LoRA-Adapter trainiert. Die Adapter haben rund 80 Millionen Parameter, gegenüber 70 Milliarden im Basismodell. Sie werden zur Laufzeit eingehängt, wenn die Routing-Schicht die entsprechende Sprache erkennt.
Der Effekt ist messbar: die Conversion in diesen drei Sprachen ist um 18 % höher als ohne Adapter, bei vernachlässigbarem Latenz-Overhead.
Schritt 4: Evaluations-Loop
Jede Konversation wird in einer Nachbearbeitung von einem Dual-Reviewer-Setup bewertet: eine LLM klassifiziert die Konversation entlang von 12 Qualitätsmerkmalen (Höflichkeit, Klarheit, korrekter Kontext, ...), eine zweite LLM überprüft die erste. Bei Konflikt geht die Konversation an einen menschlichen Reviewer.
Die Ergebnisse fließen einmal pro Woche in einen Fine-Tuning-Lauf zurück. Damit verbessert sich das Modell kontinuierlich, ohne dass wir neue Trainingsdaten von außen brauchen.
Was wir bewusst nicht tun
- Wir nutzen nicht separate Modelle pro Sprache. Der operative Aufwand wäre 12× höher, der Qualitätsgewinn marginal.
- Wir nutzen nicht externe Übersetzungsdienste in der Live-Konversation. Latenz und Datenschutz sprechen dagegen.
- Wir nutzen nicht generelle Multilingual-Benchmarks zur Qualitätsmessung. Wir messen ausschließlich auf unserem Use Case (Recruiting im DACH-Raum).
Was bleibt, ist eine Architektur, die für 95 % unserer Konversationen unter zwei Sekunden Latenz liefert, in jeder unterstützten Sprache. Die restlichen 5 % gehen explizit an Menschen.