image

Receba as melhores vagas +2.150 cursos em tech e IA

70
%OFF

IF

Iordan Filho19/08/2026 20:37
Compartir
IBM Bob: IA de Nível Empresarial para Desenvolvedores e Tech LeadersRecomendado para tiIBM Bob: IA de Nível Empresarial para Desenvolvedores e Tech Leaders

Treinei um modelo de linguagem do zero e a primeira coisa que quebrou foi a minha régua

    Passei alguns dias construindo um modelo de linguagem do zero: arquitetura, tokenizador, corpus, treino e avaliação. Sem framework pronto de treino, sem modelo pré-treinado baixado. Uma RTX 5060 de 8 GB e código meu.

    O modelo tem 27 milhões de parâmetros. É pequeno — o ChatGPT tem centenas de bilhões. Mas o objetivo nunca foi competir. Era entender o que acontece por dentro, e a única forma honesta de entender é construir.

    O que eu não esperava é que a lição mais importante não fosse sobre o modelo. Foi sobre como eu estava medindo o modelo.

    O que eu construí

    Quatro peças, todas minhas.

    O tokenizador, em duas estratégias sob a mesma interface: por caractere e BPE. Tokenizador é o que transforma texto em número, e a escolha dele muda tudo o que vem depois.

    O modelo, com arquitetura GPT e 27 milhões de parâmetros.

    O corpus, com pipeline de construção a partir de fontes diferentes. A maior: 1,55 GB de português corrido da Wikipédia, que viraram 496 milhões de tokens no disco.

    A avaliação, com scripts próprios para medir se o que sai da máquina presta.

    O treino final foram 45.000 passos em 2h27 de pré-treino, mais 10 minutos de ajuste fino em conversas.

    A régua estava medindo a coisa errada

    Aqui está a parte que eu quero contar.

    Eu tinha uma métrica que parecia razoável: contar quantas palavras o modelo inventa. Palavra inventada é o sintoma mais visível de um modelo pequeno — ele produz algo com cara de português, mas que não existe.

    Meu script marcava como inventada toda palavra que não aparecesse no material de treino de conversas.

    Isso funcionou enquanto o modelo só tinha visto conversas. Parou de funcionar no instante em que ele leu 1,55 GB de Wikipédia.

    Porque aí "hertz", "vertebrado" e "compressor" passaram a sair do modelo. Nenhuma delas estava nas conversas. Todas são palavras de verdade.

    Medindo daquele jeito, o modelo pré-treinado seria punido exatamente por aquilo que o pré-treino foi buscar. A tabela ia dizer que ele piorou, quando ele tinha melhorado.

    O conserto foi montar um dicionário a partir do corpus grande, guardando as palavras que aparecem três vezes ou mais: 1.422.647 palavras distintas viraram 566.812. E conferi nos dois sentidos antes de usar — palavras reais precisavam passar, palavras inventadas precisavam ser pegas.

    Com a régua consertada, o número real: a taxa de palavra inexistente caiu de 0,9% para 0,1%. O modelo grande que usei como referência faz 0,0%.

    A segunda régua torta

    O mesmo problema apareceu de outro jeito.

    A métrica padrão para modelo de linguagem é a perda por token. Comparei duas versões e a perda dizia 19,7% melhor.

    Só que os dois modelos usavam tokenizadores diferentes, e token não quer dizer a mesma coisa nos dois. Num deles, um token vale 3,66 caracteres. No outro, 3,15. Comparar "por token" é comparar réguas de tamanhos diferentes.

    Normalizando para a mesma unidade — por caractere, que é igual para todo mundo — a melhora real foi 6,6%.

    Continua sendo melhora. Mas 6,6% e 19,7% levam a decisões diferentes sobre onde investir o próximo treino.

    O que eu tirei disso

    Métrica é código, e código tem bug. Eu revisava o modelo e o treino com cuidado, e tratava o script de avaliação como se fosse verdade. Não é. Ele tem bug igual ao resto, e o bug dele é pior, porque leva você a decidir errado com confiança.

    Toda comparação precisa de uma unidade comum. Se dois números vêm de réguas diferentes, a diferença entre eles não quer dizer nada. Isso parece óbvio escrito assim, e não é nada óbvio no meio de uma tabela de resultados.

    Otimizar dá resultado, e dá para medir. Troquei a implementação da atenção pelo kernel fundido do PyTorch: o treino ficou 5,9x mais rápido consumindo 3,4 GB a menos. Em geração de texto em lote, de 65 segundos para 3. Não é chute — é medição antes e depois, na mesma máquina.

    Por que isso vale para quem está começando

    Não é preciso GPU de data center para aprender como um modelo de linguagem funciona. Uma placa de entrada, PyTorch e paciência resolvem.

    E se você for construir alguma coisa, construa também a forma de medir se ela funciona. Depois desconfie dessa medição, principalmente quando ela concordar com o que você queria ouvir.

    O modelo pequeno erra de um jeito que ensina. Um modelo grande acerta e você não descobre por quê.

    Compartir
    Recomendado para ti
    Itaú - Java com Inteligência Artificial
    Nublify - Primeiros passos em IA e Cloud
    IBM Bob: IA de Nível Empresarial para Desenvolvedores e Tech Leaders
    Comentarios (0)
    Recomendado para tiIBM Bob: IA de Nível Empresarial para Desenvolvedores e Tech Leaders