Innerhalb der vier Übersetzungspipelines, die InterMIND antreiben

Die alte /product/overview/how-it-works-Seite auf mind.com ist mehrere Hauptversionen alt. Sie beschreibt eine einzelne "Ü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 einer anderen Qualitätsgrenze löst. Sie teilen sich einen Sprachwähler. Sie teilen sich nicht eine Engine.

Dies ist die aktualisierte Antwort auf "wie funktioniert das".

Ein Begleitartikel: "Wie viele Sprachen unterstützen Sie?" behandelt, was jede Pipeline abdeckt (23 / 23 / 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 hat mindestens vier Aufgaben gleichzeitig zu erledigen, die in unvereinbare Richtungen weisen:

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 erhaltenen Bearbeitungen, Zitaten und HTML-Struktur.
3. Echtzeit-geteilte Notizen – zeichenweises gemeinsames Tippen, mit einer strukturellen Hierarchie (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 Treue – Formatierung, Tabellen, Seitenzahlen, Schriftart.

Man kann einen riesigen LLM-Aufruf bauen, der versucht, alle vier zu erledigen. Wir haben es versucht. Er ist in allen vier schlecht. Das Latenzbudget für Sprache bedeutet, dass das Modell nicht nachdenken kann; das Treue-Budget für Dokumente bedeutet, dass das Modell nachdenken muss. Eine Chat-Bearbeitung benötigt einen Diff in der Sprache des Zuschauers; ein 40-seitiges PDF benötigt 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, in seinem eigenen Ohr hören, mit einer Verzögerung, die kurz genug ist, um den Augenkontakt aufrechtzuerhalten.

Das Budget: Weniger als eine Sekunde Ende-zu-Ende. Alles über ~1,2 Sekunden und die Konversation bricht ab – Menschen beginnen, über die Übersetzung hinwegzusprechen, und das Meeting treibt in Richtung "lass uns einfach auf Englisch wechseln".

Wie das Audio tatsächlich fließt

Einige Dinge, die es wert sind, explizit genannt zu werden:

• ASR läuft auf dem Medienserver. Das Audio des Sprechers reist über WebRTC zu unserer eigenen Engine – der Mind API bei OVH, Frankreich – und wird dort erkannt, auf demselben Server, der den Anruf trägt; der Browser sendet nur Audio und empfängt die Wörter zurück. Kein separater Sprachanbieter und kein extra Hop, bevor die Übersetzung beginnen kann. (Chat-Sprachnotizen sind die Ausnahme: Ihr Speech-to-Text läuft auf Azure AI Speech, dem Sprachdienst des Standard-AI-Gateways.)
• Die Übersetzung ist kein einfacher Fan-out. Die Engine übersetzt pro im Raum vorhandener Zielsprache, nicht pro Zuschauer: Die Übersetzung in eine Sprache beginnt, wenn der erste Zuhörer darin einen übersetzten Stream anfordert, drei Teilnehmer, die Deutsch gewählt haben, teilen sich eine deutsche Übersetzung, und wenn niemand Arabisch hört, wird nichts ins Arabische übersetzt. Deshalb kostet ein Meeting mit vier Sprachen dasselbe 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 erfolgt pro Zuschauer. Jeder Teilnehmer empfängt 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, der in ihre gewählte Sprache übersetzt wurde. 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 brechen Dinge auf interessante Weise: WebSockets fallen aus, ASR transkribiert vorübergehend einen Eigennamen falsch, das Netzwerk eines Teilnehmers wird jitterig. Die obige Architektur ermöglicht es uns, Fehler zu isolieren: Wenn das Audio eines Zuschauers glitcht, betrifft dies nicht die anderen sieben, weil die Übersetzungs-Engine überhaupt nicht "die Übersetzung" produziert hat – 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 Echtzeit-Sprache nicht über Allzweck-LLMs von Drittanbietern. Das Latenzbudget schließt sie aus; die Datenresidenz-Story schließt sie für regulierte Kunden aus, denen es wirklich darauf ankommt.

Was wir zur Sprachqualität veröffentlichen: /benchmark führt die Produktions-Sprach-Pipeline jeden Monat gegen FLORES-200-Sätze für jedes veröffentlichte Sprachpaar aus. Der Prüfer wird benannt (Gemini 3.7 Flash primär, Claude Sonnet 5 Fallback). Die vollständige Verteilung – Median, p10, p90, Min, Max, Stichprobengröße – steht 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, ü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 zu erscheinen, ohne dass es jemanden interessiert. Worum es den Menschen geht, 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 – aber mit unterschiedlichen Vor- und Nachverarbeitungen:

• Die HTML-Struktur bleibt erhalten. Chat unterstützt Rich Text (Absätze, Listen, Zitate, Fett, Kursiv). Wir konvertieren in Klartext für das Modell, übersetzen und wickeln das Ergebnis dann wieder in die ursprünglichen Tags ein. Das Modell sieht nie das HTML – es sieht saubere Prosa.
• 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 Chunks aufgeteilt. Wir teilen an Absatzgrenzen bei 1.000 Zeichen pro Chunk. Jeder Chunk ist sein eigener Übersetzungsaufruf. Wir füttern das Modell nicht mit 4.000-Zeichen-Romanen in einem einzigen Wurf – die Fehlermodi (Abschneiden, verlorene Absätze, Abbrüche mitten im Satz) sind zu hässlich.
• Die Übersetzung ist faul. Wir verwenden einen IntersectionObserver: Eine Nachricht wird nur übersetzt, wenn sie in den Viewport des Zuschauers scrollt. Der Sprachwechsel in einem lange laufenden Kanal spielte früher jeden Übersetzungs-API-Aufruf aus der Historie neu ab. 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 frischen Absatz und müssen herausfinden, was sich bewegt 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 den Diff zwischen Ihrer vorherigen Übersetzung und Ihrer neuen Übersetzung, in Ihrer Sprache.
4. Wir zeigen diesen Diff inline – genauso wie Git Ihnen zeigt, was sich geändert hat.

Wenn also "review by Tuesday" auf Englisch zu "review by Thursday" wird, sieht Ihr spanisch lesender Kollege martes → jueves hervorgehoben, keinen neu übersetzten Absatz, den er neu lesen muss.

Dies erforderte es, die Chat-Pipeline als zustandsbehafteten Cache pro Zuschauer zu behandeln, nicht als zustandslosen Translate-on-Request-Endpunkt. Dokumente und Sprache brauchen das nicht. Chat 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 in seiner Sprache, Zeichen für Zeichen, mit der Struktur des Dokuments – Überschriften, verschachtelte Listen, Checklisten, Codeblöcke – intakt.

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 ganze Dokument" bei jedem Tastenanschlag übersetzt, erzeugt Flackern und verbrennt das API-Budget. Wir übersetzen mit der Granularität der geänderten Einheit, nicht des ganzen Dokuments.
• Die Struktur muss überleben. Wenn Sie ein Übersetzungsmodell bitten, einen Markdown-Blob mit drei verschachtelten Listen zu übersetzen, erhalten Sie 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-Überprüfung — Q2-Liefergegenstände"

– nicht:

"# Projektplan\n## Quartal\n- Compliance-Überprüfung — Q2-Liefergegenstände\n- Anbieterbewertung\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 Blattknoten durch seine Übersetzung ersetzt wird. Das Modell bekommt nie die Möglichkeit, die Hierarchie zu "verbessern".

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

Pipeline 4: Asynchrone Dokumentenü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 am Platz.

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

Warum sich diese Pipeline 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 extrahierte Prosa. DeepL unterstützt:

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

Das Dokument wird in die Pipeline von DeepL hochgeladen, serverseitig mit intakter Formatierung übersetzt und im selben Format zurückgegeben. Wir laden das Ergebnis dann in unseren Objektspeicher 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 taucht in der Übersetzungsnutzung des Meetings als abgerechnete Zeichen auf, umgerechnet 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. Andersherum stimmt das nicht – DeepL betreibt keine Live-Sprach-Pipeline von der Art, wie wir sie 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 aber nicht

Die Dokumenten-Pipeline erreicht 30 Sprachen, gegenüber 23 für Sprache. Die Extras umfassen: Bulgarisch, Griechisch, Estnisch, Indonesisch, Litauisch, Lettisch, Slowakisch, Slowenisch. (Arabisch steht ebenfalls auf dieser Liste und ist eines der Extras: Es ist aus dem Echtzeit-Wähler zurückgezogen, solange seine Sprachqualität unter unserem Maßstab liegt, und seine Punktzahlen pro Paar bleiben öffentlich auf /benchmark – diese Zahl ist es, die es zurückbringt. Die Asymmetrie läuft für Hindi umgekehrt – live auf Sprache, noch nicht auf Dateien.)

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

Wo sich die Pipelines treffen

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 Anhangs-Übersetzung, 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 Kopie dieses Zitats pro Zuschauer in der Sprache aller anderen, wobei die Quellenangabe erhalten bleibt.
• Ein nach dem Meeting exportiertes Transkript führt die Chat-ähnliche Text-Pipeline über die gesamte Konversation aus und erzeugt eine Datei pro Sprache, die die Teilnehmer herunterladen können. Dies ist derselbe Codepfad wie bei der Chat-Übersetzung, nur gebatcht.

Der Sprachwähler ist ein Stück UI. Die Infrastruktur darunter besteht aus vier Pipelines, die miteinander sprechen.

Was wir bewusst nicht versuchen

• Kein "vereinheitlichtes Übersetzungsmodell". Wir bauen kein Modell, das Sprache, Chat, Notizen und Dokumente beherrscht. Der Latenz-gegen-Treue-Kompromiss hat keinen Gewinner. Wir nutzen die richtige Engine pro Oberfläche.
• Kein stilles Umleiten. Wenn die Datei-Pipeline heute nicht nach Hindi übersetzen kann, fallen wir nicht leise auf die Sprach-Engine zurück und tun so, als hätte es funktioniert – der Datei-Wä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 23, Dokumente 30 – und anstatt einer marketingfreundlichen Zahl wird die Qualität pro Paar, die vor einem Auditor stehen muss, auf /benchmark veröffentlicht, einschließlich der schwächeren Paare.

Probieren Sie es selbst aus

• Live-Demo ausprobieren – führt die Live-Sprach-Pipeline gegen Ihr Audio aus, in jeder der 23 Produktsprachen. Dieselbe Pipeline, die bei /benchmark punktet.
• Den Benchmark ansehen – Qualität pro Paar, pro Monat auf echtem Traffic. Jedes Paar im Wähler, stark oder schwach, tief verlinkbar.
• Die 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 — unterstützte Sprachen, DeepL — Nutzungszähler und Abrechnung (das Minimum von 50.000 Zeichen pro Datei), FLORES-200; interne Pipeline-Fakten gegen den ausgelieferten Code verifiziert, geprüft im August 2026.