Vectorless RAG — Quando Swordfish Entrou no Datacenter, Viu Igor Partindo o Manual em Pedacinhos e Perguntou: “Cadê o Mapa Dessa Coisa?”

 

Bellacosa Mainframe e o vectorless rag

☕ Um Café no Bellacosa Mainframe

Vectorless RAG — Quando Swordfish Entrou no Datacenter, Viu Igor Partindo o Manual em Pedacinhos e Perguntou: “Cadê o Mapa Dessa Coisa?”

Ou: Gabriel Shear queria roubar bilhões com glamour de cinema; Stanley Jobson só queria programar; o jovem padawan COBOL descobriu que um embedding gigante não conserta uma biblioteca que perdeu o índice — e Igor tentou resolver tudo com overlap de 30%

Existe uma cena invisível em quase todo projeto de Inteligência Artificial corporativa.

Ela acontece depois da apresentação bonita, depois do “chat com seus documentos”, depois que alguém afirma que agora a empresa poderá conversar com todo o seu conhecimento acumulado desde 1987 — incluindo PDFs, políticas, manuais, procedimentos, planilhas, contratos, normas, atas e aquele arquivo chamado POLITICA-FINAL-AGORA-VAI-v12.pdf.

No porão do datacenter, Igor recebe um manual de 800 páginas. Há diagramas, tabelas, versões, exceções, notas de rodapé e uma seção chamada “Leia isto antes de provocar uma indisponibilidade em produção”. Ele então faz o que recebeu ordem para fazer: pega uma tesoura semântica, corta o manual em pedaços de 500 tokens, coloca um número em cada pedaço, transforma cada um em vetor e anuncia:

“Pronto, chefe. Agora a máquina entende o documento.”

O veterano de produção cospe o café.

Não. A máquina passou a conhecer fragmentos do documento. Entender, localizar, respeitar a versão vigente, seguir uma referência cruzada e citar a seção correta é outra conversa.

É exatamente aí que entra a discussão de Vectorless RAG.

Não como uma nova religião de LinkedIn. Não como um produto milagroso vendido por Gabriel Shear numa sala escura com telas azuis, cifras piscando e uma trilha sonora cara. Mas como um lembrete muito necessário: talvez muitos projetos de RAG estejam tentando melhorar o componente errado.

Porque, jovem padawan COBOL, aumentar o embedding não resolve tudo. É o equivalente a comprar mais MIPS para um ambiente cujo verdadeiro problema é uma consulta Db2 sem índice, um batch que lê o mesmo VSAM cinco vezes ou uma regra de negócio enterrada no parágrafo 17 de uma apostila de 2014.

Sob a tutela cinematográfica de Swordfish, vamos entender RAG, vetores, estrutura documental, citações, contexto, arquitetura híbrida e por que o futuro não será “Vector RAG versus Vectorless RAG”.

Será arquitetura contra superstição.

Prólogo — Stanley Jobson, o manual de 800 páginas e a primeira armadilha

Em Swordfish, Stanley Jobson é apresentado como o sujeito que pode entrar em sistemas impossíveis. No mundo real, porém, o problema raramente é “invadir o mainframe”.

O problema de verdade costuma ser muito mais cruel:

“Esta operação pode ser autorizada?”

“Qual procedimento vale para este incidente?”

“A regra é a vigente ou é a versão que alguém esqueceu no SharePoint?”

“Quem deve agir quando o job falha por falta de espaço?”

“A resposta está na política, na exceção, na tabela, no apêndice ou no e-mail que ninguém indexou?”

Um sistema RAG, sigla para Retrieval-Augmented Generation, existe para dar ao modelo de linguagem uma fonte externa antes que ele responda. Em vez de confiar apenas naquilo que o LLM aprendeu no treinamento, buscamos documentos corporativos e dizemos:

“Responda com base nisto. E, se possível, não invente moda.”

A ideia é excelente.

O problema mora no PERFORM UNTIL.

O fluxo tradicional costuma ser:

Documento
→ extrair texto
→ quebrar em chunks
→ gerar embeddings
→ buscar por similaridade
→ enviar trechos ao LLM
→ gerar resposta

Um chunk é um pedaço de texto. Um embedding é uma representação numérica do significado aproximado daquele pedaço. Se a pergunta fala de “controle de acesso”, o sistema tenta encontrar pedaços que pareçam semanticamente relacionados a permissão, autenticação, perfil, privilégio, segurança e auditoria.

Tudo muito bonito.

Até o momento em que o documento não é uma coleção de frases soltas.

1. O que embeddings resolvem — e o que eles nunca prometeram resolver

Antes que algum purista da estrutura apareça com um crucifixo anti-vetorial, façamos justiça.

Embeddings são extremamente úteis.

Eles ajudam quando um usuário pergunta:

“Como impedir acesso indevido?”

Mas o manual usa palavras como:

• autorização;

• privilégios;

• perfis RACF;

• controle de acesso;

• segregação de funções;

• revisão periódica de permissões.

Uma busca por palavra exata talvez não localize nada. Já a busca vetorial consegue perceber que aquelas ideias pertencem à mesma vizinhança semântica.

É muito bom para:

• perguntas em linguagem natural;

• sinônimos;

• diferenças de vocabulário entre usuário e documentação;

• abreviações e variações de linguagem;

• busca multilíngue;

• descoberta inicial em uma base grande;

• documentos pouco estruturados, como e-mails, atas, artigos e FAQs.

Mas aí vem a placa de “atenção, área de produção”:

Similaridade semântica não é a mesma coisa que relevância operacional.

Imagine a pergunta:

“Qual perfil RACF deve aprovar pagamento acima de R$ 50 mil na política vigente?”

O sistema precisa saber mais que o significado aproximado de “aprovação” e “pagamento”.

Ele precisa considerar:

• a política atual;

• a versão vigente;

• o produto ou processo correto;

• o país ou unidade organizacional;

• a faixa de valor;

• o cargo responsável;

• a exceção;

• o registro de auditoria exigido.

Um documento de 2023 pode ser semanticamente quase idêntico ao de 2026. E ainda assim estar errado.

É como copiar um copybook antigo porque o campo tem o mesmo nome. Pode até compilar. O problema é descobrir, depois, que o layout mudou e o programa passou a ler a data como valor financeiro. Aí o S0C7 vira apenas o começo da conversa.

2. Chunking: quando cortar demais transforma contexto em carne moída

Para entender o problema, pense neste COBOL simples:

       IF VALOR-PAGAMENTO > LIMITE-OPERADOR
           PERFORM SOLICITA-APROVACAO
       ELSE
           PERFORM EXECUTA-PAGAMENTO
       END-IF.

Agora imagine Igor partindo isso em dois chunks.

No primeiro, fica:

       IF VALOR-PAGAMENTO > LIMITE-OPERADOR
           PERFORM SOLICITA-APROVACAO

No segundo:

       ELSE
           PERFORM EXECUTA-PAGAMENTO
       END-IF.

Quando alguém perguntar “o que acontece acima do limite?”, a busca pode recuperar o trecho errado, porque as palavras “pagamento” e “executa” também parecem relevantes.

Mas o sentido está na estrutura inteira do IF.

Documentos corporativos sofrem da mesma doença. Um procedimento pode ter:

1. uma condição de entrada;

2. uma regra principal;

3. uma exceção;

4. um responsável;

5. um prazo;

6. uma tabela;

7. uma referência para outro documento;

8. uma obrigação de registrar evidência.

Se o RAG recupera apenas a regra principal, ele pode gerar uma resposta aparentemente perfeita — e completamente perigosa.

“Então vamos aumentar o overlap!”

Overlap é a repetição de uma parte do final de um chunk no início do próximo. É útil. Ele impede que uma frase longa, um parágrafo ou uma explicação curta seja cortada no meio.

Mas overlap não é máquina do tempo, não é mapa e não é auditor.

Com overlap exagerado, começam os problemas:

• o banco fica cheio de chunks quase idênticos;

• os resultados principais trazem cinco versões da mesma frase;

• o prompt recebe repetição, mas não recebe cobertura;

• custo de armazenamento e embedding cresce;

• a tabela importante continua de fora;

• a exceção crítica continua escondida no apêndice B.

É como colocar cópias do mesmo JCL na fila do JES2 e se surpreender porque o relatório continua errado.

O problema não é necessariamente falta de texto.

É falta de coordenadas.

3. O documento não é uma pilha de chunks: ele é um mapa

É aqui que surge a ideia chamada Vectorless RAG.

Na definição séria, ela não significa “embeddings são proibidos; joguem o banco vetorial no rio Tietê”.

Ela significa:

não trate documentos ricos como uma pilha plana de pedaços independentes.

Um manual técnico possui estrutura natural:

Manual de Segurança z/OS
└── 4. Controle de Acesso
    ├── 4.1 Autenticação
    ├── 4.2 Autorização
    │   ├── 4.2.1 Perfis RACF
    │   └── 4.2.2 Revisão de privilégios
    └── 4.3 Auditoria
        ├── SMF 80
        └── Retenção de evidências

Essa árvore não é decoração de Word.

Ela carrega significado.

SMF 80, por exemplo, não é apenas um texto parecido com “segurança”. Ele pertence à auditoria, que pertence ao controle de acesso, que pertence ao manual de segurança. A hierarquia delimita o escopo da informação.

Uma arquitetura orientada à estrutura preserva dados como:

• título do documento;

• versão;

• data de vigência;

• proprietário;

• capítulo;

• seção;

• subseção;

• página;

• tabela;

• figura;

• nota de rodapé;

• referência cruzada;

• tipo de conteúdo;

• país;

• produto;

• classificação de segurança;

• permissões de acesso.

Em vez de guardar apenas:

chunk_4423 → vetor → texto

ela pode guardar algo como:

Documento: Manual de Segurança z/OS
Versão: 4.2
Vigência: 2026-03-01
Caminho: 4 > 4.3 > 4.3.1
Tipo: procedimento de auditoria
Referência: Política de Retenção 7.1
Permissão: Segurança Operacional

O texto ganhou endereço.

E endereço importa.

4. A operação em quatro atos: entender, indexar, navegar e provar

Ato 1 — Entender o documento

O sistema precisa extrair a estrutura real: títulos, níveis, listas, tabelas, rodapés, páginas, anexos e metadados.

Parece simples até você conhecer PDF corporativo.

PDF é o arquivo que promete ser documento, mas às vezes é uma fotografia com trauma.

Nele:

• cabeçalho vira parágrafo;

• número de página vira requisito;

• tabela vira sopa de colunas;

• OCR transforma zero em letra O;

• nota de rodapé invade outro assunto;

• título não tem estilo;

• imagem contém a regra mais importante;

• anexo tem uma versão diferente do documento principal.

Não existe RAG estrutural inteligente em cima de extração burra.

Para documentos críticos, valide uma amostra. Confira se a tabela saiu como tabela. Veja se capítulos e páginas foram reconhecidos. Confirme versão, data e dono do documento.

Não entregue a chave da tesouraria a um parser que acha que “Página 12 de 87” é regra de negócio.

Ato 2 — Indexar a estrutura

Depois de entender o documento, construímos um mapa navegável.

Uma seção precisa saber quem é seu pai, quem são seus filhos, quais tabelas pertencem a ela, quais outros documentos ela cita e qual versão governa aquela regra.

Em termos mainframe, é como entender que um campo não vive sozinho. Ele tem copybook, domínio, tamanho, validação, origem, regra de negócio, log e impacto.

No RAG, a seção também não pode viver sozinha.

Ela precisa carregar contexto.

Ato 3 — Navegar conforme a pergunta

Nem toda pergunta merece o mesmo método.

Pergunta:

“O que é RACF?”

Aqui, busca semântica funciona bem. Uma explicação introdutória basta.

Pergunta:

“Qual evento comprova uma tentativa negada de acesso?”

Aqui, o sistema precisa localizar a seção de auditoria, encontrar a evidência correta, trazer a tabela ou definição adequada e preservar o contexto.

Pergunta:

“O procedimento mudou entre a versão 4.1 e a 4.2?”

Aqui, vetor sozinho é perigoso. O melhor caminho é filtrar as duas versões, alinhar seções equivalentes, comparar o conteúdo e apontar a mudança.

Pergunta:

“Qual é a exceção da regra?”

Aqui, a arquitetura precisa suspeitar que a exceção talvez esteja logo depois da regra, em uma nota, um apêndice ou uma referência cruzada.

O retrieval deixa de ser “qual parágrafo parece parecido?” e passa a ser “qual caminho documental comprova isto?”.

Ato 4 — Gerar com prova

A resposta precisa ser gerada com evidência suficiente e citação compreensível.

Isto é aceitável:

Manual de Segurança z/OS, versão 4.2, seção 4.3.1, página 67.

Isto é pouco útil:

Fonte: chunk_4423.

chunk_4423 é etiqueta de caixa de depósito. Pode ser útil para o sistema, mas não para o analista, o auditor ou o operador que precisa conferir de onde surgiu a resposta.

5. Grounding: o nome bonito para “mostre de onde saiu isso”

Grounding é o processo de prender a resposta do LLM à evidência recuperada.

Ele reduz alucinações, facilita auditoria e permite contestação.

Mas atenção: citação não é garantia automática de verdade.

Uma IA pode colocar uma citação bonita depois de uma frase errada. Pode citar uma seção real que não sustenta a conclusão apresentada. Pode usar uma política antiga. Pode misturar trechos de versões diferentes.

Por isso, um RAG sério precisa ser avaliado por mais que “a resposta ficou convincente”.

Pergunte:

• a resposta está correta?

• ela está completa?

• a seção citada sustenta a frase?

• a versão usada é a vigente?

• a exceção foi considerada?

• a resposta respeitou permissões?

• o sistema soube dizer “não sei”?

A capacidade de dizer “não encontrei evidência suficiente” é sinal de maturidade.

É o equivalente digital de um operador experiente que não executa uma mudança em produção porque alguém, num Teams às 18h42, disse: “é só ajustar uma coisinha”.

6. Não é Vector RAG versus Vectorless RAG: é RAG híbrido

Aqui está o ponto central.

O futuro corporativo dificilmente será uma escolha religiosa entre vetor e estrutura.

Será híbrido.

Recurso	Onde costuma brilhar
Busca lexical/BM25	Siglas, códigos, campos, mensagens como IEC030I
Embeddings	Sinônimos, perguntas naturais, descoberta semântica
Metadados	Versão, vigência, país, sistema, sigilo e permissões
Hierarquia documental	Seção correta, contexto, tabelas, exceções e citação
Reranking	Separar o parecido do realmente relevante
Referências e grafos	Anexos, normas relacionadas e dependências

É parecido com o mainframe.

Ninguém diz que JES2 deve substituir RACF.

Ninguém diz que Db2 deve substituir CICS.

Ninguém diz que VSAM deve substituir toda a infraestrutura.

Cada coisa possui responsabilidade.

A arquitetura madura combina as ferramentas sem entregar o teclado para o componente mais barulhento da sala.

Uma rota saudável pode ser:

Pergunta
→ identificar intenção, domínio e permissões
→ executar busca lexical e vetorial
→ filtrar por versão e metadados
→ reranquear candidatos
→ localizar documento e seção
→ expandir para contexto, tabela, exceção e referência
→ gerar resposta com fontes
→ validar citações antes de responder

O salto não está em recuperar cinquenta chunks.

Está em recuperar a menor quantidade de evidência que seja correta, suficiente, atual e explicável.

Mandar o manual inteiro para uma janela de contexto gigantesca não é inteligência. Às vezes é apenas despejar o armário inteiro do operador no colo do estagiário e chamar aquilo de Agentic AI.

7. Mini-lab: aprovação de pagamento

Imagine que a empresa possui:

• Política de Aprovação de Pagamentos, versão 2026;

• Manual de Operação CICS;

• Runbook de incidentes batch;

• Política antiga de pagamentos, versão 2023.

A pergunta chega:

“Quem aprova pagamento acima de R$ 50 mil e o que deve ficar registrado?”

O RAG pobre

1. Quebra todos os documentos em chunks.

2. Gera embeddings.

3. Recupera os cinco mais parecidos.

4. Envia tudo ao LLM.

Ele pode trazer:

• uma regra velha de R$ 30 mil;

• um chunk sobre aprovação de pagamentos;

• um parágrafo de logs;

• um trecho de CICS que não deveria estar ali;

• uma exceção sem a regra principal.

A resposta poderá ser elegante, fluente e errada.

O pior tipo de errada: aquela que parece certa para quem não tem tempo de conferir.

O RAG orientado à evidência

1. Classifica a pergunta como normativa e financeira.

2. Filtra o documento pela versão vigente.

3. Busca termos exatos: “50 mil”, “alçada”, “aprovação”.

4. Usa busca semântica para encontrar variações como “limite decisório”.

5. Localiza a seção de alçadas.

6. Recupera a tabela de valores.

7. Busca a seção de retenção e auditoria.

8. Traz a exceção aplicável, se houver.

9. Gera resposta com duas ou três citações diretas.

10. Se encontrar conflito entre documentos vigentes, não improvisa: sinaliza.

O LLM continua sendo útil.

Mas ele deixa de ser bibliotecário, advogado, auditor, operador de produção e vidente ao mesmo tempo.

8. Custo e complexidade: café grátis não existe

Vectorless RAG é apresentado, às vezes, como uma maneira de escapar do custo de embeddings e bancos vetoriais.

Pode ajudar, especialmente em acervos estruturados.

Mas não existe almoço grátis. Nem cafezinho grátis em projeto de IA.

Você troca parte do custo vetorial por custos como:

• OCR de qualidade;

• extração de layout;

• classificação de títulos e tabelas;

• construção de hierarquias;

• manutenção de versões;

• controle de acesso;

• rastreabilidade;

• avaliação;

• revisão humana.

Para uma FAQ pequena e informal, isso pode ser um canhão para matar mosquito.

Para documentos jurídicos, relatórios financeiros, procedimentos operacionais, manuais técnicos, políticas de segurança, contratos e conhecimento regulado, vale muito a pena.

Porque, nesses casos, o custo do erro é maior que o custo do índice.

9. Dez dicas para o padawan não transformar IA em ABEND

1. Comece pelas perguntas reais. Reúna dúvidas que operadores, analistas e clientes realmente fazem.

2. Classifique o acervo. FAQ solta aceita vetor. Manual com capítulos e tabelas exige estrutura. Norma com vigência exige metadados.

3. Nunca perca versão e origem. Documento sem dono, data e status de vigência é uma bomba-relógio documental.

4. Não use chunk fixo como religião. Respeite títulos, parágrafos, tabelas, blocos de código e procedimentos.

5. Trate tabelas como informação de primeira classe. Em finanças e operação, a resposta quase sempre mora nelas.

6. Filtre antes de gerar. Permissão, sigilo e versão não podem ser enfeite de pós-processamento.

7. Meça citações, não só respostas. A fonte realmente prova o que a IA afirmou?

8. Crie uma rota honesta para o “não sei”. Melhor uma resposta incompleta e explícita que uma decisão errada e confiante.

9. Registre a trilha. Pergunta, documentos localizados, seções recuperadas, versão usada e resposta final. Esse é o SMF do seu RAG.

10. Melhore retrieval antes de trocar de modelo. Um LLM brilhante com evidência ruim continua sendo um gênio preso num almoxarifado sem inventário.

Easter egg — O arquivo secreto de Gabriel Shear

No universo de Swordfish, o segredo está em dinheiro, conspiração e espetáculo.

No universo corporativo, o arquivo realmente perigoso costuma ser:

POLITICA-FINAL-DEFINITIVA-v7-USAR-ESTA.pdf

Ao lado dele existem:

POLITICA-FINAL-DEFINITIVA-v7-USAR-ESTA(1).pdf

e:

POLITICA-NOVA-VALIDA-AGORA-AGORA-SIM.pdf

Nenhum embedding do planeta conserta sozinho uma governança documental que decidiu fazer cosplay de ABEND.

Antes de construir uma IA que responde, a empresa precisa saber:

• qual documento é verdade;

• quem é dono dele;

• quando entra em vigor;

• quando deixa de valer;

• quem pode lê-lo;

• quais documentos dependem dele.

A IA não cria ordem a partir de caos documental. Ela apenas responde ao caos com mais velocidade.

Epílogo — O mapa vale mais que o músculo

O programador COBOL iniciante não precisa decorar todas as siglas de IA para participar dessa conversa.

Basta reconhecer um princípio que o mainframe já ensinava antes de boa parte do Vale do Silício descobrir a palavra “contexto”:

Dado sem contexto é candidato a incidente.

Um campo COBOL não vive sozinho. Ele tem copybook, domínio, validação, origem e impacto.

Um programa não vive sozinho. Ele tem JCL, scheduler, dataset, CICS, Db2, RACF, JES2, WLM e alguém de plantão tentando impedir que uma alteração “pequena” transforme a madrugada em reunião de crise.

Documentos também não vivem sozinhos.

Eles têm capítulos, versões, anexos, tabelas, exceções, referências e responsáveis.

Um RAG que destrói tudo isso em pedaços soltos pode ser rápido no piloto. Pode gerar uma demo bonita. Pode impressionar a diretoria com uma pergunta preparada.

Mas, quando precisar responder algo que importa, ele talvez encontre uma frase correta no documento errado, na versão errada, com a exceção faltando.

Por isso, a pergunta certa não é:

“Qual embedding é maior?”

A pergunta certa é:

“Como esta pergunta encontra a evidência correta, vigente, permitida, suficiente e auditável?”

Às vezes a resposta será busca vetorial.

Às vezes será busca lexical.

Às vezes será uma árvore documental.

Às vezes será metadado.

Na prática, quase sempre será uma arquitetura híbrida, com reranking, contexto controlado, citações verificáveis e a coragem técnica de dizer “não sei”.

Gabriel Shear venderia uma caixa-preta muito chamativa.

Stanley Jobson tentaria fazê-la funcionar.

Mas o profissional de verdade — aquele que terá de explicar a resposta ao auditor, ao operador e ao cliente — constrói o mapa, preserva a trilha e não entrega o cofre para Igor só porque ele aprendeu a pronunciar “embedding”.

Conhecimento legado preparando o futuro. Porque nem todo problema precisa virar um ABEND — mas todo RAG precisa saber onde está a seção 7.3.