Detector de Idioma com IA

Sobre o Detector de Idioma com IA

Nosso Detector de Idioma com IA usa aprendizado de máquina avançado para identificar automaticamente o idioma de qualquer texto. Alimentado por modelos de linguagem de última geração executados diretamente no seu navegador, ele pode detectar mais de 20 idiomas com alta precisão e pontuações de confiança.

A ferramenta analisa seu texto usando IA e fornece não apenas o idioma principal, mas também possibilidades alternativas com percentuais de confiança. Tudo é executado localmente no seu navegador usando Transformers.js, então seu texto permanece completamente privado e nunca deixa seu dispositivo.

Este detector de idioma envia meu texto para algum servidor?

Não. O Detector de Idioma com IA roda 100% no seu navegador, usando um modelo compacto estatístico ou neural carregado via WebAssembly. Seu texto nunca é enviado, registrado ou compartilhado com terceiros — você pode verificar abrindo o DevTools, indo na aba Network e confirmando que nenhuma requisição sai ao clicar em Detectar. Isso torna a ferramenta segura para e-mails confidenciais, rascunhos vazados, provas jurídicas ou qualquer conteúdo privado em que você só precisa saber o idioma. O modelo é baixado uma única vez no primeiro uso e fica em cache local, então detecções seguintes são instantâneas e totalmente offline.

Qual modelo de identificação de idioma é usado?

O backbone padrão é uma adaptação do FastText lid.176 do Facebook ou um híbrido n-grama + transformer equivalente hospedado no Hugging Face (ex.: facebook/fasttext-language-identification ou papluca/xlm-roberta-base-language-detection). O FastText lid.176 cobre 176 idiomas com um modelo minúsculo de 130 MB e supera 95% de precisão em texto da Wikipedia e Common Crawl. As variantes XLM-RoBERTa cobrem cerca de 20 idiomas de alto recurso e ultrapassam 99% em entradas longas. A ferramenta escolhe o FastText menor por padrão para equilibrar privacidade e velocidade, exibindo os 3 melhores candidatos com probabilidades para você notar casos mistos ou limítrofes.

Qual o tamanho mínimo do texto para uma detecção precisa?

A precisão depende muito do comprimento. Com 5 palavras ou menos, identificar o idioma é genuinamente difícil — strings curtas como "hello world" ou nomes próprios são ambíguas até para humanos. O FastText lid.176 atinge cerca de 70% de precisão com 10 caracteres, 85% com 50 e 95% acima de 200. Abaixo de 20 caracteres, o modelo costuma confundir parentes próximos como espanhol vs português, norueguês vs dinamarquês ou indonésio vs malaio. Para melhores resultados, cole pelo menos uma frase inteira (50 a 100 caracteres). Se a entrada precisar ser curta, observe a lista dos 3 mais prováveis em vez de confiar na melhor única — quando as duas primeiras probabilidades estão a menos de 10 pontos, trate a predição como incerta.

Ele consegue detectar documentos com vários idiomas misturados num mesmo parágrafo?

O classificador padrão de rótulo único devolve apenas o idioma dominante de toda a entrada, o que é certo para parágrafos monolíngues mas enganoso em alternância de código. Para texto misto, mude para o modo por frase: a entrada é dividida pela pontuação e cada frase é detectada de forma independente. É basicamente como funcionam ferramentas linha a linha como o CLD3 (Compact Language Detector v3 do Google). Detecção real de code-switching em nível de token exige um modelo de rotulação de sequência treinado em corpora bilíngues (LinCE, MULTI-CONER), mais pesado e não incluído por padrão. Para conteúdo bilíngue gerado pelo usuário, o modo por frase captura a maioria das trocas.

Por que ele às vezes erra com chinês, japonês e coreano?

A detecção CJK é especialmente difícil porque kanji japoneses e hanzi chineses compartilham milhares de caracteres, e Hanja coreano aparece em textos formais. Heurísticas puramente por caractere funcionam para hiragana, katakana e hangul (exclusivos de cada idioma), mas texto dominado por caracteres chineses pode ser ambíguo. O FastText lid.176 observa n-gramas de caractere e fronteiras de palavra e chega a ~97% em cada idioma CJK individualmente com entrada suficiente, mas uma frase curta em japonês escrita só com kanji pode ser confundida com chinês. Acrescentar apenas um caractere hiragana ou katakana inclina decisivamente para japonês, então entradas mais longas quase sempre são resolvidas corretamente.

Qual a diferença entre FastText e um detector tipo XLM-RoBERTa?

O FastText representa cada palavra como um saco de n-gramas de caractere e os agrega num classificador linear raso — é essencialmente uma regressão logística sobre traços subpalavra, o que o mantém minúsculo (menos de 200 MB) e extremamente rápido (milhões de palavras por segundo em CPU). O XLM-RoBERTa é um transformer completo de 270M parâmetros pré-treinado em 100 idiomas e ajustado para ID de idioma; é bem mais lento (cerca de 100x por token) e ocupa 3 GB no disco, mas captura pistas contextuais que o FastText perde, como ordem das palavras, sintaxe e empréstimos raros. Para detecção no navegador de parágrafos, FastText é o padrão certo — o teto de precisão em texto real já fica perto de 99% e a economia de banda é enorme.

Posso rodar o detector com aceleração WebGPU?

O próprio FastText não se beneficia de GPU porque seu laço interno é dominado por buscas em hashtables esparsas e aritmética inteira, em que CPU/WASM já é ótimo. Detectores baseados em transformer (XLM-RoBERTa, Bert-base-multilingual) ganham muito — em WebGPU, detectar em lote 100 textos curtos cai de cerca de 8 segundos (WASM CPU) para menos de 1 segundo (GPU integrada). O Transformers.js seleciona automaticamente o backend WebGPU no Chrome 113+ e Edge quando disponível, e do contrário usa WebAssembly com SIMD. Para a maioria, FastText em WASM é a melhor escolha; troque para WebGPU + transformer só se precisar de precisão máxima em entradas longas e tiver um navegador recente.

Por que o detector retorna códigos ISO 639-1 como "en" em vez de "Inglês"?

ISO 639-1 é o padrão de códigos de duas letras mantido pela Biblioteca do Congresso dos EUA e usado por praticamente todo framework de internacionalização (Content-Language HTTP, atributo lang HTML, Unicode CLDR, API de locale do navegador). É conciso, inequívoco e amigável a máquinas — "zh" sempre é chinês, "ja" sempre é japonês, independentemente do idioma em que o app está renderizado. Para idiomas sem código 639-1 (ex.: cebuano, siciliano), o modelo recorre ao ISO 639-3 (três letras: "ceb", "scn"). A ferramenta exibe o código e o nome legível na língua da sua UI. Se você só precisa do rótulo humano, a saída JSON inclui os dois campos.