Nesta página
A resposta curta
Um conjunto de dados de avaliação útil registra a entrada, o contexto relevante, o comportamento esperado, a proveniência e a categoria de falha para cada caso. Combine exemplos reais autorizados com casos sintéticos cuidadosamente revisados e preserve um conjunto resistente para decisões que o ajuste não deve influenciar.
O que levar
- Armazene por que um caso existe, não apenas sua solicitação e resposta.
- Exemplos sintéticos ampliam a cobertura, mas precisam de validação independente.
- Mantenha as alterações do conjunto de dados versionadas e revisáveis.
Fontes verificadas . Síntese de pesquisa e recomendações Rubrex. Exemplos e experimentos locais são rotulados; eles não são resultados do cliente.
Trabalhos recentes tornam a estrutura do conjunto de dados uma escolha de design
HieraRAG, uma pré-impressão de junho de 2026, investiga a granularidade das questões sintéticas em benchmarks RAG. Ele enquadra a granularidade como algo a ser avaliado dentro de uma configuração de recuperação específica. Isto apoia perguntar quais distinções um conjunto de dados expõe, em vez de assumir que mais perguntas criam automaticamente um benchmark melhor.
Dados de avaliação e dados de treinamento servem a decisões diferentes
Exemplos de treinamento ajudam a mudar o comportamento de um modelo. Um conjunto de dados de avaliação testa um comportamento definido em relação a evidências de referência ou critérios de pontuação. Rubrex recomenda manter os casos usados para ajustar prompts ou modelos separados de um conjunto de decisões pendentes. Se a equipe estudar um teste que falhou e alterar o sistema para aprová-lo, retenha esse caso como uma verificação de regressão, mas use novos casos retidos para avaliar se a mudança se generaliza.
Exemplos sintéticos podem ajudar a cobrir entradas incomuns, falta de evidências ou limites de permissão. Verifique cada pergunta e o resultado esperado em relação ao material de origem antes de aceitá-lo. Registre como o exemplo foi criado e qual falha ele representa. Um grande corpus de treinamento ou uma coleção de pares de perguntas e respostas gerados automaticamente não é, por si só, um conjunto de avaliação validado.
Defina o registro antes de coletar exemplos
Rubrex recomenda um registro de caso com identificador imutável, entrada, contexto permitido, comportamento esperado, categoria de origem, data de coleta e status do revisor. Para um fluxo de trabalho que utiliza ferramentas, inclua o estado inicial e o estado final autorizado. Para redação aberta, use uma rubrica ancorada em vez de exigir uma frase exata.
Registre se o caso veio da produção, de uma escalação de suporte, de um especialista de domínio ou de geração sintética. Preservar uma descrição pública e segura de sua origem, mesmo quando a interação bruta não puder ser retida. Um conjunto de dados não deve adquirir silenciosamente informações confidenciais apenas porque a exportação de log é conveniente.
Construir cobertura deliberadamente
Mapeie o produto em fatias significativas antes de escrever avisos. Os exemplos incluem tipo de tarefa, idade do documento, tamanho da entrada, disponibilidade de evidências, idioma e permissão do usuário. Evite o produto cartesiano completo quando ele produz combinações que não podem ocorrer. Priorize combinações com exposição real ou com hipótese de falha específica.
Para casos sintéticos, especifique o comportamento que está sendo enfatizado e faça uma etapa de revisão separada para verificar se a entrada é plausível e se a referência é suportada. Um modelo pode gerar tanto uma pergunta falha quanto uma resposta falha correspondente. A concordância entre esses dois artefatos não é uma validação independente.
| Campo | Finalidade |
|---|---|
| id_do_caso | Identidade estável entre execuções e revisões |
| comportamento_esperado | O requisito observável, incluindo incerteza aceitável |
| proveniência | Origem, permissão de uso e contexto de coleta |
| slice_tags | A tarefa e as condições de falha representadas |
| review_status | Quem ou o que validou a referência e se a ambiguidade permanece |
Exemplo ilustrativo: questões de política versionadas
Um assistente de benefícios recebe perguntas sobre uma apólice atual e uma apólice arquivada. Crie casos distintos para questões atuais, questões explicitamente históricas e questões sem data. O comportamento esperado é diferente: use a regra atual, responda historicamente ou esclareça a data aplicável. A mera mudança de nomes num exemplo fácil não permitiria esta distinção.
Mantenha estes casos ligados às versões das políticas para que uma actualização real da política não pareça ser uma regressão do modelo. Retire expectativas inválidas por meio de revisão, com uma explicação, em vez de excluir casos difíceis do conjunto de dados.
Trate o conjunto de dados como um artefato de produto mantido
Separe um conjunto de desenvolvimento de um conjunto de decisão e registre o acesso a cada um. Adicione novos casos de falha por meio de uma fila de revisão leve. Ao relatar uma pontuação, identifique a versão do conjunto de dados e explique as alterações materiais. Comparar o resultado do mês passado em uma combinação de tarefas com o resultado deste mês em outra pode confundir mudanças no tráfego com melhoria do modelo.
Limites da evidência
Um conjunto de dados é uma amostra construída, não um modelo completo de tráfego futuro. As descobertas do HieraRAG dizem respeito a um contexto de pesquisa específico. O modelo de registro e o exemplo de política aqui são recomendações da Rubrex, e não uma reprodução desse estudo.
Perguntas comuns
O conjunto de dados pode ser totalmente sintético?
Pode ser útil durante o projeto inicial, mas seu realismo e cobertura precisam de validação. Manter explícita a sua origem sintética e compará-la com o uso real autorizado, quando disponível.
As referências devem ser respostas exatas?
Use respostas exatas para tarefas exatas. Para resultados abertos, defina os fatos exigidos, o comportamento inaceitável e as variações aceitáveis.
Fontes e leituras adicionais
Fontes primárias por trás deste briefing. As descobertas de uma fonte aplicam-se às suas próprias condições de estudo; a publicação no arXiv não estabelece revisão por pares.
- Quão refinado deve ser um benchmark RAG? Uma estrutura hierárquica para geração de perguntas sintéticas arXiv · 2026 · Pré-impressãoRevisado: resumo e registro de publicação. Acessado 25 de set. de 2026.
Dúvidas ou correções? Escreva para Rubrex. Leia nossa abordagem editorial.