Wenn eine Lokalisierungs-Pipeline Retrieval-Augmented Generation nutzt, um Glossarbegriffe in das Kontextfenster des Modells einzuspeisen, hat sie ein Problem mit dem Retrieval-Recall, das noch nie gemessen wurde.
Das Muster ist universell: Eingabetext einbetten, per Kosinus-Ähnlichkeit eine Terminologiedatenbank durchsuchen, die Top-k-Treffer in den Prompt einfügen. Die Ausgabe ist grammatikalisch korrekt. Die Terminologie ist falsch. Der Fehler bleibt unsichtbar, wenn nicht jemand beide Sprachen spricht und das Glossar kennt.
Wir haben diese naive Version zuerst gebaut. Dann haben wir den Retrieval-Recall mit Produktivglossaren gemessen – und festgestellt, dass dem System bei echten Payloads die Mehrheit der anwendbaren Begriffe entging.
| Technik | Retrieval-Augmented Localization (RAL) – Kontexterweiterung zur Inferenzzeit |
| Kernkorrektur | N-Gramm-Zerlegung vor dem Embedding statt Embeddings auf Satzebene |
| Retrieval-Modi | 3 (skip / preload / vector search), pro Anfrage nach Glossarkardinalität ausgewählt |
| Schwellenwertkalibrierung | Kontinuierlich, wöchentlich, anhand von Qualitätswerten pro Sprachpaar |
| Reduktion von Terminologiefehlern | 17–45 % über fünf LLM-Anbieter hinweg (kontrollierte Studie, 42.000+ Qualitätsbewertungen) |
| Bewertung | Unabhängige modellübergreifende Auswertung, asynchron, pro Anfrage |
Warum übersehen Satz-Embeddings Glossarbegriffe?#
Ein Glossarbegriff besteht aus 1–3 Wörtern. "Lokalisierungs-Engine." "Zugriffstoken." "Deployment-Pipeline."
Der Eingabetext ist ein JSON-Objekt mit Werten, die von zwei Wörtern (eine Button-Beschriftung) bis zu zweihundert Wörtern (eine Produktbeschreibung) reichen. Wenn der vollständige String "Configure the localization engine for production deployment" eingebettet wird, erfasst der resultierende Vektor die semantische Bedeutung des Satzes – also irgendetwas zu Konfiguration und Produktionssystemen. Die glossarrelevante Phrase "localization engine" geht in dieser Repräsentation auf Satzebene unter.
Die Kosinus-Ähnlichkeit zwischen diesem Satzvektor und dem Glossareintrag "localization engine" liegt im Bereich von 0,6–0,7. Unter dem Retrieval-Schwellenwert. Der Begriff ist in der Eingabe vorhanden. Das Retrieval-System verpasst ihn.
Das Problem ist die Granularität: Repräsentationen auf Satzebene werden auf Ziele auf Phrasenebene angesetzt. Das Embedding-Modell bildet die Bedeutung des Satzes als Ganzes korrekt ab. Die enthaltene Terminologie besetzt keine eigene, unabhängige Region im Vektorraum.
Wir haben das auf die harte Tour gelernt. Bei Produktiv-Payloads – verschachtelte JSON-Objekte mit 20–50 Schlüsseln und Werten unterschiedlicher Länge – übersah das Retrieval auf Satzebene die Mehrheit der anwendbaren Glossarbegriffe. Die Lokalisierungsanfrage lief problemlos durch. Die Ausgabe las sich flüssig. Aber "localization engine" wurde zu "translation tool" – grammatikalisch korrekt, semantisch nah dran, terminologisch falsch. Und die Pipeline meldete Erfolg.
Wie behebt N-Gramm-Zerlegung das Glossar-Retrieval?#
Die Lösung war letztlich, die Eingabe vor dem Embedding in Einheiten auf Phrasenebene zu zerlegen. Jeder String-Wert wird zu einer Menge überlappender N-Gramm-Fenster:
Input: "Configure the localization engine for production"
1-grams: [configure, the, localization, engine, for, production]
2-grams: [configure the, the localization, localization engine,
engine for, for production]
3-grams: [configure the localization, the localization engine,
localization engine for, engine for production]Jedes N-Gramm wird zu einer eigenständigen Retrieval-Anfrage. "Localization engine" fragt das Glossar als eigenständige Phrase ab – und findet seinen Treffer bei hoher Ähnlichkeit.
Die Zerlegungs-Pipeline:
- Alle String-Werte rekursiv aus verschachtelten JSON-Strukturen extrahieren
- In Sätze aufteilen, HTML und Markup-Anmerkungen entfernen
- Leerzeichen normalisieren, umschließende Anführungszeichen entfernen, Formatierungen de-escapen
- Überlappende 1-Gramm-, 2-Gramm- und 3-Gramm-Phrasen aus jedem Satz erzeugen
Ein Absatz mit 50 Wörtern ergibt ungefähr 150 N-Gramme. Eine typische API-Payload mit 20 Schlüsseln liefert 1.000–3.000 durchsuchbare Phrasen. Jede Phrase wird unabhängig eingebettet, und jedes Embedding führt eine Nearest-Neighbor-Abfrage gegen den Vektorindex des Glossars aus.
Wir haben den Unterschied an denselben Produktiv-Payloads gemessen, die das ursprüngliche Problem sichtbar gemacht haben. Glossarbegriffe werden jetzt unabhängig vom umgebenden Satzkontext gefunden – ein Begriff mit 2 Wörtern, versteckt in einer 200 Wörter langen Produktbeschreibung, erzielt denselben Recall wie eine eigenständige Beschriftung.
Wie funktioniert adaptives Retrieval bei unterschiedlichen Glossargrößen?#
N-Gramm-Zerlegung und Batch-Embedding sind für große Glossare der richtige Ansatz. Für kleine Glossare erwies sich das dagegen als rechnerisch ineffizient.
Eine Lokalisierungs-Engine, die mit 8 Glossarbegriffen konfiguriert ist, arbeitet mit direkter Injektion schneller – eine Datenbankabfrage, deterministisch, unter einer Millisekunde. Eine Lokalisierungs-Engine mit 2.000 Begriffen erfordert Vektorsuche – Grenzen des Kontextfensters und verwässerte Relevanz machen eine vollständige Injektion unmöglich.
Drei Retrieval-Modi arbeiten pro Anfrage und werden anhand der Glossarkardinalität für das Sprachpaar ausgewählt:
| Modus | Bedingung | Verhalten |
|---|---|---|
| Skip | Keine passenden Einträge | Kein Embedding, keine Suche, keine Injektion |
| Preload | Unterhalb des Kardinalitätsschwellenwerts | Eine einzelne Datenbankabfrage lädt alle passenden Einträge; direkte Injektion |
| Search | Oberhalb des Kardinalitätsschwellenwerts | Vollständige N-Gramm-Zerlegung → Batch-Embedding → Vektor-Nearest-Neighbor-Suche |
Der Kardinalitätsschwellenwert, der Preload von Search trennt, wird aus Latenzprofilen im Produktivverkehr abgeleitet und angepasst, wenn sich die Leistung des Embedding-Modells, die Verteilung der Glossargrößen oder die Eigenschaften der Infrastruktur verschieben. Der anfängliche Wert, den wir ausgerollt haben, hielt ungefähr drei Wochen, bevor die Telemetrie zeigte, dass er angepasst werden sollte. Seitdem wurde er mehrfach verändert – wir haben festgestellt, dass der optimale Schwellenwert driftet, wenn Engines mehr Glossarbegriffe ansammeln und sich die Eigenschaften von Embedding-Modellen zwischen Anbieter-Updates weiterentwickeln.
Die Retrieval-Latenz skaliert mit der Komplexität des Glossars, nicht mit der Größe der Payload. Eine Lokalisierungs-Engine mit 10 Begriffen arbeitet unabhängig von der Eingabelänge in einstelligen Millisekunden. Eine Lokalisierungs-Engine mit 500 Begriffen nutzt die vollständige Zerlegungs-Pipeline, bleibt aber innerhalb des Latenzbudgets eines robusten Hintergrund-Workflow-Schritts.
Wie wird der Ähnlichkeitsschwellenwert für Glossar-Retrieval kalibriert?#
Jedes N-Gramm-Embedding fragt den Vektorindex nach nächsten Nachbarn oberhalb eines Ähnlichkeitsschwellenwerts ab. Treffer unterhalb dieses Schwellenwerts werden als Rauschen verworfen.
Der Schwellenwert bestimmt Präzision und Recall des Retrievals gleichzeitig:
- Zu großzügig: Unzusammenhängende Begriffe landen im Prompt. Das Modell sieht Glossarkontext, der nicht zur Eingabe passt, und folgt ihm gelegentlich – mit einer Ausgabe, die Terminologie aus einem völlig anderen Bereich verwendet.
- Zu streng: Legitime Varianten in der Formulierung und morphologische Formen werden ausgeschlossen. "Deploying" passt dann nicht mehr zum Glossareintrag "deploy." Der Recall sinkt.
Wir haben festgestellt, dass der richtige Schwellenwert je nach Sprachpaar variiert. English→German-Retrieval weist andere Ähnlichkeitsverteilungen auf als English→Japanese, wo sich die morphologische Distanz zwischen Quell-N-Grammen und Glossareinträgen strukturell unterscheidet. Ein einzelner globaler Schwellenwert führte bei den von uns gemessenen Sprachpaaren zu inkonsistentem Recall.
Der Schwellenwert wird jetzt kontinuierlich anhand von Qualitätswerten pro Sprachpaar aus einer unabhängigen Bewertungs-Pipeline kalibriert. Wenn das Bewertungssystem einen Anstieg bei Glossarverstößen erkennt (Begriffe sind in der Eingabe vorhanden, fehlen aber in der Ausgabe), hat sich der Retrieval-Recall verschlechtert und der Schwellenwert wird gelockert. Wenn die Bewertung erkennt, dass das Modell irrelevante Terminologie anwendet, haben falsch positive Injektionen zugenommen und der Schwellenwert wird angezogen.
Diese Kalibrierung läuft wöchentlich. Das muss sie auch – das Verhalten von Embedding-Modellen verschiebt sich zwischen Anbieter-Updates, Glossarverteilungen ändern sich, wenn Teams Begriffe hinzufügen, und die Eigenschaften von Eingabetexten entwickeln sich weiter, wenn Produkte wachsen.
Wie werden abgerufene Glossarbegriffe in das Lokalisierungsmodell injiziert?#
Abgerufene Glossareinträge teilen sich in zwei Klassen von Einschränkungen mit unterschiedlichem Durchsetzungsverhalten im System-Prompt des Modells:
Nicht übersetzbare Begriffe – quellsprachige Strings, die unverändert in der Zielausgabe erscheinen müssen. Markennamen, technische Kennungen, Produktnamen. Das Modell übernimmt diese wortwörtlich.
Benutzerdefinierte Übersetzungen – Quell→Ziel-Zuordnungen, die die eigene Einschätzung des Modells außer Kraft setzen. "Localization engine" muss zu "moteur de localisation" werden. Das Modell behandelt diese als nicht verhandelbare lexikalische Einschränkungen.
Beide Klassen werden als Regeln mit explizitem Vorrang vor dem Standardverhalten des Modells in den System-Prompt injiziert. Die Prompt-Hierarchie erzwingt die Einhaltung des Glossars über die sprachlichen Präferenzen des Modells hinweg.
Die Unterscheidung ist bei der Bewertung entscheidend: Das unabhängige Bewertungsmodell prüft, ob nicht übersetzbare Begriffe unverändert erhalten blieben und ob benutzerdefinierte Übersetzungen exakt angewendet wurden. Zwei Prüfkriterien für zwei Arten von Einschränkungen. Wir haben früh festgestellt, dass ihre Zusammenfassung in eine einzige "Glossar"-Kategorie die Bewertung unzuverlässig machte – ein Begriff, der wortwörtlich erhalten blieb, obwohl er hätte übersetzt werden sollen (oder umgekehrt), wurde bei einer einheitlichen Prüfung als korrekt bewertet.
Wie validiert man Lokalisierungsqualität in Sprachen, die man nicht spricht?#
Die gesamte Retrieval- und Lokalisierungs-Pipeline kann fehlerfrei laufen und trotzdem terminologisch falsche Ausgaben erzeugen. Ein übersehener Glossarbegriff erzeugt kein Fehlersignal. Eine falsch angewendete benutzerdefinierte Übersetzung liefert einen 200er zurück. Die Pipeline ist erfolgreich. Die Ausgabe ist falsch.
Das ist die Observability-Lücke in der Lokalisierung, die die meisten Teams nie schließen.
Retrieval ist mit einer unabhängigen asynchronen Bewertung gekoppelt. Nach Abschluss einer Lokalisierungsanfrage bewerten separate Bewertungsmodelle die Ausgabe anhand der Konfiguration der Lokalisierungs-Engine:
- Glossareinhaltung – wurden nicht übersetzbare Begriffe unverändert erhalten? Wurden benutzerdefinierte Übersetzungen exakt angewendet?
- Einhaltung von Anweisungen – wurden sprachspezifische Regeln befolgt?
- Benutzerdefinierte Bewertungskriterien – qualitative Dimensionen pro Engine, definiert vom Lokalisierungsteam
Die Bewertungsmodelle laufen auf einer anderen Infrastruktur als das Lokalisierungsmodell. Sie arbeiten asynchron in Hintergrund-Workflows und werden nach jeder Anfrage ausgelöst, die durch eine Lokalisierungs-Engine mit aktivierter Bewertung läuft. Ein Modell lokalisiert, ein anderes bewertet. Diese modellübergreifende Auswertung beseitigt das Problem der Selbstbewertung.
Die Bewertungsergebnisse fließen zurück in die Kalibrierung des Retrievals:
- Die Bewertung erkennt, dass die Glossar-Nichteinhaltung für ein Sprachpaar zunimmt
- Die Analyse zeigt, dass der Retrieval-Recall gesunken ist – der Schwellenwert hat sich relativ zur aktuellen Glossarverteilung verschoben
- Der Schwellenwert wird angepasst, der Recall erholt sich, die Einhaltung stabilisiert sich
Diese Schleife macht das System selbstkorrigierend. Die Bewertung schafft die Observability, die dem Retrieval allein fehlt. Ohne sie liefern Teams lokalisierte Inhalte in Sprachen aus, die sie nicht selbst sprechen – ohne jedes Signal, ob das von ihnen aufgebaute Glossar tatsächlich angewendet wird.
Warum potenziert sich der Retrieval-Recall im Laufe der Zeit?#
Jede Lokalisierungsanfrage, bei der Glossarbegriffe korrekt angewendet werden, stärkt die terminologische Konsistenz im gesamten Produkt. Jede Anfrage, bei der ein Begriff verfehlt wird, führt zu Drift – eine Oberfläche sagt „Lokalisierungs-Engine“, eine andere „Lokalisierungstool“, eine dritte „Lokalisierungsmodul“. Über 30 Sprachen und wöchentliche Releases hinweg summieren sich diese Inkonsistenzen.
Der Unterschied zwischen hohem und niedrigem Retrieval-Recall ist kein Qualitätsunterschied pro Anfrage. Er ist ein Mechanismus, der Konsistenz über Zeit aufbaut. Hoher Recall bedeutet, dass das Glossar jede Oberfläche, jede Sprache und jedes Release einheitlich durchsetzt. Niedriger Recall bedeutet, dass das Glossar nur gelegentlich greift – strukturell fast so, als gäbe es gar kein Glossar, nur mit langsamerer Erosion.
Was das für Localization Engineering bedeutet#
Das hier beschriebene Retrieval-Problem ist nicht auf eine bestimmte Implementierung beschränkt. Es ist strukturell in jedem System angelegt, das glossarbewusste Lokalisierung mit embeddingbasierter Suche umsetzen will. Der Granularitätskonflikt zwischen Eingaberepräsentationen auf Satzebene und Glossarzielen auf Phrasenebene besteht unabhängig davon, welches Embedding-Modell, welche Vektordatenbank oder welches LLM die Ausgabe erzeugt.
Teams, die Lokalisierungsautomatisierung aufbauen, stehen vor einer Wahl: Sie akzeptieren Retrieval auf Satzebene mit seiner unsichtbaren Recall-Lücke – oder sie bauen die Dekompositions- und Kalibrierungsinfrastruktur, die diese Lücke schließt. Der zweite Weg erfordert drei Systeme: n-Gramm-Dekomposition, adaptives Retrieval und eine Bewertungsschleife, die in das Schwellenwertmanagement zurückspielt. Jedes System hat seinen eigenen operativen Rhythmus: Die Dekompositionslogik entwickelt sich weiter, wenn sich Eingabeformate ändern, Retrieval-Schwellenwerte verschieben sich, wenn Glossare wachsen, und Bewertungskriterien werden verfeinert, wenn Lokalisierungsteams lernen, welche Dimensionen für ihre Inhalte entscheidend sind.
Retrieval-gestützte Lokalisierung in Produktionsqualität ist eine fortlaufende Engineering-Praxis – ein System, das kontinuierlich aufgebaut, instrumentiert, beobachtet und feinjustiert wird. Die Disziplin des Localization Engineering, die rund um diese Arbeit entsteht, spiegelt die operative Realität wider: Lokalisierungsinfrastruktur erfordert dieselbe kontinuierliche Aufmerksamkeit wie Backend-Services, CI/CD-Pipelines und Observability-Stacks.
Nächste Schritte#
FAQ#
Was ist retrieval augmented localization (RAL)? Retrieval augmented localization reichert jede Lokalisierungsanfrage zur Inferenzzeit mit Glossarbegriffen, Regeln zur Markenstimme und sprachspezifischen Anweisungen an – dasselbe Retrieve-Inject-Muster wie bei RAG, angewendet auf Lokalisierung. In einer kontrollierten Studie mit fünf LLM-Anbietern und fünf europäischen Sprachen reduzierte RAL Terminologiefehler im Vergleich zu denselben Modellen ohne Kontextanreicherung um 17–45 %.
Warum verfehlen Embeddings auf Satzebene Glossarbegriffe? Glossarbegriffe bestehen typischerweise aus 1–3 Wörtern. Werden sie als Teil eines vollständigen Satzes eingebettet, gehen sie im semantischen Vektor des Satzes auf. Das Embedding erfasst die Bedeutung des Satzes als Ganzes – „Lokalisierungs-Engine“ in „Konfigurieren Sie die Lokalisierungs-Engine für die Produktion“ wird nicht unabhängig registriert. Die Kosinusähnlichkeit zwischen dem Satzvektor und dem Glossareintrag fällt unter den Retrieval-Schwellenwert.
Wie verbessert n-Gramm-Dekomposition den Retrieval-Recall? Statt vollständige Eingabestrings einzubetten, zerlegt das System den Text vor dem Einbetten in überlappende 1-Gramm-, 2-Gramm- und 3-Gramm-Phrasen. Jede Phrase wird zu einer unabhängigen Retrieval-Anfrage. Ein zweigliedriger Glossarbegriff, der in einem Absatz mit 200 Wörtern verborgen ist, erreicht denselben Recall wie ein eigenständiges Label – weil er unabhängig von seinem umgebenden Kontext abgefragt wird.
Wie viele Retrieval-Modi verwendet das System? Drei. Skip (null Glossareinträge – kein Retrieval nötig), Preload (unterhalb eines Kardinalitätsschwellenwerts – alle Einträge direkt laden) und Vektorsuche (oberhalb des Schwellenwerts – vollständige n-Gramm-Dekomposition und Einbettung). Der Modus wird pro Anfrage anhand der Glossarkardinalität für das jeweilige Sprachpaar ausgewählt.
Wie wird der Ähnlichkeitsschwellenwert gepflegt? Der Schwellenwert wird wöchentlich anhand von Qualitätswerten pro Sprachpaar aus einer unabhängigen Bewertungs-Pipeline kalibriert. Wenn die Glossar-Nichteinhaltung zunimmt, wird der Schwellenwert gelockert, um den Recall zu verbessern. Wenn irrelevante Begriffe in Prompts gelangen, wird der Schwellenwert verschärft. Unterschiedliche Sprachpaare erfordern aufgrund unterschiedlicher morphologischer Distanzen unterschiedliche Schwellenwerte.
Wie funktioniert modellübergreifende Bewertung für Lokalisierungsqualität? Nach Abschluss jeder Lokalisierungsanfrage bewertet ein separates Modell – das auf einer anderen Infrastruktur läuft –, ob Glossarbegriffe korrekt angewendet wurden, ob sprachspezifische Anweisungen befolgt wurden und ob benutzerdefinierte Qualitätskriterien erfüllt wurden. Ein Modell lokalisiert, ein anderes bewertet. Das beseitigt den Bias der Selbstbewertung und schafft die Observability, die dem Retrieval allein fehlt.
Was passiert, wenn der Retrieval-Recall des Glossars niedrig ist? Niedriger Retrieval-Recall bedeutet, dass das Glossar inkonsistent greift – eine Oberfläche erhält den richtigen Begriff, eine andere nicht. Über 30+ Sprachen und wöchentliche Releases hinweg summieren sich diese Inkonsistenzen zu Terminologiedrift. Das Glossar existiert, setzt sich aber nicht durch. Über Monate hinweg ist das strukturell fast so, als gäbe es überhaupt kein Glossar.
Was ist die Observability-Lücke bei der Lokalisierung? Eine Lokalisierungs-Pipeline kann fehlerfrei laufen und trotzdem terminologisch falsche Ausgaben erzeugen. Übersehene Glossarbegriffe erzeugen kein Fehlersignal – die API gibt 200 zurück, die Übersetzung ist grammatikalisch korrekt. Die Observability-Lücke ist der Raum zwischen „Pipeline erfolgreich“ und „Terminologie ist korrekt“. Unabhängige Bewertung schließt diese Lücke, indem die Glossareinhaltung bei jeder Anfrage gemessen wird.
