Dentro de los cuatro pipelines de traducción que impulsan InterMIND

La antigua página /product/overview/how-it-works en mind.com está obsoleta por varias versiones principales. Describe un único "motor de traducción" como lo hacen la mayoría de páginas de proveedores: una gran flecha de "usted habla" a "ellos escuchan". Esa imagen ya era una simplificación hace dos años. Hoy es incorrecta.

La verdad es que InterMIND ejecuta cuatro pipelines de traducción separados, cada uno resolviendo un problema distinto 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 pipeline cubre (23 / 23 / 30 / 17). Este artículo cubre lo que cada pipeline hace — y por qué tiene entidad propia.

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

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

1. Voz en tiempo real — audio entra, audio traducido sale, en menos de un segundo, cada espectador en su propio idioma. La restricción estricta 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 documento asíncronos — un PDF de 40 páginas enviado al chat. Sin presupuesto de latencia. La restricción estricta es la fidelidad — formato, tablas, números de página, tipografía.

Se puede construir una llamada LLM gigante que intente hacer las cuatro. Lo intentamos. Es mala en las cuatro. El presupuesto de latencia de la voz significa que el modelo no puede pensar; el presupuesto de fidelidad de los documentos significa que el modelo tiene que hacerlo. 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í está cada uno.

Pipeline 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, 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 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 "cambiemos al inglés".

Cómo se mueve realmente el audio

Algunas cosas que vale la pena nombrar explícitamente:

• ASR se ejecuta en el servidor de medios. El audio del orador viaja por WebRTC a nuestro propio motor — la Mind API en OVH, Francia — y se reconoce allí, en el mismo servidor que lleva la llamada; el navegador solo envía audio y recibe las palabras de vuelta. No hay un proveedor de voz separado ni un salto extra antes de que la traducción pueda comenzar. (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 del AI gateway predeterminado.)
• La traducción no es un fan-out único. El motor traduce por idioma de destino presente en la sala, no por espectador: la traducción a un idioma comienza cuando el primer oyente en ese idioma solicita una transmisión traducida, tres participantes que eligieron alemán comparten una traducción al alemán, y que nadie escuche en árabe significa que no se traduce nada al árabe. Por eso una reunión de cuatro idiomas cuesta lo mismo que una de cuarenta idiomas hasta el punto de quién se presentó 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 video 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 a su idioma elegido. Por esto dos personas en la misma sala física pueden cada una 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 fallan de maneras interesantes: los WebSockets se caen, 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 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 el afectado 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 cuestión de la 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 pipeline de voz en producción contra frases de FLORES-200 para cada par de idiomas publicado, mensualmente. 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, tamaño de muestra — está en la página. Consulte la metodología para ver qué miden y qué no miden esos números.

Pipeline 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. Más las ediciones — y las ediciones deben parecer ediciones, no re-traducciones.

El presupuesto: Rápido, pero no sub-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.

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 pre- y pos-procesamiento diferente:

• 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 re-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 confundir los dos.
• Los mensajes largos se dividen en fragmentos. Dividimos en los límites de párrafo a 1.000 caracteres por fragmento. Cada fragmento es su propia llamada de traducción. No enviamos 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 diferida. Usamos un IntersectionObserver: un mensaje solo se traduce cuando se desplaza hacia el viewport del espectador. Cambiar de idioma en un canal de larga duración solía reproducir cada llamada a la API de traducción del historial. Ahora no.

La parte interesante: ediciones como diffs

En v1.2 cambiamos cómo se comportan las ediciones de chat para los espectadores en otro idioma. El comportamiento anterior era: alguien edita un mensaje, re-traducimos el 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, re-traducimos 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 re-traducido que tiene que volver a leer.

Esto requirió tratar el pipeline de chat como una caché stateful por espectador, no como un endpoint stateless de traducción bajo demanda. Los documentos y la voz no necesitan esto. 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 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 traduce "todo el documento" en cada pulsación produce parpadeo y agota el presupuesto de la API. Traducimos a la granularidad de la unidad cambiada, 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, obtiene algo que parece el original pero con una jerarquía sutilmente aplanada, elementos renumerados o indentación movida. No dejamos que el modelo vea el blob entero.

Cómo se diferencia el pipeline de notas del chat

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

"Revisión de cumplimiento — entregables Q2"

— no:

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

El documento envolvente — el <ul>, los encabezados, la indentación — 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 nunca tiene la oportunidad de "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.

Pipeline 4: Traducción de documentos asíncrona

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 verse como el original — mismas fuentes, 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 están bien. La restricción es la fidelidad — si el PDF traducido no se ve como el original, el destinatario no confiará en él.

Por qué este pipeline 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 la fuente" o "celda de tabla que tiene que mantener su ancho de columna."

Para esta superficie 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 sube al pipeline 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 mostramos de vuelta en el chat como un archivo 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, independientemente de si el documento tiene una página o treinta. Nosotros 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 palabra que coinciden con la forma en que el resto del producto reporta la actividad de traducción.

Elegimos DeepL para esta superficie 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 pipeline de voz en vivo 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 correcto para cada pipeline" — no "nuestro motor, en todas partes".

Idiomas que este pipeline cubre y la voz no

El pipeline de documentos alcanza 30 idiomas, frente a 23 de la voz. Los adicionales incluyen: búlgaro, griego, estonio, indonesio, lituano, letón, eslovaco, esloveno. (El árabe también está 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 estándar, y sus puntuaciones por par permanecen públicas en /benchmark — ese número es lo que lo traerá de vuelta. La asimetría funciona al revés para el hindi — disponible en 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 señalamos en el selector en lugar de suavizarlo con un único número. El razonamiento está en el artículo sobre conteo de idiomas.

Donde se encuentran los pipelines

Los cuatro pipelines no funcionan de forma aislada. Una sala de reuniones es donde se tocan entre sí, y las costuras importan:

• Un mensaje de chat con un archivo adjunto activa el pipeline de chat para el texto y el pipeline de documentos para el archivo. El participante en otro idioma ve el mensaje traducido inmediatamente y la traducción del adjunto llegando 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 produce una copia por espectador de esa cita en el idioma de todos los demás, con su atribución de fuente preservada.
• Una transcripción exportada después de la reunión ejecuta el pipeline 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, simplemente procesada por lotes.

El selector de idioma es una sola pieza de UI. La infraestructura que hay debajo son cuatro pipelines, hablando entre sí.

Lo que deliberadamente no intentamos

• No hay "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 correcto para cada superficie.
• No hay re-enrutamiento silencioso. Si el pipeline de archivos no puede traducir al hindi hoy, no recurrimos silenciosamente al motor de voz y fingimos que funcionó — el selector de archivos señala la brecha en lugar de ocultarla.
• No hay "traducimos a 200 idiomas." Nuestro motor emite 24. Las superficies en vivo entregan 23, los documentos 30 — y en lugar de un único número amigable para el 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 pipeline de voz en vivo contra su audio, en cualquiera de los 23 idiomas del producto. El mismo pipeline que puntúa en /benchmark.
• Vea el benchmark — calidad por par, 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 pipelines, cuatro motores, una sala de reuniones. Esa es la sustitución honesta de la antigua página how-it-works.

— El equipo de Mind.com

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