☕ 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

quinta-feira, 24 de outubro de 2024

⚔️ Tensei Kizoku, Kantei Skill de Nariagaru — Segunda Temporada

 

Bellacosa Mainframe apresenta a segunda temporada do anime Tensei Kizoku

☕ Bellacosa Anime

⚔️ Tensei Kizoku, Kantei Skill de Nariagaru — Segunda Temporada

O garoto que sabia encontrar talentos agora precisa descobrir se eles sobrevivem a uma guerra

A primeira temporada de Tensei Kizoku, Kantei Skill de Nariagaru fez uma pergunta muito interessante:

E se o verdadeiro cheat de um isekai fosse reconhecer o talento das outras pessoas?

A segunda temporada faz uma pergunta muito mais cruel:

E se você estiver certo sobre o talento delas, mas agora precisar mandá-las para uma guerra?

E é justamente aqui que a série cresce.

A habilidade de avaliação de Ars Louvent continua importante, mas já não basta encontrar Rietz, Charlotte, Rosell, Mireille ou Fam. Ars tornou-se senhor de seu território e precisa tomar decisões cujas consequências atingem soldados, aliados, famílias e populações inteiras.

A brincadeira de montar a melhor party virou administração de verdade.

E a Skill Matrix virou War Room.



📜 FICHA DA SEGUNDA TEMPORADA

Título: Tensei Kizoku, Kantei Skill de Nariagaru 2nd Season
Japonês: 転生貴族、鑑定スキルで成り上がる 第2期
Título internacional: As a Reincarnated Aristocrat, I’ll Use My Appraisal Skill to Rise in the World Season 2
Obra original: Miraijin A
Character design original: jimmy
Mangá: Natsumi Inoue
Direção: Takao Kato
Música: Kujira Yumemi
Animação da S2: studio MOTHER
Estreia: 29 de setembro de 2024
Episódios: 12, correspondendo aos episódios 13–24 da série.

A estreia em 29 de setembro e a contagem de 12 episódios são confirmadas pelo próprio portal oficial; os Blu-rays começam no episódio 13 e a maratona oficial posterior identifica a segunda temporada como composta por 12 episódios. (Kantei Skill)

Site oficial do anime



🎬 O QUE MUDOU?

A primeira temporada era essencialmente:

descobrir → recrutar → desenvolver.

A segunda vira:

avaliar → planejar → negociar → comandar → atacar → sobreviver → governar.

Essa mudança é fundamental.

O próprio material promocional oficial apresentou a temporada como o início efetivo da guerra de sucessão de Missian, colocando Ars e seus companheiros em sua primeira campanha militar. (Kantei Skill)

Portanto, se a primeira temporada era quase um:

LinkedIn medieval com Appraisal Skill

a segunda é:

War Room medieval com Appraisal Skill.

😂


⚔️ A GUERRA DE SUCESSÃO DE MISSIAN

O conflito político que estava sendo preparado finalmente domina a narrativa.

Temos a disputa envolvendo as forças de Clan Salemakia e Basamark Salemakia.

E isso é importante porque muda a natureza do problema de Ars.

Antes ele precisava descobrir:

Quem é talentoso?

Agora precisa descobrir:

Quem é talentoso para esta missão específica?

Essa diferença parece pequena.

Não é.


🧠 APPRAISAL 2.0

Na primeira temporada, Ars poderia encontrar alguém e pensar:

STRATEGY............. 95
LEADERSHIP........... 91
MAGIC................ 12

RESULT:
EXCEPTIONAL TALENT

Maravilha.

Contratado.

Na guerra, entretanto:

MISSION:
CAPTURE FORTRESS

ENEMY:
UNKNOWN

TERRAIN:
DIFFICULT

SUPPLIES:
LIMITED

TIME:
CRITICAL

Agora saber que alguém possui Strategy 95 não resolve o problema.

Porque guerra possui contexto.

E contexto não aparece necessariamente numa ficha de atributos.


👑 ARS DEIXA DE SER APENAS RECRUTADOR





Essa é provavelmente a evolução mais importante.

Ars começa a experimentar aquilo que poder realmente significa.

Na primeira temporada:

“Eu encontrei uma pessoa incrível!”

Na segunda:

“Agora essa pessoa poderá morrer por causa de uma decisão minha.”

Isso muda tudo.

Ele não pode simplesmente abrir seu Appraisal e terceirizar a responsabilidade.

É o comandante quem precisa decidir.

E é aqui que o protagonista começa a ficar muito mais interessante.


⚔️ RIETZ MUSES — O TALENTO PRECISA ENTREGAR

Rietz deixa de ser apenas a demonstração de que Ars consegue encontrar talento onde a sociedade enxergava preconceito.

Agora precisa mostrar por que Ars estava certo.

É diferente.

Imagine:

APPRAISAL:
MILITARY = S

Ótimo.

Mas agora:

PRODUCTION:
ENEMY APPROACHING

😂

Não existe mais ambiente de desenvolvimento.

Existe consequência.

Rietz precisa comandar, lutar e proteger.

A confiança de Ars finalmente passa pelo teste mais brutal possível.


🔥 CHARLOTTE — A ARTILHARIA DO GRUPO

Charlotte continua sendo uma das manifestações mais visíveis do potencial encontrado por Ars.

Mas novamente surge uma diferença.

Poder destrutivo não significa automaticamente vitória.

Uma maga poderosa precisa ser empregada corretamente.

Posicionamento.

Momento.

Objetivo.

Proteção.

Coordenação.

Em linguagem mainframe:

CHARLOTTE = HIGH CPU RESOURCE

Você não simplesmente executa:

RUN CHARLOTTE

😂

Existe Workload Management.


🧠 ROSELL — CPU PEQUENA, PROCESSAMENTO GIGANTESCO

Rosell é talvez um dos personagens que melhor representa a filosofia inteira do anime.

Fisicamente, ninguém olharia para ele e imaginaria:

“Esse garoto poderá alterar o resultado de uma campanha militar.”

Ars enxerga.

E justamente por isso Rosell representa o lado intelectual da guerra.

Estratégia significa prever movimentos.

Interpretar terreno.

Calcular riscos.

Entender o adversário.

É praticamente:

Capacity Planning militar.


🍷 MIREILLE — A SENIOR QUE CONHECE O LEGADO

Mireille fica ainda mais interessante nesse contexto.

Porque existe algo que o Appraisal de Ars não consegue fabricar:

experiência.

Ela já conhece guerra, política e pessoas.

E isso cria uma comparação maravilhosa com mainframe.

Imagine contratar um excelente jovem desenvolvedor.

COBOL: excelente.

Db2: excelente.

CICS: excelente.

Mas então às 03:17 acontece um incidente envolvendo uma aplicação de 1989.

O jovem pergunta:

“Onde está a documentação?”

O veterano responde:

“Documentação?”

😂

E começa a explicar por que determinado programa aparentemente inútil não pode ser removido.

Mireille representa esse conhecimento contextual.


🕵️ FAM — INTELIGÊNCIA ANTES DA BATALHA

Fam mostra outra camada da guerra.

Informação.

Você pode possuir:

  • melhores soldados;

  • melhores magos;

  • melhor general;

  • melhores armas.

Mas se não souber o que o inimigo está fazendo, continuará parcialmente cego.

Aqui a série aproxima Appraisal e inteligência.

Ars avalia pessoas.

Fam ajuda a avaliar situações.

É quase a diferença entre:

monitoramento e observabilidade.


🏰 AS FORTALEZAS

A segunda temporada também entende uma coisa importante sobre guerra medieval:

castelos não são decoração.

São infraestrutura.

Uma fortaleza controla território, passagem, abastecimento e capacidade de projetar força.

Por isso aparecem operações envolvendo posições fortificadas e comandantes inimigos. O material oficial da temporada cita, entre outros, Ryuupa Roozton, comandante da fortaleza de Vardosen, além de inimigos ligados ao Castelo Rolto. (Kantei Skill)

Pense numa fortaleza como um enorme:

FIREWALL
+
DATACENTER
+
WAREHOUSE
+
COMMAND CENTER

medieval.

Você não precisa destruir tudo.

Precisa conquistar o ponto estratégico.


🗺️ LOGÍSTICA: O PERSONAGEM INVISÍVEL

Aqui existe algo que adoro em histórias militares.

Exércitos precisam comer.

Cavalos precisam comer.

Armas quebram.

Soldados cansam.

Mensagens precisam chegar.

Feridos precisam ser transportados.

Estradas importam.

Pontes importam.

Distâncias importam.

Ou seja:

Guerra também é processamento batch.

😂

Você pode possuir o melhor programa COBOL do planeta.

Sem arquivo de entrada:

//SYSIN DD *

boa sorte.

Da mesma maneira, um exército sem suprimentos deixa de ser exército.


🎭 NOVOS PERSONAGENS

A guerra amplia muito o elenco.

Entre os personagens anunciados oficialmente para essa fase estão Leng Salemakia, Shakma Dorries e Selena Bandol; posteriormente entram nomes como Clamant Maitro III, Shin Seimaro, Braham Joe, Jean Tendry e Dan Aleest. (Kantei Skill)

Isso é necessário.

Quando a escala política aumenta, o mundo não pode continuar existindo apenas em função dos seis protagonistas.

Surgem:

mercenários, comandantes, nobres, administradores, adversários e aliados circunstanciais.

O tabuleiro aumenta.


♟️ O INIMIGO TAMBÉM TEM TALENTOS

E aqui aparece uma das melhores consequências da premissa.

Ars consegue encontrar pessoas extraordinárias.

Mas...

por que apenas Ars teria pessoas extraordinárias ao seu redor?

Não teria.

O outro lado também possui:

bons estrategistas,

bons combatentes,

bons líderes,

pessoas leais,

pessoas inteligentes.

O Appraisal não significa:

MY TEAM = TALENTED
ENEMY = IDIOTS

Isso destruiria a história.

A segunda temporada começa a mostrar um mundo onde talento existe dos dois lados do tabuleiro.


🤝 MERCENÁRIOS E LEALDADE

Esse elemento também torna a situação mais interessante.

Existe diferença entre:

capacidade e lealdade.

Uma pessoa pode ser:

COMBAT............. S
STRATEGY........... A
LEADERSHIP......... A
LOYALTY............ ?

E agora?

Ars precisa compreender algo que qualquer gestor eventualmente aprende:

Competência sem confiança também produz risco.


❤️ LICIA — A GUERRA NÃO ELIMINA A VIDA

A presença de Licia é importante porque impede que Ars seja reduzido a uma máquina de decisões militares.

Existe relacionamento.

Casamento.

Família.

Afeto.

Responsabilidade.

Futuro.

A trilha sonora oficial da segunda temporada inclusive abre com uma faixa chamada “Wedding”, seguida por temas ligados à evolução da habilidade, conspiração, conselho de guerra, avanço militar e reforços — quase um pequeno resumo musical da mudança de escala da temporada. (Kantei Skill)

Ars não está tentando conquistar território simplesmente porque um RPG precisa oferecer o próximo mapa.

Ele está construindo uma vida.


🩸 A GUERRA TEM CONSEQUÊNCIAS

É aqui que Kantei Skill ganha um pouco mais de peso.

Não chega ao nível de brutalidade de Goblin Slayer.

Nem tenta.

Mas a guerra significa que decisões possuem consequências coletivas.

Se Ars errar recrutando alguém, anteriormente poderia perder uma oportunidade.

Agora pode perder pessoas.

É uma evolução importante do conceito.


🔍 A GRANDE LIMITAÇÃO DO APPRAISAL

E encontramos talvez o aspecto mais interessante de toda a habilidade.

Appraisal responde:

“Do que essa pessoa é capaz?”

Mas não necessariamente responde:

“O que essa pessoa fará?”

Essa diferença é gigantesca.

Uma pessoa pode possuir:

LEADERSHIP = 98

e utilizar liderança para algo terrível.

Pode possuir:

INTELLIGENCE = 97

e tomar uma decisão moralmente desastrosa.

Pode possuir:

LOYALTY = 90

mas lealdade a quem?

Atributos não substituem caráter, contexto e julgamento.


🧑‍💼 BELLACOSA MAINFRAME — APPRAISAL EM PRODUÇÃO

A primeira temporada seria o treinamento:

DEV
↓
TRAINING
↓
SIT

A segunda temporada é:

==============================
       P R O D U Ç Ã O
==============================

Agora acabou o laboratório.

Imagine Ars como Technical Manager de uma aplicação crítica.

Ele montou:

RIETZ
CICS / Leadership

CHARLOTTE
Performance / Heavy Processing

ROSELL
Architecture / Capacity Planning

MIREILLE
Senior SME / Legacy Knowledge

FAM
Security Intelligence

LICIA
Business / Stakeholder Management

Na primeira temporada:

“Excelente equipe.”

Na segunda:

SEV-1.

03:17.

Black Friday.

CICS 100%.

Db2 lock.

MQ crescendo.

API Gateway retornando 503.

Diretoria ligando.

Agora descobriremos se a Skill Matrix estava certa.

😂


🧠 A DIFERENÇA ENTRE TALENTO E TIME

Talvez essa seja a principal mensagem da temporada.

Você pode juntar cinco gênios numa sala.

Isso não significa que possui um grande time.

Talento individual:

A + A + A + A + A

não produz automaticamente:

TEAM = S

Existem outras variáveis:

confiança + comunicação + liderança + propósito + experiência + coordenação.

Ars precisa aprender exatamente isso.


👑 O APPRAISAL MAIS IMPORTANTE É O DELE PRÓPRIO

Existe uma ironia deliciosa.

Ars consegue avaliar todo mundo.

Mas precisa constantemente avaliar a si mesmo sem possuir a mesma objetividade.

Será que tomou a decisão correta?

Será que colocou alguém em risco?

Será que confiou demais?

Será que deveria ter escolhido outra estratégia?

Isso é liderança.

O dashboard mostra o sistema inteiro.

Menos você.


🎵 ABERTURA E ENCERRAMENTO

A segunda temporada ganhou “SKILLAWAKE”, do PassCode, como abertura, enquanto Yuki Tanaka interpreta “Familiar” no encerramento. O portal oficial publicou separadamente as versões sem créditos da abertura e do encerramento. (Kantei Skill)

A abertura é especialmente adequada ao novo momento: o material oficial destaca tanto o crescimento anterior de Ars quanto aliados, novos personagens e adversários que entram na história. (Kantei Skill)


📚 MANGÁ E LIGHT NOVEL

A estrutura continua vindo da light novel de Miraijin A, com character concept de jimmy, além da adaptação em mangá de Natsumi Inoue.

O anime precisa condensar bastante política, estratégia e desenvolvimento de personagens. Para quem gosta especialmente da parte administrativa e estratégica, portanto, vale perceber que a adaptação televisiva não representa necessariamente toda a densidade disponível no material escrito.


🎯 O QUE A SEGUNDA TEMPORADA FAZ DIFERENTE

A primeira temporada dizia:

Encontre pessoas talentosas.

A segunda acrescenta:

Confie nelas.

Depois:

Dê responsabilidade a elas.

E finalmente:

Aceite que você também será responsável pelas consequências.

Isso transforma Ars.


🥚 EASTER EGG — INCIDENTE 03:17

Imagine a batalha decisiva.

03:17.

Mensageiro entra correndo:

“Lorde Ars! Perdemos contato com a fortaleza!”

Ars:

DISPLAY "STATUS?"

Mensageiro:

IEC141I

Ars empalidece.

Mireille toma café.

Rietz desembainha a espada.

Charlotte prepara magia.

Rosell abre o mapa.

Fam desaparece pela janela.

E algum velho programador COBOL no fundo da sala simplesmente pergunta:

“Vocês verificaram se o dataset estava catalogado?”

Silêncio.

😂☕


🌟 O GRANDE TEMA DA SEGUNDA TEMPORADA

A primeira temporada é sobre potencial.

A segunda é sobre responsabilidade.

Essa distinção muda minha leitura da série.

Ars descobriu pessoas extraordinárias quando ninguém enxergava valor nelas.

Isso era bonito.

Agora ele precisa fazer algo muito mais difícil:

confiar nelas quando existe algo real a perder.

É fácil dizer:

“Eu acredito em você.”

Muito mais difícil é dizer:

“Eu acredito em você — portanto essa missão será sua.”


☕ CONCLUSÃO BELLACOSA ANIME

Tensei Kizoku, Kantei Skill de Nariagaru poderia ter sido apenas mais um isekai com uma interface de RPG.

Mas existe uma ideia surpreendentemente boa escondida ali.

Ars não recebeu o poder de ser melhor que todos.

Recebeu o poder de perceber no que os outros poderiam ser melhores que ele.

Na primeira temporada ele construiu sua equipe.

Na segunda, coloca essa equipe em produção.

E produção nunca perdoa PowerPoint bonito.

😂

Agora existem adversários competentes, política, fortalezas, mercenários, inteligência, logística e guerra.

E o menino que conseguia enxergar números sobre a cabeça das pessoas começa a descobrir algo que nenhum número consegue resolver completamente:

liderar pessoas significa confiar em seres humanos, não em estatísticas.

Talvez esse seja o verdadeiro Appraisal Skill que Ars precisa desenvolver.

Não avaliar:

STR 92.

INT 97.

MAG 96.

Mas olhar para Rietz, Charlotte, Rosell, Mireille, Fam e Licia e entender:

“Eu não preciso ser o mais poderoso deste mundo. Preciso garantir que essas pessoas tenham condições de usar aquilo que sabem fazer.”

Isso vale para um reino.

Vale para uma guerra.

Vale para uma empresa.

E vale perfeitamente para uma equipe de mainframe.

Porque nenhum sistema crítico sobrevive quarenta anos graças a um único gênio.

Sobrevive porque, geração após geração, alguém olha para um jovem sentado diante do ISPF e decide:

“Esse Padawan ainda não sabe COBOL. Mas há alguma coisa nele. Vamos ensinar.”

☕⚔️ E talvez esse seja o Appraisal Skill que realmente constrói reinos.

Nota importante em setembro de 2026: a história do anime já vai continuar. A 3ª temporada está oficialmente marcada para estrear em 27 de setembro de 2026, e o portal oficial já está promovendo sua transmissão. (Kantei Skill)

Ou seja: falta menos de uma semana para voltarmos ao reino de Ars. 😄

quarta-feira, 23 de outubro de 2024

🕶️ DIABOLIK NO MAINFRAME — O Roubo Perfeito e o Risk Score que Percebeu Tudo

 

Bellacosa Mainframe e o Risk Score

☕ Um Café no Bellacosa Mainframe

🕶️ DIABOLIK NO MAINFRAME — O Roubo Perfeito e o Risk Score que Percebeu Tudo

Fraude, AML, comportamento, dispositivos, transações, grafos e Risk Scoring em tempo real — porque o criminoso perfeito não precisa cometer um erro. Basta fazer algo que não combine com a vítima.

Há uma diferença fundamental entre um ladrão comum e Diabolik.

O ladrão comum tenta abrir a porta.

Diabolik já sabe onde está a chave.

O ladrão comum aparece diante da câmera.

Diabolik estudou o ângulo morto.

O ladrão comum rouba o cartão.

Diabolik prefere que o banco continue acreditando que o verdadeiro dono está usando o cartão.

E é justamente por isso que ele é um excelente personagem para entendermos o Risk Scoring moderno.

Imagine uma noite qualquer.

03:17.

Em algum lugar da cidade, um cliente chamado João dorme tranquilamente.

Seu cadastro no banco diz:

CUSTOMER: JOAO
KYC: OK
PEP: NO
SANCTIONS: NO
ACCOUNT AGE: 8 YEARS
RISK: LOW

Tudo parece normal.

O problema é que João não está usando sua conta.

Diabolik está.

E nosso sistema tem poucos milissegundos para perceber isso.

Bem-vindo ao estranho mundo onde conhecer a identidade do cliente já não basta.



🕶️ CAPÍTULO 1 — Diabolik não quer parecer Diabolik

O Risk Scoring tradicional tinha uma visão relativamente confortável do mundo.

O cliente chegava, apresentava seus documentos, passava pelas verificações necessárias e recebia determinada classificação:

LOW
MEDIUM
HIGH

Era quase uma fotografia.

No momento em que João abriu sua conta, o banco verificou identidade, endereço, documentos, profissão, renda e outros elementos necessários ao processo.

Depois disso:

JOAO = LOW RISK

O problema está na palavra é.

João não é necessariamente LOW RISK.

João estava associado a determinado nível de risco naquele contexto e naquele momento.

Meses depois, muita coisa pode ter mudado.

O cliente pode trocar de telefone, viajar, mudar endereço, começar a movimentar valores diferentes, adicionar beneficiários, alterar senhas e utilizar novos dispositivos.

E existe ainda uma possibilidade mais inquietante:

João continua sendo João.

Mas alguém conseguiu assumir sua identidade digital.

Diabolik não precisa modificar o cadastro.

Pelo contrário.

Quanto menos alterar, melhor.



🎭 CAPÍTULO 2 — A melhor máscara é uma identidade verdadeira

Essa é uma das ideias mais interessantes da fraude digital.

Imagine que um criminoso tenha:

CPF correto
nome correto
endereço correto
data de nascimento correta
credenciais corretas

Uma verificação baseada exclusivamente em identidade pode encontrar:

IDENTITY = VALID

E isso pode ser perfeitamente verdadeiro.

A identidade realmente existe.

O problema é outro:

quem está controlando aquela identidade naquele instante?

É uma diferença monumental.

Podemos ter:

IDENTITY RISK = LOW

e simultaneamente:

BEHAVIOR RISK = HIGH
DEVICE RISK   = HIGH
SESSION RISK  = HIGH

Por isso o Risk Scoring moderno deixa de perguntar apenas:

Quem é você?

E começa a perguntar:

O que está acontecendo?



📸 CAPÍTULO 3 — O velho sistema guardava fotografias

Vamos imaginar um sistema fictício chamado BELLABANK.

No cadastro de João encontramos:

CUSTOMER-ID : 00091827364
NAME        : JOAO SILVA
KYC-STATUS  : APPROVED
PEP-FLAG    : N
AML-RISK    : LOW
COUNTRY     : BR

Excelente.

Só que o cadastro não consegue contar sozinho a história seguinte:

03:17 NEW DEVICE

03:19 PASSWORD RESET

03:21 NEW BENEFICIARY

03:22 TRANSFER R$ 9.800

Cada evento isoladamente pode ser legítimo.

Pessoas compram celulares.

Pessoas esquecem senhas.

Pessoas cadastram beneficiários.

Pessoas transferem R$9.800.

Mas a sequência inteira é muito mais interessante.

É aí que começamos a sair da fotografia e entrar no filme.


Bellacosa Mainframe e o risk scoring

🎬 CAPÍTULO 4 — Risk Scoring transforma fotografia em filme

No modelo contínuo, o cliente não recebe apenas uma etiqueta eterna.

Podemos imaginar:

09:00 RISK = 12

Compra café.

09:17 RISK = 11

Usa o mesmo celular.

12:30 RISK = 10

Compra almoço num estabelecimento habitual.

Tudo normal.

Então:

03:17 NEW DEVICE

Score:

10 -> 22

Logo depois:

PASSWORD RESET

Score:

22 -> 39

Novo beneficiário:

39 -> 58

Transferência incomum:

58 -> 84

Diabolik ainda possui usuário e senha corretos.

O cadastro continua correto.

Mas agora o sistema diz:

IDENTITY = OK

BEHAVIOR = NOT OK

Esse é o coração da mudança.



🧮 CAPÍTULO 5 — O Risk Score entra em cena

Para um programador COBOL iniciante, podemos começar pensando em algo simples:

RISK-SCORE = 0

Cada fator acrescenta ou reduz pontos:

IF NEW-DEVICE = 'Y'
   ADD 10 TO RISK-SCORE
END-IF

IF PASSWORD-RESET = 'Y'
   ADD 15 TO RISK-SCORE
END-IF

IF NEW-BENEFICIARY = 'Y'
   ADD 20 TO RISK-SCORE
END-IF

IF UNUSUAL-AMOUNT = 'Y'
   ADD 25 TO RISK-SCORE
END-IF.

Teríamos:

10 + 15 + 20 + 25 = 70

E poderíamos estabelecer:

00-20 LOW
21-40 MEDIUM
41-60 HIGH
61-100 CRITICAL

É apenas um exemplo didático. Um sistema real exigiria muito mais cuidado com pesos, regras, contexto, validação, calibração e governança.

Mas a essência está aqui:

SIGNALS
   ↓
WEIGHTS
   ↓
RULES
   ↓
SCORE
   ↓
DECISION

💎 CAPÍTULO 6 — Nem todo diamante vale os mesmos pontos

Aqui Diabolik começa a rir do nosso programa COBOL.

Porque ele percebeu uma fragilidade.

Se nosso modelo simplesmente somar:

NEW DEVICE        +10
PASSWORD RESET    +10
NEW BENEFICIARY   +10
TRANSFER          +10

teremos:

RISK = 40

Mas talvez essa combinação específica represente risco muito maior.

É a diferença entre observar quatro acontecimentos e observar uma história formada por quatro acontecimentos.

Considere:

A = NEW DEVICE
B = PASSWORD RESET
C = NEW BENEFICIARY
D = LARGE TRANSFER

Não podemos assumir sempre que:

RISK(A+B+C+D)
=
RISK(A)+RISK(B)+RISK(C)+RISK(D)

A sequência pode produzir um risco adicional.

Em segurança, contexto importa.

Em fraude, ordem também importa.


⏱️ CAPÍTULO 7 — Diabolik conhece o relógio

Imagine:

01/08 NEW DEVICE
15/08 PASSWORD RESET
02/09 NEW BENEFICIARY
15/09 TRANSFER

Pode ser perfeitamente normal.

Agora:

03:17 NEW DEVICE
03:18 PASSWORD RESET
03:20 NEW BENEFICIARY
03:22 TRANSFER

Os eventos são praticamente os mesmos.

Mas o significado mudou completamente.

Entrou uma nova dimensão:

velocity.

Não basta perguntar:

WHAT?

Precisamos perguntar:

WHAT?
WHEN?
HOW OFTEN?
IN WHICH ORDER?

Em sistemas transacionais, tempo também é dado.


🧬 CAPÍTULO 8 — O melhor suspeito de João é o próprio João

Agora chegamos ao comportamento.

Imagine que João normalmente faça:

R$ 70
R$ 150
R$ 380
R$ 600
R$ 1.200

Então aparece:

R$ 9.800

Interessante.

Mas Maria administra uma empresa e normalmente movimenta:

R$ 30.000
R$ 70.000
R$ 120.000

Hoje ela movimentou:

R$ 9.800

Se tivermos uma regra burra:

IF AMOUNT > 5000
   HIGH-RISK
END-IF

João e Maria recebem tratamento semelhante.

Mas os comportamentos são completamente diferentes.

O sistema moderno procura estabelecer um baseline.

Ou seja:

como este cliente normalmente se comporta?

Isso permite comparar:

CURRENT BEHAVIOR
       versus
EXPECTED BEHAVIOR

A pergunta deixa de ser:

R$9.800 é muito?

E passa a ser:

R$9.800 é estranho para João?

Isso é muito mais poderoso.


🌍 CAPÍTULO 9 — Diabolik viaja rápido demais

Imagine:

20:00 LOGIN SAO PAULO

Depois:

20:35 LOGIN TOKYO

Talvez João tenha descoberto teletransporte.

Talvez seja VPN.

Talvez seja problema na geolocalização.

Talvez sejam sessões diferentes.

Ou talvez tenhamos uma conta comprometida.

Um bom sistema não deveria automaticamente concluir:

FRAUD!

Ele deveria produzir algo semelhante a:

IMPOSSIBLE_TRAVEL +25
NEW_DEVICE        +15
UNKNOWN_IP        +10

E combinar isso com todo o restante.

Essa é outra diferença fundamental.

Sinal não é sentença.

Sinal é evidência.


🕸️ CAPÍTULO 10 — O Inspetor Ginko descobre o grafo

Diabolik conseguiu ser perfeito.

Nenhuma transferência parece absurda.

Nenhum login parece impossível.

Nenhuma senha foi redefinida.

Individualmente, cada conta parece normal.

Então entra o equivalente digital do Inspetor Ginko.

Ele deixa de olhar apenas indivíduos e começa a observar relações.

              DEVICE-X
             /    |    \
            /     |     \
         JOAO   MARIA   CARLOS
           |      |       |
        ACCOUNT ACCOUNT ACCOUNT

Interessante.

Três pessoas diferentes utilizam o mesmo dispositivo.

Isso é fraude?

Não necessariamente.

Pode ser uma família.

Pode ser uma empresa.

Pode ser um equipamento compartilhado.

Agora descobrimos:

DEVICE-X
   |
   +--- ACCOUNT-A
   |
   +--- ACCOUNT-B
   |
   +--- ACCOUNT-C
   |
   +--- ACCOUNT-D

E duas dessas contas tiveram fraude confirmada.

A relação ficou mais interessante.

Estamos entrando no mundo de graph analytics.

Clientes, contas, cartões, dispositivos, IPs, telefones, endereços, merchants e beneficiários podem ser representados como nós conectados.

O risco pode estar não apenas no indivíduo.

Pode estar na rede à qual ele pertence.


💳 CAPÍTULO 11 — Diabolik entra no BELLACARD

Vamos colocar nosso ladrão dentro de um sistema de cartões.

Diabolik conseguiu utilizar o cartão de João.

Uma autorização chega:

CARD
AMOUNT
MERCHANT
MCC
COUNTRY
TERMINAL
TIMESTAMP

O sistema tradicional verifica:

CARD VALID?
ACCOUNT ACTIVE?
LIMIT AVAILABLE?
CARD BLOCKED?
PIN/CVV VALID?

Mas agora adicionamos:

RISK ENGINE

Arquiteturalmente:

POS / ATM / MOBILE
        |
        v
 TRANSACTION
        |
        v
+----------------+
| AUTHORIZATION  |
+----------------+
        |
   +----+-----+
   |          |
   v          v
ACCOUNT    RISK ENGINE
   |          |
   +----+-----+
        |
        v
 DECISION ENGINE
        |
 +------+------+------+
 |      |      |      |
APPROVE MONITOR VERIFY DECLINE

Agora o Risk Score passa a participar da decisão.


🚦 CAPÍTULO 12 — Nem todo suspeito deve ser preso

Essa talvez seja a parte mais importante do conceito inteiro.

Imagine:

RISK 12

Resposta:

APPROVE

Score:

RISK 32

Talvez:

APPROVE + MONITOR

Score:

RISK 54

Talvez:

STEP-UP AUTHENTICATION

Peça biometria.

Confirmação adicional.

MFA.

Outro fator.

Score:

RISK 72

Talvez:

REVIEW

Score:

RISK 96

Talvez:

DECLINE
BLOCK
INVESTIGATE

Perceba a mudança.

Risk Scoring não serve exclusivamente para dizer:

NÃO.

Ele pode ajudar o sistema a decidir quanto de confiança adicional precisa antes de dizer SIM.


💰 CAPÍTULO 13 — Prender todo mundo também custa dinheiro

Imagine uma instituição aterrorizada com fraude.

Ela cria:

IF TRANSACTION-AMOUNT > 5000
   DECLINE
END-IF

Fraudes diminuem.

O diretor comemora.

Até aparecer outro relatório:

APPROVAL RATE ↓
CUSTOMER SATISFACTION ↓
REVENUE ↓
ABANDONMENT ↑
SUPPORT CALLS ↑

Descobrimos o false positive.

O cliente era legítimo.

Nosso sistema o tratou como criminoso.

Diabolik escapou enquanto prendíamos João.

É quase poeticamente apropriado.


⚖️ CAPÍTULO 14 — O Risk Engine vive entre dois erros

Todo sistema antifraude vive numa tensão.

Se for permissivo demais:

FRAUD ↑
LOSSES ↑

Se for rígido demais:

FALSE POSITIVES ↑
CUSTOMER FRICTION ↑
DECLINES ↑
REVENUE ↓

Então existe uma espécie de equação empresarial:

MAXIMIZE

LEGITIMATE APPROVALS
REVENUE
CUSTOMER EXPERIENCE

MINIMIZE

FRAUD
AML EXPOSURE
CHARGEBACKS
OPERATIONAL COST
REGULATORY RISK

Risk Scoring não elimina essa tensão.

Ele nos permite administrá-la com maior granularidade.


🏦 CAPÍTULO 15 — Fraud e AML moram no mesmo prédio, mas não são irmãos gêmeos

Fraude e AML podem utilizar muitos sinais semelhantes:

IDENTITY
TRANSACTIONS
DEVICES
LOCATION
BENEFICIARIES
BEHAVIOR
NETWORK

Mas não são exatamente o mesmo problema.

Fraude normalmente está preocupada com apropriação indevida, engano, abuso de contas, pagamentos ou recursos.

AML olha para riscos associados à movimentação e possível lavagem de recursos, entre outras tipologias de crime financeiro.

Podemos ter:

FRAUD SCORE
     |
     +------+
            |
            v
      COMPOSITE RISK
            ^
            |
     +------+
     |
AML SCORE

A vantagem está em compartilhar sinais sem destruir as particularidades de cada disciplina.


🤖 CAPÍTULO 16 — Então chega a Inteligência Artificial

Até aqui podemos fazer muita coisa com regras.

Mas temos milhões de eventos.

Centenas de variáveis.

Relações complexas.

Padrões temporais.

Machine Learning pode ajudar a encontrar combinações que seriam extremamente difíceis de escrever manualmente.

O problema aparece quando recebemos:

MODEL OUTPUT = 97

Perguntamos:

WHY?

E o computador responde metaforicamente:

¯\_(ツ)_/¯

Não.

Ginko não aceitaria.

O auditor muito menos.

Um sistema robusto precisa oferecer reason codes, evidências, rastreabilidade e governança.

Por exemplo:

RISK SCORE = 91

REASONS:

R017 NEW DEVICE
R042 IMPOSSIBLE TRAVEL
R071 UNUSUAL AMOUNT
R103 NEW BENEFICIARY
R121 HIGH VELOCITY

Agora o número possui uma história.


🗄️ CAPÍTULO 17 — Ginko entra no Db2

Vamos finalmente entrar no IBM Z.

Podemos imaginar:

CHANNELS
 |
 +-- MOBILE
 +-- WEB
 +-- ATM
 +-- POS
 |
 v
API / MESSAGE LAYER
 |
 v
CICS
 |
 +----------+
 |          |
 v          v
Db2       IBM MQ
 |          |
 |          v
 |       EVENTS
 |          |
 +-----> RISK ENGINE
            |
      +-----+-----+
      |     |     |
    RULES  ML   GRAPH
      |     |     |
      +-----+-----+
            |
            v
        RISK SCORE
            |
            v
      DECISION ENGINE

O detalhe crucial:

o cliente está esperando.

No supermercado, João não quer assistir a uma arquitetura de 47 microsserviços discutindo se deve aprovar seu café.

Ele quer:

BIP!
APROVADO

Portanto latência importa.

Muito.


⚡ CAPÍTULO 18 — O roubo perfeito dura milissegundos

Uma transação online pode precisar executar diversas verificações:

CARD VALIDATION
ACCOUNT LOOKUP
LIMIT CHECK
STATUS CHECK
FRAUD RULES
RISK SCORE
AUTHORIZATION
LOGGING

Tudo dentro de um orçamento de latência.

Essa é uma das razões pelas quais a arquitetura de sistemas críticos é tão fascinante.

Não basta calcular corretamente.

Precisamos calcular corretamente a tempo.

O Risk Engine que responde depois que a transação terminou é como Ginko chegando ao cofre na manhã seguinte.

Interessante para investigação.

Inútil para impedir aquele evento.


🧯 CAPÍTULO 19 — O sistema também precisa investigar a si mesmo

Imagine uma nova regra.

Ela bloqueia 40% das transações de determinado segmento.

Fraude cai 2%.

Parece bom?

Talvez não.

Precisamos observar:

APPROVAL RATE
DECLINE RATE
FRAUD RATE
FALSE POSITIVE RATE
CHARGEBACK RATE
CHALLENGE RATE
MANUAL REVIEW RATE

Também:

RULE HIT RATE
SCORE DISTRIBUTION
REASON CODES

E algo que considero particularmente interessante:

SCORE MIGRATION

Quem passou:

LOW -> MEDIUM

Quem passou:

MEDIUM -> HIGH

E principalmente:

LOW -> CRITICAL

O valor não está somente em descobrir quem está perigoso.

Está em descobrir quem está mudando rapidamente.


⌛ CAPÍTULO 20 — Até suspeitas envelhecem

João viajou.

Usou um novo dispositivo.

Fez uma transação diferente.

Seu score subiu:

RISK = 68

Depois voltou para casa.

Utilizou normalmente sua conta por semanas.

Nada estranho aconteceu.

Deveria continuar em 68 para sempre?

Provavelmente não.

Podemos introduzir o conceito de risk decay.

Conforme o tempo passa sem novos sinais relevantes:

68
 |
 v
55
 |
 v
41
 |
 v
28

Isso impede que eventos antigos se transformem em condenações eternas.

Tempo não serve apenas para aumentar risco.

Também pode ajudar a contextualizá-lo.


🎯 CAPÍTULO 21 — O Risk Score também pode ser atacado

Aqui Diabolik percebe outra coisa.

Se conseguir descobrir as regras, poderá tentar permanecer abaixo dos thresholds.

Suponha:

R$10.000 = HIGH RISK

Então ele tenta:

R$4.800
R$4.700
R$4.900

Uma regra olha para cada evento:

OK
OK
OK

Um sistema contextual observa:

3 TRANSACTIONS
SHORT WINDOW
TOTAL R$14.400
UNUSUAL VELOCITY

E responde:

RISK ↑

Isso nos ensina outra coisa importante:

fraudadores também observam sistemas antifraude.

O Risk Engine não enfrenta um fenômeno estático.

Existe um adversário adaptativo do outro lado.


🧪 CAPÍTULO 22 — Champion contra Challenger

Se alterarmos um modelo de risco diretamente em produção, podemos criar nosso próprio desastre.

Então imagine:

CHAMPION MODEL

É o modelo atualmente utilizado.

Ao lado:

CHALLENGER MODEL

O challenger pode receber os mesmos eventos sem necessariamente controlar a decisão final.

Depois comparamos:

FRAUD DETECTION
FALSE POSITIVES
APPROVAL RATE
LATENCY
STABILITY

Se realmente for melhor, pode tornar-se o novo champion.

Isso transforma Risk Scoring em processo de engenharia, e não numa coleção de palpites.


🧾 CAPÍTULO 23 — Diabolik odeia auditoria

Imagine que seis meses depois alguém pergunte:

Por que a transação 918273 foi recusada?

Não podemos responder:

Porque o score estava alto.

Precisamos conseguir reconstruir:

TRANSACTION
MODEL VERSION
RULE VERSION
INPUT DATA
SCORE
REASON CODES
DECISION
TIMESTAMP

Idealmente:

03:17:01 EVENT RECEIVED
03:17:01 DEVICE RULE HIT
03:17:01 VELOCITY RULE HIT
03:17:01 SCORE 82
03:17:01 STEP-UP REQUESTED
03:17:04 MFA FAILED
03:17:04 DECLINED

Isso é auditabilidade.

E em sistemas financeiros ela não é decoração arquitetural.

É parte do produto.


🕵️ CAPÍTULO 24 — A máquina encontra a pista; Ginko monta o caso

Automação não significa necessariamente remover o investigador.

Significa evitar que ele desperdice seu tempo procurando palha.

Imagine um analista recebendo:

CASE 827364

CUSTOMER: JOAO
RISK: 93

TRIGGERS:
NEW DEVICE
PASSWORD RESET
NEW BENEFICIARY
UNUSUAL TRANSFER
SHARED DEVICE

RELATED:
7 ACCOUNTS

CONFIRMED FRAUD:
2 ACCOUNTS

Agora existe um caso investigável.

A máquina percorreu milhões de eventos.

O humano recebeu uma exceção relevante.

MACHINE
   |
   v
DETECT
   |
   v
CORRELATE
   |
   v
PRIORITIZE
   |
   v
HUMAN INVESTIGATION

Essa parceria é muito mais interessante do que a fantasia de simplesmente substituir todo investigador por IA.


💎 CAPÍTULO 25 — Finalmente Diabolik chega ao cofre

Às 03:17, Diabolik inicia sua operação.

Primeiro:

LOGIN

Nada acontece.

Depois:

NEW DEVICE

Pequena alteração.

Depois:

PASSWORD RESET

Outra alteração.

Depois:

NEW BENEFICIARY

O sistema começa a ficar desconfiado.

Finalmente:

TRANSFER R$ 48.000

O antigo sistema talvez enxergasse:

JOAO
KYC OK
ACCOUNT ACTIVE
BALANCE AVAILABLE

O novo sistema enxerga:

JOAO
+
NEW DEVICE
+
PASSWORD RESET
+
NEW BENEFICIARY
+
UNUSUAL AMOUNT
+
HIGH VELOCITY
+
BEHAVIORAL DEVIATION

Resultado:

RISK SCORE = 94

Decision Engine:

STEP-UP AUTHENTICATION

Diabolik possui usuário.

Possui senha.

Possui dados pessoais.

Mas falta alguma coisa que João possui.

A operação falha.

Não porque o sistema descobriu:

Este homem é Diabolik.

Isso seria impossível.

Ele descobriu algo muito mais útil:

Quem quer que esteja realizando esta operação não está se comportando como João.

Esse é o verdadeiro poder da análise comportamental.


🐣 EASTER EGG — 03:17

Quem já visitou algumas vezes o Bellacosa Mainframe percebeu.

Algo sempre acontece às:

03:17

É o horário em que ninguém deveria estar olhando.

O batch está trabalhando.

O operador tomou café.

O desenvolvedor jurou que não mexeu em produção.

E algum JOB misterioso aparece:

JOBNAME  DIABOLIK
OWNER    UNKNOWN
STATUS   EXECUTING

Ginko abre o SDSF.

Procura o JOB.

Nada.

Só encontra no SYSOUT:

ICH408I
USER(DIABOLIK) ACCESS DENIED

Desta vez, RACF ganhou.

☕


🧠 CAPÍTULO 26 — O que o programador COBOL iniciante precisa guardar

Depois de toda essa perseguição, podemos reduzir o Risk Scoring a uma cadeia bastante compreensível:

RECEIVE EVENT
     |
     v
IDENTIFY CUSTOMER
     |
     v
LOAD CONTEXT
     |
     v
READ HISTORY
     |
     v
CALCULATE SIGNALS
     |
     v
APPLY RULES
     |
     v
CALCULATE SCORE
     |
     v
MAKE DECISION
     |
     v
LOG EVERYTHING

Veja que curioso.

Quando retiramos os nomes modernos, aparecem conceitos conhecidos:

INPUT
VALIDATION
LOOKUP
BUSINESS RULE
CALCULATION
DECISION
AUDIT
COMMIT

O programador COBOL de 1985 reconheceria boa parte da lógica.

O que mudou foi a quantidade de contexto disponível e a velocidade necessária para correlacioná-lo.

Hoje podemos acrescentar:

DEVICE
IP
LOCATION
BEHAVIOR
VELOCITY
GRAPH
ML
REAL-TIME EVENTS

Mas o problema fundamental continua lindamente familiar:

DADOS
  +
REGRAS
  +
CONTEXTO
  =
DECISÃO

☕ EPÍLOGO — Ginko nunca precisou saber quem estava atrás da máscara

Essa talvez seja a grande lição de Risk Scoring.

O modelo antigo queria classificar pessoas:

LOW
MEDIUM
HIGH

O modelo moderno procura compreender situações:

CUSTOMER
+
TRANSACTION
+
DEVICE
+
LOCATION
+
TIME
+
BEHAVIOR
+
HISTORY
+
RELATIONSHIPS

E calcula novamente quando o contexto muda.

Isso muda também a relação entre segurança e negócio.

Um bom cliente realizando uma operação compatível com seu comportamento pode receber menos atrito.

Uma pequena anomalia pode receber monitoramento.

Uma situação intermediária pode receber autenticação adicional.

Uma sequência altamente suspeita pode ser bloqueada ou enviada para investigação.

Portanto:

RISK ≠ BLOCK

Risk é informação para decidir qual controle é proporcional à situação.

É isso que torna o Risk Scoring moderno tão interessante para fintechs, bancos, adquirentes, sistemas de cartões e arquiteturas de pagamentos.

A missão não é bloquear o maior número possível de transações.

É algo muito mais difícil:

bloquear Diabolik sem impedir João de comprar o jantar.

E existe uma ironia maravilhosa nisso.

Diabolik passou décadas aperfeiçoando máscaras, identidades falsas, disfarces e planos perfeitos.

No mundo digital, porém, talvez ele encontre um adversário diferente.

Não uma câmera procurando seu rosto.

Não um policial procurando seu nome.

Não um cadastro perguntando quem ele diz ser.

Mas um Risk Engine silencioso perguntando:

Você possui as credenciais de João.

Você conhece os dados de João.

Você entrou na conta de João.

Mas...

por que não está se comportando como João?

No outro lado da tela, Ginko sorri.

O RISK-SCORE muda:

17
29
46
68
94

Diabolik aperta ENTER.

O mainframe responde:

TRANSACTION DECLINED

REASON:
BEHAVIORAL RISK

RETURN-CODE: 08

E em algum lugar do data center, provavelmente ao lado de um programa COBOL que ninguém ousa recompilar desde 1997, o JOB continua EXECUTING.

Porque no Risk Scoring moderno, o crime perfeito não precisa deixar uma impressão digital.

Basta deixar uma anomalia. ☕🕶️💻



terça-feira, 22 de outubro de 2024

Percy Jackson Entra no CPD — O Dia em que o Oráculo Mandou Buscar um Documento e o RAG Trouxe um Manual de Impressora de 2007

 

Bellacosa Mainframe apresenta o RAG

☕ Um Café no Bellacosa Mainframe

Percy Jackson Entra no CPD — O Dia em que o Oráculo Mandou Buscar um Documento e o RAG Trouxe um Manual de Impressora de 2007

Ou: por que embeddings, chunking, vector databases, BM25, reranking, metadata, grounding, observabilidade, RACF e LLMs formam uma expedição digna do Acampamento Meio-Sangue — e por que o melhor modelo do mundo continua perdido se Hermes entregar o mapa errado



Prólogo — O chamado do Oráculo

Era uma noite aparentemente normal no CPD.

As luzes verdes piscavam, o JES2 trabalhava em silêncio, algum batch estava atrasado desde antes do jantar e alguém certamente havia deixado um café esquecido ao lado de um terminal 3270.

Foi quando Percy Jackson entrou pela porta.

Espada na cintura.

Expressão de quem já tinha enfrentado monstros demais para se impressionar com um S0C7.

Atrás dele vinham Annabeth, com um notebook debaixo do braço, e Grover, que olhava desconfiado para os cabos de fibra óptica como se fossem serpentes particularmente nervosas.

O Oráculo havia dado uma missão:

“Pergunte ao sistema onde está o procedimento para resolver o incidente.”

Percy aproximou-se do novo chatbot corporativo.

Digitou:

Como resolver o ABEND S0C7 do programa CLIENT01?

O sistema pensou alguns segundos.

E respondeu magnificamente:

“Para substituir o toner da impressora LaserJet instalada no prédio administrativo...”

Silêncio.

Percy olhou para Annabeth.

Annabeth olhou para mim.

Eu olhei para o RACF, porque em situações verdadeiramente inexplicáveis alguém sempre termina olhando para o RACF.

Grover perguntou:

— Isso é uma alucinação?

Respondi:

— Talvez. Mas antes de culpar Zeus, precisamos verificar se Hermes não entregou o pergaminho errado.

E assim começava nossa aventura pelo estranho mundo do RAG.


1. Antes de enfrentar a Hidra: o que é RAG?

RAG significa:

Retrieval-Augmented Generation.

Em português:

Geração Aumentada por Recuperação.

O nome parece complicado, mas a ideia fundamental é relativamente simples.

Um modelo de linguagem possui conhecimento adquirido durante seu treinamento.

Porém uma empresa precisa frequentemente perguntar coisas que o modelo não conhece:

  • procedimentos internos;

  • documentação privada;

  • tickets;

  • contratos;

  • código-fonte;

  • runbooks;

  • manuais específicos;

  • regras atualizadas;

  • dados recentes;

  • documentação de determinado ambiente.

Não faz sentido treinar novamente um gigantesco modelo toda vez que alguém altera um procedimento.

Então fazemos outra coisa.

Quando o usuário pergunta algo, procuramos primeiro os documentos relevantes.

Depois entregamos esses documentos ao LLM.

A arquitetura simplificada fica assim:

Usuário
   |
   v
Pergunta
   |
   v
Retriever
   |
   v
Documentos relevantes
   |
   v
LLM
   |
   v
Resposta

Percy imediatamente resumiu:

— Então é como receber informações antes da missão.

Exatamente.

O LLM é o herói.

O RAG é quem fornece:

  • mapa;

  • relatório;

  • pistas;

  • pergaminhos;

  • localização do monstro;

  • instruções sobre como não morrer.

O problema começa quando o sistema entrega o mapa de Atenas para quem precisa chegar a Manhattan.


2. A primeira grande regra do RAG

Existe um velho princípio da computação:

Garbage In → Garbage Out

Lixo entra.

Lixo sai.

Mas com inteligência artificial generativa o problema ganhou uma variante ainda mais interessante:

Garbage Retrieved
       ↓
Plausible Garbage Generated

Ou seja:

lixo recuperado → lixo elegantemente escrito.

E essa segunda versão é muito mais perigosa.

Um programa COBOL tradicional normalmente é menos teatral.

Se receber dado inválido, pode produzir:

S0C7

O LLM talvez diga:

“Certamente! Com base nas informações fornecidas...”

e em seguida contar uma história completamente errada com segurança suficiente para convencer alguém.

É por isso que:

qualidade do retrieval acaba se tornando qualidade do sistema.


3. O Labirinto de Dédalo: como os documentos entram no RAG

Antes de consultar documentos, precisamos preparar nossa base de conhecimento.

Imagine termos:

COBOL Programming Guide.pdf
CICS Operations Manual.pdf
RACF Procedures.docx
RUNBOOK-PROD.txt
Tickets.xlsx
JCL.zip
KnowledgeBase.html

Não podemos simplesmente jogar tudo dentro do LLM.

Primeiro acontece um processo parecido com:

Documentos
    |
    v
Parsing
    |
    v
Limpeza
    |
    v
Chunking
    |
    v
Embeddings
    |
    v
Indexação
    |
    v
Vector Database

Cada etapa pode destruir silenciosamente a qualidade da próxima.

Essa é uma ideia importantíssima.

Uma falha em produção muitas vezes nasce muito antes do prompt.


4. Chunking — quando Cronos corta o documento em pedaços

Chegamos ao famoso chunking.

Um documento de 300 páginas normalmente é grande demais para ser tratado como uma única unidade de recuperação.

Então o dividimos.

Cada pedaço é chamado de:

chunk.

Imagine:

Manual CICS
    |
    +-- Chunk 001
    +-- Chunk 002
    +-- Chunk 003
    +-- Chunk 004
    ...

Até aí tudo ótimo.

O problema surge quando alguém decide:

“Vamos cortar de 500 em 500 caracteres.”

Cronos provavelmente aprovaria.

Ele tinha uma certa paixão por cortar coisas.

Mas semanticamente isso pode produzir desastres.

Considere:

CAPÍTULO 7
Diagnóstico do S0C7

O ABEND S0C7 normalmente ocorre quando...

Um chunker burro pode criar:

Chunk 1:
CAPÍTULO 7
Diagnóstico do

e:

Chunk 2:
S0C7

O ABEND S0C7 normalmente ocorre...

Perdemos relacionamento entre título e conteúdo.

Pior ainda com COBOL:

IF WS-STATUS = 'A'
    PERFORM PROCESS-A
ELSE
    PERFORM PROCESS-B
END-IF

Imagine cortar exatamente depois de PROCESS-A.

Um chunk conteria:

IF WS-STATUS = 'A'
    PERFORM PROCESS-A

Outro:

ELSE
    PERFORM PROCESS-B
END-IF

Individualmente, nenhum representa corretamente a lógica.

A lição de Annabeth

Chunking não deveria perguntar apenas:

“Quantos caracteres cabem?”

Deveria perguntar:

“Qual é a unidade semântica deste conteúdo?”

Para texto:

  • seção;

  • subtítulo;

  • parágrafo;

  • tópico.

Para código:

  • programa;

  • função;

  • método;

  • paragraph COBOL;

  • copybook;

  • procedure.

Para contratos:

  • cláusula;

  • seção;

  • artigo.

Para tickets:

  • descrição;

  • diagnóstico;

  • solução.

Ou seja:

conteúdo diferente exige estratégia diferente.


5. Embeddings — transformando palavras em coordenadas mágicas

Depois do chunking entram os embeddings.

Embeddings transformam texto em vetores numéricos.

Simplificando brutalmente:

"S0C7 COBOL data exception"

poderia virar algo conceitualmente semelhante a:

[0.122, -0.883, 0.431, 0.221 ...]

Outro texto:

"numeric field contains invalid data"

também será transformado em um vetor.

Se os conceitos forem parecidos, seus vetores tendem a ficar próximos em um espaço matemático multidimensional.

É quase como se cada documento recebesse coordenadas no mapa do Acampamento Meio-Sangue.

Quando o usuário faz uma pergunta, ela também vira vetor.

Então procuramos os vetores mais próximos.

Isso se chama:

semantic search.


6. Cuidado: similaridade não é relevância

Este é um dos maiores monstros escondidos no matagal.

Uma consulta:

Como corrigir um S0C7?

pode recuperar:

Documento 1:
Introdução aos ABENDs COBOL

Documento 2:
Lista histórica de S0C7 ocorridos

Documento 3:
Procedimento passo a passo para diagnosticar S0C7

Todos são semanticamente semelhantes.

Mas apenas o terceiro responde realmente à pergunta.

Portanto:

similaridade ≠ utilidade

É aí que entra o reranking.


7. Reranking — Annabeth reorganiza os pergaminhos

Imagine o vector search encontrando 50 candidatos.

100.000 chunks
     |
     v
Vector Search
     |
     v
Top 50

Agora um reranker examina melhor esses resultados.

Top 50
   |
   v
Reranker
   |
   v
Top 5

O primeiro estágio busca candidatos rapidamente.

O segundo tenta escolher os realmente úteis.

Percy perguntou:

— Então o primeiro encontra quem pode saber alguma coisa e o segundo escolhe quem deveria falar?

Perfeito.

Isso é bastante próximo da função.


8. Primeiro sinal de perigo: contexto irrelevante

Um RAG mal configurado começa frequentemente recuperando documentos errados.

Pergunta:

Como diagnosticar SQLCODE -805?

Resultados:

Db2 Bind Package
Db2 Introduction
TCP/IP Guide
CICS Installation
Printer Setup

É claramente ruim.

Mas casos reais são mais sutis.

Talvez todos os documentos sejam sobre Db2.

Mesmo assim apenas um explica -805.

A equipe olha o resultado e pensa:

“Tudo relacionado ao Db2. Está funcionando.”

Não necessariamente.

O retrieval precisa encontrar a informação correta, não simplesmente o mesmo assunto.


9. Segundo sinal: respostas frequentemente alucinadas

Muita gente começa culpando imediatamente o LLM.

— O modelo é ruim.

Talvez.

Mas façamos a pergunta certa:

Que contexto o modelo recebeu?

Imagine a pergunta:

Qual alteração foi feita no programa FATURA01 ontem?

O RAG recupera:

Manual FATURA01 - 2024

Mas não encontra:

CHANGE-20260904
Commit 4839
Ticket CHG88213

Agora o modelo possui informação sobre FATURA01.

Só não possui a informação pedida.

Ele pode:

  1. recusar responder;

  2. dizer que não encontrou evidência;

  3. solicitar mais contexto;

  4. inventar.

O número quatro produz aquilo que chamamos de alucinação.

Por isso, RAG bem projetado precisa permitir:

Evidence insufficient

Em português de CPD:

“Não achei dado suficiente para responder com segurança.”

Isso é muito melhor que fabricar um diagnóstico.


10. A caixa de Pandora chamada contexto gigante

Outro erro comum:

“Vamos enviar tudo ao modelo.”

Temos hoje modelos capazes de lidar com grandes context windows.

Ótimo.

Mas capacidade não é obrigação.

Imagine mandar 150 chunks para responder:

Qual parâmetro controla timeout?

É como Percy perguntar onde fica a espada e alguém entregar todo o inventário do Acampamento desde 1984.

A informação existe.

Mas está enterrada.

Contextos gigantes causam:

  • mais tokens;

  • maior custo;

  • maior latência;

  • redundância;

  • evidências conflitantes;

  • queda de relação sinal/ruído.

Uma regra útil é:

O contexto ideal não é o maior. É o menor conjunto de informações suficiente para responder corretamente.

No mainframe já aprendemos isso com spool.

Você não quer oito mil linhas.

Quer as vinte linhas em volta da mensagem que explica o problema.


11. Missing Key Documents — quando Hermes esquece o pergaminho importante

Agora acontece o contrário.

O retrieval encontra resultados excelentes.

Mas deixa o documento decisivo de fora.

Pergunta:

Qual versão de Enterprise COBOL roda em PROD?

RAG encontra:

COBOL Programming Guide 6.3
COBOL Migration Guide 6.5
COBOL Language Reference

Tudo excelente.

Mas o documento necessário era:

PROD_SOFTWARE_INVENTORY
Enterprise COBOL 6.5

Temos documentos muito bons que não respondem à pergunta.

Esse problema nos leva a recall.


12. Precision e Recall — duas criaturas que precisam viver juntas

Dois conceitos são fundamentais.

Precision

Dos documentos recuperados, quantos são relevantes?

Imagine recuperar 10.

Oito úteis.

Precision ≈ 80%

Recall

De todos os documentos relevantes existentes, quantos foram encontrados?

Existiam 20 documentos úteis.

Você encontrou 8.

Recall ≈ 40%

Pode existir um sistema com alta precision e péssimo recall.

Ele encontra coisas boas.

Mas deixa muita coisa boa de fora.

Annabeth provavelmente exigiria medir ambos antes de liberar a missão para produção.


13. Contexto duplicado — a Hidra dos PDFs

Você indexa:

procedure.pdf
procedure_final.pdf
procedure_final_v2.pdf
procedure_aprovado.pdf
procedure_backup.pdf

O mesmo texto existe cinco vezes.

O retriever retorna:

Top 5:

Documento A
Documento B
Documento C
Documento D
Documento E

Parece ótimo.

Cinco resultados relevantes!

Mas na realidade temos:

1 informação × 5 cópias

Gastamos contexto sem adicionar conhecimento.

Existe também um risco adicional.

Se determinada afirmação aparece em cinco documentos duplicados, o modelo pode interpretá-la como fortemente corroborada.

Quando na verdade existe uma única fonte copiada cinco vezes.

Daí a importância de:

  • deduplicação;

  • hashing;

  • identificação canônica;

  • versionamento;

  • filtros;

  • diversidade dos resultados.


14. Metadata — os rótulos que salvam expedições

Embeddings são poderosos.

Mas não devemos obrigá-los a resolver todo problema possível.

Imagine:

CICS_Guide_5.6
CICS_Guide_6.1
CICS_Guide_6.3

Pergunta:

Como funciona no CICS TS 6.1?

Semanticamente, os três manuais podem ser praticamente irmãos.

Metadata permite dizer:

product = CICS
version = 6.1
document_type = manual
language = EN

Em uma empresa poderíamos ter:

application = BILLING
environment = PROD
region = BRAZIL
version = 4.2
valid_from = 2026-01-01
valid_until = NULL
classification = INTERNAL
owner = APPLICATION_TEAM

Isso muda tudo.

RAG corporativo sem boa metadata muitas vezes acaba tentando usar inteligência artificial para compensar algo que deveria ter sido resolvido com organização básica da informação.

Quem trabalhou com Db2 já conhece essa música.


15. O monstro invisível: documento velho

Esse merece destaque especial.

Imagine:

RUNBOOK_2023
RUNBOOK_2024
RUNBOOK_2025
RUNBOOK_2026

Os quatro falam exatamente do mesmo problema.

Vector search pode considerar todos altamente relevantes.

Mas apenas o de 2026 ainda vale.

Se o sistema recuperar 2023, o LLM poderá:

  • entender corretamente;

  • citar corretamente;

  • resumir corretamente;

  • responder fielmente.

E ainda assim produzir uma resposta operacionalmente errada.

Temos então uma lição importantíssima:

Grounded não significa automaticamente verdadeiro.

Grounding significa que a resposta está sustentada pelo contexto fornecido.

Se o contexto está obsoleto, você obtém uma resposta perfeitamente sustentada por informação vencida.

É quase um RC=0000 executando o JCL errado.


16. Hybrid Search — Atena não joga fora ferramentas úteis

Existe uma tentação de tratar vector search como solução universal.

Não é.

Mainframe oferece ótimo exemplo.

Considere:

ICH408I
IEC141I
DFHAC2001
SQLCODE -805
S0C7
IGD17272I

Esses códigos têm valor literal enorme.

Quando pergunto:

ICH408I

não quero apenas algo conceitualmente semelhante a ICH408I.

Quero documentos contendo:

ICH408I

Por isso muitos sistemas combinam:

Vector Search
      +
Keyword Search
      =
Hybrid Search

Busca vetorial entende conceitos.

Busca lexical encontra termos específicos.

Um mecanismo tradicional como BM25 continua extremamente útil.

Tecnologia nova não torna automaticamente toda tecnologia anterior inútil.

Quem trabalha com mainframe deveria ser imune a essa ilusão.

COBOL está nos ensinando isso há mais de seis décadas.


17. Query rewriting — o Oráculo interpreta a pergunta

Usuário escreve:

Por que caiu?

Excelente pergunta para um humano que acompanhou a conversa inteira.

Péssima consulta isolada para um mecanismo de retrieval.

Talvez o sistema reescreva:

Qual foi a causa do ABEND da transação CICS XYZ
em PROD discutida anteriormente?

Agora retrieval possui contexto suficiente.

Essa técnica é chamada frequentemente de:

query rewriting.

Ela pode melhorar enormemente a recuperação.

Mas introduz novo risco.

Se o rewriter entender errado:

usuário
  |
  v
query rewrite errado
  |
  v
retrieval perfeito para a pergunta errada

Fantástico.

O sistema encontra exatamente aquilo que ninguém perguntou.


18. Latência — Quíron começa a olhar o relógio

Tudo funciona na demonstração.

Uma pessoa usando.

Dez documentos.

Banco vetorial pequeno.

Resposta em dois segundos.

Então chega produção.

Agora temos:

Query
  |
  v
Intent detection
  |
  v
Query rewriting
  |
  v
Embedding
  |
  v
Vector search
  |
  v
BM25
  |
  v
Metadata filters
  |
  v
Reranking
  |
  v
Document fetching
  |
  v
Context construction
  |
  v
LLM

Cada estágio acrescenta tempo.

Exemplo:

Query processing        70 ms
Embedding              120 ms
Vector search          240 ms
Keyword search         150 ms
Reranking              550 ms
Document fetch         210 ms
LLM                   2100 ms
--------------------------------
Total                 3440 ms

Se o usuário reclama:

“A IA está lenta.”

A culpa talvez nem esteja no modelo.

Isso é exatamente como:

“O CICS está lento.”

Pode ser:

CICS
 ↓
Db2
 ↓
MQ
 ↓
Rede
 ↓
API
 ↓
Serviço externo

Observabilidade existe justamente para separar impressão de evidência.


19. No Retrieval Evaluation — “aqui funcionou” não é métrica

Esse talvez seja o pecado mais grave de todos.

Equipe testa assim:

Pergunta 1.

Boa resposta.

Pergunta 2.

Boa resposta.

Pergunta 3.

Mais ou menos.

Pergunta 4.

Boa.

Resultado:

“Pode subir.”

Quíron teria expulsado metade da equipe de treinamento por menos.

Precisamos separar:

Retrieval Evaluation

de:

Generation Evaluation

Uma resposta correta não prova que o retrieval está funcionando.

Talvez o LLM simplesmente já soubesse a resposta.

Esse é um caso extremamente traiçoeiro.

O RAG falhou.

O modelo salvou.

Todos comemoraram.

Até chegar a pergunta interna que o modelo realmente não conhece.


20. Métricas para quem não quer administrar IA no horóscopo

Dependendo do projeto, podemos acompanhar:

Precision@K
Recall@K
Hit Rate
MRR
NDCG
Context relevance
Answer relevance
Faithfulness
Citation correctness
Latency
Tokens/query
Cost/query

Não é obrigatório usar todas.

Mas é obrigatório abandonar:

“Parece bom.”

Produção precisa de alguma forma de medição.

Mainframe conhece isso muito bem.

Temos:

  • SMF;

  • RMF;

  • OMEGAMON;

  • SDSF;

  • logs;

  • traces;

  • accounting;

  • performance metrics.

Imagine operar uma LPAR dizendo:

“A CPU me parece simpática hoje.”

RAG precisa adquirir a mesma maturidade.


21. Observabilidade — Argos ganha mil olhos digitais

Em mitologia grega, Argos Panoptes possuía muitos olhos.

É praticamente o mascote oficial da observabilidade.

Um RAG sério deveria conseguir registrar pelo menos:

Query original
Query transformada
Documentos candidatos
Scores
Filtros aplicados
Reranking
Chunks enviados
Tokens
Latência por etapa
Resposta
Citações
Erros

Quando algo dá errado, queremos reconstruir a jornada.

Pergunta:

“Por que o chatbot deu essa resposta?”

Resposta ruim:

“Porque inteligência artificial é probabilística.”

Resposta boa:

Query = X
Retriever encontrou A/B/C
Documento A estava desatualizado
Reranker colocou A em primeiro
LLM usou trecho Y
Resposta resultante foi Z

Agora temos engenharia.


22. Segurança — Hades também possui documentos

Chegamos a um assunto que muitos projetos descobrem tarde demais.

Imagine um RAG indexando:

RH
Financeiro
Contratos
Código-fonte
Incidentes
Runbooks
Folha salarial
Documentação pública
Documentação confidencial

Usuário pergunta:

Qual é o salário do diretor?

O vector database encontra imediatamente.

Excelente recall!

Péssima segurança.

O retrieval deveria obedecer autorização.

Arquitetura:

Identity
   |
   v
Authorization
   |
   v
Allowed Corpus
   |
   v
Retrieval
   |
   v
LLM

Quem trabalha com RACF entende isso instantaneamente.

Pergunta errada:

“O dataset existe?”

Pergunta certa:

“Esse usuário possui acesso ao dataset?”

No mundo RAG:

Não basta saber onde está o conhecimento. Precisamos saber quem pode recuperá-lo.


23. Percy conhece o RACF

Percy olhou a arquitetura.

— Então antes de abrir o pergaminho precisamos saber se eu posso lê-lo?

Sim.

Ele sorriu.

— Isso parece o acampamento.

Eu respondi:

— Isso parece RACF.

E provavelmente nenhum de nós estava errado.


24. Uma arquitetura RAG mais próxima da realidade

Depois de juntar os pedaços, nosso sistema começa a parecer assim:

                 USER
                   |
                   v
            Authentication
                   |
                   v
             Authorization
                   |
                   v
          Query Understanding
              /         \
             /           \
    Query Rewrite       Intent
             \           /
              \         /
                   |
                   v
             Hybrid Search
             /           \
            /             \
      Vector              BM25
            \             /
             \           /
                   |
                   v
            Metadata Filter
                   |
                   v
               Reranker
                   |
                   v
             Deduplication
                   |
                   v
             Context Builder
                   |
                   v
                  LLM
                   |
                   v
          Grounding Validation
                   |
                   v
               Citations
                   |
                   v
                 USER

Atrás de tudo:

LOGS
METRICS
TRACES
SECURITY
EVALUATION
VERSIONING

Isso já parece muito menos “chatbot”.

E muito mais:

sistema corporativo distribuído.


25. Um exemplo completo: o Oráculo COBOL

Vamos construir mentalmente um RAG para programadores COBOL iniciantes.

Base:

IBM Documentation
Redbooks
COBOL manuals
CICS manuals
Db2 manuals
RACF procedures
JCL examples
Copybooks
Programs
Tickets
Runbooks
Incident reports

Usuário pergunta:

“Meu programa terminou com S0C7 depois de ler o arquivo. O que verifico?”

RAG ruim:

Introdução ao COBOL
Lista geral de ABENDs
Manual do JES2
Introdução ao VSAM
Documento de JCL

O LLM tenta montar alguma coisa.

RAG melhor:

1. Definição oficial de S0C7
2. Copybook do arquivo
3. Layout atual
4. Programa COBOL
5. Runbook de data exception
6. Ticket antigo do mesmo programa

Agora é possível correlacionar:

Arquivo
   |
   v
Layout
   |
   v
PIC
   |
   v
Dado inválido
   |
   v
Operação numérica
   |
   v
S0C7

Aqui a IA começa realmente a parecer útil.

Não porque “sabe COBOL magicamente”.

Mas porque recebeu as evidências certas.


26. O grande paradoxo: modelo menor, sistema melhor

Considere dois projetos.

Projeto A

Modelo gigantesco
Vector search básico
Chunking ruim
Sem metadata
Sem reranking
Sem avaliação

Projeto B

Modelo menor
Chunking semântico
Hybrid search
Metadata correta
Reranking
Deduplicação
Avaliação contínua
Grounding
Observabilidade

Para perguntas sobre conhecimento corporativo, B pode vencer facilmente.

Essa é uma lição importantíssima.

A escolha do LLM é importante.

Mas o LLM não é o sistema inteiro.

Isso lembra um iniciante em COBOL imaginando que performance de uma aplicação depende apenas do programa.

Então descobre:

  • arquivo;

  • índice;

  • Db2;

  • locking;

  • buffer;

  • CICS;

  • MQ;

  • rede;

  • WLM;

  • I/O.

Bem-vindo à engenharia.


27. Um passo a passo para diagnosticar RAG

Se amanhã alguém disser:

“Nosso RAG está ruim.”

Não comece trocando de modelo.

Faça algo semelhante a isto:

Passo 1 — Examine perguntas reais

Colete consultas reais ou representativas.

Passo 2 — Defina a resposta esperada

Crie ground truth quando possível.

Passo 3 — Identifique documentos corretos

Quais fontes deveriam ser recuperadas?

Passo 4 — Rode apenas o retrieval

Ignore o LLM inicialmente.

Veja:

Top 1
Top 3
Top 5
Top 10

Passo 5 — Meça

Precision.

Recall.

Hit Rate.

Ranking.

Passo 6 — Examine chunking

A informação está inteira no chunk?

Passo 7 — Examine metadata

Versão?

Ambiente?

Produto?

Data?

Permissão?

Passo 8 — Procure duplicação

Cinco resultados são realmente cinco fontes?

Passo 9 — Analise latência

Quanto tempo cada estágio demora?

Passo 10 — Somente depois avalie geração

Agora verifique:

  • fidelidade;

  • citações;

  • hallucination;

  • clareza;

  • cobertura.

Esse passo a passo evita um erro caríssimo:

tentar corrigir retrieval ruim com prompt engineering.


28. O Easter Egg de 1960

Aqui vai um segredo escondido no Templo de Atena.

Muito do que estamos descobrindo em RAG parece revolucionário.

Mas vários problemas são versões modernas de questões antigas:

Índice ruim
Dados duplicados
Registro desatualizado
Chave errada
Acesso indevido
Consulta lenta
Falta de métrica

Isso existia antes de LLM.

Antes de vector database.

Antes de cloud.

Antes de muita gente nascer.

O formato mudou.

Os fundamentos resistiram.


29. Daí nasce a verdadeira frase do artigo

A imagem dizia essencialmente:

Retrieval quality becomes system quality.

Eu ampliaria:

Knowledge Quality
        ×
Chunking
        ×
Embeddings
        ×
Retrieval
        ×
Ranking
        ×
Metadata
        ×
Context
        ×
Generation
        ×
Grounding
        ×
Security
        ×
Observability
        =
RAG Quality

Usei multiplicação deliberadamente.

Imagine:

Security = 0

Sistema inaceitável.

Imagine:

Retrieval = 0

O LLM fica praticamente sozinho.

Imagine:

Knowledge Quality = 0

Agora construímos a mais sofisticada máquina do planeta para localizar lixo com velocidade impressionante.

Parabéns.

O projeto possui embeddings de última geração para encontrar documentação errada em 37 milissegundos.


30. Curiosidade: retrieval também possui “ABEND silencioso”

COBOL oferece uma vantagem psicológica maravilhosa.

Quando algo explode, frequentemente percebemos:

ABEND
SQLCODE
FILE STATUS
RETURN CODE

RAG pode falhar silenciosamente.

Ele recupera o documento errado.

LLM responde.

Usuário aceita.

Nenhum erro técnico ocorre.

Nenhum RC=12.

Nenhum dump.

Nenhuma tela vermelha.

Talvez seja o tipo mais perigoso de falha.

Podemos chamá-la informalmente de:

RC=0000
BUSINESS RESULT=WRONG

Quem trabalhou em produção sabe exatamente o terror contido nessa frase.


31. Percy encontra o Minotauro chamado “prompt engineering”

No centro do labirinto havia finalmente o Minotauro.

Em sua camiseta estava escrito:

PROMPT ENGINEERING RESOLVE TUDO

Percy ergueu Contracorrente.

Annabeth segurou seu braço.

— Não precisamos matar esse.

Ela explicou:

Prompt engineering é útil.

Muito útil.

Mas ele não pode corrigir:

  • documento inexistente;

  • chunk quebrado;

  • índice errado;

  • versão obsoleta;

  • ACL ausente;

  • retrieval ruim;

  • duplicação;

  • metadata ausente.

Você pode escrever:

“Responda apenas usando informações corretas e atualizadas.”

Se o único documento enviado é incorreto e antigo, o prompt não possui poderes divinos para teleportar o documento certo.


32. RAG começa a parecer SRE

Quando RAG vai para produção, precisamos pensar em:

availability
latency
accuracy
recall
cost
security
freshness
traceability

Podemos até imaginar SLOs:

Recall@10              > 95%
Citation correctness   > 98%
P95 retrieval latency  < 500ms
P95 total latency      < 4s
Duplicate context      < 5%
Unauthorized retrieval = 0

Agora aquela frase:

“A IA está pior hoje.”

pode virar:

“Recall@10 caiu de 96% para 81% depois da nova indexação.”

Essa é a diferença entre impressão e engenharia.


33. A regra Bellacosa para RAG

Se eu tivesse que deixar uma regra simples para um programador COBOL iniciante entrando nesse universo, seria esta:

Antes de perguntar se a IA sabe responder, pergunte se o sistema encontrou aquilo que ela precisava saber.

Quando vier uma resposta ruim, examine nesta ordem:

Fonte
 ↓
Chunk
 ↓
Embedding
 ↓
Retrieval
 ↓
Filter
 ↓
Ranking
 ↓
Context
 ↓
LLM

Não comece obrigatoriamente pelo último componente.

É o equivalente a trocar o programa COBOL porque o arquivo de entrada veio errado.

Às vezes o programa estava inocente.


34. O que Percy Jackson aprendeu no CPD

Ao final da noite, Percy perguntou novamente:

Como diagnosticar o ABEND S0C7 do CLIENT01?

Dessa vez o sistema recuperou:

CLIENT01.cbl
CLIENT01.cpy
FILE-LAYOUT-V7
S0C7-RUNBOOK
INCIDENT-2026-041
IBM COBOL documentation

A resposta explicou que o programa movimentava determinado campo para uma variável numérica e recomendou verificar o conteúdo real do registro, layout, definição PIC e ponto da operação.

Percy assentiu.

— Agora parece uma resposta.

Annabeth olhou os resultados recuperados.

— Agora parece uma arquitetura.

Grover perguntou:

— E agora podemos ir embora?

Não.

Havia um MAXCC=12 no batch noturno.


Epílogo — Os deuses também precisam de índices

Percy Jackson entrou no CPD imaginando que inteligência artificial era o herói desta história.

Saiu entendendo que o herói depende profundamente de quem fornece as pistas.

Um RAG não é apenas:

pergunta → IA → resposta

É uma cadeia inteira de decisões:

Qual documento?
Qual versão?
Qual pedaço?
Qual embedding?
Qual índice?
Qual consulta?
Qual filtro?
Qual ranking?
Qual contexto?
Qual permissão?
Qual evidência?
Qual resposta?

E qualquer etapa pode comprometer tudo o que vem depois.

Talvez por isso profissionais antigos de mainframe tenham uma vantagem curiosa ao estudar GenAI.

Nós já vimos sistemas aparentemente mágicos se tornarem problemas absolutamente mundanos assim que entram em produção.

Descobrimos que por trás da magia sempre aparecem:

  • índices;

  • dados;

  • versões;

  • autorização;

  • performance;

  • logs;

  • métricas;

  • auditoria;

  • capacidade;

  • disponibilidade.

Os deuses mudam.

Os monstros recebem nomes novos.

O Labirinto ganha banco vetorial.

O Oráculo agora atende por LLM.

Mas o fundamento permanece.

Quando uma inteligência artificial corporativa responde alguma coisa, a pergunta mais importante talvez nem seja:

“Qual modelo respondeu?”

Talvez seja:

“Quem trouxe os pergaminhos que ele leu?”

Porque, no fim das contas, até o filho de Poseidon sabe que uma missão começa antes da espada sair da bainha.

Ela começa com o mapa certo.

E, no RAG, retrieval é o mapa.

Se o mapa estiver errado, podemos ter o melhor herói do mundo caminhando com enorme competência exatamente na direção do monstro errado.

☕ Bem-vindo ao Bellacosa Mainframe. Aqui até Percy Jackson aprendeu que antes de enfrentar a Hidra é melhor conferir o índice, o FILE STATUS e se Hermes não entregou o PDF errado.

segunda-feira, 21 de outubro de 2024

A Lanterna de Diógenes, a Vaga de Medicina e o Hambúrguer Vegano de Boutique

 

Bellacosa Mainframe desconfiado com hamburguer veganos e as cotas com brechas legais

☕ Um Café no Bellacosa Mainframe

A Lanterna de Diógenes, a Vaga de Medicina e o Hambúrguer Vegano de Boutique

Ou: quando o filósofo cínico entrou numa hamburgueria sem boi, olhou a embalagem, perguntou quem pagou o cursinho e descobriu que princípios também precisam de auditoria

Há conversas que começam com uma pessoa e terminam num espelho. A personagem desta história poderia ser uma jovem aplicada, inteligente, estudiosa, vegana convicta, defensora de inclusão racial, direitos LGBT+ e proteção dos animais. Poderia ser também um rapaz conservador, um executivo que fala de meritocracia, um sindicalista que condena privilégios alheios, ou o sujeito que faz discurso ecológico enquanto deixa a churrasqueira acesa a tarde inteira.

O caso particular importa menos que a pergunta que ele provoca: o que acontece quando nossos princípios encontram exatamente o privilégio que nos beneficia?

Para responder, vamos convidar Diógenes de Sinope. O filósofo grego é famoso por morar num tonel, provocar os poderosos e andar de dia com uma lanterna procurando, segundo a tradição, “um homem honesto”. Não é um modelo completo de vida — ele podia ser deliberadamente desagradável, e ninguém precisa abandonar o banho, a casa e a civilização para ter ética. Mas a lanterna dele continua útil: ela não pergunta qual causa está impressa na camiseta; ela ilumina aquilo que a pessoa não quer ver em si mesma.

E, se Diógenes aparecesse em 2024 numa conversa brasileira, provavelmente não começaria perguntando se você come carne. Perguntaria: “quem paga sua coerência?”


1. Princípio não é uniforme moral

Ter princípios é uma coisa admirável. Defender animais contra crueldade, combater racismo, rejeitar discriminação contra pessoas LGBT+, preocupar-se com o ambiente: tudo isso pode nascer de empatia real. O problema não é acreditar muito em algo. O problema começa quando a convicção vira salvo-conduto para deixar de examinar as próprias escolhas.

Existe uma diferença enorme entre dizer “eu não como animais porque isso fere minha consciência” e dizer “quem come é moralmente inferior e precisa ser convertido”. A primeira frase descreve uma decisão pessoal. A segunda inaugura uma hierarquia religiosa, mesmo quando a religião se apresenta como consciência política.

O termo carnismo, ou pejorativamente CARNISTA usado por parte do ativismo vegano para nomear a normalização cultural do consumo de carne, pode ter lugar numa discussão acadêmica. Em uma conversa de mesa, porém, ele frequentemente chega com a função prática de carimbar o interlocutor como réu. E quase ninguém aprende quando a conversa começa pela acusação. A reação comum é a reatância: quanto mais alguém tenta controlar sua escolha, mais você sente vontade de reafirmar sua liberdade — ainda que só de birra.

Daí a piada amarga: uma pessoa que queria diminuir o consumo de carne talvez consiga exatamente o contrário se usar o veganismo como megafone moral. Não porque a causa seja absurda, mas porque ninguém gosta de receber sermão durante o almoço.

Diógenes provavelmente beberia um gole de água, olharia para o pregador e perguntaria: “Você deseja aliviar sofrimento ou deseja vencer uma discussão?” São objetivos diferentes. O primeiro aceita diálogo, contradição e progresso imperfeito. O segundo precisa de pecadores para continuar existindo.

2. A vaga de cota e a diferença entre a lei e sua alma

Agora entra a universidade pública, especialmente medicina — a fila onde princípios abstratos passam a custar muito caro.

A Lei de Cotas reserva ao menos 50% das vagas das instituições federais para estudantes que fizeram integralmente o ensino médio em escola pública. Dentro dessa reserva, metade é destinada a famílias com renda de até um salário mínimo por pessoa. Há ainda recortes de pretos, pardos, indígenas, quilombolas e pessoas com deficiência conforme a composição populacional da unidade federativa. Desde a atualização de 2023, o candidato concorre primeiro na ampla concorrência; só se não entrar por ela é que passa às vagas reservadas.

Isso significa que a lei possui dois mecanismos ao mesmo tempo. Um deles é claramente econômico: pelo menos 25% do total de vagas é protegido para quem tem baixa renda per capita. O outro usa “ensino médio integral em escola pública” como sinal de desvantagem educacional — e esse sinal é útil na média, mas falha nos extremos.

Imagine duas candidatas à mesma vaga de medicina. A primeira sempre estudou em escola pública, trabalha ou ajuda em casa, teve acesso precário a computador, não fez cursinho caro e talvez tenha tentado o ENEM enquanto enfrentava transporte, renda curta e família sem formação universitária. A segunda é filha de pais com renda conjunta de cinquenta mil reais por mês. Estudou em colégio particular, fez inglês e cursinho de ponta; depois, por estratégia perfeitamente legal, passou todo o ensino médio numa escola pública, em paralelo estudou cursinho pré-vestibular e se tornou elegível à reserva sem critério de renda.

As duas cumpriram, em tese, o requisito escolar. Mas não carregaram a mesma vida até a prova.

Isso não autoriza chamar a segunda de fraudadora. Se a documentação é verdadeira, ela está dentro da lei. Pode ter estudado muito, falhado em tentativas anteriores, perseverado e finalmente alcançado uma nota alta. Mérito existe. Só que mérito nunca chega nu ao vestibular: ele chega de ônibus, com computador ou sem computador, depois de jornada de trabalho ou depois de cursinho, com pais que entendem o processo seletivo ou com pais que jamais tiveram contato com uma faculdade.

Há algo intelectualmente fraco em fingir que toda aprovação é só mérito individual; e há algo igualmente fraco em fingir que esforço não conta. A leitura adulta suporta as duas verdades. A jovem esforçou-se. E a estrutura familiar tornou possível que seu esforço fosse mais longo, mais protegido e melhor equipado.

O problema ético aparece quando alguém defensor da justiça distributiva trata essa vantagem como se ela não existisse. A lei pode permitir; a pergunta de Diógenes é se ela deveria querer usar a permissão. A regra tem letra. A política pública tem finalidade. Quando uma família muito rica planeja a rota escolar para entrar numa reserva concebida para compensar desigualdades, ela pode obedecer à letra e contrariar a finalidade.

3. A média nacional não é a fila de medicina

Aqui convém não cair em outro exagero. Não é correto imaginar que as federais inteiras foram sequestradas por jovens ricos fingindo ser pobres. A Pesquisa de Perfil Socioeconômico dos Graduandos das IFES, divulgada pela Andifes com dados de 2018, apontou que 70,2% dos alunos presenciais tinham renda familiar per capita de até um salário mínimo e meio; 60,4% haviam feito todo o ensino médio na rede pública; e 48,3% eram cotistas. É uma mudança social concreta no perfil das universidades federais.

Portanto, cotas não são uma farsa integral nem simples “lei para o meio”. Elas abriram a universidade para muitos jovens cuja família não teve universidade, renda estável ou capital cultural. Isso merece ser reconhecido sem asterisco maldoso.

Mas uma média de toda a universidade não responde à pergunta mais incômoda: como se distribuem renda, cursinho, tentativas de ENEM e origem escolar nas carreiras de altíssimo retorno? Medicina não é Letras. Odontologia em curso concorrido não é uma licenciatura que tem dificuldade até de completar a turma. Há cursos em que a vaga remanescente é um problema administrativo; há cursos em que um décimo na redação muda uma vida inteira.

Nas filas mais competitivas, a assimetria de preparação tende a pesar mais. Quem dispõe de dinheiro pode comprar anos adicionais de estudo, materiais, simulados, orientação, tranquilidade para não trabalhar e a possibilidade de errar uma, duas ou três vezes antes de acertar. Não é culpa individual possuir esses recursos. O ponto é não fingir que eles deixam de existir quando a pessoa preenche a modalidade “escola pública”.

Uma política mais precisa talvez mantivesse a reserva por escola pública, mas escalonaria renda e patrimônio de maneira mais fina; também poderia distinguir quem sempre dependeu da rede pública de quem entrou nela apenas como estratégia. Não para humilhar ninguém, mas para impedir que uma aproximação estatística se transforme num manual de planejamento para os já favorecidos.

4. O hambúrguer sem boi não vem sem mundo

Voltemos à mesa. A jovem vegana frequenta hamburguerias veganas caras, pizzarias veganas de boutique, casas japonesas veganas e compra produtos de marca, prontos, embalados, às vezes trazidos por longa cadeia de transporte. Isso invalida sua decisão de não consumir animais? Não. Um hambúrguer vegetal pode, sim, evitar a participação direta na criação e no abate de um boi. Se a prioridade moral dela é sofrimento animal, há coerência nessa escolha.

Mas isso não permite empacotar todas as virtudes numa mesma sacola de delivery.

“Vegano” responde principalmente à presença de ingredientes e exploração de origem animal. Não responde automaticamente a embalagem, refrigeração, consumo de energia, distância percorrida, precarização do entregador, ultraprocessamento, desperdício ou preço inacessível. Um produto pode ser vegano e ainda ser um pequeno monumento ao consumo premium contemporâneo.

Essa é a razão pela qual a expressão “vegana nutella” faz rir. Não porque cozinhar em casa seja requisito de pureza moral — nem todo mundo tem tempo, quintal ou vocação para virar agricultor. Ela aponta para outra coisa: a pessoa mantém intacto o modelo de consumo sofisticado, industrial, altamente embalado e identitário, mas passa a tratá-lo como superior em todos os eixos apenas porque retirou o animal da receita.

Diógenes não exigiria que todos plantassem grão-de-bico. Mas talvez perguntasse se a embalagem dourada, o delivery e o marketing de “consciência” são parte inevitável do princípio ou apenas o conforto que a pessoa não deseja sacrificar. A resposta honesta poderia ser: “Não consigo viver de modo ambientalmente perfeito; minha prioridade é o animal.” Pronto. É uma posição limitada, porém intelectualmente limpa.

O problema é reivindicar pureza total enquanto se recusa a auditar a própria pegada.

5. Carne, sangue e a bandeja que apaga o bicho

Também é fácil fazer moralidade abstrata com carne quando nunca se viu sua origem. Quem cresceu em casa onde se criava galinha ou porco e se abatia o animal para alimentação conhece uma verdade que a bandeja de supermercado tenta apagar: carne não nasce de isopor, plástico-filme e promoção de terça-feira.

Essa proximidade não torna o abate bonito nem obriga ninguém a aceitá-lo. Mas impede a fantasia higienizada. Uma pessoa pode comer carne e ainda defender criação decente, abate com menos sofrimento, fiscalização séria, menos desperdício e consumo menos automático. Pode também ser vegana e defender o fim de toda exploração animal. São posições opostas sobre o uso do animal, mas ambas podem ser éticas se encararem a realidade em vez de fingirem que ela não existe.

Há até uma correção curiosa: o líquido vermelho da carne não é “sangue” no sentido comum; o abate busca drenar o sangue. A cor vem sobretudo de água e mioglobina, proteína muscular. Mesmo assim, muita gente percebe que a carne moderna tem menos sabor, menos aroma e textura mais padronizada. Seleção por crescimento e rendimento, animais mais jovens e magros, dieta uniforme com milho e farelo de soja, embalagens a vácuo, congelamento e cortes com pouca gordura intramuscular ajudam a explicar a sensação. Gordura carrega sabor. A eficiência industrial frequentemente entrega previsibilidade, não memória afetiva.

E as palavras colaboram para esconder a origem. Dizemos “carne bovina”, “proteína animal”, “corte premium”, “blend”, “filé mignon”. Não são mentiras; são camadas de distância. No inglês, essa distância ficou gravada na história: o camponês anglo-saxão cuidava da cow, do pig e do sheep; a elite normanda comia beef, pork e mutton, palavras trazidas do francês. No português, não há divisão histórica tão profunda: boi e carne de boi, porco e carne de porco, coelho e coelho. “Bovino” e “suíno” vêm do latim e soam técnicos, não pertencem a outro povo conquistador. Nossa cortina é mais moderna: indústria, marketing e conforto psicológico.

6. O rato, a cidade e a ética que precisa escolher prioridades

Talvez o episódio mais instrutivo seja a briga com um comerciante que mata ratos no próprio estabelecimento. É fácil enxergar a compaixão: rato é animal, sente dor, não deveria sofrer gratuitamente. Mas uma ética que para aí não terminou o raciocínio. Há alimento, clientes, funcionários, doenças, contaminação e responsabilidade sanitária. A pergunta não é “ratos merecem tortura?” Claro que não. A pergunta é: quais métodos controlam a infestação com menor sofrimento e menor risco às pessoas?

É justamente aí que princípios saem do cartaz e entram no mundo. Uma posição madura não exige que o comerciante conviva com a praga em nome de uma pureza abstrata; exige prevenção, limpeza, barreiras, controle profissional e métodos proporcionais. Ética não é o prazer de apontar a crueldade de alguém. É carregar o peso das consequências quando todos os caminhos têm custo.

7. A auditoria que vale para todos — inclusive para nós

O erro mais fácil é transformar essa jovem numa vilã perfeita. Ela provavelmente não é, pelo contrario é uma das jovens mais adoraveis que conheci, uma pessoa impar pelo seu esforço, sagacidade e perseverança. Pode ter genuína compaixão por animais, ter estudado de verdade e acreditar sinceramente que fez o correto. Pessoas não são arquivos COBOL com um único IF determinando toda a personalidade. Somos sistemas legados: regras bonitas, remendos antigos, condições não documentadas e uma exceção escondida que só aparece em produção.

Mas a intenção boa não elimina a necessidade de revisão. E a revisão vale para todos nós.

Quem condena a jovem pela vaga de cota deve também perguntar que privilégios próprios trata como naturais. Quem ri do hambúrguer vegano de boutique deve examinar desperdício, origem da carne e escolhas de consumo. Quem defende a ampla concorrência precisa perguntar se sua definição de mérito inclui dinheiro comprado como “esforço”. Quem defende cotas precisa perguntar se a ferramenta está chegando primeiro a quem tem menos alternativas.

É a parte que Diógenes entendia melhor do que quase todo mundo: o cinismo útil não é achar que todos são falsos; é desconfiar do ponto preciso em que cada pessoa deixa de aplicar a própria regra.

Ele talvez não resolvesse a política de cotas, não acabasse com o abate animal nem oferecesse uma dieta ideal. Mas levantaria a lanterna e perguntaria, a cada lado da mesa: “Você defende isso mesmo quando perde algo?”

Se a resposta for sim, há princípio. Se a resposta for “sim, exceto quando a vaga é minha, o conforto é meu, o restaurante é meu e a conta é minha”, talvez haja menos ética do que identidade.

Epílogo — O tonel não tinha iFood

No final, ninguém precisa virar Diógenes, morar num tonel ou comer feijão plantado no quintal para ter uma vida minimamente coerente. A civilização é feita de compromissos, limitações e contradições. O objetivo não é pureza; pureza costuma ser uma arma ótima para acusar os outros e impossível de praticar até o fim.

O objetivo é honestidade proporcional.

Reconhecer que comer carne envolve um animal. Reconhecer que um produto vegano pode proteger animais e ainda gerar outros impactos. Reconhecer que cotas corrigem desigualdades reais, mas podem ter brechas exploráveis. Reconhecer que esforço pessoal existe, mas chega à linha de partida acompanhado por classe social, família, informação e dinheiro. Reconhecer que defender minorias não nos imuniza contra nossos próprios privilégios.

Uma ética que começa por vigiar o prato, a vaga ou a fala do vizinho pode virar polícia moral. Uma ética que inclui a própria biografia vira caráter.

E talvez seja essa a única lanterna que vale carregar: não a que procura o pecador na mesa ao lado, mas a que ilumina o próprio recibo.


Referências para aprofundamento

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