Como o MakoBench funciona: Explicação do benchmark de LLMs abertos

Ir para: CrucibleForge no GitHub

Os exemplos práticos utilizam o conjunto de testes Suite 4.0, publicado em 7 de novembro de 2026. A Suite 4.1 corrige as respostas esperadas e reavaliou todos os modelos, mantendo as mesmas regras de pontuação e dos conjuntos bônus; o que mudou na Suite 4.1 traz os detalhes e os novos valores.

O que é o MakoBench

De um modelo até a classificação final

1. Um modeloLocal em nosso sistema ou disponível via API
2. Os casos padrãoAs mesmas perguntas para todos os modelos
3. Suas respostasArmazenadas, para que possam ser avaliadas novamente
4. AvaliaçãoCódigo: executado contra testes ocultos e verificação da saída exata. Chat: avaliado por um modelo de julgamento em nosso sistema, com base em regras textuais.
5. PontuaçõesCódigo + Chat = Pontuação total, com uma margem de erro ±
6. A classificação finalClassificação, categoria e nível de desempenho

O MakoBench é um painel público de modelos de linguagem, tanto locais quanto hospedados, todos avaliados da mesma forma. Ele mede duas capacidades: a habilidade de escrever código funcional e a capacidade de manter conversas ou simular interações. O documento O que o MakoBench testa e o que não testa descreve todo o escopo das avaliações.

O motor por trás disso é o CrucibleForge, um software gratuito e de código aberto (licença MIT-0). Você pode utilizá-lo com seus próprios modelos seguindo o guia de instalação do CrucibleForge.

Como uma pontuação é calculada

Um caso por vez

Como um único caso gera créditos

1. O casoUm chat de agendamento com 11 etapas; armadilhas embutidas no processo
2. A respostaO que o modelo diz e quais ações executa
3. As verificações, passo a passoFerramenta correta? Argumentos corretos? Deve-se responder ao usuário em vez de usar uma ferramenta?
4. 7 etapas aprovadas, 4 falharamCréditos: 7 / 11 = 0,64

Um “caso” representa uma tarefa específica: uma função a ser escrita, um programa cujo resultado deve ser previsto, um chat com ferramentas ou uma sessão longa de role-play. Cada caso é avaliado em pequenas partes — como grupos de testes ocultos ou etapas do diálogo —, de modo que uma resposta quase correta ainda garanta a maior parte dos créditos. Cada caso padrão é executado apenas uma vez.

Detalhes: lista completa dos casos de teste e código responsável pela avaliação (graders.py).

Como o juiz avalia as respostas do chat

Como o juiz avalia uma resposta do chat

1. A respostaUma mensagem numa sessão de chat
2. Uma pergunta“O personagem cumpriu a promessa?”
3. O modelo juizResponde SIM ou NÃO
4. SIM + uma citação exataO código verifica a citação: deve ter pelo menos 12 caracteres e estar escrita exatamente na resposta.
5. O resultadoSe a citação for encontrada, o SIM é contabilizado; caso contrário, conta como NÃO.
6. Regras de texto, sem intervenção do juizContagem de palavras, frases proibidas, fatos pré-definidos: tudo verificado pelo código. Se as regras não forem cumpridas, a resposta é considerada inválida.

O código nunca precisa de opinião humana. O chat, porém, sim; por isso um modelo juiz, que é outro modelo de linguagem, responde a perguntas do tipo SIM ou NÃO sobre cada resposta. Neste caso, trata-se do Gemma 4 31B (versão “herege” não censurada, Q8) rodando em nosso próprio hardware com GPU; Q8 significa uma cópia dos pesos do modelo em 8 bits. Um “SIM” só é válido se houver uma citação exata na resposta, pois os modelos juízes tendem a responder “SIM” com muita facilidade. Antes de cada lote de avaliações, o juiz precisa identificar corretamente uma resposta considerada boa e também uma considerada ruim; caso contrário, o lote é interrompido.

Quando uma única pergunta pode determinar o resultado de um caso, ela é feita três vezes. Só é considerado aprovado se houver maioria de respostas “SIM”; em caso de empate, o resultado é NÃO.

Detalhes: o código do juiz (judge.py) e como as sessões de chat funcionam.

Código mais Chat resultam no total

Código: 10 pontos

• Funções56 programas
• Previsão + detecção de erros2,53 tarefas
• Uso de ferramentas2,53 conversas

Chat: 10 pontos

• Interpretação de papéis complexos32 sessões
• Conversação32 sessões
• Criação de personagens22 sessões
• Escrita criativa22 sessões

Cada parte obtém a porcentagem de pontos que lhe cabe: “Funções”, com 76% do total, corresponde a 3,8 dos 5 pontos possíveis. As partes somam-se para formar as pontuações de Código e Chat. O teste específico para adultos possui sua própria aba e nunca é incluído no cálculo geral.

Detalhes: O perfil do teste (bench.yaml) lista todas as partes, seus pontos e os casos de teste correspondentes.

A margem ±

De onde vem a margem

1. Redesenhar os casos1.000 vezes, de forma aleatória; um caso pode aparecer duas vezes ou nunca
2. Avaliar cada redesenho integralmenteIsso gera 1.000 valores totais
3. Pegar os 90% centrais dos 1.000 valores totaisEssa faixa é o que consideramos “margem”
4. ± = metade dessa larguraClaude Sonnet 4.5: 12,8 ± 1,1

Um conjunto ligeiramente diferente de casos resultaria em um valor total ligeiramente distinto. A margem indica esse grau de variação. Dois modelos cujos valores estejam dentro das respectivas margens são, estatisticamente, considerados iguais. A margem não leva em conta as variações aleatórias entre execuções; portanto, uma diferença de um ou dois pontos também deve ser considerada como empate.

Detalhe: o código responsável pela margem (headline.py).

Lendo o quadro de avaliação

Faixas de classificação

• Classe CAbaixo de 10A faixa mais baixa
• Classe B10 ou maisDe 10 a 13
• Classe A13 ou maisDe 13 a 16
• Classe S16 ou maisDe 16 a 20; acima disso, apenas com conjuntos de bônus

Total, numa escala de 0 a 20

• Claude Sonnet 4.512,8 ± 1,1classe B
• DeepSeek V4 Flash19,2 ± 0,8classe S

O custo de execução, a plataforma utilizada e as demais colunas são explicados na guia de documentação do MakoBench e no quadro de avaliação descrito no README.

Exemplo: um modelo no conjunto padrão

Código: 6,1 de 10

• Funções3,8de 5
• Previsão + detecção de erros0,5de 2,5
• Uso de ferramentas1,8de 2,5

Chat: 6,7 de 10

• Atuação em papéis complexos2,0de 3
• Conversação2,0de 3
• Personagem1,3de 2
• Escrita criativa1,4de 2

O Claude Sonnet 4.5 utilizou apenas o conjunto padrão de avaliação. Veja como as pontuações obtidas se traduzem em resultados por parte.

Total: 6,1 + 6,7 = 12,8 ± 1,1, classificação B. A melhor parte, “Funções”, atingiu 76%, valor abaixo dos 90% necessários para desbloquear os bônus. Por isso, todos os bônus permaneceram bloqueados e a pontuação considerou apenas o conjunto padrão. A maioria dos modelos na tabela está na mesma situação.

Conjuntos de bônus

Como um conjunto é desbloqueado

Como os conjuntos de bônus são desbloqueados, para uma parte específica

1. Perguntas padrãoPor exemplo, na parte “Funções”
2. 90% ou mais?Não: o conjunto permanece bloqueado, 0 pontos. A parte mantém seus pontos padrão. Sim: os conjuntos de Nível 1 são desbloqueados; cada um vale 1 ponto.
3. PendenteConjunto já desbloqueado, mas ainda não executado: 0 pontos por enquanto.
4. Cada conjunto adiciona sua parte de pontosQuando executado, um conjunto adiciona de 0 a 1 ponto. Acertar 2 de 3 perguntas resulta em aproximadamente 0,67 ponto.
5. 90% ou mais em todos os conjuntos de Nível 1?Não: os pontos permanecem como estão. Sim: os conjuntos de Nível 2 são desbloqueados, e assim por diante, nível por nível.
6. Pontuação da partePontos padrão + a soma dos pontos de todos os conjuntos executados

Um conjunto de bônus é um grupo de perguntas mais difíceis, geralmente três, referentes a uma determinada parte. O CrucibleForge chama esses grupos de “pacotes de escada”. As regras são:

• Desbloqueio. Os conjuntos de um determinado nível só são liberados após se alcançar 90% ou mais nas perguntas padrão dessa parte e em todos os conjuntos dos níveis inferiores.
• Bloqueado, desbloqueado, pendente. Bloqueado: ainda não foi obtido. Desbloqueado: já foi obtido e será executado. Pendente: já foi obtido, mas ainda não executado ou avaliado; por isso conta como 0 pontos por enquanto.
• Máximo de 1 ponto por conjunto. As perguntas de um conjunto dividem esse ponto entre si, com crédito parcial: acertar 2 de 3 perguntas resulta em aproximadamente 0,67 ponto. Quando uma pergunta é executada duas vezes, as duas tentativas são médias.
• Níveis. Todos os conjuntos de um determinado nível são liberados juntos; cada um adiciona sua parte de pontos à parte em questão.

A partir da versão 4.1, todos os conjuntos são considerados de Nível 1. O Code possui três conjuntos, um para cada parte; o Chat, cinco (o Deep role-play tem dois), portanto o Code pode atingir 13 pontos e o Chat, 15. Uma parte cujas perguntas padrão ainda não foram respondidas corretamente não desbloqueia seus conjuntos de bônus.

Detalhes: as regras dos conjuntos de bônus, o código de desbloqueio (ladder.py) e os conjuntos de bônus públicos.

Exemplo: um modelo que desbloqueia um conjunto

O DeepSeek V4 Flash desbloqueia um conjunto de bônus

1. Funções: 6 programas padrãoTodos foram aprovados: 100%, totalizando 5,0 pontos
2. 100% é mais que 90%: desbloqueioConjunto de bônus de Funções, Nível 1
3. 3 perguntas difíceis, cada uma executada duas vezesPergunta 1: 0 e 0 → 0,00; Pergunta 2: 0 e 0 → 0,00; Pergunta 3: 4 de 6 grupos acertados, depois 0 → 0,33
4. Parte do conjunto: 0,33 / 3 = 0,11Funções: 5,0 + 0,1 = 5,1 pontos
5. Deep role-play: 74%Abaixo de 90%, portanto seus conjuntos de bônus permanecem bloqueados: 2,2 de 3 pontos
6. Code totaliza 11,2 = 5,1 + 2,7 + 3,3A pontuação ultrapassou 10 graças aos conjuntos de bônus

O DeepSeek V4 Flash aprovou todos os seis programas padrão de Funções, o que desbloqueou o conjunto de bônus: três programas criados do zero, cada um executado duas vezes. O modelo resolveu parte de uma pergunta: acertou 4 de 6 grupos de teste em uma tentativa e nada na outra; por isso obteve 0,33 ponto nessa questão. O conjunto somou (0 + 0 + 0,33) ÷ 3 = 0,11 ponto. As outras duas partes do Code e o Creative writing também desbloquearam seus respectivos conjuntos de bônus. A pontuação final do Code foi 11,2, ultrapassando os 10 pontos; a pontuação total ficou em 19,2 ± 0,8.

Já na parte de Deep role-play, o modelo obteve 74%, portanto seus conjuntos de bônus permaneceram bloqueados. Cada parte é desbloqueada independentemente das demais.

Como o teste foi criado

Mantendo os casos atualizados

O que acontece quando um caso é alterado

• Se a pergunta ou seus testes forem alteradosNovas respostasTodos os modelos de IA geram novas respostas
• Se uma pergunta do avaliador for alteradaReavaliadoO avaliador relê as respostas armazenadas
• Se uma verificação de texto ou a resposta forem alteradasReavaliado novamenteA resposta é reavaliada; nenhum modelo de IA é acionado
• Se nada mudarMantidoAs respostas armazenadas permanecem válidas

Cada resposta armazenada possui um “carimbo” do caso ao qual responde. Quando um caso é alterado, apenas o que for afetado pela mudança é reprocessado. Respostas antigas e novas nunca se misturam. Detalhes: os “carimbos” dos casos (version.py).

A revisão das chaves de respostas da versão 4.1

Revisão das chaves de respostas da versão 4.1

1. Todas as chaves de respostas públicas63 casos
2. Dois revisoresO Revisor A analisa cada caso; o Revisor B também analisa cada caso.
3. Verificação de cada afirmaçãoCódigo: executam-se os testes de referência. Chat e ferramentas: comparam-se com as respostas armazenadas de cada modelo.
4. Classificação das afirmações~190 afirmações confirmadas; corrigidas quando alteravam a pontuação. ~95 rejeitadas, cada uma com um motivo explicado por escrito.
5. Segunda verificação de cada correção“Recusar nunca rende créditos; o difícil continua sendo difícil.”
6. Reexecução, reavaliação ou recálculo da pontuaçãoPara cada caso alterado.

Uma chave de respostas pode estar errada de duas maneiras: pode aceitar uma resposta incorreta ou rejeitar uma resposta correta, ao exigir mais do que a tarefa pede. Na versão 4.1, dois revisores analisaram cada chave de respostas pública individualmente; cada afirmação foi verificada em relação às respostas armazenadas antes de qualquer alteração ser feita. O crédito por recusar também foi concedido: nenhum caso concede pontos por rejeição. O artigo Versão 4.1: o que mudou lista todas as correções feitas.

Do primeiro conjunto de testes aos novos pacotes

O conjunto de testes até agora

1. 3.0Pontuação obtida (em 100)
2. 3.9Conjuntos de bônus adicionados
3. 4.0Código + Chat; 10 itens cada
4. 4.1Chaves de resposta revisadas

Um novo pacote de bônus

1. EscreverModelos de várias famílias elaboram os casos de teste
2. AtaqueOutro modelo tenta “quebrar” cada chave de resposta
3. Verificação pelo juizUm bom exemplo de resposta é aceito; exemplos ligeiramente ruins ou muito simplificados são rejeitados
4. PilotagemAlguns modelos mais robustos realizam o teste
5. AperfeiçoamentoCorreções são feitas com base nos resultados da fase de pilotagem
6. Preparação finalO pacote fica em espera até ser revisado

Os conjuntos de bônus foram introduzidos na versão 3.9, para impedir que os melhores modelos obtivessem pontuação perfeita em todos os testes. Os conjuntos antigos permanecem inalterados no histórico do conjunto de testes; todas as atualizações dos modelos estão registradas no registro de alterações do CrucibleForge.

Quando os modelos começam a atingir a pontuação máxima em determinados testes, é necessário criar um conjunto de bônus mais difícil (um novo pacote). Todo novo pacote segue o processo descrito acima. A verificação pelo juiz é o passo mais importante: se o juiz não conseguir distinguir uma resposta boa de uma resposta ligeiramente ruim, o pacote não poderá ser avaliado de forma justa.

Por que criei isso

Cansei de não conseguir distinguir os modelos uns dos outros. Queria um benchmark rápido que qualquer pessoa pudesse executar, em qualquer modelo, com números que pudessem ser verificados por conta própria. Acredito que isso agregaria valor.

Se você acha isso útil, considere fazer uma doação para ajudar a manter o projeto atualizado. Você também pode votar no próximo modelo que testaremos.

Relacionado: Como o CrucibleForge funciona.