O sistema antigo da sua empresa sabe tudo. O problema é que ninguém consegue perguntar para ele

Todo sistema legado guarda anos de regras de negócio, decisões e exceções que ninguém mais lembra. Uma técnica chamada RAG permite consultar esse conhecimento em português simples, sem reescrever o sistema e sem parar a operação. Explicamos como ela funciona, onde ajuda de verdade e onde não adianta insistir.

O RAG fica ao lado do sistema antigo e só lê: busca o que responde à pergunta e mostra de onde veio.

Toda empresa com uns dez anos de estrada tem alguém assim. Essa pessoa sabe por que aquele cliente tem um desconto que não aparece em tabela nenhuma, por que a nota só sai se determinado campo estiver preenchido e o que acontece se mexerem na rotina de fechamento do mês. Nunca ninguém escreveu isso em lugar nenhum. Está na cabeça dela e, de um jeito mais espalhado, dentro do sistema.

Agora imagine o dia em que ela tira uma licença longa, vai para outra empresa ou se aposenta. O sistema continua funcionando normalmente. O que some é a possibilidade de perguntar alguma coisa a ele.

Quando quem conhece as ligações sai, o sistema continua lá, mas o caminho até a resposta se perde.

É esse buraco que o RAG ajuda a fechar, e dá para fazer isso sem trocar de sistema.

O legado é maior que o código

Quando alguém fala em sistema legado, a imagem que vem é a de um programa velho num servidor esquecido. Na vida real o legado é tudo junto: o sistema, o banco com quinze anos de registros, os manuais em PDF que ninguém atualiza, a pasta compartilhada cheia de planilhas com nomes duvidosos, o histórico de chamados do suporte e aquelas conversas de e-mail em que uma decisão importante foi tomada.

Isso tudo é difícil de mexer por dois motivos. O sistema funciona e dá dinheiro, então ninguém quer arriscar. E o conhecimento está em formatos que não conversam entre si. Para responder algo simples, como por que um pedido foi cancelado sozinho, alguém abre três telas, procura num PDF e ainda manda mensagem para um colega.

A saída clássica é a migração, reescrever tudo num sistema moderno. Às vezes é mesmo o melhor caminho, mas custa caro, leva meses e obriga a empresa a viver com dois sistemas ao mesmo tempo. Por isso tanta gente empurra o assunto por anos, e o problema só engorda.

O que é RAG, em português de gente

A sigla vem de Retrieval-Augmented Generation, algo como geração com consulta prévia. A ideia é simples, e entender ela desfaz um medo bem comum.

Um modelo de linguagem, desses que escrevem texto e respondem perguntas, sabe bastante sobre o mundo em geral e nada sobre a sua empresa. Se você perguntar a ele a regra de frete do seu sistema, ele vai inventar uma resposta que soa muito convincente. Esse é o grande defeito dessas ferramentas.

O RAG contorna isso mudando a ordem das coisas. Antes de o modelo responder, uma busca vai até os seus documentos, bancos e manuais e separa os trechos que têm a ver com a pergunta. Esses trechos vão para o modelo junto com a pergunta, com a instrução de responder só com base neles. A resposta chega dizendo de onde a informação veio, então dá para conferir.

Na prática fica assim: você pergunta, em português normal, qual é a regra de desconto para clientes com contrato anterior a 2019. O sistema procura nas fontes, não só pelas palavras exatas, mas pelo sentido. O modelo escreve a resposta com o que foi encontrado e aponta o documento ou a tela de origem. Se estiver errado, você vê exatamente onde.

O ponto que mais interessa a quem tem legado é que o RAG não encosta no sistema antigo. Ele fica ao lado e só lê. Não precisa reescrever código, trocar o banco nem treinar um modelo do zero com os dados da empresa, e é por isso que o risco de colocar isso no ar é pequeno.

A ideia, aliás, não é nova. O artigo que batizou a técnica é de 2020 e já propunha juntar um modelo de linguagem a uma base de documentos consultável. O que mudou desde então foi o custo e a qualidade das ferramentas, que agora permitem montar isso para uma empresa comum, e não só para gigante de tecnologia.

O que muda no dia a dia

Quem entra na empresa deixa de passar três meses pedindo ajuda aos veteranos. Consulta o assistente, vê de onde veio cada resposta, e os veteranos recuperam o tempo que gastavam explicando as mesmas coisas.

O suporte também sente. O atendente pergunta por que o boleto de determinado cliente foi recusado e recebe a regra, o histórico de casos parecidos e a tela onde se corrige. Resolve na primeira conversa o que antes pedia um chamado para o time técnico.

Auditoria e prestação de contas ficam menos dolorosas, porque descobrir quem aprovou o quê, e com base em qual regra, deixa de ser caça ao tesouro.

E tem um efeito que pouca gente enxerga de início. Se um dia a empresa decidir migrar, ter as regras de negócio documentadas e consultáveis já é metade do trabalho. Muita migração atrasa justamente porque ninguém sabe direito tudo o que o sistema antigo faz.

Onde não adianta

Tem coisa que o RAG não resolve, e vale saber antes de se empolgar. Se o sistema está lento ou cai toda semana, o problema é de infraestrutura e de código, e precisa de outro tipo de trabalho. Se a tecnologia está sem suporte e com falhas de segurança conhecidas, o RAG ajuda a entender o que existe, mas a atualização continua sendo necessária.

Se quase nada está documentado e o conhecimento mora só na cabeça das pessoas, dá para usar o RAG, mas antes é preciso tirar esse conhecimento de lá, com entrevistas, leitura do código e dos tickets antigos. E se os dados são uma bagunça, com três versões contraditórias da mesma regra, o assistente vai citar qualquer uma delas. O RAG funciona como espelho: devolve o que encontra, inclusive os erros. Boa parte do trabalho sério de implantação é decidir quais fontes merecem confiança e o que fazer com as desatualizadas.

Os cuidados que não dá para pular

Pôr um assistente para ler os dados da empresa pede atenção em alguns pontos, e todos têm solução se alguém pensar neles antes de lançar.

O primeiro é o vazamento entre áreas. Se o assistente lê tudo, qualquer funcionário pode acabar vendo o que só o financeiro deveria ver. O certo é respeitar as permissões que já existem: cada pessoa recebe só os trechos que já poderia abrir por conta própria.

Cada pessoa só recebe o que já poderia abrir. O pedido que cruza áreas é barrado.

O segundo são os dados pessoais. Cadastros de clientes e de funcionários estão sob a LGPD, então é preciso saber o que será indexado, por quanto tempo e onde fica guardado, e não mandar dado sensível para serviço externo sem controle.

Depois vem a resposta que parece certa e está errada. Reduz-se obrigando o assistente a citar a fonte e a admitir quando não achou nada, em vez de completar com palpite. Também há o índice que envelhece: o sistema muda e o assistente segue respondendo com a versão de seis meses atrás, então alguém precisa cuidar da atualização. E o custo, que cresce sem ninguém ver se cada consulta não for medida desde o primeiro dia.

Quem for contratar ou construir algo assim deveria ler a lista da OWASP, referência em segurança de software, que mantém um material só sobre os riscos de aplicações com modelos de linguagem.

Como começar sem apostar o orçamento do ano

O erro mais comum é querer indexar a empresa inteira de uma vez. O projeto fica grande, caro e demorado, e perde o apoio da diretoria antes de mostrar resultado.

Funciona melhor escolher uma pergunta que incomoda de verdade. Pode ser a dúvida que o suporte leva toda semana para o time técnico, ou a regra do módulo de faturamento que só duas pessoas dominam. Monta-se o assistente só para isso, com poucas fontes bem escolhidas, e coloca-se na mão de um grupo pequeno, para uso real.

Em vez da empresa inteira, o piloto começa por uma pergunta e poucas fontes.

Antes de começar, vale responder algumas coisas. Qual pergunta sua equipe repete toda semana e só um ou dois sabem responder? Onde está a informação que a responde: no sistema, no banco, em PDFs, em e-mails? Quem pode ver o quê, e há dado pessoal ou sigiloso no meio? Como vocês vão saber que o assistente acertou, e quem confere as primeiras respostas?

Com esse recorte, um piloto fica pronto em poucas semanas e a empresa decide com dados se vale ampliar. Se não valer, o custo foi pequeno e o aprendizado grande: no mínimo você descobre onde sua documentação está mais frágil.

Como a gente faz isso na 360 Brave

Somos um estúdio de engenharia de software e já trabalhamos por dentro de sistemas antigos, o que faz diferença. O difícil do RAG em legado nunca é o modelo. É entender o que o sistema faz e onde cada informação mora. No piloto de RAG para sistemas legados, entregamos um assistente funcionando sobre um recorte do seu sistema, com escopo, prazo e preço combinados antes de começar.

Tudo começa com uma conversa, em que você conta onde a equipe mais perde tempo procurando resposta. Depois mapeamos, com acesso só de leitura, onde estão as informações, em que estado e o que pode ser indexado com segurança, respeitando permissões e LGPD. Aí colocamos o piloto no ar: um assistente sobre o recorte combinado, que cita a fonte e admite quando não sabe, usado de verdade pelo seu time enquanto medimos os resultados. No fim mostramos o que funcionou, o que não funcionou e quanto custaria ampliar. Se fizer sentido, a gente expande. Se preferir, entregamos tudo documentado para o seu time seguir sozinho.

Como o assistente fica ao lado do sistema e não dentro dele, a operação segue rodando como sempre. E se mais adiante a empresa resolver modernizar o legado, o mapa que fizemos já serve de ponto de partida.

Se quiser saber se o seu caso é bom para isso, chame a gente. Primeiro a gente escuta e entende como o seu sistema funciona. Só depois de olhar com cuidado dá para dizer se faz sentido e, se fizer, propor escopo, prazo e preço do piloto. Se não fizer, a gente diz isso também.

Fontes

Postado por Guilherme

Vamos descobrir o que o seu sistema antigo sabe.

Conte, do seu jeito, qual pergunta a sua equipe repete toda semana. A gente retorna para entender melhor o seu cenário e combinar os próximos passos.

Prefere escrever direto? [email protected]

Usamos seus dados para responder e conversar sobre o seu projeto. Veja a política de privacidade.