Dentro de los cuatro flujos de traducción que ejecutan InterMIND

La antigua página /product/overview/how-it-works en mind.com está desactualizada por varias versiones principales. 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 escuchan». Esa imagen ya era una simplificación hace dos años. Hoy es incorrecta.

La verdad es que InterMIND ejecuta cuatro flujos de traducción separados, cada uno resolviendo un problema diferente con un motor diferente, un presupuesto de latencia diferente y un margen de calidad diferente. Comparten un selector de idioma. No comparten un motor.

Esta es la respuesta actualizada a «cómo funciona».

Un artículo complementario: «¿Cuántos idiomas admiten?» cubre lo que cada flujo cubre (24 / 24 / 30 / 17). Esta publicación cubre lo que cada flujo hace y por qué es una entidad propia.

Por qué «un motor para todo» es una mentira

Una plataforma de reuniones en directo tiene al menos cuatro tareas que realizar a la vez, y tiran en direcciones incompatibles:

1. Voz en tiempo real: entrada de audio, salida de audio traducido, en menos de un segundo, cada espectador en su propio idioma. La principal restricción 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 de verificación) que debe sobrevivir a la traducción.
4. Archivos de documentos asincrónicos: un PDF de 40 páginas enviado al chat. Sin presupuesto de latencia. La principal restricción es la fidelidad: formato, tablas, números de página, fuente.

Se puede construir una llamada LLM gigante que intente hacer las cuatro cosas. Lo intentamos. Es mala en las cuatro. El presupuesto de latencia para la voz significa que el modelo no puede pensar; el presupuesto de fidelidad para los documentos significa que el modelo tiene que hacerlo. Una edición en el 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 transmisión de tokens le ofrece.

Así que ejecutamos cuatro. Aquí está cada uno.

Flujo 1: Traducción de voz en tiempo real

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

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 «cambiemos al inglés».

Cómo se mueve el audio realmente

Algunas cosas que vale la pena mencionar explícitamente:

• ASR se ejecuta en el navegador del orador, no en un servidor central. Usamos Mind SDK localmente; esto ahorra un viaje de ida y vuelta y nos da la transcripción en el idioma de origen con el menor retraso posible antes de que la traducción pueda comenzar.
• La traducción no es una única distribución (fan-out). Mantenemos un grupo 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, el alemán comparte una conexión. Si nadie eligió árabe, no se abre ninguna conexión en árabe. El grupo elimina las conexiones inactivas después de cinco minutos. Por eso, una reunión de cuatro idiomas cuesta lo mismo que una de cuarenta idiomas hasta el punto de quién asistió realmente: nunca traducimos a idiomas en los que ningún participante está escuchando.
• La voz sintetizada es por espectador. Cada participante recibe su propia pista de audio traducida, mezclada con el vídeo del orador 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 esto, dos personas en la misma sala física pueden conectar sus auriculares y escuchar idiomas diferentes.

Por qué esto importa cuando una reunión sale mal

En una llamada de 60 minutos con ocho idiomas, las cosas se rompen de maneras interesantes: se caen los WebSockets, ASR transcribe mal temporalmente un nombre propio, la red de un participante se vuelve inestable. La arquitectura anterior es lo que nos permite aislar los fallos: que el audio de un espectador falle 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 la afectada tiene que recuperarse.

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

Lo que publicamos sobre la calidad de voz: /benchmark ejecuta el flujo de voz de producción contra las frases de FLORES-200 para cada par de idiomas publicado, mensualmente. El juez es nombrado (Gemini 2.5 Flash 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 miden esos números.

Flujo 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, a medida que se envía. Además de las ediciones, y las ediciones deben 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 realmente hace el flujo de chat

Cada mensaje pasa por el mismo motor de traducción que usa el flujo de voz, pero con un preprocesamiento y posprocesamiento diferentes:

• La estructura HTML se preserva. El chat admite texto enriquecido (párrafos, listas, citas, negrita, cursiva). Convertimos a texto sin formato para el modelo, traducimos y luego envolvemos 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, por lo que el modelo no puede confundirlos.
• Los mensajes largos se dividen en fragmentos. Dividimos en los límites de los párrafos a 1.000 caracteres por fragmento. Cada fragmento es su propia llamada de traducción. No alimentamos al modelo con novelas de 4.000 caracteres de una sola vez; los modos de fallo (truncamiento, párrafos perdidos, cortes a mitad de frase) son demasiado feos.
• La traducción es diferida (lazy). Usamos un IntersectionObserver: un mensaje solo se traduce cuando se desplaza hacia la ventana gráfica del espectador. Cambiar de idioma en un canal de larga duración solía reproducir cada llamada a la API de traducción desde el historial. Ahora ya no.

La parte interesante: ediciones como diffs

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

El nuevo comportamiento:

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 colega que lee en español ve martes → jueves resaltado, no un párrafo traducido de nuevo que tenga que volver a leer.

Esto requirió tratar el flujo de chat como una caché con estado por espectador, no como un punto final sin estado que traduce bajo demanda. Los documentos y la voz no necesitan esto. El chat sí.

Flujo 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 verificación, bloques de código) intacta.

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

• Lo que se traduce cambia a mitad de la traducción. El anfitrión sigue escribiendo. Un sistema ingenuo que traduzca «todo el documento» con cada pulsación de tecla produce parpadeo y agota el presupuesto de la API. Traducimos a la granularidad de la unidad cambiada, no de todo el documento.
• La estructura debe sobrevivir. Si le pide a un modelo de traducción que traduzca un bloque de markdown con tres listas anidadas, obtiene algo que parece el original pero con una jerarquía sutilmente aplanada, elementos renumerados o sangría desplazada. No dejamos que el modelo vea el bloque completo.

En qué se diferencia el flujo de notas del chat

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

«Revisión de cumplimiento — entregables del Q2»

— no:

"# Project plan\n## Quarter\n- Revisión de cumplimiento — entregables del Q2\n- Puntuación de proveedores\n - Proveedores de Nivel 1..."

El documento envolvente (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 reemplazado por su traducción. El modelo nunca llega a «mejorar» la jerarquía.

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

Flujo 4: Traducción asincrónica de documentos

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

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

Por qué este flujo no comparte motor con la 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 alinearse con el original» ni de «celda de tabla que tiene que mantener su ancho de columna».

Para esta capa usamos la DeepL Document API directamente. Está diseñada específicamente para traducir archivos como archivos, no prosa extraída de archivos. DeepL maneja:

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

El documento se carga en el flujo de DeepL, se traduce del lado del servidor con el formato intacto y se devuelve en el mismo formato. Luego cargamos el resultado en nuestro almacenamiento de objetos y lo mostramos de nuevo en el chat como un archivo adjunto descargable.

Cuánto cuesta esto 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 nivel 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, convertidos a unidades de palabras que coinciden con la forma en que el resto del producto informa la actividad de traducción.

Elegimos DeepL para esta capa porque traducir archivos como archivos es exactamente el trabajo para el que fue construido; no intentamos construir uno mejor. Lo mismo no es cierto en sentido contrario: DeepL no ejecuta un flujo de voz en directo del tipo que construimos para las reuniones. Problemas diferentes; herramientas diferentes. La versión honesta de «qué impulsa la traducción de InterMIND» es «el motor adecuado para cada flujo», no «nuestro motor, en todas partes».

Idiomas que cubre este flujo y la voz no

El flujo de documentos alcanza 30 idiomas, frente a 24 para la voz. Los extras incluyen: búlgaro, griego, estonio, indonesio, lituano, letón, eslovaco, esloveno. (El árabe solía estar en esta lista mientras su calidad de voz estaba por debajo de nuestro estándar; ahora está en el selector en tiempo real, con sus puntuaciones por par públicas en /benchmark como cualquier otro idioma. La asimetría ahora va en sentido contrario para el hindi: en directo en la voz, pero aún no en archivos.)

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 indicamos en el selector en lugar de disimularlo con un único número. El razonamiento está en la publicación sobre recuento de idiomas.

Dónde se cruzan los flujos

Los cuatro flujos no se ejecutan de forma aislada. Una sala de reuniones es donde se tocan entre sí, y las uniones importan:

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

El selector de idioma es una sola pieza de la interfaz de usuario. La infraestructura subyacente son cuatro flujos, hablando entre sí.

Lo que deliberadamente no intentamos hacer

• No hay un «modelo de traducción unificado». No estamos construyendo un modelo que haga voz, chat, notas y documentos. El equilibrio entre latencia y fidelidad no tiene un ganador. Usamos el motor adecuado para cada capa.
• No hay reenrutamiento silencioso. Si el flujo de archivos no puede traducir al hindi hoy, no recurrimos en silencio al motor de voz y fingimos que funcionó; el selector de archivos indica la carencia en lugar de ocultarla.
• No hay «traducimos a 200 idiomas». Nuestro motor emite 24. Las superficies en directo envían los 24, los documentos 30, y en lugar de un número apto para marketing, la calidad por par que tiene que presentarse ante un auditor se publica en /benchmark, incluyendo los pares más débiles.

Pruébelo usted mismo

• Pruebe la demo en vivo: ejecuta el flujo de voz en directo contra su audio, en cualquiera de los 24 idiomas del producto. El mismo flujo que puntúa en /benchmark.
• Vea el benchmark: calidad por par y por mes en tráfico real. Cada par en el selector, fuerte o débil, con enlace profundo.
• Lea la metodología: qué son los números, qué no son, quién es el juez.

Cuatro flujos, cuatro motores, una sala de reuniones. Ese es el reemplazo honesto de la antigua página how-it-works.

— El equipo de Mind.com

Fuentes: DeepL — idiomas admitidos, DeepL — recuento de uso y facturación (el mínimo de 50.000 caracteres por archivo), FLORES-200; datos internos del flujo verificados contra el código enviado, comprobado en agosto de 2026.