Así funcionan los cuatro pipelines de traducción que mueven InterMIND

La antigua página /product/overview/how-it-works de mind.com lleva varias versiones mayores sin actualizarse. Describe un único «motor de traducción», como hacen casi todas las páginas de proveedores: una gran flecha que va de «usted habla» a «ellos escuchan». Esa imagen ya era una simplificación hace dos años. Hoy es incorrecta.

En realidad, InterMIND ejecuta cuatro pipelines de traducción independientes. Cada uno resuelve un problema distinto, con un motor distinto, un presupuesto de latencia distinto y un margen de calidad distinto. Comparten el selector de idioma. No comparten motor.

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

Un artículo complementario: «¿Cuántos idiomas admiten?» explica qué cubre cada pipeline (23 / 23 / 30 / 17). Este artículo explica qué hace cada pipeline y por qué es una pieza independiente.

Por qué «un solo motor para todo» es un error

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

1. Voz en tiempo real: entra audio y sale audio traducido mientras el orador sigue hablando, con cada espectador en su propio idioma. La restricción principal es la latencia.
2. Texto de chat en tiempo real: mensajes breves y rápidos, con ediciones, citas y estructura HTML conservadas.
3. Notas compartidas en tiempo real: escritura colaborativa carácter a carácter, con una jerarquía (listas, encabezados, casillas de verificación) que debe 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 principal es la fidelidad: formato, tablas, números de página, tipografía.

Se puede construir una única llamada gigante a un LLM que intente hacer las cuatro cosas. Lo intentamos. Lo hace mal en las cuatro. El presupuesto de latencia de la voz exige que el modelo no piense; el presupuesto de fidelidad de los documentos exige que piense. Una edición de chat necesita un diff en el idioma del espectador; un PDF de 40 páginas necesita una conservación del formato que ningún modelo de generación por tokens ofrece.

Por eso ejecutamos cuatro. Aquí están, uno por uno.

Pipeline 1: Traducción de voz en tiempo real

El problema: un participante habla en francés. Otro se ha unido en alemán, un tercero en portugués de Brasil y un cuarto en japonés. Cada uno necesita oír al orador en su propio idioma, en su propio auricular, con un retraso lo bastante corto como para que mantener el contacto visual siga siendo posible.

El presupuesto: nadie debe tener que esperar a la traducción. Cuando el habla traducida se retrasa tanto que la gente empieza a hablar por encima, la reunión deriva hacia el «mejor pasemos todos al inglés».

Cómo se mueve realmente el audio

Conviene señalar explícitamente algunos puntos:

• El ASR se ejecuta en el servidor multimedia. El audio del orador viaja por WebRTC hasta nuestro propio motor (la Mind API en OVH, Francia) y se reconoce allí, en el mismo servidor que transporta la llamada; el navegador solo envía audio y recibe las palabras de vuelta. No hay un proveedor de voz aparte ni un salto adicional antes de que pueda empezar la traducción. (Las notas de voz del chat son la excepción: su conversión de voz a texto se ejecuta en Azure AI Speech, el servicio de voz de la pasarela de IA predeterminada.)
• La traducción no es una difusión única. El motor traduce por idioma de destino presente en la sala, no por espectador: la traducción a un idioma empieza cuando el primer oyente de ese idioma solicita una transmisión traducida, tres participantes que eligieron alemán comparten una misma traducción al alemán, y si nadie escucha en árabe, no se traduce nada al árabe. Por eso una reunión en cuatro idiomas cuesta lo mismo que una en cuarenta, en la medida en que cuenta quién asistió realmente: nunca traducimos a idiomas en los que ningún participante está escuchando.
• El habla 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, sino la misma reunión, con su canal de audio personal traducido al idioma que han elegido. Por eso dos personas en la misma sala física pueden ponerse cada una unos auriculares y oír idiomas distintos.

Por qué importa cuando una reunión se tuerce

En una llamada de 60 minutos con ocho idiomas, las cosas fallan de formas interesantes: se caen los WebSockets, el ASR transcribe mal un nombre propio durante un momento, la red de un participante se vuelve inestable. La arquitectura descrita es lo que nos permite aislar los fallos: el audio defectuoso de un espectador no afecta a los otros siete, porque el motor de traducción nunca produjo «la traducción»: produjo ocho, en paralelo, y solo la afectada tiene que recuperarse.

El motor es nuestro y está alojado en nuestra propia infraestructura. No hacemos pasar la voz en tiempo real por LLM generalistas de terceros. El presupuesto de latencia los descarta; la residencia de datos los descarta para los clientes regulados a quienes de verdad les importa.

Lo que publicamos sobre la calidad de la voz: /benchmark ejecuta cada mes el pipeline de voz de producción con frases de FLORES-200 para cada par de idiomas publicado. El juez está identificado (Gemini 3.7 Flash como principal, Claude Sonnet 5 como respaldo). La distribución completa (mediana, p10, p90, mínimo, máximo y tamaño de la muestra) está en la página. Consulte la metodología para saber qué miden y qué no miden esas cifras.

Pipeline 2: Traducción de chat en tiempo real

El problema: cada mensaje de chat de la reunión, traducido para cada participante a su propio idioma, en el momento en que se envía. Además, las ediciones, que deben verse como ediciones y no como retraducciones.

El presupuesto: más holgado que el de la voz. Un mensaje de chat puede tardar un instante en aparecer en otro idioma sin que a nadie le importe. Lo que importa es que la traducción sea correcta y que las ediciones tengan sentido.

Qué hace realmente el pipeline de chat

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

• Se conserva la estructura HTML. El chat admite texto enriquecido (párrafos, listas, citas, negrita, cursiva). Lo convertimos a texto plano para el modelo, traducimos y 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 confundirlos.
• Los mensajes largos se dividen en fragmentos. Cortamos por límites de párrafo a 1000 caracteres por fragmento. Cada fragmento es una llamada de traducción propia. No le damos al modelo novelas de 4000 caracteres de una sola vez: los modos de fallo (truncamiento, párrafos perdidos, cortes a media frase) son demasiado feos.
• La traducción es bajo demanda. Usamos un IntersectionObserver: un mensaje solo se traduce cuando entra en el área visible del espectador. Antes, cambiar de idioma en un canal activo durante mucho tiempo reproducía todas las llamadas a la API de traducción del historial. Ahora ya no.

Lo interesante: las ediciones como diffs

En la v1.2 cambiamos el comportamiento de las ediciones de chat para los espectadores de otro idioma. Antes ocurría esto: alguien editaba un mensaje, volvíamos a traducirlo entero, y usted veía un párrafo nuevo y tenía que descubrir qué había cambiado.

El nuevo comportamiento:

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

Así, cuando «review by Tuesday» pasa a ser «review by Thursday» en inglés, su colega que lee en español ve resaltado martes → jueves, no un párrafo retraducido que tenga que releer.

Esto exigió tratar el pipeline de chat como una caché con estado por espectador, no como un endpoint sin estado de traducir bajo petición. Los documentos y la voz no lo necesitan. El chat sí.

Pipeline 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 a carácter, con la estructura del documento (encabezados, listas anidadas, listas de tareas, bloques de código) intacta.

El presupuesto: el mismo que el chat, pero con dos restricciones adicionales:

• Lo que se traduce cambia durante la traducción. El anfitrión sigue escribiendo. Un sistema ingenuo que traduzca «todo el documento» en cada pulsación de tecla produce parpadeos y quema el presupuesto de la API. Nosotros traducimos con la granularidad de la unidad modificada, no del documento completo.
• La estructura debe sobrevivir. Si le pide a un modelo de traducción que traduzca un bloque de markdown con tres listas anidadas, le devuelve algo que se parece al original, pero con la jerarquía sutilmente aplanada, los elementos renumerados o la sangría desplazada. No dejamos que el modelo vea el bloque completo.

En qué se diferencia el pipeline de notas del de chat

Lo principal es la conservación de la estructura. Traducimos cada elemento de lista de forma independiente y no como un único documento. El modelo ve:

«Revisión de cumplimiento — entregables del T2»

y no:

"# Project plan\n## Quarter\n- Compliance review — Q2 deliverables\n- Vendor scoring\n - Tier 1 vendors..."

El documento envolvente (el <ul>, los encabezados, la sangría) se reconstruye en el cliente con la misma estructura que tenía el documento original, sustituyendo cada nodo hoja 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 de chat: si el anfitrión cambia una línea, los espectadores de otros idiomas ven resaltadas las palabras modificadas, no un párrafo nuevo.

Pipeline 4: Traducción asíncrona de documentos

El problema: alguien suelta en el chat un PDF de 40 páginas, un documento de Word, una presentación de PowerPoint o una hoja de Excel. Cada participante puede solicitar una copia en su propio idioma. El archivo traducido debe verse igual que el 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 está bien. Dos minutos también. La restricción es la fidelidad: si el PDF traducido no se parece al original, quien lo recibe no confiará en él.

Por qué este pipeline no comparte motor con la voz

Un LLM generalista, por bueno que sea, le devolverá un texto traducido del documento. No le devolverá un PDF traducido con la misma maquetación. El modelo no tiene ningún concepto de «salto de página que debe coincidir con el original» ni de «celda de tabla que debe conservar el ancho de su columna».

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

• PDF (con conservación de la maquetación)
• DOCX, DOC
• PPTX
• XLSX

El documento se sube al pipeline de DeepL, se traduce en el servidor con el formato intacto y se devuelve en el mismo formato. Después subimos el resultado a nuestro almacenamiento de objetos y lo mostramos de nuevo en el chat como un archivo adjunto descargable.

Qué 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 plan Pro), tenga el documento una página o treinta. Asumimos ese coste en lugar de cobrar por archivo; aparece en el uso de traducción de la reunión como caracteres facturados, convertidos en 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 traducir archivos como archivos es exactamente el trabajo para el que fue creado, y no intentamos construir uno mejor. Lo contrario no es cierto: DeepL no ofrece un pipeline de voz en directo como el que construimos para las reuniones. Problemas distintos, herramientas distintas. La versión honesta de «qué impulsa la traducción de InterMIND» es «el motor adecuado para cada pipeline», no «nuestro motor, en todas partes».

Idiomas que cubre este pipeline y la voz no

El pipeline de documentos llega a 30 idiomas, frente a 23 de la voz. Entre los adicionales están: búlgaro, griego, estonio, indonesio, lituano, letón, eslovaco y esloveno. (El árabe también figura en esta lista y es uno de los adicionales: está retirado del selector en tiempo real mientras su calidad de voz esté por debajo de nuestro listón, y sus puntuaciones por par siguen siendo públicas en /benchmark; esa cifra es la que lo devolverá. La asimetría va en sentido contrario para el hindi: disponible en voz, todavía no en archivos.)

Esa asimetría es real. Significa que un participante francés de 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 una cifra única. El razonamiento está en el artículo sobre el número de idiomas.

Dónde se encuentran los pipelines

Los cuatro pipelines no funcionan de forma aislada. Una sala de reunión es el lugar donde se tocan, y las costuras importan:

• Un mensaje de chat con un documento adjunto activa el pipeline de chat para el texto y el de documentos para el archivo. El participante de otro idioma ve el mensaje traducido de inmediato, y la traducción del adjunto llega de forma asíncrona 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 pipeline de voz produjo para el idioma del remitente; la traducción de la nota genera una copia de esa cita por espectador en el idioma de cada uno, con su atribución de origen conservada.
• Una transcripción exportada después de la reunión ejecuta el pipeline de texto de estilo chat sobre toda la conversación y produce un archivo por idioma que los participantes pueden descargar. 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 interfaz. La infraestructura que hay debajo son cuatro pipelines que se hablan 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. El equilibrio entre latencia y fidelidad no tiene ganador. Usamos el motor adecuado para cada superficie.
• Ningún reencaminamiento silencioso. Si el pipeline de archivos no puede traducir hoy al hindi, no recurrimos discretamente al motor de voz fingiendo que ha funcionado: el selector de archivos señala la carencia en lugar de ocultarla.
• Ningún «traducimos a 200 idiomas». Nuestro motor emite 24. Las superficies en directo ofrecen 23 y los documentos 30; y en lugar de una cifra atractiva para el marketing, la calidad por par que tiene que resistir ante un auditor se publica en /benchmark, con los pares más débiles incluidos.

Pruébelo usted mismo

• Pruebe la demo en vivo: ejecuta el pipeline de voz en directo con su audio, en cualquiera de los 23 idiomas del producto. Es el mismo pipeline que obtiene las puntuaciones de /benchmark.
• Consulte el benchmark: calidad por par y por mes sobre tráfico real. Todos los pares del selector, fuertes o débiles, con enlace directo.
• Lea la metodología: qué son las cifras, qué no son y quién es el juez.

Cuatro pipelines, cuatro motores, una sala de reunión. Esa es la sustitución honesta 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 de los pipelines verificados con el código en producción, comprobados en agosto de 2026.