RAG para base de conhecimento: o que sobrevive à produção

Toda empresa que experimenta IA generativa chega rápido na mesma ideia: conectar o modelo à base de conhecimento interna. A técnica tem nome, RAG, e a arquitetura básica é simples. O que não é simples é fazer ela sobreviver a dados reais, permissões reais e usuários reais.

O problema quase nunca é o modelo

RAG foi formalizado em 2020 combinando duas memórias: a paramétrica, que está nos pesos do modelo, e a não paramétrica, que é um índice recuperável na hora da pergunta. A promessa é boa: você atualiza o índice sem retreinar nada.

Quando um RAG corporativo responde mal, a causa quase sempre está na recuperação, não na geração. Se o trecho certo não chegou ao contexto, nenhum modelo salva a resposta. Por isso a primeira métrica a instrumentar não é a qualidade da resposta, é se o documento correto entrou no top-k.

Chunking é decisão de produto, não de infraestrutura

Dividir documento em pedaços parece detalhe técnico e é onde a maioria dos projetos perde qualidade. Pedaço grande demais traz ruído junto; pequeno demais corta a sentença que dava sentido ao número.

O agravante em empresa é que um trecho isolado costuma perder o referencial. "A taxa passa a ser de 2,5%" não diz de qual produto, a partir de quando, nem sob qual contrato. Recuperado sozinho, vira resposta errada com cara de certa.

A mitigação que funciona é enriquecer cada trecho com o contexto do documento de origem antes de gerar o embedding. Experimentos publicados pela Anthropic mostram que essa contextualização reduz de forma relevante a taxa de falha na recuperação, e melhora ainda mais quando combinada com busca lexical e reranking.

Mais contexto não é a solução que parece

A reação natural a uma resposta ruim é aumentar o top-k e empurrar mais texto para o modelo. Existe um limite claro para isso.

O estudo Lost in the Middle mostrou que o desempenho do modelo depende de onde a informação relevante está dentro do contexto. O acerto é maior quando ela aparece no começo ou no fim, e cai visivelmente quando fica no meio. A curva tem formato de U.

A consequência prática é direta: encher a janela de contexto pode piorar a resposta mesmo quando o trecho certo está lá dentro. Ordenar bem os poucos trechos certos vale mais do que mandar muitos.

Busca híbrida e reranking

Busca vetorial sozinha erra em dois casos comuns na empresa: código de produto e termo exato de contrato. Embedding captura semelhança semântica, não igualdade literal, então "erro 4021" e "erro 4012" ficam perigosamente próximos.

A combinação que resolve é híbrida: busca densa para significado, busca lexical para termo exato, e um reranker por cima para ordenar o conjunto final. É mais infraestrutura, e é a diferença entre demo e produção.

Medir sem depender de gabarito manual

Avaliar RAG parece exigir um gabarito escrito à mão para cada pergunta, o que não escala. Frameworks como o RAGAS existem para reduzir esse custo, decompondo a avaliação em dimensões que podem ser medidas separadamente, entre elas se a resposta está de fato apoiada nos trechos recuperados e se os trechos recuperados eram relevantes para a pergunta.

Separar essas duas dimensões é o que dá diagnóstico. Resposta infiel com contexto bom é problema de geração. Contexto irrelevante é problema de recuperação, e nenhum ajuste de prompt conserta.

O que quebra especificamente em empresa

Três coisas, nenhuma delas sobre o modelo:

• Permissão. O índice não pode devolver a alguém um trecho de documento que essa pessoa não poderia abrir. Filtro de permissão precisa acontecer na recuperação, não depois, na resposta.
• Frescor. Documento revogado que continua no índice gera resposta confiante e errada. Reindexação precisa ser parte do ciclo de vida do documento.
• Procedência. Resposta sem link para a fonte não é auditável e não ganha confiança de área jurídica ou de compliance.

O que isso significa para o seu time

Comece por um corpo de documentos pequeno e bem delimitado, com dono claro. Instrumente recuperação e geração separadamente desde o primeiro dia. Monte um conjunto de trinta a cinquenta perguntas reais, coletadas com as pessoas que vão usar, e use-o como régua de regressão a cada mudança de chunking, embedding ou prompt.

E resolva permissão na arquitetura antes de mostrar a demo para a diretoria. Retroencaixar controle de acesso num índice já construído é um dos refatores mais caros desse tipo de projeto.