Por que a Precisão da Extração em Vários Idiomas Está Caindo?
3 Cenários e Correções Específicas

O padrão é sempre o mesmo: você testa em documentos em inglês, obtém resultados que parecem mágica, depois muda para a sua mistura real de documentos — notas fiscais de fornecedores de três países, etiquetas de envio com endereços em dois alfabetos, contratos que alternam de idioma no meio da cláusula — e a precisão cai. Não de forma catastrófica, mas o suficiente para você começar a se perguntar se a ferramenta realmente funciona.

Ela funciona. A questão é o que você está pedindo para ela fazer. Uma única nota fiscal em inglês é uma entrada uniforme: um idioma, um alfabeto, uma direção de leitura. Uma nota fiscal alemã com itens em francês e condições de pagamento em espanhol não é a mesma categoria de problema — e a precisão reflete isso. Entender qual dos três cenários distintos você está enfrentando é a diferença entre saber o que corrigir e culpar a coisa errada.

Este guia aborda os três cenários mais comuns de queda de precisão, como identificar qual deles está acontecendo com seus documentos e o que fazer em cada caso. Para uma visão geral mais ampla de como a IA de visão lida com vários idiomas no nível arquitetônico, veja a IA consegue ler vários idiomas em um único documento — este artigo assume esse conhecimento prévio e foca no lado da solução de problemas.

Cenário 1: Documento Único, Vários Idiomas

Esta é a causa mais comum de queda de precisão, e geralmente os usuários não percebem que estão lidando com ela. Seu documento está "em alemão" — mas o cabeçalho está em inglês (nome e endereço da empresa), os itens misturam descrições de produtos em alemão com nomes de ingredientes em francês, e o rodapé contém cláusulas legais no idioma que o departamento jurídico escolheu no último trimestre.

A maioria dos modelos de IA de visão processa a página inteira como um único contexto visual. Eles não "alternam de idioma" como o OCR tradicional faz — eles leem tudo de uma vez e identificam o alfabeto de cada caractere como parte da mesma etapa de inferência. Isso é uma vantagem sobre mecanismos de OCR que exigem um pacote de idioma pré-selecionado, mas cria um problema sutil: quando textos em diferentes idiomas aparecem no mesmo campo visual, a confiança do modelo nos caracteres cai porque ele precisa resolver simultaneamente os limites entre alfabetos, caracteres especiais (é, ü, ñ, ß) e formatos de letras dependentes do contexto.

Aqui está o que acontece na prática em uma única nota fiscal multilíngue:

• Cabeçalho em inglês (nome da empresa, endereço) — 96% de precisão. O modelo está em seu regime mais forte.
• Corpo em alemão (descrições de itens com Umlauts, moeda "€", formato de data alemão) — 88–91% de precisão. Umlauts (ä, ö, ü) são omitidos ou substituídos; "14.03.2026" é confundido com o formato inglês "03/14/2026".
• Itens em francês (caracteres acentuados: é, è, ê, œ) — 85–88% de precisão. Acentos em linhas com glifos mistos acumulam erros; uma palavra como "générique" vira "generique" ou "g6n6rique".
• Condições de pagamento em espanhol (ñ e pontuação invertida) — 82–87% de precisão. O modelo já gastou seu orçamento de resolução de caracteres nas seções em alemão e francês quando chega ao rodapé.

Esses não são números de pior caso. Eles são típicos para um documento que alterna entre três idiomas de alfabeto latino — todos compartilhando o mesmo alfabeto, mas divergindo em caracteres especiais, formatos de data e notações de moeda.

Diagnóstico: Se a precisão por campo varia dentro do mesmo documento — datas sendo mais confiáveis que nomes de fornecedores, ou números limpos enquanto caracteres acentuados estão corrompidos — você provavelmente está no Cenário 1.

Correção: Use Extração Personalizada de Colunas em vez de OCR de página inteira. Ao definir colunas de saída específicas (como "Nome do Fornecedor", "Data da Fatura", "Valor Total"), a IA foca em encontrar esses valores por significado semântico, em vez de tentar processar cada caractere da página igualmente. Uma coluna chamada "Valor Total (EUR)" instrui o modelo a procurar um número próximo a um símbolo de moeda, independentemente de o texto ao redor estar em alemão, francês ou espanhol. Para um aprofundamento sobre como a extração baseada em colunas funciona em diferentes tipos de documento, veja como a extração de documentos por IA funciona e por que a definição de colunas é importante.

Cenário 2: Diferenças de Escrita — Latina vs. CJK vs. Árabe

É aqui que a precisão ultrapassa a linha de "irritante" para "quebra de fluxo de trabalho". Uma fatura em inglês é extraída com 96% de precisão e uma fatura em japonês com 82% — não porque o documento japonês seja de qualidade inferior, mas porque as famílias de escrita são fundamentalmente diferentes em como desafiam os modelos de visão.

Escritas latinas (inglês, francês, alemão, espanhol, português, italiano, holandês) compartilham um alfabeto de 26 caracteres, direção de leitura da esquerda para a direita e abundantes dados de treinamento. São um problema resolvido para a IA de visão moderna — a precisão em texto latino impresso e limpo atinge consistentemente 95–99%.

Escritas CJK (chinês, japonês, coreano) são um nível diferente de dificuldade. Uma única frase em japonês pode conter Kanji (milhares de caracteres de origem chinesa), Hiragana (46 caracteres fonéticos), Katakana (46 caracteres fonéticos para palavras estrangeiras), caracteres latinos para termos em inglês e numerais arábicos — tudo em uma linha. O mesmo conteúdo semântico em japonês consome aproximadamente 2× os tokens de seu equivalente em inglês, o que significa que o modelo preenche sua janela de contexto mais rápido em documentos CJK e tem menos informação disponível por campo. Para um exemplo prático desse problema de densidade, veja nossa cobertura sobre extração de dados de recibos japoneses para Excel.

O árabe e o hebraico adicionam o desafio da direção da direita para a esquerda. O modelo deve detectar que a direção de leitura se inverte, aplicá-la corretamente por bloco de texto e lidar com as formas de letras de quatro posições do árabe (uma letra muda de forma dependendo se aparece no início, meio, fim ou isoladamente em uma palavra). A precisão em documentos árabes impressos varia de 75 a 85% — não porque o modelo seja fraco em caracteres árabes especificamente, mas porque as convenções tipográficas RTL criam um problema de análise visual diferente do das escritas da esquerda para a direita.

Diagnóstico: Se seus documentos em inglês são extraídos com 95%+ de precisão e documentos não latinos consistentemente ficam 10–20% abaixo — em diferentes documentos, não apenas um — você está no Cenário 2.

Solução: Duas abordagens funcionam aqui. Primeiro, verifique se a ferramenta oferece suporte ao idioma do script específico que você está processando. Nem todas as ferramentas que afirmam ter "suporte a mais de 100 idiomas" são treinadas igualmente em todos os scripts. Alguns modelos de visão são treinados desproporcionalmente em dados latinos, com CJK e árabe adicionados como um corpus secundário menor. Pergunte especificamente se os dados de treinamento do modelo incluem a família de scripts que você precisa. Segundo, teste com uma amostra representativa dos seus documentos reais, não com as imagens de demonstração da ferramenta. A fatura de demonstração de um fornecedor em japonês será uma imagem limpa, criada digitalmente, com contraste perfeito — sua fatura japonesa digitalizada de 2019, com um carimbo desbotado sobre o nome do fornecedor, é um problema de reconhecimento muito diferente.

Cenário 3: Scripts Misturados no Mesmo Campo

Este é o caso mais difícil — e aquele que a maioria das documentações ignora. Um único campo no seu documento contém caracteres de múltiplos scripts. Um número de peça como "ABC-1234-안전밸브" (letras inglesas, numerais arábicos, Hangul coreano). Um campo de nome de fornecedor que exibe "株式会社Yamada (Osaka Branch)". Um campo de data escrito como "2026年03月14日" — numerais arábicos inseridos em texto CJK.

Modelos de visão lidam com campos de scripts misturados reconhecendo cada cluster de caracteres de forma independente e montando-os em uma string coerente. Mas esse processo introduz vários modos de falha específicos para cenários de scripts misturados:

• Detecção incorreta de limites de script: O modelo julga incorretamente onde um script termina e outro começa. Um caractere Hangul coreano que se assemelha visualmente a um ideograma CJK pode ser classificado no grupo de script errado, fazendo com que os caracteres seguintes sejam analisados com o contexto de reconhecimento errado.
• Substituição de caracteres: Caracteres visualmente semelhantes entre scripts são trocados. A letra latina "A", a cirílica "А" e a grega "Α" são visualmente quase idênticas, mas são caracteres Unicode diferentes. Um código de produto que contém o "A" latino pode ser gerado como o "А" cirílico — visualmente idêntico, semanticamente errado e indetectável em uma verificação rápida porque parece correto.
• Confusão de direção em campos LTR/RTL misturados: Um nome de empresa em árabe seguido por um número de registro em inglês entre parênteses cria uma string bidirecional que o modelo deve ordenar corretamente. A saída como "(ABC-1234 شركة") em vez de "شركة (ABC-1234)" é comum — ambos os caracteres estão presentes, mas a ordem de leitura está invertida.

Diagnóstico: Se seus dados extraídos parecem visualmente plausíveis, mas falham contra uma referência conhecida — um número de peça que parece ter todos os caracteres corretos, mas não corresponde ao seu ERP, ou um nome de fornecedor que passa por uma olhada humana, mas causa uma falha de consulta — o Cenário 3 é a causa provável.

Solução: O pré-processamento com dicas de idioma reduz significativamente os erros de scripts misturados. Embora a maioria dos modelos de visão detecte o idioma automaticamente, ancorar explicitamente o contexto de extração ajuda. Em ferramentas que suportam isso, passar uma dica como "o idioma principal deste documento é coreano com códigos de produto em inglês incorporados" diz ao modelo para esperar limites de script em vez de tratá-los como erros de reconhecimento. Para campos onde a precisão é crítica — IDs fiscais, números de peça, códigos de registro — a validação por verificação pontual por idioma é a salvaguarda mais confiável: extraia os dados e, em seguida, verifique a parte não latina separadamente da parte latina. Se você tiver um banco de dados de referência (ERP, CRM, lista de fornecedores), o cruzamento dos valores extraídos detecta erros de substituição de caracteres que nenhuma inspeção visual encontrará.

Como diagnosticar em qual cenário você está

Ao notar queda de precisão em documentos multilíngues, faça este diagnóstico de três perguntas antes de alterar qualquer outra coisa:

1. A queda de precisão é consistente entre idiomas, mas no mesmo documento? Se seus campos em inglês estão sempre limpos e os campos em francês/com trema estão consistentemente degradados no mesmo documento → Cenário 1. Tente extração por coluna com definições semânticas de campo.
2. A queda é consistente em documentos inteiros por família de idioma? Se todo documento em japonês extrai pior que todo documento em inglês, independentemente do conteúdo → Cenário 2. Verifique a cobertura dos dados de treinamento da ferramenta para o script específico.
3. A queda é específica para certos campos com conteúdo de script misto? Se nomes de fornecedores estão ok, mas números de peça com Kanji ou Árabe embutidos são propensos a erros → Cenário 3. Adicione dicas de idioma no pré-processamento e implemente referência cruzada por campo.

Esses três cenários geralmente se sobrepõem — um documento pode conter vários idiomas (Cenário 1) em diferentes scripts (Cenário 2) com campos de script misto (Cenário 3) na mesma página. A pergunta diagnóstica indica qual camada corrigir primeiro, pois corrigir a camada errada desperdiça tempo. Se você está no Cenário 2, nenhum refinamento de coluna (correção do Cenário 1) recuperará a lacuna de precisão — o modelo precisa de cobertura de treinamento diferente, não de um prompt melhor.

Prevenção: Três hábitos que reduzem quedas de precisão multilíngue

Depois de identificar seu cenário, estas práticas evitam que o mesmo problema se repita em novos tipos de documento e idiomas:

1. Separe documentos por família de script quando possível. Se você processa 200 faturas diariamente — 150 em idiomas de script latino e 50 em CJK — agrupá-las separadamente fornece duas linhas de base de precisão independentes. Você sabe que a extração em script latino opera acima de 95% e CJK em 82%. Se um lote CJK cair subitamente para 70%, você percebe imediatamente. Misturados em um lote, a média geral pode cair de 93% para 90% e ninguém escala.

2. Mantenha amostras de verificação por idioma. Escolha 5 a 10 documentos representativos para cada família de idioma que você processa. Toda vez que atualizar seu fluxo de extração ou trocar de ferramenta, execute o conjunto de verificação e compare a precisão por idioma. Isso detecta regressões antes que cheguem à produção. Uma ferramenta que melhorou a precisão do latim em 2% mas degradou a precisão do CJK em 8% não é uma melhoria líquida para um fluxo multilíngue.

3. Use limites de confiança em nível de campo que variam por idioma. Não aplique a mesma regra "aceitar se confiança > 90%" para campos em inglês e árabe do mesmo documento. Um limite de 90% de confiança em inglês pode ser muito restritivo (tudo passa), enquanto o mesmo limite em árabe pode rejeitar toda extração. Defina limites por idioma com base nos resultados de sua amostra de verificação — Árabe 75%, Latino 90%, CJK 80% — e encaminhe qualquer valor abaixo do limite para revisão manual, em vez de aceitá-lo silenciosamente.

Quando Escalar — O Que Ainda Exige Tratamento Manual

Honestidade é mais importante aqui do que em qualquer outra parte deste artigo. O Vision AI é notavelmente capaz em vários idiomas, mas existem condições de contorno onde nenhum ajuste de prompt ou pré-processamento conseguirá fechar a lacuna de precisão para níveis de produção.

• Documentos com quatro ou mais idiomas de diferentes famílias de escrita. Um documento que contém inglês (latino), árabe (RTL), japonês (CJK vertical + horizontal) e coreano (CJK horizontal) — todos na mesma página — está no limite das capacidades atuais dos modelos de visão. Espere uma queda de 5 a 15% na precisão em relação à linha de base de um único idioma.
• Mistura RTL/LTR na mesma frase ou célula de tabela. Quando árabe e inglês aparecem na mesma linha com uma relação parentética (ex.: "البند (Item) 4.2" em uma cláusula contratual), a análise bidirecional cria erros estruturais que as dicas de pré-processamento corrigem apenas parcialmente.
• Conteúdo manuscrito em escrita não latina. A caligrafia por si só reduz a precisão em 15–30% em comparação com texto impresso. Adicione um segundo idioma — numerais árabes manuscritos em japonês manuscrito — e o efeito composto coloca a maioria das extrações abaixo dos limites utilizáveis. Esses documentos ainda se beneficiam da extração por IA para as partes impressas, mas os campos manuscritos devem ser direcionados para entrada manual como fluxo de trabalho padrão, não como exceção.
• Pares de idiomas de baixos recursos. Tailandês/Árabe, Suaíli/Cirílico, Birmanês/Inglês — pares onde nenhum dos idiomas é individualmente de altos recursos para treinamento de modelos de visão. O piso de precisão para esses documentos é menor do que para pares bem cobertos como Inglês/Espanhol ou Inglês/Chinês.

O fluxo de trabalho prático: a extração por IA lida automaticamente com 80–90% dos dados multilíngues. Os 10–20% restantes — campos de alto risco em documentos com escrita mista, campos numéricos críticos em texto misto RTL/LTR e entradas manuscritas não latinas — são encaminhados para uma etapa de revisão humana que é mais rápida do que a entrada manual completa e mais confiável do que confiar na IA nos casos mais difíceis.

Perguntas Frequentes

Por que minha ferramenta de extração de IA funciona bem em faturas em inglês, mas pior em alemão ou francês?

Este é tipicamente o Cenário 1. O documento em inglês é uma entrada em um único idioma, sem ambiguidade de script. O documento em alemão ou francês provavelmente contém caracteres especiais (Umlauts, acentos) que o modelo de visão trata como variações de letras latinas padrão — e essas variações têm menor confiança porque aparecem com menos frequência nos dados de treinamento do que caracteres sem acento. A diferença de precisão entre o inglês e outros idiomas de script latino é geralmente de 5 a 8% — perceptível, mas corrigível com extração baseada em colunas que foca o modelo em campos específicos, em vez de OCR de página inteira.

Posso melhorar a precisão da extração em vários idiomas convertendo os documentos para um único idioma primeiro?

Não é confiável. A tradução automática antes da extração introduz uma camada de erro separada — você está extraindo de texto traduzido, que pode perder rótulos de campos, formatos numéricos e a estrutura do documento. O documento original contém o layout e os dados pretendidos pelo autor. A extração funciona melhor quando lê o original, não uma versão traduzida. A melhor abordagem é extrair do documento original usando definições semânticas de colunas e, em seguida, validar os dados extraídos contra o idioma que seu sistema downstream exigir.

A IA precisa saber quais idiomas estão no documento antes de processá-lo?

Não para detecção — modelos de visão modernos detectam scripts e idiomas automaticamente como parte da leitura da página. Mas sim para contexto — se seu documento contiver uma combinação de idiomas rara ou campos com scripts mistos, fornecer uma dica de idioma (por exemplo, "este documento contém coreano e inglês com numerais arábicos incorporados") melhora a precisão em 3 a 7% nas partes do idioma secundário, pois o modelo aloca recursos de reconhecimento de forma mais eficiente.

Qual a diferença de precisão esperada entre documentos em alfabeto latino e CJK usando a mesma ferramenta?

Para documentos impressos limpos de qualidade similar, espere que a precisão CJK seja 8–15% menor que a precisão latina na mesma ferramenta. Isso não é um problema de qualidade da ferramenta — reflete a diferença fundamental no inventário de caracteres (26 vs milhares), consumo de tokens (2× por unidade semântica) e volume de dados de treinamento. Uma ferramenta com 97% de acerto em inglês que obtém 83% em japonês está performando dentro do normal para o estado atual da IA de visão.

Devo usar ferramentas de extração de IA diferentes para idiomas diferentes?

Se sua combinação de documentos abrange múltiplas famílias de escrita (não apenas múltiplos idiomas dentro da mesma família), você pode obter maior precisão por idioma usando ferramentas otimizadas para scripts regionais específicos. O PaddleOCR, por exemplo, performa melhor em documentos CJK do que modelos de visão de uso geral porque seus dados de treinamento são focados em CJK. No entanto, gerenciar múltiplas ferramentas introduz complexidade no fluxo de trabalho que pode superar o ganho de precisão para a maioria das equipes. Uma abordagem que funciona bem: use uma ferramenta de IA de visão de uso geral como extrator principal para todos os idiomas, depois direcione documentos em scripts específicos para mecanismos especializados de fallback apenas quando a confiança da ferramenta principal cair abaixo do limite.

A queda de precisão entre um único documento em alfabeto latino e um documento multilíngue não é uma falha da tecnologia — é uma lacuna previsível, diagnosticável e amplamente corrigível. Comece com a pergunta diagnóstica, aplique a correção para o cenário encontrado e reserve a revisão manual para os casos extremos onde os modelos de visão atuais ainda estão aprendendo. Teste em seus próprios documentos multilíngues e veja qual cenário se aplica ao seu fluxo de trabalho.