Ein Blick in die vier Übersetzungs-Pipelines, die InterMIND betreiben

Die alte Seite /product/overview/how-it-works auf mind.com ist mehrere Hauptreleases veraltet. Sie beschreibt eine einzige „Übersetzungs-Engine" so, wie es die meisten Anbieterseiten tun — ein großer Pfeil von „Sie sprechen" zu „die anderen hören". Dieses Bild war schon vor zwei Jahren eine Vereinfachung. Heute ist es schlicht 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ätshülle löst. Sie teilen sich eine Sprachauswahl. Sie teilen sich keine Engine.

Das ist die aktualisierte Antwort auf „Wie funktioniert das?".

Ein Begleitstück: „Wie viele Sprachen unterstützen Sie?" behandelt, was jede Pipeline abdeckt (24 / 22 / 30 / 12). Dieser Beitrag behandelt, was jede Pipeline tut — und warum sie ein eigenständiges Ding ist.

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

Eine Plattform für Live-Meetings hat mindestens vier Aufgaben gleichzeitig zu erledigen, und diese ziehen in inkompatible Richtungen:

1. Sprache in Echtzeit — Audio rein, übersetztes Audio raus, unter einer Sekunde, jeder Zuhörer in seiner eigenen Sprache. Die harte Randbedingung ist die Latenz.
2. Chat-Text in Echtzeit — kurze Nachrichten, schnell, mit Bearbeitungen, Zitaten und HTML-Struktur, die erhalten bleiben muss.
3. Geteilte Notizen in Echtzeit — kollaboratives Tippen Zeichen für Zeichen, mit struktureller Hierarchie (Listen, Überschriften, Checkboxen), die die Übersetzung überleben muss.
4. Asynchrone Dokumentdateien — ein 40-seitiges PDF, das in den Chat geworfen wird. Kein Latenzbudget. Die harte Randbedingung ist die Wiedergabetreue — Formatierung, Tabellen, Seitenzahlen, Schriftarten.

Sie können einen riesigen LLM-Aufruf bauen, der versucht, alle vier zu erledigen. Wir haben es versucht. Er ist schlecht in allen vieren. Das Latenzbudget für Sprache bedeutet, dass das Modell nicht nachdenken kann; das Wiedergabetreue-Budget für Dokumente bedeutet, dass das Modell es muss. Eine Chat-Bearbeitung braucht ein Diff in der Sprache des Betrachters; ein 40-seitiges PDF braucht eine Formaterhaltung, die kein Token-Streaming-Modell liefert.

Also betreiben wir vier. Hier ist jede einzelne.

Pipeline 1: Sprachübersetzung in Echtzeit

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

Das Budget: Sub-Sekunde Ende-zu-Ende. Alles jenseits von ~1,2 Sekunden, und das Gespräch bricht ab — die Leute beginnen, durch die Übersetzung zu reden, und das Meeting driftet in Richtung „lass uns einfach auf Englisch wechseln".

Wie sich das Audio tatsächlich bewegt

Ein paar Dinge sind ausdrücklich zu benennen:

• ASR läuft im Browser des Sprechers, nicht auf einem zentralen Server. Wir nutzen das Mind SDK lokal; das spart einen Roundtrip und gibt uns das Transkript in der Ausgangssprache mit der geringstmöglichen Verzögerung, bevor die Übersetzung überhaupt starten kann.
• Übersetzung ist nicht ein einziger 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, teilen sie sich eine Verbindung. Wenn niemand Arabisch gewählt hat, wird keine Arabisch-Verbindung geöffnet. Der Pool schließt nach fünf Minuten Leerlauf inaktive Verbindungen. Deshalb kostet ein Meeting mit vier Sprachen genauso viel wie eines mit vierzig Sprachen — bis zu dem Punkt, wer tatsächlich erschienen ist — wir übersetzen nie in Sprachen, in denen kein Teilnehmer zuhört.
• Synthetisierte Sprache ist pro Zuhörer. Jeder Teilnehmer empfängt seine eigene übersetzte Audiospur, gemischt mit dem ursprünglichen Sprechervideo. Sie sehen nicht ein Master-„übersetztes Meeting" — sie sehen dasselbe Meeting, mit ihrem persönlichen Audiokanal, der in die von ihnen gewählte Sprache übersetzt wird. Deshalb können zwei Personen im selben Raum jeweils Kopfhörer einstecken und unterschiedliche Sprachen hören.

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

In einem 60-minütigen Anruf mit acht Sprachen brechen Dinge auf interessante Weise: WebSockets fallen aus, ASR transkribiert vorübergehend einen Eigennamen falsch, das Netzwerk eines Teilnehmers wird unruhig. Die obige Architektur ist das, was uns erlaubt, Fehler zu isolieren: Das Ruckeln im Audio eines Zuhörers betrifft die anderen sieben nicht, weil die Übersetzungs-Engine gar nicht erst „die Übersetzung" produziert hat — sie hat acht parallel produziert, und nur die betroffene muss sich erholen.

Die Engine selbst gehört uns und wird auf unserer eigenen Infrastruktur betrieben. Wir leiten Sprache in Echtzeit nicht über generelle LLMs von Drittanbietern. Das Latenzbudget schließt sie aus; die Datenresidenz schließt sie für die regulierten Kunden aus, denen es tatsächlich wichtig ist.

Was wir zur Sprachqualität veröffentlichen: /benchmark lässt die Produktiv-Sprach-Pipeline monatlich gegen FLORES-200-Sätze für jedes veröffentlichte Sprachpaar laufen. Der Judge wird namentlich genannt (Gemini 2.5 Flash primär, Claude Sonnet 4 als Fallback). Die vollständige Verteilung — Median, p10, p90, Min, Max, Stichprobengröße — steht auf der Seite. Siehe die Methodik dazu, was diese Zahlen messen und was nicht.

Pipeline 2: Chat-Übersetzung in Echtzeit

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

Das Budget: Schnell, aber nicht im Sub-Sekunden-Bereich. Eine Chat-Nachricht darf eine halbe Sekunde brauchen, um in einer anderen Sprache zu erscheinen, ohne dass es jemanden stört. Was die Leute interessiert, ist, ob die Übersetzung richtig ist und ob Bearbeitungen Sinn ergeben.

Was die Chat-Pipeline tatsächlich macht

Jede Nachricht durchläuft dieselbe Übersetzungs-Engine, die auch die Sprach-Pipeline verwendet — aber mit anderem Pre- und Post-Processing:

• HTML-Struktur bleibt erhalten. Chat unterstützt Rich Text (Absätze, Listen, Zitate, Fett, Kursiv). Wir konvertieren für das Modell in Plain Text, übersetzen und packen das Ergebnis dann wieder in die ursprünglichen Tags. Das Modell sieht das HTML nie — es sieht sauberen Fließtext.
• Zitate werden unabhängig übersetzt. Wenn Sie auf eine Nachricht antworten und sie zitieren, werden der [QUOTE]…[/QUOTE]-Block und der neue Inhalt als getrennte Einheiten übersetzt, damit das Modell die beiden nicht verwechseln kann.
• Lange Nachrichten werden gestückelt. Wir teilen an Absatzgrenzen bei 1.000 Zeichen pro Chunk. Jeder Chunk ist ein eigener Übersetzungsaufruf. Wir füttern dem Modell nicht in einem Rutsch 4.000-Zeichen-Romane — die Fehlermodi (Abschneiden, verlorene Absätze, abgeschnittene Sätze) sind zu hässlich.
• Übersetzung ist lazy. Wir verwenden einen IntersectionObserver: Eine Nachricht wird erst dann übersetzt, wenn sie in den Viewport des Betrachters scrollt. Das Wechseln der Sprache in einem länger laufenden Channel hat früher jeden Übersetzungs-API-Aufruf aus der Historie erneut abgespielt. Jetzt nicht mehr.

Der interessante Teil: Bearbeitungen als Diffs

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

Das neue Verhalten:

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

So sieht Ihr Spanisch lesender Kollege, wenn aus „review by Tuesday" im Englischen „review by Thursday" wird, martes → jueves hervorgehoben, nicht einen neu übersetzten Absatz, den er erneut lesen muss.

Das erforderte, die Chat-Pipeline als stateful Pro-Betrachter-Cache zu behandeln, nicht als zustandslosen Translate-on-Request-Endpoint. Dokumente und Sprache brauchen das nicht. Chat schon.

Pipeline 3: Übersetzung geteilter Notizen in Echtzeit

Das Problem: Der Host öffnet ein Panel für geteilte Notizen und beginnt zu tippen. Jeder Teilnehmer sieht die Notizen in seiner Sprache, Zeichen für Zeichen, mit der Struktur des Dokuments — Überschriften, verschachtelten Listen, Checklisten, Codeblöcken — intakt.

Das Budget: Wie bei Chat (~halbe Sekunde), aber mit zwei zusätzlichen Randbedingungen:

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

Wie sich die Notizen-Pipeline von Chat unterscheidet

Die Strukturerhaltung ist die Hauptsache. Wir übersetzen jeden Listenpunkt unabhängig, statt als ein Dokument. Das Modell sieht:

„Compliance-Review — Q2-Deliverables"

— nicht:

„# Projektplan\n## Quartal\n- Compliance-Review — Q2-Deliverables\n- Vendor-Scoring\n - Tier-1-Vendoren..."

Das umhüllende Dokument — das <ul>, die Überschriften, die Einrückung — wird auf der Client-Seite mit derselben Struktur, die das Originaldokument hatte, neu aufgebaut, wobei jeder Blattknoten gegen seine Übersetzung getauscht wird. Das Modell bekommt nie die Gelegenheit, die Hierarchie zu „verbessern".

Notizen verwenden auch das gleiche 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 frischen Absatz.

Pipeline 4: Asynchrone Dokumentübersetzung

Das Problem: Jemand wirft 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 Ort und Stelle.

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

Warum diese Pipeline keine Engine mit Sprache teilt

Ein generelles LLM, auch 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 verwenden wir die DeepL Document API direkt. Sie ist eigens dafür gebaut, Dateien als Dateien zu übersetzen, nicht aus Dateien extrahierten Fließtext. DeepL verarbeitet:

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

Das Dokument wird in die Pipeline von DeepL hochgeladen, serverseitig mit erhaltener Formatierung übersetzt und im gleichen Format zurückgegeben. Wir laden das Ergebnis dann in unseren Object Storage hoch und stellen es im Chat als herunterladbaren Anhang bereit.

Was das kostet und warum wir es nicht verstecken

DeepL berechnet mindestens 50.000 Zeichen pro Dokument — etwa einen US-Dollar pro Datei im Pro-Tarif, unabhängig davon, ob das Dokument eine Seite oder dreißig Seiten umfasst. Wir tragen diese Kosten, statt pro Datei abzurechnen; sie erscheinen in der Übersetzungsnutzung des Meetings als berechnete Zeichen, umgerechnet in Worteinheiten, die zur Art passen, wie der Rest des Produkts Übersetzungsaktivität berichtet.

Wir haben DeepL für diese Oberfläche gewählt, weil es die Best-in-Class-Engine speziell für Dokumentübersetzung ist. Wir behaupten nicht, eine bessere gebaut zu haben. Umgekehrt gilt das nicht — DeepL betreibt keine Live-Sprach-Pipeline der Art, die wir für Meetings gebaut haben. Unterschiedliche Probleme; unterschiedliche Werkzeuge. Die ehrliche Version von „was die InterMIND-Übersetzung antreibt" lautet „die richtige Engine pro Pipeline" — nicht „unsere Engine, überall".

Sprachen, die diese Pipeline abdeckt, die Sprache nicht abdeckt

Die Dokument-Pipeline erreicht 30 Sprachen, gegenüber 22 für Sprache. Zu den Extras gehören: Bulgarisch, Griechisch, Estnisch, Indonesisch, Litauisch, Lettisch, Norwegisch Bokmål, Slowakisch, Slowenisch — plus Arabisch, das wir in der Echtzeit-Auswahl verbergen, weil die Sprachqualität unsere Latte nicht überschreitet, das DeepL aber gut als Dokumente verarbeitet.

Diese Asymmetrie ist real. Sie bedeutet, dass ein französischer Teilnehmer in einem Meeting den Vertrags-PDF in Estnisch anfordern kann, obwohl er dem Meeting nicht in Estnisch zuhören kann. Wir kennzeichnen das in der Auswahl, anstatt es mit einer einzigen Zahl zu glätten. Die Begründung steht im Sprachzahl-Beitrag.

Wo sich die Pipelines begegnen

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

• Eine Chat-Nachricht mit einem Dokument-Anhang löst die Chat-Pipeline für den Text und die Dokument-Pipeline für die Datei aus. Der Teilnehmer in einer anderen Sprache sieht die Nachricht sofort übersetzt und die Anhangsübersetzung trifft asynchron als Download ein.
• Eine geteilte Notiz, die eine Transkriptzeile zitiert, überquert Notizen ↔ Sprache. Das Transkript ist das, was die Sprach-Pipeline für die Sprache des Absenders produziert hat; die Notizübersetzung erzeugt eine Pro-Betrachter-Kopie dieses Zitats in der Sprache aller anderen, mit erhaltener Quellenangabe.
• Ein nach dem Meeting exportiertes Transkript lässt die chat-artige Text-Pipeline über das gesamte Gespräch laufen und erzeugt eine Datei pro Sprache, die Teilnehmer herunterladen können. Das ist derselbe Codepfad wie die Chat-Übersetzung, nur als Batch.

Die Sprachauswahl ist ein einziges UI-Element. Die Infrastruktur darunter sind vier Pipelines, die miteinander sprechen.

Was wir bewusst nicht versuchen

• Kein „einheitliches Übersetzungsmodell". Wir bauen kein einzelnes Modell, das Sprache, Chat, Notizen und Dokumente macht. Der Trade-off zwischen Latenz und Wiedergabetreue hat keinen Gewinner. Wir verwenden die richtige Engine pro Oberfläche.
• Kein stilles Umleiten. Wenn Sprache heute nicht ins Hindi übersetzen kann, fallen wir nicht stillschweigend auf die Dokument-Engine zurück und tun so, als hätte es funktioniert. Hindi wird auf beiden Oberflächen aus der Auswahl ausgeblendet, weil das Ergebnis heute auf beiden Oberflächen nicht ausliefbar ist.
• Kein „wir übersetzen in 200 Sprachen". Unsere Engine liefert 24. Unser Produkt liefert 22 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 vor einem Auditor die Latte schafft.

Probieren Sie es selbst aus

• /demo — lässt die Live-Sprach-Pipeline gegen Ihr Audio in allen 22 Produktsprachen laufen. Dieselbe Pipeline, die /benchmark bewertet.
• /benchmark — Qualität pro Paar, pro Monat auf echtem Traffic. Beinhaltet die Paare, die wir bewusst aus der Auswahl ausblenden, deep-linkbar.
• /benchmark/methodology — was die Zahlen sind, was sie nicht sind, wer der Judge ist.

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

— The Mind.com Team