Einblick in die vier Übersetzungs-Pipelines, die InterMIND antreiben

Die alte Seite /product/overview/how-it-works auf mind.com ist mehrere Major-Releases alt. Sie beschreibt eine einzige "Übersetzungs-Engine", wie es die meisten Anbieter-Seiten tun – ein großer Pfeil von "Sie sprechen" zu "Sie hören". Dieses Bild war vor zwei Jahren bereits eine Vereinfachung. Heute ist es falsch.

Die Wahrheit ist, dass InterMIND vier separate Übersetzungs-Pipelines betreibt, von denen jede ein anderes Problem mit einer anderen Engine, einem anderen Latenzbudget und einer anderen Qualitätsanforderung löst. Sie teilen sich einen Sprachwähler. Sie teilen sich keine Engine.

Dies ist die aktualisierte Antwort auf die Frage "Wie funktioniert das?".

Ein Begleitartikel: "Wie viele Sprachen unterstützen Sie?" behandelt, was jede Pipeline abdeckt (24 / 24 / 30 / 17). Dieser Beitrag behandelt, was jede Pipeline tut – und warum sie ihr eigenes Ding ist.

Warum "eine Engine für alles" eine Lüge ist

Eine Live-Meeting-Plattform muss mindestens vier Aufgaben gleichzeitig erfüllen, und diese ziehen in unvereinbare Richtungen:

1. Echtzeit-Sprache – Audio rein, übersetztes Audio raus, unter einer Sekunde, jeder Zuschauer in seiner eigenen Sprache. Die harte Einschränkung ist die Latenz.
2. Echtzeit-Chat-Text – kurze Nachrichten, schnell, mit bearbeiteten Inhalten, Zitaten und erhaltenem HTML-Strukturaufbau.
3. Echtzeit-geteilte Notizen – gemeinsames Tippen Zeichen für Zeichen, mit einer hierarchischen Struktur (Listen, Überschriften, Kontrollkästchen), die die Übersetzung überstehen muss.
4. Asynchrone Dokumentdateien – ein 40-seitiges PDF, das in den Chat gezogen wird. Kein Latenzbudget. Die harte Einschränkung ist die Wiedergabetreue – Formatierung, Tabellen, Seitenzahlen, Schriftart.

Man kann einen riesigen LLM-Aufruf bauen, der versucht, alle vier Aufgaben zu erledigen. Wir haben es versucht. Er ist bei allen vier schlecht. Das Latenzbudget für Sprache bedeutet, dass das Modell nicht nachdenken kann; das Wiedergabetreue-Budget für Dokumente bedeutet, dass das Modell es tun muss. Eine Chat-Bearbeitung benötigt einen Diff in der Sprache des Zuschauers; ein 40-seitiges PDF erfordert eine Formaterhaltung, die Ihnen kein Token-Streaming-Modell bietet.

Also betreiben wir vier. Hier ist jede einzelne.

Pipeline 1: Echtzeit-Sprachübersetzung

Das Problem: Ein Teilnehmer spricht Französisch. Ein anderer Teilnehmer ist auf Deutsch beigetreten, ein dritter auf Brasilianischem Portugiesisch, ein vierter auf Japanisch. Jeder muss den Sprecher in seiner eigenen Sprache hören, in seinem eigenen Ohr, mit einer Verzögerung, die kurz genug ist, um den Augenkontakt aufrechtzuerhalten.

Das Budget: Unter einer Sekunde End-to-End. Alles über ~1,2 Sekunden und die Konversation bricht ab – die Menschen beginnen, die Übersetzung zu übertönen, und das Meeting driftet in Richtung "Lasst uns einfach auf Englisch wechseln."

Wie sich das Audio tatsächlich bewegt

Ein paar Dinge, die es wert sind, explizit genannt zu werden:

• ASR läuft im Browser des Sprechers, nicht auf einem zentralen Server. Wir nutzen das Mind SDK lokal; das spart einen Round-Trip und gibt uns das Transkript in der Quellsprache mit der geringstmöglichen Verzögerung, bevor die Übersetzung überhaupt beginnen kann.
• Die Übersetzung ist kein einfacher Fan-Out. Wir halten einen Pool von WebSocket-Verbindungen zu unserer Übersetzungs-Engine, eine pro im Raum vorhandener Zielsprache. Wenn drei Teilnehmer Deutsch gewählt haben, teilt sich Deutsch eine Verbindung. Wenn niemand Arabisch gewählt hat, wird keine Arabisch-Verbindung geöffnet. Der Pool löscht inaktive Verbindungen nach fünf Minuten. Deshalb kostet ein Meeting mit vier Sprachen dasselbe wie eines mit vierzig Sprachen, bis zu dem Punkt, wer tatsächlich anwesend ist – wir übersetzen nie in Sprachen, in denen kein Teilnehmer zuhört.
• Die synthetisierte Sprache erfolgt pro Zuschauer. Jeder Teilnehmer erhält seine eigene übersetzte Audiospur, gemischt mit dem Video des ursprünglichen Sprechers. Sie schauen sich kein Master-"übersetztes Meeting" an – sie schauen sich dasselbe Meeting an, mit ihrem persönlichen Audiokanal, übersetzt in ihre gewählte Sprache. Deshalb können zwei Personen im selben physischen Raum jeweils Kopfhörer einstecken und verschiedene Sprachen hören.

Warum dies wichtig ist, wenn ein Meeting aus dem Ruder läuft

In einem 60-minütigen Anruf mit acht Sprachen gehen Dinge auf interessante Weise kaputt: WebSockets brechen ab, ASR transkribiert vorübergehend einen Eigennamen falsch, das Netzwerk eines Teilnehmers wird instabil. Die obige Architektur ist es, die es uns ermöglicht, Fehler zu isolieren: Wenn das Audio eines Zuschauers fehlerhaft ist, betrifft das nicht die anderen sieben, denn die Übersetzungs-Engine hat nie "die Übersetzung" produziert – sie hat acht produziert, parallel, und nur die betroffene muss sich erholen.

Die Engine selbst gehört uns und wird auf unserer eigenen Infrastruktur gehostet. Wir leiten keine Echtzeit-Sprache über allgemeine LLMs von Drittanbietern. Das Latenzbudget schließt sie aus; die Vorgaben zur Datenresidenz schließen sie für regulierte Kunden aus, denen dies wirklich wichtig ist.

Was wir zur Sprachqualität veröffentlichen: /benchmark führt die Produktions-Sprach-Pipeline monatlich gegen FLORES-200-Sätze für jedes veröffentlichte Sprachpaar aus. Der Prüfer ist namentlich genannt (Gemini 2.5 Flash primär, Claude Sonnet 4 als Fallback). Die vollständige Verteilung – Median, p10, p90, Min, Max, Stichprobengröße – befindet sich auf der Seite. Siehe die Methodik, was diese Zahlen messen und was nicht.

Pipeline 2: Echtzeit-Chat-Übersetzung

Das Problem: Jede Chat-Nachricht im Meeting wird für jeden Teilnehmer in seiner eigenen Sprache übersetzt, sobald sie gesendet wird. Plus Bearbeitungen – und Bearbeitungen müssen als Bearbeitungen aussehen, nicht als Neuübersetzungen.

Das Budget: Schnell, aber nicht unter einer Sekunde. Eine Chat-Nachricht kann eine halbe Sekunde brauchen, um in einer anderen Sprache zu erscheinen, ohne dass es jemanden stört. Worauf die Menschen achten, ist, ob die Übersetzung richtig ist und ob Bearbeitungen Sinn ergeben.

Was die Chat-Pipeline tatsächlich tut

Jede Nachricht durchläuft dieselbe Übersetzungs-Engine, die auch die Sprach-Pipeline nutzt – jedoch mit anderer Vor- und Nachverarbeitung:

• Die HTML-Struktur bleibt erhalten. Chat unterstützt Rich Text (Absätze, Listen, Zitate, Fett, Kursiv). Wir konvertieren für das Modell zu Klartext, übersetzen und wickeln das Ergebnis dann wieder in die ursprünglichen Tags ein. Das Modell sieht nie das HTML – es sieht sauberen Text.
• Zitate werden unabhängig übersetzt. Wenn Sie auf eine Nachricht antworten und diese zitieren, werden der [QUOTE]…[/QUOTE]-Block und der neue Inhalt als separate Einheiten übersetzt, sodass das Modell die beiden nicht verwechseln kann.
• Lange Nachrichten werden in Blöcke unterteilt. Wir splitten an Absatzgrenzen bei 1.000 Zeichen pro Block. Jeder Block ist ein eigener Übersetzungsaufruf. Wir füttern das Modell nicht mit 4.000 Zeichen langen Romanen in einem Rutsch – die Fehlermodi (Abschneiden, verlorene Absätze, Abbrüche mitten im Satz) sind zu hässlich.
• Die Übersetzung erfolgt verzögert (lazy). Wir verwenden einen IntersectionObserver: Eine Nachricht wird erst übersetzt, wenn sie in den Viewport des Zuschauers scrollt. Der Sprachwechsel in einem lange laufenden Kanal führte früher dazu, dass jeder Übersetzungs-API-Aufruf aus der Historie neu abgespielt wurde. Heute tut er das nicht mehr.

Der interessante Teil: Bearbeitungen als Diffs

In v1.2 haben wir geändert, wie sich Chat-Bearbeitungen für Zuschauer in einer anderen Sprache verhalten. Das alte Verhalten war: Jemand bearbeitet eine Nachricht, wir übersetzen das Ganze neu, Sie sehen einen neuen Absatz und müssen herausfinden, was sich bewegt hat.

Das neue Verhalten:

1. Die ursprüngliche Nachricht wurde bereits in Ihre Sprache übersetzt.
2. Wenn der Absender bearbeitet, übersetzen wir die neue Version neu.
3. Wir berechnen den Diff zwischen Ihrer vorherigen Übersetzung und Ihrer neuen Übersetzung, in Ihrer Sprache.
4. Wir zeigen diesen Diff inline an – genauso wie Git Ihnen zeigt, was sich geändert hat.

Wenn also im Englischen aus "review by Tuesday" ein "review by Thursday" wird, sieht Ihr Kollege, der Spanisch liest, martes → jueves hervorgehoben und keinen neu übersetzten Absatz, den er neu lesen muss.

Dies erforderte es, die Chat-Pipeline als einen zustandsbehafteten (stateful) Per-Zuschauer-Cache zu behandeln, nicht als einen zustandslosen (stateless) Translate-on-Request-Endpunkt. Dokumente und Sprache brauchen das nicht. Chat schon.

Pipeline 3: Echtzeit-Übersetzung geteilter Notizen

Das Problem: Der Host öffnet ein Fenster für geteilte Notizen und beginnt zu tippen. Jeder Teilnehmer sieht die Notizen in seiner Sprache, Zeichen für Zeichen, wobei die Struktur des Dokuments – Überschriften, verschachtelte Listen, Checklisten, Code-Blöcke – intakt bleibt.

Das Budget: Dasselbe wie beim Chat (~eine halbe Sekunde), aber mit zwei zusätzlichen Einschränkungen:

• Das zu Übersetzende ändert sich mitten in der Übersetzung. Der Host tippt noch. Ein naives System, das "das gesamte Dokument" bei jedem Tastenanschlag übersetzt, erzeugt Flackern und verbrennt das API-Budget. Wir übersetzen in der Granularität der geänderten Einheit, nicht des gesamten Dokuments.
• Die Struktur muss überleben. Wenn man ein Übersetzungsmodell bittet, einen Markdown-Blob mit drei verschachtelten Listen zu übersetzen, erhält man etwas zurück, das aussieht wie das Original, aber mit subtil abgeflachter Hierarchie, neu nummerierten Elementen oder verschobener Einrückung. Wir lassen das Modell nicht den ganzen Blob sehen.

Wie sich die Notizen-Pipeline vom Chat unterscheidet

Die strukturelle Erhaltung ist die Hauptsache. Wir übersetzen jedes Listenelement unabhängig und nicht als ein Dokument. Das Modell sieht:

"Compliance-Review — Q2-Liefergegenstände"

— und nicht:

"# Projektplan\n## Quartal\n- Compliance-Review — Q2-Liefergegenstände\n- Anbieter-Bewertung\n - Tier-1-Anbieter..."

Das umschließende Dokument – das <ul>, die Überschriften, die Einrückung – wird auf der Client-Seite mit derselben Struktur neu aufgebaut, die das ursprüngliche Dokument hatte, wobei jeder Leaf-Node (Blattknoten) durch seine Übersetzung ersetzt wird. Das Modell bekommt nie die Möglichkeit, die Hierarchie zu "verbessern".

Notizen nutzen auch dasselbe Per-Zuschauer-Diff-Modell wie Chat-Bearbeitungen: Wenn der Host eine Zeile ändert, sehen Zuschauer in anderen Sprachen die geänderten Wörter hervorgehoben, keinen neuen Absatz.

Pipeline 4: Asynchrone Dokumentübersetzung

Das Problem: Jemand zieht ein 40-seitiges PDF, ein Word-Dokument, ein PowerPoint-Deck oder eine Excel-Tabelle in den Chat. Jeder Teilnehmer kann eine Kopie in seiner eigenen Sprache anfordern. Die übersetzte Datei muss wie das Original aussehen – gleiche Schriftarten, gleiche Tabellen, gleiche Seitenzahlen, gleiche Kopfzeilen, gleiche Diagramme an gleicher Stelle.

Das Budget: Keine Echtzeit-Einschränkung. Eine Minute ist in Ordnung. Zwei Minuten sind in Ordnung. Die Einschränkung ist die Wiedergabetreue – wenn das übersetzte PDF nicht wie das Original aussieht, wird der Empfänger ihm nicht vertrauen.

Warum diese Pipeline sich keine Engine mit der Sprache teilt

Ein allgemeines LLM, selbst ein sehr gutes, wird Ihnen einen übersetzten Text eines Dokuments zurückgeben. Es wird Ihnen kein übersetztes PDF mit demselben Layout zurückgeben. Das Modell hat kein Konzept von "Seitenumbruch, der mit der Quelle übereinstimmen muss" oder "Tabellenzelle, die ihre Spaltenbreite behalten muss".

Für diese Oberfläche nutzen wir die DeepL Document API direkt. Sie ist speziell für die Übersetzung von Dateien als Dateien gebaut, nicht für aus Dateien extrahierten Text. DeepL handhabt:

• PDF (mit Layouterhaltung)
• DOCX, DOC
• PPTX
• XLSX

Das Dokument wird in die DeepL-Pipeline hochgeladen, serverseitig mit intakter Formatierung übersetzt und im selben Format zurückgegeben. Wir laden das Ergebnis dann in unseren Object Storage hoch und stellen es im Chat als herunterladbaren Anhang wieder zur Verfügung.

Was das kostet und warum wir es nicht verbergen

DeepL berechnet ein Minimum von 50.000 Zeichen pro Dokument – etwa einen US-Dollar pro Datei im Pro-Tarif, unabhängig davon, ob das Dokument eine oder dreißig Seiten umfasst. Wir absorbieren diese Kosten, anstatt pro Datei zu berechnen; sie tauchen in der Übersetzungsnutzung des Meetings als berechnete Zeichen (billed characters) auf, umgewandelt in Wort-Einheiten, die der Art und Weise entsprechen, wie der Rest des Produkts Übersetzungsaktivitäten meldet.

Wir haben DeepL für diese Oberfläche gewählt, weil die Übersetzung von Dateien als Dateien genau die Aufgabe ist, für die es gebaut wurde – wir haben nicht versucht, eine bessere zu bauen. Dasselbe gilt nicht umgekehrt – DeepL betreibt keine Live-Sprach-Pipeline von der Art, wie wir sie für Meetings gebaut haben. Unterschiedliche Probleme; unterschiedliche Werkzeuge. Die ehrliche Version dessen, "was die InterMIND-Übersetzung antreibt", ist "die richtige Engine pro Pipeline" – nicht "unsere Engine, überall".

Sprachen, die diese Pipeline abdeckt, die Sprache jedoch nicht

Die Dokumenten-Pipeline erreicht 30 Sprachen, gegenüber 24 für die Sprache. Die Extras umfassen: Bulgarisch, Griechisch, Estnisch, Indonesisch, Litauisch, Lettisch, Slowakisch, Slowenisch. (Arabisch stand früher in dieser Liste, als die Sprachqualität noch unter unserem Standard war; es ist jetzt im Echtzeit-Wähler enthalten, mit seinen Paar-Scores öffentlich auf /benchmark wie jede andere Sprache. Die Asymmetrie läuft jetzt für Hindi umgekehrt – live bei der Sprache, aber noch nicht bei Dateien.)

Diese Asymmetrie ist real. Das bedeutet, dass ein französischer Teilnehmer in einem Meeting das Vertrags-PDF auf Estnisch anfordern kann, obwohl er das Meeting nicht auf Estnisch anhören kann. Wir kennzeichnen dies im Wähler, anstatt es mit einer einzigen Zahl zu glätten. Die Begründung steht im Beitrag zur Sprachanzahl.

Wo sich die Pipelines berühren

Die vier Pipelines laufen nicht isoliert. Ein Meeting-Raum ist der Ort, an dem sie sich berühren, und die Nähte sind wichtig:

• Eine Chat-Nachricht mit einem Dokumentanhang löst die Chat-Pipeline für den Text und die Dokumenten-Pipeline für die Datei aus. Der Teilnehmer in einer anderen Sprache sieht die Nachricht sofort übersetzt und die Übersetzung des Anhangs, die asynchron als Download eintrifft.
• Eine geteilte Notiz, die eine Transkriptzeile zitiert, kreuzt Notizen ↔ Sprache. Das Transkript ist das, was die Sprach-Pipeline für die Sprache des Absenders produziert hat; die Notizübersetzung erzeugt eine Per-Zuschauer-Kopie dieses Zitats in der Sprache aller anderen, wobei die Quellzuschreibung erhalten bleibt.
• Ein nach dem Meeting exportiertes Transkript läuft über die Chat-ähnliche Text-Pipeline über die gesamte Konversation und erzeugt eine Datei pro Sprache, die die Teilnehmer herunterladen können. Dies ist derselbe Code-Pfad wie die Chat-Übersetzung, nur gestückelt (batched).

Der Sprachwähler ist ein Stück UI. Die Infrastruktur darunter sind vier Pipelines, die miteinander kommunizieren.

Was wir bewusst nicht versuchen

• Kein "vereinheitlichtes Übersetzungsmodell". Wir bauen nicht ein Modell, das Sprache, Chat, Notizen und Dokumente übernimmt. Der Trade-off zwischen Latenz und Wiedergabetreue hat keinen Gewinner. Wir nutzen die richtige Engine pro Oberfläche.
• Kein lautloses Umleiten. Wenn die Datei-Pipeline heute nicht auf Hindi übersetzen kann, fallen wir nicht lautlos auf die Sprach-Engine zurück und tun so, als ob es funktioniert hat – der Dateiwähler kennzeichnet die Lücke, anstatt sie zu verbergen.
• Kein "wir übersetzen in 200 Sprachen". Unsere Engine gibt 24 aus. Die Live-Oberflächen liefern alle 24, Dokumente 30 – und anstatt einer marketingfreundlichen Zahl wird die Paar-Qualität, die einem Auditor standhalten muss, auf /benchmark veröffentlicht, schwächere Paare inbegriffen.

Testen Sie es selbst

• Live-Demo ausprobieren – führt die Live-Sprach-Pipeline mit Ihrem Audio aus, in jeder der 24 Produktsprachen. Dieselbe Pipeline, die bei /benchmark punktet.
• Benchmark ansehen – Paar- und Monatsqualität auf echtem Traffic. Jedes Paar im Wähler, stark oder schwach, tief verlinkbar.
• Methodik lesen – was die Zahlen sind, was sie nicht sind, wer der Prüfer ist.

Vier Pipelines, vier Engines, ein Meeting-Raum. Das ist der ehrliche Ersatz für die alte how-it-works-Seite.

— Das Mind.com-Team

Quellen: DeepL — supported languages, DeepL — usage count and billing (das Minimum von 50.000 Zeichen pro Datei), FLORES-200; interne Pipeline-Fakten gegen den ausgelieferten Code verifiziert, geprüft im August 2026.