RAG em empresas: 80% dos problemas estão nos dados, não no modelo

Um protótipo de RAG é montado em uma semana e mostrado em uma demo. Parece mágico: o modelo responde com base nos seus documentos e não alucina a partir de conhecimento geral. Mas, depois de algumas semanas em produção, o sistema começa a confundir versões, perde contexto e entrega com toda a confiança respostas baseadas em fontes que não existem. Esse é o caminho típico da maioria dos RAGs corporativos. E o culpado não é o transformer, e sim os dados e a arquitetura.

Onde o RAG quebra

Ao escalar do protótipo para a produção, surge uma verdade desagradável: de 70% a 80% dos problemas de RAG estão ligados a gestão de dados, indexação e busca, e não às capacidades do modelo de linguagem em si. Por melhor que seja o GPT-4 ou o Claude, se os dados forem mal indexados, o sistema dará respostas erradas. Isso fica especialmente evidente quando o RAG passa de 100 para 10.000 documentos.

Estas são as causas reais da falha de RAG em empresas:

• Confusão de versões de documentos: versões antigas permanecem no índice e o sistema não sabe qual é a vigente. O usuário recebe uma resposta baseada em um regulamento de dois anos atrás.
• Perda de contexto: o sistema não lembra o que foi discutido antes no chat, se repete ou se contradiz.
• Chunking ruim: os documentos são cortados por tamanho, não por sentido. A lógica se desfaz entre os trechos e o sistema não enxerga as conexões.
• Falta de reranking: o BM25 traz muito ruído e o sistema não distingue documentos relevantes de uma coincidência casual de palavra.
• Embeddings de baixa qualidade: os vetores são treinados em um corpus geral e não entendem a especificidade e a terminologia da sua empresa.
• Ausência de ciclo de feedback: ninguém acompanha as respostas erradas, e o sistema não aprende com os erros.

Como construir um RAG de forma correta

Na AlpinaGPT fizemos o caminho inverso: primeiro levantamos os requisitos de um sistema ideal, depois vimos quais problemas específicos os bloqueavam. O resultado é uma arquitetura testada em batalha com clientes corporativos. Estes são os componentes principais:

• Chunking por sentido: cortamos pela estrutura do documento, pelos títulos e por blocos semânticos, não por tamanho. Assim o contexto não se desfaz entre os trechos.
• Versionamento de dados: cada versão do documento é indexada separadamente, com uma marca de data. O sistema sabe qual é a vigente.
• Busca em duas etapas: primeiro um BM25 rápido (palavras-chave), depois reranking por rede neural (semântica). Sai mais barato do que buscar tudo via embeddings.
• Contexto entre mensagens: o sistema lembra todo o histórico do chat e não repete o que já foi explicado ao usuário.
• Feedback: acompanhamos as respostas erradas e retreinamos o ranker com esses exemplos.
• Índices separados por tipo: regulamentos, instruções, FAQ e código são indexados de formas diferentes.

O que isso significa

O RAG do futuro não é apenas embeddings e busca vetorial. É gestão do versionamento de documentos, chunking semântico correto, busca em várias etapas e feedback contínuo. Se metade das respostas do seu RAG está errada, o problema quase certamente não está no modelo GPT-4 ou Claude. O problema está em como você prepara os dados, como os corta, como os indexa e como coleta feedback. Reveja todo esse pipeline e a qualidade dá um salto. Foi isso que aprendemos com a AlpinaGPT.