Por dentro dos quatro pipelines de tradução que rodam o InterMIND

A antiga página /product/overview/how-it-works no mind.com está desatualizada há vários lançamentos importantes. Ela descreve um único "motor de tradução" da forma que a maioria das páginas de fornecedores faz — uma grande seta de "você fala" para "eles ouvem". Essa imagem já era uma simplificação dois anos atrás. Hoje, ela está errada.

A verdade é que o InterMIND roda quatro pipelines de tradução separados, cada um resolvendo um problema diferente com um motor 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 motor.

Esta é a resposta atualizada para "como funciona".

Um artigo complementar: "Quantos idiomas vocês suportam?" aborda o que cada pipeline cobre (24 / 24 / 30 / 17). Este post aborda o que cada pipeline faz — e por que ele é algo à parte.

Por que "um motor para tudo" é uma mentira

Uma plataforma de reuniões ao vivo tem pelo menos quatro tarefas a fazer simultaneamente, e elas puxam em direções incompatíveis:

1. Voz em tempo real — áudio entra, áudio traduzido sai, em menos de um segundo, cada participante no seu próprio idioma. A restrição difícil é 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, cabeçalhos, caixas de seleção) que precisa sobreviver à tradução.
4. Arquivos de documentos assíncronos — um PDF de 40 páginas solto no chat. Sem orçamento de latência. A restrição difícil é a fidelidade — formatação, tabelas, números de página, fonte.

Você pode construir uma chamada LLM gigante que tenta fazer as quatro coisas. Nós tentamos. Ela é ruim nas quatro. O orçamento de latência para voz significa que o modelo não pode pensar; o orçamento de fidelidade para documentos significa que o modelo tem que pensar. Uma edição de chat precisa de um diff no idioma do visualizador; um PDF de 40 páginas precisa de preservação de formato que nenhum modelo de streaming de tokens oferece.

Então rodamos quatro. Aqui está cada um.

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

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

O orçamento: Menos de um segundo de ponta a ponta. Qualquer coisa além de ~1,2 segundos e a conversa quebra — as pessoas começam a falar por cima da tradução, e a reunião deriva para "vamos mudar para inglês".

Como o áudio se move realmente

Algumas coisas valem a pena nomear explicitamente:

• O ASR roda no navegador do palestrante, não em um servidor central. Usamos o Mind SDK localmente; isso economiza uma viagem de ida e volta e nos dá a transcrição do idioma de origem com o menor atraso possível antes que a tradução possa sequer começar.
• A tradução não é um único fan-out. Mantemos um pool de conexões WebSocket para o nosso motor de tradução, uma por idioma de destino presente na sala. Se três participantes escolherem alemão, o alemão compartilha uma conexão. Se ninguém escolheu árabe, nenhuma conexão em árabe é aberta. O pool descarta conexões inativas após cinco minutos. É por isso que uma reunião de quatro idiomas custa o mesmo que uma reunião de quarenta idiomas até o ponto de quem realmente apareceu — nunca traduzimos para idiomas em que nenhum participante está ouvindo.
• A fala sintetizada é por visualizador. Cada participante recebe sua própria faixa de áudio traduzida, misturada com o vídeo do palestrante original. Eles não estão assistindo a uma "reunião traduzida" principal — eles 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 colocar fones de ouvido e ouvir idiomas diferentes.

Por que isso importa quando uma reunião dá errado

Em uma chamada de 60 minutos com oito idiomas, as coisas quebram de maneiras interessantes: WebSockets caem, o ASR transcreve temporariamente um nome próprio de forma errada, a rede de um participante fica instável. A arquitetura acima é o que nos permite isolar falhas: o áudio de um visualizador falhando não afeta os outros sete, porque o motor de tradução nunca produziu "a tradução" em primeiro lugar — ele produziu oito, em paralelo, e apenas o afetado precisa se recuperar.

O motor em si é nosso, hospedado em nossa própria infraestrutura. Não roteamos voz em tempo real por meio de LLMs de propósito geral de terceiros. O orçamento de latência os descarta; a história de residência de dados os descarta para os clientes regulados que realmente se importam.

O que publicamos sobre a qualidade da voz: O /benchmark roda o pipeline de voz de produção contra as frases do FLORES-200 para cada par de idiomas publicado, mensalmente. O juiz é nomeado (Gemini 2.5 Flash principal, Claude Sonnet 4 como reserva). A distribuição completa — mediana, p10, p90, mínimo, máximo, tamanho da amostra — está na página. Veja a metodologia para 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 em seu próprio idioma, conforme é enviada. Além de edições — e as edições precisam parecer edições, não re-traduções.

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

O que o pipeline de chat realmente faz

Cada mensagem passa pelo mesmo motor de tradução que o pipeline de voz usa — mas com diferentes pré e pós-processamentos:

• A estrutura HTML é preservada. O chat suporta rich text (parágrafos, listas, citações, negrito, itálico). Convertemos para texto simples para o modelo, traduzimos e, em seguida, re-envolvemos o resultado nas tags originais. O modelo nunca vê o HTML — ele vê texto limpo.
• As citações são traduzidas independentemente. Se você responder a uma mensagem e citá-la, o bloco [QUOTE]…[/QUOTE] e o novo conteúdo são traduzidos como unidades separadas, então o modelo não pode confundir os dois.
• Mensagens longas são fragmentadas. Dividimos nos limites dos parágrafos em 1.000 caracteres por fragmento. Cada fragmento é sua própria chamada de tradução. Nós não alimentamos 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 é preguiçosa (lazy). Usamos um IntersectionObserver: uma mensagem só é traduzida quando ela rola para dentro da viewport do visualizador. Mudar de idioma em um canal de longa duração costumava reproduzir todas as chamadas de API de tradução do histórico. Agora não mais.

A parte interessante: edições como diffs

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

O novo comportamento:

1. A mensagem original já estava traduzida para o seu idioma.
2. Quando o remetente edita, nós traduzimos 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 inline — da mesma forma que o Git mostra a você o que mudou.

Então, quando "review by Tuesday" se torna "review by Thursday" em inglês, seu colega que lê em espanhol vê martes → jueves destacado, não um parágrafo traduzido novamente que ele tem que reler.

Isso exigiu tratar o pipeline de chat como um cache stateful por visualizador, não um endpoint stateless de tradução sob 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 organizador abre um painel de notas compartilhadas e começa a digitar. Cada participante vê as notas em seu idioma, caractere por caractere, com a estrutura do documento — cabeçalhos, listas aninhadas, listas de verificação, blocos de código — intacta.

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

• A coisa sendo traduzida muda durante a tradução. O organizador ainda está digitando. Um sistema ingênuo que traduz "o documento inteiro" a cada tecla pressionada produz cintilação e queima o orçamento da API. Traduzimos na granularidade da unidade alterada, não do documento inteiro.
• A estrutura deve sobreviver. Se você pedir a um modelo de tradução para traduzir um blob markdown com três listas aninhadas, você recebe de volta algo que parece com o original, mas com hierarquia sutilmente nivelada, itens renumerados ou indentação movida. Não deixamos o modelo ver o blob inteiro.

Como o pipeline de notas difere do chat

A preservação estrutural é a principal coisa. Traduzimos cada item da lista independentemente em vez de como um único documento. O modelo vê:

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

— e não:

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

O documento encapsulador — o <ul>, os cabeçalhos, a indentação — é reconstruído no lado do cliente usando a mesma estrutura que o documento original tinha, com cada nó folha trocado por sua tradução. O modelo nunca tem a chance de "melhorar" a hierarquia.

As notas também usam o mesmo modelo de diff por visualizador das edições do chat: se o organizador mudar uma linha, os visualizadores em outros idiomas veem as palavras alteradas destacadas, não um parágrafo novo.

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

O problema: Alguém solta 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 em seu próprio idioma. O arquivo traduzido deve 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 está bem. Dois minutos estão bem. A restrição é fidelidade — se o PDF traduzido não se parece com o original, o destinatário não confiará nele.

Por que este pipeline não compartilha um motor com a voz

Um LLM geral, mesmo um muito bom, devolverá a você um texto traduzido de um documento. Ele não devolverá a você um PDF traduzido com o mesmo layout. O modelo não tem o conceito de "quebra de página que precisa se alinhar com a fonte" ou "célula de tabela que precisa manter sua largura de coluna".

Para esta superfície, usamos a DeepL Document API diretamente. Ela é construída com o propósito de 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 é carregado para o pipeline da DeepL, traduzido no servidor com a formatação intacta e retornado no mesmo formato. Em seguida, carregamos 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

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

Escolhemos a DeepL para esta superfície porque traduzir arquivos como arquivos é exatamente o trabalho para o qual ela foi construída — não tentamos construir uma melhor. O mesmo não é verdade no sentido inverso — a DeepL não roda um pipeline de voz ao vivo do tipo que construímos para reuniões. Problemas diferentes; ferramentas diferentes. A versão honesta de "o que impulsiona a tradução do InterMIND" é "o motor certo por pipeline" — não "nosso motor, em todo lugar".

Idiomas que este pipeline cobre e a voz não

O pipeline de documentos alcança 30 idiomas, contra 24 para voz. Os extras incluem: búlgaro, grego, estoniano, indonésio, lituano, letão, eslovaco, esloveno. (O árabe costumava estar nesta lista enquanto sua qualidade de voz estava abaixo do nosso padrão; agora ele está no seletor em tempo real, com suas pontuações por par publicadas no /benchmark como qualquer outro idioma. A assimetria agora corre no sentido inverso para o hindi — ativo na voz, mas ainda não em arquivos.)

Essa assimetria é real. Isso significa que um participante francês em uma reunião pode solicitar o PDF do contrato em estoniano, mesmo que não possa 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 rodam isoladamente. Uma sala de reunião é onde eles se tocam, e as emendas importam:

• Uma mensagem de chat com um anexo de documento aciona o pipeline de chat para o texto e o pipeline de documento para o arquivo. O participante em outro idioma vê a mensagem traduzida imediatamente e a tradução do anexo chegando assincronamente como um download.
• Uma nota compartilhada que cita uma linha de transcrição cruza notas ↔ voz. A transcrição é o que o pipeline de voz produziu para o idioma do remetente; a tradução da nota produz uma cópia por visualizador daquela citação no idioma de todos os outros, com sua atribuição de origem preservada.
• Uma transcrição exportada após a reunião roda o pipeline de texto estilo de chat sobre toda a conversa, produzindo um arquivo por idioma que os participantes podem baixar. Este é o mesmo caminho de código da tradução do chat, apenas em lote.

O seletor de idioma é uma peça de UI. A infraestrutura por baixo são quatro pipelines, conversando entre si.

O que nós deliberadamente não tentamos

• Nenhum "modelo de tradução unificado". Não estamos construindo um modelo que faz voz, chat, notas e documentos. O trade-off de latência vs. fidelidade não tem um vencedor. Usamos o motor certo por superfície.
• Nenhum re-roteamento silencioso. Se o pipeline de arquivos não consegue traduzir para hindi hoje, não recorremos discretamente ao motor 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 motor emite 24. As superfícies ao vivo enviam todos os 24, documentos 30 — e em vez de um número amigável para o marketing, a qualidade por par que precisa comparecer diante de um auditor é publicada no /benchmark, incluindo os pares mais fracos.

Experimente você mesmo

• Experimente a demo ao vivo — roda o pipeline de voz ao vivo contra o seu áudio, em qualquer um dos 24 idiomas do produto. O mesmo pipeline que pontua no /benchmark.
• Veja o benchmark — qualidade por par, por mês, em tráfego real. Cada par no seletor, forte ou fraco, com deep link.
• Leia a metodologia — o que os números são, o que não são, quem é o juiz.

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

— A equipe do Mind.com

Fontes: DeepL — idiomas suportados, DeepL — contagem de uso e faturamento (o mínimo de 50.000 caracteres por arquivo), FLORES-200; fatos internos do pipeline verificados em relação ao código enviado, verificado em agosto de 2026.