A Utilização De Determinadas Variedades Linguísticas

Por que seu modelo falha em português que não é o padrão do training set

Se você treinou ou ajustou um modelo com dados majoritariamente de português brasileiro formal e tenta rodar ele em uma transcrição de atendimento da periferia de São Paulo ou de um texto coloquial de Portugal, os resultados vão ser ruins. Não é porque o modelo é incapaz. É porque ele nunca viu dados durante o ajuste fino, e as embedding spaces não alinham direito. Eu já passei por isso na prática. Montei um pipeline de análise de sentimento para uma operadora de telecomunicações que atendia todo o Brasil. O modelo que eu havia escolhido — baseado em Fine-tune com dados de notícias e manuais técnicos — performava com F1 de 0.89 no português padrão. Quando testamos com áudio transcrito de chamadas de clientes de Salvador e Recife, o F1 caiu para 0.61. O problema não era o sotaque em si, mas as variedades linguísticas presentes na fala: contrações regionais, empréstimos do tupi, estruturas sintáticas diferentes, gírias que o vocabulário do modelo simplesmente não mapeava.

a utilização de determinadas variedades linguísticas na prática

O primeiro passo que a maioria das pessoas errou é tentar resolver tudo com prompt engineering. Isso funciona até certo ponto. Você pode pedir para o modelo se adaptar ao registro do texto. Mas se o vocabulário e as estruturas sintáticas estavam ausentes nos dados de treino, o prompt não inventa conhecimento que o modelo não tem. A solução real envolve três camadas: Camada 1 — Mapeamento de variantes. Antes de qualquer processamento, você precisa saber quais variedades linguísticas estão presentes no seu corpus. No meu caso, fiz um inventário simples: coletei 500 exemplos de falas por região e classifiquei manualmente os traços variantes — morfologia, léxico, fonética na transcrição. Foi tedioso, mas levou cerca de 3 horas. Esse inventário é o que vai guiar todo o resto.

Camada 2 — Seleção ou adaptação do modelo base. Modelos como BERT-base-Portuguese foram treinados majoritariamente em textos da internet brasileira. O CConvert da UnB tem embeddings para várias variantes. Se você trabalha com português europeu, existe o DPMBERT-pt. Paravariantes afro-brasileiras e indígenas, ainda não há modelos amplamente disponíveis, então você precisa usar tradução de estilo (style transfer) como pré-processamento ou aceitar perda de performance. Camada 3 — Ajuste fino direcionado. Não adianta fazer fine-tune geral. Você precisa de dados anotados da variedade específica. No projeto da operadora, coletamos 2.000 amostras anotadas de cada região e fizemos fine-tune separado por variante. O resultado: F1 subiu de 0.61 para 0.84 para osfalantes de Nordeste, e para 0.87 para o Sul. O ganho não foi linear — as maiores melhorias vieram para as variedades mais afastadas do padrão.

Erros comuns que todo mundo comete

A maior pegadinha é achar que normalização ortográfica resolve. Remover acentos, padronizar grafias, converter "vc" para "você" — isso ajuda com textos digitados jovens, mas piora a situação para variedades que têm regras morfológicas próprias. Um falante do sertão nordestino que escreve "nóis vai" não está cometendo erro. Está produzindo uma variedade legítima com reglas consistentes. Seu modelo precisa aprender essas regras, não corrigi-las. Outro erro frequente é misturar variantes no mesmo dataset de fine-tune sem peso adequado. Se 80% dos seus dados são de Sãopaulo formal e 20% são de outras variantes, o modelo vai otimizarse para a maioria e negligenciar o restante. A solução é balancear ou usar loss weighting por classe de variedade. Uma limitação séria que pouca gente admite: alguns modelos simplesmente não escalam para variedades muito minoritárias. Se seu corpus tem pouquíssimos exemplos de uma variante específica (digamos, oportunidade de imigrantes haitianos no Brasil falando português como língua segunda), o fine-tune não resolve. O modelo não tem base para generalizar. Nesse caso, a única saída viável é usar zero-shot com um modelo maior (como um LLM de 70B+) e construir few-shot examples manualmente. Isso aumenta o custo computacional em cerca de 10x comparado ao fine-tune, mas é o que funciona quando não há dados suficientes.

Um exemplo concreto de implementação

Vou mostrar como configurei o pipeline da operadora. A estrutura foi: Pré-processamento: identificação da variante via um classificador leve (um SGD classifier com TF-IDF de n-grams, treinado nos 500 exemplos mapeados). Esse classificador era rápido — levava cerca de 2ms por amostra — e separava o fluxo antes do modelo principal. Rotas especializadas: cada variante tinha seu modelo fine-tuned. O modelo para português brasileiro padrão era um BERT base já disponível. Os modelos regionais eram ajustes do mesmo base com dados anotados específicos.

Fusão: as previsões de todos os modelos eram combinadas por média ponderada, onde os pesos eram a confiança do classificador de variante. Isso reduziu erros de transição entre variantes — um problema que aparecia quando o classificador errava e o modelo mandava para a rota errada. O throughput final ficou em torno de 200 requisições por segundo por GPU (A10G), com latência média de 45ms. Comparado ao modelo único não especializado, que processava 400req/s mas com F1 de 0.72 no geral, houve uma queda de 50% em throughput. O trade-off valeu a pena porque a precisão por região ficou acima de 0.84.

Quando isso não funciona

Se sua aplicação envolve variedades linguísticas com documentação escassa ou variação dialetal extremamente granular — tipo diferenças entre bairros de uma mesma cidade — o custo de coleta e anotação de dados pode não compensar. Nesse cenário, um modelo grande de linguagem com few-shot prompting é mais pragmático, mesmo com menor throughput. Eu recomendaria esse caminho quando você tiver menos de 500 exemplos anotados por variante. Acima disso, o fine-tune direcionado entrega retorno melhor. Também existe o problema de dívida de manutenção. Cada variante nova que você adiciona ao pipeline exige novo ciclo de coleta, anotação, treino e validação. Num projeto com 6 variantes regionais, o tempo de manutenção mensal gira em torno de 20-30 horas de engenharia de dados. Se o volume de variantes for maior que isso, considere abandonar a abordagem especializada e investir em um único modelo robusto com augmentation de dados sintéticos.