 |
| Bellacosa Mainframe e plataformas de ia escalaveis sem misterios |
☕ Um Café no Bellacosa Mainframe
Plataformas de IA Escaláveis sem Mistérios
O Guia do Programador COBOL Padawan para Entender por que Inteligência Artificial em Produção é uma Frota Inteira — e não Apenas uma Nave
Imagine a seguinte cena.
Você está sentado diante de um terminal 3270, com uma caneca de café ao lado do teclado, observando um programa COBOL que processa milhões de registros todas as noites. De repente, um jovem programador chega correndo pela sala e anuncia:
— Bellacosa, encontrei o melhor modelo de inteligência artificial do mercado! Agora nossa plataforma está pronta!
Você olha calmamente para o monitor, toma mais um gole de café e responde:
— Padawan, encontrar um bom modelo de IA é como encontrar um excelente motor de dobra. Isso não significa que você já construiu a USS Enterprise.
O motor de dobra pode ser impressionante. Pode gerar textos, resumir documentos, escrever código, responder perguntas e analisar informações. Contudo, para atravessar a galáxia em segurança, uma nave precisa de muito mais:
computadores de bordo;
sensores;
escudos;
sistemas de comunicação;
controle de energia;
navegação;
diagnóstico;
redundância;
manutenção;
oficiais preparados;
protocolos de emergência.
Uma plataforma de inteligência artificial funciona exatamente assim.
O modelo é importante, mas ele representa apenas uma parte do sistema.
Em uma demonstração de laboratório, talvez seja suficiente enviar uma pergunta diretamente para um modelo e exibir a resposta. Em produção, entretanto, surgem usuários simultâneos, documentos internos, custos, privacidade, auditoria, segurança, latência, picos de utilização, falhas, limites de contexto, respostas incorretas e necessidade de monitoramento.
É nesse momento que muitos projetos descobrem uma verdade pouco glamorosa:
Uma aplicação de IA pode funcionar perfeitamente durante uma apresentação e desmoronar completamente quando encontra o primeiro dia real de produção.
Neste café, vamos explorar os principais componentes que transformam um modelo isolado em uma verdadeira plataforma de IA escalável. E, como toda boa missão da Frota Estelar, vamos fazer isso com mapas, analogias, exemplos, alertas, curiosidades e alguns easter eggs escondidos pelo caminho.
Prepare seu café, ajuste o comunicador e confirme se os escudos estão operacionais.
A missão começou.
1. O grande engano: acreditar que o modelo é o sistema
Nos primeiros contatos com inteligência artificial generativa, é comum imaginar uma arquitetura muito simples:
USUÁRIO
|
v
MODELO DE IA
|
v
RESPOSTA
Esse desenho funciona em testes pequenos.
Um usuário faz uma pergunta, o modelo responde e todos ficam impressionados.
Porém, uma plataforma corporativa de verdade precisa responder perguntas muito mais difíceis:
Quem é o usuário?
Ele possui autorização para acessar determinado documento?
Qual modelo deve atender essa solicitação?
O contexto enviado é realmente relevante?
A resposta deve ser armazenada em cache?
O conteúdo precisa ser filtrado?
Quanto custou a interação?
A informação utilizada estava atualizada?
O sistema consegue explicar de onde veio a resposta?
O que acontece quando chegam dez mil requisições ao mesmo tempo?
Como detectar uma regressão depois da troca de modelo?
Como impedir vazamento de dados confidenciais?
Como observar uma falha que acontece apenas em um caso entre cem mil?
O modelo não resolve sozinho nenhuma dessas questões.
Ele se parece mais com um programa COBOL dentro de uma arquitetura empresarial. O programa pode conter a lógica principal, mas depende de JCL, datasets, Db2, CICS, IMS, RACF, JES2, WLM, bibliotecas, logs, monitoramento e processos operacionais.
Nenhum profissional experiente de mainframe diria:
“O sistema bancário é apenas aquele módulo COBOL.”
Da mesma maneira, ninguém deveria dizer:
“Nossa plataforma de IA é apenas aquele LLM.”
Uma plataforma escalável é um conjunto coordenado de camadas.
2. Model Inference: quando o motor realmente entra em funcionamento
A inferência é o momento em que o modelo recebe uma entrada e produz uma saída.
Em termos simples:
PROMPT + CONTEXTO
|
v
MODELO
|
v
RESPOSTA
Essa é a camada de execução.
Para um programador COBOL, podemos comparar a inferência à execução de um programa depois da compilação e da linkedição. O load module está pronto, os parâmetros foram fornecidos e agora a lógica será processada.
Entretanto, a inferência possui um grande desafio: equilibrar latência, vazão e custo.
Latência
Latência é o tempo necessário para começar ou concluir uma resposta.
Em um chatbot, o usuário espera uma reação quase imediata.
Em uma rotina batch que analisa dois milhões de contratos durante a madrugada, alguns minutos extras podem ser aceitáveis.
Throughput
Throughput, ou vazão, representa quantas requisições o sistema consegue processar em determinado período.
Um modelo pode responder muito rápido para um único usuário e ainda assim apresentar péssimo desempenho quando recebe milhares de chamadas simultâneas.
É como um programa COBOL que executa bem com cem registros, mas enfrenta gargalos quando recebe um arquivo com quinhentos milhões.
O triângulo da engenharia de IA
Quase toda decisão de inferência envolve três fatores:
QUALIDADE
/\
/ \
/ \
CUSTO----VELOCIDADE
Um modelo maior pode produzir respostas melhores, porém costuma exigir mais recursos.
Um modelo menor pode ser rápido e econômico, mas talvez não resolva tarefas complexas.
A missão da arquitetura não é escolher o “melhor modelo do mundo”. É escolher o modelo adequado para cada tipo de operação.
O Sr. Spock provavelmente diria:
“Utilizar um modelo gigantesco para responder perguntas triviais seria ilógico.”
E ele estaria absolutamente correto.
3. Tokenização: a linguagem secreta dos modelos
Um modelo de linguagem não lê exatamente palavras da mesma maneira que um ser humano.
Antes de processar o texto, ele o divide em unidades chamadas tokens.
Uma palavra pode corresponder a:
um token;
vários tokens;
parte de um token;
uma combinação diferente conforme o idioma e o modelo.
Por exemplo, a expressão:
MAINFRAME
pode ser interpretada como uma unidade ou dividida em partes semelhantes a:
MAIN
FRAME
Já termos muito específicos, nomes técnicos, códigos COBOL, caracteres especiais e palavras em português podem consumir uma quantidade maior de tokens.
Por que o programador precisa se importar?
Porque tokens influenciam diretamente:
custo;
limite de entrada;
tamanho da resposta;
desempenho;
capacidade de contexto;
quantidade de documentos processados.
Considere este prompt:
Explique COBOL.
Ele é pequeno.
Agora considere:
Leia estes 800 manuais, compare todas as versões do compilador,
analise os exemplos, identifique divergências, gere uma tabela,
inclua recomendações e produza um relatório detalhado.
A segunda solicitação pode consumir uma quantidade enorme de tokens antes mesmo de o modelo começar a responder.
Em muitas plataformas comerciais, o custo é calculado com base nos tokens de entrada e saída.
Portanto, desperdiçar contexto é semelhante a executar repetidamente um job caro sem necessidade.
Dica do Bellacosa
Não envie para o modelo tudo o que existe.
Envie o que ele realmente precisa.
Um prompt gigantesco não é necessariamente um prompt melhor. Muitas vezes, é apenas um SYSIN desorganizado com documentos demais.
4. Gerenciamento da janela de contexto: a memória operacional da missão
A janela de contexto determina quanto conteúdo o modelo consegue considerar durante uma interação.
Ela pode incluir:
perguntas anteriores;
instruções do sistema;
documentos recuperados;
mensagens do usuário;
resultados de ferramentas;
exemplos;
regras de formatação.
Podemos comparar a janela de contexto a uma área de trabalho temporária.
No mundo COBOL, pense em estruturas como:
WORKING-STORAGE;
COMMAREA;
containers do CICS;
áreas compartilhadas;
parâmetros recebidos;
registros mantidos durante uma etapa de processamento.
Se você tentar colocar informação demais em uma área limitada, alguma coisa precisará ser removida, resumida ou ignorada.
Estratégias comuns
Janela deslizante
Mantém as mensagens mais recentes e elimina as antigas.
Funciona bem em conversas curtas, mas pode apagar decisões importantes feitas no início.
Resumo de histórico
As interações antigas são condensadas em uma versão menor.
O risco é perder detalhes.
É semelhante a transformar um log completo em um relatório resumido. Você economiza espaço, mas talvez elimine justamente a informação necessária para investigar um erro.
Priorização por relevância
A plataforma seleciona os trechos mais relacionados à pergunta atual.
Essa abordagem costuma ser melhor do que simplesmente usar os textos mais recentes.
Compressão semântica
O sistema tenta preservar significado ocupando menos tokens.
Essa área ainda exige muitos cuidados. Um resumo incorreto pode contaminar todo o raciocínio seguinte.
Curiosidade
Uma janela de contexto muito grande não elimina automaticamente o problema.
Mesmo quando o modelo aceita uma enorme quantidade de texto, inserir conteúdo excessivo pode reduzir a precisão. Informações importantes ficam escondidas no meio de trechos irrelevantes.
É o equivalente a procurar um SQLCODE dentro de dez milhões de linhas de spool sem utilizar filtros.
Ter acesso ao conteúdo não significa encontrá-lo com eficiência.
5. Embeddings: transformando significado em coordenadas
Embeddings são representações matemáticas de palavras, frases, parágrafos, imagens ou documentos.
Em vez de armazenar apenas o texto, a plataforma cria uma sequência de números que representa características semânticas daquele conteúdo.
Por exemplo, as expressões:
carro;
automóvel;
veículo de passeio;
podem gerar vetores próximos porque possuem significados semelhantes.
Já termos como:
JCL;
JES2;
execução batch;
submissão de job;
também podem aparecer próximos em um espaço vetorial bem construído.
Isso permite uma pesquisa diferente da busca tradicional por palavras-chave.
Busca tradicional
Pergunta:
Como investigar uma falha de job?
Documento:
Procedimento para diagnóstico de ABEND no JES2.
Talvez uma busca literal não encontre o documento, porque as palavras são diferentes.
Busca semântica
A pesquisa vetorial percebe que “falha de job”, “diagnóstico de ABEND” e “JES2” estão semanticamente relacionados.
Essa é uma das grandes forças dos embeddings.
Eles ajudam o sistema a localizar conteúdos por significado, não apenas por coincidência textual.
Atenção, tripulação
Embedding não é entendimento humano.
É uma representação numérica útil para calcular proximidade.
Dois textos podem parecer próximos matematicamente e ainda serem inadequados para uma pergunta específica.
Por isso, a recuperação precisa de filtros adicionais, metadados, validações e, muitas vezes, reranking.
6. Bancos vetoriais: o arquivo estelar do conhecimento
Depois de criar embeddings, precisamos armazená-los e pesquisá-los rapidamente.
Entram em cena os bancos vetoriais.
Eles são preparados para operações como:
busca por similaridade;
recuperação dos vetores mais próximos;
filtragem por metadados;
pesquisa em grande escala;
combinação de busca lexical e semântica.
Entre as tecnologias usadas nesse espaço estão soluções especializadas e extensões vetoriais de bancos já conhecidos.
O objetivo principal é responder:
“Quais documentos se parecem mais com a pergunta recebida?”
Exemplo corporativo
Imagine uma empresa com:
vinte mil procedimentos;
cem mil tickets;
cinquenta mil manuais;
milhares de normas;
históricos de incidentes;
documentação de aplicações;
diagramas e runbooks.
Quando um analista pergunta:
Como investigar lentidão em uma transação CICS após aumento de carga?
o sistema precisa localizar os materiais mais úteis sem enviar todo o repositório para o modelo.
O banco vetorial ajuda a selecionar apenas alguns trechos.
O paralelo com o mainframe
Podemos pensar em um banco vetorial como um índice especializado.
Ele não substitui necessariamente o Db2, o VSAM, o IMS ou um repositório documental. Frequentemente funciona ao lado deles.
O banco tradicional continua sendo a fonte oficial.
O índice vetorial ajuda a encontrar o conteúdo relevante.
Essa distinção é muito importante.
A camada vetorial pode apontar para um documento, mas a fonte de verdade ainda precisa ser preservada, governada e auditável.
7. RAG: quando o modelo consulta a biblioteca antes de responder
RAG significa Retrieval-Augmented Generation, ou geração aumentada por recuperação.
A ideia é simples e poderosa:
O usuário faz uma pergunta.
O sistema procura informações relevantes.
Os melhores trechos são selecionados.
Esses trechos são enviados ao modelo.
O modelo produz uma resposta baseada no material recuperado.
O fluxo básico é:
PERGUNTA
|
v
CRIAÇÃO DO EMBEDDING
|
v
BUSCA VETORIAL
|
v
RECUPERAÇÃO DE DOCUMENTOS
|
v
MONTAGEM DO CONTEXTO
|
v
MODELO
|
v
RESPOSTA
Por que o RAG é tão importante?
Porque os modelos não conhecem automaticamente:
documentos privados;
procedimentos internos;
dados recém-publicados;
alterações realizadas depois do treinamento;
regras específicas da organização;
detalhes de sistemas proprietários.
Com RAG, a empresa pode fornecer conhecimento atualizado sem retreinar o modelo inteiro.
Exemplo mainframe
Pergunta:
Qual é o procedimento interno para tratar um S0C7 na aplicação XPTO?
A plataforma recupera:
o runbook da aplicação;
o histórico de incidentes;
o manual interno;
exemplos de dumps anteriores;
a lista de responsáveis.
Depois, o modelo organiza esse conhecimento em uma resposta.
Sem RAG, ele talvez forneça apenas uma explicação genérica do S0C7.
Com RAG, pode responder conforme o ambiente real da organização.
Mas RAG não é magia
Um RAG ruim pode produzir uma resposta ruim com aparência de precisão.
Os principais pontos de falha são:
documentos desatualizados;
divisão inadequada dos textos;
embeddings fracos;
filtros errados;
recuperação de trechos irrelevantes;
contexto excessivo;
ausência de citações;
permissões mal aplicadas;
modelo ignorando a fonte recuperada.
RAG não elimina alucinações. Ele reduz riscos quando é bem projetado.
Easter egg da missão: um RAG sem governança é como acessar o computador da Enterprise usando documentos dos Klingons, Ferengi, Romulanos e Federação sem identificar a origem. A resposta pode soar convincente, mas talvez comece uma guerra interplanetária.
8. Prompt Engineering: escrevendo o JCL da conversa
Prompt engineering é a disciplina de estruturar instruções para orientar o comportamento do modelo.
Um prompt pode definir:
papel;
objetivo;
formato;
público;
tom;
restrições;
critérios de qualidade;
ferramentas permitidas;
fontes obrigatórias;
regras de segurança.
Para o programador COBOL, o prompt pode ser comparado a uma combinação de SYSIN, parâmetros, regras de negócio e instruções operacionais.
Um bom programa recebendo dados ruins continua sujeito a resultados ruins.
O mesmo vale para a IA.
Exemplo simples
Prompt fraco:
Fale sobre COBOL.
Prompt melhor:
Explique o conceito de PERFORM em COBOL para um programador iniciante.
Apresente exemplos com PERFORM simples, PERFORM UNTIL e PERFORM VARYING.
Mostre erros comuns, inclua comentários no código e evite recursos obsoletos.
O segundo prompt:
define o público;
delimita o tema;
especifica exemplos;
determina cuidados;
reduz ambiguidades.
Prompt não é garantia
Mesmo um excelente prompt não transforma um modelo inadequado em especialista absoluto.
Prompt engineering ajuda a controlar comportamento, mas não substitui:
dados;
testes;
arquitetura;
segurança;
validação;
observabilidade.
Um prompt é uma instrução, não um escudo defletor.
9. Fine-tuning: treinamento especializado da tripulação
Fine-tuning é o processo de ajustar um modelo com exemplos específicos para modificar seu comportamento.
Pode ser útil quando a empresa precisa de:
estilo consistente;
formato muito específico;
vocabulário de domínio;
classificação especializada;
respostas padronizadas;
comportamento difícil de obter apenas com prompt.
Exemplo
Uma organização pode ajustar um modelo para transformar descrições de incidentes em categorias operacionais padronizadas.
Entrada:
Job ficou preso após falha de alocação.
Saída esperada:
Categoria: Storage / Dataset Allocation
Prioridade: Média
Equipe: Operações z/OS
Com milhares de exemplos bem preparados, o modelo pode aprender esse padrão.
Quando não usar fine-tuning
Muitas equipes tentam utilizar fine-tuning para “ensinar documentos” ao modelo.
Frequentemente, RAG é mais adequado para conhecimento que muda.
Uma regra prática:
Conhecimento mutável: considere RAG.
Comportamento ou formato: considere fine-tuning.
Instrução simples: comece com prompt engineering.
O fine-tuning exige:
dados de treinamento;
limpeza;
avaliação;
controle de versões;
custos;
monitoramento de regressões.
Treinar com exemplos ruins é semelhante a formar cadetes usando manuais incorretos.
Eles aprenderão muito bem a fazer a coisa errada.
10. Model Routing: enviando cada missão para a nave correta
Model routing é a camada que escolhe qual modelo deve processar cada solicitação.
Nem toda pergunta precisa do modelo mais caro.
Considere estas tarefas:
Classificar um e-mail como urgente ou não.
Resumir um parágrafo.
Analisar um contrato de 200 páginas.
Diagnosticar uma falha complexa em COBOL, CICS e Db2.
Usar o mesmo modelo para tudo pode ser ineficiente.
Uma plataforma pode adotar:
modelo pequeno para classificação;
modelo médio para resumo;
modelo avançado para análise;
modelo especializado para código;
modelo local para dados sensíveis;
modelo externo para tarefas não confidenciais.
Critérios de roteamento
O roteador pode avaliar:
complexidade;
idioma;
domínio;
custo;
urgência;
privacidade;
tamanho do contexto;
disponibilidade;
qualidade necessária.
Isso se parece muito com direcionar diferentes workloads por classes de serviço.
O WLM do z/OS não trata todas as cargas exatamente da mesma maneira. Ele prioriza conforme objetivos definidos.
O model routing aplica uma lógica semelhante ao universo da IA.
11. Caching: não execute novamente o que já foi resolvido
Cache armazena resultados para evitar processamento repetido.
Imagine cem usuários perguntando:
Qual é a política de troca de senha?
Sem cache, a plataforma pode:
criar embedding;
pesquisar documentos;
recuperar os mesmos trechos;
chamar o modelo;
gerar praticamente a mesma resposta;
cem vezes.
Com cache, parte desse fluxo pode ser reutilizada.
Tipos de cache
Cache exato
Reutiliza a resposta quando a pergunta é idêntica.
Cache semântico
Pode reutilizar uma resposta quando a nova pergunta possui significado muito semelhante.
Exemplo:
Como altero minha senha?
e
Qual é o procedimento para trocar a senha?
Cache de embeddings
Evita recalcular vetores já processados.
Cache de recuperação
Armazena resultados frequentes de busca.
Cuidados
Cache pode servir informação antiga.
Ele precisa considerar:
validade;
versão do documento;
identidade do usuário;
permissões;
sensibilidade;
atualização das fontes.
Nunca compartilhe uma resposta em cache entre usuários quando o conteúdo depende das autorizações individuais.
O cache é um replicador útil, mas não pode materializar documentos secretos na cabine errada.
12. Streaming inference: reduzindo a espera percebida
No streaming, a resposta é enviada aos poucos.
Em vez de o usuário esperar o texto completo, ele começa a visualizar os primeiros fragmentos enquanto o restante é gerado.
Isso não significa necessariamente que a inferência ficou mais rápida.
Significa que a experiência parece mais responsiva.
É uma diferença entre:
AGUARDE...
AGUARDE...
AGUARDE...
RESPOSTA COMPLETA
e:
A resposta começa...
continua sendo formada...
e chega gradualmente...
Em aplicações interativas, essa percepção é muito importante.
Contudo, streaming exige cuidados:
filtros de segurança precisam acompanhar a saída;
erros podem aparecer no meio do texto;
o cliente precisa lidar com interrupções;
a interface deve indicar conclusão;
logs precisam reconstruir o conteúdo integral.
Transmitir tokens sem controle seria como abrir um canal subespacial antes de verificar se a mensagem está autorizada.
13. Batch processing: a inteligência artificial também trabalha de madrugada
Nem toda tarefa precisa acontecer em tempo real.
Muitas operações de IA são perfeitas para processamento em lote:
criação de embeddings;
classificação de milhões de documentos;
resumo de históricos;
extração de metadados;
avaliação de respostas;
reindexação;
análise de logs;
preparação de dados.
O programador mainframe conhece bem essa filosofia.
O batch continua sendo uma solução poderosa porque permite:
agrupar trabalho;
controlar janelas;
otimizar recursos;
repetir etapas;
reiniciar processos;
acompanhar resultados.
Exemplo
Uma empresa possui cinco milhões de PDFs.
Não faz sentido esperar um usuário perguntar sobre cada documento para então gerar o embedding.
A plataforma pode processar os documentos em lote durante períodos de menor custo e menor demanda.
O fluxo pode incluir:
LEITURA
|
v
EXTRAÇÃO DE TEXTO
|
v
LIMPEZA
|
v
DIVISÃO EM TRECHOS
|
v
EMBEDDINGS
|
v
INDEXAÇÃO
Parece familiar?
Sim. É praticamente uma nova espécie de cadeia batch.
Mudaram os componentes, mas os princípios continuam reconhecíveis.
14. Guardrails e camadas de segurança: os escudos da plataforma
Guardrails são mecanismos que controlam entradas, saídas e ações da IA.
Eles podem ajudar a impedir:
conteúdo perigoso;
vazamento de informações;
exposição de dados pessoais;
execução de comandos proibidos;
respostas fora da política;
manipulação por prompt injection;
acesso indevido a ferramentas;
uso de fontes não autorizadas.
Guardrails de entrada
Analisam o que o usuário envia.
Podem detectar:
tentativas de burlar regras;
dados sensíveis;
conteúdo malicioso;
solicitações proibidas.
Guardrails de saída
Verificam a resposta antes da entrega.
Podem procurar:
informações confidenciais;
linguagem inadequada;
instruções perigosas;
violações de conformidade;
ausência de citações.
Guardrails de ferramentas
Controlam o que o agente pode fazer.
Por exemplo:
consultar um banco;
enviar um e-mail;
criar um ticket;
executar uma transação;
alterar um cadastro.
Essa camada merece atenção máxima.
Uma IA que apenas responde texto possui riscos.
Uma IA que pode executar ações possui riscos muito maiores.
O paralelo com RACF
Guardrails não são exatamente o RACF da IA, mas a comparação ajuda.
Assim como o RACF trabalha com identidades, perfis, recursos e permissões, uma plataforma de IA precisa decidir:
quem pode perguntar;
quais fontes pode consultar;
quais ações pode executar;
quais dados pode revelar;
quais operações devem ser auditadas.
Nunca permita que o modelo seja a autoridade final sobre permissões.
A autorização precisa estar fora do modelo, em controles determinísticos.
Um LLM não deve “imaginar” se o usuário possui acesso.
Ele deve receber essa decisão de uma camada confiável.
15. Evaluation pipelines: testar a IA antes que o Klingon teste por você
Sistemas tradicionais possuem testes unitários, integrados, funcionais, de regressão, desempenho e segurança.
Plataformas de IA também precisam de avaliação contínua.
O problema é que respostas geradas não são sempre idênticas.
Um programa COBOL pode produzir um valor esperado exato.
Um modelo pode gerar duas respostas diferentes, ambas aceitáveis.
Por isso, a avaliação precisa usar múltiplos critérios.
O que avaliar?
correção;
relevância;
fundamentação;
completude;
segurança;
formato;
latência;
custo;
uso de fontes;
taxa de recusa;
consistência;
satisfação do usuário.
Conjunto dourado
Uma prática importante é criar um conjunto de perguntas com respostas esperadas.
Exemplo:
Pergunta:
O que significa DISP=(NEW,CATLG,DELETE)?
Critérios:
- explicar NEW;
- explicar CATLG;
- explicar DELETE;
- mostrar o comportamento em sucesso e falha;
- não inventar sintaxe;
A plataforma executa essas perguntas periodicamente e compara a qualidade.
Isso ajuda a detectar regressões após:
troca de modelo;
mudança de prompt;
alteração no RAG;
nova versão do índice;
mudança no tokenizer;
atualização dos documentos.
Curiosidade importante
Uma plataforma pode melhorar a média geral e piorar exatamente os casos mais críticos.
Por isso, não basta olhar uma única nota.
É necessário separar avaliações por:
domínio;
risco;
tipo de usuário;
complexidade;
sensibilidade.
Uma resposta errada sobre uma curiosidade custa pouco.
Uma resposta errada sobre uma operação financeira pode custar milhões.
16. Observabilidade: SMF, RMF e OMEGAMON encontraram a inteligência artificial
Observabilidade permite compreender o comportamento interno de um sistema por meio de sinais como:
logs;
métricas;
traces;
eventos;
correlações.
Em IA, precisamos observar muito mais do que “funcionou ou falhou”.
Métricas importantes
tokens de entrada;
tokens de saída;
custo por requisição;
latência;
tempo até o primeiro token;
erros;
timeout;
modelo selecionado;
documentos recuperados;
score de similaridade;
taxa de cache;
bloqueios de guardrail;
satisfação do usuário;
uso de ferramentas;
falhas de autorização.
Tracing
Um trace pode mostrar toda a jornada:
REQUISIÇÃO DO USUÁRIO
|
v
AUTENTICAÇÃO
|
v
CLASSIFICAÇÃO
|
v
MODEL ROUTING
|
v
BUSCA VETORIAL
|
v
RERANKING
|
v
MONTAGEM DO PROMPT
|
v
INFERÊNCIA
|
v
VALIDAÇÃO
|
v
RESPOSTA
Sem tracing, a equipe vê apenas:
A resposta ficou ruim.
Com tracing, pode descobrir:
O documento correto não foi recuperado porque o filtro de versão estava errado.
Essa diferença é gigantesca.
O profissional de mainframe entende muito bem o valor de SMF, RMF, dumps, traces e históricos.
A IA não elimina a necessidade de diagnóstico.
Ela aumenta essa necessidade.
17. Autoscaling: preparando a frota para a hora do pico
A demanda por IA pode variar muito.
Durante a madrugada, talvez existam poucas chamadas.
Depois de uma campanha, lançamento ou incidente, podem surgir milhares de usuários.
Autoscaling ajusta automaticamente os recursos.
Ele pode:
adicionar instâncias;
aumentar réplicas;
distribuir requisições;
ativar aceleradores;
reduzir capacidade quando a demanda cai.
Mas escalar IA não é tão simples quanto escalar uma página web.
Modelos grandes podem exigir:
muita memória;
GPU;
tempo de inicialização;
distribuição especializada;
carregamento de pesos;
cache aquecido.
Cold start
Quando uma nova instância precisa carregar o modelo, pode haver atraso.
É como iniciar uma região inteira do sistema apenas depois de a fila já estar cheia.
Por isso, a plataforma precisa prever:
capacidade mínima;
réplicas aquecidas;
comportamento em picos;
limites de fila;
degradação controlada.
Degradação elegante
Quando o modelo principal está indisponível, o sistema pode:
usar um modelo menor;
reduzir o tamanho da resposta;
desativar funções não críticas;
colocar tarefas em fila;
oferecer resposta parcial;
encaminhar para atendimento humano.
Uma plataforma madura não pergunta apenas:
“Como manter tudo perfeito?”
Ela também pergunta:
“Como continuar operando quando alguma camada falhar?”
Essa é a verdadeira mentalidade de resiliência.
18. Otimização de custos: não desperdice dilítio
A IA generativa pode consumir recursos rapidamente.
Os custos aparecem em diferentes pontos:
inferência;
tokens;
armazenamento;
banco vetorial;
GPU;
rede;
observabilidade;
reprocessamento;
avaliação;
embeddings;
manutenção.
Estratégias de economia
Usar modelos menores quando possível
Classificações simples não precisam do modelo mais poderoso.
Limitar contexto
Enviar apenas documentos relevantes reduz tokens.
Aplicar cache
Evita inferência repetida.
Utilizar processamento em lote
Operações não urgentes podem ser agrupadas.
Comprimir prompts
Instruções redundantes custam dinheiro.
Controlar tamanho de resposta
Nem toda pergunta precisa de três mil palavras.
Medir custo por caso de uso
O custo médio global pode esconder operações extremamente caras.
Métrica realmente útil
Não observe apenas:
Custo por milhão de tokens
Observe também:
Custo por atendimento resolvido
ou:
Custo por incidente evitado
ou:
Custo por documento processado
Uma solução aparentemente cara pode gerar alto valor.
Uma solução barata pode ser inútil.
O objetivo não é gastar o mínimo.
É produzir resultado sustentável.
19. Como todas as camadas trabalham juntas
Agora podemos montar uma arquitetura simplificada:
USUÁRIO
|
v
AUTENTICAÇÃO E AUTORIZAÇÃO
|
v
GUARDRAIL DE ENTRADA
|
v
CLASSIFICAÇÃO DA SOLICITAÇÃO
|
v
MODEL ROUTING
|
+----------------------+
| |
v v
CACHE RAG / BUSCA
| |
+----------+-----------+
|
v
MONTAGEM DO PROMPT
|
v
INFERÊNCIA
|
v
GUARDRAIL DE SAÍDA
|
v
STREAMING / API
|
v
USUÁRIO
Paralelamente, outras camadas acompanham tudo:
OBSERVABILIDADE
AVALIAÇÃO
CUSTOS
AUTOSCALING
AUDITORIA
SEGURANÇA
Nenhuma camada trabalha completamente isolada.
Uma decisão pode afetar várias outras.
Exemplo:
Ao aumentar o contexto:
a qualidade pode melhorar;
a latência pode aumentar;
o custo pode crescer;
o limite do modelo pode ser atingido;
o cache pode perder eficiência.
Ao trocar para um modelo menor:
o custo pode cair;
a velocidade pode melhorar;
a qualidade pode diminuir;
o roteamento precisa mudar;
as avaliações devem ser repetidas.
Arquitetura de IA é um jogo permanente de trade-offs.
Não existe uma configuração perfeita para todos os casos.
Existe uma configuração adequada ao objetivo.
20. Um exemplo completo: copiloto para operações mainframe
Vamos imaginar uma empresa criando um assistente para ajudar operadores e programadores iniciantes.
O usuário pergunta:
Meu job terminou com S0C7. O que devo verificar?
Passo 1 — Autenticação
O sistema identifica o usuário.
Passo 2 — Autorização
Verifica quais aplicações, logs e runbooks ele pode consultar.
Passo 3 — Guardrail
Remove ou mascara dados sensíveis enviados no prompt.
Passo 4 — Classificação
Identifica a pergunta como diagnóstico técnico de mainframe.
Passo 5 — Model routing
Seleciona um modelo especializado em código e operações.
Passo 6 — RAG
Busca:
documentação de S0C7;
runbook da aplicação;
incidentes semelhantes;
padrões internos de diagnóstico;
guias de dump.
Passo 7 — Montagem de contexto
Seleciona apenas os trechos mais relevantes.
Passo 8 — Prompt
Instrui o modelo a:
explicar o erro;
sugerir sequência de análise;
não executar ações;
citar as fontes;
separar hipóteses de fatos.
Passo 9 — Inferência
O modelo gera a resposta.
Passo 10 — Validação
A plataforma verifica:
ausência de dados sigilosos;
presença de fontes;
aderência ao formato;
inexistência de instruções perigosas.
Passo 11 — Streaming
A resposta aparece gradualmente.
Passo 12 — Observabilidade
O sistema registra:
modelo;
tokens;
latência;
documentos consultados;
custo;
feedback.
Passo 13 — Avaliação
A interação pode entrar em um conjunto de análise para melhorar a plataforma.
Perceba que o modelo participou apenas de uma etapa.
A qualidade final dependeu da missão inteira.
21. Erros comuns de equipes iniciantes
Escolher o modelo antes de entender o problema
A equipe se apaixona por uma tecnologia e tenta encaixá-la em qualquer caso.
Comece pelo resultado desejado.
Jogar documentos em um banco vetorial sem governança
Documentos duplicados, antigos e conflitantes produzirão respostas ruins.
Não medir custos
A surpresa chega na primeira fatura.
Confiar em testes manuais
Cinco perguntas bem respondidas não provam que a plataforma está pronta.
Ignorar autorização no RAG
O sistema pode recuperar um documento que o usuário não deveria ler.
Usar um modelo grande para tudo
Funciona tecnicamente, mas pode ser economicamente inviável.
Não registrar versões
Sem saber qual modelo, prompt e índice foram usados, investigar regressões se torna difícil.
Confundir fluência com correção
Uma resposta bem escrita pode estar errada.
O modelo fala com confiança porque foi treinado para produzir linguagem plausível, não porque possui certeza.
22. Roteiro prático para construir uma plataforma
Etapa 1 — Escolha um caso de uso pequeno
Evite começar com:
Vamos criar uma IA para toda a empresa.
Comece com:
Vamos responder dúvidas sobre os procedimentos da equipe de operações.
Etapa 2 — Defina métricas
Exemplos:
taxa de resolução;
precisão;
tempo de resposta;
custo;
satisfação;
redução de chamados.
Etapa 3 — Organize as fontes
Remova:
duplicações;
documentos vencidos;
versões conflitantes;
conteúdos sem proprietário.
Etapa 4 — Crie um RAG simples
Teste recuperação antes de culpar o modelo.
Etapa 5 — Monte um conjunto de avaliação
Inclua perguntas fáceis, difíceis, ambíguas e perigosas.
Etapa 6 — Implemente segurança
Autenticação, autorização, mascaramento e auditoria não devem ser deixados para o final.
Etapa 7 — Adicione observabilidade
Registre toda a cadeia.
Etapa 8 — Otimize custo
Somente depois de medir.
Etapa 9 — Teste carga
Descubra o limite antes de os usuários descobrirem.
Etapa 10 — Planeje falhas
Defina o comportamento quando:
o modelo falhar;
o banco vetorial ficar indisponível;
a latência aumentar;
a cota acabar;
o documento não for encontrado.
23. Pontos para fixar no diário de bordo
Guarde estas ideias:
O modelo é um componente, não a plataforma inteira.
Escalabilidade envolve desempenho, custo, segurança, qualidade e operação.
Tokens afetam limites, latência e orçamento.
Contexto precisa ser selecionado, não apenas acumulado.
Embeddings permitem busca por significado.
Bancos vetoriais aceleram a recuperação semântica.
RAG conecta o modelo ao conhecimento atualizado.
Prompt engineering orienta comportamento, mas não corrige toda limitação.
Fine-tuning serve principalmente para especialização comportamental.
Model routing evita usar uma nave capitânia para entregar uma encomenda simples.
Cache reduz repetição e custo.
Streaming melhora a experiência percebida.
Batch continua essencial.
Guardrails protegem entradas, saídas e ações.
Avaliação contínua detecta regressões.
Observabilidade transforma “a IA errou” em um diagnóstico real.
Autoscaling prepara o sistema para picos.
Otimização de custos precisa considerar valor, não apenas preço por token.
Conclusão: a plataforma é a frota
O mercado adora discutir modelos.
Qual possui mais parâmetros?
Qual responde melhor?
Qual escreve código?
Qual aceita mais contexto?
Qual é mais barato?
Essas perguntas são úteis, mas insuficientes.
Uma plataforma escalável precisa funcionar em condições reais:
muitos usuários;
dados imperfeitos;
documentos conflitantes;
picos de acesso;
ameaças;
falhas;
mudanças de versão;
pressão de custo;
exigências regulatórias;
auditoria.
É nesse ambiente que a arquitetura mostra seu verdadeiro valor.
O modelo pode ser o cérebro da operação, mas ainda precisa de memória, sensores, controles, comunicação, proteção, supervisão e energia.
Um grande sistema de IA não nasce apenas da escolha de um modelo poderoso.
Ele nasce da integração disciplinada entre componentes.
Para o programador COBOL Padawan, existe uma vantagem inesperada: muitos desses princípios já fazem parte do universo mainframe há décadas.
Separação de responsabilidades.
Controle de acesso.
Processamento em lote.
Priorização de carga.
Observabilidade.
Auditoria.
Resiliência.
Otimização de recursos.
Recuperação após falhas.
A tecnologia mudou, mas a engenharia continua reconhecível.
No final da missão, a pergunta correta não é:
“Qual modelo está sendo utilizado?”
A pergunta madura é:
“Como tokenização, contexto, RAG, roteamento, segurança, avaliação, observabilidade, infraestrutura e custos trabalham juntos quando a plataforma está sob pressão?”
Se a equipe não consegue responder, talvez ainda não possua uma plataforma.
Talvez possua apenas uma demonstração bonita estacionada no hangar.
E como diria o Sr. Spock, olhando para um dashboard cheio de alertas:
“Uma inteligência sem arquitetura é apenas uma probabilidade esperando por um incidente.”
Portanto, jovem programador, quando alguém apresentar um novo modelo milagroso, admire sua capacidade, estude suas possibilidades e faça a pergunta que separa cadetes de oficiais experientes:
— Muito interessante. Mas onde estão os logs, os testes, os escudos, o roteamento, o controle de custo e o plano para quando ele falhar?
Nesse momento, você não estará mais pensando apenas como usuário de inteligência artificial.
Estará pensando como arquiteto de sistemas.
E a Frota Estelar precisa exatamente desse tipo de profissional.
Sem comentários:
Enviar um comentário