Dentro de las cuatro canalizaciones de traducción que ejecutan InterMIND

La antigua página /product/overview/how-it-works en mind.com lleva varias versiones mayores desactualizada. Describe un único "motor de traducción" como lo hacen la mayoría de las páginas de proveedores — una gran flecha desde "usted habla" hasta "ellos oyen". Esa imagen ya era una simplificación hace dos años. Hoy es directamente errónea.

La realidad es que InterMIND ejecuta cuatro canalizaciones de traducción independientes, cada una resolviendo un problema diferente con un motor diferente, un presupuesto de latencia diferente y una envolvente de calidad diferente. Comparten un selector de idioma. No comparten motor.

Esta es la respuesta actualizada a "cómo funciona".

Una pieza complementaria: "¿Cuántos idiomas admiten?" cubre lo que cada canalización abarca (24 / 22 / 30 / 12). Esta publicación cubre lo que cada canalización hace — y por qué cada una es una cosa distinta.

Por qué "un motor para todo" es una mentira

Una plataforma de reuniones en vivo tiene al menos cuatro tareas que hacer al mismo tiempo, y tiran en direcciones incompatibles:

1. Voz en tiempo real — audio que entra, audio traducido que sale, en menos de un segundo, cada espectador en su propio idioma. La restricción dura es la latencia.
2. Texto de chat en tiempo real — mensajes cortos, rápidos, con ediciones, citas y estructura HTML preservada.
3. Notas compartidas en tiempo real — escritura colaborativa carácter por carácter, con jerarquía estructural (listas, encabezados, casillas) que tiene que sobrevivir a la traducción.
4. Archivos de documentos asíncronos — un PDF de 40 páginas soltado en el chat. Sin presupuesto de latencia. La restricción dura es la fidelidad — formato, tablas, números de página, tipografía.

Se puede construir una sola llamada LLM gigantesca que intente hacer las cuatro. Lo intentamos. Es mala en las cuatro. El presupuesto de latencia para voz significa que el modelo no puede pensar; el presupuesto de fidelidad para documentos significa que el modelo tiene que pensar. Una edición de chat necesita un diff en el idioma del espectador; un PDF de 40 páginas necesita preservación de formato que ningún modelo de streaming de tokens le ofrece.

Así que ejecutamos cuatro. Aquí va cada una.

Canalización 1: Traducción de voz en tiempo real

El problema: Un participante habla en francés. Otro participante se unió en alemán, un tercero en portugués brasileño, un cuarto en japonés. Cada uno necesita oír al hablante en su propio idioma, en su propio oído, con un retardo lo suficientemente corto como para mantener posible el contacto visual.

El presupuesto: Menos de un segundo de extremo a extremo. Cualquier cosa por encima de ~1,2 segundos y la conversación se rompe — la gente empieza a hablar por encima de la traducción, y la reunión deriva hacia "mejor pasémonos al inglés".

Cómo se mueve realmente el audio

Algunas cosas merecen nombrarse explícitamente:

• El ASR se ejecuta en el navegador del hablante, no en un servidor central. Usamos el Mind SDK localmente; esto ahorra un viaje de ida y vuelta y nos da la transcripción en idioma origen con el menor retardo posible antes de que la traducción siquiera pueda empezar.
• La traducción no es un único fan-out. Mantenemos un pool de conexiones WebSocket a nuestro motor de traducción, una por cada idioma de destino presente en la sala. Si tres participantes eligieron alemán, ese alemán comparte una conexión. Si nadie eligió árabe, no se abre ninguna conexión de árabe. El pool descarta las conexiones inactivas después de cinco minutos. Por eso una reunión de cuatro idiomas cuesta lo mismo que una reunión de cuarenta idiomas hasta el punto de quiénes se conectaron realmente — nunca traducimos a idiomas que ningún participante esté escuchando.
• El habla sintetizada es por espectador. Cada participante recibe su propia pista de audio traducida, mezclada contra el vídeo del hablante original. No están viendo una "reunión traducida" maestra — están viendo la misma reunión, con su canal de audio personal traducido al idioma que eligieron. Por eso dos personas en la misma sala física pueden enchufarse cada uno sus auriculares y oír idiomas distintos.

Por qué esto importa cuando una reunión se tuerce

En una llamada de 60 minutos con ocho idiomas, las cosas se rompen de formas interesantes: los WebSockets caen, el ASR transcribe mal temporalmente un nombre propio, la red de un participante se vuelve inestable. La arquitectura anterior es lo que nos permite aislar fallos: que el audio de un espectador tenga un glitch no afecta a los otros siete, porque el motor de traducción nunca produjo "la traducción" en primer lugar — produjo ocho, en paralelo, y solo el afectado tiene que recuperarse.

El motor en sí es nuestro, alojado en nuestra propia infraestructura. No enrutamos voz en tiempo real a través de LLMs de propósito general de terceros. El presupuesto de latencia los descarta; la historia de residencia de datos los descarta para los clientes regulados a quienes esto realmente les importa.

Lo que publicamos sobre calidad de voz: /benchmark ejecuta la canalización de voz de producción contra frases de FLORES-200 para cada par de idiomas publicado, mensualmente. El juez está identificado (Gemini 2.5 Flash como principal, Claude Sonnet 4 como respaldo). La distribución completa — mediana, p10, p90, mín, máx, tamaño de muestra — está en la página. Consulte la metodología para saber qué miden y qué no esos números.

Canalización 2: Traducción de chat en tiempo real

El problema: Cada mensaje de chat en la reunión, traducido para cada participante en su propio idioma, según se envía. Más las ediciones — y las ediciones tienen que parecer ediciones, no retraducciones.

El presupuesto: Rápido, pero no inferior a un segundo. Un mensaje de chat puede tardar medio segundo en aparecer en otro idioma sin que a nadie le importe. Lo que a la gente le importa es si la traducción es correcta y si las ediciones tienen sentido.

Lo que hace realmente la canalización de chat

Cada mensaje pasa por el mismo motor de traducción que usa la canalización de voz — pero con un pre y posprocesado diferentes:

• La estructura HTML se preserva. El chat admite texto enriquecido (párrafos, listas, citas, negrita, cursiva). Convertimos a texto plano para el modelo, traducimos, y luego volvemos a envolver el resultado en las etiquetas originales. El modelo nunca ve el HTML — ve prosa limpia.
• Las citas se traducen de forma independiente. Si responde a un mensaje y lo cita, el bloque [QUOTE]…[/QUOTE] y el contenido nuevo se traducen como unidades separadas, para que el modelo no pueda confundir ambos.
• Los mensajes largos se trocean. Dividimos en los límites de párrafo a 1.000 caracteres por trozo. Cada trozo es su propia llamada de traducción. No le metemos novelas de 4.000 caracteres al modelo de una sola vez — los modos de fallo (truncamiento, párrafos perdidos, cortes a mitad de frase) son demasiado feos.
• La traducción es perezosa. Usamos un IntersectionObserver: un mensaje solo se traduce cuando entra en la viewport del espectador. Cambiar de idioma en un canal de larga duración antes reproducía todas las llamadas a la API de traducción del historial. Ahora ya no.

La parte interesante: las ediciones como diffs

En la v1.2 cambiamos cómo se comportan las ediciones de chat para los espectadores en otro idioma. El comportamiento antiguo era: alguien edita un mensaje, retraducimos todo, usted ve un párrafo nuevo y tiene que detectar qué se movió.

El comportamiento nuevo:

1. El mensaje original ya estaba traducido a su idioma.
2. Cuando el remitente edita, retraducimos la nueva versión.
3. Calculamos el diff entre su traducción anterior y su nueva traducción, en su idioma.
4. Mostramos ese diff en línea — de la misma manera que Git le muestra qué cambió.

Así, cuando "review by Tuesday" se convierte en "review by Thursday" en inglés, su compañero que lee en español ve martes → jueves resaltado, no un párrafo retraducido que tiene que volver a leer.

Esto requirió tratar la canalización de chat como una caché con estado por espectador, no como un endpoint sin estado que traduce a petición. Documentos y voz no necesitan esto. El chat sí.

Canalización 3: Traducción de notas compartidas en tiempo real

El problema: El anfitrión abre un panel de notas compartidas y empieza a escribir. Cada participante ve las notas en su idioma, carácter por carácter, con la estructura del documento — encabezados, listas anidadas, listas de comprobación, bloques de código — intacta.

El presupuesto: El mismo que el chat (~medio segundo), pero con dos restricciones adicionales:

• Lo que se está traduciendo cambia a mitad de traducción. El anfitrión sigue escribiendo. Un sistema ingenuo que traduzca "el documento entero" en cada pulsación produce parpadeo y quema el presupuesto de API. Traducimos a la granularidad de la unidad modificada, no del documento entero.
• La estructura debe sobrevivir. Si le pide a un modelo de traducción que traduzca un blob de markdown con tres listas anidadas, le devuelve algo que parece el original pero con jerarquía sutilmente aplanada, elementos renumerados o sangría desplazada. No dejamos que el modelo vea el blob entero.

En qué se diferencia la canalización de notas del chat

La preservación estructural es lo principal. Traducimos cada elemento de lista de forma independiente en lugar de como un único documento. El modelo ve:

"Revisión de cumplimiento — entregables del Q2"

— no:

"# Plan de proyecto\n## Trimestre\n- Revisión de cumplimiento — entregables del Q2\n- Puntuación de proveedores\n - Proveedores Tier 1..."

El documento que envuelve — el <ul>, los encabezados, la sangría — se reconstruye en el lado del cliente usando la misma estructura que tenía el documento original, con cada nodo hoja sustituido por su traducción. El modelo no llega a "mejorar" la jerarquía.

Las notas también usan el mismo modelo de diff por espectador que las ediciones de chat: si el anfitrión cambia una línea, los espectadores en otros idiomas ven las palabras cambiadas resaltadas, no un párrafo nuevo.

Canalización 4: Traducción de documentos asíncrona

El problema: Alguien deja caer un PDF de 40 páginas, un documento de Word, una presentación de PowerPoint o una hoja de Excel en el chat. Cada participante puede solicitar una copia en su propio idioma. El archivo traducido debe parecerse al original — mismas tipografías, mismas tablas, mismos números de página, mismos encabezados, mismos gráficos en su sitio.

El presupuesto: Sin restricción de tiempo real. Un minuto vale. Dos minutos valen. La restricción es la fidelidad — si el PDF traducido no se parece al original, el destinatario no confiará en él.

Por qué esta canalización no comparte motor con voz

Un LLM general, incluso uno muy bueno, le devolverá un texto traducido de un documento. No le devolverá un PDF traducido con el mismo diseño. El modelo no tiene concepto de "salto de página que tiene que cuadrar con el origen" o "celda de tabla que tiene que conservar su ancho de columna".

Para esta superficie usamos directamente la DeepL Document API. Está construida específicamente para traducir archivos como archivos, no prosa extraída de archivos. DeepL gestiona:

• PDF (con preservación de diseño)
• DOCX, DOC
• PPTX
• XLSX

El documento se sube a la canalización de DeepL, se traduce en el servidor con el formato intacto y se devuelve en el mismo formato. Luego subimos el resultado a nuestro almacenamiento de objetos y lo presentamos de vuelta en el chat como un adjunto descargable.

Lo que esto cuesta y por qué no lo ocultamos

DeepL factura un mínimo de 50.000 caracteres por documento — aproximadamente un dólar estadounidense por archivo en el plan Pro, independientemente de si el documento tiene una página o treinta. Absorbemos ese coste en lugar de cobrar por archivo; aparece en el uso de traducción de la reunión como caracteres facturados, convertido a unidades de palabras que coinciden con la forma en que el resto del producto informa de la actividad de traducción.

Elegimos DeepL para esta superficie porque es el motor de referencia para traducción de documentos específicamente. No pretendemos haber construido uno mejor. Lo contrario no es cierto — DeepL no ejecuta una canalización de voz en directo del tipo que construimos para reuniones. Problemas distintos; herramientas distintas. La versión honesta de "qué impulsa la traducción de InterMIND" es "el motor adecuado por canalización" — no "nuestro motor, en todas partes".

Idiomas que esta canalización cubre y que voz no

La canalización de documentos llega a 30 idiomas, frente a los 22 de voz. Los extras incluyen: búlgaro, griego, estonio, indonesio, lituano, letón, noruego bokmål, eslovaco, esloveno — más árabe, que ocultamos del selector en tiempo real porque la calidad de voz no supera nuestro listón pero que DeepL gestiona bien como documentos.

Esa asimetría es real. Significa que un participante francés en una reunión puede solicitar el PDF del contrato en estonio aunque no pueda escuchar la reunión en estonio. Lo señalamos en el selector en lugar de disimularlo con un único número. El razonamiento está en la publicación sobre el número de idiomas.

Donde se encuentran las canalizaciones

Las cuatro canalizaciones no funcionan aisladas. Una sala de reuniones es donde se tocan unas a otras, y las costuras importan:

• Un mensaje de chat con un documento adjunto activa la canalización de chat para el texto y la canalización de documentos para el archivo. El participante en otro idioma ve el mensaje traducido inmediatamente y la traducción del adjunto llega de forma asíncrona como descargable.
• Una nota compartida que cita una línea de transcripción cruza notas ↔ voz. La transcripción es lo que la canalización de voz produjo para el idioma del remitente; la traducción de la nota produce una copia por espectador de esa cita en el idioma de cada cual, con su atribución de origen preservada.
• Una transcripción exportada después de la reunión ejecuta la canalización de texto estilo chat sobre toda la conversación, produciendo un archivo por idioma que los participantes pueden descargar. Es la misma ruta de código que la traducción de chat, solo que en lote.

El selector de idioma es una pieza de UI. La infraestructura debajo son cuatro canalizaciones, hablándose entre sí.

Lo que deliberadamente no intentamos

• Ningún "modelo de traducción unificado". No estamos construyendo un único modelo que haga voz, chat, notas y documentos. La disyuntiva entre latencia y fidelidad no tiene ganador. Usamos el motor adecuado por superficie.
• Ningún reenrutamiento silencioso. Si voz no puede traducir al hindi hoy, no recurrimos calladamente al motor de documentos fingiendo que funcionó. El hindi está oculto del selector en ambas superficies porque el resultado en cualquiera de las dos superficies hoy no es presentable.
• Ningún "traducimos a 200 idiomas". Nuestro motor emite 24. Nuestro producto ofrece 22 en las superficies en vivo y 30 en documentos. El número grande amigable para marketing es solo el techo del motor. El número del producto es el que realmente supera el listón frente a un auditor.

Pruébelo usted mismo

• /demo — ejecuta la canalización de voz en directo contra su audio, en cualquiera de los 22 idiomas del producto. La misma canalización que puntúa /benchmark.
• /benchmark — calidad por par y por mes sobre tráfico real. Incluye los pares que deliberadamente ocultamos del selector, con enlaces directos.
• /benchmark/methodology — qué son los números, qué no son, quién es el juez.

Cuatro canalizaciones, cuatro motores, una sala de reuniones. Esa es la sustitución honesta para la antigua página how-it-works.

— The Mind.com Team