Por dentro dos quatro pipelines de tradução que fazem a InterMIND funcionar

A antiga página /product/overview/how-it-works no mind.com está desatualizada em várias versões principais. Ela descreve um único "mecanismo de tradução" da forma como a maioria das páginas de fornecedores faz — uma grande seta de "você fala" para "eles ouvem". Essa imagem já era uma simplificação há dois anos. Hoje ela está errada.

Na verdade, a InterMIND executa quatro pipelines de tradução separados, cada um resolvendo um problema diferente com um mecanismo diferente, um orçamento de latência diferente e um envelope de qualidade diferente. Eles compartilham um seletor de idioma. Eles não compartilham um mecanismo.

Esta é a resposta atualizada para "como funciona".

Um texto complementar: "Quantos idiomas vocês suportam?" aborda o que cada pipeline cobre (23 / 23 / 30 / 17). Este post aborda o que cada pipeline faz — e por que cada um é único.

Por que "um mecanismo para tudo" é uma mentira

Uma plataforma de reuniões em tempo real tem pelo menos quatro tarefas para realizar ao mesmo tempo, e elas puxam em direções incompatíveis:

1. Voz em tempo real — áudio entra, áudio traduzido sai, em menos de um segundo, cada espectador no seu próprio idioma. A restrição rígida é a latência.
2. Texto de chat em tempo real — mensagens curtas, rápidas, com edições, citações e estrutura HTML preservadas.
3. Notas compartilhadas em tempo real — digitação colaborativa caractere por caractere, com hierarquia estrutural (listas, títulos, caixas de seleção) que precisa sobreviver à tradução.
4. Arquivos de documentos assíncronos — um PDF de 40 páginas enviado no chat. Sem orçamento de latência. A restrição rígida é a fidelidade — formatação, tabelas, números de página, fonte.

Você pode criar uma única chamada gigante de LLM que tenta fazer as quatro coisas. Tentamos. O resultado é ruim nas quatro. O orçamento de latência da voz significa que o modelo não pode "pensar"; o orçamento de fidelidade dos documentos significa que ele precisa pensar. Uma edição de chat precisa de um diff no idioma do espectador; um PDF de 40 páginas precisa de preservação de formato que nenhum modelo de streaming de tokens oferece.

Por isso, executamos quatro. Aqui está cada um deles.

Pipeline 1: tradução de voz em tempo real

O problema: Um participante fala francês. Outro participante entrou falando alemão, um terceiro em português brasileiro, um quarto em japonês. Cada um precisa ouvir quem está falando no seu próprio idioma, no seu próprio ouvido, com um atraso curto o suficiente para manter o contato visual possível.

O orçamento: Abaixo de um segundo, de ponta a ponta. Depois de aproximadamente 1,2 segundo, a conversa quebra — as pessoas começam a falar sobre a tradução, e a reunião vai deslizando para "vamos simplesmente mudar para o inglês".

Como o áudio realmente se move

Algumas coisas que valem a pena destacar explicitamente:

• O ASR é executado no navegador de quem está falando, não em um servidor central. Usamos o Mind SDK localmente; isso economiza uma ida e volta e nos dá a transcrição no idioma de origem com o menor atraso possível antes que a tradução possa até começar.
• A tradução não é um único fan-out. Mantemos um pool de conexões WebSocket com nosso mecanismo de tradução, uma por idioma de destino presente na sala. Se três participantes escolheram alemão, o alemão compartilha uma conexão. Se ninguém escolheu árabe, nenhuma conexão de árabe é aberta. O pool encerra conexões inativas após cinco minutos. É por isso que uma reunião com quatro idiomas custa o mesmo que uma reunião com quarenta idiomas, até o ponto de quem realmente compareceu — nunca traduzimos para idiomas que nenhum participante está ouvindo.
• A fala sintetizada é individual, por espectador. Cada participante recebe sua própria faixa de áudio traduzida, mixada com o vídeo original de quem está falando. Eles não estão assistindo a uma "reunião traduzida" mestre — estão assistindo à mesma reunião, com seu canal de áudio pessoal traduzido para o idioma escolhido. É por isso que duas pessoas na mesma sala física podem, cada uma, conectar fones de ouvido e escutar idiomas diferentes.

Por que isso importa quando uma reunião sai do controle

Em uma chamada de 60 minutos com oito idiomas, as coisas quebram de formas interessantes: WebSockets caem, o ASR transcreve incorretamente um nome próprio por um momento, a rede de um participante fica instável. A arquitetura descrita acima é o que nos permite isolar falhas: uma falha no áudio de um espectador não afeta os outros sete, porque o mecanismo de tradução nunca produziu "a tradução" — ele produziu oito, em paralelo, e apenas a afetada precisa se recuperar.

O mecanismo em si é nosso, hospedado em nossa própria infraestrutura. Não roteamos voz em tempo real por LLMs genéricos de terceiros. O orçamento de latência os descarta; a questão da residência de dados os descarta para os clientes regulados que realmente se importam com isso.

O que publicamos sobre a qualidade da voz: /benchmark executa o pipeline de voz em produção contra frases do FLORES-200 para cada par de idiomas publicado, mensalmente. O avaliador é identificado (Gemini 3.7 Flash como principal, Claude Sonnet 5 como substituto). A distribuição completa — mediana, p10, p90, mínimo, máximo, tamanho da amostra — está na página. Veja a metodologia para entender o que esses números medem e o que não medem.

Pipeline 2: tradução de chat em tempo real

O problema: Cada mensagem de chat na reunião, traduzida para cada participante no seu próprio idioma, no momento em que é enviada. Além das edições — e as edições precisam parecer edições, não retraduções.

O orçamento: Rápido, mas não abaixo de um segundo. Uma mensagem de chat pode levar meio segundo para aparecer em outro idioma sem que ninguém se importe. O que importa é se a tradução está correta e se as edições fazem sentido.

O que o pipeline de chat realmente faz

Cada mensagem passa pelo mesmo mecanismo de tradução usado pelo pipeline de voz — mas com pré e pós-processamento diferentes:

• A estrutura HTML é preservada. O chat suporta texto formatado (parágrafos, listas, citações, negrito, itálico). Convertemos para texto simples para o modelo, traduzimos e depois envolvemos novamente o resultado nas tags originais. O modelo nunca vê o HTML — ele vê apenas o texto limpo.
• As citações são traduzidas de forma independente. Se você responde a uma mensagem e a cita, o bloco [QUOTE]…[/QUOTE] e o novo conteúdo são traduzidos como unidades separadas, para que o modelo não confunda os dois.
• Mensagens longas são divididas em blocos. Dividimos nos limites de parágrafo, a 1.000 caracteres por bloco. Cada bloco é sua própria chamada de tradução. Não enviamos "romances" de 4.000 caracteres para o modelo de uma só vez — os modos de falha (truncamento, parágrafos perdidos, cortes no meio da frase) são feios demais.
• A tradução é lazy (sob demanda). Usamos um IntersectionObserver: uma mensagem só é traduzida quando entra na área visível da tela do espectador. Antes, trocar de idioma em um canal com histórico longo repetia todas as chamadas de tradução da API. Agora, não repete mais.

A parte interessante: edições como diffs

Na v1.2, mudamos como as edições de chat se comportam para espectadores em outro idioma. O comportamento antigo era: alguém edita uma mensagem, retraduzimos tudo, e você vê um parágrafo novo e precisa identificar o que mudou.

O novo comportamento:

1. A mensagem original já havia sido traduzida para o seu idioma.
2. Quando quem enviou edita, retraduzimos a nova versão.
3. Calculamos o diff entre sua tradução anterior e sua nova tradução, no seu idioma.
4. Mostramos esse diff diretamente no texto — da mesma forma que o Git mostra o que mudou.

Então, quando "revisar até terça" se torna "revisar até quinta" em inglês, seu colega que lê em espanhol vê martes → jueves destacado, e não um parágrafo retraduzido que precisa reler.

Isso exigiu tratar o pipeline de chat como um cache stateful por espectador, e não como um endpoint stateless de tradução por solicitação. Documentos e voz não precisam disso. O chat precisa.

Pipeline 3: tradução de notas compartilhadas em tempo real

O problema: O host abre um painel de notas compartilhadas e começa a digitar. Cada participante vê as notas no seu idioma, caractere por caractere, com a estrutura do documento — títulos, listas aninhadas, checklists, blocos de código — intacta.

O orçamento: O mesmo do chat (~meio segundo), mas com duas restrições extras:

• O conteúdo sendo traduzido muda no meio da tradução. O host ainda está digitando. Um sistema ingênuo que traduz "o documento inteiro" a cada tecla produz flicker e consome o orçamento de API. Traduzimos na granularidade da unidade alterada, não do documento inteiro.
• A estrutura precisa sobreviver. Se você pede a um modelo de tradução para traduzir um bloco de markdown com três listas aninhadas, o resultado parece com o original, mas com hierarquia sutilmente achatada, itens renumerados ou indentação deslocada. Não deixamos o modelo ver o bloco inteiro.

Como o pipeline de notas difere do chat

A preservação estrutural é o ponto principal. Traduzimos cada item de lista de forma independente, em vez de como um documento único. O modelo vê:

"Revisão de conformidade — entregáveis do T2"

— e não:

"# Plano do projeto\n## Trimestre\n- Revisão de conformidade — entregáveis do T2\n- Pontuação de fornecedores\n - Fornecedores de Nível 1..."

O documento que envolve tudo — o <ul>, os títulos, a indentação — é reconstruído no lado do cliente usando a mesma estrutura que o documento original tinha, com cada nó folha substituído pela sua tradução. O modelo nunca chega a "melhorar" a hierarquia.

As notas também usam o mesmo modelo de diff por espectador que as edições de chat: se o host muda uma linha, espectadores em outros idiomas veem as palavras alteradas destacadas, não um parágrafo novo.

Pipeline 4: tradução assíncrona de documentos

O problema: Alguém envia um PDF de 40 páginas, um documento do Word, uma apresentação do PowerPoint ou uma planilha do Excel no chat. Cada participante pode solicitar uma cópia no seu próprio idioma. O arquivo traduzido precisa parecer com o original — mesmas fontes, mesmas tabelas, mesmos números de página, mesmos cabeçalhos, mesmos gráficos no lugar.

O orçamento: Sem restrição de tempo real. Um minuto é aceitável. Dois minutos são aceitáveis. A restrição é a fidelidade — se o PDF traduzido não parecer com o original, o destinatário não vai confiar nele.

Por que esse pipeline não compartilha um mecanismo com a voz

Um LLM genérico, mesmo um muito bom, devolve o texto traduzido de um documento. Ele não devolve um PDF traduzido com o mesmo layout. O modelo não tem noção de "quebra de página que precisa se alinhar com a fonte" ou "célula de tabela que precisa manter a largura da coluna".

Para essa superfície, usamos diretamente a DeepL Document API. Ela foi construída especificamente para traduzir arquivos como arquivos, não prosa extraída de arquivos. A DeepL lida com:

• PDF (com preservação de layout)
• DOCX, DOC
• PPTX
• XLSX

O documento é enviado ao pipeline da DeepL, traduzido no servidor com a formatação intacta e devolvido no mesmo formato. Em seguida, enviamos o resultado para nosso armazenamento de objetos e o exibimos novamente no chat como um anexo para download.

Quanto isso custa e por que não escondemos isso

A DeepL cobra um mínimo de 50.000 caracteres por documento — aproximadamente um dólar americano por arquivo no plano Pro, independentemente de o documento ter uma página ou trinta. Absorvemos esse custo em vez de cobrar por arquivo; ele aparece no uso de tradução da reunião como caracteres cobrados, convertidos em unidades de palavra que correspondem à forma como o resto do produto reporta a atividade de tradução.

Escolhemos a DeepL para essa superfície porque traduzir arquivos como arquivos é exatamente a tarefa para a qual ela foi construída — não tentamos construir algo melhor. O contrário não é verdade — a DeepL não executa um pipeline de voz em tempo real do tipo que construímos para reuniões. Problemas diferentes; ferramentas diferentes. A versão honesta de "o que impulsiona a tradução da InterMIND" é "o mecanismo certo para cada pipeline" — não "nosso mecanismo, em todo lugar".

Idiomas que esse pipeline cobre e a voz não cobre

O pipeline de documentos alcança 30 idiomas, contra 23 para voz. Os extras incluem: búlgaro, grego, estoniano, indonésio, lituano, letão, eslovaco, esloveno. (O árabe também está nessa lista, e é um dos extras: ele foi retirado do seletor em tempo real enquanto a qualidade da voz estiver abaixo do nosso padrão, e suas pontuações por par ficam públicas em /benchmark — esse número é o que o traz de volta. A assimetria vai na direção contrária para o hindi — disponível na voz, ainda não nos arquivos.)

Essa assimetria é real. Ela significa que um participante francês em uma reunião pode solicitar o PDF do contrato em estoniano, mesmo sem poder ouvir a reunião em estoniano. Sinalizamos isso no seletor em vez de suavizar com um único número. O raciocínio está no post sobre contagem de idiomas.

Onde os pipelines se encontram

Os quatro pipelines não funcionam isoladamente. Uma sala de reunião é onde eles se encontram, e as costuras entre eles importam:

• Uma mensagem de chat com um anexo de documento aciona o pipeline de chat para o texto e o pipeline de documentos para o arquivo. O participante em outro idioma vê a mensagem traduzida imediatamente e a tradução do anexo chegando de forma assíncrona, como um download.
• Uma nota compartilhada que cita uma linha da transcrição cruza notas ↔ voz. A transcrição é o que o pipeline de voz produziu para o idioma de quem falou; a tradução da nota produz, para cada espectador, uma cópia dessa citação no idioma de todos os outros, com a atribuição de origem preservada.
• Uma transcrição exportada após a reunião executa o pipeline de texto no estilo do chat sobre a conversa completa, produzindo um arquivo por idioma que os participantes podem baixar. É o mesmo caminho de código da tradução de chat, apenas em lote.

O seletor de idioma é uma única peça de UI. A infraestrutura por baixo é composta por quatro pipelines, conversando entre si.

O que deliberadamente não tentamos fazer

• Nenhum "modelo de tradução unificado". Não estamos construindo um único modelo que faça voz, chat, notas e documentos. O trade-off entre latência e fidelidade não tem um vencedor. Usamos o mecanismo certo para cada superfície.
• Nenhum redirecionamento silencioso. Se o pipeline de arquivos não conseguir traduzir para o hindi hoje, não recorremos silenciosamente ao mecanismo de voz e fingimos que funcionou — o seletor de arquivos sinaliza a lacuna em vez de escondê-la.
• Nenhum "nós traduzimos para 200 idiomas". Nosso mecanismo emite 24. As superfícies em tempo real entregam 23, os documentos entregam 30 — e, em vez de um único número amigável para marketing, a qualidade por par que precisa se sustentar diante de um auditor é publicada em /benchmark, incluindo os pares mais fracos.

Experimente você mesmo

• Experimente a demonstração ao vivo — executa o pipeline de voz em tempo real com seu áudio, em qualquer um dos 23 idiomas do produto. O mesmo pipeline que pontua em /benchmark.
• Veja o benchmark — qualidade por par, por mês, com tráfego real. Todo par no seletor, forte ou fraco, com link direto.
• Leia a metodologia — o que os números são, o que não são, e quem é o avaliador.

Quatro pipelines, quatro mecanismos, uma sala de reunião. Essa é a substituição honesta para a antiga página how-it-works.

— A equipe da Mind.com

Fontes: DeepL — idiomas suportados, DeepL — contagem de uso e cobrança (o mínimo de 50.000 caracteres por arquivo), FLORES-200; fatos internos dos pipelines verificados em relação ao código em produção, checados em agosto de 2026.