Geração aumentada de recuperação (RAG) tornou-se rapidamente o padrão empresarial para aterramento IA generativa no conhecimento interno. Promete menos alucinações, mais precisão e uma forma de desbloquear valor a partir de décadas de documentos, políticas, bilhetes e memória institucional. No entanto, embora quase todas as empresas possam criar uma prova de conceito, muito poucas conseguem executar o RAG de forma confiável na produção.
Essa lacuna não tem nada a ver com a qualidade do modelo. É um problema de arquitetura de sistemas. O RAG quebra em escala porque as organizações o tratam como uma característica de grandes modelos de linguagem (LLMs) em vez de uma disciplina de plataforma. Os verdadeiros desafios surgem não na solicitação ou na seleção de modelos, mas na ingestão, otimização de recuperação, gerenciamento de metadados, controle de versão, indexação, avaliação e governança de longo prazo. O conhecimento é confuso, em constante mudança e muitas vezes contraditório. Sem rigor arquitetônico, o RAG torna-se frágil, inconsistente e caro.
RAG em grande escala exige tratar o conhecimento como um sistema vivo
Os protótipos de pipelines RAG são aparentemente simples: incorpore documentos, armazene-os em um banco de dados vetorialrecupere os ok principais resultados e passe-os para um LLM. Isso funciona até o primeiro momento em que o sistema encontra o comportamento actual da empresa: novas versões de políticas, documentos obsoletos que permanecem indexados por meses, dados conflitantes em vários repositórios e conhecimento espalhado por wikis, PDFs, planilhas, APIs, sistemas de tickets e threads do Slack.