A linguagem de um modelo não é a linguagem de uma sociedade.

Uma interface multilingue não é justa só porque lista muitas línguas. A cobertura linguística é uma questão institucional, cultural e de segurança, e a...

A linguagem de um modelo não é a linguagem de uma sociedade.

Dezasseis línguas são um começo, não um veredicto

Em 22 de julho de 2026, a Direção-Geral da Tradução da Comissão Europeia publicou o EU MMLU, um benchmark concebido para testar grandes modelos de linguagem em contextos linguísticos e culturais europeus. O anúncio foi invulgarmente honesto quanto à lacuna que procurava colmatar. Muitos conjuntos de dados de avaliação foram construídos em inglês. Um modelo pode obter bons resultados nesses conjuntos e, ainda assim, ter um desempenho fraco em francês, húngaro ou maltês. O novo conjunto de dados começa com dezasseis línguas oficiais da UE, sete áreas temáticas e mais de mil perguntas traduzidas e revistas por quase 250 estudantes de 21 universidades europeias.

A parte mais importante desse anúncio não é a lista de línguas. É a frase que lhe está subjacente: o comportamento de um modelo não pode ser inferido a partir da língua em que parece mais fluente. Isso deveria ser óbvio. É também o pressuposto por detrás de uma quantidade notável de aquisições, investigação e conversa pública. Continuamos a falar de um modelo de linguagem como se tivesse uma única mente, e depois pedimos-lhe que vista diferentes línguas como casacos. O casaco muda. A mente, as provas, os pontos cegos e o contexto social são tratados como estáveis.

Não são estáveis. A língua é o ponto de encontro entre uma pessoa e uma instituição. Transporta os termos de um benefício, o tom de um recurso, a diferença entre conselho e instrução, a forma de uma piada, o nome de um lugar e os pressupostos de um formulário. Quando um sistema lida melhor com uma língua do que com outra, não se limita a produzir uma frase menos elegante. Pode mudar quem é compreendido, quem é acreditado, quem pode contestar um resultado e quem desiste antes de encontrar a porta certa.

A conclusão prática é simples. A IA multilingue não é uma funcionalidade de tradução a acrescentar depois de o modelo ser construído. É uma questão de acesso, provas e autoridade. O trabalho europeu em tecnologias linguísticas, dados linguísticos e avaliação multilingue é valioso porque trata o problema como infraestrutura. O trabalho ainda está incompleto. Um benchmark não é uma garantia, e dezasseis línguas não são a totalidade da Europa. Mas a direção está certa: deixar de perguntar se um modelo fala uma língua e começar a perguntar o que ele pode fazer com segurança nessa língua, para quem, em que condições e com que provas.

A cobertura linguística só é credível quando as afirmações sobre fonte, contexto, revisão e serviço permanecem ligadas.

A língua é uma fronteira de acesso

A Europa tornou a língua um facto institucional, não uma preferência privada. O artigo 22.º da Carta dos Direitos Fundamentais afirma que a União respeita a diversidade cultural, religiosa e linguística. A própria política de tecnologias linguísticas da Comissão coloca essa obrigação ao lado de um aviso prático: as tecnologias linguísticas precisam de uma utilização imparcial para que os direitos e os princípios sobrevivam ao contacto com o software. Não são compromissos decorativos. Descrevem o limite que um sistema público encontra quando um residente não consegue ler um aviso, não consegue compreender por que razão foi tomada uma decisão ou não consegue exprimir um facto relevante na língua em que esse facto existe.

Esse limite é fácil de ignorar quando uma equipa mede apenas se foi produzida uma tradução. Uma frase pode chegar na língua pedida e ainda assim falhar a pessoa que dela precisa. A tradução pode achatar uma distinção jurídica, alterar o nível de cortesia que indica se um funcionário está a perguntar ou a ordenar, ou usar um termo que tem um significado corrente mas um significado especializado num determinado serviço. Um reconhecedor de voz pode transformar uma pronúncia regional numa palavra diferente. Um resumidor pode retirar a ressalva que carrega a responsabilidade. A fluência não nos diz se a transação permaneceu intacta.

Imagine um serviço público de informação que oferece a mesma explicação de elegibilidade em neerlandês, francês e numa língua regional. As duas primeiras vias foram treinadas e testadas com material administrativo, cartas de recurso e conversas com peritos do domínio. A terceira via tem excelente prosa geral, mas nenhuma avaliação significativa sobre a terminologia própria do serviço. Um painel pode apresentar três indicadores verdes de língua. Os residentes não recebem três serviços equivalentes. Um grupo recebe uma explicação; outro recebe uma aproximação; o terceiro recebe uma incerteza polida que parece oficial porque tem o logótipo certo.

O exemplo é deliberadamente hipotético. Não é uma afirmação sobre um município ou fornecedor específico. O seu propósito é expor um erro de conceção. O apoio linguístico é muitas vezes contado na interface, enquanto a obrigação real se situa mais abaixo na cadeia. O sistema tem de saber que dados sustentam a língua, que tarefas foram avaliadas, quem reviu os erros, como os utilizadores os podem corrigir e quando a via deve recusar responder. Se esses detalhes faltarem, o seletor de língua é uma promessa sem contrato.

O mapa de um modelo não é o mapa da sociedade

Um modelo aprende a partir de um mapa da língua que os seus dados e o seu processo de treino tornam disponível. Uma sociedade vive num mapa muito maior. O mapa do modelo contém os textos, gravações, rótulos, traduções e avaliações que foram admitidos. O mapa da sociedade contém pessoas que falam de modo diferente em casa e no trabalho, mudam de registo sem o anunciar, tomam palavras emprestadas através de uma fronteira, usam uma língua minoritária numa instituição local ou escrevem numa escrita que um referencial não incluiu. Um mapa é um artefacto técnico. O outro é um arranjo de vidas, direitos e obrigações.

A diferença é importante mesmo para línguas com grandes corpora públicos. Uma língua nacional não é um fluxo uniforme. Formulários do governo, decisões judiciais, discurso em sala de aula, conselhos de saúde, mensagens de texto e uma conversa entre vizinhos usam vocabulários diferentes e tolerâncias diferentes para a ambiguidade. Um modelo pode ser competente em prosa noticiosa e fraco num recurso de prestações. Pode lidar com a ortografia padrão e ter dificuldades com um dialeto. Pode traduzir uma frase literal e não captar o significado pragmático transportado por uma fórmula cortês. Chamar apoiada a toda a língua esconde o limite da tarefa.

A tecnologia linguística precisa, portanto, de um vocabulário mais rigoroso. Devemos distinguir uma língua presente nos dados de treino de uma tarefa avaliada nessa língua. Devemos distinguir uma tradução de referência de um item de teste escrito de forma independente. Devemos distinguir a leitura de um sistema de escrita da compreensão do registo de uma comunidade. Devemos distinguir a capacidade de um sistema gerar texto da sua autoridade para aconselhar, classificar ou decidir. Cada distinção é um pequeno documento administrativo. Em conjunto, impedem que uma afirmação ampla seja construída a partir de evidências limitadas.

Há uma razão institucional para sermos rigorosos. Os serviços públicos não são livres de escolher a língua mais fácil e chamar ao resultado eficiência. Um banco, um hospital, uma entidade patronal ou um fornecedor de software podem ter obrigações legais diferentes, mas cada um decide quanta fricção uma pessoa tem de absorver para ser compreendida. Uma via multilingue que falha silenciosamente transfere o custo para o utilizador. O utilizador tem de encontrar um tradutor, repetir uma história, aceitar um resultado pior ou abandonar o processo. O sistema reporta sucesso porque devolveu uma cadeia de caracteres. A pessoa experiencia exclusão com gramática impecável.

O que significa realmente baixos recursos

Baixos recursos é frequentemente tratado como uma propriedade de uma língua, como se algumas línguas tivessem chegado à porta do modelo com menos recursos e devessem pedir desculpa pelo incómodo. É mais útil tratá-lo como uma propriedade de uma tarefa, de um conjunto de dados e de uma decisão de governação. Uma língua pode ter material literário substancial mas poucos dados anotados para um classificador médico. Pode ter texto paralelo mas quase nenhuma gravação de fala. Pode estar representada num corpus sem os direitos ou metadados necessários para uma implementação específica. Pode ter dados numa forma padrão enquanto as pessoas afetadas usam uma variedade regional.

A política de tecnologia linguística da Comissão Europeia nomeia isto claramente. Os dados linguísticos são o alicerce das ferramentas linguísticas, e a experiência humana é uma parte necessária do desenvolvimento bem-sucedido. Um modelo precisa de texto ou fala, algoritmos, computação e pessoas que compreendam a língua e o domínio. Remover qualquer um desses elementos altera o sistema. Mais computação não pode criar uma conversa em falta. Mais exemplos não podem reparar um rótulo que confunde duas categorias legais. Um modelo maior não pode decidir qual fonte uma comunidade considera autoritativa.

O trabalho com baixos recursos não é, portanto, um convite para baixar o padrão. É uma razão para tornar o padrão visível. Se uma tarefa tem pouco material de avaliação, diga-se. Se uma métrica é instável para um par de línguas, reporte-se a instabilidade. Se a revisão humana foi pequena, identifique-se o âmbito da revisão em vez de a apresentar como uma garantia geral. Se uma via é útil para rascunhos mas não para decisões, coloque-se essa fronteira onde um comprador e um utilizador a possam ver. A escassez honesta é mais segura do que um silêncio que aparenta abundância.

A paisagem linguística da Europa torna esta disciplina inevitável. A Comissão descreve um conjunto complexo de línguas oficiais, regionais e minoritárias e apoiou iniciativas como a European Language Grid, a agenda European Language Equality e o Espaço Europeu Comum de Dados Linguísticos. Estes projetos não são uma solução única e não devem ser descritos como tal. São peças de um ecossistema no qual dados, ferramentas, direitos, experiência e instituições públicas se podem encontrar. A forma institucional é tão importante quanto o modelo que contém.

A camada de direitos chega antes da referência

É tentador falar de modelos de linguagem como se a linguagem fosse um canal de entrada neutro. Não é. A entrada pode conter dados pessoais, uma característica protegida, um topónimo local, um detalhe médico ou o registo de uma pessoa a pedir ajuda. A fonte pode estar sujeita a direitos de autor ou a uma reserva. Uma saída traduzida pode ser usada numa decisão, mesmo que o percurso de tradução nunca tenha sido avaliado para esse contexto. O problema linguístico do modelo já é um problema de direitos antes de alguém escolher uma pontuação.

A orientação da Comissão sobre tecnologias linguísticas liga os dados linguísticos tanto aos direitos de autor como à proteção de dados. Essa ligação deveria mudar a forma como as equipas concebem os pipelines. Um corpus não é apenas uma pilha de frases. Tem identidade de origem, condições de aquisição, estado de licença ou de direitos, metadados de língua e de escrita, sinais de qualidade, finalidade e regras de retenção. Se um item for corrigido ou retirado, a organização precisa de saber quais os artefactos derivados que foram afetados. Caso contrário, um modelo posterior pode repetir um erro antigo com a confiança de um formulário acabado de imprimir.

É aqui que a expressão proveniência mostra o seu valor. Proveniência não é uma nota de rodapé a dizer que os dados vieram de algum lado. É o conjunto de relações que permite a um revisor ir de um resultado até à evidência relevante e voltar. Em trabalho multilingue, essas relações precisam de sobreviver à tradução, transcrição, normalização, segmentação e avaliação. Uma frase traduzida para um benchmark não é intercambiável com a frase de origem. Um rótulo feito por um revisor não é intercambiável com um rótulo herdado de outra língua. A transformação faz parte da evidência.

Não há exigência de que todos os utilizadores vejam um registo de investigação. Há uma exigência de que uma organização consiga responder a uma pergunta séria quando ela chega. Que versão do recurso linguístico foi usada? Que tarefa suportava? Que especialistas de língua a reviram? O que fez o sistema quando a confiança era baixa? Foi uma reclamação tratada como uma correção a uma resposta ou como uma possível classe de falhas? O percurso linguístico torna-se digno de confiança quando estas perguntas têm responsáveis e registos.

A Europa está a construir infraestrutura linguística, não apenas botões de tradução

A descrição da Comissão Europeia do Espaço Europeu Comum de Dados Linguísticos é útil porque não reduz o projeto a um lançamento de modelo. O objetivo é uma plataforma e um mercado para recolher, partilhar e reutilizar dados linguísticos multilingues e multimodais, mantendo ao mesmo tempo as organizações e os indivíduos que geram os dados no controlo. Essa formulação aponta para uma ideia diferente de progresso. O trabalho não é apenas produzir uma frase melhor. É tornar os recursos linguísticos detetáveis, conscientes dos direitos, reutilizáveis e responsabilizáveis na administração pública, na investigação e na indústria.

A European Language Grid deu um passo relacionado ao reunir ferramentas e recursos especializados de tecnologia linguística num catálogo comum. Um catálogo não prova que todos os serviços funcionam para todas as tarefas. Torna, no entanto, uma dependência oculta mais fácil de inspecionar. Uma equipa pode perguntar o que faz a ferramenta, que língua suporta, de onde vieram os seus dados e se a licença corresponde ao uso pretendido. Esta é infraestrutura sem glamour. É também assim que um continente com muitas instituições evita reconstruir a mesma capacidade linguística em salas desconectadas.

A infraestrutura é importante porque a cauda longa do trabalho linguístico não é resolvida por um único modelo de referência. Um organismo público pode precisar de reconhecimento de fala para um sotaque regional, extração de terminologia para um domínio especializado, memória de tradução para legislação, reconhecimento de entidades nomeadas para topónimos, ou uma forma de comparar duas versões de um documento sem perder diacríticos. Uma empresa pode precisar de uma implementação local porque o material não pode sair da sua jurisdição. Um grupo de investigação pode precisar de um conjunto de dados com proveniência clara em vez de mais uma pontuação anónima.

Há uma escolha política discreta nesta abordagem. Os dados e as ferramentas são tratados como capacidades que a Europa deve poder inspecionar e moldar, e não como um serviço que chega de um qualquer lugar invisível. Isso não significa que os sistemas europeus sejam automaticamente bons ou que os fornecedores comerciais de outras regiões não possam ser úteis. Significa que uma língua é demasiado importante para ficar sem um vocabulário público para os seus dados, as suas lacunas e a sua avaliação. A soberania começa por saber aquilo que o sistema não consegue ver.

A tradução não é um encanamento neutro

A tradução é muitas vezes colocada entre dois componentes num diagrama de arquitetura, como se fosse um tubo que transporta o significado de um lado para o outro. A tradução real é uma sequência de decisões. Qual é o texto de origem que tem autoridade? Que palavras têm de permanecer exatas? Que ambiguidade deve ser preservada? Que referência cultural precisa de uma explicação? Que registo é adequado para um aviso público? Que entidade não deve ser traduzida? Que data, número ou unidade deve ser apresentado na convenção do leitor? Um modelo pode tomar essas decisões rapidamente. A rapidez não as torna invisíveis.

Considere a diferença entre traduzir uma frase sobre o tempo e traduzir um aviso sobre um prazo. No primeiro caso, um pequeno erro de estilo pode ser irritante. No segundo, um número ou um verbo modal pode alterar aquilo que uma pessoa acredita que tem de fazer. O modelo de linguagem subjacente pode ter o mesmo orçamento de tokens e a mesma apresentação de confiança. As consequências sociais não são as mesmas. A avaliação deve, portanto, seguir a tarefa e não parar numa pontuação geral de língua.

A página da Comissão sobre o seu próprio uso das línguas faz esta observação sem dramatismos. A tradução automática pode dar uma ideia básica, mas a qualidade e a exatidão variam significativamente entre textos e entre pares de línguas. É uma frase pública útil porque recusa transformar um serviço num oráculo. Dá ao leitor permissão para usar uma tradução como orientação, preservando ao mesmo tempo uma razão para procurar uma versão humana ou com autoridade quando a consequência o justificar.

Para as equipas de produto, a implicação é um conjunto de percursos explícitos. Uma tradução de baixa consequência pode ser devolvida diretamente com um estado claro. Um percurso jurídico ou médico pode exigir revisão humana, uma ligação para a fonte ou uma recusa. Um rascunho interno pode preservar a fonte ao lado da tradução. Uma interface de voz pode repetir um nome crítico e pedir confirmação. A escolha não é entre automatização total e ausência de automatização. É entre um pipeline que declara as suas passagens de mão e um que as esconde atrás de um parágrafo fluente.

A frase sobrevive, a situação não

Os modelos trabalham com representações. As sociedades trabalham com situações. Quando uma tradução passa de umas para as outras, pequenos detalhes podem tornar-se todo o significado. Uma frase que é educada numa língua pode soar evasiva noutra. Um termo que distingue um direito estatutário de um serviço discricionário pode ser reduzido a uma palavra genérica para ajuda. Uma expressão idiomática pode ser traduzida literalmente e tornar-se um disparate, ou traduzida livremente e perder a referência que identifica uma comunidade. Nenhum destes falhanços precisa de um resultado absurdo. A resposta perigosa é a que parece comum.

O lançamento do EU MMLU aborda exatamente este território. Os seus critérios de qualidade pedem que os benchmarks multilingues testem não só o significado e a dificuldade, mas também expressões idiomáticas, humor, referências culturais, formatos de data e número e diferenças no tom ou na polidez esperados. Este é um alargamento importante do alvo da avaliação. Não se pergunta a um modelo de linguagem apenas se consegue produzir uma frase gramatical. Pergunta-se se a frase pertence à situação em que uma pessoa vai agir com base nela.

A menção do humor não é um convite para tornar o benchmark divertido. Reconhece que o humor é um teste de esforço para o contexto. Uma tradução literal pode preservar as palavras e destruir a piada. Uma tradução culturalmente adaptada pode preservar o efeito enquanto altera a referência. Num serviço de informação pública, o mesmo mecanismo aparece sem risos. Um provérbio, um nome de lugar local ou uma saudação formal pode sinalizar quem está a falar e que relação a mensagem cria.

Quando as equipas dizem que um modelo compreende uma língua, devem perguntar a que camada se referem. Reconhece o script? Segmenta as palavras corretamente? Identifica entidades? Traduz a proposição? Preserva a força legal? Segue uma convenção local? Mantém o nível de certeza do falante? Lida com uma grafia não padronizada? Responde no registo certo? Estas são capacidades separadas. Um único rótulo chamado multilíngue esconde o trabalho necessário para estabelecer cada uma delas.

Porque é que a avaliação tem de viajar com a língua

A avaliação é muitas vezes adicionada no final porque as equipas querem um número para associar a um modelo. Os sistemas multilíngues tornam essa ordem impossível. Os dados de teste determinam o que conta como erro. A língua determina como uma frase pode falhar. O domínio determina qual falha importa. O utilizador determina se a resposta do sistema é uma ajuda ou um obstáculo. A avaliação tem de viajar com todos os quatro.

O artigo de investigação europeu Towards Multilingual LLM Evaluation for European Languages demonstra a escala do problema. Os autores avaliam 40 modelos de linguagem em 21 línguas europeias, examinam versões traduzidas de cinco benchmarks amplamente utilizados e publicam uma estrutura que inclui EU20-MMLU, EU20-HellaSwag, EU20-ARC, EU20-TruthfulQA e EU20-GSM8K. O artigo não afirma que traduzir um benchmark existente o torna automaticamente justo. Trata os serviços de tradução, a construção de benchmarks e a comparabilidade entre línguas como aspetos a investigar.

Essa é a postura correta. Um item de teste traduzido pode herdar uma alteração de dificuldade, uma suposição cultural ou uma pista que não existia no original. Um modelo pode obter uma pontuação mais alta porque a redação traduzida torna a resposta mais fácil, não porque o modelo se tornou mais capaz. Pode obter uma pontuação mais baixa porque uma construção gramatical é pouco natural na língua de destino, mesmo que o raciocínio subjacente seja sólido. Ambos os resultados são evidências sobre o teste e também sobre o modelo.

A revisão humana continua a ser necessária, mas a revisão humana também precisa de um contrato. Quem reviu o item? Os revisores eram falantes nativos, especialistas de domínio, ou ambos? Reviram frases isoladas ou a tarefa em contexto? Os desacordos foram registados? O benchmark preservou respostas alternativas aceitáveis? Um especialista em língua pode dizer-nos que uma frase está errada. Um especialista de domínio pode dizer-nos por que razão o erro altera uma decisão. Uma avaliação credível muitas vezes precisa de ambos e deve indicar qual deles teve.

O objetivo não é fazer com que todos os sistemas passem por um exame interminável antes de alguém os poder usar. É impedir que um teste restrito seja confundido com uma afirmação ampla. Se um modelo foi avaliado em perguntas factuais curtas em linguagem escrita padrão, informe isso. Não deixe que o resultado se torne silenciosamente numa afirmação sobre interação falada, redação jurídica, governo local, crianças, pessoas mais velhas ou todos os registos da língua.

Uma pontuação torna-se útil quando os limites da tarefa, da língua, do contexto e da revisão permanecem visíveis.

A lição do maltês e do basco

Um artigo apresentado na conferência LREC-COLING de 2024 estudou a avaliação da tradução automática do inglês para maltês e do espanhol para basco. Os autores examinaram a métrica de avaliação COMET, recolheram avaliações humanas diretas e testaram o comportamento da métrica quando adaptada aos dois pares de línguas. A conclusão é modesta, mas consequente: o desempenho da métrica pode melhorar com afinação, e pode ser muito suscetível à distribuição das pontuações nos dados de treino, sobretudo em contextos com poucos recursos.

Não é uma história sobre uma métrica a falhar. É uma história sobre aquilo de que uma pontuação depende. Uma métrica treinada numa distribuição pode comportar-se de forma diferente quando é chamada a avaliar outra. Um par de línguas com menos material de avaliação pode fazer a pontuação parecer mais decisiva do que é. Um sistema que é conveniente comparar pode continuar a ser um mau substituto para aquilo que os falantes consideram uma boa tradução. Os juízos humanos não tornam a avaliação perfeita, mas expõem os pontos onde uma medida automática está a fazer suposições.

Outro estudo de 2024, Benchmarking Low-Resource Machine Translation Systems, compara sistemas disponíveis publicamente em quatro conjuntos de dados e 26 línguas e publica os resultados através do BENG, uma plataforma FAIR de avaliação comparativa para a geração de linguagem natural. Também aqui, a contribuição não é uma classificação universal. É uma comparação mais inspecionável. A eficiência e a eficácia são consideradas em conjunto, e a lista de línguas é visível. O leitor pode perguntar se a avaliação comparativa inclui o percurso que interessa, em vez de aceitar um único número de destaque.

Estes estudos oferecem uma lição europeia de contenção. A parte difícil não é inventar outra pontuação. É construir uma avaliação que permita ao leitor ver de quem é a língua, de quem é a tarefa e de quem é a definição de qualidade que produziu a pontuação. Quando esse contexto falta, um número torna-se uma travessia de fronteira sem passaporte. Pode passar na apresentação, mas ninguém consegue estabelecer de onde veio.

A cobertura linguística pode ser uma propriedade de segurança

As discussões sobre segurança centram-se muitas vezes no conteúdo que um sistema deve recusar, nos ataques que deve resistir ou nos erros que deve detetar. A língua acrescenta outra questão: consegue o sistema reconhecer quando está fora da sua competência? Um percurso que funciona numa língua pode falhar mais vezes noutra, mantendo o mesmo tom confiante. Se a interface não expõe a diferença, os utilizadores não conseguem calibrar a sua confiança.

Isto é especialmente importante quando a linguagem faz parte de uma interação crítica para a segurança. Um doente pode descrever um sintoma numa variedade regional. Um trabalhador pode reportar um perigo usando um termo local. Um residente pode apresentar uma reclamação com uma convenção ortográfica que um normalizador trata como ruído. Um modelo pode ser tecnicamente preciso no seu benchmark e operacionalmente inseguro para essa via. A questão relevante não é se o sistema consegue gerar uma resposta plausível. É se os controlos de segurança foram avaliados na língua e na situação que tem diante de si.

A segurança não exige tratar todas as vias linguísticas como uma emergência especial. Exige adequar o controlo à consequência. Um resultado de pesquisa de baixo risco pode expor as suas fontes e convidar a uma correção. Uma interface de triagem médica pode encaminhar entradas linguísticas incertas para um profissional qualificado. Um fluxo de trabalho de documentos legais pode manter a fonte e a tradução lado a lado e exigir aprovação antes da publicação. Um sistema de voz pode pedir ao utilizador para repetir um nome em vez de selecionar silenciosamente a entidade familiar mais próxima. Estas são escolhas de engenharia comuns quando a linguagem é tratada como parte do limite do sistema.

A própria recusa precisa de design linguístico. Dizer ao utilizador que o sistema não pode responder não é suficiente se a recusa for opaca, paternalista ou indisponível na língua do utilizador. O sistema deve dizer o que não conseguiu estabelecer, que informação ajudaria e qual a via humana ou de autoridade disponível. Caso contrário, um controlo de segurança torna-se outra barreira de acesso. O princípio linguístico da Europa é testado com maior clareza quando um sistema não consegue fornecer a resposta solicitada.

O design operacional de um serviço multilingue

Um serviço multilingue fiável tem uma forma operacional fácil de descrever e surpreendentemente difícil de manter. Primeiro, nomeia a tarefa. Tradução, transcrição, classificação, recuperação, sumarização e geração não são intercambiáveis. Segundo, nomeia a via linguística, incluindo a escrita e qualquer limite regional ou de domínio relevante. Terceiro, regista o material de origem e as transformações aplicadas. Quarto, define o percurso de revisão e escalada. Quinto, informa o utilizador sobre o que o sistema pode e não pode afirmar.

Esses passos não são uma exigência de uma burocracia gigante. São o mínimo necessário para tornar uma promessa linguística testável. Se um fornecedor diz que um modelo suporta finlandês, um comprador deve poder perguntar se isso significa geração de texto, reconhecimento de fala, tradução a partir de quais línguas, ou tudo isto. Se uma equipa de produto diz que suporta uma língua regional, deve dizer se o suporte se baseia em dados nativos, dados traduzidos, um pequeno conjunto de avaliação ou uma revisão especializada. Se a resposta for desconhecida, desconhecida é um estado válido.

O serviço também precisa de uma política de alterações. Novo material de formação, um novo tokenizador, um novo modelo de tradução, uma nova lista de terminologia ou uma nova população de utilizadores podem alterar o comportamento linguístico. Um lançamento que melhora uma via pode regredir outra. Um resultado de benchmark do ano passado não descreve automaticamente o sistema de hoje. Registos de versões, testes de comparação e uma via para reportar erros específicos da língua tornam o serviço mantível em vez de cerimonial.

A manutenção tem um lado humano. Os especialistas em línguas precisam de uma forma de ver os erros que afetam as suas comunidades. As equipas de domínio precisam de uma forma de distinguir um erro de tradução de uma ambiguidade de política. Os operadores precisam de uma forma de pausar uma via sem esperar que um fornecedor de modelos interprete uma reclamação. Os utilizadores precisam de uma forma de dizer que o sistema interpretou mal uma palavra, um contexto ou o nome de uma pessoa. Um serviço multilingue não está completo quando o modelo é implementado. Está suficientemente completo para ser responsabilizado quando o próximo problema linguístico chegar.

Proveniência através de um pipeline linguístico

Provenance becomes concrete when we follow one piece of meaning through a system. Start with a source paragraph. Record its language, script, author or institution when known, rights and purpose. If it is segmented, preserve the relationship to the original. If it is translated, retain the source and the translator or translation process. If a reviewer changes the wording, record that as a new state, not as a silent replacement. If the paragraph becomes a benchmark item, carry the task, answer key, language and review record with it.

At runtime, the same discipline applies in reverse. Store which language route handled the request, which model or tool version ran, which source evidence was retrieved, which uncertainty or refusal state was reached, and which human action followed. The record does not need to expose private content to every operator. It does need to make the material facts available to an authorised reviewer. Without them, a language incident becomes a debate about impressions.

This is where multilingual provenance differs from a generic audit log. A timestamp and model name tell us that something happened. They do not tell us whether the source was translated, whether the answer changed a number format, whether a named entity was normalised, or whether the reviewer was working in the target language. The transformation path is the evidence. A short answer can hide a long chain of decisions.

There is a small Dutch virtue in this approach: keep the ledger boring enough that someone can use it on a Tuesday afternoon. A provenance record should not be a museum label written for an audit that may never arrive. It should help an operator answer the next question, stop the right route and explain the result to a person who has no interest in your architecture diagram. Good language governance is slightly dull. That is how you know it might survive contact with work.

The hidden choices in a translation

Every translation system carries choices that deserve names. Tokenisation decides how the input is split. Normalisation decides which distinctions are preserved or discarded. Alignment decides which parts of two texts are treated as equivalent. Terminology decides which words are stable. Decoding decides how the output is selected. Post-processing decides what the reader sees. None of these steps is inherently wrong. Each can create a language-specific failure that is invisible in a general demo.

Take a proper name. A system may translate it, transliterate it, preserve it, or replace it with a familiar spelling. For a poem, several choices may be defensible. For an identity document, only one may be acceptable, and that one may depend on the issuing authority. Take a unit or date. The values may remain mathematically equivalent while the form becomes ambiguous to a reader. Take a gendered noun or pronoun. A translation can introduce information that the source withheld, or erase a distinction the source made deliberately.

The design answer is not to freeze language. It is to state the policy and make the exception visible. A terminology list can protect legal terms. A named-entity rule can prevent a town from becoming a person. A source-preserving view can let a reviewer compare the original and output. A human escalation can be triggered by a low-confidence name, a disagreement between routes or a task classified as high consequence. The model remains useful because its boundaries are part of the workflow.

Os modelos de linguagem de grande dimensão tornam as escolhas mais difíceis de ver porque o resultado é fluido. Um resultado fluido é uma interface maravilhosa e uma explicação pouco fiável. O sistema pode produzir uma frase que soa como nativa ao mesmo tempo que seleciona o sentido errado de uma palavra. Pode preservar o tópico geral enquanto omite uma negação. Pode traduzir uma expressão local para uma expressão padrão que altera a posição do falante. É por isso que a qualidade da língua não pode ser representada apenas pela gramática. O significado tem uma forma social.

Escritas, dialetos, registos e instituições

O suporte linguístico é frequentemente anunciado ao nível do nome de uma língua, mas os leitores encontram escritas, variedades e registos. Um sistema que lida com a ortografia padrão moderna pode ter dificuldades com documentos históricos. Um reconhecedor de voz pode lidar com áudio de estúdio e falhar numa estação cheia. Um chatbot de atendimento ao público pode responder num registo formal quando o utilizador precisa de linguagem simples. Uma instituição pode usar um termo que difere da linguagem comum por uma razão juridicamente importante.

Estes não são casos extremos no sentido depreciativo. São os lugares onde a língua encontra o mundo. Um nome regional pode significar a diferença entre um endereço correto e uma entrega falhada. Uma palavra dialetal pode ser a única palavra que uma pessoa conhece para um sintoma. Uma frase formal pode sinalizar que uma mensagem tem efeito legal. Uma variante de escrita pode determinar se um documento é pesquisável. Se um benchmark excluir estes caminhos, pode ainda assim ser útil, mas não pode substituir a língua como um todo.

Testar todas as variedades nem sempre é possível. A resposta honesta é descrever o subconjunto suportado e convidar a apresentação de evidências sobre o resto. Um sistema pode publicar que foi avaliado em neerlandês escrito padrão para sumarização de informação pública, sem fazer afirmações sobre o reconhecimento de fala regional. Pode acrescentar um teste para o frísio ou o basco sem fingir que essa adição resolve todas as questões regionais e de línguas minoritárias. A especificidade não é uma fraqueza. Diz aos utilizadores onde está o limite mínimo.

As instituições devem também resistir à ideia de que uma rota linguística nacional única é automaticamente neutra. A linguagem administrativa pode ser inacessível para falantes da mesma língua. A acessibilidade e o multilinguismo sobrepõem-se porque ambos perguntam se o leitor consegue compreender e agir. O trabalho linguístico da Comissão inclui ferramentas de simplificação e texto acessível precisamente por esta razão. Uma frase pode ser linguisticamente correta e ainda assim institucionalmente inutilizável.

Quando a interface é fluida mas errada

As falhas linguísticas mais difíceis não são espetaculares. São respostas que passam no teste à vista. Um resumo inclui os nomes certos mas muda quem é o responsável. Uma tradução preserva os substantivos mas transforma uma recomendação numa instrução. Um classificador compreende o tópico mas falha uma negação. Um sistema de voz reconhece as palavras mas não a hesitação do falante. Um utilizador lê o resultado na sua própria língua e assume que a fluidez é um sinal de cuidado.

Devemos conceber para esta classe de erros em vez de esperar que um exemplo bizarro se torne manchete. Compare a fonte e o resultado para conteúdo de alto impacto. Preserve os marcadores de incerteza. Mantenha as citações ou referências documentais ligadas. Peça confirmação quando um número, nome ou prazo for central. Torne o percurso visível para o operador. Ofereça um mecanismo de correção que não exija que o utilizador saiba qual componente falhou. Estes controlos são pequenos, mas transformam uma tradução numa transação inspecionável.

A revisão humana não deve ser descrita como uma linha final mágica. Os revisores têm limites de tempo, lacunas de domínio e os seus próprios pressupostos linguísticos. Uma interface de revisão útil dá-lhes a fonte, o resultado, o contexto e o motivo da escalada. Regista o desacordo em vez de o suavizar. Se os revisores corrigirem repetidamente um termo, a organização pode melhorar a terminologia ou alterar o âmbito da tarefa. Se o desacordo revelar que a própria fonte é ambígua, a ação correta pode ser perguntar ao autor, e não treinar o modelo com mais afinco.

Os operadores também precisam de uma forma de ver as evidências negativas. Que línguas não foram avaliadas? Que tarefas não têm revisão humana? Que pedidos foram recusados? Que utilizadores abandonaram o percurso após uma tradução? Uma ausência pode ser um sinal. Um gráfico de cobertura verde que omite os percursos falhados é um mapa da superfície de marketing, não do serviço.

A perícia humana não é um botão de recurso

A política europeia de tecnologias linguísticas coloca linguistas, cientistas de dados, engenheiros informáticos e especialistas de domínio na mesma frase. Isso é um requisito de conceção, não uma lista de profissões para convidar para uma reunião de lançamento. Cada pessoa vê uma falha diferente. O linguista vê uma construção pouco natural ou uma distinção perdida. O engenheiro vê um problema de segmentação ou de encaminhamento. O especialista de domínio vê um erro de categoria perigoso. O operador vê uma fila que ninguém consegue assumir. A pessoa que utiliza o serviço experiencia uma decisão que já não faz sentido.

A perícia humana deve entrar antes de o benchmark ser congelado. Um especialista em línguas pode ajudar a selecionar material de teste que represente registos reais e não apenas frases limpas. Um especialista de domínio pode identificar termos que não podem variar. Um representante da comunidade pode dizer a uma equipa que formulação parece oficial, familiar ou insultuosa. Um responsável pelos dados pode explicar que proveniência está disponível e qual não está. Estes contributos moldam o contrato do sistema. Não são decoração depois de as escolhas técnicas terem sido feitas.

Há um custo, claro. Uma boa revisão leva tempo e paga a pessoas por um conhecimento que muitas vezes é tratado como invisível. Esse custo faz parte do suporte linguístico. A alternativa é externalizá-lo para os utilizadores, que pagam com confusão e recursos, ou para o pessoal, que traduz e repara o percurso informalmente. Um sistema que parece barato porque ignora a perícia linguística não é eficiente. Simplesmente transferiu a fatura.

O que um benchmark justo deve expor

Um benchmark multilingue deve começar com uma afirmação suficientemente pequena para ser testada. A afirmação pode ser que um sistema consegue responder a perguntas de informação pública num conjunto de línguas, preservar datas e números e recusar quando faltam as evidências da fonte. Pode ser que um percurso de tradução lide com um par e um domínio específicos a um nível de qualidade definido. Pode ser que um reconhecedor de fala consiga transcrever uma variedade especificada em condições acústicas especificadas. O benchmark é um contrato para essa afirmação.

O contrato precisa de mais do que uma lista de línguas. Deve expor a tarefa, a fonte, o domínio, o registo, o script, a direção, o comprimento do contexto, as condições de entrada, as respostas de referência, as variantes aceitáveis, as métricas, a revisão humana e a incerteza. Deve indicar se os itens foram originalmente escritos em cada língua ou traduzidos. Deve registar quem os reviu e que desacordos permaneceram. Deve separar os resultados agregados dos resultados por língua. Deve mostrar exemplos suficientes para que um leitor compreenda o que a pontuação está a medir.

The EU MMLU criteria are useful because they widen the word fair. Balanced representation across the EU’s official languages is one part. Retaining meaning, difficulty and testing value across languages is another. Testing EU values and cultural contexts, including idioms, humour, references, date and number formats, tone and politeness, makes the benchmark a social instrument as well as a technical one. The criteria do not remove judgement. They make the judgement inspectable.

Benchmark designers should publish failure slices, not only averages. A model can have a good mean score while failing every item involving a particular register or type of number. A route can be efficient in one direction and slow or expensive in another. A metric can correlate with human judgement in one language and become unstable in another. Per-language and per-task views are not a luxury. They are how a buyer avoids purchasing the average while deploying the exception.

Finally, a benchmark should state what it cannot tell us. A written test does not establish speech performance. A translation score does not establish legal reliability. A set of official languages does not establish support for regional or minority languages. A high score does not establish that a person can challenge a decision. The limitation is not an embarrassment. It is the edge of the map, and users need to see it before they sail.

A score is a map legend, not the territory

Numbers are useful because they force a comparison. They are dangerous because they invite a conclusion larger than the measurement. A score can tell us how a system behaved on a defined sample under a defined method. It cannot tell us how a community will experience the system without a bridge of assumptions. The bridge may be sound. It must be named.

Suppose a system improves on a multilingual benchmark after fine-tuning. That is evidence of improved performance on that evaluation. It is not automatically evidence that the system is safer in a public service. The service may use different terminology, longer context, speech input, a different register or a downstream workflow that turns a suggestion into a decision. The benchmark can still be valuable. It becomes more valuable when the organisation says which part of the service it represents.

The same discipline applies to energy, speed and cost. A low-resource language route may require more human review or a larger retrieval context. That is not a defect to conceal in an average. It is a property of the service that should inform design. European institutions have spent decades building translation and language services because the practical cost of linguistic diversity is real. An AI system does not abolish that cost by emitting text quickly.

There is no shame in choosing a narrower route. A team can support fewer tasks well, publish the boundary and add languages as evidence grows. That is better than claiming every language and asking users to discover the gaps. The European instinct for a standard is strongest when it is paired with the Dutch instinct to check whether the thing works on an ordinary Wednesday.

Build for 24, test beyond 24

The European Union has 24 official and working languages, and the Commission’s translation service operates across them. That number creates a useful baseline for public infrastructure. It does not define Europe’s linguistic life. Regional, minority, non-territorial and migrant languages also shape communities and institutions. A system built for 24 can still exclude people who do not use one of those routes, or who use an official language in a form the system did not evaluate.

Construir para 24 é, portanto, uma responsabilidade de tornar a base real, e não uma permissão para parar. Uma rota linguística deve apresentar as suas próprias provas. Um organismo público deve poder indicar quais as línguas oficiais abrangidas para cada tarefa, que revisão humana existe e onde os utilizadores podem obter uma versão com valor oficial. Deve também ter forma de aprender com línguas fora do conjunto inicial, sem transformar a comunidade num laboratório de testes não remunerado.

Testar para além de 24 significa mais do que acrescentar uma língua de novidade a uma demonstração. Significa trabalhar com falantes, instituições e investigadores para decidir qual é a tarefa, para que pode ser utilizado o material de origem e o que conta como erro prejudicial. O processo pode produzir uma capacidade pequena e cuidadosamente delimitada. Isso continua a ser progresso. Uma rota modesta com um contrato claro pode valer mais do que uma afirmação impressionante que nenhum operador consegue defender.

O que procuramos tornar explícito

Na Dweve, abordamos este assunto do lado da infraestrutura. O Loom é descrito no nosso material público de produto como um modelo cognitivo compilado por tarefa, cujos componentes linguísticos apresentam um grafo de resultados governado, cabendo a autoridade de decisão à aprendizagem de restrições, à composição de grafos, aos resolvedores e à verificação. Esta é uma posição arquitetónica, não uma afirmação de desempenho multilingue. Não torna correta uma rota linguística. Mas torna difícil esconder uma obrigação: o resultado linguístico não deve ser o único lugar onde existem o raciocínio e as provas do sistema.

O nosso trabalho Ground Truth faz o mesmo ponto a uma escala mais humana. As pessoas precisam de linguagem partilhada suficiente para distinguir um modelo de um fluxo de trabalho, uma previsão de uma prova e uma resposta fluente de um resultado verificado. Em sistemas multilingues, esse vocabulário precisa de mais uma palavra: rota. Uma resposta em neerlandês, uma resposta em francês e uma resposta em basco não são meras representações de um único evento interno se as provas, a terminologia, a revisão e o comportamento em caso de falha forem diferentes. A rota faz parte da afirmação.

Essa posição é deliberadamente menos empolgante do que dizer que um modelo compreende a Europa. Também é mais útil. Queremos que um sistema mostre o que recebeu, que fontes e restrições pôde utilizar, o que não conseguiu estabelecer e quando uma pessoa deve assumir o controlo. A língua é uma superfície através da qual uma pessoa encontra esse trabalho. A superfície deve ser clara, mas não deve poder apagar a estrutura subjacente.

Não estamos isentos das normas aqui descritas. Um campo de proveniência não repara dados em falta. Um caminho determinístico não prova que uma tradução é justa. Uma fronteira europeia de processamento não confere competência linguística. A única forma honesta de fazer uma afirmação multilingue é continuar a testar, publicar os limites e deixar que especialistas em línguas desafiem a rota. O nome do produto não é prova. O registo é.

Uma norma prática para equipas

As equipas que decidem se devem introduzir uma funcionalidade de IA multilingue podem começar com um conjunto curto de perguntas. O que exatamente deve o sistema fazer em cada língua? Que pessoas são afetadas se estiver errado? Que material de origem tem valor oficial? Como foram criados os itens de teste, e por quem? Que registos, escritas, dialetos e domínios estão dentro da afirmação? O que faz o sistema quando não consegue estabelecer significado? Quem pode suspender a rota? Como pode um utilizador corrigir uma resposta sem se tornar no linguista não remunerado do projeto?

As perguntas tornam-se concretas quando ligadas a artefactos. Mantenha um cartão de rota linguística com a tarefa, as variedades linguísticas suportadas, as famílias de fontes, o estado dos direitos, as versões do modelo e das ferramentas, os resultados da avaliação, os modos de falha conhecidos e o responsável pela revisão. Mantenha exemplos de erros com o seu contexto, não apenas uma pontuação. Mantenha a fonte junto de uma tradução de alto impacto. Mantenha um motivo de escalamento que um operador consiga compreender. Mantenha um registo de alterações quando mudar um tokenizador, uma lista de terminologia, um referencial ou um modelo.

As equipas de compras podem pedir aos fornecedores resultados por língua e por tarefa, em vez de uma única média multilingue. Podem perguntar se um benchmark foi traduzido ou escrito de raiz na língua, se estão disponíveis avaliações humanas, como são tratadas as vias de baixos recursos e se o fornecedor consegue exportar as provas necessárias para uma revisão. Podem perguntar o que acontece quando uma língua não é suportada, porque uma recusa e uma alternativa silenciosa têm consequências muito diferentes.

As equipas de produto podem conceber a interface para mostrar a via e o nível de confiança sem fingir que um número de confiança é uma probabilidade de verdade. Podem preservar as ligações às fontes, usar linguagem simples nas recusas e tornar as ações de revisão visíveis. Podem evitar a expressão suporta todas as línguas, a menos que consigam definir o verbo. Suportar pode significar apresentar texto, aceitar dados, traduzir, resumir, responder, classificar, falar ou gerir um fluxo de trabalho regulado. Um seletor de línguas não é uma especificação.

As equipas de investigação podem publicar conjuntos de dados com proveniência e percursos de correção. Podem incluir resultados negativos e comunicar quando uma métrica não se generaliza bem. Podem convidar as comunidades linguísticas para a avaliação antes de um modelo ser declarado pronto e pagar por essa experiência. Podem resistir à pressão de transformar um resultado restrito numa afirmação universal. O benchmark mais valioso pode ser aquele que leva uma equipa a remover uma frase da sua página de produto.

A sociedade por detrás do modelo

Um modelo de linguagem pode ser muito bom a produzir linguagem sem saber o que a linguagem faz numa sociedade. Pode prever uma frase, traduzir um parágrafo e responder a uma pergunta sem captar a relação institucional transportada pelas palavras. Essa lacuna não é prova de que o modelo é inútil. É prova de que a linguagem é mais do que um tipo de dados.

A resposta da Europa não deve ser uma competição para contar línguas numa ficha de modelo. Deve ser um esforço sustentado para fazer dos dados linguísticos, dos direitos, da experiência, da avaliação e do controlo público parte da mesma infraestrutura. O trabalho da Comissão em tecnologia linguística, o Language Data Space, a European Language Grid e o benchmark EU MMLU apontam todos nessa direção. Os investigadores europeus estão a testar o que acontece quando os benchmarks traduzidos são tratados como questões de investigação e não como instrumentos inquestionáveis. Esse trabalho merece atenção porque torna tecnicamente visível um facto político antigo: as pessoas não vivem a União numa única língua.

Da próxima vez que um fornecedor disser que um modelo é multilingue, pergunte o que contém essa afirmação. Que línguas? Que tarefas? Que comunidades? Que fontes? Que revisão? Que recusa? Que registo de alterações? A pergunta não é hostil. É o começo normal da responsabilização.

Uma sociedade não se torna justa porque uma máquina consegue repetir as suas palavras. Torna-se mais justa quando as pessoas podem entrar nas suas instituições, compreender o que se passa, contestar um resultado e ser ouvidas na língua que acompanha a sua vida. Um modelo pode ajudar nesse trabalho. Não pode defini-lo. A língua de um modelo é uma capacidade técnica. A língua de uma sociedade é uma responsabilidade partilhada.

Fontes