1. Por que avaliar RAG
Um protótipo que responde bem a 10 perguntas manuais pode falhar em 40% do tráfego real. Avaliação transforma “achismo” em números e permite detectar regressões quando você muda chunk size, embedding ou prompt.
2. Golden set
Monte 50–200 perguntas reais (ou realistas) com:
- Resposta esperada (ou critérios de aceitação)
- Documentos de referência que deveriam ser recuperados
- Categoria (fácil / difícil / ambígua / fora do escopo)
Atualize o golden set quando o domínio mudar. Sem isso, as métricas envelhecem.
3. Métricas de retrieval
- Hit Rate @k — percentual de queries em que pelo menos 1 documento relevante aparece no top-k
- MRR — Mean Reciprocal Rank (posição do primeiro relevante)
- nDCG — considera relevância graduada e posição
- Context Precision / Recall — o quanto do contexto recuperado é realmente útil
4. Métricas de geração
- Faithfulness — a resposta é suportada pelo contexto?
- Answer Relevance — a resposta responde à pergunta?
- Context Relevance — o contexto recuperado era adequado?
Ferramentas como RAGAS e DeepEval automatizam parte disso.
5. LLM-as-judge
Use um modelo forte (ex: GPT-4o ou Claude) com prompt estruturado para avaliar faithfulness e relevância em escala. Sempre calibre com uma amostra humana para evitar bias do juiz.
6. Continuous evaluation
- Golden set no CI (quebra o build se hit rate cair > X%)
- Amostra de produção (1–5%) avaliada diariamente
- Feedback explícito do usuário (👍/👎 + motivo)
- Alerta quando latência p95 ou taxa de “não sei” sobe
7. Checklist prático
- [ ] Golden set versionado no repositório
- [ ] Métricas de retrieval e geração rodando no CI
- [ ] LLM-as-judge calibrado com amostra humana
- [ ] Dashboard com tendência semanal
- [ ] Processo de análise de falhas (root cause)
8. Exemplo numérico das métricas de retrieval
Imagine um golden set de 5 perguntas, com k = 5. Para cada uma, anota-se em que posição apareceu o primeiro documento relevante:
| Pergunta | Posição do 1º relevante | Entrou no top-5? | Inverso da posição |
|---|---|---|---|
| P1 | 1 | sim | 1,000 |
| P2 | 3 | sim | 0,333 |
| P3 | não apareceu | não | 0 |
| P4 | 2 | sim | 0,500 |
| P5 | 1 | sim | 1,000 |
| Métrica | Cálculo | Resultado |
|---|---|---|
| Hit Rate @5 | 4 perguntas com acerto ÷ 5 | 80% |
| MRR | (1 + 0,333 + 0 + 0,5 + 1) ÷ 5 | 0,567 |
O Hit Rate diz se a resposta certa chegou ao contexto. O MRR mostra também se chegou perto do topo. A P3 é a que merece investigação, pois o documento nem foi recuperado.
9. Como ler as métricas de geração
| Métrica | Pergunta que responde | Exemplo de falha |
|---|---|---|
| Faithfulness | a resposta está apoiada no contexto? | o contexto diz "prazo de 30 dias" e a resposta diz "60 dias" |
| Answer Relevance | a resposta trata do que foi perguntado? | a pergunta é sobre prazo e a resposta fala de preço |
| Context Relevance | o contexto recuperado era adequado? | os trechos são de outro assunto |
| Padrão nos números | O que costuma indicar | Por onde começar |
|---|---|---|
| Hit Rate baixo | a busca não traz o documento certo | chunking, modelo de embedding e busca híbrida |
| Hit Rate alto, Faithfulness baixa | o contexto está certo, mas a resposta o ignora | o prompt e as instruções ao modelo |
| Faithfulness alta, Answer Relevance baixa | a resposta é fiel a um contexto que não serve | a recuperação e a interpretação da pergunta |
10. Armadilhas do LLM-as-judge
| Problema | O que acontece | Como reduzir |
|---|---|---|
| Viés de verbosidade | o juiz tende a preferir respostas mais longas | defina na rubrica que tamanho não é critério |
| Autopreferência | um modelo tende a favorecer respostas do mesmo modelo | use um juiz diferente do modelo que gera |
| Variabilidade | a mesma resposta recebe notas diferentes | temperatura baixa, rubrica objetiva e notas em escala curta |
| Nota sem validação | ninguém sabe se o juiz concorda com pessoas | compare com uma amostra avaliada por humanos, como o artigo recomenda |