Pesquisas por Anthropic Simon encontram smevals, uma aposta menor na avaliação de IA

Simon Willison lançou o smevals após anos de experimentos com evals, criando um novo contraste com as orientações mais formais da Anthropic para testar agentes de IA. A conexão anthropic simon importa porque ambos os lados agora enfatizam o mesmo problema. Uma pontuação de modelo diz pouco, a menos que as equipes também testem prompts, ferramentas, instruções de sistema e o harness que envolve esse modelo.

Willison desenvolveu o smevals com o laboratório de pesquisa em IA aplicada Prime Radiant, de Jesse Vincent. O projeto executa pequenas suítes de avaliação em várias configurações, classifica suas saídas e gera relatórios para uma inspeção mais detalhada.

O lançamento desafia uma suposição comum sobre avaliação de IA. As equipes nem sempre precisam de uma grande plataforma de benchmarks antes de poderem fazer uma pergunta útil. Elas precisam de uma tarefa focada, configurações reproduzíveis, verificações explícitas e visibilidade suficiente para entender as falhas.

Isso torna a principal disputa menor e mais prática do que Anthropic versus outro provedor de modelos. O foco é a avaliação local e direcionada versus uma infraestrutura de avaliação generalizada e robusta. A primeira favorece velocidade e capacidade de inspeção, enquanto a segunda viabiliza experimentos mais amplos e ambientes mais complexos.

O que o smevals mudou para pequenas avaliações de IA

O smevals transforma uma pergunta específica de produto em um diretório portátil de tarefas, configurações e regras de classificação.

Willison anunciou o smevals em 31 de julho de 2026. Sua visão geral do smevals o descreve como uma ferramenta para executar pequenas suítes de evals em diferentes configurações de modelo e classificar as saídas resultantes.

O fluxo de trabalho básico começa com uvx smevals docs. Esse comando fornece a documentação do projeto a um agente de programação, permitindo que ele estude o formato antes de criar uma suíte de avaliação.

Essa abordagem trata a documentação como contexto operacional. Em vez de pedir que os usuários memorizem todos os campos de configuração, o projeto espera que um agente de programação leia as instruções e ajude a criar os arquivos.

Uma avaliação então fica dentro de um diretório que contém arquivos YAML. YAML é um formato de dados legível por humanos, frequentemente usado para configuração. Esses arquivos descrevem a pergunta, as tarefas, as configurações de modelo e o comportamento de classificação.

Um usuário pode executar a mesma suíte contra vários modelos. O exemplo de Willison compara configurações nomeadas de GPT e Claude por meio de argumentos -m repetidos.

Essa estrutura de comando é importante. Ela enquadra a escolha do modelo como uma variável dentro de um experimento maior, em vez de tratar o modelo como o produto inteiro.

O smevals também separa execução de classificação. O comando run registra o que ocorreu quando uma configuração tentou realizar uma tarefa. O comando grade aplica posteriormente verificações definidas a esses resultados registrados.

Essa separação cria uma fronteira útil para auditoria. As equipes podem preservar o comportamento bruto, revisar sua lógica de classificação e examinar como uma rubrica diferente altera a interpretação.

A ferramenta oferece dois caminhos de relatório. O comando serve inicia uma interface web local, enquanto build produz HTML estático que pode ser hospedado em outro lugar.

Willison demonstrou o fluxo de trabalho com uma avaliação de haicais. O relatório verificou se os modelos produziam exatamente três linhas não vazias e classificou as configurações usando as notas resultantes.

Um benchmark de haicais é deliberadamente modesto. Ainda assim, ele ilustra um princípio sério de avaliação: requisitos definidos de forma restrita frequentemente revelam diferenças que pontuações amplas de preferência não conseguem explicar.

O lançamento também introduz um vocabulário consistente. Uma eval contém tarefas, enquanto uma configuração define o modelo e outras variáveis em análise.

Uma execução registra uma configuração tentando realizar uma tarefa. Um avaliador produz uma nota ao aplicar verificações, incluindo verificações determinísticas ou scripts personalizados de checagem.

Essas verificações personalizadas podem inspecionar strings, validar formatos como XML ou chamar outro modelo para emitir um julgamento. Essa variedade permite que uma suíte combine restrições objetivas com avaliações de qualidade mais subjetivas.

Nada nesse fluxo de trabalho estabelece o smevals como um produto da Anthropic. A associação anthropic simon decorre do interesse sobreposto em avaliação de agentes e configurações do Claude, não de propriedade corporativa.

A mudança imediata é, portanto, a acessibilidade. Um desenvolvedor agora pode empacotar uma pequena questão de avaliação sem antes adotar um serviço de avaliação extenso ou criar um dashboard personalizado.

Por que o interesse em Anthropic Simon agora se concentra no harness

O modelo deixou de ser a única unidade significativa de comparação porque o harness de agente ao redor dele pode alterar o resultado.

A Anthropic define um harness de agente como o sistema que processa a entrada, coordena chamadas de ferramentas e retorna resultados. Sua orientação sobre evals de agentes distingue essa camada do harness de avaliação que executa e classifica experimentos.

Essa distinção ajuda a explicar por que o smevals oferece suporte a configurações além de um nome de modelo. Uma configuração também pode incluir diferentes prompts de sistema, parâmetros de modelo ou harnesses de agentes.

Suponha que dois produtos de programação usem o mesmo modelo subjacente. Um fornece ao modelo melhor contexto do repositório, enquanto o outro disponibiliza ferramentas mais robustas e verificações de conclusão mais claras.

Um benchmark apenas de modelo trataria esses sistemas como equivalentes. Uma avaliação no nível de configuração pode mostrar que seu comportamento real é diferente.

A pressão recai sobre equipes de produtos de IA que ainda selecionam modelos apenas com base em rankings públicos. Essas classificações podem ajudar a restringir o campo, mas raramente reproduzem os prompts, ferramentas, permissões e dados exatos de um produto.

O comportamento de um agente também se desenrola em várias etapas. Um sistema pode chamar uma ferramenta, modificar o estado, interpretar o resultado e decidir se deve continuar.

Um erro inicial pode afetar todas as ações posteriores. Isso torna a avaliação de um agente diferente de verificar se um chatbot respondeu corretamente a uma única pergunta.

As orientações da Anthropic afirmam que as equipes avaliam o modelo e o harness de agente em conjunto quando avaliam um agente. Essa visão se alinha de perto ao modelo de configuração usado pelo smevals.

Essa sobreposição é a verdadeira história de anthropic simon. Ambas as abordagens deslocam a atenção da inteligência isolada do modelo para o sistema completo que os usuários experimentam.

O momento também reflete um problema operacional crescente. Modelos, prompts e harnesses mudam de forma independente, mas as equipes de produto ainda precisam identificar o que causou uma regressão.

Um novo modelo pode melhorar o raciocínio enquanto altera o estilo de saída. Um prompt de sistema revisado pode reduzir a verbosidade, mas enfraquecer o seguimento de instruções. Uma atualização do harness pode expor ferramentas melhores enquanto introduz erros de estado.

Sem configurações controladas, essas mudanças ficam entrelaçadas. As equipes percebem que um produto parece diferente, mas não conseguem atribuir a diferença com confiança.

A Anthropic descreve essa condição como operar sem visibilidade suficiente. As equipes esperam reclamações de usuários, reproduzem falhas manualmente, corrigem um problema e correm o risco de criar outra regressão.

O smevals oferece uma resposta menor ao mesmo problema. Ele não tenta reproduzir todas as condições de produção. Ele dá às equipes uma forma estruturada de isolar uma questão antes de expandir o experimento.

Isso importa para trabalhos intensivos em conhecimento. Uma equipe de engenharia pode testar se um assistente encontra a especificação interna correta antes de gerar código.

O teste poderia comparar dois prompts de recuperação, duas versões de modelo ou duas políticas de ferramentas. Equipes que mantêm uma base de conhecimento pesquisável enfrentam questões semelhantes sempre que o acesso a documentos muda.

A comparação resultante é mais útil do que perguntar qual modelo é o melhor. Ela pergunta qual configuração completa executa uma tarefa definida sob condições declaradas.

O mecanismo é a separação, não uma pontuação mais inteligente

O smevals obtém clareza ao manter tarefas, execução, classificação e relatórios suficientemente separados para serem inspecionados de forma independente.

Muitos produtos de avaliação prometem uma única pontuação que torna a comparação fácil. Essa conveniência pode ocultar as decisões que produziram a pontuação.

O smevals adota uma abordagem mais decomposta. A eval apresenta a questão maior, e cada tarefa traz um desafio específico.

As configurações então descrevem os sistemas que tentam realizar essas tarefas. Uma execução registra a tentativa, enquanto um avaliador analisa o resultado salvo por meio de uma ou mais verificações.

Essa arquitetura soa como testes comuns porque grande parte dela segue a lógica de testes comuns. Entradas, condições, saídas, asserções e relatórios continuam sendo conceitos reconhecíveis.

O comportamento de modelos de linguagem complica cada componente. O mesmo prompt pode produzir respostas diferentes, enquanto várias respostas diferentes podem satisfazer o usuário.

Uma verificação útil, portanto, precisa corresponder ao requisito. A correspondência exata de strings é adequada para um token fixo, mas funciona mal quando várias formulações são válidas.

Verificações estruturais oferecem outra opção. Uma equipe pode validar JSON, XML, número de linhas, seções obrigatórias ou arquivos criados dentro de um ambiente de agente.

Avaliadores baseados em modelos lidam com qualidades menos determinísticas. Outro modelo pode avaliar se uma resposta segue uma rubrica, inclui o raciocínio necessário ou atende a um requisito de estilo.

No entanto, um juiz de IA não transforma uma questão subjetiva em verdade objetiva. Ele introduz outro modelo, prompt e conjunto de pressupostos na avaliação.

Separar a classificação da execução torna essa limitação mais fácil de investigar. Uma equipe pode preservar as mesmas execuções e comparar vários métodos de classificação sem pagar por cada tarefa novamente.

Ela também pode inspecionar divergências. Se um verificador de formato aprova enquanto um juiz de IA reprova, o relatório revela duas dimensões diferentes em vez de fazer uma média delas imediatamente.

A camada de relatórios importa pelo mesmo motivo. Pontuações agregadas ajudam os leitores a examinar os resultados rapidamente, mas execuções individuais revelam por que uma configuração teve sucesso ou falhou.

O exemplo de haicais de Willison ilustra esse equilíbrio. Um ranking fornece o resumo, enquanto execuções recentes, detalhes das tarefas, tags e informações do avaliador expõem as evidências subjacentes.

O HTML estático acrescenta outro benefício prático. Uma equipe pode publicar um resultado sem manter um serviço de avaliação ativo.

O ponto de entrada uvx também reduz o atrito de configuração. De acordo com o guia oficial da ferramenta uv, uvx executa uma ferramenta empacotada em um ambiente temporário e isolado.

Esse design é adequado para investigações curtas. Um desenvolvedor pode experimentar o comando sem tornar uma instalação global persistente o primeiro requisito.

O fluxo de trabalho com agente de programação reduz outro custo de configuração. O agente pode ler a documentação do projeto, propor arquivos YAML e ajudar a refinar o teste.

A revisão humana continua necessária. Uma suíte gerada por agente pode codificar expectativas vagas, omitir casos difíceis ou criar verificações que apenas recompensam suas próprias suposições.

A ferramenta, portanto, não elimina o design de avaliação. Ela reduz a distância entre uma pergunta e a primeira versão executável dessa pergunta.

Essa diferença importa. As equipes frequentemente adiam a avaliação porque imaginam que o primeiro passo envolve bancos de dados, dashboards, sistemas de rastreamento e um grande conjunto de dados de referência.

O smevals propõe um primeiro passo mais restrito: codificar uma incerteza real e executá-la em algumas configurações controladas.

Pequenas suítes de evals desafiam frameworks robustos

O argumento mais forte a favor do smevals não é a amplitude de recursos, mas a capacidade de começar com uma questão delimitada e preservar as evidências.

O mercado de avaliação já inclui frameworks abertos mais abrangentes. A plataforma Inspect, do UK AI Security Institute, oferece suporte a conjuntos de dados, resolvedores, avaliadores, agentes, sandboxes, provedores de modelos e transcrições detalhadas.

A documentação do Inspect apresenta uma tarefa como a combinação de um conjunto de dados, um resolvedor e um avaliador. O resolvedor pode fazer uma única chamada de modelo ou operar um agente de múltiplas etapas com ferramentas.

O Inspect também oferece suporte a avaliações complexas de segurança e ambientes de execução isolados. Esses recursos atendem a organizações que executam benchmarks formais ou testam agentes que modificam estados externos.

O Promptfoo aborda o problema a partir de testes de prompts e aplicações. Seu formato de configuração abrange provedores, prompts, casos de teste, asserções e variáveis.

O workspace de avaliação oficial mostra como o YAML pode definir provedores, prompts e comportamentos esperados. Isso torna o Promptfoo uma comparação relevante para equipes que já tratam prompts como código testável.

O smevals entra nesse campo com um escopo declarado menor. Sua vantagem depende de esse escopo reduzido permanecer coerente à medida que os usuários solicitam mais recursos.

Uma suíte focada pode ser mais fácil de revisar. Cada tarefa pode se relacionar diretamente a uma decisão de produto, e cada configuração pode representar uma mudança que uma equipe realmente enviaria.

Esse foco também melhora a análise de falhas. Um teste nomeado em torno de uma necessidade concreta do usuário informa mais aos desenvolvedores do que uma categoria abstrata de capacidade.

Considere um assistente que prepara atualizações semanais de produto. Uma pequena suíte poderia testar se ele cita as notas de reunião corretas, distingue decisões de propostas e evita alegações sem respaldo.

As configurações poderiam variar o prompt de recuperação, o modelo e a ferramenta de seleção de documentos. Os avaliadores poderiam verificar a presença de citações, a identidade das fontes e a consistência factual.

Um benchmark público não responderia a essa pergunta de produto. Ele não tem os documentos da equipe, o fluxo de trabalho esperado nem a definição de uma atualização útil.

Frameworks robustos continuam valiosos quando o próprio ambiente exige simulação. Agentes de navegador, agentes de programação e sistemas de atendimento ao cliente frequentemente precisam de tarefas com estado e bancos de dados ou sandboxes reproduzíveis.

Pequenas suítes em YAML não recriam automaticamente essas condições. Elas precisam de executores compatíveis, scripts, fixtures ou outros componentes de harness.

É por isso que o principal concorrente é uma abordagem, não uma empresa específica. A escolha está entre começar localmente com uma pergunta restrita e começar com uma infraestrutura de avaliação generalizada.

Nenhuma das abordagens vence em todos os casos. A menor vence quando o custo de configuração impede as equipes de testar qualquer coisa.

A abordagem mais ampla vence quando o teste precisa controlar estados complexos, capturar trajetórias completas, garantir isolamento ou operar continuamente dentro de pipelines de implantação.

A progressão mais útil talvez conecte as duas. Uma equipe pode descobrir casos valiosos por meio do smevals e, depois, migrar testes maduros para um sistema maior de regressão.

Essa progressão só funciona se os artefatos permanecerem legíveis. Tarefas, configurações, saídas e regras de avaliação precisam ser claras o bastante para que outro engenheiro possa reproduzi-las.

O smevals parece ser projetado em torno dessa portabilidade, mas a adoção determinará se a convenção se sustenta. A substituição das ferramentas se torna mais difícil à medida que avaliadores e executores personalizados se acumulam.

O tamanho reduzido do projeto é, portanto, tanto seu argumento de venda quanto seu teste. Ele precisa adicionar recursos suficientes para agentes reais sem recriar todas as plataformas complexas de avaliação.

O que as pontuações ainda não conseguem resolver

Uma suíte repetível pode expor comportamentos, mas não pode garantir que suas tarefas, avaliadores e amostras representem a realidade de produção.

A primeira incerteza diz respeito à cobertura. Uma suíte compacta pode responder bem a uma pergunta restrita enquanto deixa de lado falhas raras que importam mais do que sua pontuação média.

As equipes também podem escrever tarefas em torno de casos de sucesso conhecidos. Agentes de programação solicitados a gerar evals podem produzir variações plausíveis sem descobrir os casos-limite surpreendentes encontrados por usuários reais.

Incidentes de produção devem, portanto, retroalimentar a suíte. Reclamações, rastros de falha, tickets de suporte e revisões manuais podem revelar cenários que a geração sintética de tarefas não identificou.

A segunda incerteza é a não determinismo. Os modelos podem produzir resultados diferentes em tentativas repetidas, mesmo quando a configuração parece inalterada.

Uma única execução por tarefa não consegue distinguir uma configuração confiável de outra que apenas teve sucesso por acaso. Testes repetidos tornam-se essenciais quando a variação da saída afeta a decisão.

As orientações de avaliação da Anthropic recomendam examinar taxas de sucesso em múltiplas tentativas. Elas também alertam que um modelo pode encontrar uma solução válida que o avaliador não previu.

Isso cria um modo de falha difícil. Um avaliador rígido pode punir um resultado criativo mesmo quando ele atende melhor ao usuário.

O problema oposto ocorre com avaliadores baseados em modelos. Um juiz de IA generoso pode aceitar uma saída fluente que viola um requisito oculto importante.

A calibração humana ajuda a identificar esses erros. Os revisores devem inspecionar aprovações e falhas, comparar decisões dos avaliadores e revisar rubricas quando o juiz recompensa o comportamento errado.

A terceira incerteza diz respeito à contaminação entre o sistema e o avaliador. Quando agentes de programação ajudam a escrever tarefas, prompts e verificações, suas preferências podem moldar o benchmark.

Usar um modelo relacionado como avaliador pode aprofundar esse efeito. O teste pode favorecer formulações ou padrões de raciocínio familiares sem medir a utilidade real.

Isso não torna a avaliação por modelos inválida. Significa que a nota deve continuar rastreável a uma rubrica, à configuração do juiz e ao processo de revisão.

A quarta questão é a confiança estatística. Uma suíte de três tarefas pode identificar uma regressão óbvia de formato, mas não pode sustentar afirmações amplas sobre a qualidade de um modelo.

O smevals se define como uma pequena suíte de evals, e os leitores devem preservar esse limite. Seus relatórios comparam as tarefas executadas, não todas as capacidades dos modelos envolvidos.

As equipes devem evitar transformar um resultado local em uma classificação universal. “A configuração A passou em oito casos de produto” é defensável. “O modelo A é melhor” geralmente não é.

Custos e latência exigem cuidado semelhante. Uma configuração que obtém uma pontuação maior pode usar prompts mais longos, mais chamadas de ferramentas ou um modo de raciocínio mais lento.

Se esses fatores importam para o produto, a suíte precisa registrá-los e compará-los. Pontuações de qualidade, por si só, não podem determinar a melhor escolha para lançamento.

A segurança também altera o desenho da avaliação. Um agente com acesso a shell, navegador ou banco de dados precisa de ambientes isolados e verificações do estado final.

Uma transcrição pode mostrar que um agente afirmou ter tido sucesso. O resultado real depende de ele ter criado o arquivo correto, alterado o registro pretendido ou evitado ações proibidas.

Essas limitações não são um argumento contra evals pequenas. Elas definem onde uma pequena suíte permanece confiável.

A convergência anthropic simon é útil justamente porque nenhuma das abordagens trata um número agregado como a linha de chegada. Execuções, rastros, resultados e comportamento dos avaliadores merecem inspeção.

Três sinais mostrarão se a sobreposição entre Anthropic e Simon perdura

O smevals será relevante além de seu lançamento se as equipes o usarem para comparar decisões reais de harness, calibrar avaliadores e preservar evidências repetíveis.

O primeiro sinal é a variedade de suítes de avaliação publicadas. A formatação do Haiku comprova o fluxo de trabalho, mas desenvolvedores de agentes precisam de exemplos envolvendo ferramentas, estado e conclusão em múltiplas etapas.

Suítes que comparam apenas prompts manteriam o smevals próximo das ferramentas estabelecidas de teste de prompts. Suítes que comparam harnesses de programação ou pesquisa sustentariam seu posicionamento mais amplo.

A avaliação se fortalece se os usuários publicarem casos de agentes reproduzíveis com execuções e verificações visíveis. Ela se enfraquece se os exemplos continuarem limitados a tarefas curtas de formatação de texto.

O segundo sinal é a calibração dos avaliadores. O projeto oferece suporte a verificações determinísticas e scripts de verificação mais complexos, incluindo avaliação baseada em modelos.

Agora, os usuários precisam de métodos para comparar essas notas com o julgamento humano. Relatórios úteis devem expor divergências, em vez de escondê-las em uma única pontuação.

O argumento a favor do smevals se fortalece se as equipes puderem reexecutar a avaliação, inspecionar rubricas e documentar por que os avaliadores mudaram. Ele se enfraquece se os rankings se desvincularem das evidências subjacentes.

O terceiro sinal é a integração ao desenvolvimento cotidiano. Um experimento local gera insight uma vez, enquanto uma suíte de regressão protege mudanças futuras.

Observe se as equipes executam o smevals após atualizações de modelo, edições de prompt, mudanças em ferramentas e lançamentos de harness. O uso repetido mostraria que pequenas suítes podem se tornar ativos duradouros de engenharia.

A integração não exige que todas as equipes construam uma plataforma elaborada. Um repositório compartilhado, YAML revisado, execuções salvas e uma verificação consistente de lançamento podem ser suficientes.

O sinal se enfraquece se as suítes se tornarem obsoletas após a comparação inicial. Um benchmark desatualizado pode gerar confiança sem refletir o produto atual.

Para desenvolvedores e compradores corporativos, a ação prática é simples. Identifique uma decisão que atualmente está sendo tomada com base na intuição e, então, defina o menor teste que poderia questioná-la.

Essa decisão pode envolver Claude versus GPT, mas também pode envolver dois prompts de sistema ou duas estratégias de recuperação. A configuração deve refletir o que os usuários realmente experimentam.

Trate o primeiro resultado como evidência, não como veredito. Inspecione as falhas, questione o avaliador, adicione casos do trabalho real e repita os testes onde o comportamento variar.

A lição duradoura de anthropic simon não é que uma pequena ferramenta resolve a avaliação de IA. É que a escolha do modelo, o desenho do prompt e o comportamento do harness precisam ser testados juntos.

Qual decisão de produto sua equipe ainda toma com base em demos, rankings ou instinto? Transforme essa incerteza em uma suíte focada, preserve as execuções e veja se as evidências mudam a resposta.