Afinar um Guardrail de IA para Português Europeu

Há uma falha pequena e persistente que corrói discretamente a confiança em texto escrito por IA para uma marca portuguesa: o modelo escreve português do Brasil. Não de forma óbvia, nem sempre — mas escapa um brasileirismo, falta um acento ou uma frase resvala para o registo informal. Para um leitor europeu, soa a estrangeiro, e texto estrangeiro de uma marca que se diz local quebra a confiança num instante.

A solução óbvia é dizer ao modelo "escreve em português europeu". Experimentámos. Não é fiável. Pedir empurra as probabilidades, mas não fecha a distância — o modelo continua a deixar escapar PT-BR de forma intermitente, e sempre no momento em que já se deixou de rever. Um pedido não é uma garantia.

Por isso deixámos de pedir e construímos antes uma garantia. Eis como afinámos um pequeno modelo guardrail cuja única função é reescrever qualquer texto em português europeu limpo, sem alterar o significado — e, tão importante quanto isso, o que ainda faz mal.

Virar o guia de estilo do avesso

A parte mais difícil de afinar um modelo costuma ser os dados. São precisos pares emparelhados — entrada má, saída boa — e aos milhares. Escrever esses pares à mão levaria uma eternidade.

Já tínhamos metade da resposta guardada nas nossas próprias ferramentas. Há anos que mantemos um guia de estilo estrito de PT-PT e um verificador baseado em marcadores (check-pt-pt.sh) que percorre o texto à procura de brasileirismos conhecidos. Esse verificador existe para apanhar texto sujo. O truque foi corrê-lo ao contrário.

Em vez de corrigir mau português para bom, pegámos no nosso corpus limpo de PT-PT e corrompemo-lo programaticamente em português do Brasil: a introduzir brasileirismos, a retirar acentos e a trocar frases neutras para o registo informal. Cada corrupção produziu um par de treino (sujo → limpo) — o texto corrompido como entrada, o texto limpo original como alvo. O gerador faz a metade confusa; o original impecável é a chave de correção.

A garantia vive num portão de limpeza. Cada saída-alvo tem de passar pelos marcadores do verificador antes de entrar no dataset, para podermos prometer que aquilo que o modelo aprende a produzir é genuinamente limpo — sem fugas acidentais nas etiquetas. O resultado foram 1572 pares de treino a partir de 509 unidades limpas, divididos em treino, validação e teste com um método consciente dos grupos e verificados sem qualquer fuga entre as divisões. (A consciência dos grupos importa: se dois pares derivam da mesma unidade de origem, têm de cair na mesma divisão, ou a pontuação de teste está discretamente a medir memorização.)

Um modelo de 3B, 12 minutos, numa placa de 2018

O modelo é deliberadamente pequeno. Isto é um guardrail, não um assistente geral — faz uma única tarefa estreita de reescrita, por isso não precisa de ser grande.

Afinámos o Qwen2.5-3B com QLoRA (4 bits) através do Unsloth, em fp16, durante cerca de 2 épocas. O treino inteiro demorou cerca de 12 minutos numa RTX 2080 Ti — a mesma placa de jogos de 2018, com 11GB que usamos no resto do nosso trabalho local. É o mesmo tema de hardware antigo que percorre toda a nossa stack: capacidade de que somos donos, numa placa que custou uma fração de uma fatura de treino na cloud.

Depois de treinado, o guardrail é servido localmente através do Ollama como um modelo quantizado de cerca de 1,9GB. Na pipeline, ocupa uma posição determinística mesmo no fim: seja o que for que o modelo a montante gere, o guardrail reescreve-o em português europeu limpo antes de qualquer coisa chegar a uma pessoa. Não é uma sugestão que o modelo de escrita possa ignorar — é um passo que corre sempre.

Os resultados, honestamente

É aqui que a maior parte dos relatos arredonda para cima. Não vou fazê-lo.

Num conjunto de avaliação reservado — a divisão de teste sem fugas, texto que o modelo nunca viu no treino — a taxa de limpeza PT-PT do modelo base já era respeitável, situada nos valores altos dos 80 aos baixos dos 90 por cento. O número que citamos como manchete é ~87% de limpeza no modelo base a subir para ~100% após a afinação nesse conjunto reservado. Quase perfeito, nesse conjunto.

Mas "quase perfeito no conjunto reservado" não é "perfeito em todo o lado", e o número honesto depende do rigor com que se pontua. Quando mais tarde acrescentámos um avaliador mais rigoroso, atento ao registo informal (já explico porquê), a mesma comparação passou a ler-se mais perto de 90% → 98%. Continua a ser uma melhoria grande e real — mas são 98%, não uns 100% redondos, e os dois por cento que sobram são exatamente os casos-limite que um teste sintético pior consegue ver.

Portanto, o resumo honesto é este: o guardrail fecha quase toda a distância nos padrões de língua com que foi treinado, e o resíduo é pequeno mas real. Quem disser que uma afinação chegou aos 100% em todo o lado ou não está a medir com rigor ou não está a contar o teste todo.

Duas lições que nos custaram

A parte interessante deste projeto não foi o treino. Foram dois erros que nos ensinaram algo geral.

Lição 1 — os substantivos com género pedem tratamento do artigo, não trocas de palavra. A nossa primeira lógica de corrupção tratava o problema como um dicionário: encontrar a palavra brasileira, trocá-la pela europeia. Isso parte-se no género. Veja-se tela (brasileiro, feminino) face a ecrã (europeu, masculino). Uma troca ingénua transforma "na tela" em "no ecrã"… só que fez o contrário — produziu texto gramaticalmente errado como "no tela", porque trocou o substantivo mas deixou o determinante a concordar com o género antigo. A correção foi uma corrupção consciente do género que também inverte o determinante junto com o substantivo (o↔a, no↔na, do↔da, num↔numa, e por aí fora). Isso generaliza-se a qualquer par masculino↔feminino PT/BR, não só a esta palavra.

Lição 2 — o único teste honesto é correr o modelo em texto real. Esta é a razão do avaliador atento ao registo informal referido acima. A nossa avaliação sintética era cega ao registo informal — porque o verificador não listava essas formas como marcadores. Essa única omissão fez cascata: os exemplos de treino nesse registo passavam o portão de limpeza (o portão não sabia que os devia rejeitar) e a avaliação nunca os media (o avaliador não sabia que os devia procurar). Por ambas as métricas, o guardrail parecia perfeito nesse problema, sem fazer nada quanto a ele.

Só o apanhámos ao correr o guardrail numa geração real, em vez de mais um teste sintético. Em texto real a jusante, deixou "alinhada ao teu foco" — a forma informal — completamente por corrigir. A correção foi acrescentar um conjunto curado de marcadores dessas formas, para que o portão passe a expurgá-las dos alvos e a avaliação passe a medi-las; depois voltámos a treinar. A conclusão merece ser dita com clareza, porque vale para qualquer sistema de qualidade de IA:

Um defeito que não está no verificador não é treinado para desaparecer nem é medido. Por isso, corra o modelo em texto real a jusante, e não apenas em testes sintéticos — os testes sintéticos só conseguem ver as falhas que já se lembrou de codificar.

O que ainda faz mal

Um guardrail que se dissesse completo estaria a repetir exatamente o erro que a Lição 2 acabou de descrever. Por isso, eis o que ainda escapa.

Sobressaem duas fraquezas residuais. Primeiro, um léxico de transportes e do mundo rural de que o corpus de treino é pobre — a família de palavras do tipo ônibus / pedágio / carona, que raramente aparece no nosso material de origem, pelo que o modelo viu poucos exemplos para as corrigir de forma fiável. Segundo, verbos raros do registo informal enterrados em orações relativas, onde a forma está suficientemente longe da superfície para os marcadores atuais nem sempre a apanharem.

É um guardrail, não magia. Apanha os mais de 95% de alta frequência da fuga de PT-BR que aparece de facto no texto do dia a dia, e falha uma cauda longa de casos mais raros. É uma ferramenta genuinamente útil — desde que se saiba distinguir uma coisa da outra e não se desligue a leitura humana para a cauda.

Porque é que isto importa se vende na Europa

Afastando-nos da mecânica, o ponto é simples. Qualidade de língua europeia a este nível é algo que não se consegue de forma fiável de um modelo de cloud americano genérico — ele continua a deixar escapar o dialeto errado, e nenhum prompt o trava por completo. Um pequeno guardrail afinado trava, para os casos comuns, de forma determinística.

E, por ser um modelo pequeno self-hosted, entrega essa qualidade sem a troca do costume. O texto do cliente é reescrito em infraestrutura que ele controla; nunca sai do edifício para um modelo de terceiros. É o mesmo método "soberano e verificável" que aplicamos ao resto da nossa stack — ser dono do modelo, ser dono do caminho dos dados — aplicado aqui à própria língua. Fica com português de qualidade europeia e mantém os dados. Para uma marca europeia, isto não é um luxo. É a razão inteira para construir desta maneira.

A conclusão

Pedir a um modelo que respeite um dialeto é um pedido. Afinar um guardrail para o impor é uma garantia — pelo menos para os padrões que nos lembrámos de testar. Lá chegámos ao virar o nosso próprio verificador do avesso para gerar dados de treino, ao treinar um modelo de 3B em doze minutos numa placa com sete anos e, depois, ao ser honesto quanto aos dois por cento que ainda falha.

A lição mais duradoura nada tinha que ver com português: o seu sistema de qualidade de IA só consegue apanhar os defeitos que já lhe ensinou a ver. Corra a coisa em texto real, veja onde falha e acrescente essa falha ao verificador. Depois, faça tudo outra vez.