Prompting em Diferentes Idiomas: Como Obter Resultados Consistentes

O prompting multilíngue não é tradução — ativa uma parte diferente da distribuição aprendida do modelo. Os LLMs tokenizam e representam o texto em um espaço de embedding comum, mas os dados de treinamento são muito enviesados: o CommonCrawl (usado para treinar a maioria dos LLMs) consiste em ~46% de inglês, ~6% de alemão, ~5% de francês, ~3% de chinês. Idiomas com menos de 1% de participação no treinamento se comportam de forma imprevisível.

Quando você faz prompting em português, o modelo se apoia em padrões dos dados de treinamento em português. Como o português representa apenas ~3% do corpus de treinamento, o modelo tem significativamente menos associações aprendidas em comparação com os prompts em inglês. Isso se manifesta em: menor precisão de raciocínio, seguimento de instruções inconsistente, taxas de alucinação mais altas e qualidade de saída imprevisível.

O desempenho dos idiomas nos LLMs segue uma hierarquia de quatro níveis baseada na participação no treinamento. O nível 1 (inglês) alcança resultados quase perfeitos; o nível 4 (idiomas com poucos recursos) produz saídas pouco confiáveis. Use o mapeamento de níveis para determinar a estratégia correta para o seu idioma-alvo.

O mesmo texto de 1.000 palavras custa 46% mais em tokens em árabe do que em inglês e 31% mais em russo — isso impacta diretamente sua fatura da API. A eficiência de tokens varia significativamente de acordo com o sistema de escrita e a família de idiomas.

Para tarefas de raciocínio e estruturadas, os prompts de sistema em inglês superam os prompts de sistema no idioma-alvo em idiomas de nível 2 e nível 3. Para tom e formalidade, as instruções no idioma-alvo são superiores. Esta é a decisão mais importante no prompting multilíngue.

Por quê? A maior parte da capacidade de seguimento de instruções dos LLMs foi treinada em dados RLHF (Reinforcement Learning from Human Feedback) em inglês. As instruções de sistema complexas (regras de formato, personas, diretivas Chain-of-Thought) são seguidas de forma mais confiável quando escritas em inglês.

Árvore de decisão: Regras de raciocínio/formato complexas → prompt de sistema em inglês. Registro de formalidade (você, vous, keigo) → idioma-alvo. Definição de persona → inglês + um exemplo no idioma-alvo. Especificação do idioma de saída → sempre explícita no prompt de sistema: "Respond in formal Brazilian Portuguese (tratamento de você)."

Prompt ruim — assume que o modelo reconhecerá o idioma e o registro:

"Resuma este contrato em português."

Resultado: saída misturada em português e inglês, registro informal, terminologia jurídica faltando.

Prompt bom — idioma, registro e caminho de raciocínio explícitos:

"You are a legal analyst. The following document is a Brazilian employment contract (contrato de trabalho). Summarise its key obligations in formal Brazilian Portuguese (tratamento de você). Structure: Partes do contrato, Remuneração, Prazos de aviso prévio, Cláusulas especiais. Maximum 200 words. Flag any clause that is unusual for standard Brazilian employment law with REVISAR."

Resultado: saída formal em português estruturada com terminologia específica do domínio e anomalias marcadas.

Nenhum modelo individual domina todos os idiomas. Mistral Large 2 lidera em idiomas românicos; Google Gemini 3.0 Pro em idiomas do Leste Asiático; GPT-5.5 em árabe e tarefas de raciocínio multilíngue.

As diferenças de custo de tokens se refletem diretamente em sua fatura da API. Aqui o impacto real baseado nos preços do GPT-5.5 (5 USD por milhão de tokens de entrada).

Para idiomas de nível 3, especificar a instrução Chain-of-Thought em inglês — ao mesmo tempo que se solicita a resposta final no idioma-alvo — melhora a precisão do raciocínio entre 5 e 12% (Shi et al., 2023). Esta técnica de CoT entre idiomas aproveita os pontos fortes de raciocínio do modelo em inglês, mantendo a qualidade de saída no idioma-alvo.

Modelo: `Think through this step by step in English, then write your final answer in Brazilian Portuguese. Question: pergunta`

Decisão: Usar CoT em inglês quando → a tarefa requer raciocínio em múltiplas etapas, o idioma-alvo é de nível 3+, a precisão é mais importante que a latência. Usar CoT nativo quando → o tom e o registro importam mais que a profundidade do raciocínio, o idioma-alvo é de nível 1–2.

Os exemplos few-shot devem estar no mesmo idioma que a tarefa — exemplos entre idiomas reduzem a precisão de saída em idiomas de nível 2 e nível 3 entre 15 e 20% (Shi et al., 2023). Os exemplos few-shot ensinam ao modelo o formato, o tom e os padrões. Se os exemplos estão em inglês, mas a tarefa está em português, o modelo recebe sinais contraditórios.

Duas estratégias: (1) Few-shot nativo — todos os exemplos no idioma-alvo (melhor qualidade). (2) Zero-shot + instruções explícitas — sem exemplos, mas com regras claras de estilo/formato em inglês (melhor opção quando não há exemplos nativos disponíveis). Evite: exemplos em inglês + tarefa em português = o pior dos dois mundos.

Os LLMs usam registros informais por padrão na maioria dos idiomas. Se o seu caso de uso exige português formal (tratamento de você), japonês formal (丁寧語) ou o francês com vous, você deve declarar o registro explicitamente no prompt de sistema — o modelo não deduz isso do contexto. Isso é frequentemente ignorado e produz saídas que soam incorretas para os falantes nativos.

Quando os usuários misturam idiomas (por exemplo, uma pergunta em português com um nome de marca em inglês ou um comentário de código em inglês), a maioria dos modelos responde no idioma dominante da solicitação — mas isso não é confiável sem instruções explícitas.

Abordagem recomendada: (1) No prompt de sistema: "Quando o usuário misturar idiomas, responda em idioma-alvo a menos que a pergunta esteja explicitamente em inglês." (2) Detecte o idioma programaticamente (langdetect, FastText, lingua-rs) antes de rotear para o modelo — não dependa de que o modelo o detecte. (3) Para apps multilíngues em produção: implemente uma etapa de detecção de idioma antes da chamada ao LLM.

Quatro padrões de modelo que você pode adaptar para seus próprios fluxos de trabalho multilíngues. Substitua os marcadores de posição conforme o seu caso de uso.

Brasil (LGPD / ANPD): A Lei Geral de Proteção de Dados (Lei nº 13.709/2018) e as diretrizes da ANPD (Autoridade Nacional de Proteção de Dados) exigem base legal para o processamento de dados pessoais por sistemas de IA. Ao processar dados de usuários brasileiros, sua API de LLMs deve ter um DPA (Data Processing Agreement) ou equivalente. Para conteúdo sensível, recomenda-se o processamento local. Os modelos que oferecem residência de dados no Brasil ou na América Latina são preferíveis para dados pessoais.

União Europeia (RGPD): Ao processar dados em alemão, francês, português europeu ou outros idiomas da UE, sua API de LLMs deve cumprir o Artigo 28 do RGPD (Acordo de Tratamento de Dados). Mistral Large 2 e Claude Opus 4.8 oferecem implantações conformes com a UE.

Japão (APPI): As empresas japonesas que usam LLMs multilíngues devem cumprir a Lei de Proteção de Informações Pessoais (APPI). Para soberania total de dados, recomenda-se o uso local de Qwen 3 72B para tarefas em japonês e chinês.