Benchmarks de LLM: cómo leer una tabla en cinco minutos

Los benchmarks de LLM sirven para decidir qué conviene probar a continuación. SWE-bench Verified mide el rendimiento al resolver 500 incidencias de software seleccionadas; una puntuación alta no indica si un agente será capaz de cumplir tu política de reembolsos. Antes de fijarte en la cifra ganadora, revisa la tarea, las condiciones de la prueba y el criterio de puntuación.

Verificado con las páginas de los autores de los benchmarks y la ficha del modelo de Google el 15 de octubre de 2026. Las descripciones que siguen explican cada prueba; las puntuaciones del ejemplo son los resultados publicados por Google. La interpretación y la lista de comprobaciones para evaluar los modelos son nuestras.

Para elegir un asistente de programación, empieza por las tareas en repositorios o terminales. Para un agente de atención al cliente, prioriza el uso de herramientas durante una conversación y el cumplimiento de políticas. Para un asistente de documentos, busca pruebas de razonamiento con contexto largo. Una puntuación de conocimientos generales puede orientar esas decisiones, pero no resolverlas.

¿Qué miden los benchmarks de LLM?

Un benchmark mide el rendimiento en un conjunto concreto de tareas y bajo unas reglas determinadas. Se parece más a una prueba deportiva que a un certificado de inteligencia: el tiempo en una carrera de velocidad aporta información útil, pero no decide quién debe participar en un rescate de montaña.

El conjunto de datos contiene las preguntas o tareas. El protocolo de evaluación establece qué recibe el modelo, con qué ayuda cuenta y cómo se puntúa el resultado. El harness, también llamado scaffold, es el software que rodea al modelo: sus prompts, herramientas y bucle de ejecución.

Esta distinción importa cuando un anuncio afirma que un modelo sabe programar. Escribir una función a partir de un prompt breve no es lo mismo que recorrer un repositorio, editar archivos, ejecutar pruebas y recuperarse de un error. En el segundo caso, la puntuación corresponde al sistema completo en funcionamiento, incluido su harness.

La clasificación de SWE-bench hace visible esa diferencia al distinguir las condiciones de evaluación, entre ellas un entorno compartido de mini-SWE-agent. Tu herramienta de programación puede ofrecer otras herramientas, instrucciones o límites. Antes de trasladar la puntuación a tu flujo de trabajo, identifica qué software acompañaba al modelo durante la prueba.

Qué benchmarks aparecen en los anuncios de modelos

Antes de comparar puntuaciones, comprueba si el benchmark se parece al trabajo que necesitas resolver. Estas son las familias que conviene reconocer en los anuncios de modelos de propósito general, programación y voz de 2026, junto con las pruebas de contexto que ayudan a interpretar sus afirmaciones. El nombre de cada benchmark enlaza a la página o al repositorio de sus autores.

La versión debe acompañar siempre al nombre. HLE-Diamond contiene 1,000 preguntas depuradas, mientras que la versión definitiva del HLE original contiene 2,500. Terminal-Bench 4.0 cambió los recursos y las tareas. El repositorio actual de tau documenta tanto modalidades nuevas como correcciones en la puntuación. Al comparar una cifra reciente con una anterior, la diferencia puede estar en el examen, no en una mejora del modelo.

¿Qué puntuaciones importan para tu trabajo?

Elige la familia que más se acerque al fallo que necesitas evitar. Quien decide qué función de IA incorporar a su empresa, quien aprueba un agente desde la dirección técnica y quien gestiona solicitudes de soporte no deberían dar el mismo peso a todas las filas de una tabla de lanzamiento.

Benchmarks de programación con agentes

Si mantienes un producto existente, empieza por las tareas de reparación de repositorios y trabajo en terminal. SWE-bench aporta evidencia útil sobre la resolución de incidencias; Terminal-Bench, sobre la ejecución de trabajo en una shell. LiveCodeBench y HumanEval ayudan a responder preguntas de programación más acotadas. Ninguno mide por sí solo si un cambio será fácil de mantener en tu base de código.

Imagina a alguien que desarrolla un producto por su cuenta y pide a un agente modificar la eliminación de cuentas. Escribir una función auxiliar correcta es solo una parte del trabajo. El agente debe encontrar todos los puntos de llamada afectados, conservar los permisos, actualizar las pruebas y evitar inconsistencias en los registros de clientes. La evaluación debe incluir ese cambio completo, con el mismo acceso al repositorio y las mismas herramientas que piensas proporcionar.

Criterio de decisión: si el trabajo abarca varios archivos y pasos de ejecución, exige evidencia de tareas realizadas por agentes antes de preseleccionar candidatos. Usa las puntuaciones de funciones como información complementaria. Mantén la revisión de código como requisito de aceptación hasta que tus propios casos justifiquen reducirla.

Benchmarks de razonamiento de LLM

GPQA, HLE, MMLU-Pro, AIME y ARC-AGI examinan distintos tipos de razonamiento. Sirven para orientar qué investigar, sobre todo cuando la tarea exige resolver problemas científicos o matemáticos difíciles. Aportan poca evidencia directa sobre el cumplimiento de tus reglas operativas.

Las 198 preguntas de GPQA Diamond forman un conjunto científico seleccionado deliberadamente. Una persona a cargo de la dirección técnica que evalúa un asistente de investigación interno puede usar esa señal para preseleccionar modelos y después probarlos con preguntas cuyas respuestas dependan del material de la empresa. Quien dirige un equipo de soporte debería prestar más atención al uso de herramientas sujeto a políticas y a la derivación de casos.

En Humanity's Last Exam, conviene separar la ambición del nombre de lo que realmente se mide. Sus autores distinguen expresamente entre el rendimiento en preguntas académicas de respuesta cerrada y la investigación autónoma. Responder una pregunta difícil con una solución conocida no demuestra que un sistema sepa elegir un problema que merezca la pena, reunir evidencia fiable y reconocer sus errores.

El contexto largo y la voz necesitan pruebas propias

La ventana de contexto expresa capacidad: cuánta información de entrada admite un sistema. La evaluación de contexto largo pregunta qué puede hacer con ella. Las pruebas de recuperación localizan información; las de razonamiento exigen relacionarla. Los autores de RULER explican por qué encontrar un dato oculto no basta para demostrar un buen rendimiento general con contextos largos.

Para quien revisa contratos, la prueba útil consiste en comprobar si el asistente relaciona una excepción de un anexo con una cláusula del acuerdo principal y cita ambas correctamente. Incluye documentos en los que la respuesta no aparezca, haya quedado obsoleta o entre en contradicción con otra información. Un sistema que combina con seguridad versiones incompatibles ha fallado, aunque haya recuperado cada pasaje.

En voz, separa la escucha, el razonamiento, el habla y la gestión de la conversación. FLEURS puede orientar la evaluación de la transcripción; Big Bench Audio se centra en el razonamiento a partir de preguntas orales; VoiceBench abarca tareas con instrucciones habladas. La familia tau actual también evalúa interacciones de voz. Son mediciones diferentes.

Una prueba piloto de soporte telefónico debe incluir ruido de fondo, nombres, interrupciones, correcciones y la transferencia a una persona. Escucha la interacción y verifica la acción final. La transcripción puede parecer correcta aunque la conversación resulte frustrante o se actualice la cuenta equivocada.

Benchmarks de rendimiento de LLM

Al decidir si adoptar un sistema, define el rendimiento como trabajo que cumple los criterios de aceptación dentro de los límites de tu flujo. La calidad de la respuesta, la fiabilidad al completar tareas y el tiempo de respuesta son requisitos distintos. Una ejecución con razonamiento intensivo puede ser pertinente para una investigación que se realiza durante la noche y encajar mal en una interacción de soporte en vivo.

Quien compra debería pedir resultados para los tipos de tareas que necesita y con la configuración real del producto. Quien lo opera debería revisar los fallos y la recuperación. Quien lo desarrolla debería poder reproducir los ajustes. Si el proveedor no puede identificar la configuración evaluada, la puntuación no aporta evidencia suficiente para comprometerse a usarlo en producción.

Cómo leer una tabla de lanzamiento en cinco minutos

Esta revisión de cinco minutos sirve para decidir si un lanzamiento merece una evaluación más a fondo. Es un método de lectura; ese tiempo no basta para determinar si un modelo es seguro o útil en tu aplicación.

1. 1

   Minuto 1: Define tu tarea

   Escribe el resultado que necesitas: corregir incidencias en repositorios, resolver solicitudes de soporte, responder a partir de documentos o atender llamadas. Marca las filas que se parezcan a esa tarea. Deja fuera de la decisión de adopción las victorias en tareas ajenas a tu caso.

2. 2

   Minuto 2: Identifica la prueba exacta

   Anota la edición del benchmark, el subconjunto, el idioma y el intervalo temporal de las tareas. Busca calificativos como Diamond, Verified, offline, solo texto o con herramientas. Si la etiqueta está incompleta, consulta la página del propio benchmark.

3. 3

   Minuto 3: Revisa las condiciones

   Localiza el harness, las herramientas, el nivel de razonamiento, el tiempo permitido y la política de intentos. Comprueba si tu producto utilizará esas mismas condiciones. El acceso a búsquedas, la ejecución de código o un mayor número de reintentos pueden cambiar lo que representa una puntuación.

4. 4

   Minuto 4: Descifra la métrica

   La exactitud es la proporción de respuestas calificadas como correctas. F1 equilibra cuántos elementos devueltos son correctos con cuántos de los elementos requeridos se encontraron. La puntuación parcial puede premiar el avance sin que se complete la tarea. En una tasa de error, un valor menor es mejor. Lee la definición antes de interpretar un porcentaje como trabajos terminados.

5. 5

   Minuto 5: Averigua quién ejecutó la prueba

   Identifica quién realizó la evaluación: el fabricante, el organizador del benchmark u otro evaluador. Lee la nota de cada fila en lugar de dar por hecho que toda la tabla sigue un mismo procedimiento. Guarda la fuente y la configuración, y después elige un candidato para tus propias pruebas.

El resultado debe ser una breve nota de decisión: «Familia de tareas pertinente, versión actual, configuración comprendida, merece una prueba con nuestros casos». Si no puedes completar esa nota, registra la información que falta antes de cambiar un sistema que funciona.

Ejemplo práctico: la tabla de Gemini 4 Argon de Google

Gemini 4 Argon, el modelo de IA de propósito general de Google, ofrece un buen ejemplo porque su tabla mezcla familias de tareas y criterios de puntuación. Las filas siguientes reproducen los resultados de Google de su ficha del modelo de octubre, comprobados el 15 de octubre de 2026. Son resultados atribuidos a esa fuente, no mediciones realizadas para este artículo.

Lee la etiqueta de la fila y las notas que acompañan a cada valor. Estos porcentajes no comparten denominador ni significado.

BFS significa búsqueda en anchura: recorre las conexiones del grafo por niveles de profundidad. Los tokens son las unidades con las que se mide el contexto de un modelo; no equivalen a palabras.

Lee las notas antes de sacar conclusiones

La metodología de evaluación de Google indica que Argon suele utilizar el nivel máximo de razonamiento y pass@1, con excepciones. El resultado de DeepSWE utiliza un harness mini-swe. Google calcula su propio resultado de Terminal-Bench, mientras que los resultados de comparación proceden de la clasificación oficial. Google también calcula los resultados de GraphWalks para todos los modelos comparados. En OSWorld se toma el máximo de tres ejecuciones y se informa de la puntuación parcial del subconjunto offline.

Se combinan, por tanto, distintas condiciones de evaluación; no hay evidencia de que todas las celdas procedan de un único experimento controlado. Para quien desarrolla, la siguiente pregunta es si el harness de programación se parece al del agente previsto. Para quien compra, si la configuración propuesta de la aplicación coincide con la evidencia. Para quien opera el sistema, si la métrica premia el resultado completo.

Nuestro cálculo: 99.7 menos 84.2 da una diferencia de 15.5 puntos porcentuales entre los resultados F1 publicados de GraphWalks. Esas filas utilizan subconjuntos de distinta longitud, de modo que la resta no aísla el efecto causal de la longitud sobre preguntas idénticas. Sí muestra por qué citar solo la fila de contexto más corto omitiría evidencia pertinente para un flujo de trabajo con documentos extensos.

La interpretación del uso del equipo informático es igual de concreta: no conviertas la puntuación parcial en «el agente completa esa proporción de nuestras tareas de escritorio». Los avances parciales pueden ser valiosos en un asistente que devuelve el trabajo a una persona. Un proceso sin supervisión necesita evidencia de resultados completos y correctos.

Para conocer el contexto de adopción de este modelo, consulta la guía de Gemini 4 Argon y la comparativa de Gemini 4 Argon frente a Opus 5.5.

Por qué una puntuación alta puede llevar a engaño

Una puntuación alta puede ser válida y, aun así, responder a una pregunta de negocio equivocada. Lo útil es identificar la limitación y decidir qué evidencia permitiría resolverla.

Contaminación y optimización para la prueba

La contaminación se produce cuando las preguntas o respuestas de la evaluación entran en el material de entrenamiento. El modelo puede beneficiarse entonces de haberlas visto antes, en vez de resolver un problema desconocido. Las pruebas públicas también pueden convertirse en objetivos de optimización: ajustar una y otra vez los prompts o el software del agente contra las mismas tareas reduce su valor como comprobación nueva.

LiveCodeBench utiliza problemas con fecha de publicación para que los evaluadores puedan seleccionar tareas posteriores a la fecha de corte del entrenamiento. Es una decisión de diseño útil, no una razón para suponer que cualquier resultado con «Live» en el nombre está libre de contaminación. Revisa el intervalo real de los problemas. Un salto sospechosamente grande es motivo para examinar el protocolo, no una prueba de mala conducta.

En tus propias evaluaciones, reserva un conjunto de casos que no utilices para ajustar los prompts. Cuando un fallo pase a ser un ejemplo de desarrollo, incorpora casos nuevos al conjunto reservado. De lo contrario, el sistema puede volverse excelente con tus ejemplos habituales y seguir fallando ante otros.

El software que rodea al modelo puede cambiar la comparación

El entorno de ejecución importa. Un modelo con búsquedas, herramientas de archivos, reintentos e instrucciones cuidadosamente redactadas forma un sistema distinto del mismo modelo respondiendo a un único prompt. Mejorar ese entorno puede ser un avance de ingeniería valioso; el error consiste en atribuir todo el resultado al modelo subyacente.

Usa un harness compartido cuando quieras aislar el efecto de cambiar de modelo. Evalúa el producto completo cuando estés eligiendo entre productos completos. Es legítimo que esas preguntas conduzcan a conclusiones distintas.

Un resultado del proveedor puede ser útil sin estar reproducido de forma independiente

El resultado de un fabricante es útil cuando el método está claro, y el del organizador de un benchmark lo es cuando su configuración encaja con la comparación. Ninguna de esas etiquetas sustituye la lectura del protocolo. Distingue entre un resultado enviado a una clasificación y otro que se ha vuelto a ejecutar de forma independiente bajo condiciones comunes.

Busca el prompt, el identificador del modelo, el harness, el método de puntuación, las exclusiones y la incertidumbre. Una diferencia pequeña, sin suficiente información sobre su variabilidad, no debería decidir una migración. Un resultado omitido es evidencia que falta; no equivale automáticamente a un cero.

Revisa también cómo se agregan los resultados. Un promedio general refleja la elección de tareas y ponderaciones del evaluador. Tu cola de soporte puede contener muchos casos excepcionales que apenas influyen en ese promedio. No promedies porcentajes de benchmarks sin relación entre sí para crear tu propia puntuación de inteligencia.

Un buen evaluador también puede medir el resultado equivocado

Las pruebas unitarias, las respuestas de referencia, los modelos evaluadores y las preferencias humanas premian cosas distintas. La cobertura de pruebas puede dejar pasar un defecto; una respuesta de referencia puede contener un error; un modelo evaluador puede preferir una explicación elocuente a una acción correcta. Ganar una evaluación de preferencias mide lo que prefirieron los participantes bajo ese procedimiento.

El repositorio actual de tau documenta correcciones en las tareas y en la puntuación. Esas correcciones mejoran la evaluación y, al mismo tiempo, hacen imprescindible registrar la versión. Una prueba es un sistema de medición que se mantiene y revisa, no una fuente de verdad incuestionable.

Cuándo conviene hacer tus propias evaluaciones de LLM

Haz tus propias evaluaciones cuando la decisión dependa de tus datos, políticas, herramientas, usuarios o tolerancia a los fallos. Las puntuaciones públicas bastan para identificar candidatos plausibles. No bastan para aprobar un agente que modifica registros de clientes o responde a partir de documentos privados.

Actúa ahora si una mejora en un benchmark pertinente aborda un fallo conocido de tu sistema actual: realiza una comparación controlada con ese tipo de fallo. Aplaza la migración si la mejora corresponde a tareas ajenas a tu caso o si tu producto no dispone de la configuración publicada. Mantén el sistema actual si ya cumple tus criterios de aceptación y el nuevo candidato no ha demostrado una mejora pertinente.

Para un equipo de soporte de una empresa mediana, una primera prueba piloto práctica podría incluir 50 casos: 20 solicitudes rutinarias, 10 excepciones a las políticas, 10 casos con información ausente o contradictoria y 10 casos de permisos o derivación. Son cantidades propuestas para diseñar la prueba, no una afirmación de que la muestra sea estadísticamente suficiente para un despliegue. Determina el tamaño final según las tasas de fallo y las diferencias que necesites detectar.

Define el resultado antes de ejecutar las pruebas con los candidatos. Un caso de reembolso puede exigir determinar correctamente si procede, seleccionar la cuenta y el importe adecuados, evitar acciones no autorizadas y ofrecer una explicación clara. Un caso de derivación debe aprobarse cuando el agente lo transfiere correctamente, aunque no resuelva la solicitud por sí mismo.

Ejecuta cada candidato con los prompts, la recuperación de información, las herramientas y los permisos previstos. Revisa el registro final y la traza de acciones, no solo el último mensaje. Repite los casos inestables, mide la latencia por separado y revisa los desacuerdos antes de declarar una mejora. Conserva un conjunto de casos reservado para la decisión final.

Promptfoo es una herramienta de evaluación que permite comparar prompts, modelos y aplicaciones mediante casos de prueba y aserciones. Su documentación explica el modelo de ejecución; nuestro análisis de Promptfoo detalla dónde encaja y de qué debes seguir haciéndote cargo.

Usa comprobaciones deterministas para los hechos que puedas verificar directamente, como la cuenta seleccionada o una acción prohibida. Para las cualidades que requieren criterio, como determinar si una explicación está completa y respaldada, utiliza una rúbrica y calíbrala con evaluaciones humanas. La guía de LLM como evaluador aborda esa capa de puntuación y sus posibles fallos.

El primer paso del lunes: elige un flujo de trabajo, escribe sus criterios de aceptación, reúne casos recientes y compara el sistema actual con un candidato en las mismas condiciones. Decide el despliegue a partir de los resultados y fallos que importan a tus usuarios.

Preguntas frecuentes sobre las tablas de benchmarks

¿Cuáles son los benchmarks de LLM más habituales?

Primero reconoce las familias: SWE-bench y Terminal-Bench para agentes de programación, GPQA y Humanity's Last Exam para preguntas académicas, la familia tau para el uso de herramientas durante conversaciones, y pruebas específicas para contexto largo y voz. Conserva la edición y la configuración junto a cada puntuación.

¿Cuál es el mejor benchmark de LLM para programación?

Usa el benchmark más cercano a la tarea. SWE-bench se centra en resolver incidencias de repositorios; Terminal-Bench, en el trabajo con terminales; HumanEval, en generar funciones; LiveCodeBench incluye problemas de competición con fecha de publicación. Los cambios en tu propio repositorio determinarán si esa evidencia es aplicable.

¿Qué es el conjunto de datos de un benchmark de LLM?

El conjunto de datos aporta las preguntas o tareas. Para que el resultado de un benchmark sea comparable, también hace falta conocer el protocolo: prompts, herramientas, límites, intentos y puntuación. Compartir el nombre del conjunto de datos no demuestra por sí solo que dos resultados sean comparables.

Para recibir orientación práctica sobre evaluación y adopción de IA, suscríbete al boletín.