Cómo funciona MakoBench: Explicación del benchmark de LLM de código abierto

Ir a: CrucibleForge en GitHub

Los ejemplos prácticos utilizan el conjunto de pruebas Suite 4.0, publicado el 7 de noviembre de 2026. La Suite 4.1 corrige las claves de respuesta y vuelve a puntuar a todos los modelos, aplicando las mismas reglas de puntuación y de conjuntos de bonificación; en qué cambió en la Suite 4.1 se detallan los cambios y las nuevas puntuaciones.

¿Qué es MakoBench?

De un modelo a la clasificación final

1. Un modeloYa sea local en nuestro equipo o mediante una API alojada
2. Los casos de prueba estándarLas mismas preguntas para todos los modelos
3. Sus respuestasSe almacenan para poder ser evaluadas nuevamente
4. EvaluaciónPara código: se ejecuta contra pruebas ocultas y se compara con la salida esperada. Para chat: se utiliza un modelo evaluador en nuestro equipo, junto con reglas textuales.
5. PuntuacionesCódigo + Chat = Puntuación total, con un margen de error ±
6. La clasificación finalRanking, categoría y nivel de desempeño

MakoBench es un tablero público para modelos de lenguaje, tanto locales como alojados, todos evaluados de la misma manera. Mide dos capacidades: la habilidad para escribir código funcional y la capacidad de mantener conversaciones tipo “role-play” o de acompañamiento. En el enlace Qué prueba MakoBench y qué no se detalla todo el alcance de las evaluaciones.

El motor que utiliza es CrucibleForge, un software gratuito y de código abierto bajo licencia MIT-0. Puede ejecutarlo con sus propios modelos siguiendo la guía de instalación de CrucibleForge.

Cómo se calcula la puntuación

Un caso a la vez

Cómo se otorga crédito por un caso

1. El casoUn chat de reservas con 11 pasos; incluye trampas integradas
2. La respuestaLo que el modelo dice y qué herramientas invoca
3. Las verificaciones, paso a paso¿Herramienta correcta? ¿Argumentos correctos? ¿Responder al usuario en lugar de invocar una herramienta?
4. 7 pasos aprobados, 4 fallidosCrédito: 7 / 11 = 0,64

Un caso representa una tarea: escribir una función, predecir la salida de un programa, interactuar mediante un chat con herramientas o participar en una sesión larga de role-play. Cada caso se califica por partes; por ejemplo, por grupos de pruebas ocultas o por los pasos del chat, de modo que una respuesta casi correcta obtiene la mayor parte del crédito. Cada caso estándar se ejecuta una sola vez.

Detalles: la lista de casos de evaluación y el código de calificación (graders.py).

Cómo el juez califica las respuestas del chat

Cómo el juez evalúa una respuesta del chat

1. La respuestaUn turno dentro de una sesión de chat
2. Una pregunta“¿Cumplió el personaje su promesa?”
3. El modelo juezResponde SÍ o NO
4. SÍ + una cita exactaEl código verifica la cita: debe tener al menos 12 caracteres y coincidir palabra por palabra con la respuesta.
5. El resultadoSi se encuentra la cita, el SÍ cuenta; si falta o es incorrecta, se considera NO.
6. Reglas de texto, sin intervención del juezRecuento de palabras, frases prohibidas, datos previamente establecidos: todo esto lo verifica el código. Si una tarea no cumple con estas reglas, se considera fallida.

El código nunca necesita opinar; el chat, en cambio, sí lo requiere. Por eso un modelo juez, que es otro modelo de lenguaje, responde con SÍ o NO a cada respuesta. En este caso se trata de Gemma 4 31B (versión “hereje” sin censura, Q8) ejecutándose en nuestro propio equipo con GPU; Q8 significa que los pesos del modelo están representados en 8 bits. Un “SÍ” solo cuenta si incluye una cita idéntica a la original, ya que los modelos jueces tienden a responder SÍ con demasiada facilidad. Antes de procesar cada lote, el juez debe identificar correctamente una respuesta válida y detectar una inválida; de lo contrario, el lote se detiene.

Cuando una sola pregunta puede hacer que un caso sea rechazado, esta se plantea tres veces. Solo se considera aprobado si la mayoría de las respuestas son SÍ; en caso de empate, el resultado es NO.

Detalles: el código del juez (judge.py) y cómo funcionan las sesiones de chat.

El código y el chat suman el total

Código: 10 puntos

• Funciones56 programas
• Predicción y detección de errores2.53 tareas
• Uso de herramientas2.53 interacciones de chat

Chat: 10 puntos

• Juego de roles profundo32 sesiones
• Conversación32 sesiones
• Caracterización de personajes22 sesiones
• Escritura creativa22 sesiones

Cada parte obtiene la cantidad de puntos que le corresponde: por ejemplo, “Funciones”, con un 76% de logro, equivale a 3.8 de los 5 puntos posibles. Las partes se suman para dar el total del Código y el Chat. La prueba específica para adultos cuenta con su propia pestaña y nunca se incluye en este cálculo.

Detalles: El perfil de evaluación (bench.yaml) enumera cada parte, sus puntos asignados y los casos de prueba correspondientes.

El margen ±

De dónde proviene el margen

1. Volver a generar los casos1,000 veces, de forma aleatoria; un caso puede aparecer dos veces o ninguna
2. Puntuar cada regeneración por completoEsto genera 1,000 “Totales”
3. Tomar el 90% central de esos 1,000 TotalesEsa es la banda sombreada
4. ± = la mitad de ese anchoClaude Sonnet 4.5: 12.8 ± 1.1

Un grupo ligeramente distinto de casos produciría un Total algo diferente. El margen muestra cuánto varía ese valor. Dos modelos cuyas puntuaciones estén más cerca que sus respectivos márgenes se consideran estadísticamente empatados. El margen no tiene en cuenta las variaciones entre ejecuciones, por lo que una diferencia de uno o dos puntos también debe considerarse como un empate.

Detalle: el código del cálculo del margen (headline.py).

Leyendo el tablero de evaluación

Categorías de clasificación

• Clase CMenos de 10La categoría más baja
• Clase B10 o másDe 10 a 13
• Clase A13 o másDe 13 a 16
• Clase S16 o másDe 16 a 20; valores superiores solo con conjuntos de bonificación

Puntuación total, en una escala del 0 al 20

• Claude Sonnet 4.512.8 ± 1.1clase B
• DeepSeek V4 Flash19.2 ± 0.8clase S

El costo de ejecución, la plataforma utilizada y el resto de columnas se explican en la página de documentación de MakoBench y en las descripciones de las columnas del tablero en el README.

Ejemplo: un modelo en el conjunto estándar

Código: 6,1 de 10

• Funciones3,8de 5
• Predicción + detección de errores0,5de 2,5
• Uso de herramientas1,8de 2,5

Chat: 6,7 de 10

• Juego de roles profundo2,0de 3
• Conversación2,0de 3
• Carácter del personaje1,3de 2
• Escritura creativa1,4de 2

Claude Sonnet 4.5 utilizó únicamente el conjunto estándar. A continuación se muestra cómo sus puntuaciones se convierten en los valores correspondientes a cada parte.

Total: 6,1 + 6,7 = 12,8 ± 1,1; clase B. La mejor parte, “Funciones”, alcanzó un 76%, por debajo del 90% necesario para desbloquear los conjuntos de bonificación. Por ello, todos los conjuntos permanecieron bloqueados y la puntuación corresponde únicamente al conjunto estándar. La mayoría de los modelos en el tablero se encuentran en la misma situación.

Conjuntos de bonificación

Cómo se desbloquea un conjunto

Cómo se desbloquean los conjuntos de bonificación, paso a paso

1. Preguntas estándarPor ejemplo, en la parte de Funciones.
2. ¿Se alcanzó el 90% o más?No: El conjunto permanece bloqueado y da 0 puntos; la parte mantiene sus puntos estándar. Sí: Se desbloquean los conjuntos de nivel 1, cada uno valiendo 1 punto.
3. PendienteConjunto ya desbloqueado pero aún no ejecutado: por ahora da 0 puntos.
4. Cada conjunto aporta sus puntosAl ejecutarse, un conjunto aporta entre 0 y 1 punto.Responder correctamente a 2 de 3 preguntas equivale a aproximadamente 0,67 puntos.
5. ¿Se alcanzó el 90% o más en todos los conjuntos de nivel 1?No: Se detiene el proceso; se mantienen los puntos obtenidos. Sí: Se desbloquean los conjuntos de nivel 2, y así sucesivamente.
6. Puntuación final de la partePuntos estándar + suma de los puntos aportados por cada conjunto ejecutado.

Un conjunto de bonificación es un grupo de preguntas más difíciles, normalmente tres, correspondientes a una misma parte. CrucibleForge los denomina “ladder packs”. Las reglas son las siguientes:

• Desbloqueo. Los conjuntos de cada nivel solo se otorgan tras alcanzar el 90% o más en las preguntas estándar de esa parte y en todos los conjuntos de niveles inferiores.
• Bloqueado, desbloqueado, pendiente. Bloqueado: aún no se ha ganado. Desbloqueado: ya se ganó y se ejecuta. Pendiente: ya se ganó pero aún no se ha ejecutado ni evaluado; por ahora da 0 puntos.
• Hasta 1 punto por conjunto. Los puntos de un conjunto se reparten entre sus preguntas, permitiendo crédito parcial: responder correctamente a 2 de 3 preguntas equivale a aproximadamente 0,67 puntos. Si una pregunta se ejecuta dos veces, se promedian los resultados.
• Niveles. Todos los conjuntos de un mismo nivel se otorgan simultáneamente; cada uno aporta sus puntos a la parte correspondiente.

A partir de la versión 4.1, todos los conjuntos son de nivel 1. Code cuenta con tres conjuntos, uno por parte; Chat, con cinco (el de role-play profundo tiene dos), por lo que Code puede alcanzar hasta 13 puntos y Chat hasta 15. Una parte cuya prueba estándar aún no se haya completado no desbloqueará sus conjuntos de bonificación.

Detalles: reglas de los conjuntos de bonificación, código de desbloqueo (ladder.py) y conjuntos de bonificación públicos.

Ejemplo: un modelo que desbloquea un conjunto

DeepSeek V4 Flash desbloquea un conjunto de bonificación

1. Funciones: 6 programas estándarTodos se superaron: 100%, por lo que se obtienen 5,0 puntos.
2. El 100% supera el 90%: se desbloqueaConjunto de bonificación de Funciones, nivel 1.
3. 3 preguntas difíciles, cada una ejecutada dos vecesPregunta 1: 0 y 0 → 0,00; Pregunta 2: 0 y 0 → 0,00; Pregunta 3: se resolvieron 4 de 6 grupos en un intento y luego 0 en el otro → 0,33.
4. Puntos aportados por el conjunto: 0,33 / 3 = 0,11Funciones: 5,0 + 0,1 = 5,1 puntos.
5. Role-play profundo: 74%Por estar por debajo del 90%, sus conjuntos de bonificación permanecen bloqueados: se obtienen 2,2 de 3 puntos.
6. Puntuación total de Code: 11,2 = 5,1 + 2,7 + 3,3Solo gracias a los conjuntos de bonificación se superó el umbral de 10 puntos.

DeepSeek V4 Flash superó los seis programas estándar de la parte de Funciones, lo que desbloqueó el conjunto de bonificación correspondiente: tres programas creados desde cero, cada uno ejecutado dos veces. En uno de ellos, el modelo resolvió 4 de 6 grupos en un intento y nada en el otro; por eso obtuvo 0,33 puntos en esa pregunta. El conjunto aporta (0 + 0 + 0,33) ÷ 3 = 0,11 puntos. Las otras dos partes de Code y la de escritura creativa también desbloquearon sus respectivos conjuntos. La puntuación final de Code fue 11,2, superando el umbral de 10; la puntuación total alcanzó los 19,2 ± 0,8 puntos.

En cuanto a la parte de role-play profundo, obtuvo un 74%, por lo que sus conjuntos de bonificación permanecieron bloqueados. Cada parte se desbloquea de forma independiente.

Cómo se creó la prueba

Mantener los casos actualizados

Qué ocurre cuando un caso cambia

• Si la pregunta o sus pruebas cambianNuevas respuestasTodos los modelos generan respuestas nuevas
• Si cambia una pregunta de evaluaciónReevaluadoEl evaluador vuelve a leer las respuestas almacenadas
• Si cambia una verificación de texto o una respuestaRecalificadoSe vuelve a calificar, sin intervención de modelos
• Si no cambia nadaSe mantieneLas respuestas almacenadas siguen siendo válidas

Cada respuesta almacenada incluye un sello del caso al que responde. Cuando un caso cambia, solo se vuelven a procesar aquellos elementos afectados por el cambio. Las respuestas antiguas y las nuevas nunca se mezclan. Detalles: los sellos de caso (version.py).

Revisión de las claves de respuestas de la suite 4.1

Revisión de las claves de respuestas de la suite 4.1

1. Todas las claves de respuestas públicas63 casos
2. Dos revisoresEl Revisor A lee cada caso. El Revisor B también lee cada caso.
3. Comprobación de cada afirmaciónCódigo: se ejecutan el código de referencia y las pruebas. Chat y herramientas: se comparan con las respuestas almacenadas de cada modelo.
4. Clasificación de las afirmacionesAproximadamente 190 afirmaciones confirmadas; se corrigieron aquellas que modificaban la puntuación. Unas 95 fueron rechazadas, cada una con su motivo escrito.
5. Segunda comprobación de cada corrección“Rechazar nunca otorga crédito; lo difícil sigue siendo difícil.”
6. Reejecución, revaluación o recálculo de puntuacionesSe realiza en cada caso modificado.

Una clave de respuestas puede ser incorrecta de dos maneras: puede aceptar una respuesta errónea, o rechazar una respuesta correcta al exigir más de lo que el enunciado del problema pedía. En la suite 4.1, dos revisores de modelos analizaron por separado cada clave de respuestas pública; además, cada afirmación se comparó con las respuestas almacenadas antes de realizar cualquier cambio. El crédito por rechazar también se otorga: ningún caso concede puntos por simplemente declinar una respuesta. En el artículo Suite 4.1: ¿qué cambió? se detallan todas las correcciones realizadas.

Desde el conjunto inicial hasta los nuevos paquetes

El conjunto hasta ahora

1. 3.0Puntuación sobre 100
2. 3.9Se añadieron conjuntos de bonificación
3. 4.0Código + Chat; 10 puntos cada uno
4. 4.1Se revisaron las claves de respuesta

Un nuevo paquete de bonificación

1. WriteModelos de varias familias redactan casos de prueba
2. AttackOtro modelo intenta “romper” cada clave de respuesta
3. Judge checkSe acepta una respuesta correcta; se rechazan una mala y otra poco sólida
4. PilotUnos cuantos modelos potentes lo prueban
5. HardenSe corrigen los problemas detectados en la fase piloto
6. StageEl paquete queda en espera hasta ser revisado

Los conjuntos de bonificación se introdujeron en la versión 3.9 para evitar que todos los mejores modelos obtuvieran una puntuación perfecta. Los conjuntos antiguos permanecen sin cambios en el historial del conjunto; además, cada lanzamiento de motor aparece en el registro de cambios de CrucibleForge.

Cuando los modelos comienzan a alcanzar la puntuación máxima en una sección, es necesario crear un conjunto de bonificación más difícil (un nuevo paquete); cada uno de estos paquetes sigue el proceso descrito anteriormente. La fase de “Judge check” es la más importante: si el juez no puede distinguir una respuesta correcta de una ligeramente incorrecta, el paquete no podrá ser evaluado de manera justa.

¿Por qué creé esto?

Me cansé de no poder distinguir unos modelos de otros. Quería un benchmark rápido que cualquiera pudiera ejecutar, con cualquier modelo, y cuyos resultados pudieran verificarse por sí mismos. Pensé que eso aportaría valor.

Si considera que esto es útil, le invito a realizar una donación para ayudar a mantenerlo actualizado. También puede votar por el siguiente modelo que probaremos.

Relacionado: Cómo funciona CrucibleForge.