RAG empresarial: como avaliar recuperação, fontes, permissões e citações antes de um piloto

Escolha um fluxo concreto, seus usuários e o tipo de pergunta a responder. Registre também o que fica fora do escopo: decisões que exigem julgamento humano, solicitações sem documentação autorizada ou ações que o piloto não deve executar.

Para cada fonte, identifique responsável, autoridade sobre o assunto, público autorizado, versão, atualização, formato e política de retenção. Verifique duplicatas, documentos contraditórios, tabelas ou anexos que perdem contexto na extração e arquivos sem responsável. Um índice pode devolver rapidamente um trecho obsoleto ou incompleto; a velocidade da busca não corrige o estado do documento original.

Defina como reconhecer a versão vigente quando documentos divergem e como remover ou reindexar conteúdo. Políticas internas, instruções operacionais e materiais de referência podem exigir regras diferentes. Não existe uma configuração única adequada a todos os corpora.

Conteúdo heterogêneo precisa ser extraído e dividido em trechos que preservem o significado. Cabeçalhos, tabelas, notas de rodapé, identificadores e hierarquia podem ser necessários para recuperar e citar corretamente. Granularidade dos trechos, metadados, modelo de embeddings e combinação de busca textual, vetorial ou híbrida devem ser testados com dados representativos da tarefa — não escolhidos apenas por preferência ou por uma demonstração isolada.

Registre a configuração de ingestão e indexação, inclusive exclusões, versão do parser, estratégia de segmentação, metadados e parâmetros de busca. Isso ajuda a reproduzir uma avaliação quando as fontes ou o índice mudarem. Preparação, segmentação, enriquecimento, embeddings, recuperação e avaliação envolvem decisões próprias.

Em ambiente corporativo, filtrar depois que o modelo recebeu o contexto é tarde demais. A identidade autenticada e as regras de autorização precisam chegar à camada que recupera os documentos. Restrinja os resultados antes de encaminhar contexto ao modelo, em cada busca e em cada etapa de recuperação que possa ocorrer durante uma conversa ou execução de agente.

Teste com identidades e grupos representativos, inclusive casos negativos: uma pessoa sem acesso não deve obter o conteúdo, uma citação nem um resumo derivado de um documento restrito. Verifique filtros por unidade e sensibilidade quando aplicáveis. Registre o que foi consultado e por qual identidade de serviço, conforme as políticas de auditoria da organização.

A arquitetura pode usar isolamento de armazenamento, controles da plataforma, filtros ou uma camada de API que aplique as regras. A escolha depende do modelo de tenancy e dos requisitos do ambiente. Autenticação, autorização, filtragem durante a recuperação e testes de isolamento são controles distintos.

Monte um conjunto de teste com perguntas reais ou representativas, documentos de referência e, quando possível, avaliação humana da relevância dos trechos esperados. Inclua perguntas diretas, termos alternativos, consultas ambíguas, informações distribuídas por mais de um documento e perguntas sem resposta no corpus. O conjunto deve refletir o uso previsto, não apenas exemplos em que a busca já funciona.

Avalie primeiro a recuperação: os documentos corretos aparecem em posição útil? Há trechos irrelevantes, lacunas ou fontes antigas? Quando existem rótulos de relevância, medidas de ranking e cobertura ajudam a comparar configurações. Sem esses rótulos, uma avaliação qualitativa cuidadosa ainda pode localizar falhas, mas não deve ser chamada de benchmark universal.

Depois avalie a resposta final em dimensões distintas: pertinência à pergunta, sustentação no contexto recuperado, completude em relação à resposta esperada e fidelidade das citações. Uma resposta pode ser pertinente e incluir uma afirmação sem suporte; também pode estar bem fundamentada e omitir uma condição importante. Métricas automáticas e avaliadores baseados em modelo ajudam a organizar comparações, mas devem ser interpretados junto com exemplos e revisão humana.

Documente as perguntas, a versão do corpus, a configuração de recuperação e os critérios de aceitação antes de comparar mudanças. Os responsáveis pelo produto, pelos dados e pelo risco do caso de uso devem definir os limiares. Exemplos publicados por fornecedores não são metas automaticamente adequadas à organização.

Uma citação é útil quando leva a uma fonte autorizada e identificável — por exemplo, documento, versão e seção — e quando o trecho realmente sustenta a afirmação associada. Teste se a interface mantém a referência até o documento original, se a pessoa que recebe a resposta pode abrir aquela fonte e se a afirmação continua correta quando citada fora do contexto.

Verifique citações ausentes, links quebrados, fontes duplicadas, documentos alterados e afirmações apoiadas apenas por uma passagem correlata, mas inconclusiva. A presença de um link não prova que a resposta está correta. Quando a evidência não sustentar uma afirmação, o sistema deve explicitar essa limitação.

Inclua casos em que a resposta não está nas fontes, os documentos entram em conflito, as permissões impedem a consulta ou a recuperação traz contexto insuficiente. Avalie se o sistema sinaliza a limitação, pede esclarecimento ou encaminha a questão a uma pessoa responsável, em vez de preencher a lacuna com uma inferência apresentada como fato.

Teste a política de abstenção junto com a utilidade das respostas. Um sistema que nunca arrisca pode deixar de cumprir o propósito do piloto; um que sempre responde pode ocultar a ausência de evidência. O equilíbrio depende da criticidade da tarefa e deve ser aprovado pelos responsáveis pelo processo.

RAG não elimina alucinações nem substitui controles de qualidade, segurança ou revisão. Mesmo com contexto recuperado, o modelo pode responder de forma incompleta ou produzir afirmações sem suporte.

A recuperação adiciona componentes, processamento, latência e manutenção ao fluxo de geração. A ingestão, a atualização do índice, os embeddings, o volume de contexto e a estratégia de busca também influenciam o comportamento e o custo. Registre esses sinais na avaliação e compare alternativas dentro do objetivo e das restrições do caso, sem fixar metas genéricas.

Um piloto deve deixar claro como detectar mudanças nas fontes, revisar perguntas e exemplos de teste, identificar regressões e atribuir responsabilidade por incidentes de acesso ou conteúdo. Aprovar um protótipo não substitui o planejamento operacional necessário antes de ampliar o uso.

Use estas perguntas para estruturar a avaliação. Elas não garantem que uma solução esteja pronta para produção.