Escolher um modelo de linguagem para trabalhar em espanhol não se resolve com uma tabela de pontuações. A maioria das comparações públicas concentra-se em benchmarks em inglês, e quando você traslada esses números para um caso real em castelhano descobre que o modelo que ganhava no MMLU perde o fio da meada numa conversa com expressões argentinas ou mistura terminologia catalã com castelhana. Este guia não te dá um ranking fechado: te dá um procedimento de configuração reproduzível para que você mesmo meça qual modelo rende melhor no seu caso concreto, com testes concretos e limiares de decisão.
Passo 0: defina o que significa «rendimento em espanhol» para o seu projeto
Antes de tocar numa API ou baixar pesos, escreva numa folha quais tarefas você vai delegar ao modelo. Não é a mesma coisa um classificador de tickets de suporte que um gerador de resumos jurídicos. Os eixos que de fato discriminam entre modelos em espanhol são quatro:
- Compreensão leitora: extrair respostas de um texto longo sem inventar dados.
- Fluência e registro: que o texto não soe a tradução automática do inglês.
- Robustez dialetal: comportamento diante de variantes rio-platense, mexicana, peninsular ou andina.
- Fidelidade instrucional: respeitar formatos (JSON, listas, comprimentos) em castelhano.
Um modelo pode ser excelente no primeiro e desastroso no terceiro. Segundo documentação oficial de vários provedores, suas avaliações multilíngues agregam resultados por idioma, o que oculta diferenças regionais. Por isso o passo 0 é imprescindível.
Passo 1: monte o banco de testes com textos reais seus
Reúna entre 20 e 40 exemplos próprios. Servem e-mails de clientes, fragmentos da sua base de conhecimento, páginas de produto ou transcrições de chamadas. Etiquete manualmente a resposta esperada numa coluna à parte. Esse detalhe faz a diferença: os benchmarks públicos usam modelos que os modelos viram em treinamento; seus textos não.
O que incluir obrigatoriamente
- Pelo menos cinco exemplos com code-switching (castelhano com termos em inglês, habitual em tecnologia).
- Dois ou três com números e unidades (datas, valores, percentagens) para detectar erros de formato.
- Um exemplo com instrução negativa: «não menciones preços» ou «responda apenas com a tabela».
- Textos com acentos, nhões e sinais de abertura (¿ ¡). É um teste barato que descarta modelos com tokenizadores pobres para espanhol.
Passo 2: configure o ambiente de comparação
Não compare modelos a partir de interfaces de chat diferentes: mudam o system prompt por padrão, a temperatura e o truncamento. Use um script único que chame cada endpoint com parâmetros idênticos. Um esqueleto em Python com a biblioteca padrão de cada provedor basta.
params = {
«temperature»: 0.2,
«max_tokens»: 800,
«top_p»: 1.0
}
Fixe temperatura baixa (0.1–0.3) para tarefas de extração. Se o seu caso for criativo, repita a bateria com temperatura 0.8 e compare estabilidade entre execuções. Um modelo que varia muito com a mesma semente é difícil de integrar em produção.
O erro que quase todos cometem aqui
Comparar apenas a primeira resposta. Os modelos grandes costumam acertar no primeiro turno e degradar-se quando o contexto cresce. Adicione um teste de dois e três turnos com contexto acumulado de 3.000–6.000 tokens em espanhol. Na minha experiência com assistentes de atendimento ao cliente, a queda mais brusca aparece justamente aí: o modelo começa a responder em inglês ou perde a instrução de formato quando o histórico se alonga. Essa limitação não aparece em nenhuma tabela comparativa pública.
Passo 3: defina métricas que você possa calcular sem uma equipe de anotadores
Você não precisa de um laboratório. Com três métricas simples obtém sinal suficiente:
- Acerto exato ou por sobreposição: para extração, compare com a resposta etiquetada usando coincidência de palavras-chave ou similaridade de cadeias.
- Taxa de violação de formato: percentagem de respostas que não respeitam o esquema pedido (JSON inválido, listas com marcadores quando se pedia prosa).
- Penalização por anglicismos: contagem de termos em inglês não justificados pelo domínio. Um limiar razoável é mais de dois por cada 200 palavras em textos de divulgação.
Se precisar avaliar fluência, peça a dois colegas que ordenem pares de respostas às cegas. Com 30 pares você obtém uma preferência bastante estável. Não é preciso mais para decidir.
Passo 4: execute a bateria e leia os resultados com ceticismo
Lance cada modelo três vezes por exemplo e registre a variância. Um modelo com 85 % de acerto e desvio alto é pior para produção que um com 80 % estável. Documente também latência e custo por 1.000 tokens: em espanhol, o comprimento médio das respostas costuma ser 10–20 % maior que em inglês para o mesmo conteúdo, e isso encarece o uso real embora o preço por token pareça baixo.
O que esperar segundo o tipo de modelo
Os modelos abertos de tamanho médio costumam defender-se bem em classificação e extração com instruções claras, mas fraquejam em matizes dialetais e em manter registro formal durante textos longos. Os modelos proprietários grandes tendem a produzir castelhano mais natural, embora às vezes «sobrecorrijam» e gerem um espanhol neutro artificial que soa estranho a um leitor local. Nenhum ganha em tudo. Se o seu produto é para Espanha, teste explicitamente com exemplos que usem «vosotros» e léxico peninsular; se é para a América Latina, evite que o modelo imponha «ordenador» onde o seu usuário diz «computadora».
Passo 5: ajuste o prompt antes de mudar de modelo
Muitas diferenças entre modelos desaparecem com um system prompt bem escrito em espanhol. Inclua o idioma de saída de forma explícita, o registro desejado e um exemplo de resposta. Os modelos interpretam melhor as instruções quando o próprio prompt está no idioma-alvo, embora entendam inglês perfeitamente.
Teste esta sequência: primeiro otimize o prompt com o modelo A; depois aplique o mesmo prompt ao modelo B. Se B melhorar muito, o problema era o prompt e não o modelo. Se B continuar falhando nos mesmos exemplos, aí você tem uma limitação real que justifica a mudança.
Passo 6: decida com uma matriz, não com um palpite
Pontue cada candidato de 1 a 5 em quatro critérios ponderados segundo o seu caso: acerto na sua bateria, estabilidade entre execuções, custo total e latência. Multiplique pelo peso e some. Um modelo que tira 4 em acerto mas 2 em estabilidade raramente é a escolha correta para um fluxo automatizado.
Adicione uma coluna de «risco»: se o provedor não documenta o tratamento de dados em espanhol ou não oferece retenção zero, esse fator pode pesar mais que dois pontos de precisão. A transparência do provedor sobre os seus dados de treinamento é um sinal de qualidade, não um adorno.
Limitações que esta metodologia não resolve
Não avalia vieses culturais de forma sistemática, nem cobre idiomas cooficiais (catalão, galego, basco) a menos que você adicione exemplos próprios. Tampouco prevê o comportamento após uma atualização do provedor: os modelos mudam sem aviso e a sua bateria deve ser repetida periodicamente. E não substitui uma revisão humana em domínios regulados. Se o seu caso for de saúde ou jurídico, a validação por especialistas é obrigatória independentemente da pontuação.
Por último, tenha presente que o rendimento em espanhol não é uma propriedade fixa do modelo: depende do tokenizador, do comprimento do contexto e do domínio. Um modelo que brilha em conversação geral pode falhar em terminologia técnica do seu setor. A única comparação que importa é a que você executa com os seus dados, os seus parâmetros e os seus critérios de aceitação. O resto são pistas, não veredictos.