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

La antigua página /product/overview/how-it-works en mind.com está varias versiones principales desactualizada. Describe un único "motor de traducción" como lo hacen la mayoría de las 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 conductos de traducción separados, cada uno 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 un motor.

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

Un artículo complementario: "¿Cuántos idiomas soportan?" cubre lo que cada conducto cubre (24 / 21 / 30 / 6). Esta publicación cubre lo que cada conducto hace — y por qué es una entidad propia.

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

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

1. Voz en tiempo real — audio de entrada, audio traducido de salida, en menos de un segundo, cada espectador en su propio idioma. La restricción principal es la latencia.
2. Texto de chat en tiempo real — mensajes cortos, rápidos, con ediciones y citas y estructura HTML preservada.
3. Notas compartidas en tiempo real — escritura colaborativa carácter por carácter, con una jerarquía estructural (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, fuente.

Se puede construir una única llamada a un LLM gigante que intente hacer las cuatro cosas. Lo intentamos. Es malo 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 de chat necesita una diferencia en el idioma del espectador; un PDF de 40 páginas necesita una preservación del formato que ningún modelo de transmisión de tokens le da.

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

Conducto 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 el contacto visual.

El presupuesto: De extremo a extremo en menos de un segundo. Cualquier cosa más allá de ~1.2 segundos y la conversación se rompe — la gente comienza a hablar sobre la traducción, y la reunión se desvía hacia "simplemente cambiemos a inglés".

Cómo se mueve realmente el audio

Algunas cosas que vale la pena nombrar explícitamente:

• El ASR se ejecuta en el navegador del orador, no en un servidor central. Utilizamos el Mind SDK localmente; esto ahorra un viaje de ida y vuelta y nos proporciona la transcripción en el idioma de origen con el menor retraso posible antes de que la traducción pueda siquiera comenzar.
• La traducción no es una única distribución. Mantenemos un grupo de conexiones WebSocket a nuestro motor de traducción, una por 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 árabe. El grupo cierra 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 presentaron 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 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 a su idioma elegido. Por eso, dos personas en la misma habitación física pueden cada una conectar auriculares y escuchar idiomas diferentes.

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

En una llamada de 40 minutos con ocho idiomas, las cosas se rompen de maneras interesantes: los WebSockets se caen, el ASR transcribre erróneamente temporalmente un nombre propio, la red de un participante se vuelve inestable. La arquitectura anterior es lo que nos permite aislar los fallos: el fallo de audio de un espectador 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 LLM de propósito general de terceros. El presupuesto de latencia los descarta; la historia 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 conducto de voz de producción contra oraciones FLORES-200 para cada par de idiomas publicado, mensualmente. Se nombra al juez (Gemini 2.5 Flash principal, Claude Sonnet 4 de respaldo). La distribución completa — mediana, p10, p90, min, max, tamaño de muestra — está en la página. Consulte la metodología para saber qué miden y qué no miden esos números.

Conducto 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 en menos de 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 conducto de chat

Cada mensaje pasa por el mismo motor de traducción que utiliza el conducto de voz — pero con diferentes pre y post-procesamientos:

• 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 independientemente. Si responde a un mensaje y lo cita, el bloque [QUOTE]…[/QUOTE] y el nuevo contenido se traducen como unidades separadas, para que el modelo no pueda confundir los dos.
• Los mensajes largos se dividen en fragmentos. Dividimos por límites de párrafo a 1,000 caracteres por fragmento. Cada fragmento es su propia llamada de traducción. No alimentamos 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 desagradables.
• La traducción es perezosa. Utilizamos un IntersectionObserver: un mensaje solo se traduce cuando se desplaza al área visible del espectador. Cambiar de idioma en un canal de larga duración solía repetir cada llamada a la API de traducción del historial. Ahora no lo hace.

La parte interesante: ediciones como diferencias

En la 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, volvemos a traducir todo, usted ve un párrafo nuevo y tiene que detectar qué se movió.

El nuevo comportamiento:

1. El mensaje original ya estaba traducido a su idioma.
2. Cuando el remitente edita, volvemos a traducir la nueva versión.
3. Calculamos la diferencia entre su traducción anterior y su nueva traducción, en su idioma.
4. Mostramos esa diferencia en línea — de la misma manera que Git muestra lo que 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 retraducido que tenga que volver a leer.

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

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

El problema: El anfitrión abre un panel de notas compartidas y comienza 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 está traduciendo cambia a mitad de la traducción. El anfitrión sigue escribiendo. Un sistema ingenuo que traduce "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 markdown con tres listas anidadas, obtendrá algo que parece el original, pero con una jerarquía sutilmente aplanada, elementos renumerados o sangría movida. No permitimos que el modelo vea todo el bloque.

Cómo el conducto de notas difiere del chat

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

"Revisión de cumplimiento — entregables del T2"

— no:

"# Plan del proyecto\n## Trimestre\n- Revisión de cumplimiento — entregables del T2\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 utilizando la misma estructura que tenía el documento original, con cada nodo hoja intercambiado por su traducción. El modelo nunca llega a "mejorar" la jerarquía.

Las notas también utilizan el mismo modelo de diferencias 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.

Conducto 4: Traducción asíncrona de documentos

El problema: Alguien suelta 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 fuentes, mismas tablas, mismos números de página, mismos encabezados, mismos gráficos en su lugar.

El presupuesto: Sin restricciones en 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 conducto 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 el concepto de "salto de página que debe coincidir con el origen" o "celda de tabla que debe mantener el ancho de su columna".

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

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

El documento se carga al conducto de DeepL, se traduce en el servidor con el formato intacto y se devuelve en el mismo formato. Luego cargamos el resultado a 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 o treinta páginas. Asumimos 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 superficie porque es el mejor motor de su clase específicamente para la traducción de documentos. No pretendemos haber construido uno mejor. Lo mismo no es cierto a la inversa — DeepL no ejecuta un conducto de voz en vivo del tipo que construimos para reuniones. Problemas diferentes; herramientas diferentes. La versión honesta de "qué impulsa la traducción de InterMIND" es "el motor adecuado para cada conducto" — no "nuestro motor, en todas partes".

Idiomas que este conducto cubre y la voz no

El conducto de documentos abarca 30 idiomas, frente a 21 para la voz. Los nueve adicionales incluyen: búlgaro, griego, estonio, indonesio, lituano, letón, noruego bokmål, eslovaco, esloveno — además de árabe y turco, que ocultamos del selector en tiempo real porque la calidad de voz no supera nuestro estándar, pero que DeepL maneja 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 suavizarlo con un solo número. El razonamiento está en la publicación sobre el recuento de idiomas.

Dónde se encuentran los conductos

Los cuatro conductos no funcionan 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 de documento activa el conducto de chat para el texto y el conducto de documentos para el archivo. El participante en otro idioma ve el mensaje traducido inmediatamente y la traducción del archivo adjunto llega asincrónicamente como un descargable.
• Una nota compartida que cita una línea de la transcripción cruza notas ↔ voz. La transcripción es lo que el conducto 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 conducto de texto estilo chat sobre toda la conversación, produciendo un archivo por idioma que los participantes pueden descargar. Este es el mismo camino de código que la traducción de chat, solo que en lotes.

El selector de idioma es una pieza de la interfaz de usuario. La infraestructura subyacente son cuatro conductos, comunicándose entre sí.

Lo que deliberadamente no intentamos

• No hay un "modelo de traducción unificado". No estamos construyendo un único modelo que haga voz, chat, notas y documentos. La compensación entre latencia y fidelidad no tiene un ganador. Usamos el motor adecuado para cada superficie.
• No hay redireccionamiento silencioso. Si la voz no puede traducir al hindi hoy, no recurrimos silenciosamente al motor de documentos y fingimos que funcionó. El hindi está oculto en el selector en ambas superficies porque el resultado en cualquiera de ellas hoy no es apto para su envío.
• No "traducimos a 200 idiomas". Nuestro motor emite 24. Nuestro producto se distribuye en 21 en las superficies en vivo y 30 en documentos. El número mayor, amigable para el marketing, es solo el límite del motor. El número del producto es lo que realmente cumple el estándar frente a un auditor.

Pruébelo usted mismo

• /demo — ejecuta el conducto de voz en vivo contra su audio, en cualquiera de los 21 idiomas del producto. El mismo conducto que puntúa /benchmark.
• /benchmark — calidad por par, por mes en tráfico real. Incluye los pares que ocultamos deliberadamente del selector, con enlaces directos.
• /benchmark/methodology — qué son los números, qué no son, quién es el juez.

Cuatro conductos, cuatro motores, una sala de reuniones. Ese es el reemplazo honesto para la antigua página cómo-funciona.

— El equipo de Mind.com