chimera-when-two-results-contradict-suspect-the-apparatus
Quando duas medições suas discordam por uma margem que nenhum mecanismo produziria, o defeito está no instrumento. Audite o harness antes de construir teoria em cima dele.
Conferida por quem revisou e leu o cartão, não reivindicada pelo próprio arquivo. Um cartão que o agente destila durante uma execução que consumiu conteúdo não confiável nasce contaminado e fica retido para revisão antes de alguma vez ser recuperado.
Quando ele vem à mente
- duas execuções discordam demais
- a execução menor pontuou melhor
- uma métrica andou numa direção impossível
- explicando um resultado surpreendente de benchmark
Evite e Verifique são onde costuma estar o valor. Faça é a seção que todo mundo escreve.
O corpo do cartão acima é uma tradução. O original em inglês é o que a CLI importa, o que o agente lê em execução e o que o hash abaixo atesta.
Gatilho
Duas medições que você mesmo produziu discordam por uma quantidade que você não consegue explicar: a execução com uma fração dos dados pontua melhor que a grande; um componente marca 0% numa tarefa que uma medição vizinha mostra ele fazendo rotineiramente; uma mudança move um número na direção que ela torna impossível.
O gatilho é o tamanho da diferença, não a existência dela. Duas execuções diferindo dentro da banda de ruído delas é uma questão de amostragem, e este card não tem nada a dizer sobre isso. Também não se aplica ao seu número contra um número publicado por outra pessoa — dados, prompts, sementes e versões diferentes explicam esses o dia inteiro, e tratar isso como alarme de aparato vai te fazer auditar um harness que está bom. O caso aqui é: os dois lados da contradição são seus, e os dois não podem ser verdade.
Faça
- Escreva a contradição primeiro, como duas linhas: os dois números, e os comandos e commits exatos que os produziram. Pare de teorizar até que isso esteja no papel — uma contradição não escrita é amaciada até virar um enigma em cerca de um parágrafo.
- Compare (diff) as duas execuções antes de raciocinar sobre elas: config, commit, caminho de código, hash do arquivo de entrada, versão do avaliador. Prefira um diff que você consegue ler a uma explicação que você consegue construir.
- Empurre respostas conhecidas pela própria medição. Rode as soluções de referência/gabarito pelo seu avaliador antes de confiar em qualquer pontuação de modelo. Se uma resposta sabidamente correta é avaliada como falha, o defeito está no avaliador e todo número que ele já produziu é nulo, inclusive o que você gostou.
- Só depois que o aparato sobreviver ao passo 3 é que você gasta esforço explicando o fenômeno.
- Se o aparato era o culpado, retrate os números em vez de reinterpretá-los. Uma pontuação vinda de um avaliador quebrado não é uma estimativa ruidosa da verdade; ela não tem relação com a verdade.
Evite
Construir várias hipóteses cuidadosas para explicar os dois números e então testá-las com rigor. Essa é a versão cara deste erro: o rigor é real, o esforço é real, e tudo isso é medido sobre um artefato. Qualidade de método a jusante de um instrumento quebrado só te leva à resposta errada com barras de erro melhores.
Evite reconciliar por aritmética — tirar a média dos dois, ou silenciosamente ficar com o que bateu com o que você esperava. Evite um avaliador de mundo fechado, que é o bug específico que produz esse formato com mais frequência:
# and the score then reads as "the model cannot do this at all"
CITIES = {"lisbon", "porto"}
ok = answer.lower() in CITIES
# yes — grade against a rule that the real world can satisfy
ok = geocode(answer) == geocode(expected)
E evite a frase "deve ter sido um acaso" como ponto final. É uma hipótese sobre o aparato, portanto testável — teste-a ou descarte-a.
Verifique
Uma frase, em voz alta, com uma magnitude dentro dela: "X produz uma diferença deste tamanho porque …". Se você não consegue terminá-la — "dez vezes menos dados produzindo uma pontuação melhor porque …" — o instrumento é o suspeito e o passo 3 é para onde você vai.
Depois a binária: os gabaritos passaram no avaliador? Todo item de gabarito que o avaliador marca como errado é um teto sobre o que a medição poderia ter significado, e a fração deles que falha é o primeiro número a reportar.
Risco
Às vezes a contradição é real e o resultado surpreendente é o achado. Um reflexo de culpar o harness descarta esses e — pior — é exatamente a jogada disponível para quem quer que uma medição inconveniente suma. Então delimite: a checagem do aparato é uma lista fixa e curta (comparar as execuções, gabarito pelo avaliador, conferir os hashes de entrada). Se essa lista voltar limpa, acredite na contradição e vá investigar o fenômeno. Este card ordena o trabalho; ele não escolhe a resposta.
O segundo custo é recursivo. Código novo escrito para checar o código antigo é mais uma coisa que pode estar errada, e um script de auditoria com bug acabou de produzir um terceiro número. Prefira checagens que usam artefatos que você já tem e entradas cujas respostas são conhecidas, em vez de um harness novo escrito sob a pressão de uma anomalia.
Como usar
O cartão é dado. Clone o repositório e importe pelo caminho — o que chega pela rede é tratado como contaminado e fica retido para aprovação, que é o comportamento desejável e a razão de não haver um instalador de uma linha aqui.
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/chimera-when-two-results-contradict-suspect-the-apparatus/SKILL.mdIntegridade
SHA-256 do arquivo como publicado. Quem importa pode conferir que o que recebeu é o que esta página mostrou.
c33d19c446e5da887d8aee039d0e58690472bd2db3c6d8322497b6cebfbb62bf