Você enviou um sistema RAG. Funciona... principalmente. Às vezes, as respostas são impressionantemente boas. Às vezes, afirma com segurança algo que está completamente errado, citando um documento que não diz o que o modelo afirma que diz. E às vezes ele perde totalmente a resposta, mesmo que o documento certo esteja ali na sua base de conhecimento.
Este é o estado normal de um sistema de produção RAG. A questão não é se você tem problemas de qualidade - você tem - é se você tem uma maneira sistemática de encontrá-los e corrigi-los. É para isso que servem as retrospectivas RAG: examinar regularmente onde seu pipeline falha e fazer melhorias direcionadas em vez de adivinhar.
Por que os sistemas RAG precisam de suas próprias retrospectivas
RAG não é um sistema. É uma cadeia de componentes e a qualidade de cada elo determina o resultado final. Quando a resposta é ruim, a falha pode estar em qualquer lugar:
- Ingestão: os documentos foram analisados incorretamente, partes foram divididas em locais incorretos, metadados foram perdidos
- Recuperação: a consulta de pesquisa não correspondeu aos documentos corretos, o modelo de incorporação perdeu a conexão semântica, seu K principal era muito pequeno ou muito grande
- Montagem de contexto: os pedaços recuperados eram relevantes individualmente, mas se contradiziam ou a janela de contexto estava cheia de ruído
- Geração: O modelo teve alucinações apesar do bom contexto ou ignorou o contexto relevante em favor do seu conhecimento paramétrico
As retrospectivas de software padrão não estão equipadas para desvendar esses modos de falha. Você precisa de um formato que rastreie saídas incorretas através do pipeline para encontrar o ponto real de falha. Caso contrário, você acabará "consertando" a recuperação quando o problema real era a fragmentação ou reescrevendo os prompts quando o problema real era a recuperação.
Métricas que valem a pena acompanhar
Antes de fazer uma retrospectiva RAG, você precisa de dados. Nem todas as métricas possíveis – apenas o suficiente para diagnosticar os modos de falha mais comuns.
Qualidade de recuperação
Precisão@K: Dos K documentos recuperados, quantos eram realmente relevantes? Se você estiver retirando 10 pedaços e apenas 2 forem úteis, você estará inundando a janela de contexto com ruído.
Lembre-se@K: De todos os documentos relevantes em sua base de conhecimento, quantos terminaram nos K resultados? Baixa recuperação significa que as respostas certas existem, mas sua recuperação não consegue encontrá-las.
MRR (classificação média recíproca): Onde aparece o primeiro resultado relevante no seu ranking? Se o melhor documento estiver consistentemente na posição 5 em vez da posição 1, sua classificação precisará ser melhorada, mesmo que a recuperação seja boa.
Você não precisa calculá-los em toda a sua base de conhecimento. Amostra de 50 a 100 consultas recentes, tenha um juiz humano que identificou os documentos recuperados como relevantes e calcule a partir daí. Faça isso mensalmente.
Qualidade de Geração
Fidelidade: A resposta gerada realmente reflete o que dizem os documentos recuperados? Esta é a questão da alucinação. Você pode verificar isso comparando os resultados com o contexto fornecido.
Relevância da resposta: A resposta realmente responde à pergunta que foi feita? É possível gerar um resumo perfeitamente fiel dos documentos recuperados que foge completamente da intenção do usuário.
Utilização do contexto: Quando a informação correta está no contexto recuperado, o modelo realmente a utiliza? Se você recupera consistentemente documentos bons e o modelo os ignora, isso é um problema do lado da geração (geralmente um problema imediato).
Métricas Operacionais
Latência: Quanto tempo leva o pipeline completo, desde a consulta até a resposta? Divida isso por componente para saber se a recuperação ou geração é o gargalo.
Custo por consulta: Rastreie o uso de tokens e os custos API. Algumas melhorias de qualidade (como expandir a janela de contexto ou reclassificar) aumentam significativamente os custos.
Executando a retrospectiva
Preparação (antes da reunião)
Designe alguém para preparar uma “amostra de falha” – 10 a 15 consultas recentes em que o resultado estava errado ou de baixa qualidade. Para cada um, capture o estado completo do pipeline: a consulta original, o que foi recuperado, qual contexto foi enviado ao modelo e o que o modelo gerou. Esse rastreamento é essencial. Sem ele, você está depurando às cegas.
Prepare também suas tendências métricas. As coisas estão melhorando ou piorando desde o último retro? Alguma mudança brusca?
A Reunião (60 minutos)
Revisão de métricas (10 minutos). Percorra as métricas de recuperação e geração. Concentre-se nas tendências e surpresas, não na recitação número por número. “Precision@5 caiu de 0,72 para 0,58 este mês” é útil. Ler todas as métricas de um painel não é.
Análise de falhas (35 minutos). Este é o núcleo do retro. Pegue a amostra de falha e classifique cada uma de acordo com o local onde o pipeline quebrou:
- Falha na recuperação: Os documentos corretos não foram recuperados. Por que? Incompatibilidade entre consulta e documento? Incorporando limitação do modelo? Filtragem de metadados muito agressiva?
- Falha de fragmentação: o documento correto foi recuperado, mas os limites do bloco dividiram a resposta em dois blocos e apenas um foi retornado. Ou o pedaço era muito grande e diluído em conteúdo irrelevante.
- Falha de contexto: bons pedaços foram recuperados, mas a ordenação ou truncamento da janela de contexto perdeu as informações importantes. Ou pedaços conflitantes confundiram o modelo.
- Falha de geração: Foi fornecido um bom contexto, mas o modelo teve alucinações mesmo assim, ignorou o contexto ou deu uma resposta vaga em vez da resposta específica disponível nos documentos.
Para cada falha, pergunte: "Qual a solução mais barata que teria detectado ou evitado isso?" Às vezes é um ajuste imediato. Às vezes, é reagrupamento de um documento específico. Às vezes é uma mudança sistêmica.
Priorização e itens de ação (15 minutos). Agrupe as falhas por causa raiz. O padrão que causou mais falhas recebe mais atenção. Escolha 2 a 3 melhorias para implementar antes da próxima retro.
Padrões e correções de falhas comuns
Aqui estão os padrões que você verá com mais frequência e abordagens práticas para cada um:
"O documento certo está em nossa base de conhecimento, mas a recuperação não o encontra." Isso geralmente é um problema de similaridade de incorporação. A consulta do usuário usa um vocabulário diferente do documento de origem. Correções: adicione uma etapa de expansão de consulta (reescreva a consulta do usuário em várias frases), implemente pesquisa híbrida (combine incorporações semânticas com correspondência de palavras-chave como BM25) ou melhore sua filtragem de metadados para restringir o espaço de pesquisa.
"Recuperamos o documento certo, mas o pedaço errado." Sua estratégia de chunking é mais importante do que a maioria das equipes imagina. Se você estiver usando chunking de tamanho fixo (por exemplo, 500 tokens), é quase certo que você estará dividindo conteúdo importante entre limites. Correções: use fragmentação semântica (divisão com base em mudanças de tópico), adicione sobreposição de partes, tente fragmentação hierárquica onde partes pais maiores fornecem contexto para partes filhos menores.
"O modelo ignora o bom contexto e inventa coisas." Este é um problema de alerta e comportamento de modelo. O conhecimento paramétrico do modelo está em conflito com o contexto fornecido e o conhecimento paramétrico está vencendo. Correções: ajuste o prompt do sistema para instruir explicitamente o modelo a usar apenas o contexto fornecido, adicione uma instrução "se o contexto não contiver a resposta, diga", considere reduzir a temperatura do modelo.
"As respostas estão corretas, mas muito lentas." Os problemas de latência geralmente vêm de três locais: muitas chamadas de recuperação, uma janela de contexto muito grande (mais tokens = geração mais lenta) ou etapas de reclassificação que aumentam o tempo de processamento. Crie o perfil do seu pipeline componente por componente. A correção depende de para onde está indo o tempo.
"A qualidade é inconsistente – ótima para alguns tópicos, péssima para outros." Isso geralmente significa que algumas partes da sua base de conhecimento são melhor indexadas do que outras. Talvez certos documentos tenham sido mal analisados ou certos tópicos não tenham cobertura suficiente. Mapeie suas falhas por área temática e você encontrará as lacunas.
Construindo um Ciclo de Melhoria Contínua
As equipes RAG mais eficazes tratam seu sistema como um produto, não como um projeto. Nunca está "pronto". Cada retrospectiva deve produzir melhorias incrementais, e essas melhorias devem ser mensuráveis na próxima retrospectiva.
Uma cadência prática:
- Semanalmente: Revisão rápida de métricas de qualidade automatizadas (pode ser assíncrona, basta verificar o dashboard)
- Quinzenal ou mensal: Retrospectiva completa com análise de falhas
- Trimestralmente: Decisões arquitetônicas maiores — deveríamos mudar os modelos de incorporação, reestruturar nossa base de conhecimento, adotar uma nova estratégia de chunking?
Mantenha um documento atualizado do que você tentou e do impacto que teve. A otimização RAG é iterativa e não linear — às vezes você revisitará abordagens que não funcionavam antes porque o restante do pipeline mudou o suficiente para funcionar agora.
Evite a armadilha de objetos brilhantes
Toda semana há um novo artigo ou estrutura que afirma resolver a qualidade do RAG. Resista à tentação de reestruturar seu pipeline com base em uma postagem de blog. Em vez disso, use seus dados retrospectivos para identificar seu maior problema de qualidade real e resolver esse problema específico. Talvez a resposta seja um novo modelo sofisticado de reclassificação. Mais provavelmente, está corrigindo a forma como você fragmenta a documentação do produto.
As equipes que melhoram mais rapidamente não são aquelas que utilizam a arquitetura mais sofisticada. Eles são os que têm o ciclo de feedback mais restrito entre “este resultado foi ruim” e “aqui está especificamente o porquê e aqui está o que mudamos”.
Experimente NextRetro grátis — Categorize os padrões de falha RAG com colunas e vote em quais melhorias de pipeline priorizar.
Última atualização: Fevereiro de 2026
Tempo de leitura: 7 minutos
