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

A antiga página /product/overview/how-it-works no mind.com está várias versões importantes desatualizada. Ela descreve um único "motor de tradução" do jeito que a maioria das páginas de fornecedores faz — uma grande seta de "você fala" para "eles ouvem". Esse retrato já era uma simplificação há dois anos. Hoje está errado.

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 texto complementar: "Quantos idiomas vocês suportam?" cobre o que cada pipeline abrange (24 / 22 / 30 / 12). Este post cobre o que cada pipeline faz — e por que cada um é uma coisa em si.

Por que "um motor para tudo" é mentira

Uma plataforma de reunião ao vivo tem pelo menos quatro tarefas para fazer 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 em seu próprio idioma. A restrição dura é 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 largado no chat. Sem orçamento de latência. A restrição dura é fidelidade — formatação, tabelas, números de página, fonte.

Você pode construir uma única chamada gigante de LLM que tenta fazer as quatro coisas. Nós tentamos. Ela é ruim em todas as 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 o modelo 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 entrega.

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 entrou em alemão, um terceiro em português brasileiro, um quarto em japonês. Cada um precisa ouvir o falante 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: Abaixo de um segundo, ponta a ponta. Acima de ~1,2 segundo a conversa quebra — as pessoas começam a falar por cima da tradução e a reunião deriva para "vamos só mudar para inglês".

Como o áudio realmente se move

Algumas coisas que vale a pena nomear explicitamente:

• O ASR roda no navegador do falante, não em um servidor central. Usamos o Mind SDK localmente; isso economiza um round-trip e nos dá a transcrição no 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 escolheram alemão, o alemão compartilha uma conexão. Se ninguém escolheu árabe, nenhuma conexão de árabe é aberta. O pool descarta conexões ociosas 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 que nenhum participante está ouvindo.
• A fala sintetizada é por espectador. Cada participante recebe sua própria faixa de áudio traduzida, mixada contra o vídeo original do falante. 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 que escolheram. É 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 temporariamente transcreve mal um nome próprio, a rede de um participante fica instável. A arquitetura acima é o que nos permite isolar falhas: a falha de áudio de um espectador 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 a afetada precisa se recuperar.

O motor em si é nosso, hospedado em nossa própria infraestrutura. Não roteamos voz em tempo real através 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 de fato se importam.

O que publicamos sobre qualidade de voz: /benchmark roda o pipeline de voz em produção contra sentenças do FLORES-200 para cada par de idiomas publicado, mensalmente. O juiz é nomeado (Gemini 2.5 Flash primário, Claude Sonnet 4 fallback). 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. Mais edições — e 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 ninguém se importar. O que as pessoas se importam é 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 motor de tradução que o pipeline de voz usa — mas com pré e pós-processamento diferentes:

• A estrutura HTML é preservada. O chat suporta texto rico (parágrafos, listas, citações, negrito, itálico). Convertemos para texto puro para o modelo, traduzimos e depois reembalamos o resultado nas tags originais. O modelo nunca vê o HTML — ele vê prosa limpa.
• Citações são traduzidas independentemente. 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 possa confundir os dois.
• Mensagens longas são divididas em pedaços. Dividimos em fronteiras de parágrafo a cada 1.000 caracteres por pedaço. Cada pedaço é sua própria chamada de tradução. Não alimentamos o modelo com romances de 4.000 caracteres de uma vez só — os modos de falha (truncamento, parágrafos perdidos, cortes no meio da frase) são feios demais.
• A tradução é preguiçosa. Usamos um IntersectionObserver: uma mensagem só é traduzida quando rola para o viewport do espectador. Trocar de idioma em um canal de longa duração costumava reproduzir cada chamada da API de tradução do histórico. Agora não faz 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, você vê um parágrafo novo e tem que detectar o que mudou.

O novo comportamento:

1. A mensagem original já estava traduzida para o seu idioma.
2. Quando o remetente 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 inline — do mesmo jeito que o Git mostra o que mudou.

Então quando "review by Tuesday" vira "review by Thursday" em inglês, sua colega que lê em espanhol vê martes → jueves destacado, não um parágrafo retraduzido que ela tem que reler.

Isso exigiu tratar o pipeline de chat como um cache com estado por espectador, não um endpoint sem estado de traduzir-sob-demanda. Documentos e voz não precisam disso. Chat precisa.

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

O problema: O anfitrião 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 — 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:

• A coisa sendo traduzida muda no meio da tradução. O anfitrião ainda está digitando. Um sistema ingênuo que traduz "o documento inteiro" a cada tecla produz flicker e queima o orçamento de API. Traduzimos na granularidade da unidade alterada, não do documento inteiro.
• A estrutura precisa sobreviver. Se você pedir a um modelo de tradução para traduzir um blob de markdown com três listas aninhadas, você recebe de volta algo que parece o original mas com hierarquia sutilmente achatada, 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 coisa principal. Traduzimos cada item da lista independentemente em vez de como um documento. O modelo vê:

"Revisão de conformidade — entregas do Q2"

— e não:

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

O documento envolvente — a <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 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 espectador que as edições de chat: se o anfitrião 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 larga 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 pedir uma cópia em seu próprio idioma. O arquivo traduzido precisa parecer 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á bom. Dois minutos está bom. A restrição é fidelidade — se o PDF traduzido não parece o original, o destinatário não vai confiar nele.

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

Um LLM de propósito geral, mesmo um muito bom, vai te devolver um texto traduzido de um documento. Ele não vai te devolver um PDF traduzido com o mesmo layout. O modelo não tem 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 API de documentos do DeepL diretamente. Ela é construída especificamente para traduzir arquivos como arquivos, não prosa extraída de arquivos. O DeepL lida com:

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

O documento é enviado para o pipeline do DeepL, traduzido server-side com formatação intacta, e retornado no mesmo formato. Em seguida, fazemos upload do resultado para nosso armazenamento de objetos e o disponibilizamos de volta no chat como um anexo para download.

Quanto isso custa e por que não escondemos

O 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 faturados, convertidos em unidades de palavras que correspondem ao modo como o resto do produto reporta atividade de tradução.

Escolhemos o DeepL para esta superfície porque é o melhor motor da categoria para tradução de documentos especificamente. Não fingimos ter construído um melhor. O mesmo não é verdade no sentido oposto — o 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 alimenta 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 22 da voz. Os extras incluem: búlgaro, grego, estoniano, indonésio, lituano, letão, norueguês Bokmål, eslovaco, esloveno — mais árabe, que escondemos do seletor em tempo real porque a qualidade de voz não passa do nosso patamar mas que o DeepL lida bem como documentos.

Essa assimetria é real. Significa que um participante francês em uma reunião pode pedir o PDF do contrato em estoniano mesmo que ele não possa ouvir a reunião em estoniano. Sinalizamos isso no seletor em vez de mascarar com um único número. O raciocínio está no post sobre a 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 junções importam:

• Uma mensagem de chat com um documento anexado dispara 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 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 espectador dessa citação no idioma de cada um dos outros, com sua atribuição de origem preservada.
• Uma transcrição exportada após a reunião roda o pipeline de texto estilo chat sobre a conversa completa, produzindo um arquivo por idioma que os participantes podem baixar. Esse é o mesmo caminho de código da tradução de chat, só que em lote.

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

O que 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 entre latência e fidelidade não tem vencedor. Usamos o motor certo por superfície.
• Nenhum reroteamento silencioso. Se a voz não consegue traduzir para hindi hoje, não voltamos silenciosamente para o motor de documentos e fingimos que funcionou. O hindi fica escondido do seletor em ambas as superfícies porque o resultado em qualquer uma das superfícies hoje não é entregável.
• Nenhum "traduzimos para 200 idiomas". Nosso motor emite 24. Nosso produto entrega 22 nas superfícies ao vivo e 30 em documentos. O número maior, amigável para marketing, é só o teto do motor. O número do produto é o que de fato passa no critério diante de um auditor.

Experimente você mesmo

• /demo — roda o pipeline de voz ao vivo contra seu áudio, em qualquer um dos 22 idiomas do produto. O mesmo pipeline que pontua o /benchmark.
• /benchmark — qualidade por par, por mês, em tráfego real. Inclui os pares que deliberadamente escondemos do seletor, com deep-link.
• /benchmark/methodology — 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. Essa é a substituição honesta para a antiga página how-it-works.

— The Mind.com Team