RAG na prática: como colocar o conhecimento da sua empresa dentro de um assistente de IA

Toda empresa tem o mesmo problema de conhecimento. A informação existe — está no manual de procedimentos, no contrato assinado ano passado, na apresentação que o diretor fez em março, no e-mail que explicou a exceção da regra. Mas ninguém encontra. Então as pessoas perguntam para colegas, os colegas respondem de memória, e a memória de cada um diverge um pouco. Ao longo do tempo, a empresa opera com várias versões da verdade.

RAG — sigla em inglês para geração aumentada por recuperação — é a técnica que ataca esse problema. Em vez de esperar que um modelo de linguagem "saiba" as informações da sua empresa, o sistema busca os documentos relevantes no momento da pergunta e pede ao modelo que responda com base neles, citando a fonte.

É a arquitetura mais usada em assistentes corporativos, e também a que mais falha silenciosamente quando mal construída. Este artigo trata de como fazer certo.

Por que RAG e não treinar um modelo próprio

A primeira pergunta que aparece é se não seria melhor treinar um modelo com os dados da empresa. Para a esmagadora maioria dos casos corporativos, não.

Custo e prazo. Ajustar um modelo exige infraestrutura, dados rotulados e tempo. RAG entra no ar em semanas.

Atualização. Quando um procedimento muda, com RAG você substitui o documento e o sistema já responde diferente na próxima pergunta. Com um modelo ajustado, é preciso retreinar.

Rastreabilidade. RAG cita a fonte. O usuário clica e verifica. Um modelo ajustado responde do "conhecimento interno" e não há como auditar de onde veio aquilo — o que é inaceitável em ambiente corporativo.

Controle de acesso. Com RAG, o filtro de permissão é aplicado na busca. Com um modelo treinado sobre todos os documentos, a informação restrita está incorporada nos pesos e pode vazar em qualquer resposta.

Ajuste de modelo tem seu lugar — principalmente para adaptar formato, tom ou domínio muito específico. Mas para responder com base em conhecimento organizacional, RAG é a resposta certa em praticamente todos os cenários.

A arquitetura, camada por camada

1. Ingestão

Coleta dos documentos das fontes originais: repositórios de arquivos, intranet, sistema de gestão documental, base de chamados, wiki, e-mail institucional quando aplicável.

Aqui aparecem os primeiros obstáculos reais. PDFs escaneados sem camada de texto exigem reconhecimento óptico. Planilhas complexas perdem sentido quando convertidas linearmente. Apresentações têm informação em imagens. Documentos antigos usam terminologia que ninguém mais usa.

A decisão mais importante desta camada não é técnica: é o que não entra. Documentos rascunho, versões antigas, materiais de projetos cancelados e conteúdo contraditório envenenam o sistema. Curadoria inicial vale mais do que qualquer otimização posterior.

2. Divisão em trechos

O documento inteiro raramente cabe no contexto do modelo, então ele é dividido. Esta etapa determina boa parte da qualidade final e costuma ser tratada com descaso.

Divisão por tamanho fixo é o padrão de ferramentas prontas e o pior método na prática: ela corta no meio de uma frase, separa uma cláusula do seu título e destrói o contexto que dá sentido ao trecho.

O que funciona melhor:

• Dividir respeitando a estrutura do documento — por seção, artigo, cláusula, item numerado. A estrutura já foi criada por um humano para agrupar significado.
• Manter sobreposição entre trechos vizinhos, tipicamente de 10% a 20%, para que uma informação na fronteira não se perca.
• Adicionar cabeçalho contextual em cada trecho: título do documento, seção, data de vigência. Um trecho que diz "o prazo é de 30 dias" é inútil sem saber prazo de quê, em qual política e desde quando.
• Preservar tabelas inteiras sempre que possível. Tabela cortada gera resposta errada com aparência de certa.

3. Indexação e metadados

Cada trecho é convertido em vetor e armazenado com metadados. Os metadados são tão importantes quanto o vetor:

Origem do documento, data de publicação e de última revisão, versão, área responsável, classificação de sigilo, lista de perfis autorizados e status de vigência.

Sem esses campos, é impossível filtrar por permissão, priorizar conteúdo recente ou remover documento revogado.

4. Recuperação

Dada uma pergunta, o sistema seleciona os trechos mais relevantes. Três decisões definem a qualidade:

Busca híbrida. Combinar busca vetorial, que capta similaridade de significado, com busca por palavra-chave, que acerta termos exatos — códigos de produto, números de norma, nomes próprios, siglas internas. Busca puramente vetorial falha justamente nos termos precisos que mais importam em ambiente corporativo.

Reordenação. Recuperar mais candidatos do que o necessário e reordená-los com um modelo especializado antes de enviar ao gerador. Melhora significativamente a precisão a um custo modesto.

Filtro de permissão aplicado na busca. Este ponto é inegociável e é a falha de segurança mais comum em implementações apressadas. O filtro precisa acontecer na recuperação, restringindo o conjunto de candidatos ao que o usuário pode ver. Filtrar depois da geração é tarde demais: a informação já entrou no contexto e pode vazar na formulação da resposta.

5. Geração com citação obrigatória

O modelo recebe a pergunta e os trechos, com instrução clara: responder apenas com base no material fornecido, citar a origem de cada afirmação e declarar explicitamente quando a informação não está disponível.

Esse último comportamento — admitir que não sabe — é o mais valioso e o mais difícil de obter. Modelos tendem a preencher lacunas. A instrução precisa ser explícita, testada e verificada no conjunto de avaliação.

Os erros que destroem a confiança do usuário

Assistentes internos morrem por perda de confiança, não por falha técnica. Basta um punhado de respostas erradas com aparência confiante para que o time volte a perguntar para colegas.

Conteúdo desatualizado no índice. O sistema responde com a política revogada porque o documento antigo continua indexado. Solução: campo de vigência obrigatório e processo de remoção junto com o de publicação.

Documentos contraditórios sem hierarquia. Três documentos dizem coisas diferentes sobre o mesmo procedimento e o sistema escolhe um deles aleatoriamente. Solução: definir hierarquia de fontes nos metadados e instruir o modelo a apontar a divergência em vez de escolher.

Trechos sem contexto. Já discutido, e responsável por boa parte das respostas ruins.

Ausência de citação. Sem link para a fonte, o usuário não consegue verificar e não confia. Com link, mesmo uma resposta parcialmente imprecisa é útil, porque conduz ao documento certo.

Cobertura silenciosa. O sistema responde bem sobre RH e mal sobre a área técnica, mas ninguém percebe porque não há métrica por domínio. Solução: avaliar por categoria, não só no agregado.

Uma resposta "não encontrei essa informação nos documentos disponíveis" preserva a confiança. Uma resposta inventada a destrói permanentemente.

Avaliação: sem isso, você está no escuro

Esta é a parte que separa implementação profissional de demonstração.

Construa um conjunto de 100 a 300 perguntas reais, coletadas do time que vai usar o sistema, com resposta correta e documento de origem validados por especialista. Inclua deliberadamente:

• Perguntas cuja resposta não está na base — para medir se o sistema admite desconhecimento.
• Perguntas ambíguas, para verificar se pede esclarecimento.
• Perguntas cuja resposta mudou ao longo do tempo, para testar vigência.
• Perguntas que exigem combinar dois documentos.
• Perguntas que um usuário sem permissão não deveria conseguir responder.

Meça quatro coisas: se os trechos certos foram recuperados, se a resposta está correta, se a citação corresponde ao que foi afirmado, e a taxa de invenção. Rode esse conjunto a cada mudança de prompt, de modelo, de estratégia de divisão ou de base.

Sem esse conjunto, cada ajuste é um palpite e cada melhoria aparente pode estar quebrando outra coisa.

Custos e desempenho

O custo operacional de um sistema RAG tem três componentes: geração de vetores na ingestão (uma vez por documento, mais reprocessamento quando muda), armazenamento vetorial (proporcional ao volume, geralmente modesto) e inferência por pergunta (o item dominante).

Alavancas de otimização que funcionam:

• Cache de perguntas frequentes. Em bases corporativas, a distribuição é extremamente concentrada: poucas perguntas respondem pela maior parte do volume.
• Enviar menos trechos, melhor selecionados. Reordenação bem feita permite reduzir o contexto sem perder qualidade, e o contexto é o que domina o custo.
• Modelo menor para tarefas auxiliares — reformulação de pergunta, classificação de intenção — reservando o modelo maior para a geração final.
• Reindexação incremental, processando apenas o que mudou.

Sobre latência: usuários toleram bem 2 a 4 segundos quando há indicação de progresso e a resposta é boa. Toleram muito mal resposta instantânea e errada.

Como estruturar o projeto

Fase 1 — Escopo estreito. Escolha um domínio único e bem delimitado: apenas políticas de RH, ou apenas documentação de um produto. Um assistente excelente em um domínio conquista adoção; um assistente medíocre em dez domínios é abandonado.

Fase 2 — Curadoria. Levante os documentos, remova versões antigas, resolva contradições, defina responsável pelo conteúdo. Esta fase geralmente consome mais tempo do que a implementação técnica, e é a que mais determina o resultado.

Fase 3 — Construção e avaliação. Implementação com o conjunto de avaliação desde o início, não depois.

Fase 4 — Piloto com feedback fácil. Botão de "resposta útil / não útil" em cada interação, com campo livre opcional. Esse feedback alimenta o conjunto de avaliação e mostra onde a base tem lacunas.

Fase 5 — Expansão domínio a domínio, repetindo a curadoria a cada novo escopo.

Onde os projetos travam de verdade

Se listássemos as causas reais de atraso em implantações de RAG que acompanhamos, quase nenhuma seria técnica.

Ninguém sabe onde está o documento oficial. Existem quatro cópias da política de reembolso em três lugares diferentes, todas ligeiramente distintas, e não há autoridade estabelecida para dizer qual vale. O projeto para até que alguém decida — e essa decisão é organizacional, não técnica.

O acervo está em formato hostil. Contratos digitalizados como imagem, planilhas com informação em células mescladas, apresentações onde o conteúdo está dentro de figuras. A conversão exige trabalho e, em alguns casos, redigitação. Vale medir o custo desse esforço antes de prometer prazo.

As permissões não estão modeladas em lugar nenhum. A empresa sabe informalmente quem pode ver o quê, mas isso não existe como estrutura de dados consultável. Construir esse mapeamento costuma ser a etapa mais longa do projeto em organizações com controle de acesso maduro apenas nos sistemas transacionais.

Falta dono do conteúdo. A TI implanta, mas ninguém do negócio assume manter a base atualizada. O sistema entra no ar bom e envelhece rápido.

Expectativa desalinhada. O patrocinador esperava um sistema que respondesse qualquer pergunta sobre a empresa; o escopo entregue cobre um domínio. Sem alinhamento explícito no início, um bom resultado é recebido como decepção.

A recomendação prática: trate essas cinco questões como itens formais do plano de projeto, com responsável e prazo, e não como pressupostos. Elas determinam o cronograma muito mais do que a escolha de qualquer componente técnico.

Sinais de que o projeto está indo bem

Depois de alguns meses em produção, os indicadores que importam: percentual de perguntas respondidas sem escalonamento, taxa de avaliação positiva, número de usuários ativos recorrentes (adoção espontânea é o melhor sinal), e redução de perguntas repetidas nos canais internos.

O indicador mais revelador de todos, porém, é qualitativo: o time começa a reclamar quando um documento está desatualizado no assistente. Isso significa que passaram a tratá-lo como fonte oficial — que era o objetivo.

Conclusão

RAG é uma tecnologia madura e acessível, mas o resultado depende muito mais de disciplina de conteúdo do que de sofisticação técnica. Curadoria, metadados corretos, permissões aplicadas na busca, citação obrigatória e avaliação sistemática entregam mais qualidade do que qualquer otimização de modelo.

A pergunta que define o sucesso do projeto não é qual banco vetorial usar. É: quem é o dono do conteúdo e como ele será mantido atualizado?

A BHELP.tech implanta assistentes de conhecimento com essa disciplina — curadoria conduzida junto com as áreas, permissões respeitadas, avaliação mensurável e transferência de operação para o time interno. Se a sua empresa tem informação demais e acesso de menos, é um bom lugar para começar.