RAG в enterprise: почему 80% проблем в данных, а не в модели

Um protótipo de RAG é construído em uma semana e demonstrado. Parece mágico: o modelo responde perguntas sobre seus documentos sem alucinar com conhecimento geral. Mas em algumas semanas em produção, o sistema começa a confundir versões, perde contexto e fornece com confiança respostas de fontes inexistentes. Este é o caminho típico para a maioria dos sistemas RAG empresariais. E o culpado aqui não é o transformer, mas os dados e a arquitetura.

Onde o RAG Falha

Ao dimensionar de um protótipo para a produção, uma verdade desagradável emerge: 70-80% dos problemas do RAG estão relacionados ao gerenciamento de dados, indexação e busca, não às capacidades do próprio modelo de linguagem. Não importa quão bom seja o GPT-4 ou Claude, se os dados estiverem mal indexados, o sistema fornecerá respostas incorretas. Isso fica especialmente aparente ao dimensionar RAG de 100 para 10.000 documentos.

Aqui estão as razões reais pelas quais o RAG falha nas empresas:

• Confusão de versão de documentos — versões antigas permanecem no índice, o sistema não sabe qual documento é atual. Os usuários obtêm respostas baseadas em regulamentações de dois anos atrás.
• Perda de contexto — o sistema não se lembra do que foi discutido nas mensagens de chat anteriores, repete a si mesmo ou se contradiz.
• Divisão deficiente — os documentos são divididos por tamanho em vez de por significado. A lógica se desintegra entre os pedaços, o sistema perde as conexões.
• Falta de reranking — o BM25 puxa muito ruído, o sistema não consegue distinguir documentos relevantes de correspondências aleatórias de palavras-chave.
• Embeddings de baixa qualidade — os vetores são treinados em um corpus geral, mas não entendem sua terminologia específica do domínio.
• Sem feedback loop — ninguém rastreia respostas incorretas, o sistema não aprende com erros.

Como Construir RAG Corretamente

Na AlpinaGPT, trabalhamos ao contrário: primeiro coletamos os requisitos de um sistema ideal, depois identificamos os problemas específicos que os bloqueiam. O resultado é uma arquitetura que passou em testes reais com clientes corporativos. Aqui estão os componentes principais:

• Chunking semântico — dividimos pela estrutura do documento, títulos e blocos semânticos em vez de por tamanho. Isso evita que o contexto se fragmente em pedaços.
• Versionamento de dados — cada versão do documento é indexada separadamente com um carimbo de data. O sistema sabe qual documento é atual.
• Busca em dois estágios — primeiro, BM25 rápido (palavras-chave), depois reranking neural (semântica). Isso é mais barato do que procurar tudo por meio de embeddings.
• Contexto entre mensagens — o sistema lembra todo o histórico de chat e não repete o que já foi explicado ao usuário.
• Feedback — rastreamos respostas incorretas e retreinamos o ranker nesses exemplos.
• Índices separados por tipo — regulamentos, instruções, FAQs e código são indexados diferentemente.

O que Isso Significa

O RAG do futuro não é apenas embeddings e busca vetorial. É gerenciamento de versão de documento, chunking semântico adequado, busca em múltiplos estágios e feedback contínuo. Se metade das suas respostas de RAG estão erradas, o problema quase certamente não é o modelo GPT-4 ou Claude. O problema é como você prepara seus dados, como os divide, como os indexa e como coleta feedback. Repense todo esse pipeline — e a qualidade salta. Isto é o que aprendemos com a AlpinaGPT.