Gramax mostra como comparar a qualidade das respostas de RAG sem avaliar «no olho»

A Gramax descreveu uma transição prática da avaliação subjetiva de sistemas RAG para uma comparação reprodutível de respostas. A equipe propõe olhar não para o quão bonitas são as métricas de retrieval, mas para o fato de o usuário receber da base de conhecimento uma resposta precisa, completa e compreensível.

O motivo para rever a abordagem foi um problema típico de quase qualquer busca RAG em documentação ou em uma base de conhecimento interna. Mesmo que o sistema encontre bem os chunks relevantes, isso ainda não garante uma boa resposta final. O usuário não vê DCG, Recall@10, reranking nem outros indicadores internos. Ele vê apenas o texto final. É nesse nível que surgem as principais falhas: o modelo pode ignorar parte do contexto encontrado, responder no idioma errado, acrescentar detalhes não confirmados ou entregar um texto confiante, mas de leitura ruim.

A Gramax observa que já havia trabalhado na melhoria da camada de retrieval: ajustou o esquema de chunking, adicionou metadados, combinou diferentes tipos de busca e usou reranqueamento dos resultados. Esse conjunto de técnicas de fato aumenta a chance de extrair os trechos certos da base de conhecimento. Mas, depois que a busca se estabiliza, surge a pergunta seguinte: como saber se toda a cadeia funciona para o usuário final, e não só para o engenheiro que olha um painel técnico? Na prática, essa distância entre a qualidade da busca e a qualidade da resposta costuma causar um otimismo falso no desenvolvimento de RAG.

A ideia central do artigo é que a avaliação deve estar ligada ao cenário do usuário. Quando alguém faz uma pergunta sobre a documentação, não lhe interessa uma lista de chunks bem extraídos, mas uma resposta concreta: se ela traz o fato necessário, se algum detalhe importante se perdeu, se há alucinações, se o idioma da pergunta foi respeitado e se a formulação merece confiança.

Essa mudança de foco obriga a montar a verificação de qualidade de outra forma. Em vez de avaliar «no olho», a equipe propõe fixar um conjunto de critérios e comparar modelos e configurações na mesma amostra de perguntas. Isso é especialmente importante quando as diferenças entre as opções não são óbvias e a impressão subjetiva de alguns exemplos bem-sucedidos distorce facilmente o quadro.

Uma conclusão prática à parte diz respeito à comparação de modelos. No material, a Gramax destaca que, em tarefas de RAG, não basta se apoiar em benchmarks gerais ou na reputação do modelo no mercado. Um mesmo modelo pode ser forte na geração e mais fraco na disciplina de responder com base no contexto encontrado. Por isso, a comparação deve ser feita em um cenário aplicado: com perguntas próprias, na própria base de conhecimento e com regras de verificação claras. Assim dá para ver qual modelo retém melhor os fatos, não foge para a fantasia, trabalha corretamente com o idioma e responde de forma estável a consultas do mesmo tipo.

Para o mercado, é um sinal importante. Projetos de RAG são cada vez mais implantados em suporte, manuais internos, bases de regulamentos e documentação de produto, onde um erro na resposta custa mais do que uma queda em uma métrica abstrata de busca. A abordagem descrita pela Gramax, na prática, move a conversa sobre qualidade do plano da engenharia para o do produto: um bom sistema não é o que fica bonito no relatório de retrieval, mas o que entrega de forma estável uma resposta útil e verificável à pessoa.

Quanto antes as equipes começarem a medir justamente essa camada, mais rápido deixarão de confundir contexto encontrado com uma tarefa do usuário realmente resolvida. Isso significa que a próxima etapa do desenvolvimento de sistemas RAG estará ligada não só à melhoria da busca, mas também à normalização da avaliação da resposta como um produto à parte. Para equipes que já configuraram chunking, busca híbrida e reranking, essa metodologia pode se tornar o principal caminho para entender qual combinação de modelos e prompts realmente funciona em produção.