 |
| Bellacosa Mainframe Metricas RAG e IA |
☕ Um Café no Bellacosa Mainframe
O Que Todo Programador COBOL Padawan Precisa Saber Sobre as Métricas que Realmente Fazem um Sistema RAG Funcionar
Você Não Está Apenas Aprendendo Inteligência Artificial. Está Descobrindo Que Todo Grande Sistema Começa Muito Antes da Primeira Linha da Resposta.
"Um programador iniciante acredita que um sistema inteligente responde porque o modelo é poderoso. Um engenheiro experiente sabe que um sistema inteligente responde bem porque recebeu as informações corretas."
Nos últimos anos, a Inteligência Artificial Generativa transformou completamente a maneira como interagimos com computadores. ChatGPT, Claude, Gemini, Llama, Mistral e tantos outros modelos impressionam pela capacidade de escrever textos, criar código, explicar conceitos complexos e até ajudar na engenharia de software.
Naturalmente, muitas pessoas chegaram à seguinte conclusão:
"Quanto maior o modelo, melhores serão as respostas."
Embora exista um fundo de verdade nessa afirmação, ela está longe de explicar como funcionam os sistemas corporativos modernos.
Na prática, a maioria das empresas não está simplesmente conectando um LLM aos seus usuários. Elas estão construindo sistemas conhecidos como RAG (Retrieval-Augmented Generation), uma arquitetura que permite ao modelo consultar documentos internos antes de responder.
É exatamente nesse ponto que surge um dos maiores equívocos da atualidade.
A maioria dos problemas de um sistema RAG não está no modelo de IA.
Está na qualidade da recuperação das informações.
Para um Programador COBOL Padawan, essa ideia pode parecer estranha à primeira vista. Afinal, estamos acostumados a pensar que o programa faz o processamento e produz o resultado.
Mas pense no Batch.
O Batch Nunca Foi Mágico
Imagine um programa COBOL que calcula juros.
Seu algoritmo está absolutamente perfeito.
Entretanto, alguém carregou um arquivo VSAM corrompido.
Ou um JOB anterior terminou em ABEND.
Ou o catálogo aponta para um dataset errado.
O programa produzirá resultados corretos?
Claro que não.
O algoritmo continua excelente.
Os dados de entrada é que estão errados.
A Inteligência Artificial funciona exatamente da mesma maneira.
O LLM é o algoritmo.
O Retrieval representa os dados de entrada.
Se os documentos recuperados estiverem errados, incompletos ou desatualizados, a resposta também será.
O Que é um Sistema RAG?
Imagine que você faça a seguinte pergunta:
"Como configurar RACF PassTickets?"
O modelo poderia responder apenas com aquilo que aprendeu durante seu treinamento.
Mas um sistema RAG faz algo diferente.
Primeiro ele procura documentação relevante.
Depois envia essa documentação ao modelo.
Só então o modelo escreve a resposta.
O fluxo simplificado é parecido com isto:
Pergunta
↓
Transformação em Embeddings
↓
Busca Vetorial
↓
Ranking
↓
Reordenação (Reranking)
↓
Construção do Contexto
↓
Prompt
↓
LLM
↓
Resposta
Observe algo importante.
O modelo só entra quase no final.
Todo o restante acontece antes.
É exatamente como um programa COBOL que depende de dezenas de JOBs anteriores.
O LLM Não É Um Oráculo
Muitas pessoas imaginam que um modelo moderno "sabe tudo".
Na realidade, ele trabalha com probabilidades.
Ele observa padrões.
Relaciona conceitos.
Constrói frases coerentes.
Mas quando recebe documentação incorreta, ele faz o melhor possível com aquilo que recebeu.
Isso lembra muito um operador de produção.
Se o operador recebe um relatório incompleto, ele tomará decisões baseadas naquele relatório.
O problema não está no operador.
Está na informação disponível.
A Engenharia da Recuperação
Existe uma disciplina inteira dedicada a responder uma pergunta aparentemente simples:
"Estamos encontrando os documentos certos?"
Essa disciplina utiliza dezenas de métricas.
Vamos conhecer as mais importantes.
1. Hallucination Rate
Uma das métricas mais famosas.
Ela mede a frequência com que o modelo inventa informações.
Imagine perguntar:
Qual comando cria um VSAM KSDS?
Resposta correta:
DEFINE CLUSTER
Resposta incorreta:
CREATE VSAM
O modelo inventou.
Isso é uma alucinação.
Curiosamente, muitas alucinações acontecem porque nenhum documento correto foi encontrado.
2. Query Coverage
Nem toda pergunta possui apenas uma intenção.
Veja esta:
Como criar um KSDS com índice alternativo?
Existem dois assuntos.
• KSDS
• Alternate Index
Se apenas documentos sobre KSDS forem encontrados, metade da pergunta ficou sem resposta.
O sistema recuperou informação.
Mas não recuperou informação suficiente.
3. Recall@K
Esta talvez seja a métrica mais importante de Retrieval.
Imagine que existam dez documentos realmente úteis.
Seu mecanismo recuperou apenas seis.
O Recall é de 60%.
Agora imagine que outro mecanismo encontrou nove.
Recall de 90%.
Qual deles oferece maior chance de produzir uma boa resposta?
Obviamente o segundo.
Quanto mais documentos relevantes forem encontrados, maior será a qualidade do contexto enviado ao modelo.
4. Precision@K
Agora acontece o contrário.
O sistema recuperou dez documentos.
Mas apenas quatro são realmente úteis.
Os outros seis falam sobre assuntos diferentes.
O modelo agora precisa descobrir sozinho quais informações ignorar.
Isso desperdiça processamento e aumenta o risco de respostas equivocadas.
5. Top-1 Accuracy
Nem sempre basta recuperar bons documentos.
O melhor documento precisa aparecer primeiro.
Imagine procurar informações sobre CICS.
Primeiro resultado:
Manual de DB2.
Segundo:
Manual de JCL.
Terceiro:
Manual de CICS.
Tecnicamente o documento existe.
Mas ficou escondido.
Essa métrica mede exatamente isso.
6. Groundedness
Uma boa resposta deve estar apoiada nas evidências recuperadas.
Suponha que o contexto diga:
DFSORT suporta INCLUDE COND.
A resposta utiliza exatamente essa informação.
Excelente.
Agora imagine que a resposta também afirma:
DFSORT foi desenvolvido originalmente para...
Essa informação não apareceu em nenhum documento recuperado.
O modelo começou a extrapolar.
Quanto menor essa extrapolação, maior a Groundedness.
7. Faithfulness
Essa métrica costuma ser confundida com Hallucination.
Mas existe uma diferença importante.
Hallucination significa inventar.
Faithfulness significa preservar o significado original.
Imagine o documento:
Apenas administradores podem executar este comando.
A resposta produzida:
Todos os usuários podem executar este comando.
O modelo não inventou um comando novo.
Ele simplesmente alterou completamente o sentido do texto.
Esse é um problema gravíssimo em ambientes financeiros, jurídicos e médicos.
8. Chunk Diversity
Os documentos são divididos em pequenos pedaços chamados Chunks.
Agora imagine recuperar dez chunks.
Todos vieram do mesmo PDF.
Todos dizem praticamente a mesma coisa.
Isso reduz drasticamente a riqueza das informações.
Um bom sistema procura diferentes perspectivas.
Manuais.
Runbooks.
Documentação oficial.
Procedimentos internos.
Artigos técnicos.
Quanto maior essa diversidade, maior tende a ser a qualidade da resposta.
9. Chunk Redundancy
O oposto da diversidade.
Imagine gastar milhares de tokens enviando dez vezes a mesma informação.
Você ocupa espaço precioso da janela de contexto.
Sem acrescentar conhecimento novo.
É exatamente como imprimir dez cópias do mesmo relatório e colocar todas sobre a mesa do gerente.
10. Token Efficiency
Os modelos possuem limite de contexto.
Imagine uma janela de 100 mil tokens.
Você envia 90 mil.
Mas apenas 20 mil são realmente úteis.
Os outros 70 mil representam redundância.
Isso custa dinheiro.
Aumenta a latência.
E ainda reduz espaço para documentos realmente importantes.
11. Freshness
Conhecimento envelhece.
Muito rapidamente.
Imagine um sistema que consulta documentação do z/OS 2.3.
Enquanto sua empresa utiliza z/OS 3.2.
As respostas podem até estar corretas.
Mas já não refletem a realidade operacional.
Por isso grandes empresas monitoram constantemente a atualização dos documentos indexados.
12. Source Coverage
Outro erro comum.
Construir um RAG utilizando apenas PDFs.
Na prática, empresas possuem conhecimento espalhado por diversos lugares.
IBM Documentation.
Redbooks.
Confluence.
SharePoint.
GitHub.
Wiki interna.
Runbooks.
Tickets.
Procedimentos operacionais.
Quanto maior a cobertura dessas fontes, menor a chance de perder conhecimento importante.
13. Citation Accuracy
Imagine um sistema jurídico.
A resposta afirma:
Conforme a Lei X...
Mas a referência aponta para outra legislação.
O texto parece convincente.
Mas a citação está errada.
Em ambientes regulatórios isso pode gerar enormes problemas.
14. Evidence Sufficiency
Às vezes existe informação.
Mas ela não é suficiente.
Você pergunta:
Como instalar z/OS Connect?
O Retrieval encontra apenas a introdução do manual.
O modelo tentará preencher o restante utilizando seu conhecimento geral.
A resposta pode parecer excelente.
Mas a evidência disponível era insuficiente.
15. Retrieval Latency
Não basta encontrar documentos.
É preciso encontrá-los rapidamente.
Imagine um Chat Corporativo.
Cada busca demora cinco segundos.
Depois o modelo leva mais dez segundos para responder.
O usuário esperará quinze segundos.
Mesmo uma resposta perfeita passa a transmitir sensação de lentidão.
Performance também faz parte da experiência.
16. MRR (Mean Reciprocal Rank)
Essa métrica responde:
Em que posição apareceu o primeiro documento realmente útil?
Se ele apareceu logo na primeira posição.
Excelente.
Se apareceu apenas na décima.
O mecanismo de ranking precisa melhorar.
17. Hit Rate
Existe pelo menos um documento útil?
Sim?
Ótimo.
Não?
Todo o restante provavelmente falhará.
É uma métrica simples.
Mas extremamente valiosa para acompanhar a cobertura do índice.
18. Retrieval Failure Rate
Quantas consultas retornam praticamente lixo?
Imagine cem perguntas.
Trinta recuperam documentos irrelevantes.
O sistema possui uma taxa de falha de 30%.
Isso indica problemas sérios na indexação, na vetorização ou no mecanismo de busca.
19. Context Relevance Score
Nem todo documento relacionado é realmente útil.
Pergunta:
Como criar um Cluster VSAM?
Documento recuperado:
História da IBM.
Existe alguma relação?
Muito distante.
A relevância contextual mede exatamente esse alinhamento entre a intenção da pergunta e o conteúdo recuperado.
20. NDCG@K
Talvez a métrica mais sofisticada desta lista.
Ela não avalia apenas se os documentos corretos foram encontrados.
Ela verifica a ordem em que eles aparecem e atribui maior peso aos documentos mais relevantes posicionados no topo da lista.
Motores de busca, sistemas de recomendação e plataformas de streaming utilizam métricas semelhantes para organizar resultados.
No mundo do RAG, isso faz enorme diferença.
O Que Tudo Isso Tem a Ver com COBOL?
Mais do que parece.
Um sistema Batch depende de:
Nenhum programador experiente atribui um erro automaticamente ao COBOL.
Primeiro ele verifica:
o dataset correto foi utilizado?
o arquivo estava atualizado?
houve erro no JOB anterior?
o SORT terminou corretamente?
houve perda de registros?
O mesmo raciocínio deve ser aplicado aos sistemas baseados em IA.
Antes de culpar o modelo, pergunte:
Os documentos certos foram recuperados?
Eles estavam atualizados?
Eram suficientes?
Estavam classificados corretamente?
Vieram de fontes confiáveis?
Havia redundância excessiva?
A intenção completa da pergunta foi compreendida?
Essas perguntas representam a verdadeira maturidade em Engenharia de IA.
A Grande Lição para um Programador COBOL Padawan
Durante décadas, os profissionais de Mainframe aprenderam que qualidade não nasce apenas do código.
Ela nasce da disciplina.
Da observabilidade.
Dos controles.
Da monitoração.
Dos indicadores.
Dos relatórios.
Da governança.
A Inteligência Artificial está caminhando exatamente para esse mesmo estágio.
Os sistemas mais avançados do mundo não são aqueles que simplesmente utilizam o maior LLM disponível no mercado. São aqueles que monitoram continuamente a qualidade da recuperação da informação, medem seus indicadores, detectam degradações antes que afetem os usuários e refinam constantemente seus índices, embeddings e estratégias de busca.
Da mesma forma que um ambiente IBM Z monitora CPU, I/O, SMF, RMF, WLM, JES2, CICS e DB2 para garantir disponibilidade e desempenho, um ecossistema RAG precisa monitorar Recall@K, Precision@K, Groundedness, Faithfulness, Freshness, Source Coverage, MRR e NDCG@K para garantir respostas confiáveis.
No futuro, o diferencial dos engenheiros de software não será apenas saber utilizar modelos de IA. Será compreender toda a engenharia que existe antes da geração da resposta.
E, curiosamente, esse modo de pensar já faz parte da cultura dos profissionais de Mainframe há décadas.
Porque, no fim das contas, um grande sistema nunca depende apenas da inteligência do processamento. Ele depende, acima de tudo, da qualidade das informações que alimentam esse processamento. Essa é uma lição que acompanha os Programadores COBOL desde os primeiros arquivos VSAM e que agora ressurge como um dos pilares da Inteligência Artificial moderna.
