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

A antiga página /product/overview/how-it-works no mind.com está desatualizada por várias versões principais. 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 executa 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 idiomas. Eles não compartilham um motor.

Esta é a resposta atualizada para "como funciona".

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

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 visualizador 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 deve sobreviver à tradução.
4. Arquivos de documentos assíncronos — um PDF de 40 páginas colocado 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 fazer 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 precisa 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, nós 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 em alemão, um terceiro em português brasileiro, um quarto em japonês. Cada um precisa ouvir o orador 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 acima 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 o inglês".

Como o áudio se move realmente

Algumas coisas valem nomear explicitamente:

• O ASR é executado no servidor de mídia. O áudio do orador viaja via WebRTC para nosso próprio motor — a Mind API na OVH, França — e é reconhecido lá, no mesmo servidor que carrega a chamada; o navegador apenas envia o áudio e recebe as palavras de volta. Nenhum fornecedor de fala separado e nenhum salto extra antes que a tradução possa começar. (Notas de voz do chat são a exceção: sua conversão de fala em texto é executada no Azure AI Speech, o serviço de fala do gateway de IA padrão.)
• A tradução não é um único fan-out. O motor traduz por idioma de destino presente na sala, não por visualizador: a tradução para um idioma começa quando o primeiro ouvinte o solicita, três participantes que escolheram alemão compartilham uma tradução em alemão, e ninguém ouvindo em árabe significa que nada é traduzido para o árabe. É 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 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, mixada com o vídeo do orador original. Eles não estão assistindo a uma "reunião traduzida" mestre — 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 conectar 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 erroneamente um nome próprio temporariamente, 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 uso geral de terceiros. O orçamento de latência os elimina; a história de residência de dados os elimina para os clientes regulados que realmente se importam.

O que publicamos sobre a qualidade da voz: /benchmark executa o pipeline de voz de produção contra as frases do FLORES-200 para cada par de idiomas publicado, mensalmente. O juiz é nomeado (Gemini 3.7 Flash primário, Claude Sonnet 5 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 menos 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 para as pessoas é 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 rich text (parágrafos, listas, citações, negrito, itálico). Convertemos para texto simples para o modelo, traduzimos e depois re-envolvemos o resultado nas tags originais. O modelo nunca vê o HTML — ele vê prosa limpa.
• 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 divididas em blocos. Nós dividimos nos limites dos parágrafos em 1.000 caracteres por bloco. Cada bloco é 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. Usamos um IntersectionObserver: uma mensagem só é traduzida quando rola para a área de visualização 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.

A parte interessante: edições como diffs

Na v1.2, mudamos 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 parágrafo novo e tem que notar o que mudou.

O novo comportamento:

1. A mensagem original já havia sido 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 o que mudou.

Então, quando "revisão até terça-feira" se torna "revisão até quinta-feira" em inglês, seu colega que lê em espanhol vê martes → jueves destacado, e 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 demanda. Documentos e voz não precisam disso. O 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 — 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 no meio da tradução. O anfitrião 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 o original, mas com hierarquia sutilmente achatada, itens renumerados ou recuo movido. 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 um documento inteiro. O modelo vê:

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

— 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 que envolve — o <ul>, os cabeçalhos, o recuo — é 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 consegue "melhorar" a hierarquia.

As notas também usam o mesmo modelo de diff por visualizador das edições de chat: se o anfitrião mudar uma linha, os visualizadores em outros idiomas veem as palavras alteradas destacadas, e 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 se 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 é a fidelidade — se o PDF traduzido não se parecer com o original, o destinatário não confiará nele.

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

Um LLM genérico, 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 deve se alinhar com a fonte" ou "célula de tabela que deve manter sua largura de coluna".

Para esta superfície, usamos a DeepL Document API diretamente. Ela é feita 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 para o pipeline da DeepL, traduzido no servidor com a formatação intacta e retornado no mesmo formato. Em seguida, carregamos o resultado em 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 ou trinta páginas. 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 executa 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" — e não "nosso motor, em todo lugar".

Idiomas que este pipeline abrange e a voz não

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á nesta lista, e é um dos extras: foi retirado do seletor em tempo real enquanto sua qualidade de voz está abaixo do nosso padrão, e suas pontuações por par permanecem públicas em /benchmark — esse número é o que o traz de volta. A assimetria corre no sentido inverso para o hindi — ativo na voz, ainda não em arquivos.)

Essa assimetria é real. 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 funcionam isoladamente. Uma sala de reunião é onde eles se tocam, e as costuras 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 da 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 fonte preservada.
• Uma transcrição exportada após a reunião executa o pipeline de texto no 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 de chat, apenas em lote.

O seletor de idiomas é uma peça de interface. 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 para cada superfície.
• Sem re-roteamento silencioso. Se o pipeline de arquivos não consegue traduzir para hindi hoje, não retornamos silenciosamente para o 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 23, documentos 30 — e em vez de um número amigável para o marketing, a qualidade por par que precisa ficar 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 ao vivo contra o 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, em tráfego real. Cada 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, 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 cobrança (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.