Pular para o conteúdo

Software HouseIA no software7 min de leitura

RAG explicado para quem decide: quando os documentos da empresa viram resposta confiável, e quando não viram

RAG é um jeito de fazer o modelo de linguagem responder consultando os documentos da empresa, em vez de depender só do que aprendeu no treinamento. Funciona quando o documento está atualizado e tem dono, quando a permissão de acesso é respeitada e quando a resposta mostra a fonte para alguém revisar.

Neste artigo6 partes
  1. O que é RAG em linguagem de quem decide
  2. As três condições para funcionar
  3. LGPD e dado pessoal na base de documentos
  4. O que a Pocket já faz de parecido: dado publicado para uma rede de parceiros
  5. A mesma mecânica vista de fora: como um modelo encontra e cita a sua marca
  6. Quando não vale a pena
  7. Perguntas frequentes

O que é RAG em linguagem de quem decide

RAG é a sigla em inglês para geração aumentada por recuperação. Na prática, é um jeito de fazer um modelo de linguagem responder consultando os documentos da sua empresa, em vez de depender só do que ele aprendeu no treinamento. O sistema primeiro busca os trechos certos nos documentos. Depois pede ao modelo que responda com base neles e indique de onde tirou cada informação.

É isso. O conceito cabe em duas frases e não exige conhecimento técnico para ser avaliado. O que exige atenção é o que vem antes do modelo: os documentos, quem pode vê-los e como a resposta é conferida.

Esse ponto segue a regra que orienta todo uso de IA na Pocket Lab, descrita em o que a IA faz e o que continua humano num projeto de software. A IA tira o repetitivo do caminho, como procurar o trecho certo entre centenas de arquivos. Decidir o que entra na base, quem acessa e se a resposta está certa continua com pessoas.

RAG não elimina o erro da IA. Ele muda o lugar onde o erro aparece: do modelo para o documento.

Compartilhar esta frase

O que o modelo faz e o que a base de documentos faz

Num projeto de RAG há duas peças com papéis diferentes.

A base de documentos guarda o conhecimento da empresa: manuais, políticas, contratos-padrão, fichas técnicas, perguntas frequentes do atendimento. Ela é organizada para que um mecanismo de busca encontre rapidamente os trechos ligados a uma pergunta. É a base que define o que o sistema sabe.

O modelo de linguagem recebe a pergunta e os trechos encontrados, e escreve a resposta. Ele define como o sistema fala: o tom, a síntese, a clareza. Não define o conteúdo. Se o trecho estiver errado, o modelo vai escrever bem uma resposta errada.

Por que isso não elimina o erro, mas muda onde ele aparece

Sem RAG, o erro mais comum de um modelo é inventar: produzir uma resposta plausível sobre algo que ele não sabe. Com RAG, esse risco diminui, porque o modelo responde a partir de um texto concreto. Mas surgem outros pontos de falha.

  • O documento está desatualizado. A resposta sai fiel a uma política que já mudou.
  • A busca trouxe o trecho errado. A pergunta era sobre um produto e o sistema encontrou o manual de outro.
  • O modelo interpretou mal. O trecho estava certo e a síntese inverteu uma condição.

Nenhum desses erros se resolve trocando de modelo. Eles se resolvem com dado cuidado e resposta que pode ser conferida. Daí as três condições a seguir.

As três condições para funcionar

RAG costuma funcionar quando três condições estão presentes: o documento está atualizado e tem dono, a permissão de acesso é respeitada e a resposta mostra a fonte para alguém revisar. As três dependem mais de dado e de processo do que de tecnologia.

Documento atualizado e com dono

Cada conjunto de documentos precisa de uma pessoa responsável por mantê-lo correto. Não a TI, que cuida da infraestrutura, mas a área que conhece o assunto: o jurídico para os contratos-padrão, a engenharia para as fichas técnicas, o atendimento para as respostas frequentes.

Também precisa existir uma versão oficial. Se o mesmo manual circula em quatro pastas, com datas diferentes, o sistema vai encontrar qualquer uma delas. Antes de indexar, é preciso decidir qual vale e retirar as outras.

Permissão de acesso respeitada

Numa empresa, nem todo mundo pode ler tudo. A tabela de comissão não é do mesmo grupo que o manual de produto. Um sistema de RAG precisa herdar essa regra: a resposta para um usuário só pode usar trechos de documentos que aquele usuário poderia abrir por conta própria.

Esse é um dos pontos em que mais projetos tropeçam. Junta-se tudo numa base só, por conveniência, e a IA passa a resumir para qualquer pessoa o que estava protegido. O desenho correto trata a permissão como parte da busca, não como filtro depois da resposta.

Resposta com fonte citada e revisável

Toda resposta deveria indicar de quais documentos e trechos saiu, com acesso direto ao original. Isso faz duas coisas. Permite que quem perguntou confira antes de agir. E permite que o dono do documento descubra quando o texto está velho, porque a resposta errada aponta para ele.

Resposta sem fonte pede confiança. Resposta com fonte pede leitura, e é isso que mantém uma pessoa no circuito nas decisões que importam.

Teste a base de documentos da sua empresa: marque o que vale para ela

Marque os itens. O resultado aparece aqui.

LGPD e dado pessoal na base de documentos

Se a base de documentos contém dado pessoal, o projeto de RAG passa a envolver a LGPD. Isso não impede o projeto, mas muda o desenho. As perguntas certas aparecem antes da tecnologia, e a resposta final sobre a base legal é do jurídico da empresa.

Na prática, isso significa colocar três áreas na mesma conversa desde o começo: a área dona dos documentos, a TI, que responde pela infraestrutura e pelo acesso, e o jurídico, que responde pela base legal. Quando uma delas entra só no fim, o projeto costuma voltar algumas casas.

A Pocket Lab trabalha com adequação à LGPD em sites e formulários, e a lição que vale aqui é a mesma de lá: o risco costuma estar no dado que ninguém lembrava que estava ali.

Que dado entra na base e com qual base legal

Contratos têm nome e documento de pessoas. Históricos de atendimento têm telefone, endereço e, às vezes, informação sensível. Planilhas antigas guardam o que ninguém lembra. O primeiro passo é um inventário: o que existe nos arquivos que vão para a base, e se há fundamento para usar esse dado nessa finalidade.

Quando o dado pessoal não é necessário para responder, o melhor caminho costuma ser retirá-lo ou anonimizá-lo antes de indexar.

Para onde o dado vai quando passa por um modelo de linguagem

Na consulta, os trechos encontrados são enviados ao modelo junto com a pergunta. Se o modelo roda num serviço externo, o dado sai do ambiente da empresa. É preciso saber em que país esse serviço opera, se ele guarda o que recebe, por quanto tempo e se usa esse conteúdo para outros fins. Essas respostas estão no contrato do serviço, não na demonstração do produto.

Retenção e exclusão

Quando um titular pede a exclusão dos próprios dados, ou quando um documento perde a validade, ele precisa sair da base de documentos e dos índices de busca derivados dela. Um projeto bem desenhado prevê esse caminho desde o início. Sem ele, o dado apagado da pasta continua aparecendo nas respostas.

O que a Pocket já faz de parecido: dado publicado para uma rede de parceiros

A Pocket Lab não apresenta um case de RAG. O que temos é experiência adjacente, em portais que publicam dados de uma empresa para uma rede de parceiros. Não há IA nesse trabalho. Há os mesmos problemas de base.

Num portal desse tipo, a pergunta central é a mesma de um projeto de RAG: qual informação é a oficial, quem é responsável por ela e o que cada parceiro deve ver. Publicar dado para uma rede obriga a decidir a versão que vale, a manter a publicação atualizada e a tratar a informação de forma que a rede confie no que encontra.

Três hábitos desse tipo de projeto se transferem para RAG sem adaptação:

  • Uma fonte oficial por informação. Antes de publicar, decide-se de onde o dado vem e qual versão vale.
  • Um responsável pelo que é publicado. Alguém da área de negócio responde pelo conteúdo, e não só quem construiu o sistema.
  • Atualização como rotina. Publicar uma vez é fácil. O trabalho está em manter a informação correta mês após mês.

É desse lugar que vem a nossa leitura de RAG. A parte difícil raramente é o modelo. É a disciplina sobre o dado que alimenta o modelo, e ela se aprende em projetos sem IA nenhuma.

A mesma mecânica vista de fora: como um modelo encontra e cita a sua marca

A lógica de RAG também funciona do lado de fora da empresa. Ferramentas de IA que respondem com base na web fazem algo parecido: buscam fontes, selecionam trechos e escrevem uma resposta, muitas vezes citando de onde tiraram.

Isso quer dizer que o conteúdo público da sua empresa passa pela mesma peneira. Texto claro, atualizado, com afirmações verificáveis e autoria definida tende a ser encontrado e usado. Texto vago ou contraditório tende a ficar de fora. As condições que valem para a base interna valem, com outro nome, para o site.

Quem cuida dessa frente é o time de marketing, e o assunto tem um texto próprio: como empresas B2B passam a ser encontradas e citadas por ferramentas de IA.

Quando não vale a pena

RAG não vale a pena quando os documentos estão desatualizados ou sem dono, quando a base é pequena e uma busca comum resolve, quando há dado pessoal sem base legal, quando a resposta precisa ser exata e não há quem revise, ou quando o problema deveria ser corrigido na origem.

  • Documentos desatualizados ou sem dono. O sistema vai responder com segurança o que já não vale. Organize a base primeiro.
  • Base pequena. Se são vinte documentos bem nomeados, uma boa busca e uma página de perguntas frequentes costumam bastar.
  • Dado pessoal sem base legal. Sem fundamento para usar o dado nessa finalidade, o projeto não começa até isso estar resolvido.
  • Resposta que precisa ser exata, sem revisor. Valor de contrato, dosagem, especificação de segurança. Se não há pessoa conferindo, a resposta não deveria vir de um modelo.
  • Problema de origem. Se as pessoas perguntam sempre a mesma coisa porque o processo é confuso, corrigir o processo rende mais do que responder melhor sobre ele.

Se a sua base passou por esses filtros, o próximo passo é técnico: como o sistema de RAG conversa com a intranet, o CRM ou o ERP que já existem. Tratamos disso em como integrar IA aos sistemas que a empresa já tem. Antes de contratar, vale levar estas perguntas.

Leve para a reunião com o fornecedor do projeto de RAG

  1. Quais documentos entram na base e quem é o dono de cada conjunto?
  2. Como a permissão de acesso de cada usuário é respeitada na resposta?
  3. A resposta mostra a fonte, com link para o trecho usado?
  4. Para onde vai o dado quando passa pelo modelo, e ele fica guardado lá?
  5. Como um documento é atualizado ou excluído da base?
  6. O que acontece quando o sistema não encontra resposta?

Se o seu projeto já está na mesa, conheça como trabalha a Software House da Pocket Lab.

Perguntas frequentes

O que é RAG?

É uma técnica em que o sistema busca trechos nos documentos da empresa e pede ao modelo que responda com base neles, citando a fonte.

RAG elimina erro da IA?

Não. Reduz a dependência do que o modelo memorizou, mas o erro pode vir de documento antigo, busca falha ou má interpretação. Por isso a fonte citada e a revisão importam.

RAG tem risco de LGPD?

Sim, quando a base contém dado pessoal. É preciso saber que dado entra, com qual base legal, para onde vai e como é excluído.

Este artigo foi útil?

Compartilhar
Vinícius Mont Serrat

Quem escreveu

Vinícius Mont Serrat

Cofundador e diretor executivo da Pocket Lab

Trabalha com internet desde 2008. Na Pocket Lab, responde pela estratégia, pelas grandes contas e pela Software House. Texto com revisão técnica do time.

Ver todos os artigos LinkedIn

Seus documentos estão prontospara responder por você?

Conheça como a Software House da Pocket Lab avalia dado, acesso e risco antes de propor qualquer projeto com IA.

Conhecer a Software House