DEV Community: Lhayana Vieira

Você já ouviu falar do meme do monstro Shoggoth?

Lhayana Vieira — Sat, 17 Jan 2026 10:11:37 +0000

Ele é usado na comunidade de IA para representar o que acontece durante o pré-treino dos grandes modelos de linguagem. O Shoggoth é um monstro cheio de tentáculos e diversos olhos (quem curte literatura de terror vai identificar de onde ele vem). Ele é usado como metáfora para o modelo "cru", treinado com uma quantidade absurda de dados da internet, sem nenhum filtro nem curadoria.

Um fato bem conhecido sobre LLMs é que eles são feito para completar texto, não para ter diálogos. Ou seja, ele não entende o que faz uma resposta parecer humana. Além disso, como o conjunto de dados vem de todos os cantos da internet, o modelo acaba herdando também os piores comportamentos que encontra por lá.

Visto que ninguém quer criar um modelo incel (eu espero), o pós-treino visa corrigir isso. No Supervised Finetuning (SFT), o modelo começa a aprender a conversar, passando por um processo supervisionado em que humanos altamente qualificados criam exemplos de conversas que servem como demonstração.

Após o SFT, é aplicado o Reinforcement Learning from Human Feedback (RLHF), visando alinhar o comportamento da IA com as preferências humanas, que é basicamente o processo que coloca o rostinho sorridente no monstro.

Porém, esse alinhamento às preferências humanas pode gerar alguns problemas. O primeiro é que não existe uma moral universal. O que é o correto quando o assunto é desarmamento, por exemplo? Outro problema é quando há um descompasso entre o conhecimento interno do modelo e o conhecimento dado pelo feedback humano. Nesse caso, o modelo pode acabar confirmando as visões do usuário mesmo que não sejam verdade ou inventando fatos para parecer prestativo.

No fim, a jornada de transformar esse monstrinho em um produto confiável é um desafio. Tenho estudado essas questões de arquitetura e segurança no livro AI Engineering, da Chip Huyen, estou gostando bastante!

Para além do versionamento de código: modelos também devem ser versionados.

Lhayana Vieira — Sat, 17 Jan 2026 10:06:58 +0000

Se você já trabalhou com modelos de machine learning, sabe que devem ser testados vários modelos e parâmetros diferentes. Isso pode virar um caos.
Uma das principais ferramentas que veio para resolver esse problema foi o MLFlow.

Com ele, é possível gravar as principais métricas que você está usando no seu projeto e, com elas, comparar os modelos que você está testando. Essa comparação pode ser feita inclusive com gráficos, como o teste que fiz na imagem acima. Inclusive, nesse teste, não registrei apenas números, o MLflow salvou automaticamente minha matriz de confusão e a curva ROC junto com cada versão do modelo. Assim, consigo analisar visualmente onde cada algoritmo acertou ou errou, sem precisar rodar o código tudo de novo nem ficar anotando as métricas em uma planilha (já fiz muito isso).

Futuramente pretendo explorar como a ferramenta se comporta versionando LLMs, já que a versão mais recente traz um suporte específico pra GenAI.

O que você faz quando está fazendo uma prova e não sabe a resposta?

Lhayana Vieira — Sat, 17 Jan 2026 10:06:21 +0000

O que você faz quando está fazendo uma prova e não sabe a resposta?

Você chuta uma alternativa, certo? As LLMs também!

Foi essa analogia que esse paper recente da OpenAI fez para explicar as alucinações e eu achei genial.

As avaliações de uma resposta nas LLMs são binárias, dando 1 ponto para a resposta correta e 0 para a incorreta ou em branco (no caso, seria afirmar que não sabe). Isso acaba incentivando o "chute", visto que afirmar que não sabe é uma certeza de que o resultado da avaliação vai ser 0. O artigo chama isso de epidemia de penalização da incerteza.

Recomendo a leitura pra quem se interessa no tema: https://lnkd.in/dJbTcKmx.

Otimizando o uso da GPU no Google Colab

Lhayana Vieira — Sat, 10 May 2025 14:24:55 +0000

Estava fazendo o projeto de visão computacional do mestrado e, assim como todo treinamento de transformers, estava demorando muito. Comecei a cogitar pagar o google colab pro, pra poder usar a GPU A100, mas um colega me falou que não viu muita diferença comparado à GPU gratuita, a T4. Achei estranho, então fui pesquisar um pouco e descobri que, com alguns ajustes no modelo, é possível otimizar o uso da GPU. Então resolvi escrever sobre algumas dessas otimizações que me ajudaram a acelerar MUITO o fine-tuning, para caso alguém esteja com o mesmo problema. Vou explicar no contexto do meu projeto, que era a detecção de violência em vídeos.

Mixed Precision Training

Imagine que o seu modelo precisa "assistir" a sequência de frames do vídeo e "entender" o que está acontecendo em cada frame e como eles se relacionam no tempo para decidir se há violência. Para fazer isso, o modelo realiza milhões, talvez até bilhões, de operações matemáticas complexas em cada frame e entre os frames (que é algo que os modelos tansformers fazem muito bem, devido ao mecanismo de atenção).

Cada frame é uma imagem, que são são representadas por muitos números. Uma sequência de frames de um vídeo de alta resolução é uma quantidade ENORME de dados numéricos. O modelo transformer também tem muitos parâmetros (pesos), que também são números. Armazenar e processar todos esses números com a "precisão total" (FP32) exige uma quantidade gigantesca da memória da GPU. Isso limita o tamanho dos vídeos que você pode analisar de uma vez (batch size) ou a resolução dos frames que você pode usar. E fazer todas essas bilhões de contas com "precisão total" leva tempo. Mesmo com uma GPU poderosa, o treinamento (o processo de ensinar o modelo a detectar violência) pode ser muito lento.

Com mixed precision, o sistema decide que essas operações podem ser feitas usando a "meia precisão" (FP16), então a maior parte das operações dentro do seu transformer, como as que processam a informação de cada frame, calculam a atenção entre frames, ou transformam os dados através das camadas internas, não precisa de toda a precisão do FP32 o tempo todo. É como se, para a maior parte da análise visual e temporal dos frames, o modelo usasse uma representação numérica mais resumida. Isso usa metade da memória por número e, além disso, as GPUs do google colab têm unidades especiais (os chamados tensor cores da NVIDIA) que fazem contas em FP16 muito mais rápido do que em FP32.

O "conhecimento" do seu modelo, que são os pesos que ele aprende para identificar padrões de violência, continua sendo guardado com "precisão total" (FP32). Se eles continuassem sendo guardados em FP16, eles poderiam simplesmente virar zero devido à menor precisão do formato. É aí que entra o GradScaler: ele "amplifica" esses pequenos ajustes temporariamente para que eles não sumam durante os cálculos feitos em FP16. Depois que os cálculos são feitos, ele retorna os ajustes de volta ao tamanho original antes de usá-los para atualizar os pesos principais (que estão em FP32). Isso garante que o modelo possa aprender até os detalhes mais sutis que são necessários, mesmo usando FP16 para a maior parte do processamento.

Ajuste de batch_size

O batch_size representa quantos blocos de imagens (sequências de frames) são mostrados ao modelo de uma vez durante o treinamento. Quando você envia um batch maior, você dá mais trabalho para a GPU fazer em paralelo em vez de esperar por vários batches pequenos. Isso mantém as unidades de processamento da GPU mais ocupadas, levando a uma utilização melhor e maior velocidade no processamento de dados. O objetivo é usar o máximo de recursos da GPU sem estourar a memória, então processar mais exemplos de uma vez resulta em melhor aproveitamento da GPU.

Além disso, durante o treinamento, o modelo calcula o erro (loss) para cada batch e usa esse erro para calcular os gradientes (as direções de ajuste) para aquele batch específico. O gradiente é um vetor que aponta para a direção de maior aumento da função de perda (erro) em relação aos pesos do modelo naquele momento. Em termos simples, ele mostra como cada peso do modelo deve ser ajustado (para mais ou para menos, e quanto) para diminuir o erro de forma mais eficiente. Os pesos do modelo são então atualizados com base nesses gradientes calculados a partir do batch.

O gradiente calculado a partir de um batch é uma estimativa do gradiente "verdadeiro" que seria calculado se usássemos todo o conjunto de dados de treinamento (o que é impraticável). Um batch maior geralmente fornece uma estimativa de gradiente mais precisa e menos ruidosa do gradiente global, já que estamos calculando a média do "direcionamento" de erro sobre mais exemplos. Isso leva a um caminho de otimização mais estável e direto em direção ao mínimo da função de loss.

torch.backends.cudnn.benchmark

Essa configuração, quando configurada como True, instrui a biblioteca cuDNN (uma biblioteca da NVIDIA otimizada para operações de redes neurais que o PyTorch utiliza em GPUs) a encontrar e usar os algoritmos mais rápidos para as operações que ela executa para uma dada configuração específica de input e operação.

O que acontece é que, para cada tipo de operação matemática que o cuDNN otimiza (como as multiplicações de matrizes usadas intensivamente no seu modelo Transformer, ou possíveis convoluções iniciais) e para cada tamanho específico de dados de entrada que essa operação recebe pela primeira vez durante o treinamento, o cuDNN realiza internamente um pequeno teste. Ele executa essa mesma operação usando diferentes algoritmos que tem disponíveis e mede qual deles termina mais rápido na sua GPU atual com aqueles dados daquele tamanho. Uma vez encontrado o algoritmo mais veloz para essa configuração específica de operação e dados, o cuDNN armazena essa informação.

A mágica acontece nas centenas de milhares ou milhões de vezes seguintes que o seu modelo precisa executar exatamente essa mesma operação com os mesmos tamanhos de dados (o que ocorre repetidamente em cada passo de treinamento, batch após batch). Em vez de gastar tempo escolhendo um algoritmo ou usando um padrão que pode não ser o ideal, o cuDNN vai direto e usa o algoritmo mais rápido que ele descobriu no teste inicial. Isso resulta em uma aceleração significativa no tempo total de treinamento, pois as partes mais pesadas e repetitivas dos cálculos do seu modelo são executadas da maneira mais eficiente que a sua GPU permite para aquelas dimensões exatas, o que funciona muito bem quando os tamanhos de input do modelo (como frames de vídeo redimensionados) são consistentes.

O que são zero-shot, one-shot e few-shot learning em LLMs?

Lhayana Vieira — Wed, 26 Mar 2025 20:51:47 +0000

Hoje em dia todo mundo utiliza modelos de LLM gigantes gratuitamente via chat, o que é ótimo. Mas caso você queira desenvolver alguma aplicação específica, irá usar algum modelo pré-treinado menor, provavelmente algum gratuito do hugging face.

Caso você esteja utilizando um modelo menor (como o T5, por exemplo, que foi o que utilizei aqui para fazer os testes), existem alguma estratégias de criação de prompt que irão afetar o desempenho. Vamos supor que você quer envie esse prompt "Classifique esse review: Esse filme é muito bom! Sentimento:" esperando que ele diga se o sentimento será positivo ou negativo. Ele terá um desempenho ruim.

eu diria que “it’s amazing” não é bem um sentimento. minha psicóloga também.

Já o GPT-4o faz essa análise perfeitamente. Essa ténica de prompt de não dar nenhum exemplo se chama zero-shot inference.

Porém, se você adicionar um exemplo, o modelo menor irá funcionar melhor. Essa técnica é chamada de one-shot inference. Caso não funcione, você pode utilizar a few-shot inference, que imagino que já deu pra entender o que é (dar mais de um exemplo).

Caso dar vários exemplos ainda não funcione, as técnicas de prompt não irão te salvar, você irá precisar de um fine-tuning, que é o processo de ajustar o modelo ao seu conjunto de dados para melhorar o desempenho dele em alguma tarefa específica.

K-means não é o suficiente

Lhayana Vieira — Fri, 10 Jan 2025 14:53:49 +0000

Muito se fala sobre k-means quando o assunto é clusterização. E o objetivo desse post não é falar mal do algoritmo que minimiza a soma das distâncias quadradas entre os pontos de dados e seus centróides, afinal ele é genial. Mas é importante lembrar que, para usar o k-means, todo os seus dados precisam ser numéricos. E não, não vale usar one hot encoding nos categóricos, pois isso irá distorcer as distâncias euclidianas. Então, na vida real, nem sempre iremos conseguir usar o k-means.

O que usar, então? Como uma boa chata vou responder: depende!

Se seus dados são todos categóricos (como, por exemplo, dados populacionais de gênero, etnia, profissão, etc), você deve utilizar o k-modes, que ao invés de utilizar a média, utiliza a moda como medida central dos clusters.

Mas nem sempre todos os nossos dados são categóricos, muitas vezes há algumas features categóricas e outras numéricas. Se for o seu caso, use o k-prototypes. Esse algoritmo calcula a dissimilaridade de maneira separada para atributos numéricos e categóricos, e depois combina essas dissimilaridades usando uma soma ponderada.

Deixo abaixo alguns artigos para caso queiram se aprofundar um pouco sobre esses algoritmos:

E se você quiser se aprofundar BASTANTE, recomendo essa aula aqui, é excelente e bem completa.

Eu aprendi isso muito tempo depois de ter estudado sobre clusterização pela primeira vez, então resolvi fazer esse artigo, acredito que isso é algo que devia ser muito mais abordado do que é atualmente. Espero ter te ajudado!