Você envia um chatbot para a sua equipa alemã. A interface do usuário é alemã. Os documentos de origem são parcialmente em alemão e parcialmente em inglês. As ferramentas por detrás do assistente esperam valores de enum em inglês, descrições de funções em inglês, nomes de produtos em inglês, tudo em inglês.
Depois, alguém faz uma pergunta perfeitamente normal em alemão, o modelo escolhe a ferramenta correta, passa um argumento em alemão em vez de inglês e tudo se desmorona silenciosamente.
Já vi versões disto vezes suficientes e já não penso nisto como um problema de tradução. **É um problema de execução.
O meu padrão atual é simples: deixar os utilizadores falarem a língua que quiserem, mas deixar o LLM fazer a sua recuperação, raciocínio e trabalho de ferramenta em inglês sempre que a fiabilidade for realmente importante. Depois, localizar a resposta fora desse ciclo.
Isto parece um pouco herético à primeira vista. Mas é também, na minha opinião, a coisa mais prática que se pode fazer neste momento.
A pesquisa está a começar a dizer isto em voz alta
Os números já não são subtis.
No [MASSIVE-Agents benchmark] (https://aclanthology.org/2025.findings-emnlp.1099/), os investigadores avaliaram a chamada de funções multilingues em 52 línguas, 47.020 amostras e 21 modelos. A melhor pontuação média em todas as línguas foi de apenas 34,05%. O inglês atingiu 57,37%. O amárico desceu para 6,81%.
Isto não é uma pequena oscilação de qualidade. É um abismo de fiabilidade.
Depois, há o [Lost in Execution] (https://arxiv.org/abs/2601.05366), que se aproxima ainda mais do problema dos sistemas reais. O documento mostra que muitas falhas na chamada de ferramentas multilingues acontecem depois de o modelo já ter compreendido a intenção e selecionado a ferramenta correta. A questão dominante era a incompatibilidade linguística do valor dos parâmetros. Em termos simples, o modelo sabia o que fazer, mas expressou os bits executáveis na língua do utilizador em vez da língua da interface, pelo que a chamada falhou na mesma.
E isto não se limita à chamada de ferramentas. Em [Do Multilingual Language Models Think Better in English?] (https://aclanthology.org/2024.naacl-short.46/), Etxaniz e colegas descobriram que a auto-tradução para inglês superava consistentemente a inferência direta em língua não inglesa em cinco tarefas. A sua formulação é refrescantemente direta: os modelos são "incapazes de aproveitar todo o seu potencial multilingue quando solicitados em línguas que não o inglês".
Portanto, sim, os modelos multilingues são impressionantes. Mas se a sua fasquia não for "soa muito bem" mas sim "deve comportar-se corretamente na produção", o inglês continua a parecer a língua de trabalho mais segura com uma frequência notável.
Porque é que o RAG quebra no mesmo sítio
As pessoas normalmente ouvem este argumento e pensam primeiro em agentes. Chamada de função, saída estruturada, execução de API, esse tipo de coisa.
O RAG tem a mesma fraqueza, apenas uma camada antes.
Se a sua camada de recuperação tiver de fazer corresponder a fraseologia local de um utilizador ao conteúdo escrito em idiomas mistos, com terminologia inconsistente, nomes de produtos traduzidos e etiquetas de taxonomia semi-localizadas, cria mais hipóteses de o sistema se desviar antes mesmo de a geração começar. Honestamente, é daqui que vêm muitas das queixas "o modelo não é fiável". O modelo pode ser bom. A interface de conteúdo não é.
Eu prefiro normalizar cedo.
Traduzir a pergunta para inglês. Recuperar a partir de um corpus canónico inglês. Deixar o modelo raciocinar sobre uma camada terminológica estável. Gerar um rascunho de resposta em inglês, se necessário. Em seguida, traduzir ou localizar a resposta final para o utilizador.
Isto dá-lhe um local onde a nomenclatura se mantém estável:
- um título de documento canónico
- um vocabulário de produto canónico
- um esquema de ferramenta canónico
- um conjunto canónico de etiquetas de recuperação
Continua a ser possível suportar todas as línguas do utilizador no exterior. Basta deixar de exigir que o percurso de execução principal seja perfeitamente multilingue em cada etapa.
Isto não é anti-localização
Muito pelo contrário.
Uma má arquitetura de IA multilingue prejudica normalmente os utilizadores locais em primeiro lugar. Estes obtêm uma interface localizada agradável, mas depois o sistema oculto centrado no inglês comporta-se de forma inconsistente e fá-los pagar o preço.
Uma localização correta significa ser honesto sobre onde a linguagem deve ser flexível e onde não deve.
Para mim, a divisão é a seguinte:
- Localizar a interface do utilizador, os avisos, o texto de ajuda, a integração e as respostas finais.
- Localizar o conteúdo de origem que as pessoas lêem diretamente quando esse conteúdo tem de existir no mercado.
- Mantenha as definições internas da ferramenta, os identificadores canónicos, as etiquetas de recuperação e os pivôs de raciocínio em inglês, se essa for a camada mais estável.
- Adicionar pós-processamento explícito ou revisão humana quando um resultado localizado tiver peso legal, regulamentar ou contratual.
Este último ponto é mais importante do que as equipas gostam de admitir. Se o modelo estiver a falar com um ser humano, a localização é uma decisão de experiência do utilizador. Se o modelo está a falar com outro sistema, a linguagem é um contrato de interface.
Não são a mesma coisa.
A arquitetura em que mais confio neste momento
Esta é a versão em que eu apostaria atualmente para produtos de IA multilingues:
- O utilizador pergunta na sua língua.
- O sistema traduz ou normaliza o pedido para inglês.
- A recuperação, o raciocínio, a classificação e as chamadas de ferramentas ocorrem em relação aos dados canónicos em inglês.
- A resposta final é localizada de volta para a língua do utilizador.
- Os resultados de alto risco recebem uma etapa de validação adicional antes de saírem do sistema.
Não é filosoficamente puro. É operacionalmente sensato.
O que é bom é que a investigação recente aponta na mesma direção. A [Lost in Execution] (https://arxiv.org/abs/2601.05366) descobriu que a pré-tradução das consultas dos utilizadores reduzia geralmente os erros de incompatibilidade linguística melhor do que as correcções post-hoc, mesmo que ainda não recuperasse totalmente o desempenho ao nível do inglês. Isto corresponde ao que muitos construtores já suspeitam na prática. Se esperar até ao fim para eliminar as incoerências multilingues, normalmente é demasiado tarde.
E sim, há excepções. Se estiver a construir para línguas com poucos recursos, para uma linguagem específica de um domínio ou para um fraseado culturalmente dependente, traduzir tudo para inglês pode introduzir desvios. O documento acima referido alerta explicitamente para esse facto. Por isso, não transforme isto num dogma.
Mas como padrão para co-pilotos de empresas, assistentes internos, RAG multilingues e agentes utilizadores de ferramentas, penso que a regra se mantém surpreendentemente bem.
O que isto significa para o Rasepi
É exatamente por isto que me preocupo tanto com a estrutura canónica do conteúdo.
Se a sua base de conhecimento tiver uma camada de fonte limpa, terminologia estável e localização controlada no topo, a IA torna-se mais fácil de confiar. Se cada versão linguística se desviar independentemente dentro do caminho de execução, está a pedir ao modelo para improvisar onde o seu sistema deve ser preciso.
Toda a abordagem do Rasepi é construída em torno de separar essas preocupações de forma limpa. Manter um núcleo canónico. Localizar deliberadamente. Rastrear onde existem variantes. Não finja que todas as camadas da pilha devem ser igualmente multilíngues só porque a interface do usuário é.
Eu costumava pensar que a melhor experiência de IA multilingue significava "fazer tudo na língua do utilizador". Já não penso assim. Não para sistemas que têm de obter o parágrafo certo, escolher a ferramenta certa e devolver algo em que se possa confiar.
A regra prática é simples: os utilizadores devem permanecer locais, mas o caminho de execução do LLM deve permanecer estável. Atualmente, isso significa geralmente inglês no meio e localização nas extremidades.
Isso vai mudar com o tempo. Espero que mude rapidamente. Mas, se estiver a fazer envios hoje e a fiabilidade for mais importante do que a estética, eu deixaria o modelo pensar em inglês e deixaria o seu produto falar a língua do utilizador.