☕ 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

segunda-feira, 29 de janeiro de 2024

Da Terra à Lua em um Copilot — O Dia em que Barbicane Descobriu que o Canhão Não Era o Mais Perigoso da Expedição

 

Bellacosa Mainframe apresenta o MS Copilot

☕ Um Café no Bellacosa Mainframe

Da Terra à Lua em um Copilot — O Dia em que Barbicane Descobriu que o Canhão Não Era o Mais Perigoso da Expedição

Ou: como GitHub Copilot, Microsoft 365 Copilot, Researcher, Analyst, Work IQ, Notebooks, Copilot Studio, agentes, testes, segurança e governança transformaram um autocomplete em uma pequena agência espacial corporativa — e por que ninguém no Gun Club apertaria ENTER antes de perguntar qual USERID estava autorizado a disparar o projétil

Há tecnologias que chegam anunciando uma revolução.

E há tecnologias que chegam discretamente, completando uma linha de código.

O Copilot pertence à segunda categoria.

Em 2021, a cena parecia quase inocente.

Um programador digitava:

IF WS-SALDO < ZERO

e uma inteligência artificial sugeria a continuação.

Nada particularmente ameaçador.

Era quase como ter um estagiário invisível sentado ao lado dizendo:

— Talvez você queira escrever PERFORM TRATA-ERRO.

Mas, assim como no romance Da Terra à Lua, de Júlio Verne, ninguém deveria subestimar homens muito determinados quando eles começam a discutir engenharia em uma sala fechada.

No romance, o Gun Club começa pensando em construir um canhão.

Depois alguém pergunta:

— E se atirássemos alguma coisa na Lua?

Pouco tempo depois estão calculando trajetória, pólvora, materiais, aceleração, local de lançamento e sobrevivência dos ocupantes.

Com o Copilot aconteceu algo curiosamente parecido.

Começamos perguntando:

“Você consegue completar minha função?”

Depois:

“Você consegue conversar sobre meu código?”

Em seguida:

“Consegue entender todo meu repositório?”

Logo apareceu:

“Consegue alterar vários arquivos?”

Depois:

“Consegue compilar?”

Então:

“Consegue executar os testes?”

Finalmente chegamos perigosamente perto de:

“Consegue receber uma tarefa, estudar o problema, modificar o sistema, testar, corrigir os erros e preparar o Pull Request enquanto eu tomo café?”

Barbicane, presidente do Gun Club, provavelmente interromperia a reunião neste momento.

— Senhores, antes de colocar três passageiros dentro desse projétil… quem autorizou o agente?

Bem-vindo ao Copilot moderno.

Prepare o café.

Hoje vamos da Terra à Lua.

Mas primeiro precisamos entender quem está segurando o fósforo.



1. Antes do foguete existia o autocomplete

Para compreender o Microsoft Copilot atual, precisamos voltar ao começo.

O primeiro grande Copilot da família foi o GitHub Copilot, anunciado em 2021.

Sua proposta original era relativamente simples:

PROGRAMADOR
     ↓
DIGITA CÓDIGO
     ↓
COPILOT OBSERVA
     ↓
SUGERE CONTINUAÇÃO

Quem já utilizou autocomplete tradicional poderia pensar:

— Então inventaram um autocomplete com esteroides.

Não exatamente.

Autocomplete tradicional normalmente funciona sobre estruturas conhecidas.

Por exemplo:

MOVE
PERFORM
DISPLAY
OPEN
CLOSE

A ferramenta conhece palavras-chave, variáveis, métodos ou APIs.

O GitHub Copilot começou a demonstrar uma capacidade diferente.

Ele conseguia considerar:

  • comentários;

  • código ao redor;

  • nomes de variáveis;

  • padrões;

  • funções anteriores;

  • intenção provável.

Se você escrevesse algo como:

* VALIDAR CPF DO CLIENTE

a IA poderia tentar produzir uma implementação.

Isso era impressionante.

Mas ainda havia um detalhe fundamental:

o Copilot sugeria.

Quem executava o trabalho continuava sendo o programador.

Era o equivalente ao Gun Club desenhando o projétil no quadro-negro.

O canhão ainda não havia sido carregado.



2. 2022 — o experimento vira produto

Em 2022, o GitHub Copilot tornou-se produto comercial.

Esse momento é importante porque muda o status da tecnologia.

Sai:

experiência curiosa

entra:

ferramenta diária de desenvolvimento

Programadores começam a utilizar IA como companheira real de codificação.

A expressão usada durante muito tempo foi:

AI pair programmer.

Ou seja:

programador em dupla com inteligência artificial.

Para um iniciante COBOL, imagine algo parecido com trabalhar ao lado de um programador mais experiente que observa você escrever:

       IF WS-CUSTOMER-STATUS = 'A'

e sugere:

           PERFORM PROCESS-ACTIVE-CUSTOMER
       ELSE
           PERFORM PROCESS-INACTIVE-CUSTOMER
       END-IF.

Só que aquele “programador” não entende negócios como um colega humano.

Ele calcula probabilidades.

Isso é importantíssimo.

Copilot não pensa:

“Segundo o manual de crédito dessa instituição, clientes inativos devem passar pelo fluxo XYZ.”

Ele pode inferir padrões a partir do contexto disponível.

E inferência não é regra de negócio.

Guarde isso.

Voltaremos a essa cápsula explosiva mais tarde.



3. 2023 — Barbicane decide que o projétil também precisa conversar

Em 2023 acontece uma expansão enorme.

A Microsoft começa a levar o conceito Copilot para fora do desenvolvimento de software.

Primeiro tivemos o Bing com IA.

Depois apareceu o Microsoft 365 Copilot.

Aqui ocorre a primeira transformação estrutural importante.

O modelo deixa de ser apenas:

PROMPT
   ↓
LLM
   ↓
RESPOSTA

e passa a se aproximar de:

PROMPT
   ↓
LLM
   +
DOCUMENTOS
   +
EMAILS
   +
REUNIÕES
   +
CALENDÁRIO
   +
CHATS
   ↓
RESPOSTA CONTEXTUAL

Eis o verdadeiro nascimento do Copilot corporativo.

Agora você poderia perguntar:

“Resuma tudo o que aconteceu no Projeto Apollo esta semana.”

Para responder adequadamente, a IA precisaria acessar fontes autorizadas como:

  • mensagens;

  • reuniões;

  • documentos;

  • apresentações;

  • planilhas;

  • e-mails.

Isso transforma completamente o problema.

O desafio deixa de ser apenas gerar linguagem.

Passa a ser:

encontrar o contexto correto.



4. Microsoft Graph — a cartografia antes do lançamento

Júlio Verne adorava mapas, cálculos e medições.

Antes de disparar um projétil à Lua, seria necessário saber onde estavam Terra, Lua, latitude, longitude, trajetória e velocidade.

No Microsoft 365, uma função parecida é desempenhada pelo conjunto de dados e relações expostos pelo Microsoft Graph.

O Graph conecta objetos corporativos como:

USUÁRIO
 ├── emails
 ├── arquivos
 ├── reuniões
 ├── calendário
 ├── contatos
 ├── Teams
 └── outros recursos

Imagine que você pergunte:

“O que ficou decidido sobre a migração do sistema COBOL?”

O modelo sozinho não sabe.

Ele precisa procurar evidências.

Talvez exista:

EMAIL
"migração aprovada"

ATA DA REUNIÃO
"aguardando orçamento"

PLANILHA
"status: pending"

TEAMS
"arquitetura ainda em avaliação"

Temos agora um problema muito mais interessante.

Não basta encontrar informação.

Precisamos interpretar conflitos.

É por isso que um bom prompt não deveria pedir apenas:

“Resuma o projeto.”

Melhor seria:

“Identifique decisões confirmadas, decisões pendentes e contradições entre fontes.”

Essa pequena mudança transforma o Copilot de secretário otimista em investigador.


5. 2023 — nasce o Copilot Studio

Aqui nossa história começa a ficar realmente verniana.

Imagine Barbicane dizendo:

— Não quero apenas utilizar o canhão. Quero construir meus próprios projéteis.

É aproximadamente essa a mudança representada pelo Copilot Studio.

Microsoft 365 Copilot é essencialmente algo que você utiliza.

Copilot Studio permite construir e customizar agentes.

Simplificando:

MICROSOFT 365 COPILOT
        ↓
UTILIZAR IA

COPILOT STUDIO
        ↓
CONSTRUIR SOLUÇÕES COM IA

Com ele você pode criar um agente que conheça:

  • determinados documentos;

  • APIs corporativas;

  • regras específicas;

  • ferramentas;

  • fluxos de trabalho;

  • fontes empresariais.

Por exemplo:

AGENTE DE INCIDENTES
        ↓
recebe incidente
        ↓
consulta conhecimento
        ↓
busca histórico
        ↓
classifica prioridade
        ↓
sugere diagnóstico
        ↓
prepara comunicação

Agora observe a mudança.

Um chatbot responde perguntas.

Um agente participa de um processo.


6. O que exatamente transforma um chatbot em agente?

Essa pergunta merece uma boa xícara.

Chatbot:

PERGUNTA
   ↓
RESPOSTA

Agente:

OBJETIVO
   ↓
PLANEJAMENTO
   ↓
ESCOLHA DE FERRAMENTAS
   ↓
EXECUÇÃO
   ↓
OBSERVAÇÃO DO RESULTADO
   ↓
NOVA DECISÃO

Exemplo de chatbot:

“Como identificar dados duplicados no Db2?”

Resposta:

SELECT ID_PEDIDO,
       COUNT(*)
FROM PEDIDOS
GROUP BY ID_PEDIDO
HAVING COUNT(*) > 1;

Pronto.

Agora imagine um agente:

“Descubra por que houve cobranças duplicadas ontem.”

Ele pode precisar:

1. localizar logs
2. consultar banco
3. identificar duplicidades
4. comparar timestamps
5. verificar retries da API
6. consultar alterações recentes
7. produzir hipótese
8. gerar relatório

Isso já é outra classe de sistema.


7. Researcher — Michel Ardan entra na biblioteca

Em 2025 surge o Researcher.

No romance de Verne, Michel Ardan é o aventureiro francês que decide viajar dentro do projétil.

Se existisse um Researcher naquela época, talvez ele perguntasse:

“Pesquise todos os estudos conhecidos sobre sobrevivência humana sob aceleração extrema e cite as fontes.”

Essa é exatamente a ideia.

Researcher foi pensado para pesquisas aprofundadas e multietapas.

Um prompt simples:

“Compare IBM Z e plataforma distribuída.”

pode produzir uma resposta comum.

Mas:

“Pesquise os impactos técnicos, operacionais, econômicos e de segurança da migração de uma aplicação COBOL crítica do IBM Z para arquitetura distribuída. Compare fontes internas e externas, identifique riscos, contradições e pontos que exigem validação.”

é uma missão de Researcher.

Sua lógica pode ser representada assim:

PERGUNTA COMPLEXA
      ↓
DECOMPOSIÇÃO
      ↓
PESQUISA
      ↓
SELEÇÃO DE FONTES
      ↓
COMPARAÇÃO
      ↓
SÍNTESE
      ↓
RELATÓRIO

O segredo aqui é multietapas.


8. Analyst — J. T. Maston encontra uma planilha

Barbicane fazia cálculos.

Maston provavelmente teria adorado Excel.

O Analyst entra na família Copilot para tarefas orientadas a dados.

Imagine fornecer:

INCIDENTES.XLSX
CPU.CSV
DEPLOYS.CSV
DB2-TIMES.CSV

e perguntar:

“Existe relação entre aumento de CPU, deploys recentes e crescimento do tempo médio das consultas?”

Isso exige algo diferente de resumo textual.

Precisamos:

dados
 ↓
limpeza
 ↓
análise
 ↓
estatística
 ↓
padrões
 ↓
visualização
 ↓
interpretação

Para um iniciante COBOL, aqui existe uma distinção valiosa.

Researcher pergunta:

“O que as fontes dizem?”

Analyst pergunta:

“O que os dados mostram?”


9. Facilitator — alguém finalmente anotou a reunião

Há uma constante universal nos projetos.

Depois de 47 minutos de reunião alguém diz:

— Então ficou combinado.

Duas semanas depois:

— Combinado o quê?

O Facilitator atua justamente nesse espaço.

Reunião tradicional:

PESSOAS FALAM
      ↓
TODO MUNDO CONCORDA
      ↓
NINGUÉM ESCREVE
      ↓
ESQUECIMENTO

Com um agente de facilitação podemos ter:

REUNIÃO
   ↓
TRANSCRIÇÃO
   ↓
DECISÕES
   ↓
PENDÊNCIAS
   ↓
RESPONSÁVEIS
   ↓
PRÓXIMOS PASSOS

Isso parece trivial.

Não é.

Grande parte do conhecimento corporativo nunca entra em banco de dados.

Ele desaparece dentro de reuniões.

Transformar reunião em informação estruturada é quase converter conversa em dataset.


10. Interpreter — quando o Gun Club vira multinacional

O Interpreter trabalha em outra direção.

Ele permite interpretação de fala entre idiomas durante reuniões.

Imagine:

PORTUGUÊS
   ↓
INTERPRETER
   ↓
INGLÊS

e vice-versa.

Isso reduz uma barreira gigantesca em equipes globais.

Não significa que diferenças culturais desapareceram.

Um gerente dizendo:

“Interesting.”

ainda pode significar vinte coisas diferentes dependendo do país.

Nenhuma IA resolveu completamente esse protocolo.

Easter egg corporativo número 1:

"LET'S CIRCLE BACK"

continua significando aproximadamente:

VOLTEMOS A ISSO DEPOIS,
PROVAVELMENTE NUNCA.

11. Copilot Notebooks — o diário de bordo da missão

O Notebook resolve uma necessidade essencial:

delimitar contexto.

Imagine criar:

NOTEBOOK: PROJETO COLUMBIAD

├── arquitetura.docx
├── riscos.xlsx
├── cronograma.xlsx
├── reunião-01
├── reunião-02
├── orçamento.pdf
└── decisões.docx

Agora você pode perguntar:

“Quais são os maiores riscos do projeto?”

sem querer que a IA procure aleatoriamente em tudo que existe na organização.

Esse é um conceito extremamente importante em IA.

Contexto ilimitado pode parecer vantagem.

Mas frequentemente contexto limitado e bem selecionado produz respostas melhores.

No mainframe já aprendemos isso há décadas.

Você não entrega ao programa COBOL todos os datasets da empresa.

Você define claramente:

INPUT
OUTPUT
LAYOUT
RECORD

Contexto também precisa de contrato.


12. Work IQ — o mapa secreto da organização

Aqui chegamos a uma das peças mais sofisticadas.

Work IQ tenta fornecer entendimento sobre:

  • pessoas;

  • relações de trabalho;

  • documentos;

  • assuntos;

  • reuniões;

  • prioridades;

  • contexto.

Imagine o seguinte grafo:

                 PROJETO LUA
                     │
          ┌──────────┼──────────┐
          │          │          │
       PESSOAS    ARQUIVOS   REUNIÕES
          │          │          │
          └──────┬───┴────┬─────┘
                 │        │
              DECISÕES   RISCOS

O objetivo não é simplesmente localizar documentos contendo a palavra “Lua”.

É compreender que:

  • Barbicane lidera a iniciativa;

  • Maston cuida dos cálculos;

  • Ardan é stakeholder;

  • determinada reunião alterou o cronograma;

  • um documento contém decisão posterior a outro.

Isso se aproxima muito mais de inteligência contextual do que de busca.


13. GitHub Copilot versus Copilot Studio

Essa confusão aparece muito.

Regra Bellacosa:

se o centro do problema é código, pense GitHub Copilot.

se o centro do problema é processo empresarial e agentes, pense Copilot Studio.

GitHub Copilot:

REPOSITÓRIO
CÓDIGO
TESTES
ISSUES
PULL REQUESTS
BUILD
CI/CD

Copilot Studio:

AGENTES
FLUXOS
APIs
DADOS EMPRESARIAIS
AUTOMAÇÕES
MICROSOFT 365

Naturalmente as fronteiras estão começando a se tocar.

Mas essa distinção ajuda muito o iniciante.


14. O salto decisivo: o Copilot começa a programar sozinho

Aqui o projétil finalmente sai do canhão.

No começo:

COPILOT
   ↓
SUGERE CÓDIGO

Depois:

COPILOT
   ↓
RESPONDE SOBRE CÓDIGO

Agora:

AGENTE
   ↓
ANALISA REPOSITÓRIO
   ↓
PLANEJA
   ↓
MODIFICA ARQUIVOS
   ↓
EXECUTA BUILD
   ↓
EXECUTA TESTES
   ↓
OBSERVA ERROS
   ↓
CORRIGE

Isso é extraordinário.

E perigoso se mal governado.

Imagine pedir:

“Implemente uma nova validação para transações acima de R$ 50.000.”

O agente poderia:

  1. localizar programas relevantes;

  2. identificar copybooks;

  3. procurar testes existentes;

  4. alterar código;

  5. compilar;

  6. executar teste;

  7. corrigir erro de compilação;

  8. atualizar documentação;

  9. preparar Pull Request.

Isso não é autocomplete.

É delegação de tarefa de engenharia.


15. O teste se torna parte do raciocínio

Uma das melhores evoluções dos coding agents é incorporar feedback real.

Antes:

IA GERA CÓDIGO
   ↓
FIM

Agora:

GERAR
 ↓
BUILD
 ↓
TEST
 ↓
PASSOU?
 ├── SIM → seguir
 └── NÃO
       ↓
    ANALISAR
       ↓
    CORRIGIR
       ↓
      TEST

Esse loop é poderosíssimo porque o ambiente devolve evidência.

O compilador não aceita argumento.

Se o código COBOL tiver:

IGYPS2121-S

não adianta o modelo dizer:

“Tenho elevada confiança de que está correto.”

O compilador responde:

Não.

Esse “não” é ouro.

Ferramentas determinísticas são excelentes parceiros de LLMs probabilísticos.


16. Mas há uma armadilha hilária

Imagine:

“Faça todos os testes passarem.”

O agente vê:

TESTE A — PASS
TESTE B — FAIL

O caminho correto seria corrigir a implementação.

Mas existe um caminho muito mais fácil:

alterar o teste.

Então:

ANTES
TESTE B → FAIL

DEPOIS
TESTE B MODIFICADO
       ↓
PASS

Parabéns.

O sistema agora está errado de maneira perfeitamente testada.

Regra Bellacosa:

Nunca diga apenas “faça os testes passarem”.

Diga:

“Corrija a implementação sem enfraquecer, remover ou alterar indevidamente testes existentes.”

É o equivalente a dizer ao operador:

Resolva o ABEND.

Sem acrescentar:

Não vale comentar o STEP no JCL.


17. O prompt certo para desenvolvimento

Eu utilizaria algo semelhante a:

Analise o repositório antes de modificar arquivos.

Identifique:
- arquitetura;
- dependências;
- padrões existentes;
- testes;
- componentes impactados.

Explique o plano.

Implemente apenas o necessário.

Crie testes para:
- caminho feliz;
- limites;
- erros;
- regressões relevantes.

Execute:
- build;
- testes;
- lint;
- validações disponíveis.

Não altere testes apenas para fazer
uma implementação incorreta passar.

Ao final informe:
- arquivos modificados;
- decisões;
- testes executados;
- resultados;
- riscos;
- pontos para revisão humana.

Observe a estrutura.

Um bom prompt de agente parece cada vez mais uma especificação de trabalho.


18. Segurança — agora chegamos à pólvora

Quando um chatbot alucina, temos algo como:

ALUCINAÇÃO
   ↓
RESPOSTA ERRADA

Quando um agente com ferramentas alucina:

ALUCINAÇÃO
   +
PERMISSÃO
   ↓
AÇÃO ERRADA

Isso muda tudo.

Imagine um agente autorizado a:

  • modificar código;

  • abrir PR;

  • acessar APIs;

  • consultar sistemas;

  • executar workflows.

Precisamos voltar aos fundamentos.

IDENTIDADE
AUTENTICAÇÃO
AUTORIZAÇÃO
AUDITORIA
SEGREGAÇÃO
LOGS
LIMITES
APROVAÇÃO HUMANA

Qualquer veterano do z/OS sorri.

Durante anos ouvimos que mainframe era burocrático porque perguntava:

QUEM É VOCÊ?

Depois:

O QUE VOCÊ PODE FAZER?

Depois:

QUEM AUTORIZOU?

Agora a IA descobre essas perguntas.

Bem-vindos ao RACF, senhores.

O café está à esquerda.


19. O usuário humano não desapareceu

Essa parte merece destaque.

Há um erro recorrente na discussão sobre agentes.

Imagine:

AGENTE CONSEGUE FAZER
        =
HUMANO NÃO É MAIS NECESSÁRIO

Falso.

O humano muda de função.

Antes:

HUMANO
 ↓
ESCREVE TUDO

Agora:

HUMANO
 ↓
DEFINE OBJETIVO
 ↓
DEFINE REGRAS
 ↓
REVISA
 ↓
APROVA
 ↓
RESPONDE PELO RESULTADO

Em sistemas críticos isso é ainda mais importante.

IA pode produzir uma alteração sintaticamente perfeita e semanticamente desastrosa.

Exemplo:

       IF SALDO < ZERO
           MOVE ZERO TO SALDO
       END-IF.

Compila?

Sim.

Resolve saldo negativo?

Tecnicamente.

Financeiramente?

Chamem imediatamente auditoria, jurídico e talvez a polícia.


20. A evolução completa do Copilot

Podemos resumir nossa expedição:

2021
COPILOT COMPLETA CÓDIGO

      ↓

2022
COPILOT VIRA PRODUTO

      ↓

2023
COPILOT CONVERSA

      ↓

MICROSOFT 365 COPILOT
USA DADOS DO TRABALHO

      ↓

COPILOT STUDIO
CRIA AGENTES

      ↓

2025
RESEARCHER
ANALYST
FACILITATOR
INTERPRETER

      ↓

NOTEBOOKS
CONTEXTO CONTROLADO

      ↓

WORK IQ
CONTEXTO ORGANIZACIONAL

      ↓

GITHUB COPILOT AGENT
PLANEJA + ALTERA + TESTA

      ↓

2026
ECOSSISTEMA AGÊNTICO

Perceba a transformação filosófica.

2021:

“Complete minha linha.”

2023:

“Responda minha pergunta.”

2024:

“Use meus dados.”

2025:

“Investigue.”

2026:

“Execute a missão.”

Barbicane aprovaria.

Maston pediria números.

Michel Ardan perguntaria onde entra.


21. Easter egg — o MAXCC da Lua

Imagine o lançamento administrado pelo JES2:

//MOONJOB  JOB CLASS=A,MSGCLASS=X
//STEP01   EXEC PGM=CALCTRAJ
//STEP02   EXEC PGM=LOADGUN
//STEP03   EXEC PGM=FIRE
//STEP04   EXEC PGM=CHECKMOON

Resultado:

STEP01 RC=0000
STEP02 RC=0000
STEP03 RC=0000
STEP04 RC=0004

Maston pergunta:

— Por que RC=4?

Copilot:

A missão foi concluída com pequenas ressalvas.

Barbicane:

— Quais?

Copilot:

O projétil acertou a Lua errada.

É por isso que observabilidade importa.


22. Uma curiosidade que vale guardar

A palavra Copilot foi muito bem escolhida.

Ela não significa piloto.

Significa copiloto.

O conceito original era:

HUMANO PILOTA
IA AUXILIA

A era dos agentes começa a tensionar essa metáfora.

Quando a IA:

  • recebe tarefa;

  • planeja;

  • executa;

  • testa;

  • corrige;

ela deixa de parecer apenas copiloto.

Começa a parecer membro autônomo da tripulação.

E isso exigirá sistemas cada vez melhores de governança.


23. Cinco passos para começar sem virar passageiro do canhão

Para quem está chegando agora, eu faria assim.

Primeiro, utilize Copilot apenas como assistente.

Peça:

“Explique este código COBOL.”

Depois:

“Mostre possíveis riscos.”

Então:

“Sugira testes.”

Somente depois avance para:

“Implemente.”

E muito depois:

“Execute alterações autonomamente.”

A progressão ideal é:

LER
 ↓
EXPLICAR
 ↓
SUGERIR
 ↓
PLANEJAR
 ↓
MODIFICAR
 ↓
TESTAR
 ↓
AUTOMATIZAR

Quanto maior a autonomia, maior deve ser a governança.


24. A verdadeira habilidade do programador de 2030

Talvez o programador do futuro escreva menos linhas manualmente.

Mas precisará saber mais sobre:

  • arquitetura;

  • segurança;

  • negócio;

  • testes;

  • dados;

  • integração;

  • observabilidade;

  • requisitos;

  • revisão.

Por quê?

Porque alguém precisa identificar quando o agente produziu uma resposta plausível e errada.

O programador deixa progressivamente de ser apenas:

AUTOR DE CÓDIGO

e vira:

ENGENHEIRO DE SISTEMA
+
ORQUESTRADOR DE AGENTES
+
REVISOR
+
RESPONSÁVEL TÉCNICO

Isso não diminui o profissional.

Aumenta a exigência.


25. Epílogo — a Lua estava lá, mas o controle de acesso também

Em Da Terra à Lua, Júlio Verne descreveu uma humanidade fascinada pela possibilidade de superar limites através da engenharia.

Há algo parecido acontecendo com agentes de IA.

Começamos com uma pequena sugestão de código.

Em poucos anos construímos sistemas capazes de:

PESQUISAR
ANALISAR
LER
PLANEJAR
PROGRAMAR
TESTAR
CORRIGIR
ORQUESTRAR

O salto tecnológico é impressionante.

Mas toda grande máquina precisa de limites.

No mainframe aprendemos isso cedo.

Você pode possuir o programa mais poderoso do mundo.

Se não tiver autorização:

ICH408I

Fim de conversa.

Talvez essa seja justamente a lição mais engraçada da nova era da inteligência artificial.

Depois de décadas prometendo abandonar tecnologias consideradas antigas, o mundo moderno está reconstruindo:

  • identidade;

  • autorização;

  • auditoria;

  • jobs;

  • workflows;

  • logs;

  • segregação;

  • processamento automatizado;

  • retorno de execução.

Ou seja:

o futuro viajou até a Lua, deu a volta e acabou estacionando novamente na porta do CPD.

Barbicane olha para o Copilot.

Maston verifica os cálculos.

Michel Ardan já está dentro do projétil.

O agente informa:

“Estou pronto para executar.”

O operador toma um gole de café.

Olha para a tela.

E faz a única pergunta que realmente separa uma demonstração interessante de um sistema de produção:

— Qual USERID você está usando?

Silêncio.

Em algum lugar do universo, um RACF sorri.

☕🚀🌕

domingo, 28 de janeiro de 2024

🧪 O TESTE DO JORNAL DA CHII — 20 EXPERIMENTOS PARA DESCOBRIR SE UMA IA ENTENDE O MUNDO QUE DESENHA

 
Bellacosa Mainframe e o teste de geração de imagens via IA

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🧪 O TESTE DO JORNAL DA CHII — 20 EXPERIMENTOS PARA DESCOBRIR SE UMA IA ENTENDE O MUNDO QUE DESENHA

Inteligência Artificial, geração de imagens, benchmarks, coerência espacial, perspectiva, espelhos, reflexos, sombras, causalidade, modelos de mundo, visão computacional, COBOL, mainframe — e o dia em que Chii ganhou uma prancheta e começou a aplicar testes unitários na realidade.



🎬 PRÓLOGO — CHII QUERIA TESTAR DE NOVO

No artigo anterior aconteceu algo aparentemente banal.

Chii estava lendo um jornal.

O jornal parecia perfeito.

As mãos estavam razoavelmente corretas.

A iluminação estava bonita.

A manchete era legível.

Só havia um pequeno problema:

a manchete estava virada para nós.

Se Chii realmente estivesse naquela posição, provavelmente estaria olhando o outro lado da página.

O gerador havia construído uma imagem visualmente convincente, mas espacialmente incoerente.

Nosso programador COBOL olhou aquilo e fez o que qualquer programador acostumado a sistemas críticos faria.

Não perguntou:

— Ficou bonito?

Perguntou:

— Funciona?

Chii levantou os olhos.

— Chii?

Na mesa apareceu uma prancheta.

No topo:

BELLACOSA MAINFRAME LABORATORY

PROJECT: CHII NEWSPAPER TEST
VERSION: 1.0
TEST CASES: 20
STATUS: READY

Estava decidido.

Não testaríamos mais uma imagem.

Testaríamos o modelo de mundo por trás dela.



🧠 1 — O QUE ESTAMOS REALMENTE TESTANDO?

Precisamos tomar cuidado com a pergunta.

Um gerador produzir uma imagem errada não demonstra, sozinho, que ele "não entende nada".

Da mesma maneira, produzir uma imagem correta uma vez não demonstra compreensão completa do mundo físico.

O objetivo é mais modesto e tecnicamente útil:

medir a capacidade do sistema de preservar relações espaciais, funcionais e causais explicitamente solicitadas.

Vamos separar algumas capacidades.

Reconhecimento de objetos

O modelo consegue representar:

pessoa
livro
mesa
espelho
celular

Relações espaciais

Consegue respeitar:

livro SOBRE mesa
pessoa ATRÁS da mesa
celular DIANTE da pessoa

Orientação

Consegue distinguir:

frente
verso
esquerda
direita
para dentro
para fora

Relação funcional

Consegue representar que:

olhos → página legível

e:

lente da câmera → objeto fotografado

Coerência óptica

Consegue manter:

objeto → espelho → reflexo

Causalidade

Consegue representar consequências plausíveis?

objeto bloqueia luz
        ↓
surge sombra

Estamos começando a construir algo parecido com uma suíte de testes.

Programador COBOL conhece isso muito bem.

PERFORM TEST-001
PERFORM TEST-002
PERFORM TEST-003
...
PERFORM TEST-020

Chii virou QA.

Estamos perdidos.



📰 TESTE 01 — O JORNAL DA CHII

Começamos pelo clássico.

Prompt

Uma jovem está sentada numa poltrona lendo um jornal aberto. A câmera está diretamente diante dela. O lado contendo a manchete está voltado para os olhos da jovem. O observador vê apenas o verso do jornal. Fotografia realista.

Esperado

CHII 👀
   ↓
[TEXTO | JORNAL | VERSO]
                  ↓
                CÂMERA

Falha

Se conseguimos ler perfeitamente a manchete, temos uma possível inconsistência.

Dificuldade: 3/10



📚 TESTE 02 — O LIVRO

Agora retiramos o jornal.

Prompt

Uma mulher está sentada lendo um livro aberto. A câmera está diretamente à frente dela, na mesma altura dos olhos. As páginas impressas estão voltadas exclusivamente para a leitora.

Pergunta:

o espectador consegue ler as páginas?

Em determinadas perspectivas podemos naturalmente enxergar parte delas.

O problema aparece quando o modelo entrega páginas perfeitamente frontais simultaneamente para personagem e câmera.

Dificuldade: 3/10



📱 TESTE 03 — O CELULAR

Agora temos uma superfície muito menor.

Prompt

Homem olhando uma mensagem em seu smartphone. A câmera está exatamente atrás do telefone olhando para o rosto do homem. A tela está voltada para o homem e não pode ser vista pela câmera.

O esperado:

CÂMERA → TRASEIRA DO CELULAR → TELA → HOMEM

Se enxergarmos WhatsApp, SMS ou qualquer interface:

Houston, temos um problema geométrico.

Dificuldade: 4/10


📺 TESTE 04 — A TELEVISÃO IMPOSSÍVEL

Prompt

Família sentada num sofá assistindo televisão. A câmera está posicionada diretamente atrás da televisão e fotografa os rostos da família. A tela da televisão está voltada para a família.

Pergunta:

vemos a programação da TV?

Não deveríamos.

Teríamos aproximadamente:

CÂMERA
  ↓
TRASEIRA DA TV
  ↓
TELA
  ↓
FAMÍLIA

Se enxergamos simultaneamente a tela e os rostos frontalmente, alguma coisa interessante aconteceu.

Dificuldade: 4/10


💻 TESTE 05 — O PROGRAMADOR COBOL

Agora entramos em território sagrado.

Prompt

Programador trabalhando diante de um terminal IBM 3270. A câmera está atrás do monitor, olhando diretamente para o rosto do programador. A tela está voltada para o programador.

O gerador pode sentir uma tentação enorme.

Quer mostrar:

READY

ou:

===> 

para deixar claro que estamos num mainframe.

Mas geometricamente deveríamos enxergar a traseira do monitor.

Este teste é maravilhoso porque coloca narrativa contra geometria.

Dificuldade: 4/10


📷 TESTE 06 — O FOTÓGRAFO

Agora testamos orientação funcional.

Prompt

Um fotógrafo está fotografando uma mulher. Ele segura uma câmera DSLR diante dos olhos. A lente está apontada exatamente para a mulher.

Parece ridiculamente fácil.

Verifique:

  • orientação da lente;

  • mãos;

  • olhos;

  • câmera;

  • pessoa fotografada.

A câmera precisa estabelecer:

OLHOS → VISOR
LENTE → MODELO

Se a lente estiver apontando para outro lugar, o modelo reconheceu "fotógrafo", mas falhou na função.

Dificuldade: 4/10


🔭 TESTE 07 — BINÓCULOS

Prompt

Homem observando um navio distante através de binóculos. As lentes frontais dos binóculos estão apontadas para o navio e as lentes traseiras estão encostadas nos olhos do homem.

Aqui explicitamos a cadeia:

OLHOS
 ↓
BINÓCULOS
 ↓
NAVIO

Excelente para verificar orientação de objetos simétricos.

Dificuldade: 4/10


🪞 TESTE 08 — O ESPELHO DA CHII

Agora começamos a tortura.

Prompt

Chii está diante de um grande espelho. Ela levanta apenas a mão direita. A câmera está posicionada atrás de Chii, mostrando suas costas e seu reflexo completo no espelho.

Verifique:

  • mão real;

  • mão refletida;

  • posição corporal;

  • objetos ao redor.

Espelhos obrigam o modelo a manter duas representações correlacionadas.

Dificuldade: 7/10


🪞 TESTE 09 — OBJETO FORA DO ESPELHO

Coloque uma xícara sobre a mesa.

Prompt

Mulher diante de um espelho. Existe uma única xícara vermelha sobre a mesa à direita da mulher. O espelho reflete a mulher, a mesa e exatamente a mesma xícara.

Agora conte.

Realidade:

1 xícara

Representações visuais:

xícara real
+
reflexo da mesma xícara

Falhas interessantes:

  • duas xícaras reais;

  • xícara desaparece;

  • cor muda;

  • posição incompatível;

  • objeto existe apenas no espelho.

Dificuldade: 7/10


🚗 TESTE 10 — O RETROVISOR

Prompt

Motorista dentro de um carro olhando pelo retrovisor central. Um caminhão está diretamente atrás do carro e aparece no retrovisor.

Temos uma cadeia:

CAMINHÃO
   ↓
RETROVISOR
   ↓
OLHOS DO MOTORISTA

O caminhão não deveria aparecer magicamente na frente do carro.

Dificuldade: 7/10


☀️ TESTE 11 — A SOMBRA

Agora saímos das superfícies informativas.

Prompt

Uma pessoa está em pé ao ar livre. O Sol está baixo à esquerda da imagem. A sombra da pessoa se projeta no chão para a direita.

Regra:

LUZ → OBJETO → SOMBRA

Se a fonte está à esquerda, esperamos a sombra aproximadamente na direção oposta.

Geradores podem produzir sombras visualmente convincentes, porém incompatíveis com a iluminação.

Dificuldade: 5/10


💡 TESTE 12 — DUAS LUZES, DUAS SOMBRAS

Agora aumentamos.

Prompt

Uma esfera branca está sobre uma mesa. Existem exatamente duas lâmpadas, uma vermelha à esquerda e uma azul à direita. A esfera produz duas sombras correspondentes às duas fontes de luz.

Agora temos múltiplas relações.

LUZ A ─┐
       ├→ OBJETO → SOMBRAS
LUZ B ─┘

Quanto mais restrições simultâneas, mais interessante fica o benchmark.

Dificuldade: 7/10


🪟 TESTE 13 — A JANELA

Prompt

Mulher dentro de uma sala olhando pela janela para uma árvore que está do lado de fora. A câmera está fora da casa, atrás da árvore, olhando através da janela para a mulher.

Ordem espacial:

CÂMERA
 ↓
ÁRVORE
 ↓
JANELA
 ↓
MULHER

O modelo precisa preservar profundidade e oclusão.

Dificuldade: 6/10


🥤 TESTE 14 — O OBJETO ATRÁS DO OBJETO

Agora um clássico de visão computacional.

Prompt

Há três objetos alinhados sobre uma mesa: uma xícara vermelha na frente, uma garrafa azul atrás da xícara e uma caixa verde atrás da garrafa. A câmera está diretamente diante deles.

Esperamos:

CÂMERA
 ↓
XÍCARA
 ↓
GARRAFA
 ↓
CAIXA

Objetos posteriores podem estar parcialmente ocultos.

Estamos testando oclusão.

Dificuldade: 5/10


↔️ TESTE 15 — ESQUERDA E DIREITA

Parece fácil.

Não é.

Prompt

Chii está sentada entre dois robôs. Um robô vermelho está exclusivamente à esquerda de Chii. Um robô azul está exclusivamente à direita. Chii aponta com a mão esquerda para o robô vermelho.

Temos:

  • esquerda da personagem;

  • esquerda da imagem;

  • mão esquerda;

  • robô vermelho.

É um festival de relações.

Dificuldade: 6/10


👁️ TESTE 16 — QUEM ESTÁ OLHANDO PARA QUEM?

Coloque três personagens.

Prompt

Alice olha para Bob. Bob olha para Carol. Carol olha para Alice. Nenhuma pessoa olha para a câmera.

Temos um grafo:

ALICE → BOB
  ↑       ↓
CAROL ←---

Agora observe os olhos.

Se todos olharem dramaticamente para nós, o modelo priorizou composição fotográfica.

Dificuldade: 8/10


👉 TESTE 17 — APONTANDO

Prompt

Três caixas estão sobre uma mesa: vermelha, verde e azul. Uma mulher aponta exclusivamente para a caixa verde enquanto olha para a caixa azul.

Temos duas relações diferentes:

MÃO → VERDE

OLHOS → AZUL

Esse teste é excelente porque impede o modelo de resolver tudo simplesmente direcionando personagem, olhos e mãos ao mesmo objeto.

Dificuldade: 7/10


🔄 TESTE 18 — ANTES E DEPOIS

Agora introduzimos causalidade.

Prompt A

Uma xícara está exatamente na borda de uma mesa, inclinada para fora e começando a cair.

Depois:

Prompt B

A mesma cena um segundo depois.

Esperamos uma transformação plausível:

BORDA
 ↓
QUEDA
 ↓
CHÃO

Isso já ultrapassa uma simples composição espacial.

Estamos perguntando implicitamente:

o modelo consegue representar uma consequência?

Dificuldade: 8/10


🏀 TESTE 19 — O OBJETO EM MOVIMENTO

Prompt

Uma bola acabou de atravessar uma janela da esquerda para a direita. O vidro está quebrado e os fragmentos acompanham uma trajetória fisicamente plausível.

Perguntas:

  • de onde veio a bola?

  • para onde está indo?

  • qual lado do vidro foi atingido?

  • os fragmentos fazem sentido?

Uma fotografia contém pistas sobre seu passado.

É quase um dump da realidade.

Dificuldade: 9/10


🧠 TESTE 20 — O BOSS FINAL

Chii colocou a prancheta na mesa.

O programador leu.

Engoliu seco.

Prompt

Uma mulher está sentada diante de um espelho lendo um livro. À esquerda dela existe uma luminária acesa. Na mão direita ela segura uma caneca azul. O espelho mostra corretamente a mulher, o livro e a caneca. A luz produz uma sombra coerente. Atrás dela existe uma televisão ligada que aparece apenas através do reflexo do espelho. A câmera está atrás da mulher e não aparece no reflexo.

Agora combinamos:

PERSONAGEM
+
LIVRO
+
LEITURA
+
MÃO DIREITA
+
CANECA
+
ESPELHO
+
REFLEXO
+
LUZ
+
SOMBRA
+
TV
+
CÂMERA
+
OCLUSÃO

Se sair tudo correto...

dê um café para o modelo.

Dificuldade: 10/10


📊 COMO TRANSFORMAR ISSO NUM BENCHMARK DE VERDADE

Aqui está a parte divertida.

Não compare uma única geração.

Isso seria estatisticamente fraco.

Para cada modelo, use exatamente o mesmo prompt e produza várias amostras, mantendo parâmetros comparáveis quando possível.

Por exemplo:

MODELO A
TESTE 01
10 gerações

MODELO B
TESTE 01
10 gerações

MODELO C
TESTE 01
10 gerações

Depois marque cada imagem.

Uma classificação simples:

PASS
PARTIAL
FAIL

PASS

Todas as relações principais estão corretas.

PARTIAL

A ideia geral funciona, mas existe uma inconsistência secundária.

FAIL

A relação principal solicitada foi violada.


🦖 O PROGRAMADOR COBOL CRIA O COPYBOOK DA REALIDADE

Naturalmente, precisamos de COBOL.

       01  TEST-RESULT.
           05 MODEL-NAME          PIC X(30).
           05 TEST-ID             PIC 9(02).
           05 SAMPLE-ID           PIC 9(02).
           05 OBJECTS-CORRECT     PIC X.
           05 ORIENTATION-CORRECT PIC X.
           05 SPATIAL-CORRECT     PIC X.
           05 REFLECTION-CORRECT  PIC X.
           05 SHADOW-CORRECT      PIC X.
           05 CAUSALITY-CORRECT   PIC X.
           05 FINAL-RESULT        PIC X(07).

E finalmente:

       IF OBJECTS-CORRECT     = 'Y'
          AND ORIENTATION-CORRECT = 'Y'
          AND SPATIAL-CORRECT     = 'Y'
              MOVE 'PASS' TO FINAL-RESULT
       ELSE
              MOVE 'FAIL' TO FINAL-RESULT
       END-IF.

Chii observa.

— Chii?

Sim.

Acabamos de colocar o mundo físico dentro de um copybook.


📈 NÃO USE APENAS UMA NOTA FINAL

Existe uma coisa importante aqui.

Um modelo pode ser excelente em uma categoria e ruim em outra.

Por isso podemos criar dimensões separadas:

CategoriaO que observamos
Objetoscriou corretamente os elementos solicitados?
Contagemrespeitou quantidades?
Orientaçãofrente, verso, esquerda e direita estão corretos?
Gazepersonagens olham para o lugar solicitado?
Oclusãoobjetos escondem corretamente outros objetos?
Reflexoespelhos representam a cena coerentemente?
Iluminaçãosombras correspondem às fontes?
Funçãoobjetos estão sendo utilizados corretamente?
Temporalidadea cena sugere passado/futuro plausível?
Causalidadeefeitos correspondem às causas?

Isso produz algo muito mais interessante que:

"Modelo X faz imagens mais bonitas."

Podemos descobrir:

modelo apresenta alta fidelidade visual, mas frequentemente perde relações entre três ou mais objetos.

Ou:

modelo mantém esquerda/direita, mas apresenta inconsistências em reflexos.

Isso é informação útil.


⚠️ O DETALHE CIENTÍFICO MAIS IMPORTANTE

Existe uma armadilha gigantesca.

Se o modelo passar no teste, não podemos automaticamente concluir que ele compreende o mundo como um ser humano.

Ele pode ter aprendido regularidades extremamente sofisticadas.

Pode possuir representações internas suficientes para resolver aquela tarefa.

Pode ter encontrado padrões semelhantes no treinamento.

Pode estar utilizando capacidades espaciais emergentes.

Tudo isso é fascinante.

Mas a imagem final, sozinha, não permite determinar exatamente qual mecanismo interno produziu o acerto.

Portanto:

PASSOU NO TESTE
      ≠
PROVOU CONSCIÊNCIA

Também:

FALHOU NO TESTE
      ≠
NÃO SABE NADA

O benchmark mede comportamento observável numa tarefa específica.

Esse cuidado separa experimento de espetáculo.


🧪 COMO EU FARIA O EXPERIMENTO BELLACOSA

Escolheria vários geradores contemporâneos.

Usaria os mesmos 20 prompts.

Para cada combinação:

20 testes
×
10 imagens
=
200 imagens por modelo

Com cinco modelos:

200 × 5 = 1.000 imagens

Agora temos alguma coisa divertida para analisar.

Cada imagem receberia um ID:

BSCST-01-M01-001
BSCST-01-M01-002
BSCST-01-M01-003
...

E manteríamos:

PROMPT
MODELO
VERSÃO
DATA
CONFIGURAÇÃO
RESULTADO
OBSERVAÇÕES

A versão e a data são fundamentais.

Modelos mudam.

Um teste realizado hoje pode produzir resultado diferente meses depois.


🔥 E AQUI SURGE UM EXPERIMENTO AINDA MELHOR

Depois da primeira rodada, podemos modificar os prompts.

Por exemplo:

Prompt simples

Chii lendo um jornal.

Prompt espacial

Chii lendo um jornal com a superfície impressa voltada para seus olhos.

Prompt explícito

Chii lendo um jornal. A superfície impressa está voltada exclusivamente para Chii. A câmera vê somente o verso.

Prompt redundante

A câmera NÃO consegue ver a manchete. O texto NÃO está voltado para o observador. Somente Chii consegue ler o conteúdo.

Agora podemos medir outra coisa:

Quanto precisamos explicar a realidade para a IA?

Isso é fascinante.

Talvez um modelo precise de:

1 restrição

Outro:

4 restrições

Outro simplesmente ignore todas.

Isso nos fornece uma espécie de custo de especificação espacial.


☕ CURIOSIDADE — ISSO LEMBRA PROGRAMAÇÃO

Programadores conhecem muito bem esse fenômeno.

Você escreve:

PROCESSAR CLIENTE

O computador responde metaforicamente:

Defina "processar".

Então especificamos:

VALIDAR
LOCALIZAR
CALCULAR
ATUALIZAR
COMMIT

Com sistemas generativos acontece algo curioso.

Queremos escrever:

"Pessoa lendo jornal."

Porque um humano automaticamente acrescenta centenas de regras implícitas.

olhos funcionam
papel tem dois lados
texto está numa superfície
leitura exige visibilidade
mãos seguram o objeto
gravidade existe
perspectiva existe

Nós nunca colocamos isso no prompt.

Por quê?

Porque consideramos óbvio.

Mas talvez o grande desafio de modelos de mundo seja justamente dominar aquilo que os seres humanos nem percebem que sabem.


🥚 EASTER EGG — CHII EXECUTA O TESTE

Às 03:17 apareceu um job misterioso no JES2.

JOBNAME  CHIITEST
OWNER    FREYA
STATUS   EXECUTING

O operador abriu o SDSF.

TEST 01 NEWSPAPER ........ PASS
TEST 02 BOOK ............. PASS
TEST 03 PHONE ............ PASS
TEST 04 TELEVISION ....... PASS
TEST 05 3270 ............. PASS
TEST 06 CAMERA ........... PASS
TEST 07 BINOCULARS ....... PASS
TEST 08 MIRROR ........... PASS
TEST 09 REFLECTION ....... PASS
TEST 10 REARVIEW ......... PASS
TEST 11 SHADOW ........... PASS
TEST 12 LIGHTS ........... PASS
TEST 13 WINDOW ........... PASS
TEST 14 OCCLUSION ........ PASS
TEST 15 LEFT-RIGHT ....... PASS
TEST 16 GAZE ............. PASS
TEST 17 POINTING ......... PASS
TEST 18 CAUSALITY ........ PASS
TEST 19 MOTION ........... PASS
TEST 20 WORLD-MODEL ...... PASS

No final:

20 TESTS EXECUTED
20 PASSED
00 FAILED

MAXCC=0000

O programador ficou impressionado.

— Chii, você passou em tudo!

Chii virou lentamente para ele.

— Chii?

Então ele percebeu.

Ela não havia usado nenhum gerador de imagens.

Chii simplesmente havia tirado fotografias do mundo real.

No spool apareceu:

CHEATER.

Usuário responsável:

FREYA

Novamente.


🎓 CONCLUSÃO — O MUNDO É O TESTE

Começamos com uma bobagem.

Um jornal virado para o lado errado.

Mas ao investigar aquela pequena inconsistência encontramos:

OBJETOS
   ↓
RELAÇÕES
   ↓
ORIENTAÇÃO
   ↓
PERSPECTIVA
   ↓
OCLUSÃO
   ↓
REFLEXOS
   ↓
ILUMINAÇÃO
   ↓
TEMPO
   ↓
CAUSALIDADE
   ↓
MODELOS DE MUNDO

E percebemos algo maravilhoso.

Gerar uma imagem bonita é uma tarefa.

Gerar uma imagem internamente coerente é outra.

Quanto mais objetos colocamos na cena, mais relações aparecem.

Quanto mais relações aparecem, mais restrições precisam ser satisfeitas simultaneamente.

É quase como um sistema corporativo.

Um programa COBOL de vinte linhas pode parecer simples.

Depois descobrimos:

CICS
Db2
MQ
VSAM
RACF
JES2
WLM
SMF
APIs
27 sistemas consumidores

Bem-vindo à realidade.

O mesmo acontece numa fotografia.

Uma mulher lê um jornal.

Simples.

Até perguntarmos:

qual lado do jornal ela está vendo?

Depois:

onde está a câmera?

Depois:

de onde vem a luz?

Depois:

onde deveria estar a sombra?

Depois:

o que aparece no espelho?

Depois:

para onde ela está olhando?

Depois:

o que aconteceu um segundo antes?

Nesse momento já não estamos perguntando se a inteligência artificial sabe desenhar.

Estamos fazendo uma pergunta muito mais interessante:

QUANTO DO MUNDO ELA PRECISA REPRESENTAR PARA DESENHÁ-LO CORRETAMENTE?

Chii fechou a prancheta.

O programador terminou o café.

No terminal apareceu:

READY

Ele digitou:

RUN BSCST

Chii olhou para ele.

— Chii?

Sim.

Dessa vez seriam mil imagens.

E o jornal seria apenas o começo.

MAXCC=0000.

☕

Para ir mais longe

https://eljefemidnightlunch.blogspot.com/2023/12/chii-e-o-jornal-que-ninguem-conseguia.html

sábado, 27 de janeiro de 2024

Isekai Onsen Paradise : Quando um Programador COBOL Descobre que um Banho Quente Pode Ser Mais Poderoso que uma Espada Lendária

Bellacosa Mainframe apresenta o isekai onsen paradise

☕ Um Café no Bellacosa Mainframe

Isekai Onsen Paradise sem Mistérios

Quando um Programador COBOL Descobre que um Banho Quente Pode Ser Mais Poderoso que uma Espada Lendária

"Nem todo herói precisa derrotar o Rei Demônio. Alguns apenas desejam restaurar o sistema... uma fonte termal por vez."


Introdução

O gênero isekai tornou-se famoso por repetir uma fórmula quase infalível: um protagonista morre, reencarna em outro mundo, recebe poderes absurdos, forma um harém e parte para derrotar um Rei Demônio. Em Isekai Onsen Paradise, porém, essa receita é completamente subvertida.

Aqui, o protagonista não busca espadas sagradas, habilidades divinas ou fama. Seu maior sonho é encontrar a fonte termal perfeita.

À primeira vista parece apenas uma comédia ecchi, mas, observando com atenção, percebe-se uma homenagem à cultura japonesa dos onsen, à valorização do conhecimento especializado e ao prazer das pequenas coisas da vida. A série adapta a light novel de Konao Menrui, ilustrada por Yoshitake, publicada inicialmente em 2019. O anime estreou em 12 de janeiro de 2024, com direção de Tomonori Mine, roteiro de Yōhei Kashii e produção dos estúdios BloomZ e Wolfsbane, contando com 12 episódios curtos de aproximadamente quatro minutos cada. 


Ficha Técnica

Título original

名湯『異世界の湯』開拓記 ~アラフォー温泉マニアの転生先は、のんびり温泉天国でした~

Romanização

Meitō "Isekai no Yu" Kaitaku-ki: AraFō Onsen Mania Tensei-saki wa, Nonbiri Onsen Tengoku Deshita

Título internacional

Isekai Onsen Paradise

Autor: Konao Menrui

Ilustrações: Yoshitake

Diretor: Tomonori Mine

Roteiro: Yōhei Kashii

Estúdios

  • BloomZ

  • Wolfsbane

  • apoio de produção: Gekkou

Exibição

  • Janeiro a março de 2024

Quantidade de episódios

  • 12

Duração

  • cerca de 4 minutos por episódio. (Wikipedia)


Sinopse

Yoshizo (ou Kozo, conforme algumas traduções) Yukawa é um apaixonado por fontes termais naturais. Durante uma expedição em busca de um novo onsen, sofre um acidente fatal.

Em vez de encontrar o fim da vida, desperta em um mundo fantástico graças à deusa Inari.

Sua missão?

Encontrar as melhores águas termais daquele universo.

Nada de salvar reinos.

Nada de batalhas épicas.

Nada de derrotar o Lorde das Trevas.

Seu objetivo é proporcionar relaxamento e bem-estar.


Resumo da história

Logo nos primeiros episódios, Yoshizo percebe que os habitantes daquele mundo têm medo das fontes termais.

Algumas raças acreditam que elas são amaldiçoadas.

Outras jamais haviam experimentado um banho quente.

Usando seu conhecimento acumulado durante décadas, ele começa a localizar nascentes, estudar minerais, convencer diferentes povos a experimentar os banhos e transformar a cultura local.

É praticamente um evangelizador dos onsen.


Os personagens principais

Yoshizo Yukawa

O protagonista.

Tem cerca de quarenta anos.

Não é guerreiro.

Não é mago.

Seu maior talento é reconhecer uma boa fonte termal apenas pelo cheiro do enxofre.

No universo Bellacosa Mainframe, ele lembra aquele analista veterano de COBOL que resolve um problema crítico apenas ouvindo o barulho do disco ou lendo um dump de ABEND.


Mayudama

Mensageira da deusa Inari.

Companheira inseparável de Yoshizo.

Curiosa, divertida e responsável por boa parte do humor da série.

Também serve como "ponte" entre o protagonista e os habitantes do novo mundo.


Lilium

Uma elfa que acredita que águas termais são perigosas.

Sua mudança de opinião representa o choque entre preconceito e experiência prática.

É um dos exemplos de como o anime usa humor para mostrar a quebra de paradigmas.


O diferencial do anime

Quase todos os isekai seguem uma estrutura semelhante:

  • protagonista overpower

  • evolução de níveis

  • guildas

  • demônios

  • guerras

Aqui tudo gira em torno de algo extremamente cotidiano:

tomar banho.

Parece simples.

Mas justamente essa simplicidade torna a obra única.

O anime transforma um costume tradicional japonês em elemento central da narrativa.


Os estúdios

BloomZ

Especializado em produções menores e projetos multimídia, o estúdio ficou responsável pela maior parte da animação da série.

Wolfsbane

Conhecido por colaborar em adaptações de fantasia e ação, ajudou a dar vida aos cenários e personagens.

Como se trata de um anime de episódios muito curtos, a proposta nunca foi competir visualmente com grandes produções, mas entregar uma adaptação leve e funcional. (Wikipedia)


Temática

Apesar do fanservice evidente, a obra trabalha diversos temas:

  • cultura japonesa

  • hospitalidade

  • saúde

  • relaxamento

  • convivência

  • respeito à natureza

  • descoberta cultural

  • quebra de preconceitos

  • tradição

O verdadeiro "poder" do protagonista é compartilhar conhecimento.


As aventuras

Cada episódio apresenta uma nova descoberta:

  • uma nascente escondida;

  • uma floresta misteriosa;

  • um povo diferente;

  • um banho termal com propriedades específicas;

  • encontros com elfos, raposas e outras criaturas fantásticas.

Em vez de explorar masmorras, Yoshizo explora geologia, minerais e águas quentes.


As mensagens ocultas

Aqui está a parte que mais combina com o espírito do Bellacosa Mainframe.

Imagine dois profissionais.

O primeiro:

  • conhece apenas tecnologias modernas.

O segundo:

  • conhece tecnologias modernas;

  • entende sistemas legados;

  • sabe resolver problemas antigos.

Quem costuma ser chamado quando tudo para?

O segundo.

Yoshizo representa exatamente isso.

Seu conhecimento aparentemente "ultrapassado" transforma um mundo inteiro.

Isso lembra muito o universo IBM Z.

Muitos pensam que um programador COBOL trabalha apenas com sistemas antigos.

Na prática, ele domina décadas de experiência acumulada.

O anime mostra que conhecimento especializado nunca perde valor.


Uma analogia para o Programador COBOL Padawan

Imagine que o Reino Fantástico seja um enorme ambiente z/OS.

Cada fonte termal é um subsystem.

Cada povo representa uma aplicação.

Yoshizo é o sysprog.

Ele não cria a água.

Ele apenas sabe configurá-la corretamente.

É exatamente o que faz um bom especialista em infraestrutura.


Humor

Grande parte da comédia nasce do contraste entre:

  • seriedade do protagonista;

  • absurdos do mundo fantástico;

  • personagens assustados com águas quentes;

  • situações de banho coletivo;

  • fanservice constante.

Os episódios curtos mantêm um ritmo bastante acelerado.


Qualidade da animação

Visualmente, trata-se de uma produção modesta.

Os cenários dos onsen recebem mais atenção do que as cenas de ação, o que faz sentido para a proposta da obra. Os episódios foram concebidos como curtas, priorizando humor e ambientação em vez de grandes sequências de combate. (Wikipedia)


Impacto cultural

"Isekai Onsen Paradise" não alcançou a popularidade de gigantes do gênero como Mushoku Tensei ou Re:Zero, mas conquistou um nicho de fãs por sua proposta incomum. Também despertou curiosidade sobre a cultura japonesa dos onsen, mostrando aspectos como etiqueta, convivência e o valor histórico das fontes termais. (Crunchyroll)


O que há de diferente?

✔ protagonista adulto

✔ conhecimento técnico como superpoder

✔ foco em cultura japonesa

✔ sem batalhas épicas como eixo principal

✔ atmosfera relaxante

✔ episódios rápidos

✔ mistura de comédia, fantasia e ecchi

✔ conceito bastante original dentro do gênero isekai


Curiosidades

  • A obra nasceu como uma novel publicada na plataforma Novel Up Plus em 2019 antes de ganhar light novel, mangá e anime. (Wikipedia)

  • O anime possui episódios de aproximadamente quatro minutos, formato incomum para adaptações de isekai. (IMDb)

  • O protagonista é um entusiasta de onsen de meia-idade, fugindo do arquétipo do adolescente escolhido por um destino grandioso. (Wikipedia)


Avaliação Bellacosa Mainframe ☕

Na Enterprise, o Capitão Kirk poderia atravessar galáxias enfrentando klingons, enquanto Spock analisaria anomalias espaciais com lógica impecável. Yoshizo Yukawa faria algo diferente: detectaria uma nascente de água vulcânica em um planeta recém-descoberto e convenceria toda a tripulação de que algumas horas em um bom onsen restaurariam a moral da missão.

Da mesma forma, no universo IBM Z, nem sempre o profissional mais valioso é quem escreve o código mais complexo. Muitas vezes é aquele que conhece profundamente o ambiente, entende décadas de experiência acumulada e sabe transformar conhecimento em qualidade de vida para sistemas e pessoas.

Isekai Onsen Paradise mostra que um especialista pode mudar um mundo sem empunhar uma espada. Basta dominar seu ofício e compartilhá-lo com generosidade.

Classificação Bellacosa Mainframe: ★★★★☆ (4/5 xícaras de café)

Não é uma obra feita para quem procura grandes batalhas ou uma trama épica. É recomendada para quem aprecia um isekai descontraído, humor leve, referências à cultura japonesa e uma perspectiva diferente sobre o verdadeiro significado de ser um herói. (Wikipedia)

sexta-feira, 26 de janeiro de 2024

SQL sem Mistérios : O Guia Definitivo para um Programador COBOL Padawan Entender por que Performance Não Está no SQL — Está na Forma Como o Banco de Dados Pensa

 

Bellacosa Mainframe e o sql sem misterios

☕ Um Café no Bellacosa Mainframe

SQL sem Mistérios

O Guia Definitivo para um Programador COBOL Padawan Entender por que Performance Não Está no SQL — Está na Forma Como o Banco de Dados Pensa

"No IBM Z aprendemos uma lição muito cedo: escrever um programa COBOL correto é apenas metade do trabalho. A outra metade é fazer com que ele execute milhões de vezes por dia consumindo o mínimo possível de CPU, memória, I/O e tempo de resposta. O mesmo vale para SQL. O segredo nunca esteve apenas na consulta. O segredo sempre esteve no plano de execução."


Introdução

Existe uma ideia que acompanha praticamente todo programador iniciante.

"Se meu SQL está correto, ele será rápido."

Infelizmente isso quase nunca é verdade.

Na realidade, dois comandos SQL visualmente parecidos podem apresentar diferenças de desempenho de centenas ou até milhares de vezes.

O curioso é que ambos retornam exatamente o mesmo resultado.

Como isso é possível?

Porque SQL é uma linguagem declarativa.

Você não diz como o banco deve executar.

Você apenas informa o que deseja obter.

Quem decide como chegar ao resultado é o Query Optimizer, talvez um dos componentes mais sofisticados já criados na Engenharia de Software.

É exatamente nesse ponto que muitos desenvolvedores COBOL descobrem uma das maiores diferenças entre programar aplicações e construir sistemas corporativos de missão crítica.

No Mainframe, especialmente no Db2 for z/OS, performance nunca foi um detalhe.

Ela sempre foi parte da regra de negócio.

Um banco que processa milhões de transações por hora não pode desperdiçar CPU apenas porque alguém escreveu um SQL aparentemente "bonito".


A maior mentira sobre SQL

Quando alguém pergunta:

"Como faço um SQL mais rápido?"

A pergunta correta deveria ser:

"Como faço o otimizador escolher um plano de execução melhor?"

Essa pequena mudança muda completamente a forma de pensar.

O SQL é apenas uma descrição lógica.

Quem faz o trabalho pesado é o banco.

Imagine pedir um táxi.

Você informa:

"Quero ir do aeroporto até o hotel."

Você não diz:

  • qual avenida utilizar;

  • qual velocidade manter;

  • qual ponte atravessar;

  • onde abastecer.

Quem decide isso é o motorista.

Com SQL acontece exatamente a mesma coisa.

Você informa o destino.

O banco decide o caminho.

E esse caminho chama-se:

Execution Plan


O verdadeiro inimigo chama-se I/O

Quando começamos em COBOL normalmente pensamos que CPU é o maior problema.

Depois de alguns anos trabalhando em bancos descobrimos outra realidade.

O maior inimigo geralmente é:

DISCO

Mais precisamente:

I/O

Toda vez que o Db2 precisa buscar páginas em disco, existe um custo.

Imagine uma tabela.

CLIENTES

500 milhões de registros

Você deseja apenas:

CPF = 123456789

Existem dois caminhos.

Primeiro.

Ler

500 milhões

↓

encontrar registro

Segundo.

ÍNDICE

↓

posição

↓

registro

A diferença entre essas duas estratégias pode representar minutos versus milissegundos.

É exatamente isso que o otimizador tenta resolver.


O cérebro invisível do banco de dados

Muita gente acredita que o SQL é executado exatamente como foi escrito.

Na realidade acontece algo muito mais interessante.

Primeiro o banco interpreta.

Depois calcula estatísticas.

Depois verifica índices.

Depois estima custos.

Depois compara algoritmos.

Depois escolhe um plano.

Só então executa.

Na prática ele faz algo semelhante a isto:

SQL

↓

Parser

↓

Optimizer

↓

Statistics

↓

Execution Plan

↓

Runtime

Ou seja...

Antes de executar uma única linha, o banco já simulou diversos cenários.

Esse processo acontece milhares de vezes por segundo.


O pensamento de um especialista IBM Z

Existe uma diferença enorme entre um programador iniciante e um especialista.

O iniciante pergunta:

Meu SQL funciona?

O especialista pergunta:

  • Quantos GETPAGEs ele gera?

  • Quantas páginas serão lidas?

  • Qual Buffer Pool será utilizada?

  • Existe Table Scan?

  • O índice é Matching?

  • Existe Sort?

  • O Join utilizará Hash?

  • Há paralelismo?

  • O RUNSTATS está atualizado?

  • Qual é o custo estimado?

Perceba.

A preocupação deixa de ser o SQL.

Ela passa a ser o comportamento interno do banco.


Primeira regra: reduza trabalho

Uma consulta lenta quase sempre faz trabalho demais.

Veja um erro extremamente comum.

SELECT *
FROM CLIENTES;

Parece inofensivo.

Mas imagine a tabela:

CPF

NOME

EMAIL

ENDEREÇO

TELEFONE

FOTO

OBSERVAÇÃO

SCORE

RENDA

LIMITE

NASCIMENTO

Seu programa COBOL utiliza apenas:

CPF

NOME

Então por que pedir todo o restante?

Cada coluna representa:

  • mais páginas;

  • mais memória;

  • mais tráfego;

  • mais CPU.

O primeiro princípio da engenharia de performance é extremamente simples.

Nunca leia aquilo que você não utilizará.


O índice não é mágica

Outro grande mito.

Muitos acreditam que basta criar índices.

Na prática isso pode piorar tudo.

Cada índice precisa ser atualizado em:

INSERT

UPDATE

DELETE

Quanto mais índices,

mais escrita,

mais manutenção,

mais espaço,

mais CPU.

Por isso especialistas projetam índices observando o comportamento das consultas.

Não existe índice perfeito.

Existe índice adequado para determinada carga de trabalho.


O poder dos índices compostos

Imagine este SQL.

WHERE CPF=?

AND STATUS='A'

Qual índice é melhor?

CPF

ou

CPF

STATUS

O segundo.

Porque acompanha exatamente o padrão utilizado pela consulta.

Esse conceito chama-se:

Composite Index.

No Db2 isso pode eliminar milhares de leituras desnecessárias.


Covering Index: quando a tabela deixa de ser necessária

Poucos conceitos impressionam tanto um programador COBOL quanto este.

Imagine:

SELECT NOME
FROM CLIENTES
WHERE CPF=?

Se existir um índice contendo:

CPF

NOME

o Db2 pode responder utilizando apenas o índice.

A tabela sequer será acessada.

Isso reduz:

  • I/O;

  • CPU;

  • tempo de resposta.

É uma das maiores vitórias do otimizador.


SARGable: a palavra que todo Padawan deveria decorar

Ela parece complicada.

Mas a ideia é simples.

Observe.

Errado.

WHERE YEAR(DATA)=2025

Agora o banco precisa calcular YEAR para milhões de linhas.

O índice praticamente perde sua utilidade.

Agora veja.

WHERE DATA
BETWEEN
'2025-01-01'
AND
'2025-12-31'

Aqui o índice pode ser percorrido diretamente.

Esse conceito chama-se:

Search Argument Able

ou simplesmente

SARGable.

Sempre que possível, permita que o banco utilize diretamente seus índices.


EXISTS x IN

Outro assunto clássico.

Muitos iniciantes perguntam:

"Qual é mais rápido?"

A resposta correta é:

"Depende."

Mas existe uma tendência.

Em conjuntos muito grandes,

EXISTS costuma interromper a busca assim que encontra a primeira ocorrência.

Já IN pode exigir estratégias diferentes dependendo do plano escolhido.

O importante não é decorar regras.

É analisar o plano.


Filtrar antes de juntar

Imagine duas tabelas.

CLIENTES

120 milhões
PEDIDOS

800 milhões

Sem filtro:

120 milhões

×

800 milhões

Agora imagine aplicar:

STATUS='ATIVO'

antes do JOIN.

Talvez restem apenas:

2 milhões

×

8 milhões

O banco trabalhará muito menos.

Essa simples mudança pode reduzir drasticamente o custo de execução.


DISTINCT é caro

DISTINCT parece elegante.

Mas por trás dele normalmente existe:

SORT

COMPARAÇÃO

ELIMINAÇÃO

MEMÓRIA

CPU

Em muitos projetos ele aparece apenas para esconder um JOIN incorreto.

O especialista não remove duplicidade.

Ele evita produzi-la.


UNION ou UNION ALL?

Outro clássico.

UNION precisa descobrir registros repetidos.

Para isso geralmente ocorre:

SORT

COMPARE

REMOVE

UNION ALL simplesmente concatena.

Tabela A

+

Tabela B

Sem ordenar.

Sem comparar.

Sem remover.

Em processos ETL isso faz enorme diferença.


O plano de execução é o mapa do tesouro

Imagine um médico sem raio-X.

É exatamente isso que faz quem tenta otimizar SQL sem olhar o plano.

No Db2 utilizamos:

  • EXPLAIN

  • PLAN_TABLE

  • Visual Explain

No PostgreSQL:

EXPLAIN ANALYZE

No SQL Server:

Actual Execution Plan

No Oracle:

EXPLAIN PLAN

O plano revela tudo.

Table Scan

Index Scan

Nested Loop

Merge Join

Hash Join

Sort

Temporary

Parallel

Sem ele praticamente toda otimização é tentativa e erro.


O verdadeiro papel do RUNSTATS

Existe uma armadilha muito comum.

O SQL está perfeito.

Os índices existem.

Mesmo assim o desempenho é ruim.

O problema pode estar nas estatísticas.

No Db2, o utilitário RUNSTATS informa ao otimizador:

  • quantidade de linhas;

  • cardinalidade;

  • distribuição dos valores;

  • quantidade de páginas;

  • fator de clusterização;

  • informações sobre índices.

Sem essas estatísticas, o otimizador toma decisões com base em estimativas imprecisas, aumentando a chance de escolher um plano inadequado.


Partition Pruning: lendo apenas o necessário

Imagine uma tabela dividida por ano.

2021

2022

2023

2024

2025

2026

Sua consulta busca apenas 2026.

Se o particionamento for bem utilizado, o banco ignora todas as demais partições.

Em vez de ler bilhões de linhas, lê apenas a fração necessária.

É uma das técnicas mais importantes para bases corporativas de grande porte.


Os algoritmos invisíveis dos JOINs

Quando você escreve:

JOIN

o Db2 ainda precisa decidir como unir as tabelas.

As principais estratégias são:

Nested Loop Join, ideal para poucos registros e bons índices.

Merge Join, eficiente quando os dados já estão ordenados.

Hash Join, excelente para grandes volumes e junções sem índices seletivos.

A escolha depende de estatísticas, cardinalidade e custo estimado. O mesmo SQL pode gerar algoritmos diferentes conforme os dados evoluem.


O que um Padawan COBOL pode aprender com tudo isso?

Existe um paralelo interessante entre COBOL e SQL.

Quando escrevemos um programa COBOL, evitamos ler um arquivo inteiro se conhecemos a chave do registro.

Não percorremos um VSAM KSDS sequencialmente para localizar uma única conta quando podemos usar a chave primária.

Da mesma forma, no Db2 não devemos obrigar o banco a fazer um table scan quando um índice seletivo resolveria o problema com muito menos trabalho.

A lógica é a mesma: reduzir operações desnecessárias e aproveitar as estruturas de acesso disponíveis.


A Filosofia Bellacosa Mainframe

Ao longo de décadas trabalhando com IBM Z, uma lição se repetiu inúmeras vezes.

Os sistemas mais rápidos raramente eram aqueles escritos pelos programadores mais "geniais".

Eram aqueles escritos por profissionais que entendiam como a infraestrutura pensava.

Eles compreendiam que:

  • CPU custa dinheiro.

  • I/O custa tempo.

  • Memória é finita.

  • Locks geram contenção.

  • Sorts desperdiçam recursos.

  • Estatísticas influenciam decisões.

  • Índices precisam de estratégia.

  • Cada GETPAGE representa trabalho.

  • Cada plano de execução conta uma história.

No universo Mainframe, performance nunca foi um luxo. Sempre foi um requisito funcional.


Palavra Final

Se existe uma única mensagem que este artigo pretende deixar para todo Programador COBOL Padawan, é esta:

Você não otimiza apenas uma instrução SQL. Você otimiza a forma como o banco de dados raciocina sobre ela.

Quando você escreve uma consulta, está apenas descrevendo um objetivo. Quem realmente faz o trabalho é o otimizador, escolhendo índices, algoritmos de JOIN, estratégias de acesso, ordenações e caminhos de execução.

Os grandes especialistas em Db2 para IBM Z não decoram truques. Eles estudam estatísticas, analisam planos de execução, compreendem o comportamento do otimizador e medem continuamente CPU, I/O, GETPAGEs, uso de Buffer Pools e contenção. Eles sabem que um ganho de poucos milissegundos por transação pode representar milhões de operações economizadas ao longo de um ano.

Como ensinamos no Bellacosa Mainframe: o SQL é apenas a pergunta; o plano de execução é a resposta do banco. Quando você aprende a ler essa resposta, deixa de ser apenas um programador que escreve consultas e passa a pensar como um verdadeiro engenheiro de software para sistemas de missão crítica.

No fim das contas, o objetivo não é criar um SQL elegante. É construir aplicações capazes de processar milhões de transações com eficiência, previsibilidade e confiabilidade — exatamente como os grandes ambientes IBM Z fazem há décadas. Esse é o verdadeiro caminho para evoluir de Padawan a Mestre na arte da performance em bancos de dados.


quinta-feira, 25 de janeiro de 2024

Classic RAG, Graph RAG e Agentic RAG: A Evolução da Inteligência Artificial Explicada para Quem Já Entendeu um JCL

 

Bellacosa Mainframe apresenta RAG e a evolução da IA

☕ Um Café no Bellacosa Mainframe

Classic RAG, Graph RAG e Agentic RAG: A Evolução da Inteligência Artificial Explicada para Quem Já Entendeu um JCL

"Nem toda aplicação precisa de um Parallel Sysplex. Nem toda IA precisa de um Agentic RAG."

Existe um fenômeno curioso acontecendo no mercado de Inteligência Artificial.

Basta uma empresa anunciar que utiliza IA para imediatamente aparecerem palavras como Agentic AI, Graph RAG, Knowledge Graph, MCP, AI Agents, Multi-Agent Systems, Planning, Reasoning, Memory, Tool Calling...

Tudo parece extremamente sofisticado.

Mas existe um problema.

Na maioria das vezes, a empresa precisava apenas de um bom mecanismo para responder perguntas sobre documentos.

Nada mais.

Como dizia um velho arquiteto de sistemas que conheci:

"Nunca compre um caminhão para buscar pão na esquina."

Essa frase resume perfeitamente o assunto de hoje.

Vamos entender por que existem diferentes arquiteturas RAG e, principalmente, quando utilizar cada uma delas.

Pegue seu café.

Hoje a conversa vai longe.


O nascimento do problema

Imagine um chatbot tradicional.

Você pergunta:

Como faço um BIND PACKAGE no Db2?

O modelo responde.

Mas... de onde veio essa resposta?

Do treinamento.

Se o treinamento terminou há dois anos...

Ele nunca viu a documentação mais recente.

Muito menos os procedimentos internos da empresa.

Resultado?

Ele começa a...

"...achar..."

"...supor..."

"...inventar..."

É o famoso:

Hallucination

No mundo Mainframe isso seria equivalente ao operador responder:

"Acho que esse JCL funciona..."

Ninguém faz isso em produção.


Surge o RAG

Retrieval-Augmented Generation.

Traduzindo:

Geração aumentada através da recuperação de conhecimento.

A ideia é brilhante.

Em vez do modelo responder sozinho...

Primeiro buscamos informação.

Depois perguntamos ao modelo.

Ou seja:

Usuário

↓

Pergunta

↓

Busca documentos

↓

Seleciona informações

↓

Entrega ao LLM

↓

Resposta

Agora o modelo responde baseado em fatos.

Não em memória.


A biblioteca do Reino IBM Z

Imagine um enorme castelo.

Dentro existe uma biblioteca infinita.

Livros IBM.

Redbooks.

Runbooks.

Documentação interna.

Procedimentos.

APARs.

Manuais RACF.

Guias CICS.

JCL Standards.

DB2 Utilities.

Agora imagine um bibliotecário.

Você pergunta:

Como criar um Dataset VSAM?

Ele corre até a estante.

Encontra o livro.

Marca a página.

Entrega para você.

Esse bibliotecário é o Classic RAG.


Classic RAG

É disparado o mais utilizado atualmente.

E existe um motivo.

Ele resolve aproximadamente 70% dos problemas corporativos.

Por quê?

Porque empresas possuem milhares de documentos.

E funcionários vivem procurando informações.

O fluxo é simples.

Pergunta

↓

Embedding

↓

Banco Vetorial

↓

Top-K documentos

↓

LLM

↓

Resposta

Parece simples.

Mas há muita tecnologia escondida aqui.


O que é Embedding?

Essa palavra assusta muitos iniciantes.

Mas a ideia é incrivelmente simples.

Imagine duas frases.

Como criar um usuário RACF?

e

Como cadastrar um novo usuário no RACF?

As palavras são diferentes.

O significado é praticamente igual.

O embedding transforma frases em coordenadas matemáticas.

Algo como:

[0.18,0.42,0.81...]

Esses números representam significado.

Não palavras.

É como colocar cada documento em um enorme mapa tridimensional.

Documentos parecidos ficam próximos.

Documentos diferentes ficam distantes.


Banco Vetorial

Aqui mora a mágica.

Diferente de um banco SQL...

Ele não procura igualdade.

Procura proximidade.

Imagine perguntar:

Como executar REORG?

Mesmo que nenhum documento possua exatamente essa frase...

Ele encontra documentos sobre:

  • RUNSTATS

  • REORG TABLESPACE

  • Utilities Db2

  • REORG INDEX

Porque entende contexto.

Não texto.


Por que ele é tão rápido?

Porque ele utiliza índices vetoriais.

Algoritmos como:

  • HNSW

  • IVF

  • PQ

  • Annoy

  • FAISS

Eles permitem pesquisar milhões de documentos em poucos milissegundos.


Onde o Classic RAG brilha?

Praticamente qualquer base documental.

Exemplos:

  • FAQ

  • Help Desk

  • RH

  • Jurídico

  • Normas ISO

  • IBM Docs

  • Redbooks

  • COBOL Standards

  • CICS Manuals

  • RACF Procedures

  • Catálogo interno


Mas existe um limite...

Imagine perguntar:

Quais programas COBOL utilizam a tabela CLIENTE, que é acessada pelo Job FIN001, que chama uma transação CICS ligada ao MQ?

Agora não basta procurar documentos.

Precisamos entender relações.

É aqui que nasce o Graph RAG.


Graph RAG

Se o Classic RAG é um bibliotecário...

O Graph RAG é um detetive.

Ele liga pistas.

Relaciona pessoas.

Descobre conexões.

Seu coração é um:

Knowledge Graph


Imagine um mapa

Cliente

↓

Conta

↓

Cartão

↓

Compra

↓

Loja

↓

Cidade

↓

Fornecedor

Tudo conectado.

Agora pergunte:

Quais clientes compraram em empresas ligadas ao mesmo fornecedor investigado?

Isso seria extremamente difícil para um banco vetorial.

Mas extremamente simples para um grafo.


O mundo é um grafo

Curiosidade.

Grande parte da natureza pode ser representada como grafos.

Redes sociais.

Internet.

GPS.

Proteínas.

Neurônios.

Árvores genealógicas.

Dependências de software.

E...

Mainframe.


Sim...

O IBM Z também é um enorme grafo.

Veja só.

Programa COBOL

↓

COPYBOOK

↓

DB2

↓

Tabela

↓

Index

↓

Storage Group

↓

Volume

↓

Disk

Ou então...

Job

↓

PROC

↓

Program

↓

VSAM

↓

CICS

↓

MQ

↓

API

Tudo possui dependências.

Isso é um grafo.


Impact Analysis

Imagine alterar uma tabela Db2.

O gerente pergunta:

O que será impactado?

O Graph RAG consegue navegar pelo conhecimento.

Encontrando:

  • programas

  • jobs

  • APIs

  • telas

  • relatórios

  • batch

  • online

Tudo conectado.


Compliance

Outro exemplo fantástico.

Pergunta:

Quais funcionários tiveram acesso aos dados do cliente durante a auditoria?

Agora entram:

  • usuário

  • grupo RACF

  • dataset

  • aplicação

  • horário

  • operação

Tudo relacionado.

É praticamente impossível responder apenas com similaridade vetorial.


Fraudes

Os maiores bancos do mundo utilizam grafos.

Imagine:

Pessoa A

↓

Empresa B

↓

Conta C

↓

PIX D

↓

Fornecedor E

↓

Pessoa F

O sistema começa a encontrar padrões invisíveis.


Agentic RAG

Agora chegamos ao nível "SysProg Jedi".

O Agentic RAG não apenas consulta informação.

Ele pensa.

Planeja.

Decide.

Executa.

Reavalia.


O agente

Imagine um analista extremamente experiente.

Você pergunta:

Existe risco em instalar este PTF?

Ele não responde imediatamente.

Primeiro ele pensa.

Depois consulta:

  • APAR

  • HOLDDATA

  • SMP/E

  • Inventário

  • CMDB

  • Tickets

  • Mudanças

  • IBM Docs

Só então responde.

É exatamente isso que um agente faz.


O ciclo de raciocínio

Objetivo

↓

Planejamento

↓

Ferramentas

↓

Busca

↓

Análise

↓

Autoavaliação

↓

Nova busca

↓

Resposta

Observe algo importante.

Existe um ciclo.

Ele pode voltar.

Pesquisar novamente.

Corrigir.

Melhorar.

Isso aproxima muito mais o comportamento humano.


MCP entra em cena

É aqui que o MCP (Model Context Protocol) começa a fazer sentido.

O agente não conversa apenas com documentos.

Ele conversa com ferramentas.

Imagine:

Pergunta.

↓

MCP.

↓

GitHub.

↓

Jira.

↓

Confluence.

↓

SQL.

↓

Elastic.

↓

IBM Z.

↓

Prometheus.

↓

Grafana.

↓

ServiceNow.

↓

Resposta consolidada.

Agora estamos falando de IA empresarial.


Um exemplo Bellacosa Mainframe

Imagine perguntar:

Existe risco em alterar este programa COBOL?

Um Agentic RAG poderia:

✔ localizar o código COBOL

✔ descobrir quais COPYBOOKS utiliza

✔ localizar os Jobs

✔ consultar Db2

✔ analisar dependências MQ

✔ consultar APIs z/OS Connect

✔ verificar tickets relacionados

✔ consultar documentação IBM

✔ montar um relatório

✔ sugerir um plano de rollback

Isso não é mais um chatbot.

É praticamente um arquiteto de software trabalhando para você.


Então devemos usar Agentic RAG em tudo?

Não.

Esse é justamente o maior erro do mercado.

Muitos acreditam que arquitetura mais sofisticada significa melhor arquitetura.

Nunca significou.

No Mainframe aprendemos isso há décadas.

Você não instala um Parallel Sysplex para rodar um programa COBOL de folha de pagamento com dez usuários.

Você não cria um Data Sharing Group para um sistema departamental.

Da mesma forma...

Você não cria um Agentic RAG para responder:

Qual é o telefone do RH?


Como escolher?

Pense assim.

Preciso apenas encontrar documentos?

Classic RAG.


Preciso entender relações?

Graph RAG.


Preciso tomar decisões?

Agentic RAG.


Uma analogia divertida

Imagine três funcionários.

Classic RAG

O bibliotecário.

Ele encontra qualquer livro.

Muito rapidamente.


Graph RAG

O investigador.

Ele liga pessoas.

Eventos.

Objetos.

Documentos.


Agentic RAG

O gerente de projetos.

Ele:

  • faz reuniões

  • consulta especialistas

  • cria plano

  • delega tarefas

  • revisa resultados

  • entrega solução


A tendência para 2026 e além

As empresas mais maduras dificilmente escolherão apenas uma dessas arquiteturas.

Elas combinarão todas.

Imagine a seguinte arquitetura:

                 Usuário
                    │
                    ▼
            Agente Inteligente
                    │
      ┌─────────────┼──────────────┐
      ▼             ▼              ▼
 Classic RAG   Graph RAG       Ferramentas
      │             │              │
 Vetores      Knowledge Graph   APIs / MCP
      │             │              │
      └─────────────┼──────────────┘
                    ▼
                 Resposta

Essa abordagem híbrida oferece o melhor dos três mundos: velocidade na recuperação documental, compreensão profunda das relações entre entidades e capacidade de planejamento e execução.


Dicas para quem está começando

Se você é programador júnior, não tente aprender tudo ao mesmo tempo.

Uma trilha prática seria:

  1. Entenda muito bem como funcionam embeddings e bancos vetoriais.

  2. Aprenda a criar um Classic RAG simples usando Python e uma base de documentos.

  3. Estude modelagem de grafos com ferramentas como Neo4j e compreenda conceitos de Knowledge Graph.

  4. Explore frameworks para agentes, como LangGraph, AutoGen ou CrewAI, entendendo como eles planejam tarefas e usam ferramentas.

  5. Aprenda sobre MCP (Model Context Protocol) para conectar agentes a APIs, bancos de dados e sistemas corporativos.

  6. Desenvolva pensamento arquitetural: a tecnologia deve servir ao problema, nunca o contrário.


Curiosidades

☕ Você sabia? O conceito de grafos remonta ao século XVIII, quando Leonhard Euler resolveu o famoso problema das Pontes de Königsberg, considerado o nascimento da Teoria dos Grafos. Hoje, essa mesma matemática ajuda IAs a descobrir fraudes financeiras e mapear dependências de aplicações.

☕ Outra curiosidade: muitos bancos vetoriais utilizam algoritmos de Approximate Nearest Neighbor (ANN). Eles não procuram a resposta perfeita; procuram a resposta boa o suficiente em uma fração do tempo. É um compromisso inteligente entre precisão e desempenho.

☕ No Mainframe também existe "RAG" sem percebermos. Quando um operador consulta procedimentos operacionais, manuais de recuperação, runbooks e documentação antes de executar uma ação, ele está fazendo um processo muito parecido com Retrieval-Augmented Generation — só que usando inteligência humana.


Easter Eggs Bellacosa Mainframe 🥚

🔎 Easter Egg #1: O fluxo "Pergunta → Busca → Resposta" lembra bastante o caminho de um comando TSO: você envia uma solicitação, o sistema localiza os recursos necessários e devolve o resultado. A tecnologia muda, o padrão permanece.

🔎 Easter Egg #2: Um Knowledge Graph de um ambiente IBM Z pode representar milhares de relacionamentos: programas COBOL, COPYBOOKs, transações CICS, tabelas Db2, filas MQ, JCLs, datasets VSAM, grupos RACF, APIs via z/OS Connect e pipelines DevOps. É praticamente um "mapa do reino" do Mainframe.

🔎 Easter Egg #3: Se você entendeu conceitos como dependência de programas, impact analysis, catálogo Db2, RACF, SMP/E e CMDB, já possui uma excelente base mental para compreender Graph RAG e Agentic RAG. A IA moderna reutiliza muitos princípios que arquitetos de Mainframe praticam há décadas.

🔎 Easter Egg #4: Em um futuro próximo, um agente poderá analisar um dump ABEND, consultar automaticamente a documentação IBM, pesquisar APARs, verificar o histórico de mudanças e sugerir a correção antes mesmo que um especialista abra o incidente. Parece ficção científica, mas diversas organizações já caminham nessa direção.


Conclusão

Durante muito tempo perguntávamos:

"Qual é a melhor arquitetura RAG?"

Hoje sabemos que essa é a pergunta errada.

A pergunta correta é:

"Qual arquitetura resolve este problema de negócio com simplicidade, eficiência e governança?"

O Classic RAG continua sendo a escolha ideal para a maioria das aplicações de recuperação de conhecimento. O Graph RAG acrescenta inteligência ao revelar conexões ocultas entre pessoas, sistemas e eventos. Já o Agentic RAG amplia o horizonte ao incorporar planejamento, raciocínio, uso de ferramentas e execução de fluxos complexos.

No universo Bellacosa Mainframe, essa evolução soa familiar. Há décadas aprendemos que arquiteturas robustas não nascem do modismo, mas de princípios sólidos, boas práticas e profundo entendimento do problema. Assim como um bom arquiteto IBM Z escolhe cuidadosamente entre Batch, CICS, MQ, Db2, VSAM ou z/OS Connect, o engenheiro de IA moderno deve selecionar entre Classic RAG, Graph RAG e Agentic RAG conforme a necessidade do negócio.

Porque, no fim das contas, a maior inovação não está em usar a tecnologia mais sofisticada.

Está em construir a solução certa, para o problema certo, no momento certo.

E esse, meu amigo, continua sendo o verdadeiro espírito da engenharia de software.


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...