 |
| 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
RespostaPercy 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 OutLixo entra.
Lixo sai.
Mas com inteligência artificial generativa o problema ganhou uma variante ainda mais interessante:
Garbage Retrieved
↓
Plausible Garbage GeneratedOu 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:
S0C7O 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.htmlNã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 DatabaseCada 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 doe:
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-IFImagine cortar exatamente depois de PROCESS-A.
Um chunk conteria:
IF WS-STATUS = 'A'
PERFORM PROCESS-AOutro:
ELSE
PERFORM PROCESS-B
END-IFIndividualmente, 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 S0C7Todos 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 50Agora um reranker examina melhor esses resultados.
Top 50
|
v
Reranker
|
v
Top 5O 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 - 2024Mas não encontra:
CHANGE-20260904
Commit 4839
Ticket CHG88213Agora o modelo possui informação sobre FATURA01.
Só não possui a informação pedida.
Ele pode:
recusar responder;
dizer que não encontrou evidência;
solicitar mais contexto;
inventar.
O número quatro produz aquilo que chamamos de alucinação.
Por isso, RAG bem projetado precisa permitir:
Evidence insufficientEm 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 ReferenceTudo excelente.
Mas o documento necessário era:
PROD_SOFTWARE_INVENTORY
Enterprise COBOL 6.5Temos 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.pdfO mesmo texto existe cinco vezes.
O retriever retorna:
Top 5:
Documento A
Documento B
Documento C
Documento D
Documento EParece ótimo.
Cinco resultados relevantes!
Mas na realidade temos:
1 informação × 5 cópiasGastamos 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.3Pergunta:
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 = ENEm 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_TEAMIsso 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_2026Os 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
IGD17272IEsses códigos têm valor literal enorme.
Quando pergunto:
ICH408Inão quero apenas algo conceitualmente semelhante a ICH408I.
Quero documentos contendo:
ICH408IPor isso muitos sistemas combinam:
Vector Search
+
Keyword Search
=
Hybrid SearchBusca 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 erradaFantá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
LLMCada 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 msSe 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 externoObservabilidade 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 Evaluationde:
Generation EvaluationUma 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/queryNã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
ErrosQuando 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 ZAgora 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 confidencialUsuá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
LLMQuem 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
USERAtrás de tudo:
LOGS
METRICS
TRACES
SECURITY
EVALUATION
VERSIONINGIsso 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 reportsUsuá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 JCLO 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 programaAgora é possível correlacionar:
Arquivo
|
v
Layout
|
v
PIC
|
v
Dado inválido
|
v
Operação numérica
|
v
S0C7Aqui 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çãoProjeto B
Modelo menor
Chunking semântico
Hybrid search
Metadata correta
Reranking
Deduplicação
Avaliação contínua
Grounding
ObservabilidadePara 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 10Passo 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étricaIsso 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 QualityUsei multiplicação deliberadamente.
Imagine:
Security = 0Sistema inaceitável.
Imagine:
Retrieval = 0O LLM fica praticamente sozinho.
Imagine:
Knowledge Quality = 0Agora 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 CODERAG 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=WRONGQuem 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 TUDOPercy 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
traceabilityPodemos até imaginar SLOs:
Recall@10 > 95%
Citation correctness > 98%
P95 retrieval latency < 500ms
P95 total latency < 4s
Duplicate context < 5%
Unauthorized retrieval = 0Agora 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
↓
LLMNã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 documentationA 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.
Sem comentários:
Enviar um comentário