Uma base de conhecimento RAG empresarial não é «despejar todo o disco partilhado numa base de dados vetorial». É uma camada de engenharia com quatro partes: fontes selecionadas, divisão correta dos documentos, pesquisa híbrida com reordenação e aplicação de permissões. Segundo relatórios de fornecedores publicados em 2026, entre 70% e 80% dos projetos RAG empresariais nunca chegam a produção, e a maioria das falhas tem origem nas camadas de ingestão e pesquisa, não no modelo. Este guia decompõe as quatro camadas e propõe um plano a 90 dias.
Porque é que a maioria dos projetos RAG morre antes da produção
O padrão repete-se. Uma equipa constrói um piloto em duas semanas, a demonstração impressiona, depois o sistema encontra a realidade da organização e desmorona-se. Um estudo da MLOps Community de 2026 sobre 143 implementações RAG empresariais concluiu que 73% sofreram pelo menos uma falha crítica no primeiro trimestre em produção, e que 41% dessas falhas nunca foram sinalizadas pelas suites de avaliação convencionais.
A causa quase nunca é a escolha do modelo. A estimativa mais citada no setor é a de que 80% das falhas de RAG remontam à camada de ingestão e divisão. Por outras palavras: quando o sistema devolve uma resposta errada, na maioria dos casos foi entregue ao modelo o excerto errado desde o início. Essa distinção importa, porque muda o destino do orçamento – não para uma atualização de modelo, mas para engenharia de recuperação.
O que isso implica no orçamento: em 2026 o RAG não é um problema de modelo, é um problema de engenharia de recuperação. Melhorar a divisão e a reordenação produz um salto de precisão maior do que passar para um modelo mais caro, com um custo de operação muito inferior. Se está a acompanhar a economia unitária de um projeto de IA, essa é a diferença entre um custo variável que cresce com a utilização e um investimento pontual em infraestrutura.
As quatro camadas de uma base de conhecimento empresarial
| Camada | O que faz | Falha comum |
|---|---|---|
| Fontes e metadados | Que documentos entram, quem é o responsável por cada um, quando foram atualizados pela última vez | Ingerir tudo de uma vez, incluindo versões obsoletas e rascunhos |
| Divisão | Dividir os documentos nos excertos que o modelo recebe como contexto | Uma única regra de divisão para todos os tipos de documento, que parte tabelas e secções |
| Recuperação e ordenação | Encontrar os excertos relevantes e devolver os melhores | Depender apenas da pesquisa vetorial, sem correspondência por palavras-chave |
| Permissões | Garantir que um utilizador só vê aquilo a que tem direito | Permissões verificadas na interface em vez de no momento da recuperação |
Como dividir os documentos corretamente
A divisão é a decisão que mais afeta a precisão e é também a que a maioria das equipas toma por inércia. Em 2026 contam três famílias de métodos:
| Método | Mais adequado a | Tamanho de bloco recomendado |
|---|---|---|
| Divisão recursiva de tamanho fixo | Prosa corrida, documentos de política interna, descrições de processos | 256 a 512 tokens para perguntas e respostas factuais |
| Divisão semântica | Documentos técnicos, especificações, documentação de produto | 512 a 1024 tokens para tarefas analíticas |
| Late chunking (divisão tardia) | Documentos longos em que o contexto atravessa fronteiras de secção | O documento inteiro é primeiro vetorizado e só depois dividido |
Uma regra prática: um bloco deve conter uma resposta completa a uma única pergunta. Se entregasse esse excerto em papel a um colaborador, conseguiria ele responder sem consultar mais nada? Se não, o bloco é curto demais. Se o excerto abrange três assuntos diferentes, é longo demais e a pesquisa vetorial terá dificuldade em focá-lo.
Dois erros recorrentes: partir tabelas a meio, o que transforma dados numéricos em ruído, e perder o título hierárquico. A correção do segundo é barata: acrescentar no início de cada bloco uma linha de contexto com o nome do documento, a secção e a data.
Pesquisa híbrida e reordenação
A pesquisa vetorial sozinha falha exatamente aquilo que as organizações perguntam: referências de peças, nomes de clientes, códigos de erro, cláusulas contratuais. São cadeias exatas que o embedding semântico esbate. É por isso que a pesquisa híbrida, que combina embeddings densos com correspondência por palavras-chave ao estilo BM25, continua a superar a pesquisa puramente densa na maioria dos tipos de documento empresarial.
A estrutura que se tornou um ponto de partida comum: recuperar 20 candidatos, reordená-los com um modelo de reranking e passar os cinco melhores ao LLM. A reordenação é o passo com melhor retorno face ao esforço, porque corrige erros de recuperação sem mexer na camada de divisão.
Permissões: a camada que toda a gente adia
É aqui que os pilotos morrem. Num piloto toda a gente vê tudo, e depois chega o momento em que um agente de apoio não pode ver documentos de vencimentos. Se as permissões só forem aplicadas na interface, a recuperação continua a ler o documento e o modelo pode ainda citá-lo. A aplicação tem de acontecer no momento da recuperação, como filtro de metadados, antes de qualquer excerto chegar ao modelo.
Na prática: cada bloco transporta os identificadores dos grupos autorizados a vê-lo, e a consulta filtra por eles. É também isso que torna o sistema auditável, porque consegue mostrar exatamente que documentos alimentaram cada resposta.
Como medir que o sistema funciona
Cerca de 70% das equipas com RAG em produção não medem sistematicamente a qualidade da recuperação. É por isso que as falhas passam despercebidas. O quadro aceite é a «tríade RAG», três eixos que pode executar automaticamente sobre um conjunto fixo de perguntas:
| Eixo | A pergunta que testa | O que fazer quando está baixo |
|---|---|---|
| Relevância do contexto | A recuperação encontrou os documentos certos? | Corrigir a divisão, acrescentar pesquisa híbrida |
| Fundamentação nas fontes | A resposta é realmente sustentada pelos excertos recuperados? | Apertar o prompt, exigir citação da fonte |
| Relevância da resposta | A resposta trata aquilo que foi perguntado? | Decompor perguntas de vários saltos |
Um ponto fraco conhecido: 71% dos sistemas RAG em produção falham em perguntas de vários saltos, aquelas que exigem combinar informação de dois documentos diferentes. Se esse é o seu caso de uso principal, construa o conjunto de avaliação em torno dele desde o primeiro dia, em vez de o construir com perguntas factuais simples que passam sempre.
O que distingue as equipas que entregam: um conjunto de avaliação documentado, versionado e executado automaticamente todas as noites. Sem ele, cada alteração à divisão ou ao prompt é uma aposta e não consegue saber se melhorou ou se partiu alguma coisa.
Um plano a 90 dias
Dias 1-30: escolha um caso de uso com um público definido. Mapeie apenas os 50 a 200 documentos relevantes, elimine versões obsoletas e atribua a cada documento um responsável e uma data de última atualização. Em paralelo, escreva 40 perguntas reais que a equipa faz mesmo, com respostas aprovadas. Esse é o seu conjunto de avaliação.
Dias 31-60: construa o pipeline – divisão, embeddings, pesquisa híbrida, reordenação, filtro de permissões. Execute o conjunto de avaliação e registe uma pontuação de referência nos três eixos. Melhore a divisão e a ordenação até a relevância do contexto estabilizar.
Dias 61-90: abra a um grupo piloto real, registe cada pergunta juntamente com os excertos recuperados e acrescente um botão de feedback. As perguntas falhadas passam a integrar o conjunto de avaliação. Só depois de as métricas se manterem estáveis durante duas semanas consecutivas deve alargar a mais fontes.
Se está a construir isto pela primeira vez, leia também como medir a visibilidade nos motores de resposta de IA – a mesma disciplina de medição aplica-se do lado externo. E quando chegar à disseminação organizacional, a nossa prática de implementação de IA parte exatamente deste exercício de mapeamento.
Perguntas frequentes
Quantos documentos são precisos para começar um projeto RAG empresarial?
Muito menos do que se supõe. Um único caso de uso fica bem coberto por 50 a 200 documentos limpos e atuais. Ingerir dezenas de milhares de documentos logo no início baixa a precisão, porque versões obsoletas e rascunhos competem pelos mesmos lugares de recuperação.
Qual é o tamanho de bloco recomendado?
Entre 256 e 512 tokens para perguntas factuais e entre 512 e 1024 tokens para tarefas analíticas. A regra prática: um bloco deve conter uma resposta completa a uma única pergunta, sem partir tabelas e sem perder o título da secção.
Porque é que a pesquisa vetorial sozinha não chega?
Porque esbate cadeias exatas como referências de peças, códigos de erro e nomes de clientes. A pesquisa híbrida, que combina embeddings com correspondência por palavras-chave ao estilo BM25, dá melhores resultados em quase todos os tipos de documento empresarial.
Como garantir que um utilizador nunca vê um documento a que não tem acesso?
Aplicando as permissões no momento da recuperação e não na interface. Cada bloco transporta os identificadores dos grupos autorizados a vê-lo e a consulta filtra por eles antes de qualquer excerto chegar ao modelo.
Quanto tempo demora a chegar a produção?
Um caso de uso único e focado pode chegar a um piloto real em cerca de 90 dias: um mês para mapear as fontes e construir um conjunto de avaliação, um mês para construir e afinar o pipeline e um mês de piloto com feedback real.