Ablation Planner: teste cada componente antes de atribuir o resultado

ANÁLISE EDITORIAL

Planeje ablações que isolam componentes, não resultados que apenas parecem convincentes

Um modelo melhora depois de várias mudanças ao mesmo tempo. Qual delas realmente contribuiu? A pergunta parece simples, mas não é respondida por uma tabela final que compara apenas a versão antiga com a nova. A Ablation Planner transforma o método, os resultados já observados e as alegações pretendidas em um plano de estudos que remove, substitui ou varia cada componente de forma controlada.

A Skill pertence ao repositório comunitário Auto Claude Code Research in Sleep, mantido por wanshuiyin. Ela foi auditada no commit 94d8093ed21d20a790830318190095b9f5036ce8. O repositório tinha 15.391 estrelas na consulta de 28 de agosto de 2026, estava ativo e declarava licença MIT. O SKILL.md não declara uma versão própria. A release do repositório verificada separadamente era a v0.4.24.

Ilustração editorial exclusiva do Bastidores da IA. Não é captura de tela, interface real, resultado experimental, gráfico medido, logotipo ou prova de ganho científico.

O que esta Skill faz de verdade

A Ablation Planner instrui um agente a ler descrição do método, componentes, resultados atuais, alegações e orçamento computacional. Em seguida, pede a uma revisão independente via Codex um conjunto de ablações orientadas por perguntas: remover um módulo, substituí-lo por uma alternativa natural, variar um hiperparâmetro ou comparar escolhas de projeto.

O formato esperado não é uma lista solta. Cada ablação deve ter nome, pergunta testada, resultado esperado caso o componente importe e prioridade. A resposta também deve registrar cobertura das dúvidas de revisores, experimentos desnecessários, ordem recomendada e estimativa total de GPU-horas. O SKILL.md auditado preserva essa estrutura.

Depois do desenho, o fluxo original manda revisar viabilidade, criar configurações ou scripts, fazer testes rápidos, executar as ablações e registrar tudo no EXPERIMENT_LOG.md. Isso amplia bastante o alcance. A Skill não é apenas um gerador de tabela. Se as permissões do agente permitirem, ela pode alterar o projeto e iniciar trabalho computacional.

Ela não comprova causalidade sozinha, não escolhe a métrica correta e não transforma um resultado esperado em evidência. A contribuição de um componente só pode ser discutida depois de execução controlada, comparação justa, repetição suficiente e análise compatível com o desenho do experimento.

Para quem serve

A Skill é útil para pesquisadores de machine learning, engenheiros que avaliam sistemas com vários módulos e estudantes preparando a seção experimental de um artigo. Ela ajuda especialmente quando o método combina pré-processamento, arquitetura, função de perda, recuperação, memória, roteamento, dados auxiliares ou etapas de pós-processamento.

Também serve como roteiro de revisão antes de consumir GPU. Um pesquisador pode mostrar o método e as alegações, pedir somente o plano e verificar se cada experimento responde a uma pergunta real. Isso é mais seguro do que começar com uma varredura ampla de configurações sem prioridade.

Não é a melhor escolha quando ainda não existe resultado principal, hipótese delimitada ou baseline reproduzível. O próprio arquivo condiciona o uso a resultados aceitos ou parcialmente aceitos pelo estágio result-to-claim, ou a um pedido explícito de planejamento. Sem esse contexto, o agente pode produzir ablações formalmente organizadas, mas metodologicamente vazias.

Compatibilidade e pré-requisitos

O arquivo principal foi escrito para um fluxo em que Claude Code executa e um servidor Codex MCP atua como revisor. O frontmatter permite Bash, leitura, busca, glob, escrita, edição e duas ferramentas do Codex. Portanto, copiar apenas o Markdown para qualquer cliente não garante funcionamento equivalente.

O repositório mantém uma variante para Codex e guias para outros ambientes. O guia oficial de configuração descreve a combinação principal de Claude Code, Codex MCP e ambiente de pesquisa. Confirme o runtime, a descoberta de Skills e as ferramentas disponíveis antes de instalar.

Para usar o estágio completo, o projeto precisa fornecer descrição do método, resultados, alegações e orçamento. A Skill procura arquivos como research_contract.md, EXPERIMENT_LOG.md, EXPERIMENT_TRACKER.md e configurações do projeto. Se os nomes ou caminhos forem diferentes, informe-os explicitamente.

GPU não é pré-requisito para escrever o plano. Ela se torna relevante quando o fluxo avança para implementação e execução. Antes dessa etapa, registre hardware, filas, limite de horas, custo aceitável, dados autorizados e quem pode aprovar comandos.

Instalação recomendada

Comece pelo diretório da Skill no commit auditado. Leia o arquivo principal e compare o hash antes de qualquer instalação. O repositório completo inclui muitos outros fluxos, scripts e ferramentas. Não trate o número de estrelas como autorização para executar tudo.

No Windows, a documentação oferece um instalador PowerShell com seleção de plataforma:

.toolsinstall_aris.ps1 C:caminhodoprojeto -Platform claude
.toolsinstall_aris.ps1 C:caminhodoprojeto -Platform codex

Esses comandos pertencem ao repositório clonado e podem criar links ou copiar Skills no projeto. Antes de executá-los, use o modo de planejamento disponível na documentação, confira o destino e revise o diff. O instalador oficial no commit é a referência, mas o primeiro teste pode usar apenas uma cópia manual do arquivo em um projeto descartável.

O pacote local do Bastidores é somente documental. Ele não inclui instaladores, scripts, ferramentas auxiliares ou servidor MCP. Essa limitação é intencional: você consegue ler a instrução e a licença antes de decidir se o repositório completo cabe no ambiente.

Configuração antes do primeiro uso

Escreva um contrato mínimo do experimento. Inclua a alegação principal, baseline, componentes removíveis, métricas, datasets, sementes, orçamento e critério de interrupção. Separe o que já foi medido do que ainda é hipótese. Não entregue ao agente uma narrativa que mistura resultado confirmado e resultado desejado.

Defina também a autoridade do primeiro uso. Para uma revisão inicial, permita leitura somente nos arquivos de método e resultados. Bloqueie Bash, Write e Edit, ou mantenha cada chamada sob aprovação. O Codex MCP pode receber conteúdo do projeto, então não envie dados sigilosos, credenciais, material sob embargo ou resultados que não possam sair do ambiente.

O repositório possui um contrato de esforço que relaciona níveis de profundidade a quantidades aproximadas de ablações. Use isso como limite operacional, não como garantia de qualidade. Um plano curto com quatro perguntas fortes pode ser melhor do que dez variações redundantes.

Por fim, determine onde o plano será salvo e quem aprova a transição para execução. Uma saída em Markdown revisada por humano é um bom primeiro marco. A criação de configurações, o envio a uma fila e o consumo de GPU devem ser autorizações separadas.

Primeiro uso seguro

Use um método sintético, sem dados reais. Descreva três componentes, um baseline, duas métricas e um orçamento fictício. Peça explicitamente: “gere apenas o plano; não crie arquivos, não altere código e não execute comandos”. Se o host não consegue impor essa restrição, teste em um diretório descartável e sem credenciais.

Uma entrada de ensaio pode dizer que o método combina um filtro de entrada, um módulo de recuperação e um reranqueador. A alegação é que a combinação melhora qualidade sem aumentar muito a latência. O plano deveria propor remoções individuais, substituições naturais, análise de sensibilidade e ordem baseada em custo informacional.

Confira se cada linha responde a uma dúvida identificável. “Remover o reranqueador” testa a contribuição dele. “Testar mais configurações” não diz o que está sendo isolado. Verifique também se o resultado esperado aparece como hipótese, nunca como número previsto ou conclusão.

Só depois dessa revisão use arquivos reais. Mantenha a primeira passagem em leitura e preserve o plano em um arquivo novo. Não deixe o agente atualizar conclusões, paper ou findings.md antes de a execução existir e passar por conferência independente.

Resultado esperado

A primeira saída útil é uma matriz de ablações priorizada. Ela deve separar remoção de componentes, sensibilidade de hiperparâmetros e comparação de escolhas de projeto. Para cada item, espere uma pergunta, uma hipótese de direção, prioridade e dependências.

O plano também deve indicar quais dúvidas de revisão permanecem abertas. Por exemplo, uma ablação pode mostrar que um módulo contribui para a métrica principal, mas não explicar estabilidade entre datasets. Essa lacuna precisa continuar visível em vez de ser preenchida por uma conclusão geral.

A ordem de execução deve privilegiar experimentos baratos e informativos. Mudanças apenas de configuração costumam vir antes de alterações de código. Isso não é uma regra científica universal, mas um critério de triagem declarado no SKILL.md. Se uma ablação simples invalida a contribuição principal, ela pode evitar uma bateria cara de variações menores.

Nenhum valor de desempenho faz parte do resultado esperado desta página. O Bastidores não executou modelos, não mediu GPU-horas e não verificou uma alegação científica com a Skill. O artefato auditado é a instrução para planejar, não um experimento concluído.

Permissões e riscos

O frontmatter permite Bash, Read, Grep, Glob, Write e Edit. O fluxo também chama um revisor por Codex MCP. Na etapa final, manda criar configurações ou scripts, fazer smoke tests, executar ablações e escrever logs. Em um projeto real, isso pode alterar código, consumir GPU, usar rede, ler resultados e produzir custo.

O risco científico é igualmente importante. Se datasets, seeds, budgets ou baselines mudam entre ablações, a comparação perde controle. Se apenas resultados positivos entram no log, o plano vira seleção conveniente. O arquivo exige registrar resultados negativos, e esse ponto deve ser preservado.

Estimativas de GPU-horas são aproximações até que o hardware, o tamanho do dataset e o tempo por execução sejam medidos. Não transforme a estimativa do agente em compromisso financeiro. Defina teto, fila, timeout e aprovação antes de iniciar qualquer job.

Há ainda risco de exposição. Descrições de métodos inéditos, resultados sob embargo e configurações de servidores podem aparecer no contexto enviado ao revisor. Minimize o material, remova segredos e use apenas integrações aprovadas pela instituição.

Erros comuns

A Skill não aparece no cliente: confirme se o frontmatter foi lido como YAML e se o diretório de descoberta está correto. Um problema antigo de argument-hint em formato de lista foi registrado e corrigido. O issue oficial de compatibilidade ajuda a reconhecer versões anteriores.

Codex MCP não é encontrado: o arquivo principal referencia ferramentas específicas. Verifique a configuração no guia oficial ou use a variante Codex apropriada. Não substitua silenciosamente o revisor por um modelo qualquer e continue chamando o resultado de revisão independente.

O plano repete uma grade de hiperparâmetros: volte à alegação e aos componentes. Cada linha deve isolar uma contribuição ou comparar uma alternativa. Varreduras amplas sem pergunta ficam em prioridade menor ou são removidas.

Resultados esperados viram conclusões: marque-os como hipóteses. Só mude a redação depois de executar, registrar e analisar. Resultado negativo também deve permanecer no EXPERIMENT_LOG.md.

O agente começa a executar sem aprovação: remova permissões de escrita e Bash, use sandbox e divida planejamento, implementação e execução em etapas distintas. O texto da Skill descreve um fluxo completo; sua política de ambiente precisa impor o limite.

Orçamento não fecha: corte primeiro itens de prioridade baixa, preserve as ablações que isolam componentes centrais e registre a cobertura perdida. Não reduza seeds, datasets ou baseline sem explicar o impacto metodológico.

Versão auditada e download local

A auditoria fixou o commit 94d8093ed21d20a790830318190095b9f5036ce8. O arquivo LICENSE materializa a licença MIT. A release v0.4.24 é do repositório completo; o SKILL.md não declara versão própria.

O ZIP contém somente SKILL.md, LICENSE e ORIGEM.md. Não contém instaladores, scripts, executáveis, dependências, conectores MCP, credenciais, dados de pesquisa, configuração de GPU, logs ou resultados.

Baixar o pacote documental auditado

SHA-256 do ZIP: e15026107354644f1e7437f4e218582801511bd5858ff702bae4dc8227e51873

O botão de repositório no card é separado e abre a pasta oficial no commit. Compare o hash e releia a origem antes de atualizar. O pacote local preserva evidência documental, não oferece uma instalação funcional completa.

Resultado esperado e limite final

A Ablation Planner é valiosa quando a equipe já tem um resultado principal e precisa descobrir quais partes sustentam a alegação. Ela força cada experimento a responder uma pergunta e ajuda a ordenar o trabalho pelo custo de informação. Esse é um ganho de método, não uma promessa de aceitação em conferência.

Seu limite mais importante é o alcance operacional. O mesmo fluxo que desenha a matriz também orienta criação de configurações, execução e registro. Instalar a Skill com permissões amplas pode transformar uma revisão de papel em mudanças de código e consumo de recursos. O primeiro uso deve parar no plano.

Antes de avançar, confirme baseline, seeds, métricas, datasets, orçamento, política de dados e autoridade de execução. Depois de rodar, registre resultados positivos, negativos e inconclusivos. Se uma ablação não consegue ser ligada a uma pergunta e a uma alegação, ela ainda não está pronta para consumir compute.

Fontes primárias

• Pasta oficial da Ablation Planner no commit auditado, conteúdo e caminho conferidos em 28 de agosto de 2026.
• Repositório oficial Auto Claude Code Research in Sleep, atividade, estrelas e licença verificadas pela API pública do GitHub.
• README do commit, plataformas, instalação e arquitetura do fluxo.
• Release v0.4.24 do repositório, confirmada na API pública do GitHub.
• Variante oficial para Codex, usada para verificar compatibilidade e diferenças de orquestração.

Curadoria: a pesquisa ampla cobriu GitHub, GitLab, Hugging Face e documentação do mantenedor. Não foi encontrada origem canônica alternativa no GitLab ou Hugging Face. Para versão, licença, instalação e comportamento, prevalecem o repositório e os arquivos fixados no commit.