Se seu sistema RAG não tem eval set, toda mudança de prompt é um release baseado em vibe. A boa notícia: você pode construir um eval set útil em uma semana. Não um perfeito — um útil. Perfeito é a armadilha que mantém times sem evals nenhum.
Aqui está a receita que usamos em engagements onde o cliente tem 0–5 evals no dia um e precisa de 200 no fim da semana.
A forma
Você quer três coisas:
- Um corpus congelado — os documentos reais sobre os quais seu sistema faz retrieval, com snapshot em um ponto no tempo.
- 200 perguntas que um usuário real poderia fazer, com respostas e citações de referência.
- Um conjunto held-out — 30 dessas 200, trancadas, nunca usadas para tunar nada.
O conjunto held-out é o mais importante e o mais frequentemente pulado. Voltaremos a ele.
Dia 1–2: Minere perguntas reais
Pule workshops de "o que usuários perguntariam?". Produzem perguntas que nenhum usuário jamais fez de verdade. Vá às suas fontes:
- Support tickets que mencionam qualquer tópico que o RAG cobre.
- Logs de busca da sua barra de busca atual, se você tem uma.
- Canais de Slack onde as pessoas fazem a pergunta internamente.
- Os logs de chat do seu sistema LLM atual, se você tem um rodando.
Mire em 250 perguntas brutas. Dedupe, normalize fraseado, descarte as obviamente fora de escopo. Você vai pousar em ~200.
Dia 3: Tag por dificuldade e tópico
Categorize cada pergunta:
- Dificuldade: trivial (resposta está em um parágrafo), média (resposta exige sintetizar 2–3 docs), difícil (exige entender um procedimento ou regra).
- Área de tópico — geralmente 5–15 categorias, dependendo do seu domínio.
- Flag adversarial — perguntas projetadas para disparar modos de falha conhecidos (fora de escopo, info contraditória, info recentemente atualizada).
Você quer uma mistura. Uma suíte com 90% de perguntas triviais vai te dizer que seu sistema é ótimo, e você vai entregar uma regressão porque os casos médios e difíceis quebraram.
Dia 4: Ground truth
Para cada pergunta, você precisa de:
- A resposta esperada — escrita, 1–3 frases, a resposta que um especialista de domínio daria.
- Os trechos de suporte — ponteiros (IDs de doc, intervalos de linha, IDs de chunk) para as partes do corpus que deveriam ser recuperadas para responder à pergunta.
Esta é a parte lenta. Planeje ~3 minutos por pergunta = ~10 horas para 200 perguntas. Duas pessoas em paralelo, meia semana. Use um especialista de domínio.
Vale a pena. Esta é a parte que transforma "o LLM disse algo plausível" em "o LLM citou a fonte certa e acertou a resposta."
Dia 5: Baselines + métricas
Rode seu sistema atual (ou um stub se você não tem um) contra as 170 perguntas visíveis. Registre:
- Retrieval@k: os top-k chunks recuperados incluíram os trechos de suporte esperados?
- Correção da resposta: avaliada por um judge LLM contra a resposta esperada, com a referência held-out. Calibre o judge contra ~30 avaliações humanas para garantir que não está só carimbando.
- Precisão de citação: das citações retornadas, que fração de fato sustenta a afirmação?
Você agora tem baselines. Toda mudança futura de prompt ou retrieval aparece como um delta destes.
O conjunto "não otimize isto"
As 30 perguntas held-out existem por um motivo: pegar você mesmo no flagra.
Todo time que constrói um eval set eventualmente começa a tunar o sistema contra o eval set. Nova revisão de prompt, roda evals, score subiu, entrega. Três meses depois, seu score in-suite é 95% e sua satisfação de usuário não mudou porque você vinha fazendo overfitting.
As 30 held-out são rodadas apenas em health checks trimestrais. Se regridem enquanto o resto da suíte melhora, este é o alarme de fumaça para overfitting. São uma checagem da checagem.
Não olhe para elas. Não adicione. Não substitua por equivalentes. Tranque num cofre.
O que isto te dá
- Um sinal reproduzível que faz gate em mudanças de prompt e retrieval.
- Um baseline contra o qual você pode comparar ao avaliar novas versões de LLM.
- Uma resposta defensável para "como você sabe que seu RAG presta?"
Construa a v1 em uma semana. Itere as perguntas mensalmente. Substitua o conjunto held-out uma vez por ano.
Você nunca vai ter tempo de construir o eval set perfeito. Você absolutamente pode ter tempo de construir o útil.