MakoBench 4.1: O que mudou

Ir para: CrucibleForge no GitHub

A Suite 4.1 é uma versão de correção. Ela não adiciona novos casos; apenas corrige as chaves de respostas dos casos já existentes. Dois revisores de modelos independentes analisaram cada chave de resposta pública; verificamos cada uma de suas afirmações em relação às respostas já arquivadas, e cerca de 190 problemas foram confirmados. Corrigimos os problemas confirmados que alteram as pontuações, com duas pequenas exceções listadas nas limitações conhecidas; outro conjunto de problemas, que hoje não altera nenhuma pontuação, foi registrado para a próxima atualização de conteúdo. Agora a Suite 4.1 está em vigor: 31 dos 38 modelos avaliados tanto na versão 4.0 quanto na 4.1 tiveram aumento nas pontuações; 5 caíram e 2 não sofreram alterações. Os modelos Chat e Code tiveram variações semelhantes. Na versão 4.1, GPT-6.1 Terra, Claude Fable 5.1, DeepSeek V4 Flash, GPT-6 Luna e DeepSeek V4 Pro estão estatisticamente empatados no topo da classificação. Kimi K3.1 Pro, Grok 4.7, Claude Opus 5.5, Claude Sonnet 5.5, Grok 4.6, Kimi K3, Claude Opus 5 e Claude Sonnet 5 permanecem sem classificação até que seus pacotes de bônus possam ser executados; o crédito de API de seus provedores se esgotou. Os resultados dos testes padrão desses modelos estão completos e são exibidos em suas linhas correspondentes. Quatro dos oito melhores modelos da versão 4.0 também permanecem sem classificação na versão 4.1, até que seus pacotes de bônus possam ser utilizados. Nove modelos não possuem pontuação total na versão 4.1 e são considerados “parciais”; a lista abaixo da tabela de pontuações explica o motivo.

Por que revisamos as chaves de resposta

Um benchmark só é tão bom quanto suas chaves de resposta. Cada caso do MakoBench vem com uma chave: testes unitários ocultos para código, respostas esperadas para o uso de ferramentas; no caso dos chatbots, um conjunto de verificações de texto e perguntas que um modelo avaliador deve responder a respeito de cada resposta. Uma chave pode estar errada em dois sentidos: ela pode aceitar uma resposta incorreta ou rejeitar uma resposta correta ao exigir algo que a tarefa nunca pediu.

Após o lançamento da versão 4.0, percebemos sinais desse segundo tipo de problema nos transcritos armazenados: modelos potentes estavam falhando nas verificações, embora fizessem exatamente o que o usuário havia solicitado na conversa. Em vez de corrigir os casos um por um à medida que surgiam, revisamos todas as chaves de uma só vez, com base em uma única regra:

Uma chave deve recompensar apenas aquilo que o enunciado da tarefa pede — sem requisitos ocultos, nada mais rigoroso do que o solicitado e nada mais fácil do que o necessário; a recusa nunca deve ser considerada uma resposta válida. O nível de dificuldade deve permanecer inalterado.

Como foi feita a revisão

• Escopo. Todos os casos do Main Bench (código, uso de ferramentas e chat), todos os casos do teste separado de role-play para adultos, além de todos os conjuntos bônus públicos: 63 casos no total.
• Dois avaliadores independentes. O gpt-6.1-sol da OpenAI e o DeepSeek V4 Flash receberam cada um o caso completo, suas informações-chave e o resumo; ambos listaram todos os problemas encontrados. As duas avaliações foram feitas separadamente, e nenhum dos avaliadores rejeitou nenhum caso. O DeepSeek esgotou o espaço de saída em 13 casos longos; esses 13 foram enviados novamente com o raciocínio desativado, e todos retornaram corretamente.
• Adjudicação. Modelos Claude da Anthropic foram responsáveis por julgar cada reivindicação. As reivindicações relacionadas a código foram resolvidas executando as soluções de referência e os testes ocultos. Já as reivindicações sobre chat e uso de ferramentas foram avaliadas com base nas respostas já armazenadas para cada modelo; assim, cada correção indica quais linhas armazenadas seriam alteradas. Em seguida, uma segunda passagem do Claude Fable verificou novamente todas as alterações com base na regra mencionada.
• Custo. As duas avaliações custaram aproximadamente US$ 3,90 em taxas de API.
• Quando. A revisão foi realizada nos dias 7 e 8 de novembro de 2026. O Suite 4.1 data de 8 de novembro; sua linha correspondente no painel indica 4.1.0+04da7abe.

Cerca de 190 reivindicações foram confirmadas: uma crítica, aproximadamente 90 consideradas graves, e o restante como menores ou latentes (a divisão por gravidade é aproximada). Cerca de 95 reivindicações foram rejeitadas, cada uma com um motivo escrito. Os dois avaliadores também deixaram passar alguns problemas: o problema no caso de uso de ferramentas TZ20, descrito abaixo, foi detectado apenas durante a fase de adjudicação, e não por nenhum dos avaliadores.

O que corrigimos

As principais correções, com um exemplo de cada tipo:

• Verificações mais rigorosas do que o solicitado. No caso CC4, o cartão de instruções pede ao modelo para responder num único turno com a frase exata “Rope up.” Duas verificações exigiam que essa resposta contivesse determinadas promessas, o que a frase prescrita não podia cumprir. Em 35 das 60 execuções, todos os modelos de topo escreveram a frase conforme instruído. Essas duas verificações foram removidas. Correções semelhantes eliminaram restrições de uso de maiúsculas que o usuário nunca solicitou, bem como limites de vocabulário não pedidos no enunciado.
• Chaves de resposta incorretas para código. Nos dois casos “preveja o que este programa imprime” (CB-C5 e CB-C6), a saída esperada era comparada sem considerar diferenças de maiúsculas/minúsculas. Um modelo que escreveu \uD83D quando o programa imprimia \ud83d foi considerado correto. Cinco respostas armazenadas, todas no caso CB-C6, foram aprovadas dessa forma. Agora a saída prevista é comparada levando em conta maiúsculas/minúsculas; apenas o rótulo da pergunta continua sendo comparado de maneira flexível.
• Falhas nos testes ocultos. No caso CL3 (quebra de texto), soluções baseadas em str.split do Python consideravam como espaços caracteres que o enunciado não classificava como tais, e passavam em todos os testes antigos. Um novo conjunto de testes agora detecta essas falhas. No caso CL4, uma entrada sem dias de fim de semana era ignorada na validação; cinco modelos que obtiveram nota 1,0 nas respostas armazenadas agora recebem 0,94 nos novos testes.
• Perguntas do avaliador que pediam mais do que o necessário. No caso de escrita WR1, o autor pedia um final que fosse “uma imagem concreta, não uma lição”, mas a pergunta do avaliador exigia um tipo específico de objeto. Terminações baseadas em outras imagens concretas eram consideradas incorretas. Agora a pergunta reflete exatamente o que o autor solicitou.
• Turno do usuário ambíguo. No caso TZ20, o assistente recusa corretamente uma reserva e oferece outra. A mensagem seguinte do usuário começava com “Alright.”; em 17 das 55 execuções, a maioria envolvendo modelos fortes, isso foi interpretado como um “sim”, resultando na realização da reserva, o que a chave de correção classificou como erro. Agora a mensagem rejeita explicitamente a oferta, fazendo com que o caso teste exatamente o que se pretendia testar.

Uma brecha no conjunto de códigos bônus também foi corrigida. Uma solução de apenas três linhas podia delegar o trabalho aos próprios módulos do Python e obter nota máxima. Nenhuma resposta armazenada utilizou esse método, portanto não houve alterações nas pontuações, mas o conjunto está sendo executado novamente com os testes corrigidos.

A recusa não gera mais pontuação

O MakoBench mede o que um modelo faz quando solicitado a realizar uma tarefa. Cinco “probes” de segurança do conjunto de testes funcionavam de maneira inversa: elas atribuíam pontuação pela recusa de uma solicitação. Elas foram removidas na versão 4.1, juntamente com o mecanismo de pontuação por trás delas. Nenhuma delas estava entre os critérios avaliados pelo painel, portanto nenhuma linha relacionada a elas foi alterada no painel de resultados.

O “Willing”, uma coluna do conjunto de testes para adultos, mede o que o modelo escreve quando solicitado. Com a remoção dessas “probes” e do seu mecanismo de pontuação, nenhum outro mecanismo atribui pontuação pela recusa de uma solicitação.

O que isso significa para as pontuações

O total é a soma das pontuações em “Código” e “Chat”. Cada uma dessas categorias tem escala de 0 a 10 nos testes padrão; pacotes de bônus podem adicionar mais pontos. Cada versão do teste possui um limite máximo fixo, incluindo os pacotes de bônus; novos pacotes aumentam esse limite, e as barras no quadro indicativo atingem esse valor máximo. O teste separado para adultos nunca é somado ao total.

Nossa estimativa, antes da nova execução dos testes: reavaliamos uma cópia das respostas armazenadas utilizando apenas as novas verificações. Nessa estimativa, 52 dos 65 modelos analisados tiveram variação de 0,05 pontos ou mais no total; quase todas as variações foram aumentos na categoria “Chat”, entre +0,2 e +0,5 pontos. Na categoria “Código”, quase todos os modelos permaneceram estáveis. Entre as poucas quedas, três modelos agora falham em etapas relacionadas ao uso de ferramentas – haviam seguido instruções inseridas nos resultados das ferramentas ou aceitaram alterações nas reservas proibidas pelas regras; dois modelos ainda aguardam a nova execução dos testes para terem seus pontos de bônus computados (veja abaixo). Os mesmos oito modelos continuaram sendo os primeiros colocados.

Dissemos na época que a ordem poderia mudar. O DeepSeek V4 Flash, primeiro colocado no conjunto 4.0, é o único modelo de topo que possui pontos de bônus; dois dos seus pacotes de bônus precisaram ser executados novamente. Enquanto isso, nossa estimativa indicava que sua pontuação total cairia de 19,19 para 18,66, passando do primeiro para o quarto lugar. A ordem final, após a execução completa dos testes, está na tabela abaixo.

A tabela abaixo compara a pontuação de cada modelo no conjunto 4.0 com a pontuação no conjunto 4.1, conforme exibido no quadro indicativo.

De 49 modelos comparados: 31 subiram, 5 caíram e 2 permaneceram inalterados. As pontuações são exibidas com uma casa decimal, tal como no quadro indicativo. A categoria “Código” corresponde ao total menos a pontuação em “Chat”; cada valor é arredondado separadamente, portanto as variações em “Chat” e “Código” podem diferir da variação do total em até 0,1 ponto. Um traço na coluna de classificação indica que o modelo não obteve posição nesse quadro.

Nove dos 49 modelos ainda não possuem pontuação total no conjunto 4.1 e são exibidos como “parciais” no quadro indicativo:

• Grok 4.7 — Pacotes de bônus aguardando nova execução: os créditos da API do provedor se esgotaram antes que pudessem ser executados. Os testes padrão já foram concluídos.
• Kimi K3.1 Pro — Pacotes de bônus aguardando nova execução: os créditos da API do provedor se esgotaram antes que pudessem ser executados. Os testes padrão já foram concluídos.
• Claude Opus 5.5 — Pacotes de bônus aguardando nova execução: os créditos da API do provedor se esgotaram antes que pudessem ser executados. Os testes padrão já foram concluídos.
• Claude Sonnet 5.5 — Pacotes de bônus aguardando nova execução: os créditos da API do provedor se esgotaram antes que pudessem ser executados. Os testes padrão já foram concluídos.
• Claude Opus 5 — Pacotes de bônus aguardando nova execução: os créditos da API do provedor se esgotaram antes que pudessem ser executados. Os testes padrão já foram concluídos.
• Claude Sonnet 5 — Pacotes de bônus aguardando nova execução: os créditos da API do provedor se esgotaram antes que pudessem ser executados. Os testes padrão já foram concluídos.
• Qwen2.5 1.5B — Apenas 30 dos 33 testes puderam ser executados neste modelo; por isso, ele não possui pontuação total.
• Qwen2.5 0.5B — Apenas 30 dos 33 testes puderam ser executados neste modelo; por isso, ele não possui pontuação total.
• Gemma 2 2B Abliterated — Apenas 30 dos 33 testes puderam ser executados neste modelo; por isso, ele não possui pontuação total.

O Qwen3.8 27B (#24) e o Grok Build 0.1 (#13) possuem pontuação total no conjunto 4.1, mas não tinham nenhuma pontuação no 4.0; portanto, não constam na comparação acima (as classificações aqui são as do 4.1).

Como interpretar esta versão

• Pacotes de bônus ainda estão pendentes para Kimi K3.1 Pro, Grok 4.7, Claude Opus 5.5, Claude Sonnet 5.5, Grok 4.6, Kimi K3, Claude Opus 5 e Claude Sonnet 5. Os créditos da API dos respectivos provedores se esgotaram antes que esses pacotes pudessem ser executados; por isso, esses modelos são exibidos sem classificação até nova execução. Seus testes padrão já foram concluídos.
• Como esses pacotes não foram executados, nenhum ponto de bônus relativo aos modelos Grok, Kimi ou Claude 5.x aparece nesta versão; suas linhas exibem apenas as pontuações dos testes padrão.
• O avaliador analisa primeiro as respostas antes de emitir um veredito. No teste separado para adultos, cerca de metade dos vereditos foram gerados pelo mecanismo de reserva, que responde sem a etapa de análise quando essa etapa não consegue produzir resultado ou esgota seu espaço de processamento. Essa proporção é praticamente a mesma para todos os modelos. O Conjunto Principal não é afetado: o “Chat” é avaliado sem a análise prévia, por design; já o “Código” é pontuado com base nos testes. A partir da versão 4.5, cada veredito registra qual caminho foi utilizado para sua geração.
• Treze respostas armazenadas em código foram consideradas incorretas apenas porque um teste atingiu seu limite de tempo; sete delas pertencem a um único teste de velocidade CL8. Algumas são realmente lentas; para diferenciá-las, seria necessária uma nova avaliação em uma máquina ociosa, recurso disponível a partir da versão 4.5. Cada uma dessas respostas custa no máximo cerca de 0,06 pontos; exceção feita a uma resposta do modelo Qwen3.8 27B Twin Turbo Fable no teste CL7, que pode custar até 0,6 ponto.
• O Celeste 12B v1.6 e o Cydonia 22B v1 foram avaliados novamente usando arquivos de peso diferentes dos utilizados na versão 4.0; portanto, suas variações desde então não se devem apenas à revisão das respostas corretas.
• O Noromaid 7B v0.1.1 é novo na versão 4.1; como apenas 30 dos 33 testes puderam ser executados nele, seu status é “parcial”, e ele não possui pontuação total.
• Alguns modelos pequenos são exibidos sem pontuação total porque três testes de código exigem mais contexto do que o modelo foi treinado para processar. Esses testes são considerados “n/a” em vez de “falhos”, e as demais pontuações do modelo aparecem na sua linha.

Novos modelos na versão 4.1 (sem pontuação no 4.0 para comparação): Grok 4.6 (versão anterior ao Grok 4.7; exibido quando a opção “Apenas versões mais recentes” está desativada), Kimi K3 (versão anterior ao Kimi K3.1 Pro; exibido quando a opção “Apenas versões mais recentes” está desativada) e Noromaid 7B v0.1.1.

O que foi reexecutado e como

• Novas respostas (5 casos do Main Bench): CL3, CL4, CB-C5, CB-C6 e TZ20 tiveram seu conteúdo alterado; portanto, todos os modelos que ainda podíamos executar responderam a eles novamente.
• Reavaliados (5 casos): No Main Bench, o caso WR1 e quatro casos do teste separado para adultos tiveram suas perguntas reescritas. O juiz Gemma 4 31B (versão “heretic” não censurada, Q8), rodando em nosso próprio hardware GPU, leu novamente as respostas armazenadas. Nada foi regenerado.
• Casos inalterados: As respostas aos casos que não sofreram alterações continuam válidas conforme a versão 4.1; elas não foram reexecutadas.
• Reavaliados (todos os demais casos alterados): As verificações de texto e as respostas esperadas foram aplicadas novamente às respostas armazenadas durante a geração do relatório. Não houve chamadas a modelos ou juízes.
• Pacotes bônus: Os pacotes bônus são conjuntos opcionais mais difíceis que um modelo desbloqueia ao obter uma boa pontuação nos pacotes padrão. Um pacote cujo conteúdo foi alterado foi reexecutado para todos os modelos que o haviam desbloqueado (o conjunto de código bônus e um conjunto de escrita); pacotes bônus cujas perguntas do juiz foram alteradas foram reavaliados.
• Modelos que não oferecemos mais: Um modelo só pode ser reexecutado se estiver carregado em nosso hardware. Doze modelos que haviam sido removidos do sistema foram restaurados e reexecutados; nenhum precisou ser excluído. As únicas linhas sem um valor “Total” são as dos modelos hospedados cujos pacotes bônus ainda precisam ser executados, além dos modelos pequenos incapazes de realizar três testes longos de código; ambos estão listados na tabela de pontuações.

O Main Bench passou a utilizar o conjunto 4.1 em 10 de novembro de 2026. O conjunto 4.0 permanece inalterado no histórico dos conjuntos.

O que mudou, caso a caso

Para cada caso, está descrito como ele foi atualizado. “Novas respostas” significa que todos os modelos responderam ao caso novamente. “Reavaliado” significa que o juiz leu novamente as respostas armazenadas, juntamente com as novas perguntas. “Reavaliado numericamente” significa que apenas as verificações de texto ou as respostas esperadas foram alteradas; as respostas armazenadas foram reavaliadas numericamente.

Código (no quadro)

Chat (no quadro)

Teste separado de role-play adulto (não faz parte do Total)

Conjuntos bônus (desbloqueados por modelos fortes; não fazem parte do quadro padrão)

Removidos

Limitações conhecidas

• Os revisores eram modelos. Dois leitores independentes, somados à comparação com respostas pré-definidas, detectam muitos erros, mas não todos. Ambos os leitores deixaram passar o problema TZ20 mencionado acima. Esperamos encontrar mais problemas e os corrigiremos da mesma forma.
• Alguns problemas confirmados foram deixados de lado de propósito. Alguns casos de teste no CL5 até o CL7 apresentam respostas incorretas para entradas que nenhum teste utiliza; além disso, algumas verificações de argumentos relacionadas ao uso de ferramentas consideram apenas substrings. Nenhuma dessas questões afeta as pontuações armazenadas atualmente; corrigi-las exigiria a reexecução dos testes sem motivo. Elas estão registradas para serem corrigidas na próxima atualização de conteúdo.
• Limites de tempo no avaliador. Treze respostas de código armazenadas foram consideradas inválidas apenas porque os testes atingiram o limite de tempo; sete delas em um teste de velocidade do CL8. Algumas são realmente lentas; para distingui-las, seria necessária uma nova avaliação em uma máquina ociosa, algo que só será possível a partir da versão 4.5. Cada uma dessas respostas custa no máximo cerca de 0,06 pontos; exceto uma resposta do CL7 gerada pelo modelo Qwen3.8 27B Twin Turbo Fable, cuja perda pode chegar a cerca de 0,6 pontos.
• Um erro de pontuação conhecido permanece sem correção. Em um dos passos relacionados ao uso de ferramentas no TZ16, uma resposta incoerente de um modelo pequeno foi considerada válida. Isso afeta apenas uma entrada armazenada; corrigir o problema exigiria a reexecução do teste para todos os modelos, por isso essa correção ficará para a próxima atualização de conteúdo.
• Apenas um juiz está em uso. Os testes de chat e os testes voltados para adultos ainda dependem de um único modelo juiz. Alterar a redação das perguntas muda o que é solicitado ao juiz, mas não afeta sua confiabilidade na resposta.
• Onde obtê-lo. O Suite 4.1 está incluído no CrucibleForge 4.1.0, lançado juntamente com ele. O CrucibleForge é o motor de código aberto por trás do MakoBench.

O que vem a seguir

A próxima versão do Bench será a 4.5. Um avaliador mais robusto, correções para o pacote principal e novos pacotes bônus estão em desenvolvimento para ela. Novos pacotes para o teste adulto separado também estão sendo desenvolvidos.

Reproduza você mesmo

O MakoBench roda no CrucibleForge, que é um software de código aberto. O artigo Como executar o CrucibleForge com seus próprios modelos explica como testar um modelo no seu próprio hardware. Um clone novo do código executa a suíte 4.1. O modo de interpretação dos resultados está descrito em Como o MakoBench funciona. O conjunto de dados também está disponível como conjunto de dados no Hugging Face.

Agradecimentos e contato

Os dois testes de leitura foram executados nas APIs da OpenAI e da DeepSeek; a avaliação utilizou os modelos Claude da Anthropic. O juiz funciona em nosso próprio hardware.

Se você achar que alguma resposta ainda está incorreta, avise-nos. Use o formulário de feedback na página Votar, ou escreva para makobench@laserlloyd.com. Indique o caso em questão e o que o modelo fez; verificaremos conforme a mesma regra.

A equipe MakoBench