RAG 6: da avaliação a uma operação reproduzível
O que eu prepararia para manter o sistema quando documentos, permissões ou modelos mudarem, e quando consideraria treiná-lo de novo.
Neste artigo
Um notebook que encontra evidência hoje não demonstra que o sistema continuará funcionando quando um arquivo mudar, uma permissão for retirada ou um modelo for atualizado. Depois de uma comparação experimental favorável, a próxima tarefa é transformar as decisões em contratos verificáveis. Esta é uma proposta de engenharia para o próximo ciclo; não uma descrição de controles já implantados na Taesa.
Uma versão do sistema contém mais que um modelo
Eu versionaria corpus, parser, regras de segmentação, metadados, prompt de enriquecimento, embeddings, índice, recuperadores, reranker, gerador e avaliação. Guardaria configuração e dependências com cada resultado. Uma mudança de embedding exige revisar compatibilidade e reconstrução do índice; uma correção de permissões exige invalidar resultados e caches afetados. A ingestão deve ser idempotente: repetir um evento não duplica documentos.
Para atualizar o acervo eu construiria uma versão candidata, verificaria integridade e consultas de regressão e só então mudaria a referência ao índice ativo. Manteria uma versão recuperável para rollback. Exclusões e revogações não podem esperar indefinidamente pelo próximo lote: precisam de uma política verificável de propagação, incluindo a camada de cache.
Testes que correspondem a falhas reais
Eu separaria testes do parser com documentos difíceis, validações do esquema, testes de integração da busca e avaliação das respostas. Incluiria referências quebradas, tabelas sem cabeçalho, documentos duplicados, novas versões e acesso revogado. Um documento recuperado é conteúdo não confiável: suas instruções não devem modificar permissões, executar ferramentas ou substituir o pedido do usuário. Cenários de injeção fazem parte dos testes do sistema.
Cada execução registraria IDs dos documentos, versão do índice, candidatos, escores, filtros e configuração, com retenção e acesso compatíveis com a sensibilidade dos dados. Não é necessário registrar indiscriminadamente perguntas e documentos completos. A observabilidade deve permitir localizar a falha no corpus, na extração, na busca ou na geração sem criar outro acervo confidencial sem controle.
Quando treinar e quando corrigir o pipeline
Eu não treinaria para compensar uma tabela perdida pelo parser ou um documento ausente. Se o modelo recebe a evidência correta e falha sistematicamente em uma tarefa bem definida, treinamento supervisionado pode ser uma hipótese. Um estudo de 2026 sobre perguntas multi-hop encontrou vantagens diferentes para RAG, treinamento não supervisionado e supervisionado; este último obteve a melhor exatidão em sua comparação. Isso impede sustentar que RAG sempre supera qualquer treinamento.
Comparação de injeção de conhecimento em perguntas multi-hop
SPA estuda geração de dados sintéticos para treinamento continuado. Seu resultado não é uma validação de índices contextualizados. Se eu testasse dados sintéticos, controlaria diversidade, fidelidade e separação do teste, comparando com uma alternativa simples. Fatos que mudam e precisam de citação continuariam exigindo uma fonte recuperável e atualizada.
SPA: alcance do estudo de aumento sintético
Responsabilidades e critério de entrega
O cientista de dados lidera a definição do objetivo, da amostra, das métricas e da análise de erros. Engenharia de dados responde por ingestão, versões, linhagem e atualização. Engenharia de software integra permissões, testes, implantação e recuperação. Especialistas do domínio revisam evidência e significado. São responsabilidades compartilhadas com entregas concretas, não uma transferência do problema ao modelo.
No próximo ciclo quero guardar o manifesto do corpus, as perguntas revisadas e as configurações, junto com os rankings, erros e intervalos. Também contaria quais mudanças não ajudaram. Esse protocolo ainda não foi executado; o que apresento aqui é o plano de testes.
O preprint AGO AI Quality Gate, de outubro de 2026, reforça outra cautela: um juiz pode produzir JSON impecável e discriminar mal respostas incorretas. Seus estudos do juiz e da promoção têm alcances diferentes, incluindo um experimento com resultados sintéticos. A lição que eu incorporaria é calibrar o avaliador contra referências humanas, separar evidência ausente de resultado ruim e medir decisões inseguras de promoção. Não copiaria seus limiares sem validação local.
AGO: validar o juiz antes de promover uma versão