 |
| Bellacosa Mainframe e o fine tuning de llm |
☕ Um Café no Bellacosa Mainframe
Fine-Tuning de LLMs Descomplicado
O Que Todo Programador COBOL Padawan Precisa Saber Sobre Full Fine-Tuning, LoRA, QLoRA, SFT, DPO e RLHF na Era da Inteligência Artificial
"No Mainframe aprendemos cedo que não se recompila um sistema bancário inteiro para corrigir uma única regra de negócio. Então por que tantas pessoas fazem exatamente isso com modelos de Inteligência Artificial?"
Introdução
Se você trabalha há algum tempo com IBM Mainframe, provavelmente já participou de alguma situação parecida.
O banco precisava alterar apenas uma regra tributária.
A alteração estava concentrada em um único programa COBOL.
Mesmo assim alguém sugeriu:
"Vamos recompilar tudo."
A reação de qualquer analista experiente seria imediata.
— Para quê?
Afinal, recompilar centenas de programas significa consumir CPU, aumentar riscos, gerar mais testes, envolver homologação, aumentar o tempo de deploy e, principalmente, criar possibilidades de novos erros.
No mundo dos Large Language Models (LLMs), acontece exatamente a mesma coisa.
Muitos profissionais ouvem falar em Fine-Tuning e imaginam que exista apenas uma maneira de "ensinar" algo novo para uma IA.
Na prática, existem diversas estratégias.
Algumas alteram bilhões de parâmetros.
Outras modificam apenas alguns milhões.
Outras nem sequer alteram o modelo.
É exatamente essa diferença que separa projetos de milhares de dólares de projetos que podem ser treinados em uma única GPU doméstica.
Neste café vamos entender toda essa arquitetura utilizando comparações que fazem muito sentido para quem já viveu anos trabalhando com COBOL, CICS, DB2, VSAM e JCL.
Pegue seu café.
Hoje vamos abrir a tampa do motor da Inteligência Artificial.
Antes de falar em Fine-Tuning precisamos entender um Transformer
Imagine um programa COBOL enorme.
Não estamos falando de 3.000 linhas.
Imagine um sistema bancário com:
milhares de programas
centenas de COPYBOOKs
dezenas de módulos
chamadas CICS
SQL para DB2
VSAM
MQ
APIs REST
Agora imagine que tudo isso fosse compactado em um único conjunto gigantesco de matrizes matemáticas.
Esse conjunto é o modelo.
Um Transformer moderno possui dezenas ou centenas de camadas (Layers).
Visualmente podemos imaginar algo assim:
Entrada
↓
Embedding
↓
Layer 1
↓
Layer 2
↓
Layer 3
↓
...
↓
Layer 80
↓
Saída
Cada Layer possui milhões de parâmetros.
Juntos eles representam o conhecimento aprendido.
O que são parâmetros?
Se você nunca estudou Redes Neurais, imagine um enorme arquivo VSAM contendo bilhões de pequenos números.
Cada número representa um ajuste aprendido durante o treinamento.
Exemplo:
0.834829
↓
0.834841
A diferença parece insignificante.
Mas quando bilhões desses valores são alterados ao mesmo tempo...
O comportamento inteiro do modelo muda.
Esses números são chamados de pesos (weights).
Treinar uma IA significa simplesmente alterar esses pesos.
Nada mais.
Nada menos.
Pense como um Programador COBOL
Imagine um sistema bancário.
Você possui:
Programa COBOL
COPYBOOKS
CICS
DB2
JCL
Agora alguém pede:
"Ensine esse sistema a emitir PIX internacional."
Você possui diversas opções.
Pode alterar somente um COPYBOOK.
Pode alterar apenas um módulo.
Pode criar um novo programa.
Ou pode reescrever absolutamente tudo.
No universo dos LLMs acontece exatamente a mesma coisa.
O espectro do Fine-Tuning
Muitos iniciantes acreditam que Fine-Tuning é uma técnica.
Na realidade ele é um conjunto de técnicas.
Podemos organizar assim:
Prompt Engineering
↓
RAG
↓
SFT
↓
LoRA
↓
QLoRA
↓
Full Fine-Tuning
↓
DPO
↓
RLHF
Quanto mais descemos...
Maior o custo.
Maior o consumo de GPU.
Maior a complexidade.
Maior o tempo de treinamento.
Prompt Engineering
É a primeira ferramenta.
E curiosamente...
É a mais barata.
Você não altera absolutamente nada no modelo.
É como escrever uma JCL melhor.
O programa continua exatamente igual.
Você apenas fornece instruções mais inteligentes.
Exemplo:
Você é um especialista em COBOL IBM Enterprise COBOL 6.5.
Explique COMP-3.
Utilize exemplos bancários.
Responda em português.
Nenhum parâmetro foi alterado.
Nenhum peso foi modificado.
Mesmo assim a qualidade melhora bastante.
RAG
Agora imagine outra situação.
Seu programa COBOL precisa consultar um novo cadastro.
Você faria o quê?
Reescreveria todo o sistema?
Claro que não.
Bastaria consultar um novo banco de dados.
É exatamente isso que faz o RAG.
Pergunta
↓
Busca documentos
↓
Envia ao LLM
↓
Resposta
O modelo continua congelado.
Quem muda é apenas o conhecimento disponível durante a consulta.
Por isso dizemos:
RAG adiciona memória.
Não inteligência.
Quando NÃO devemos fazer Fine-Tuning
Esse talvez seja o maior erro da indústria.
Imagine que sua empresa possui:
manuais
normas
PDFs
contratos
documentação interna
Alguém diz:
"Vamos treinar um LLM com tudo isso."
Provavelmente está desperdiçando dinheiro.
RAG resolve praticamente todos esses casos.
Full Fine-Tuning
Agora chegamos ao método clássico.
Todos os parâmetros são atualizados.
Visualmente:
Layer 1
Treina
↓
Layer 2
Treina
↓
Layer 3
Treina
↓
...
↓
Layer N
Treina
Nada permanece congelado.
Tudo muda.
Por que isso é tão caro?
Vamos imaginar um modelo de 70 bilhões de parâmetros.
Todos eles precisarão:
armazenar gradientes
calcular derivadas
atualizar pesos
salvar checkpoints
Isso exige dezenas de GPUs profissionais.
Em muitos casos:
Centenas.
Analogia Mainframe
É como recompilar:
COBOL
PL/I
Natural
CICS
MQ
DB2
JCL
COPYBOOKS
Tudo.
Mesmo que apenas um programa precisasse mudar.
Faz sentido?
Na maioria das vezes...
Não.
Onde Full Fine-Tuning ainda faz sentido?
Modelos médicos.
Modelos militares.
Modelos científicos.
Modelos jurídicos extremamente especializados.
Ou quando estamos criando um novo modelo base.
Fora isso...
Existem alternativas melhores.
A Revolução Chamada LoRA
Em 2021 surgiu uma ideia brilhante.
E se...
Em vez de alterar bilhões de parâmetros...
Nós adicionássemos pequenas correções?
Foi exatamente isso que o artigo LoRA propôs.
O modelo original permanece intacto.
Quem aprende são pequenos adaptadores.
Visualmente:
Modelo Original
↓
Congelado
+
Adaptadores
↓
Aprendem
O que significa Low Rank?
Aqui entra um pouco de matemática.
Imagine uma matriz enorme:
4096 x 4096
Em vez de aprender tudo isso...
LoRA aprende duas matrizes muito menores.
4096 x 16
+
16 x 4096
A multiplicação das duas aproxima a alteração necessária.
Resultado?
Muito menos parâmetros.
Muito menos memória.
Muito menos GPU.
Analogia COBOL
Imagine um programa de 40.000 linhas.
Você não altera tudo.
Você cria uma rotina adicional.
Algo parecido com um módulo externo.
Na execução...
O sistema utiliza:
Programa Original
Nova Rotina
Essa nova rotina corresponde ao adaptador LoRA.
Vantagens do LoRA
Economia.
Rapidez.
Facilidade.
Possibilidade de possuir dezenas de especializações diferentes para o mesmo modelo.
Imagine um único Llama.
E vários LoRAs.
Llama
↓
LoRA Jurídico
↓
LoRA Médico
↓
LoRA COBOL
↓
LoRA DevOps
↓
LoRA SAP
Todos compartilham exatamente o mesmo modelo base.
QLoRA
Agora vem outra inovação.
E se...
Além de congelar o modelo...
Nós comprimíssemos sua memória?
É isso que faz o QLoRA.
O modelo base é armazenado em apenas 4 bits.
Mas atenção.
Esse é um detalhe extremamente importante.
Os adaptadores continuam treinando normalmente em maior precisão, como FP16 ou BF16.
Isso evita perda excessiva de qualidade durante o aprendizado.
Quantização
Imagine uma fotografia.
Original:
16 milhões de cores.
Depois:
256 cores.
Ela ocupa muito menos espaço.
Com os modelos acontece algo semelhante.
Menos bits.
Menos memória.
Mais eficiência.
Analogia Mainframe
É como compactar um dataset utilizando um formato extremamente eficiente.
O conteúdo continua disponível.
Mas ocupa muito menos disco.
SFT – Supervised Fine-Tuning
Aqui começamos a ensinar comportamento.
Não conhecimento.
A diferença é enorme.
Imagine um professor.
Ele entrega:
Pergunta.
Resposta correta.
Pergunta.
Resposta correta.
Pergunta.
Resposta correta.
O modelo aprende imitando.
Exemplo:
Pergunta
Explique VSAM.
↓
Resposta ideal.
↓
Treinamento.
Onde usamos SFT?
Chatbots corporativos.
Assistentes técnicos.
Documentação.
Atendimento.
Programação.
Explicações.
Tudo isso normalmente começa com SFT.
DPO – Direct Preference Optimization
Imagine que existam duas respostas.
Resposta A.
Resposta B.
Um especialista diz:
"A ficou muito melhor."
O DPO aprende exatamente isso.
Ele não precisa calcular recompensas complexas.
Ele apenas aprende qual saída deve ser preferida.
É extremamente elegante.
Analogia COBOL
Imagine dois programas.
Os dois compilam.
Os dois executam.
Mas apenas um segue corretamente a especificação do banco.
O DPO aprende a favorecer esse comportamento.
RLHF
Agora chegamos ao método mais sofisticado.
Reinforcement Learning from Human Feedback.
O fluxo é enorme.
Modelo
↓
Respostas
↓
Humanos avaliam
↓
Reward Model
↓
PPO
↓
Novo treinamento
Existe inclusive um segundo modelo.
O Reward Model.
Ele aprende a dar notas.
Depois outro algoritmo utiliza essas notas para melhorar o modelo principal.
É poderoso.
Mas extremamente caro.
Por que DPO ficou tão popular?
Porque elimina boa parte dessa complexidade.
Em muitos cenários.
SFT + DPO produz resultados muito próximos ao RLHF.
Com muito menos custo.
O maior erro das empresas
Muitas organizações ainda pensam assim:
Preciso melhorar o modelo.
↓
Fine-Tuning.
Essa pergunta está errada.
A pergunta correta é:
"O que realmente precisa mudar?"
Talvez apenas o prompt.
Talvez apenas o RAG.
Talvez um LoRA.
Talvez um SFT.
Talvez nenhum treinamento.
O que a imagem não mostra
O universo de PEFT (Parameter Efficient Fine-Tuning) vai muito além do LoRA.
Hoje existem técnicas como:
AdaLoRA
DoRA
IA³
Prefix Tuning
Prompt Tuning
P-Tuning v2
VeRA
LoKr
LoHa
OFT
BOFT
Todas elas têm o mesmo objetivo:
Treinar menos.
Aprender mais.
Consumir menos GPU.
Misturando Adaptadores
Outra grande vantagem.
Você pode carregar múltiplos adaptadores.
Imagine:
Modelo Base
↓
LoRA Financeiro
↓
LoRA RH
↓
LoRA Jurídico
↓
LoRA Mainframe
Dependendo da tarefa...
Você ativa apenas o adaptador correspondente.
É como carregar módulos diferentes em uma aplicação COBOL sem alterar o núcleo do sistema.
Catastrophic Forgetting
No Full Fine-Tuning existe um risco importante.
Ao aprender demais um novo domínio...
O modelo pode esquecer conhecimentos antigos.
É o chamado Catastrophic Forgetting.
Como o LoRA preserva o modelo original congelado, esse problema tende a ser muito menor.
O Futuro
A tendência da indústria é clara.
Pouquíssimas empresas treinam modelos gigantes do zero.
A maioria utiliza modelos abertos como:
Llama
Mistral
Qwen
Gemma
DeepSeek
Depois aplica:
Prompt Engineering
RAG
LoRA
QLoRA
SFT
DPO
Conseguindo resultados excelentes com custos muito menores.
O Café do Bellacosa ☕
Quando comecei minha carreira em Mainframe, aprendi uma lição que continua verdadeira décadas depois.
O melhor engenheiro não é aquele que modifica mais código.
É aquele que modifica apenas o necessário.
Essa filosofia aparece em praticamente tudo que fazemos em TI.
No COBOL, evitamos recompilar aplicações inteiras para uma pequena mudança de negócio.
No DB2, preferimos ajustar um índice ou um plano de acesso antes de reescrever consultas complexas.
No CICS, alteramos uma transação ou um programa específico, não toda a região.
No z/OS, aplicamos um PTF em vez de reinstalar o sistema operacional.
Na Inteligência Artificial, a lógica é exatamente a mesma.
Nem todo problema exige Full Fine-Tuning.
Nem todo projeto precisa de RLHF.
Muitas vezes, um bom Prompt Engineering resolve o problema. Em outras, um RAG bem construído fornece o conhecimento necessário. Quando o desafio é adaptar o comportamento do modelo, LoRA ou QLoRA costumam oferecer uma relação extraordinária entre custo e benefício. Se o objetivo é ensinar exemplos de respostas ideais, o SFT é o caminho natural. E quando precisamos alinhar preferências de forma eficiente, o DPO surge como uma alternativa elegante ao complexo pipeline do RLHF.
O verdadeiro arquiteto de IA não escolhe a ferramenta mais sofisticada.
Escolhe a ferramenta mais adequada.
Assim como um bom programador COBOL sabe que nem toda alteração exige recompilar milhares de programas, um bom engenheiro de IA entende que o segredo não está em treinar mais, mas em treinar melhor.
No fim das contas, Fine-Tuning não é uma única técnica. É um conjunto de estratégias, cada uma com objetivos, custos e impactos diferentes. Compreender o que realmente está sendo atualizado dentro do modelo é a diferença entre um projeto sustentável e um desperdício de GPUs, tempo e dinheiro.
E talvez essa seja a maior lição deste café: a evolução da Inteligência Artificial não elimina os princípios da Engenharia de Software que aprendemos no Mainframe. Pelo contrário, ela os reforça. Planejamento, eficiência, reutilização, modularidade e otimização continuam sendo as bases dos grandes sistemas — apenas mudaram de cenário.
Porque, seja ajustando um programa COBOL em um IBM Z ou adaptando um LLM de bilhões de parâmetros, a pergunta continua a mesma:
"O que realmente precisa ser alterado?"
Quando você sabe responder a essa pergunta, deixa de apenas usar Inteligência Artificial e passa a projetá-la com a mesma disciplina e maturidade que fizeram do Mainframe a plataforma mais confiável da história da computação.
