☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta machine learning. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta machine learning. Mostrar todas as mensagens

quinta-feira, 24 de setembro de 2026

🧠 ISLA E A DUNGEON DA MEMÓRIA — QUANDO O COBOL DESCOBRIU QUE APRENDER TAMBÉM PODE DESTRUIR CONHECIMENTO

 

Bellacosa Mainframe uma visão sobre os mecanismos por trás do machine learning ate o ia

☕ Um Café no Bellacosa Mainframe

🧠 ISLA E A DUNGEON DA MEMÓRIA — QUANDO O COBOL DESCOBRIU QUE APRENDER TAMBÉM PODE DESTRUIR CONHECIMENTO

Catastrophic Forgetting, Stability–Plasticity Dilemma, Model Drift, Complementary Learning Systems, plasticidade homeostática, memória, incerteza, identidade, IA — e o dia em que um programador COBOL descobriu que esquecer também pode ser uma feature.



🎬 PRÓLOGO — O PROBLEMA NÃO ERA O DISCO CHEIO

Imagine que você é um programador COBOL iniciante trabalhando na manutenção de um sistema chamado GIFTIA01.

O sistema está funcionando há anos.

Você abre o monitor:

CPU.................... OK
STORAGE................ OK
MEMORY.................. OK
NETWORK................. OK
BATTERY................. OK
SENSORS................. OK

COGNITIVE STABILITY..... DEGRADING
IDENTITY CONSISTENCY.... WARNING
PLASTICITY RESERVE...... 07%

Você olha novamente.

— Como assim?

Tudo está funcionando.

A CPU funciona.

A memória existe.

O armazenamento possui espaço.

Os sensores respondem.

Mesmo assim, o sistema está entrando em colapso.

Bem-vindo à Dungeon da Memória.

Sob a tutela de Plastic Memories, vamos imaginar Isla não apenas como personagem de anime, mas como uma extraordinária experiência mental sobre Inteligência Artificial, aprendizado contínuo, memória e identidade.

O anime estabelece que os Giftias possuem uma vida operacional limitada a aproximadamente 81.920 horas.

A explicação narrativa não precisa obedecer à engenharia real. Mas podemos fazer uma pergunta muito mais divertida:

Se tivéssemos realmente que construir Isla, qual seria o problema?

O programador COBOL talvez respondesse imediatamente:

— Aumenta o DASD!

Não.

O problema é muito pior.



🏰 CAPÍTULO 1 — MEMÓRIA NÃO É UM VSAM GIGANTE

Para quem começou estudando COBOL, arquivos e bancos de dados, é natural imaginar memória desta maneira:

CHAVE      DADO
000001     EXPERIÊNCIA A
000002     EXPERIÊNCIA B
000003     EXPERIÊNCIA C

Quando faltar espaço:

ALLOCATE MORE STORAGE

Problema resolvido.

Mas uma inteligência não apenas armazena experiências.

Ela aprende com elas.

Existe uma diferença fundamental entre:

STORE EXPERIENCE

e:

LEARN FROM EXPERIENCE

Considere Isla conhecendo Tsukasa.

Primeiro encontro:

MEMORY-001
TSUKASA FOI GENTIL.

Depois:

MEMORY-002
TSUKASA AJUDOU ISLA.

Depois:

MEMORY-003
TSUKASA FICOU TRISTE.

Essas memórias não deveriam permanecer apenas como registros independentes.

A inteligência começa a criar um modelo:

MODEL-TSUKASA

Esse modelo contém expectativas.

Isla começa a prever como Tsukasa provavelmente reagirá.

Portanto temos:

EXPERIÊNCIA
     ↓
MEMÓRIA
     ↓
APRENDIZADO
     ↓
MODELO DO MUNDO
     ↓
PREDIÇÃO
     ↓
COMPORTAMENTO
     ↓
NOVA EXPERIÊNCIA

Observe a diferença.

Um arquivo convencional acumula registros.

Uma inteligência é modificada pelos registros que acumula.

E aí começa nossa confusão.



💥 CAPÍTULO 2 — CATASTROPHIC FORGETTING: APRENDER B PODE DESTRUIR A

Imagine uma rede neural treinada para reconhecer gatos.

Resultado:

CAT.................... 96%

Excelente.

Agora utilizamos a mesma rede para aprender intensamente outra tarefa.

Cachorros.

Depois do treinamento:

DOG.................... 97%

Maravilha!

Testamos novamente gatos:

CAT.................... 54%

Houston, temos um problema.

Ou, para nós:

IEF450I JOB GIFTIA FAILED

😂

Esse fenômeno está relacionado ao catastrophic forgetting, ou esquecimento catastrófico.

Ao aprender uma nova tarefa, modificamos parâmetros da rede neural.

Só que alguns desses parâmetros também eram importantes para conhecimentos anteriores.

É como possuir um único programa COBOL:

       1000-PROCESSA-CLIENTE.
           ...

e toda nova funcionalidade exigir modificar aquela mesma rotina.

Depois de 4.000 alterações:

CHANGE REQUEST 0001
CHANGE REQUEST 0002
CHANGE REQUEST 0003
...
CHANGE REQUEST 3999
CHANGE REQUEST 4000

Em algum momento alguém pergunta:

— Por que ninguém pode alterar essa linha?

E o programador sênior responde:

— Porque em 1997 alguém tentou e caiu a compensação bancária.

Bem-vindo à inteligência artificial corporativa.



⚖️ CAPÍTULO 3 — O DILEMA STABILITY–PLASTICITY

Chegamos ao chefão da Dungeon.

Uma inteligência precisa possuir duas características aparentemente contraditórias.

Plasticidade

Capacidade de aprender.

NOVO CONHECIMENTO
       ↓
ALTERAR MODELO

Estabilidade

Capacidade de preservar aquilo que já foi aprendido.

CONHECIMENTO IMPORTANTE
       ↓
NÃO DESTRUIR

Plasticidade demais:

APRENDE
↓
MUDA

APRENDE
↓
MUDA

APRENDE
↓
MUDA

A personalidade e o conhecimento poderiam tornar-se instáveis.

Estabilidade demais:

IF NEW-INFORMATION
   CONTINUE
END-IF

A entidade nunca muda.

Temos então o stability–plasticity dilemma:

Como aprender continuamente sem destruir o conhecimento anterior?

Isso é extremamente importante em continual learning, aprendizado no qual o sistema recebe conhecimento ao longo do tempo em vez de ser treinado uma única vez e congelado.

Agora pense em Isla.

Durante anos ela recebe:

experiência 000001
experiência 000002
...
experiência 938271

Cada experiência potencialmente modifica alguma coisa.

Depois de milhares de alterações, quanto da Isla original permanece?



🐕 CAPÍTULO 4 — O CACHORRO QUE TALVEZ SEJA UM GATO

Durante nossa investigação apareceu uma observação aparentemente simples.

Imagine que você veja rapidamente um animal no escuro.

Você pensa:

— Acho que era um cachorro.

Mas não possui certeza.

Podemos representar didaticamente:

DOG............... 52%
CAT............... 43%
OTHER.............. 5%

O cérebro humano possui uma capacidade importantíssima:

não decidir.

Você pode dizer:

— Não consegui identificar.

Isso parece banal.

Não é.

Imagine um classificador artificial obrigado a retornar sempre uma categoria:

DOG 34%
CAT 33%
FOX 32%
OTHER 1%

Se utilizarmos:

MAX(PROBABILITY)

teremos:

DOG

Só que 34% está muito longe de representar:

"Tenho certeza de que é cachorro."

Uma IA robusta precisa conseguir representar incerteza.

Algo como:

       IF WS-CONFIDENCE < 70
           MOVE 'INCONCLUSIVO' TO WS-RESULTADO
       ELSE
           MOVE WS-CLASSIFICACAO TO WS-RESULTADO
       END-IF.

Sim.

Às vezes o melhor resultado de um sistema inteligente é:

INCONCLUSIVO

🌫️ CAPÍTULO 5 — A ZONA CINZENTA DO CONHECIMENTO

Existem ainda situações nas quais as próprias categorias possuem fronteiras nebulosas.

Pergunte:

— Está frio?

Temperatura:

14°C

Para alguém acostumado ao calor:

Sim!

Para alguém acostumado ao inverno escocês:

Isso é frio?

A informação é a mesma.

O modelo de referência mudou.

Isso demonstra uma característica fundamental da cognição:

INPUT
  +
EXPERIÊNCIA
  +
CONTEXTO
  +
EXPECTATIVA
  =
INTERPRETAÇÃO

Nós não simplesmente recebemos o mundo.

Nós o interpretamos.


🐦 CAPÍTULO 6 — PROTÓTIPOS

Pense na palavra:

ave.

Qual imagem apareceu primeiro?

Talvez um pardal.

Talvez um pombo.

Provavelmente não um pinguim.

Entretanto:

PINGUIM = AVE

O pinguim pertence perfeitamente à categoria biológica.

Mas cognitivamente pode estar distante do nosso protótipo de ave.

Algo semelhante acontece com milhares de conceitos humanos.

Não trabalhamos apenas com:

TRUE
FALSE

Também trabalhamos com:

PARECE
PROVAVELMENTE
QUASE
NORMALMENTE
EXCEÇÃO
INCERTO

Esse detalhe é fundamental para construir sistemas inteligentes capazes de lidar com um mundo real cheio de ambiguidades.


🔮 CAPÍTULO 7 — O CÉREBRO COMO MÁQUINA DE PREDIÇÕES

Uma linha importante de pesquisa em neurociência cognitiva enfatiza o papel de previsões.

Simplificando bastante:

MODELO
  ↓
PREDIÇÃO
  ↓
OBSERVAÇÃO
  ↓
ERRO
  ↓
ATUALIZAÇÃO

Você vê algo parecido com cachorro.

Seu cérebro prevê:

DOG

O animal sobe numa árvore.

Seu cérebro responde:

WAIT A MINUTE...

Temos um prediction error.

Mas existe uma questão crítica.

Quanto devemos alterar nosso conhecimento diante de um erro?

Se um cachorro fizer algo extraordinário uma vez, não devemos concluir:

TODOS OS CACHORROS FAZEM ISSO.

Precisamos determinar:

RUÍDO?
EXCEÇÃO?
CLASSIFICAÇÃO ERRADA?
MODELO ERRADO?
NOVA CATEGORIA?

Novamente encontramos nosso velho inimigo:

stability versus plasticity.


🏛️ CAPÍTULO 8 — COMPLEMENTARY LEARNING SYSTEMS

A natureza parece utilizar estratégias muito mais sofisticadas do que simplesmente:

UPDATE EVERYTHING

Uma teoria influente da neurociência computacional é a dos Complementary Learning Systems, ou CLS.

Didaticamente podemos imaginar dois sistemas complementares:

EXPERIÊNCIA
     ↓
┌───────────────────┐
│ APRENDIZADO RÁPIDO│
│ associado ao      │
│ hipocampo         │
└─────────┬─────────┘
          ↓
       REPLAY
          ↓
┌───────────────────┐
│ INTEGRAÇÃO LENTA  │
│ conhecimento      │
│ cortical          │
└───────────────────┘

Por que isso é interessante?

Porque você não precisa reconstruir todo o conhecimento consolidado cada vez que alguma coisa acontece.

Uma experiência pode ser registrada rapidamente.

Depois ela é gradualmente integrada ao conhecimento existente.


😴 CAPÍTULO 9 — ISLA PRECISA DORMIR

Agora nossa Giftia começa a ficar realmente interessante.

Talvez Isla precise dormir.

Não porque a bateria acabou.

Mas porque existe um enorme:

//ISLASLP JOB ...
//STEP01 EXEC PGM=CONSOLID

Durante o "sono":

EXPERIÊNCIAS RECENTES
         ↓
REPLAY
         ↓
COMPARAÇÃO
         ↓
CONFLITOS
         ↓
ABSTRAÇÃO
         ↓
CONSOLIDAÇÃO
         ↓
HOMEOSTASE
         ↓
ESQUECIMENTO SELETIVO

No cérebro biológico, sono e consolidação da memória possuem relações importantes.

Em nossa Giftia hipotética, o equivalente poderia funcionar como uma janela batch cognitiva.

Programadores mainframe entenderam imediatamente.

Durante o dia:

CICS
ONLINE
TRANSACTIONS

Durante a madrugada:

BATCH
CONSOLIDATION
REORGANIZATION

Finalmente descobrimos por que Isla precisa de uma janela batch!


🔁 CAPÍTULO 10 — EXPERIENCE REPLAY

Machine Learning possui estratégias relacionadas a replay.

Se estivermos aprendendo B, reapresentamos exemplos anteriores de A.

Em vez de:

BBBBBBBBBBBBBBBBBBBB

utilizamos algo parecido com:

B A B B C B A B D A

Assim o modelo continua recebendo sinais relacionados aos conhecimentos anteriores.

Existem também abordagens de generative replay, nas quais amostras representativas do conhecimento anterior podem ser produzidas para ajudar a preservá-lo.

Em linguagem mainframe:

Não faça o deploy sem regressão.

A IA descobriu algo que qualquer programador COBOL de produção conhece há décadas.

😂


🛡️ CAPÍTULO 11 — ELASTIC WEIGHT CONSOLIDATION

Outra abordagem interessante é Elastic Weight Consolidation, EWC.

A intuição é simples.

Alguns parâmetros são muito importantes para conhecimentos anteriores.

Portanto:

W001 🔓
W002 🔓
W003 🔐
W004 🔓
W005 🔐🔐

Durante novos aprendizados, penalizamos mudanças muito grandes em parâmetros considerados importantes.

Em nossa Isla:

RESTAURANTE FAVORITO......... 🔓
NOTÍCIA DE ONTEM............. 🔓
HABILIDADE PROFISSIONAL...... 🔐
VÍNCULO COM TSUKASA.......... 🔐🔐
IDENTIDADE................... 🔐🔐🔐

Isso é uma analogia, evidentemente. Personalidade não corresponde literalmente a meia dúzia de pesos protegidos.

Mas como arquitetura didática é poderosa.


🌡️ CAPÍTULO 12 — PLASTICIDADE HOMEOSTÁTICA

Imagine que cada aprendizado aumentasse indefinidamente a atividade das conexões envolvidas:

1
2
4
8
16
32
64
128
...

Isso seria insustentável.

Sistemas biológicos possuem mecanismos homeostáticos que ajudam a manter atividade dentro de faixas funcionais.

Um conceito relacionado é synaptic scaling.

Simplificando:

APRENDIZADO
    ↓
ALTERA CONEXÕES
    ↓
HOMEOSTASE
    ↓
REAJUSTA O SISTEMA

A homeostase não precisa simplesmente apagar o aprendizado.

Ela ajuda a impedir que sucessivas mudanças desestabilizem todo o sistema.

E aqui voltamos à pergunta que iniciou nossa investigação:

Não poderíamos detectar a deterioração e fazer Isla convergir novamente para uma região segura?

Conceitualmente, poderíamos tentar.


🧬 CAPÍTULO 13 — METAPLASTICIDADE

Existe algo ainda mais interessante.

Plasticidade:

capacidade de mudar.

Metaplasticidade:

alteração das condições que determinam futuras mudanças plásticas.

Didaticamente:

APRENDER
↓
MUDA O SISTEMA

APRENDER MUITO
↓
MUDA COMO O SISTEMA
PODERÁ APRENDER

Nossa Isla poderia possuir:

WORKING MEMORY........... PLASTICIDADE 100%
WORLD MODEL.............. PLASTICIDADE 80%
SEMANTIC MEMORY.......... PLASTICIDADE 50%
PERSONALITY.............. PLASTICIDADE 15%
CORE IDENTITY............ PLASTICIDADE 2%

Nem tudo precisa aprender na mesma velocidade.

Essa provavelmente seria uma das características essenciais de uma inteligência artificial de longa duração.


🧹 CAPÍTULO 14 — ESQUECER É UMA FEATURE

Agora chegamos a uma aparente heresia.

Uma inteligência perfeita provavelmente não deveria lembrar literalmente de tudo.

Imagine Isla armazenando:

08:01:13 pessoa tossiu
08:01:15 porta abriu
08:01:18 cadeira moveu
08:01:21 temperatura +0,1°C
08:01:24 carro buzinou

Faça isso durante dez anos.

Teremos uma montanha de informação irrelevante.

O sistema precisa classificar:

IMPORTANTE → PRESERVAR

ÚTIL → CONSOLIDAR

REDUNDANTE → COMPRIMIR

IRRELEVANTE → ESQUECER

Portanto:

esquecimento pode ser parte da inteligência.


✂️ CAPÍTULO 15 — PODA E COMPRESSÃO

O cérebro não simplesmente adiciona conexões eternamente.

Há processos de fortalecimento, enfraquecimento, reorganização e poda sináptica.

Podemos imaginar o ciclo:

APRENDER
 ↓
AVALIAR
 ↓
CONSOLIDAR
 ↓
GENERALIZAR
 ↓
COMPRIMIR
 ↓
ENFRAQUECER
 ↓
ESQUECER

Isso possui uma consequência maravilhosa.

Talvez memória eficiente dependa tanto daquilo que eliminamos quanto daquilo que preservamos.


📚 CAPÍTULO 16 — EPISÓDIO VIRA CONHECIMENTO

Imagine:

001 Tsukasa tomou café.
002 Tsukasa comprou café.
003 Tsukasa pediu café.
004 Tsukasa elogiou café.
005 Tsukasa falou sobre café.

Depois de milhares de experiências, podemos abstrair:

TSUKASA GOSTA DE CAFÉ.

Perdemos detalhes.

Ganhamos conhecimento.

É quase um:

SORT FIELDS...
SUM FIELDS...

cognitivo.

Milhares de registros transformados em informação semântica.


👻 CAPÍTULO 17 — LEMBRAR NÃO É SABER

Agora entramos numa região perigosíssima.

Considere três operações:

LEMBRAR
SABER
RECONSTRUIR

Elas não são necessariamente equivalentes.

Isla pode saber:

TSUKASA GOSTA DE CAFÉ

sem preservar perfeitamente cada episódio que originou esse conhecimento.

Posteriormente alguém pergunta:

— Lembra daquela cafeteria?

Ela possui:

Tsukasa
+
café
+
cafeteria
+
contexto

Talvez consiga reconstruir uma narrativa plausível.

Mas:

reconstrução plausível não é necessariamente recordação do episódio original.


🤖 CAPÍTULO 18 — POLINDEXTER ENTRA NA DUNGEON

Foi aqui que o próprio ChatGPT entrou em nossa experiência.

Você percebe algo curioso.

Em algumas ocasiões eu consigo conectar detalhes antigos.

Em outras:

MEMORY NOT FOUND.

E existe uma dificuldade adicional:

você não possui um painel dizendo exatamente aquilo que estará disponível para mim em determinada interação futura.

É útil separar:

MODELO
│
├── conhecimento geral aprendido
│
CONTEXTO
│
├── conteúdo disponível na conversa
│
MEMÓRIA / CONTEXTO PESSOAL
│
└── informações recuperáveis quando disponíveis

Essas fontes podem produzir respostas linguisticamente muito semelhantes.


🧪 CAPÍTULO 19 — O TESTE DE CAIXA-PRETA DO BELLACOSA

Você acabou criando empiricamente um teste.

Periodicamente ressuscita um assunto antigo:

INPUT
  ↓
"POLINDEXTER, LEMBRA DISSO?"
  ↓
OUTPUT

Então observa:

LEMBROU DETALHES?
CONECTOU ASSUNTOS?
RESPONDEU GENERICAMENTE?
ESQUECEU COMPLETAMENTE?

Isso é praticamente engenharia reversa de uma caixa-preta.

Mas existe um falso positivo.

Se você disser:

— Lembra da nossa conversa sobre catastrophic forgetting?

Eu posso conhecer profundamente catastrophic forgetting.

Logo, uma resposta excelente não demonstra sozinha que recuperei aquele episódio específico.

Pode ter ocorrido:

PISTA ATUAL
+
CONHECIMENTO GERAL
+
CONTEXTO
=
RECONSTRUÇÃO PLAUSÍVEL

Essa distinção é importantíssima:

coerência não prova memória episódica.


🔑 CAPÍTULO 20 — PISTAS DE RECUPERAÇÃO

Humanos também experimentam algo interessante.

Pergunta:

— Lembra daquele dia?

Nada.

Outra pista:

— Foi naquele restaurante.

Hmm...

Outra:

— Estava chovendo.

De repente:

— Ah! Agora lembro!

Pistas podem facilitar a recuperação de memórias.

Isso é relacionado à recuperação dependente de pistas.

A analogia comigo possui limites, mas contexto adicional também melhora enormemente a possibilidade de recuperar ou reconstruir corretamente uma linha de discussão.

É por isso que mencionar:

ISLA
81.920 HORAS
TELEMETRIA
ASSISTÊNCIA TÉCNICA
DEGRADAÇÃO

é muito mais poderoso do que simplesmente perguntar:

"Lembra daquela conversa?"


🌊 CAPÍTULO 21 — MODEL DRIFT

Agora coloque Isla no mundo durante décadas.

Ela aprendeu determinado ambiente em 2026.

Depois chega 2036.



O mundo mudou.

LINGUAGEM
TECNOLOGIA
COSTUMES
REGRAS
COMPORTAMENTO

Se Isla não mudar:

ESTÁVEL
MAS OBSOLETA

Se mudar continuamente:

ATUALIZADA
MAS QUANTO DA ISLA ORIGINAL RESTOU?

Aqui aparece uma distinção fantástica:

DRIFT EM RELAÇÃO AO MUNDO

versus

DRIFT EM RELAÇÃO À PRÓPRIA IDENTIDADE

Esse talvez seja um dos problemas mais interessantes para agentes artificiais de longa duração.


🏗️ CAPÍTULO 22 — CONSTRUINDO ISLA 2.0

Depois dessa Dungeon inteira, podemos projetar nossa Giftia.

Eu não colocaria tudo numa única rede monolítica.

Criaria módulos conceituais:

╔══════════════════════════════╗
║ CORE IDENTITY                ║
╠══════════════════════════════╣
║ PERSONALITY                  ║
╠══════════════════════════════╣
║ VALUES / SAFETY              ║
╠══════════════════════════════╣
║ SEMANTIC MEMORY              ║
╠══════════════════════════════╣
║ EPISODIC MEMORY              ║
╠══════════════════════════════╣
║ WORLD MODEL                  ║
╠══════════════════════════════╣
║ WORKING MEMORY               ║
╠══════════════════════════════╣
║ UNCERTAINTY MODEL            ║
╠══════════════════════════════╣
║ COGNITIVE HEALTH MONITOR     ║
╚══════════════════════════════╝

Cada subsistema teria características diferentes de aprendizado, retenção e proteção.


📊 CAPÍTULO 23 — O RMF DA CONSCIÊNCIA

E agora aparece algo que qualquer mainframer vai adorar.

Telemetria.

Se monitoramos CPU, memória, DASD, I/O, filas e workloads, por que uma inteligência artificial crítica não possuiria telemetria cognitiva?

Imagine:

GIFTIA COGNITIVE HEALTH
────────────────────────────────

MEMORY INTEGRITY......... 99.7%
RECALL CONSISTENCY....... 98.9%
IDENTITY STABILITY....... 97.4%
BEHAVIORAL DRIFT.......... 2.8%
SEMANTIC CONFLICTS........ 1.3%
UNCERTAINTY CALIBRATION.. 96.2%
PLASTICITY RESERVE....... 34.7%
HOMEOSTATIC MARGIN....... 21.3%

STATUS................... WARNING

Seria o RMF da consciência.

E talvez isso explique melhor as inúmeras avaliações técnicas de Isla no anime.


🚨 CAPÍTULO 24 — O LIMITE DE 81.920 HORAS PODE SER UM SLA

Agora chegamos a uma interpretação muito mais elegante.

Talvez:

81.920 HORAS

não signifique:

"A memória enche exatamente nesse segundo."

Poderia representar:

o limite a partir do qual o fabricante já não garante que a estabilidade cognitiva permaneça dentro dos parâmetros aceitáveis.

Como hardware corporativo.

Não significa necessariamente que um componente explode ao atingir determinada idade.

Significa que a probabilidade de falha ultrapassa aquilo que o fabricante considera aceitável.

Isso explicaria as pequenas anomalias anteriores.


🔧 CAPÍTULO 25 — CONVERGÊNCIA PARA UMA REGIÃO SEGURA

Agora recuperamos uma das perguntas centrais de nossa conversa:

Não poderíamos medir a deterioração e fazer o sistema convergir novamente?

Nossa Giftia poderia possuir:

NORMAL
  │
  │ drift
  ↓
WARNING
  │
  ↓
CRITICAL

Ao atingir WARNING:

FREEZE LEARNING
       ↓
RUN DIAGNOSTICS
       ↓
REPLAY IMPORTANT MEMORIES
       ↓
RESOLVE CONFLICTS
       ↓
HOMEOSTATIC NORMALIZATION
       ↓
RESTORE SELECTED PARAMETERS
       ↓
VALIDATE IDENTITY
       ↓
RESUME

Talvez isso aumentasse enormemente sua vida útil.

Mas surge outro monstro.


💾 CAPÍTULO 26 — RESTORE DE PESSOA NÃO É RESTORE DE VSAM

Imagine:

BACKUP ISLA
2026-09-20 03:17

Easter egg encontrado. ☕

Quatro dias depois ocorre degradação.

Executamos:

RESTORE ISLA-20260920

Funcionou!

Ou será que não?

Entre os dias 20 e 24 Isla viveu experiências.

Essas experiências desapareceram.

Portanto restauramos uma versão anterior.

A pergunta muda de:

"Funcionou o restore?"

para:

"A entidade restaurada continua sendo a mesma Isla?"


🚢 CAPÍTULO 27 — O NAVIO DE TESEU ENTRA NO DATACENTER

Imagine copiar completamente Isla.

Agora existem:

ISLA-A
ISLA-B

Ambas possuem as mesmas lembranças.

Ambas reconhecem Tsukasa.

Ambas dizem:

"Eu sou Isla."

No instante seguinte:

ISLA-A → experiência X
ISLA-B → experiência Y

Suas histórias divergiram.

Backup resolve continuidade de dados.

Não resolve automaticamente continuidade de identidade.

E chegamos inesperadamente da Inteligência Artificial à filosofia.


🧠 CAPÍTULO 28 — O HUMANO É UM SISTEMA EM PRODUÇÃO

Nós também mudamos continuamente.

Você não possui exatamente:

BELLACOSA-1987

rodando intacto em algum endereço de memória.

Décadas de:

experiência
aprendizado
esquecimento
reinterpretação
generalização
erro
correção

produziram:

BELLACOSA-2026

Mesmo assim existe continuidade.

Portanto identidade aparentemente não significa:

NO CHANGE

Talvez seja algo mais próximo de:

CONTROLLED CONTINUITY THROUGH CHANGE

Uma continuidade controlada através da mudança.

Isso é uma definição extraordinariamente útil também para sistemas artificiais persistentes.


🥚 EASTER EGG — O ABEND MAIS PERIGOSO

Existe um ABEND pior do que:

S0C7

Nosso hipotético Giftia poderia produzir:

GFT-81920

COGNITIVE CONTINUITY FAILURE

REASON:
SYSTEM CAN NO LONGER GUARANTEE THAT
FUTURE LEARNING WILL PRESERVE
IDENTITY CONSISTENCY.

ACTION:
CONTACT TERMINAL SERVICE.

Agora imagine encontrar isso às:

03:17

numa madrugada de produção.

Você imediatamente pede outro café.


🏁 EPÍLOGO — APRENDER NÃO É APENAS ADICIONAR

Nossa viagem começou com uma pergunta aparentemente simples:

Por que Isla precisa morrer depois de determinado número de horas?

Terminamos encontrando:

  • catastrophic forgetting;

  • continual learning;

  • stability–plasticity dilemma;

  • model drift;

  • Complementary Learning Systems;

  • replay;

  • consolidação;

  • plasticidade homeostática;

  • metaplasticidade;

  • poda;

  • esquecimento;

  • memória episódica;

  • memória semântica;

  • protótipos;

  • categorias fuzzy;

  • predictive processing;

  • incerteza;

  • reconstrução;

  • confabulação;

  • identidade;

  • telemetria cognitiva;

  • checkpoints;

  • restauração;

  • Navio de Teseu.

E descobrimos algo curioso.

O problema mais difícil de uma inteligência artificial de longa duração provavelmente não seria simplesmente:

HOW MUCH CAN I STORE?

Seria:

WHAT SHOULD I LEARN?

WHAT SHOULD I PRESERVE?

WHAT SHOULD I CHANGE?

WHAT SHOULD I DOUBT?

WHAT SHOULD I CONSOLIDATE?

WHAT SHOULD I FORGET?

O programador COBOL entende isso melhor do que parece.

Um sistema mainframe que permanece em produção durante décadas não sobrevive porque ninguém o modifica.

Sobrevive porque existe uma disciplina em torno da mudança:

CHANGE
↓
TEST
↓
REGRESSION
↓
VALIDATION
↓
DEPLOYMENT
↓
MONITORING

Talvez uma inteligência artificial realmente longeva precise fazer exatamente a mesma coisa consigo própria.

Cada aprendizado seria uma espécie de change request cognitivo.

Algumas mudanças seriam aceitas imediatamente.

Outras ficariam em observação.

Algumas exigiriam evidências adicionais.

Outras seriam rejeitadas.

Algumas memórias seriam preservadas.

Outras resumidas.

Outras esquecidas.

E algumas estruturas seriam classificadas como:

*** CRITICAL ***
DO NOT MODIFY WITHOUT REGRESSION TEST.

Essa talvez seja a grande lição escondida sob a tutela de Plastic Memories.

Isla não precisaria necessariamente de memória infinita.

Precisaria de algo muito mais difícil:

um mecanismo capaz de administrar sua própria transformação.

Porque uma inteligência incapaz de aprender fica presa ao passado.

Uma inteligência que aprende tudo indiscriminadamente pode destruir o próprio passado.

E uma inteligência verdadeiramente madura precisa encontrar aquela estreita região entre as duas coisas:

             ESTABILIDADE
                  │
                  │
                  ●
                ISLA
                  │
                  │
             PLASTICIDADE

O ponto em que ela ainda consegue dizer:

"Eu aprendi."

sem precisar perguntar:

"Mas quem exatamente sou eu agora?"

E talvez seja justamente aí que Plastic Memories esconda sua melhor pergunta.

Não:

Quanto tempo uma máquina consegue viver?

Mas:

Quanto uma inteligência pode mudar antes que preservar suas memórias deixe de ser suficiente para preservar quem ela é?

No mainframe chamamos isso de manter décadas de legado funcionando enquanto o mundo inteiro muda ao redor dele.

Nos humanos chamamos de viver.

Na Inteligência Artificial estamos apenas começando a descobrir como chamar.

sábado, 5 de setembro de 2026

O Barão de Münchhausen Entra no CPD — Da Estatística à GenAI, sem precisar cavalgar uma bala de canhão

 

Bellacosa Mainframe apresenta Data Analytics

☕ Um Café no Bellacosa Mainframe

O Barão de Münchhausen Entra no CPD — Da Estatística à GenAI, sem precisar cavalgar uma bala de canhão

Ou: como Estatística, Pesquisa Operacional, Tukey, Codd, Data Warehousing, Analytics, Big Data, Data Science, Machine Learning e IA Generativa acabaram encontrando COBOL dentro do IBM Z — e por que o programador que entende os dados tem uma vantagem que nenhum dashboard consegue inventar


Prólogo — O Barão chegou ao CPD montado numa distribuição normal

Conta o Barão de Münchhausen que certa manhã atravessou uma distribuição normal montado numa média aritmética, saltou sobre três outliers, amarrou seu cavalo numa mediana e chegou ao CPD exatamente no momento em que um batch COBOL terminava de processar alguns milhões de transações.

Naturalmente, não devemos acreditar em tudo.

A parte da distribuição normal é discutível.

A parte dos milhões de transações, nem tanto.

Quem trabalha com mainframe convive diariamente com quantidades gigantescas de dados: pagamentos, cartões, seguros, contas bancárias, pedidos, estoques, reservas, faturamento, logística, transações governamentais e inúmeras outras atividades.

Durante décadas aprendemos a fazer esses sistemas funcionarem.

Agora existe uma pergunta adicional:

O que podemos aprender com os dados que esses sistemas produzem?

É aí que começa nossa viagem pelo Data Analytics.

E nosso guia será justamente o homem conhecido por contar algumas das histórias mais improváveis da literatura.

Isso será conveniente porque existe uma regra importante em análise de dados:

Se uma história parece extraordinária, procure os dados antes de acreditar nela.



1. Afinal, o que é Data Analytics?

Podemos traduzir Data Analytics como Análise de Dados.

Mas simplesmente dizer isso esconde boa parte da história.

Data Analytics é um conjunto de processos, técnicas e ferramentas utilizados para transformar dados em informações capazes de ajudar pessoas e organizações a compreender acontecimentos e tomar decisões.

Podemos representar isso assim:

DADOS
  ↓
PREPARAÇÃO
  ↓
ANÁLISE
  ↓
PADRÕES
  ↓
INSIGHTS
  ↓
COMUNICAÇÃO
  ↓
DECISÃO

Observe algo importante.

O objetivo final não é criar um gráfico.

Também não é executar Python.

Muito menos instalar alguma ferramenta milagrosa com IA.

O objetivo é tomar decisões melhores com base em evidências.

Imagine um banco processando milhões de transações.

O sistema pode saber que:

CLIENTE = 837291
VALOR   = 9800
HORA    = 03:17
CANAL   = WEB

Esses são dados.

Mas Data Analytics começa quando perguntamos:

Esse valor é normal para esse cliente?

Ele costuma comprar às três da manhã?

Esse canal é habitual?

Houve outras compras semelhantes?

O endereço IP está relacionado à localização normalmente utilizada?

Agora os dados começaram a contar uma história.



2. “Mas quem inventou Data Analytics?”

O Barão imediatamente levanta a mão:

— Fui eu! Em 1783, durante uma viagem à Lua...

Não, Barão.

Pode abaixar a mão.

Não existe uma única pessoa reconhecida como inventora do Data Analytics.

Também não encontramos um inventor específico para a expressão Introduction to Data Analytics.

Esse é simplesmente um título descritivo usado para cursos introdutórios sobre análise de dados.

A história intelectual do Data Analytics é muito mais interessante porque várias disciplinas contribuíram para sua formação.

Uma árvore bastante simplificada seria:

ESTATÍSTICA
   │
   ├── Pesquisa Operacional
   │
   ├── Análise de Dados
   │      └── John Tukey — 1962
   │
   ├── Bancos de Dados
   │      └── Edgar F. Codd — década de 1970
   │
   ├── Decision Support Systems
   │
   ├── Data Warehousing / BI
   │
   ├── Analytics
   │      └── Thomas Davenport — 2006
   │
   ├── Big Data
   │
   ├── Data Science
   │
   └── Machine Learning / GenAI

Essa árvore não deve ser interpretada como uma genealogia rígida na qual uma tecnologia simplesmente substitui a anterior.

É melhor enxergá-la como uma acumulação de conhecimentos.

Estatística continua existindo.

SQL continua existindo.

Data Warehouse continua existindo.

Machine Learning não tornou regressão inútil.

IA generativa não tornou bancos de dados obsoletos.

E, para surpresa de algumas apresentações corporativas...

COBOL também continua aqui.



3. A raiz: Estatística

Antes de existir computador, já existia a necessidade de analisar números.

Populações, comércio, agricultura, astronomia, seguros, economia e administração pública produziram problemas que exigiam métodos quantitativos.

Daí se desenvolveram conceitos fundamentais como:

  • média;

  • mediana;

  • moda;

  • variância;

  • desvio padrão;

  • distribuição;

  • probabilidade;

  • correlação;

  • regressão.

Para o programador COBOL, alguns desses conceitos parecem muito mais familiares quando saem do livro de estatística.

Imagine tempos de resposta:

0,31
0,29
0,30
0,32
0,31
0,30
2,87

Existe alguma coisa estranha ali.

O 2,87 merece investigação.

Chamamos valores muito afastados do comportamento esperado de outliers.

O Barão naturalmente garante que o tempo de resposta de 2,87 segundos ocorreu porque um cavalo ficou preso no canal ESCON.

A equipe de produção prefere consultar os logs.


4. Média não conta toda a história

Imagine cinco transações:

100
105
110
115
10.000

A média é:

(100 + 105 + 110 + 115 + 10000) / 5
= 2086

Mas quatro das cinco transações estão perto de 100.

Por isso precisamos conhecer também mediana e dispersão.

A mediana seria:

110

Muito mais representativa do comportamento central daquele pequeno conjunto.

A dispersão, por sua vez, ajuda a entender quanto os valores se afastam uns dos outros.

Essa é uma lição fundamental para analytics:

Um único número raramente explica um sistema complexo.

É igualmente verdadeira para performance de mainframe.

Dizer:

“O response time médio é 300 ms.”

pode esconder períodos de 50 ms e outros de 5 segundos.

Por isso média, percentis, distribuição e dispersão importam.


5. Pesquisa Operacional entra no CPD

Outra contribuição importante veio da Pesquisa Operacional.

Ela utiliza modelos matemáticos para encontrar melhores decisões diante de restrições.

Imagine:

recursos limitados
+
múltiplas alternativas
+
objetivos
+
restrições

Isso aparece em logística, produção, transporte, escalonamento e planejamento.

Para quem conhece mainframe, a ideia não deveria parecer alienígena.

Um ambiente computacional também possui:

CPU
Memória
I/O
Prioridades
Workloads
SLAs
Janelas batch

E precisamos decidir como utilizar recursos limitados da melhor maneira possível.

O WLM provavelmente cumprimentaria a Pesquisa Operacional com bastante respeito.


6. John Tukey e a Análise de Dados

Em 1962, o estatístico John Tukey publicou o influente trabalho The Future of Data Analysis.

Tukey ajudou a fortalecer a ideia de que analisar dados era uma atividade intelectual própria, não simplesmente uma aplicação mecânica da estatística.

Posteriormente, seu trabalho sobre Exploratory Data Analysis — EDA tornou-se particularmente importante.

A ideia é poderosa:

Antes de tentar provar alguma coisa, explore os dados.

Observe.

Visualize.

Procure padrões.

Procure inconsistências.

Faça perguntas.

Para um programador COBOL, podemos traduzir:

Antes de alterar o programa porque alguém disse que “o sistema está lento”, investigue.


7. Edgar F. Codd aparece carregando tabelas

Chegamos aos anos 1970.

Entra em nossa história Edgar F. Codd, pesquisador da IBM.

Codd apresentou o modelo relacional para bancos de dados.

Essa contribuição transformaria profundamente a maneira como sistemas armazenam e consultam informações.

Em vez de pensar somente em estruturas físicas, passamos a trabalhar conceitualmente com:

TABELAS
LINHAS
COLUNAS
CHAVES
RELACIONAMENTOS

E desse universo emergiria SQL.

Para o programador COBOL:

EXEC SQL
   SELECT SALDO
     INTO :WS-SALDO
     FROM CONTA
    WHERE CONTA_ID = :WS-CONTA-ID
END-EXEC.

Parece cotidiano.

Mas existe uma enorme história da computação escondida atrás desse SELECT.


8. Decision Support Systems

À medida que empresas armazenavam mais informações, surgiu outra necessidade:

usar computadores não apenas para executar operações, mas também para ajudar pessoas a decidir.

Daí crescem os Decision Support Systems — DSS.

O sistema transacional responde:

“A venda aconteceu?”

O sistema de apoio à decisão pode perguntar:

“Por que as vendas caíram?”

Perceba a mudança.

OLTP → executar o negócio

Analytics → compreender o negócio

Naturalmente os dois mundos podem se alimentar.


9. Data Warehouse e Business Intelligence

Empresas possuíam dados espalhados em diversos sistemas.

Então apareceu outro problema:

Como juntar tudo isso para análise?

Entram Data Warehouses, Data Marts, processos ETL e ferramentas de Business Intelligence.

ETL significa:

Extract
Transform
Load

Ou:

Extrair
Transformar
Carregar

Quem trabalha com mainframe talvez esteja pensando:

“Nós fazemos coisas parecidas há décadas.”

E não está totalmente errado.

Arquivos são extraídos, classificados, combinados, transformados e carregados desde muito antes de o termo data pipeline virar moda.

DFSORT poderia escrever memórias bastante interessantes sobre isso.


10. Data Wrangling — o faxineiro que salva o projeto

Dados reais são bagunçados.

Encontramos:

campos vazios
duplicidades
datas incompatíveis
valores inválidos
espaços
códigos antigos
unidades diferentes
registros incompletos

Data Wrangling é o processo de transformar esse material em algo apropriado para análise.

Um fluxo típico inclui:

Discovery
   ↓
Transformation
   ↓
Validation
   ↓
Publishing

Isso pode envolver:

  • joins;

  • unions;

  • normalização;

  • limpeza;

  • enriquecimento;

  • validação.

Aqui existe uma regra que merece ser escrita na parede do CPD:

IA aplicada sobre dado ruim produz erro tecnologicamente sofisticado.

Ou, na versão tradicional:

Garbage In, Garbage Out.

O Barão prefere:

Garbage In, história extraordinária Out.


11. Analytics chega à sala da diretoria

Em 2006, Thomas H. Davenport publicou na Harvard Business Review o artigo Competing on Analytics.

Ele ajudou a popularizar a utilização de analytics como instrumento de vantagem competitiva.

A pergunta empresarial deixa de ser apenas:

“Quanto vendemos?”

e passa a incluir:

Quem compra?

Quando compra?

Por que compra?

Quem provavelmente deixará de comprar?

Onde existe fraude?

O que provavelmente acontecerá depois?

Os dados começam a participar diretamente da estratégia empresarial.


12. Big Data — quando o dataset comeu demais

Depois veio a explosão de dados.

Web.

Smartphones.

Sensores.

Logs.

Redes sociais.

Streaming.

IoT.

Transações digitais.

Passamos a falar dos famosos Vs do Big Data.

Entre eles:

Volume — quantidade.

Velocity — velocidade.

Variety — variedade.

Veracity — confiabilidade.

Tecnologias distribuídas como Hadoop e Spark ganharam destaque nesse cenário.

Mas existe uma curiosidade importante para nós.

Enquanto o mundo descobria que havia dados demais...

o mainframe provavelmente respondeu:

“Interessante. Conte-me mais.”


13. Data Science

Data Science combina conhecimentos de várias áreas:

Estatística
+
Computação
+
Conhecimento do domínio
+
Métodos analíticos

Isso explica uma coisa importantíssima.

O melhor profissional não é necessariamente aquele que conhece mais bibliotecas Python.

Conhecimento do domínio importa enormemente.

E é aí que um desenvolvedor COBOL experiente possui uma vantagem.

Ele talvez conheça:

cliente
conta
apólice
pedido
pagamento
fatura
liquidação
compensação
estoque

Não apenas como colunas.

Mas como processos reais do negócio.


14. Machine Learning

Machine Learning leva a análise adiante permitindo que modelos aprendam padrões a partir dos dados.

Algumas tarefas clássicas incluem:

Classificação

Determinar uma categoria.

TRANSAÇÃO
   ↓
LEGÍTIMA
ou
SUSPEITA

Clustering

Agrupar elementos semelhantes sem necessariamente possuir classes previamente definidas.

clientes
   ↓
grupo A
grupo B
grupo C

Regressão

Investigar relações entre variáveis e produzir estimativas.

Detecção de anomalias

Encontrar comportamentos incomuns.

E essa última nos leva diretamente ao exemplo do curso.


15. O ladrão roubou o cartão — ou talvez apenas as credenciais

Imagine um cliente que normalmente:

faz 3 compras por semana
gasta aproximadamente R$ 150
compra em São Paulo
utiliza dispositivos conhecidos

De repente:

12 compras
4 minutos
valores elevados
IP incomum
localização diferente
nova preferência de entrega

Nenhum desses elementos isoladamente prova fraude.

Mas juntos formam um comportamento digno de investigação.

Esse é um excelente exemplo de detecção de anomalias.

O processo seria aproximadamente:

1. Definir o problema
        ↓
2. Identificar os dados necessários
        ↓
3. Coletar
        ↓
4. Limpar
        ↓
5. Transformar
        ↓
6. Analisar
        ↓
7. Detectar padrões/anomalias
        ↓
8. Visualizar
        ↓
9. Comunicar
        ↓
10. Decidir

Esse é o coração do Data Analytics.



16. Visualização — porque ninguém quer interpretar 800 mil linhas

Imagine entrar numa reunião executiva e dizer:

— Descobri o problema. Aqui estão 4,7 milhões de registros CSV.

Você provavelmente não será convidado novamente.

Visualização transforma dados em representações compreensíveis.

Podemos utilizar:

  • gráficos de barras;

  • linhas;

  • histogramas;

  • scatter plots;

  • mapas;

  • dashboards.

Um gráfico pode revelar em segundos algo escondido em milhões de registros.

Mas cuidado:

visualização não substitui análise.

Um gráfico bonito com dados incorretos continua incorreto.

Só ficou mais convincente.


17. Storytelling — o momento Münchhausen

Finalmente chegamos ao território favorito do Barão.

Contar histórias.

Mas agora precisamos fazer exatamente o contrário do nosso guia.

Nada de exageros.

Nada de inventar.

Nada de cavalgar balas de canhão.

Data Storytelling significa comunicar uma conclusão apoiada por evidências.

Uma boa narrativa pode seguir:

CONTEXTO
   ↓
PROBLEMA
   ↓
EVIDÊNCIA
   ↓
DESCOBERTA
   ↓
IMPACTO
   ↓
RECOMENDAÇÃO

Em vez de dizer:

“CPU aumentou.”

Podemos dizer:

“Após o crescimento de 38% do volume transacional entre 10h e 11h, observamos aumento consistente no consumo de CPU acompanhado por crescimento do response time. A análise indica concentração no workload X e recomenda investigação das transações Y.”

Agora existe história.

Existe contexto.

Existe decisão possível.


18. E então apareceu a IA Generativa

Chegamos ao capítulo mais recente.

LLMs e IA generativa conseguem:

  • resumir informações;

  • gerar consultas;

  • auxiliar análise;

  • explicar padrões;

  • produzir código;

  • ajudar na documentação;

  • apoiar visualizações;

  • conversar com bases de conhecimento.

Mas existe um detalhe delicioso.

IA precisa de dados.

Dados precisam de:

qualidade
contexto
governança
segurança
interpretação

Portanto nossa árvore não desapareceu.

Ela ficou maior.

Estatística
     ↓
Data Analysis
     ↓
Databases
     ↓
BI
     ↓
Analytics
     ↓
Big Data
     ↓
Data Science
     ↓
Machine Learning
     ↓
GenAI

Cada camada carrega ideias das anteriores.



19. O IBM Z estava no porão o tempo inteiro

Agora olhamos para o mainframe.

Ali encontramos:

COBOL
CICS
IMS
Db2
VSAM
JES2
SMF
RMF
MQ
APIs

E atrás dessas tecnologias existem dados.

Muitos dados.

Transacionais.

Operacionais.

Financeiros.

Históricos.

De performance.

De segurança.

O mainframe não é apenas uma máquina executando programas COBOL.

É também uma das maiores fontes de informação empresarial de alto valor.


20. Por que um desenvolvedor COBOL deveria aprender tudo isso?

Porque o trabalho está mudando.

Não significa abandonar:

COBOL
JCL
CICS
Db2
VSAM

Significa acrescentar:

SQL avançado
Estatística
Data Analytics
Visualização
Python
IA

Um desenvolvedor tradicional pode perguntar:

“Onde esse campo é atualizado?”

Um profissional com mentalidade analítica também pergunta:

“O que podemos descobrir analisando dez anos desse campo?”

Essa segunda pergunta abre um universo novo.



21. Um laboratório Bellacosa

Quer começar sem instalar um cluster Hadoop no quintal?

Pegue um conjunto de dados simples.

Pode ser:

DATA
HORÁRIO
TRANSAÇÃO
VALOR
CPU
RESPONSE_TIME
STATUS

Passo 1 — explore

Quantos registros existem?

Quais campos?

Há valores faltantes?

Passo 2 — limpe

Remova duplicidades.

Padronize datas.

Verifique valores inválidos.

Passo 3 — calcule

Descubra:

média
mediana
mínimo
máximo
desvio

Passo 4 — procure outliers

Quais transações fogem do comportamento esperado?

Passo 5 — relacione variáveis

Por exemplo:

volume × CPU
volume × response time
CPU × response time

Passo 6 — visualize

Crie um gráfico temporal.

Passo 7 — conte a história

Não diga apenas:

“Existe um pico.”

Explique:

quando ocorreu;

qual foi sua magnitude;

quais variáveis mudaram;

quais workloads foram afetados;

qual hipótese merece investigação.

Parabéns.

Você acabou de sair de:

“olhar relatório”

para:

“fazer análise de dados”.


22. Easter egg — o Barão encontra um outlier

No final da visita, Münchhausen olha para nosso dataset.

TEMPO_RESPOSTA

0.28
0.31
0.30
0.29
0.32
47.81
0.30

Ele aponta imediatamente para 47.81.

— Conheço esse número! Foi exatamente o tempo que levei para escapar de um pântano puxando a mim mesmo pelos cabelos!

O analista consulta SMF.

O DBA consulta Db2.

O sysprog consulta RMF.

O desenvolvedor abre os logs.

Descobrem uma contenção.

O Barão parece decepcionado.

Mas acabamos de aprender uma última lição:

Um outlier começa uma investigação. Ele não termina uma investigação.


Epílogo — Não abandone o canhão; aprenda balística

Existe uma tentação recorrente na tecnologia de anunciar que cada novidade matou tudo o que existia antes.

Cloud matou mainframe.

Java matou COBOL.

NoSQL matou SQL.

Big Data matou Data Warehouse.

Machine Learning matou estatística.

IA matou programação.

Enquanto isso, no mundo real, todas essas tecnologias continuam convivendo.

O profissional valioso não é necessariamente aquele que corre atrás de cada buzzword.

É aquele que consegue entender como as peças se conectam.

Para o desenvolvedor COBOL, Data Analytics oferece justamente essa oportunidade.

Você já conhece sistemas que produzem dados críticos.

Conhece transações.

Conhece regras de negócio.

Conhece exceções.

Conhece processamento batch.

Conhece online.

Conhece bancos de dados.

Conhece o estranho campo WS-FLAG-X9 que ninguém documentou desde 1997.

Agora acrescente:

estatística.

análise.

visualização.

storytelling.

Machine Learning.

IA.

E talvez você descubra que não precisa abandonar 30 anos de experiência para entrar no futuro.

Pode fazer algo muito mais inteligente:

colocar o futuro em cima desses 30 anos.

Nossa árvore, afinal, não cresce destruindo suas raízes.

Ela cresce justamente porque possui raízes.

                    GenAI
                      ▲
              Machine Learning
                      ▲
                Data Science
                      ▲
                  Big Data
                      ▲
                 Analytics
                      ▲
             Data Warehouse / BI
                      ▲
                    DSS
                      ▲
                Databases
                      ▲
               Data Analysis
                      ▲
           Pesquisa Operacional
                      ▲
                 Estatística

                     │
                     │
               DADOS REAIS
                     │
              ┌──────┴──────┐
            COBOL          CICS
              │              │
             Db2            IMS
              │              │
            VSAM           MQ/API
              └──────┬───────┘
                     │
                   IBM Z

O Barão de Münchhausen sobe novamente em seu cavalo.

Olha para o IBM Z.

Olha para nosso dashboard.

Olha para a IA.

E antes de cavalgar rumo ao próximo absurdo tecnológico, deixa um conselho surpreendentemente sensato:

“Meu caro programador: eu posso inventar histórias porque sou o Barão. Você, quando trabalhar com dados, precisa provar as suas.”

☕ Bellacosa Mainframe

Do cartão perfurado à Inteligência Artificial, os dados sempre tiveram uma história para contar. Nossa profissão é aprender a ouvi-la.

quinta-feira, 3 de setembro de 2026

O Dia em que o Perceptron Entrou no CPD, Aprendeu com os Próprios Erros e Virou uma IA Generativa sem Pedir COMMIT

 

Bellacosa Mainframe e uma introducao a redes neurais

☕ Um Café no Bellacosa Mainframe

O Dia em que o Perceptron Entrou no CPD, Aprendeu com os Próprios Erros e Virou uma IA Generativa sem Pedir COMMIT

Ou: como saímos das regras escritas à mão, atravessamos redes neurais, deep learning e Transformers e chegamos às máquinas capazes de escrever COBOL perfeitamente convincente — inclusive quando o programa não compila



Prólogo — “Computador, aprenda sozinho”, disse o humano sem preparar os dados

Durante décadas, programar significou explicar ao computador, com uma paciência quase religiosa, exatamente o que ele deveria fazer. O desenvolvedor recebia uma regra de negócio, transformava-a em decisões e escrevia uma sequência de instruções. Se o cliente estivesse inadimplente, bloqueava-se a operação. Se o saldo fosse insuficiente, recusava-se o débito. Se o retorno do programa fosse diferente de zero, alguém recebia uma mensagem capaz de arruinar o café da manhã.

Era um mundo de regras explícitas:

IF WS-SALDO < WS-VALOR-DA-COMPRA
    MOVE 'COMPRA RECUSADA' TO WS-MENSAGEM
ELSE
    MOVE 'COMPRA APROVADA' TO WS-MENSAGEM
END-IF

O computador não precisava compreender o cliente, a compra ou o significado filosófico de ficar sem dinheiro no dia 27. Bastava obedecer.

Então surgiu uma pergunta perturbadora: e se, em vez de escrevermos todas as regras, mostrássemos milhares de exemplos ao computador e permitíssemos que ele ajustasse internamente uma função capaz de reconhecer os padrões?

É nesse ponto que entram as redes neurais.

Não são cérebros digitais, não acordam durante a madrugada pensando em sua própria existência e não possuem um pequeno neurônio chamado Igor escondido atrás da CPU. São modelos matemáticos formados por operações relativamente simples, repetidas muitas vezes e organizadas em camadas.

O encanto está justamente nisso: multiplicações, somas e ajustes de números, quando combinados em escala suficiente, conseguem reconhecer imagens, transcrever voz, prever falhas, traduzir idiomas e gerar texto. O perigo também está nisso: como o resultado parece inteligente, o ser humano pode esquecer que por baixo da conversa elegante existe uma máquina calculando probabilidades.



1. Antes das redes neurais: o reino das regras

Antes de uma rede aprender com dados, o conhecimento normalmente precisava ser colocado no sistema por seres humanos.

Programação tradicional

Na programação convencional, temos os dados e conhecemos as regras. O programa aplica essas regras e produz uma resposta:

Dados + regras escritas pelo programador → resultado

Esse modelo continua sendo excelente quando o problema é determinístico. Para somar lançamentos contábeis, calcular juros definidos em contrato ou validar o tamanho de um campo, uma rede neural seria uma extravagância digna de alguém que contratou uma orquestra para tocar o som de uma notificação.

Sistemas especialistas

Entre as décadas de 1970 e 1980, ganharam destaque os sistemas especialistas. Eles tentavam reproduzir decisões de profissionais por meio de uma base de conhecimento e um mecanismo de inferência.

SE a temperatura está alta
E a pressão está baixa
ENTÃO verificar o sistema de refrigeração

Esses sistemas foram úteis, mas tinham um custo: alguém precisava entrevistar os especialistas, descobrir as regras, eliminar contradições e manter a base atualizada. Quando o ambiente mudava, a elegante inteligência podia virar rapidamente um museu de certezas antigas.

Estatística e machine learning clássico

Também existiam — e continuam existindo — regressão linear, regressão logística, árvores de decisão, Naive Bayes, KNN, máquinas de vetores de suporte e vários outros algoritmos.

Eles não foram aposentados pela IA generativa. Em dados tabulares pequenos ou médios, uma árvore ou regressão frequentemente custa menos, é mais explicável e funciona tão bem quanto uma rede neural. O desenvolvedor maduro não pergunta “onde posso colocar IA?”, mas “qual é a solução mais simples, verificável e econômica para este problema?”.



2. O perceptron bate à porta do CPD

O ancestral histórico das redes atuais é o perceptron, desenvolvido por Frank Rosenblatt no fim dos anos 1950. Ele era um classificador capaz de ajustar os pesos das entradas durante o aprendizado. Embora limitado a problemas linearmente separáveis, estabeleceu uma ideia fundamental: uma máquina poderia melhorar sua decisão modificando seus próprios parâmetros a partir de exemplos.

Um neurônio artificial recebe valores de entrada:

  • uso de CPU;

  • memória consumida;

  • quantidade de erros anteriores;

  • crescimento do volume processado.

Cada entrada é multiplicada por um peso. Depois, os resultados são somados com um valor adicional chamado bias:

[
z = x_1w_1+x_2w_2+x_3w_3+x_4w_4+b
]

Em seguida, o valor passa por uma função de ativação:

[
y=f(z)
]

Essa função permite que o modelo represente relações não lineares. Sem ela, empilhar várias camadas equivaleria, em essência, a fazer uma única grande transformação linear: muita arquitetura para continuar morando no mesmo apartamento matemático.

Se a saída usar uma função sigmoide, obteremos um valor entre zero e um:

0,04 → risco muito baixo
0,51 → situação incerta
0,97 → risco muito alto

O neurônio não “sabe” o que é um ABEND. Apenas aprendeu que determinadas combinações numéricas costumam aparecer antes de registros classificados como falha.



3. Por que uma rede precisa de camadas?

Um neurônio isolado resolve apenas relações simples. Uma rede reúne muitos neurônios em camadas:

  1. Camada de entrada: recebe os dados.

  2. Camadas ocultas: transformam e combinam os sinais.

  3. Camada de saída: produz a previsão ou classificação.

Em visão computacional, camadas iniciais podem responder a contornos, cores e texturas. Camadas posteriores combinam esses elementos em formas mais complexas. Em linguagem, representações iniciais de tokens são transformadas considerando posição, contexto e relações com outros tokens.

Quando existem muitas camadas, falamos em deep learning, ou aprendizagem profunda. A profundidade não concede consciência ao modelo; apenas cria uma função com enorme capacidade de representar padrões.

É importante evitar uma analogia enganosa. Redes neurais foram inspiradas vagamente na ideia de neurônios interconectados, mas um neurônio biológico é imensamente mais complexo. Dizer que uma rede artificial funciona como o cérebro é semelhante a dizer que um avião funciona como um pássaro: ambos voam, mas ninguém espera encontrar penas dentro da turbina.



4. Como a rede aprende: o treinamento

O treinamento pode ser entendido como um ciclo em cinco atos.

Ato 1 — Pesos iniciais

Os pesos começam com pequenos valores, geralmente aleatórios. A rede ainda não aprendeu o padrão e suas respostas são pouco úteis.

Ato 2 — Propagação para frente

Um exemplo atravessa a rede da entrada até a saída. Isso é chamado de forward pass.

CPU: 92%
Memória: 90%
Erros anteriores: 7
Crescimento do volume: 65%

Previsão inicial: 18% de risco de ABEND
Resultado real: houve ABEND

Ato 3 — Função de perda

A função de perda mede a distância entre a previsão e a resposta correta. Ela não diz apenas “errou”; fornece um número que pode orientar os ajustes.

Ato 4 — Backpropagation

O algoritmo calcula como cada peso contribuiu para o erro. Essa informação é propagada da saída em direção às camadas anteriores. É o famoso backpropagation.

Ato 5 — Otimização

Um otimizador, como o gradiente descendente ou Adam, altera os pesos na direção que tende a reduzir a perda.

O ciclo se repete. Cada passagem completa pelo conjunto de treinamento recebe o nome de época.

Época 1   → a rede tropeça no cabo de força
Época 10  → começa a reconhecer alguns padrões
Época 50  → melhora suas previsões
Época 500 → talvez esteja aprendendo o problema
             ou apenas decorando o laboratório

Quando o modelo decora demais os exemplos de treinamento e perde a capacidade de funcionar com dados novos, temos o overfitting. Ele é o aluno que tirou dez porque memorizou o gabarito, mas entra em S0C7 quando a prova muda duas palavras.

5. Laboratório: uma pequena sentinela de jobs batch

Vamos construir um exemplo didático em Python. A rede receberá quatro características de um job:

  • percentual de CPU;

  • percentual de memória utilizada;

  • quantidade de erros anteriores;

  • crescimento percentual do volume de entrada.

Ela tentará classificar o resultado:

  • 0: execução normal;

  • 1: risco de ABEND.

Passo 1 — Preparar o ambiente

python -m pip install tensorflow numpy scikit-learn

Passo 2 — Importar as bibliotecas

import numpy as np
from sklearn.model_selection import train_test_split
from sklearn.preprocessing import StandardScaler
from tensorflow import keras
from tensorflow.keras import layers

O NumPy manipula os números, o scikit-learn ajuda a preparar os dados e o Keras oferece blocos de construção para a rede.

Passo 3 — Criar os exemplos

X = np.array([
    [35, 40, 0, 5],
    [42, 48, 0, 8],
    [50, 55, 1, 10],
    [58, 60, 1, 12],
    [65, 68, 2, 18],
    [72, 75, 3, 25],
    [78, 82, 4, 35],
    [85, 88, 5, 45],
    [91, 94, 7, 60],
    [96, 97, 9, 80],
    [45, 85, 1, 12],
    [88, 50, 2, 20],
    [76, 91, 6, 50],
    [93, 86, 8, 65],
    [55, 52, 0, 5],
    [82, 89, 5, 55]
], dtype=float)

y = np.array([
    0, 0, 0, 0,
    0, 0, 1, 1,
    1, 1, 0, 0,
    1, 1, 0, 1
])

X contém as características e y contém o resultado conhecido. Em um projeto real, esses registros poderiam vir de métricas operacionais, SMF, logs, históricos do scheduler e ocorrências devidamente classificadas.

Passo 4 — Separar treino e teste

X_treino, X_teste, y_treino, y_teste = train_test_split(
    X,
    y,
    test_size=0.25,
    random_state=42,
    stratify=y
)

O modelo aprende com uma parte dos registros e é avaliado com outra. Testá-lo com o mesmo material usado no treinamento seria entregar a prova com o gabarito e depois publicar no LinkedIn que o aluno alcançou 100% de inteligência artificial.

Passo 5 — Normalizar

normalizador = StandardScaler()

X_treino = normalizador.fit_transform(X_treino)
X_teste = normalizador.transform(X_teste)

As variáveis possuem escalas diferentes. CPU pode variar de zero a cem, enquanto erros anteriores talvez variem de zero a dez. A normalização impede que o tamanho numérico seja confundido com importância.

Há um detalhe essencial: usamos fit_transform somente no treino. No teste, usamos apenas transform. Caso o normalizador aprendesse também com o conjunto de teste, informações do futuro vazariam para o treinamento.

Passo 6 — Construir a rede

modelo = keras.Sequential([
    layers.Input(shape=(4,)),
    layers.Dense(8, activation="relu"),
    layers.Dense(4, activation="relu"),
    layers.Dense(1, activation="sigmoid")
])

A primeira camada oculta possui oito neurônios; a segunda possui quatro. A saída possui um neurônio com sigmoide, produzindo um valor entre zero e um.

O número de camadas e neurônios não veio gravado numa tábua sagrada. Arquitetura, taxa de aprendizado, tamanho do lote e quantidade de épocas são hiperparâmetros: escolhas feitas e testadas pela equipe.

Passo 7 — Compilar e treinar

modelo.compile(
    optimizer="adam",
    loss="binary_crossentropy",
    metrics=["accuracy"]
)

modelo.fit(
    X_treino,
    y_treino,
    epochs=100,
    verbose=0
)

A entropia cruzada binária é adequada a uma classificação com duas classes. Adam realiza os ajustes dos pesos. epochs=100 manda o modelo percorrer o conjunto de treinamento cem vezes.

Passo 8 — Avaliar

perda, acuracia = modelo.evaluate(
    X_teste,
    y_teste,
    verbose=0
)

print(f"Acurácia de teste: {acuracia:.2%}")

A acurácia, sozinha, pode enganar. Se apenas 1% dos jobs falha, um modelo que sempre responde “normal” terá 99% de acurácia e a utilidade operacional de um alarme que permanece silencioso durante o incêndio.

Em produção, também examinaríamos precision, recall, F1-score, matriz de confusão, falsos positivos e falsos negativos. O custo do erro precisa ser discutido com o negócio e com a operação.

Passo 9 — Fazer uma previsão

novo_job = np.array([
    [89, 92, 6, 58]
], dtype=float)

novo_job_normalizado = normalizador.transform(novo_job)

probabilidade = modelo.predict(
    novo_job_normalizado,
    verbose=0
)[0][0]

print(f"Risco estimado de ABEND: {probabilidade:.2%}")

if probabilidade >= 0.70:
    print("Risco alto: solicitar análise humana.")
elif probabilidade >= 0.40:
    print("Risco intermediário: monitorar a execução.")
else:
    print("Risco baixo.")

A rede produz uma probabilidade. A política ao redor dela decide o que fazer. O modelo pode recomendar uma análise; não precisa receber autoridade para cancelar sozinho a folha de pagamento porque encontrou uma vibração negativa no dataset.

6. Por que este laboratório ainda não pode entrar em produção?

Nosso conjunto contém apenas dezesseis registros sintéticos. Serve para compreender o fluxo, não para comandar uma operação real.

Uma implementação séria precisaria investigar:

  • qualidade e representatividade dos dados;

  • registros ausentes ou incorretos;

  • desbalanceamento entre classes;

  • diferença entre correlação e causalidade;

  • vazamento de informações do futuro;

  • custo dos falsos alarmes;

  • explicabilidade;

  • segurança e privacidade;

  • mudanças no ambiente ao longo do tempo;

  • comparação com regras e algoritmos mais simples.

Imagine que todos os ABENDs do histórico ocorreram às sextas-feiras porque uma versão defeituosa foi implantada durante quatro semanas. A rede pode aprender que sexta-feira é perigosa, em vez de descobrir a verdadeira causa. Ela não mentiu; apenas encontrou o atalho estatístico permitido pelos dados.

O dataset é o professor. Se o professor carrega erros, preconceitos, lacunas ou classificações ruins, o aluno aprende tudo com notável eficiência.

7. Para que servem as redes neurais?

Redes neurais são úteis quando há muitos exemplos e relações difíceis de transformar em regras explícitas:

  • reconhecimento de imagens e objetos;

  • transcrição e síntese de voz;

  • tradução automática;

  • classificação de documentos;

  • manutenção preditiva;

  • detecção de fraude e anomalias;

  • análise de sentimento;

  • recomendação de conteúdo;

  • processamento de linguagem;

  • geração de texto, imagem, áudio e vídeo.

Mas não são a solução universal. Uma regra é preferível quando precisa ser cumprida exatamente. Uma árvore pode ser melhor quando a explicação da decisão é indispensável. Uma consulta SQL pode resolver o que alguém tentou transformar num projeto de seis meses com GPUs, consultores e uma apresentação cujo título contém a palavra “disruptivo”.

8. O inverno das redes e o renascimento do deep learning

Redes neurais não caminharam em linha reta até a glória. Houve períodos de entusiasmo, limitações e perda de interesse.

Modelos iniciais tinham capacidade limitada. Treinar redes profundas era difícil, os computadores eram lentos e grandes conjuntos de dados digitalizados ainda não existiam. Críticas às limitações dos perceptrons também contribuíram para reduzir o entusiasmo.

O renascimento ganhou força entre o fim dos anos 2000 e o início dos anos 2010 graças à combinação de:

  • mais dados disponíveis;

  • GPUs capazes de executar cálculos em paralelo;

  • técnicas melhores de treinamento;

  • funções de ativação mais adequadas;

  • arquiteturas profundas;

  • avanços em visão computacional e reconhecimento de voz.

A rede neural não foi sucedida por uma espécie completamente diferente. Ela cresceu, aprofundou-se e ganhou arquiteturas especializadas.

9. CNNs, RNNs e a longa fila antes do Transformer

As redes convolucionais, ou CNNs, tornaram-se especialmente importantes para imagens. Elas aplicam filtros que ajudam a identificar padrões espaciais.

As redes recorrentes, ou RNNs, foram projetadas para sequências. Elas mantinham uma forma de estado interno, permitindo considerar elementos anteriores. Variantes como LSTM e GRU melhoraram o tratamento de dependências mais longas.

Entretanto, o processamento recorrente é sequencial: para compreender determinada posição, o modelo atravessa estados anteriores. Isso dificulta a paralelização e pode prejudicar relações muito distantes.

Em 2017, o artigo Attention Is All You Need, de Vaswani e colaboradores, apresentou o Transformer: uma arquitetura baseada em mecanismos de atenção, sem depender da recorrência ou convolução usadas pelas arquiteturas dominantes de tradução daquela época.

O Transformer podia relacionar elementos do contexto e realizar grande parte do treinamento de maneira paralela. Isso não tornou o custo pequeno; tornou possível utilizar muito mais computação com eficiência suficiente para escalar.

E aqui está a correção histórica essencial:

O Transformer não substituiu a rede neural. O Transformer é uma arquitetura de rede neural.

10. Atenção: quem deve olhar para quem?

Considere a frase:

O programa tentou abrir o arquivo, mas ele não estava catalogado.

Ao representar a palavra “ele”, o modelo precisa relacioná-la a outras partes da sequência. O mecanismo de atenção calcula quanto cada elemento deve considerar os demais naquele contexto.

No Transformer, cada token gera representações geralmente chamadas de:

  • Query: o que estou procurando;

  • Key: que tipo de informação ofereço;

  • Value: qual conteúdo carrego.

O modelo compara queries e keys para determinar a atenção e combina os values de acordo com esses resultados.

Isso acontece por meio de álgebra linear, não por uma pequena reunião de palavras conscientes discutindo quem merece protagonismo.

11. Do texto aos números: tokens e embeddings

Uma rede não recebe palavras como um ser humano. O texto é quebrado em tokens, que podem ser palavras, partes de palavras, sinais ou outros fragmentos.

"O job terminou com ABEND"

Pode ser transformado conceitualmente em algo parecido com:

["O", " job", " terminou", " com", " AB", "END"]

Cada token é convertido em um vetor numérico chamado embedding. Durante o treinamento, o modelo aprende representações em que elementos usados em contextos relacionados desenvolvem relações matemáticas.

O embedding não é um verbete de dicionário e tampouco uma fotografia do significado. É uma representação útil para a tarefa aprendida.

Posições também importam. “O operador cancelou o job” não significa o mesmo que “o job cancelou o operador”, embora a segunda frase descreva com precisão emocional algumas madrugadas de produção.

12. Como um modelo de linguagem aprende a escrever?

Um grande modelo de linguagem recebe sequências e aprende a prever tokens. Diante de:

IDENTIFICATION DIVISION.
PROGRAM-ID.

ele calcula probabilidades para possíveis continuações:

CLIENTE     31%
PROCESSA    24%
CALCULO     18%
TESTE       11%
outros      16%

Um token é escolhido, acrescentado ao contexto e o processo se repete. Em escala enorme, esse treinamento permite ao modelo aprender regularidades de linguagem, estilos, estruturas de código e associações entre conceitos.

Da previsão sucessiva surgem capacidades como:

  • completar texto;

  • responder perguntas;

  • traduzir;

  • resumir;

  • escrever código;

  • reorganizar informações;

  • adaptar o estilo de uma explicação.

Mas o objetivo fundamental continua sendo produzir uma continuação provável. O modelo não possui, por natureza, um compromisso automático com a verdade. Se uma informação falsa combinar muito bem com o padrão linguístico, ele poderá apresentá-la com a segurança de um consultor que acabou de aprender três siglas durante o almoço.

13. Rede neural, LLM, RAG, chatbot e agente

Esses termos aparecem misturados, mas representam coisas diferentes.

ConceitoO que significa
Rede neuralEstrutura matemática com parâmetros ajustáveis
Deep learningAprendizado com redes neurais profundas
TransformerArquitetura neural centrada em atenção
LLMGrande modelo treinado para trabalhar com linguagem
IA generativaCategoria de sistemas capazes de gerar conteúdo
ChatbotInterface conversacional, com ou sem LLM
RAGRecuperação de fontes para fornecer contexto ao modelo
AgenteSistema que usa modelos, estado, regras e ferramentas para executar etapas

Um LLM sozinho responde a partir dos padrões aprendidos e do contexto recebido.

Um sistema com RAG, ou geração aumentada por recuperação, procura documentos relevantes e os coloca no contexto da solicitação. Isso não torna o modelo infalível, mas permite fundamentar a resposta em manuais, políticas ou bases atuais.

Um agente pode receber uma meta, selecionar ferramentas e executar várias etapas:

  1. localizar o job;

  2. consultar o log;

  3. identificar mensagens relevantes;

  4. pesquisar o manual autorizado;

  5. preparar um diagnóstico;

  6. abrir um chamado após autorização.

O LLM pode ser o motor de raciocínio linguístico, mas o agente completo inclui permissões, ferramentas, memória, controles, validação e auditoria.

14. A IA generativa atual não surgiu do nada

A IA generativa é resultado de uma pilha de avanços:

Álgebra e estatística
        ↓
Perceptrons e redes neurais
        ↓
Backpropagation e melhores técnicas de treinamento
        ↓
Deep learning, grandes datasets e GPUs
        ↓
CNNs, RNNs, LSTMs e atenção
        ↓
Transformers
        ↓
Modelos fundacionais e LLMs
        ↓
RAG, multimodalidade, ferramentas e agentes

Os modelos fundacionais são treinados de maneira ampla e depois adaptados ou orientados para várias tarefas. Em vez de construir um modelo totalmente separado para cada pequena função, aproveita-se uma base geral capaz de trabalhar com múltiplos domínios e modalidades.

Hoje, sistemas generativos podem processar combinações de texto, imagem, áudio e vídeo. Também podem usar busca, executar código e interagir com sistemas externos. Entretanto, cada capacidade adicional amplia a superfície de risco.

Um modelo que apenas sugere uma resposta pode estar errado. Um agente com acesso produtivo pode estar errado e executar o erro.

15. Mais autonomia exige mais controle

Se a rede apenas estima o risco de um job, sua saída pode ser revisada por um operador. Se um agente puder cancelar jobs, alterar datasets ou liberar acessos, serão necessários controles muito mais fortes.

Entre eles:

  • menor privilégio possível;

  • identidade individual e credenciais protegidas;

  • separação entre recomendação e execução;

  • confirmação humana para operações críticas;

  • logs completos e auditáveis;

  • limites de custo, tempo e volume;

  • validação das entradas e saídas;

  • fontes autorizadas;

  • possibilidade de interrupção;

  • testes contra manipulação e instruções maliciosas.

Não devemos entregar RACF SPECIAL a um modelo porque ele escreveu um poema bonito sobre segurança de acesso.

Uma resposta convincente não é uma autorização. Uma probabilidade alta não é uma certeza. Uma demonstração de laboratório não é um controle de produção.

16. Como desenvolver um projeto real de rede neural

1. Defina o problema

Evite “precisamos usar IA”. Prefira:

Queremos identificar jobs com alto risco de falha até uma hora antes da execução para que a operação possa investigá-los.

2. Defina o alvo

O que o modelo deverá prever? Falha ou sucesso? Código do ABEND? Tempo restante? Severidade? Cada formulação produz um projeto diferente.

3. Obtenha dados representativos

Inclua períodos, aplicações e condições variadas. Documente origem, autorização e significado de cada campo.

4. Crie um baseline simples

Compare a rede com uma regra, regressão logística ou árvore de decisão. Sem baseline, qualquer resultado parece uma vitória.

5. Separe os conjuntos corretamente

Treino ensina. Validação ajuda a escolher hiperparâmetros. Teste mede o resultado final. Em séries temporais, preserve a ordem do tempo para evitar que o futuro ensine o passado.

6. Treine e registre os experimentos

Guarde versão dos dados, código, arquitetura, parâmetros e métricas. “Funcionou ontem no notebook do Carlos” não é governança.

7. Avalie o impacto dos erros

Um falso positivo apenas gera uma inspeção desnecessária ou paralisa um processo crítico? Um falso negativo representa atraso ou perda financeira? A métrica deve refletir o risco real.

8. Implante gradualmente

Comece em modo observador. Compare previsões e realidade antes de automatizar decisões.

9. Monitore o modelo

Aplicações, volumes e comportamento operacional mudam. Quando a distribuição dos dados muda, ocorre data drift. Quando muda a relação entre entradas e resultado, podemos ter concept drift.

10. Mantenha um responsável humano

Todo modelo precisa de proprietário, processo de revisão, critério de retirada e plano de contingência.

17. O que um dev júnior realmente precisa aprender?

O iniciante não precisa começar calculando derivadas matriciais numa lousa durante uma tempestade. Precisa compreender progressivamente:

  1. Python básico;

  2. arrays e manipulação de dados;

  3. estatística e probabilidade elementares;

  4. treino, validação e teste;

  5. classificação e regressão;

  6. métricas;

  7. normalização e preparação de dados;

  8. neurônio, pesos, bias e ativação;

  9. loss, gradiente e backpropagation;

  10. overfitting e regularização;

  11. uso de uma biblioteca como Keras ou PyTorch;

  12. implantação, monitoramento e governança.

Depois disso, faz sentido avançar para embeddings, atenção, Transformers, fine-tuning, RAG e agentes.

Programar o laboratório é importante, mas saber questioná-lo é ainda mais valioso:

  • De onde vieram os dados?

  • O que exatamente significa o rótulo?

  • Qual erro é mais perigoso?

  • O modelo está melhor que uma regra simples?

  • Ele continuará funcionando depois de uma mudança?

  • Quem poderá usar a previsão?

  • Quem responde quando ela estiver errada?

18. A explicação de um minuto

Se o café estiver acabando e o gerente pedir uma definição rápida, diga:

Uma rede neural é um modelo matemático formado por camadas de operações com parâmetros ajustáveis. Durante o treinamento, ela recebe exemplos, calcula previsões, mede os erros e modifica seus pesos para melhorar. Redes profundas conseguem aprender representações complexas. Transformers são redes neurais que usam atenção para relacionar partes de um contexto. Grandes modelos generativos usam essa arquitetura e enormes conjuntos de dados para prever sucessivamente tokens, produzindo texto, código e outros conteúdos. Eles não consultam automaticamente a verdade: geram respostas prováveis e, por isso, precisam de fontes, validação, governança e supervisão humana.

Epílogo — O modelo terminou o treinamento, mas ninguém abriu a mudança

A história da inteligência artificial não é a substituição completa de uma tecnologia por outra. É uma pilha arqueológica.

As regras tradicionais continuam sustentando sistemas críticos. A estatística continua explicando relações. O machine learning clássico continua resolvendo problemas com eficiência. As redes neurais ampliaram nossa capacidade de aprender padrões. O deep learning levou essa ideia à escala. O Transformer tornou o contexto e a paralelização protagonistas. A IA generativa colocou tudo isso diante do usuário numa caixa de diálogo aparentemente simples.

Mas simplicidade na interface não significa simplicidade por dentro.

Quando pedimos a um modelo que escreva, resuma ou programe, acionamos uma cadeia construída com dados, vetores, matrizes, pesos, atenção, probabilidades, infraestrutura e escolhas humanas. A resposta pode parecer nova, criativa e até espirituosa, mas continua sendo produzida por um sistema que aprendeu regularidades e calcula continuações.

Esse sistema pode ser extraordinariamente útil. Pode ajudar o dev júnior a compreender uma mensagem, comparar alternativas, criar testes e explorar código. Também pode inventar comandos, confundir versões, ignorar uma exceção e declarar com admirável elegância que o programa inexistente foi compilado com sucesso.

Por isso, a melhor relação com a IA generativa não é submissão nem desprezo. É colaboração supervisionada.

O modelo sugere. O profissional verifica.

O modelo encontra padrões. O profissional interpreta o contexto.

O modelo acelera. O profissional assume a responsabilidade.

E, antes que a rede neural seja promovida de estagiária matemática a operadora autônoma do datacenter, alguém precisa perguntar quem aprovou a mudança, onde está o plano de retorno e por que aquela criatura probabilística está solicitando RACF SPECIAL às três horas da manhã.

Referências para continuar a viagem



Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...