Nesta página
A resposta curta
A contaminação do benchmark ocorre quando as informações sobre os casos de teste influenciam o sistema de maneira que prejudicam a medição pretendida. Um conjunto privado reduz alguns vazamentos, mas ajustes repetidos, exemplos compartilhados e informações adquiridas durante a avaliação ainda podem comprometer o resultado.
O que levar
- Separar o feedback de desenvolvimento das evidências da decisão final.
- Registre o acesso à ferramenta e as informações disponíveis durante cada execução.
- Divulgue a incerteza sobre a contaminação em vez de declarar um teste limpo sem evidências.
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.
Uma taxonomia recente amplia a questão
Uma pré-impressão de agosto de 2026 organiza a contaminação em torno das mitigações que pode derrotar, incluindo a exposição adquirida durante a avaliação. Também relata limitações na confiabilidade de partes do seu instrumento de divulgação. Sua contribuição é uma forma de fazer perguntas mais precisas, e não um detector que prova que qualquer referência está incontaminada.
Evidência: Contaminação de referência: uma taxonomia organizada por mitigação derrotada [1]
Rastrear como as informações de avaliação podem chegar ao sistema
Liste os locais onde o material de teste pode aparecer: prompts, documentos recuperados, exemplos rápidos, notas do desenvolvedor, dados de ajuste fino, conversas compartilhadas e ferramentas. Um caso pode permanecer fora do treinamento do modelo e ainda assim ser incorporado ao prompt do aplicativo após repetidas depurações. Isso muda o que significa sucesso no caso.
Para sistemas habilitados para web, considere também se uma pergunta do teste leva diretamente à sua resposta publicada. Isso pode ser legítimo para uma tarefa de recuperação e inválido para uma reivindicação de capacidade de livro fechado. O mesmo comportamento pode ser aceitável ou contaminante dependendo do contrato de avaliação.
Use controles que correspondam à declaração pretendida
Rubrex recomenda manter conjuntos separados de desenvolvimento, regressão e decisão. Uma falha conhecida pertence aos testes de regressão, mesmo depois de os engenheiros a terem visto. Um conjunto retido serve a um propósito diferente: medir a transferência além dessas correções. Não apague o valor da regressão apenas porque um caso não é mais secreto.
Limite o acesso ao conjunto de decisões, registre quando ele foi exposto e congele as regras de pontuação antes de executar a comparação final. Se as ferramentas forem permitidas, registre seus limites de acesso. Novas questões devem ser revisadas quanto à semelhança com exemplos anteriores e quanto a pistas acidentais em identificadores ou documentos de referência.
Exemplo ilustrativo: a escalação memorizada
Uma equipe corrige um assistente após uma escalação de suporte e adiciona a interação exata ao seu prompt como exemplo. A próxima avaliação passa nessa interação. Este é um resultado de regressão útil, mas fraca evidência de que o assistente lida com casos desconhecidos do mesmo tipo.
Construa casos separados que exerçam a mesma regra subjacente com diferentes evidências, frases e condições de limite. Mantenha a escalação original, rotule sua exposição e relate os casos de generalização separadamente. Uma distinção transparente é mais útil do que uma percentagem de sucesso maior.
Incluir um registro de exposição ao lado da pontuação
Um registro compacto deve descrever a origem do conjunto de dados, quem viu os casos, como o aplicativo foi ajustado, se as ferramentas poderiam recuperar material relacionado e o que permanece desconhecido. Anexe-o à execução, pois a exposição pode mudar entre as execuções. Um rótulo de referência por si só não descreve as condições sob as quais uma pontuação foi obtida.
- Nomeie a reivindicação de capacidade ou fluxo de trabalho que o teste pretende oferecer suporte.
- Registre treinamento conhecido ou exposição de ajuste, quando disponível.
- Explique a recuperação e as permissões de rede durante a avaliação.
- Mantenha o conjunto de decisão final separado do feedback de depuração de rotina.
Limites da evidência
A contaminação é muitas vezes apenas parcialmente observável. Uma redação nova não prova independência e o armazenamento privado não prova que a informação nunca influenciou um sistema. A taxonomia citada é uma pré-impressão com limitações de medição relatadas.
Perguntas comuns
Os casos expostos devem ser excluídos?
Não automaticamente. Podem continuar a ser testes de regressão valiosos se a sua exposição for documentada e as suas pontuações não forem apresentadas como evidência de generalização independente.
Um benchmark mais recente elimina vazamentos?
Não. O tempo de liberação aborda alguns caminhos, mas não exclui exemplos derivados, ajuste imediato ou informações adquiridas durante a execução.
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.
- Contaminação de referência: uma taxonomia organizada por mitigação derrotada 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.