Einblicke in die vier Übersetzungspipelines, die InterMIND antreiben

Die alte Seite /product/overview/how-it-works auf mind.com ist mehrere Hauptversionen veraltet. Sie beschreibt eine einzige „Übersetzungs-Engine“, wie es die meisten Anbieterseiten tun – ein großer Pfeil von „Sie sprechen“ zu „Sie hören“. Dieses Bild war schon vor zwei Jahren eine Vereinfachung. Heute ist es falsch.

Die Wahrheit ist, dass InterMIND vier separate Übersetzungspipelines betreibt, von denen jede ein anderes Problem mit einer anderen Engine, einem anderen Latenzbudget und einem anderen Qualitätsrahmen löst. Sie teilen sich eine Sprachauswahl. Sie teilen sich keine Engine.

Dies ist die aktualisierte Antwort auf „Wie funktioniert es?“.

Ein begleitender Artikel: "Wie viele Sprachen unterstützen Sie?" behandelt, was jede Pipeline abdeckt (24 / 21 / 30 / 6). Dieser Beitrag behandelt, was jede Pipeline tut – und warum sie etwas Eigenes ist.

Warum „eine Engine für alles“ eine Lüge ist

Eine Live-Meeting-Plattform muss mindestens vier Aufgaben gleichzeitig erledigen, und diese ziehen in inkompatible Richtungen:

1. Echtzeit-Sprache — Audio rein, übersetztes Audio raus, unter einer Sekunde, jeder Zuschauer in seiner eigenen Sprache. Die strikte Einschränkung ist die Latenz.
2. Echtzeit-Chattext — kurze Nachrichten, schnell, mit Bearbeitungen und Zitaten sowie erhaltener HTML-Struktur.
3. Echtzeit-Freigabe von Notizen — kollaboratives Tippen Zeichen für Zeichen, mit struktureller Hierarchie (Listen, Überschriften, Checkboxen), die die Übersetzung überstehen muss.
4. Asynchrone Dokumentdateien — eine 40-seitige PDF-Datei, die in den Chat hochgeladen wird. Kein Latenzbudget. Die strikte Einschränkung ist die Fidelität — Formatierung, Tabellen, Seitenzahlen, Schriftart.

Man könnte einen einzigen riesigen LLM-Aufruf erstellen, der versucht, alle vier zu erledigen. Wir haben es versucht. Er ist in allen vier Bereichen schlecht. Das Latenzbudget für Sprache bedeutet, dass das Modell nicht denken kann; das Fidelitätsbudget für Dokumente bedeutet, dass das Modell es muss. Eine Chat-Bearbeitung benötigt einen Diff in der Sprache des Betrachters; eine 40-seitige PDF-Datei benötigt eine Formaterhaltung, die 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 hat sich auf Deutsch angeschlossen, ein dritter auf Brasilianischem Portugiesisch, ein vierter auf Japanisch. Jeder von ihnen muss den Sprecher in seiner eigenen Sprache, in seinem eigenen Ohr, mit einer ausreichend kurzen Verzögerung hören, um Augenkontakt zu ermöglichen.

Das Budget: End-to-End unter einer Sekunde. Alles über ~1,2 Sekunden hinaus lässt das Gespräch abbrechen – die Leute beginnen, über die Übersetzung hinweg zu sprechen, und das Meeting tendiert zu „lasst uns einfach zu Englisch wechseln“.

Wie das Audio tatsächlich übertragen wird

Ein paar Dinge, die explizit genannt werden sollten:

• ASR läuft im Browser des Sprechers, nicht auf einem zentralen Server. Wir verwenden das Mind SDK lokal; dies spart einen Round-Trip und liefert uns das Transkript in der Ausgangssprache mit der geringstmöglichen Verzögerung, bevor die Übersetzung überhaupt beginnen kann.
• Die Übersetzung erfolgt nicht über eine einzige Verteilung. 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 arabische Verbindung geöffnet. Der Pool trennt inaktive Verbindungen nach fünf Minuten. Deshalb kostet ein Meeting mit vier Sprachen genauso viel wie ein Meeting mit vierzig Sprachen, bis zu dem Punkt, wer tatsächlich teilgenommen hat – wir übersetzen niemals in Sprachen, die kein Teilnehmer hört.
• Synthetisierte Sprache ist pro Zuschauer. Jeder Teilnehmer erhält seine eigene übersetzte Audiospur, gemischt mit dem Video des Originalssprechers. Sie sehen kein „übersetztes Master-Meeting“ – sie sehen das gleiche Meeting, wobei ihr persönlicher Audiokanal in die von ihnen gewählte Sprache übersetzt wird. Deshalb können zwei Personen im selben physischen Raum jeweils Kopfhörer anschließen und verschiedene Sprachen hören.

Warum dies wichtig ist, wenn ein Meeting schiefläuft

In einem 40-minütigen Anruf mit acht Sprachen können interessante Dinge schiefgehen: WebSockets fallen aus, ASR transkribiert einen Eigennamen vorübergehend falsch, das Netzwerk eines Teilnehmers wird instabil. Die oben genannte Architektur ermöglicht es uns, Fehler zu isolieren: Die Audioaussetzer eines Zuschauers beeinträchtigen die anderen sieben nicht, da die Übersetzungs-Engine niemals „die Übersetzung“ im ersten Anlauf produzierte – sie produzierte acht, parallel, und nur die betroffene muss sich erholen.

Die Engine selbst ist unsere, gehostet auf unserer eigenen Infrastruktur. Wir leiten Echtzeit-Sprache nicht über allgemeine LLMs von Drittanbietern. Das Latenzbudget schließt sie aus; die Anforderungen an die Datenresidenz schließen sie für regulierte Kunden aus, die dies tatsächlich interessiert.

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

Pipeline 2: Echtzeit-Chat-Übersetzung

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

Das Budget: Schnell, aber nicht unter einer Sekunde. Eine Chat-Nachricht kann eine halbe Sekunde brauchen, um in einer anderen Sprache angezeigt zu werden, ohne dass es jemanden stört. Was den Leuten wichtig ist, ist, ob die Übersetzung richtig ist und ob Bearbeitungen sinnvoll sind.

Was die Chat-Pipeline tatsächlich leistet

Jede Nachricht durchläuft dieselbe Übersetzungs-Engine, die auch die Sprachpipeline verwendet – jedoch mit unterschiedlicher Vor- und Nachbearbeitung:

• Die HTML-Struktur bleibt erhalten. Chat unterstützt Rich Text (Absätze, Listen, Zitate, fett, kursiv). Wir konvertieren den Text für das Modell in Reintext, übersetzen ihn und umschließen das Ergebnis dann wieder mit den ursprünglichen Tags. Das Modell sieht niemals 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 aufgeteilt. Wir teilen an Absatzgrenzen bei 1.000 Zeichen pro Block. Jeder Block ist ein eigener Übersetzungsaufruf. Wir füttern dem Modell nicht Romane mit 4.000 Zeichen auf einmal – die Fehlermodi (Kürzung, verlorene Absätze, Satzabbrüche mitten im Satz) sind zu unschön.
• Die Übersetzung ist „lazy“. Wir verwenden einen IntersectionObserver: Eine Nachricht wird nur übersetzt, wenn sie in den sichtbaren Bereich des Betrachters scrollt. Das Umschalten von Sprachen in einem langlebigen Kanal führte früher dazu, dass jeder Übersetzungs-API-Aufruf aus dem Verlauf erneut ausgeführt wurde. Jetzt ist das nicht mehr der Fall.

Der interessante Teil: Bearbeitungen als Diffs

In v1.2 haben wir geändert, wie Chat-Bearbeitungen für Zuschauer in einer anderen Sprache funktionieren. Das alte Verhalten war: Jemand bearbeitet eine Nachricht, wir übersetzen das Ganze neu, Sie sehen einen frischen Absatz und müssen erkennen, was sich geändert 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 – auf die gleiche Weise, wie Git Änderungen anzeigt.

Wenn also „review by Tuesday“ im Englischen zu „review by Thursday“ wird, sieht Ihr Spanisch lesender Kollege martes → jueves hervorgehoben, nicht einen neu übersetzten Absatz, den er erneut lesen muss.

Dies erforderte, die Chat-Pipeline als zustandsbehafteten Cache pro Betrachter zu behandeln, nicht als zustandslosen Translate-on-Request-Endpunkt. Dokumente und Sprache benötigen dies nicht. Chat hingegen schon.

Pipeline 3: Echtzeit-Übersetzung geteilter Notizen

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

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

• Das zu übersetzende Objekt ändert sich während der Übersetzung. Der Host tippt noch. Ein naives System, das „das ganze Dokument“ bei jedem Tastendruck übersetzt, erzeugt Flackern und verbraucht das API-Budget. Wir übersetzen auf der Granularität der geänderten Einheit, nicht des gesamten Dokuments.
• Die Struktur muss erhalten bleiben. Wenn Sie ein Übersetzungsmodell bitten, einen Markdown-Blob mit drei verschachtelten Listen zu übersetzen, erhalten Sie etwas zurück, das dem Original ähnlich sieht, aber mit subtil abgeflachter Hierarchie, neu nummerierten Elementen oder verschobener Einrückung. Wir lassen das Modell den gesamten Blob nicht sehen.

Wie sich die Notizen-Pipeline vom Chat unterscheidet

Die strukturelle Erhaltung ist das Wichtigste. Wir übersetzen jedes Listenelement unabhängig voneinander, anstatt es als ein Dokument zu behandeln. Das Modell sieht:

„Compliance-Prüfung – Q2-Lieferobjekte“

— nicht:

"# Projektplan\n## Quartal\n- Compliance-Prüfung – Q2-Lieferobjekte\n- Anbieterbewertung\n - Tier-1-Anbieter..."

Das umgebende Dokument – das <ul>, die Überschriften, die Einrückung – wird clientseitig unter Verwendung derselben Struktur neu aufgebaut, die das Originaldokument hatte, wobei jeder Blattknoten durch seine Übersetzung ersetzt wird. Das Modell bekommt niemals die Möglichkeit, die Hierarchie zu „verbessern“.

Notizen verwenden auch dasselbe pro-Betrachter-Diff-Modell wie Chat-Bearbeitungen: Wenn der Host eine Zeile ändert, sehen Betrachter in anderen Sprachen die geänderten Wörter hervorgehoben, nicht einen neuen Absatz.

Pipeline 4: Asynchrone Dokumentübersetzung

Das Problem: Jemand lädt eine 40-seitige PDF-Datei, ein Word-Dokument, eine PowerPoint-Präsentation oder eine Excel-Tabelle in den Chat hoch. 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 ihrem Platz.

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

Warum diese Pipeline keine Engine mit Sprache teilt

Ein allgemeines LLM, selbst ein sehr gutes, wird Ihnen einen übersetzten Text eines Dokuments zurückgeben. Es wird Ihnen keine übersetzte PDF-Datei mit dem gleichen Layout zurückgeben. Das Modell hat kein Konzept von „Seitenumbruch, der mit der Quelle übereinstimmen muss“ oder „Tabellenzelle, die ihre Spaltenbreite beibehalten muss“.

Für diesen Bereich verwenden wir direkt die DeepL Dokumenten-API. Sie wurde speziell für die Übersetzung von Dateien als Dateien entwickelt, nicht für aus Dateien extrahierte Prosa. DeepL unterstützt:

• PDF (mit Layout-Erhaltung)
• DOCX, DOC
• PPTX
• XLSX

Das Dokument wird in die DeepL-Pipeline hochgeladen, serverseitig mit intakter Formatierung übersetzt und im selben Format zurückgegeben. Anschließend laden wir das Ergebnis in unseren Objektspeicher hoch und stellen es im Chat als herunterladbaren Anhang bereit.

Was das kostet und warum wir es nicht verbergen

DeepL berechnet mindestens 50.000 Zeichen pro Dokument – ungefähr einen US-Dollar pro Datei im Pro-Tarif, unabhängig davon, ob das Dokument eine Seite oder dreißig Seiten lang ist. Wir übernehmen diese Kosten, anstatt pro Datei abzurechnen; dies erscheint in der Übersetzungsnutzung des Meetings als abgerechnete Zeichen, umgerechnet in Wort-Einheiten, die der Art und Weise entsprechen, wie der Rest des Produkts die Übersetzungsaktivität meldet.

Wir haben DeepL für diesen Bereich ausgewählt, weil es die beste Engine für die Dokumentenübersetzung ist. Wir geben nicht vor, eine bessere entwickelt zu haben. Umgekehrt ist das nicht der Fall – DeepL betreibt keine Live-Sprachpipeline, wie wir sie für Meetings entwickelt haben. Unterschiedliche Probleme; unterschiedliche Werkzeuge. Die ehrliche Version von „Was die InterMIND-Übersetzung antreibt“ ist „die richtige Engine pro Pipeline“ – nicht „unsere Engine, überall“.

Sprachen, die diese Pipeline abdeckt, die die Sprachpipeline nicht abdeckt

Die Dokumentenpipeline erreicht 30 Sprachen, gegenüber 21 für die Sprachpipeline. Die zusätzlichen neun umfassen: Bulgarisch, Griechisch, Estnisch, Indonesisch, Litauisch, Lettisch, Norwegisch Bokmål, Slowakisch, Slowenisch – plus Arabisch und Türkisch, die wir aus der Echtzeit-Auswahl ausblenden, weil die Sprachqualität unsere Anforderungen nicht erfüllt, DeepL sie aber gut als Dokumente verarbeitet.

Diese Asymmetrie ist real. Sie bedeutet, dass ein französischer Teilnehmer an einem Meeting das Vertrags-PDF auf Estnisch anfordern kann, obwohl er das Meeting nicht auf Estnisch anhören kann. Wir kennzeichnen dies in der Auswahl, anstatt es mit einer einzigen Zahl zu beschönigen. Die Begründung finden Sie im Beitrag zur Sprachenanzahl.

Wo sich die Pipelines treffen

Die vier Pipelines laufen nicht isoliert. Ein Meetingraum ist der Ort, an dem sie sich berühren, und die Schnittstellen 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 Anhangübersetzung asynchron als herunterladbare Datei eintreffen.
• Eine geteilte Notiz, die eine Transkriptzeile zitiert, verbindet Notizen ↔ Sprache. Das Transkript ist das, was die Sprachpipeline für die Sprache des Absenders erstellt hat; die Notizübersetzung erstellt eine Kopie dieses Zitats für jeden Zuschauer in dessen Sprache, wobei die Quellenangabe erhalten bleibt.
• Ein nach dem Meeting exportiertes Transkript führt die Chat-artige Textpipeline über die gesamte Konversation aus und erstellt eine sprachspezifische Datei, die die Teilnehmer herunterladen können. Dies ist derselbe Codepfad wie bei der Chat-Übersetzung, nur gebündelt.

Die Sprachauswahl ist ein einzelnes UI-Element. Die darunter liegende Infrastruktur besteht aus vier Pipelines, die miteinander kommunizieren.

Was wir bewusst nicht versuchen

• Kein „einheitliches Übersetzungsmodell“. Wir bauen kein einziges Modell, das Sprache, Chat, Notizen und Dokumente übersetzt. Der Kompromiss zwischen Latenz und Fidelität hat keinen Gewinner. Wir verwenden die richtige Engine pro Oberfläche.
• Kein stilles Re-Routing. Wenn die Sprachübersetzung heute kein Hindi unterstützen kann, greifen wir nicht stillschweigend auf die Dokumenten-Engine zurück und tun so, als hätte es funktioniert. Hindi ist in der Sprachauswahl auf beiden Oberflächen ausgeblendet, da das Ergebnis auf beiden Oberflächen heute nicht lieferbar ist.
• Kein „wir übersetzen in 200 Sprachen“. Unsere Engine gibt 24 aus. Unser Produkt liefert 21 auf den Live-Oberflächen und 30 auf Dokumenten. Die marketingfreundliche größere Zahl ist nur die Obergrenze der Engine. Die Produktzahl ist das, was tatsächlich den Anforderungen eines Prüfers entspricht.

Probieren Sie es selbst aus

• /demo — führt die Live-Sprachpipeline mit Ihrem Audio in jeder der 21 Produktsprachen aus. Dieselbe Pipeline, die /benchmark bewertet.
• /benchmark — qualität pro Paar, pro Monat im realen Traffic. Enthält die Paare, die wir bewusst aus der Auswahl ausblenden, direkt verlinkbar.
• /benchmark/methodology — was die Zahlen sind, was sie nicht sind, wer der Richter ist.

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

— Das Mind.com Team