Casi cada semana se anuncia un nuevo modelo "estado del arte", cada uno con un gráfico que muestra cómo supera a la competencia en una docena de benchmarks. Para un equipo que construye un producto, la pregunta práctica es otra: ¿qué modelo da los mejores resultados a nuestros usuarios, con un coste y una latencia asumibles y sin atarnos a un proveedor? Los benchmarks públicos son un punto de partida para esa decisión, no la respuesta. Esta guía explica cómo leer los benchmarks, cómo construir una evaluación ligera para tu propia tarea y cómo sopesar los compromisos.

Qué miden los benchmarks públicos

Benchmark Qué mide Útil para Advertencias
SWE-bench / SWE-bench Verified Resolver issues reales de GitHub en repositorios Python Agentes de programación Solo Python; el andamiaje del agente influye tanto como el modelo
LMArena (Chatbot Arena) Preferencias humanas por pares en chat abierto Calidad general del asistente, estilo Premia el estilo y la longitud; los prompts difieren de tu dominio
HELM Muchos escenarios y métricas, incluidas robustez y calibración Comparación global La cobertura va por detrás de los modelos más nuevos
MMLU / MMLU-Pro, GPQA Conocimiento y razonamiento en preguntas tipo test Niveles aproximados de capacidad Saturados en la parte alta; riesgo de contaminación
MTEB Modelos de embeddings Recuperación y RAG Consulta la guía de embeddings
Tests de contexto largo (RULER y similares) Recuperación y razonamiento sobre entradas largas Aplicaciones con muchos documentos Tareas sintéticas

SWE-bench, construido a partir de 2.294 issues y pull requests reales de 12 repositorios Python populares, se convirtió en el estándar para agentes de programación (Jimenez et al., 2023); su subconjunto validado por personas, SWE-bench Verified, eliminó tareas problemáticas (OpenAI, 2024). Chatbot Arena clasifica los modelos mediante votos por pares de la comunidad usando un modelo de Bradley-Terry (Chiang et al., 2024).

Por qué los benchmarks engañan

  • Contaminación. Las preguntas de test se filtran a los datos de entrenamiento. Cuando unos investigadores crearon GSM1k, un conjunto nuevo que replicaba un benchmark de matemáticas popular, varios modelos bajaron notablemente, lo que sugiere sobreajuste al original (Zhang et al., 2024).
  • Saturación. Cuando todos los modelos punteros superan el 90%, las diferencias son ruido.
  • Andamiaje. Los benchmarks de agentes miden modelo + entorno. La cifra de un proveedor con su agente a medida no se traslada a tu configuración.
  • Distribución distinta. Tus entradas —correos de clientes en español o ucraniano, datos de un ERP, contratos legales— no se parecen en nada a las preguntas de los benchmarks.
  • Sesgo de estilo. Los rankings basados en preferencias premian respuestas más largas y con más formato que pueden no encajar en tu producto.
  • Dimensiones ausentes. Los benchmarks rara vez miden el comportamiento de rechazo, el seguimiento de instrucciones en prompts de sistema largos, la fiabilidad en llamadas a herramientas o la consistencia entre ejecuciones.

Usa los benchmarks para hacer una lista corta de 3–5 candidatos. Después prueba con tu propia tarea.

Construye un eval específico para tu tarea en dos días

No necesitas un equipo de investigación. Un eval práctico:

  1. De 50 a 200 entradas reales de tu dominio, incluidos casos límite y los idiomas en los que escriben tus usuarios.
  2. Evaluación por elemento: comprobaciones en código cuando sea posible (JSON correcto, categoría correcta, contiene los hechos requeridos), LLM-as-a-judge con una rúbrica clara cuando no, más revisiones humanas por muestreo.
  3. El mismo prompt y la misma configuración para todos los candidatos primero; después, una adaptación rápida del prompt por modelo, porque los modelos responden de forma distinta a las mismas instrucciones.
  4. Varias ejecuciones para medir la varianza.
  5. Registra el coste y la latencia por elemento, no solo la calidad.

La metodología completa está en cómo evaluar aplicaciones LLM. Para agentes, incluye tareas de varios pasos con herramientas y evalúa el estado final y la trayectoria.

Model         Quality (judge)  JSON valid  p95 latency  Cost / 1k req
candidate-A        0.91          100%         6.8 s        $14.20
candidate-B        0.89          100%         3.1 s         $4.10
candidate-C        0.82           97%         1.4 s         $0.90

Resultados como estos suelen llevar a una decisión de routing más que a un único ganador.

Dimensiones que sopesar

Calidad en tu tarea

El resultado del eval es la señal principal. Mira los fallos por categoría: un modelo 2 puntos mejor en general que falla todas las preguntas sobre reembolsos puede ser la elección equivocada.

Coste

El precio por token es solo una parte. Compara el coste por tarea resuelta: un modelo más barato que necesita más reintentos, prompts más largos o más pasos de agente puede salir más caro. Ten en cuenta los descuentos por prompt caching, los precios por lotes y las cargas con muchos tokens de salida; consulta optimización de costes de LLM.

Latencia

Mide el tiempo hasta el primer token y el tiempo total con tus prompts. Los modos de razonamiento mejoran la calidad en tareas difíciles y aumentan la latencia; muchos productos los usan de forma selectiva. En un chat, un primer token por debajo del segundo importa más que el tiempo total; en tareas en segundo plano, importa más el rendimiento.

Capacidades

Fiabilidad en llamadas a herramientas, soporte de salida estructurada, longitud de contexto, entrada de imágenes y PDF, calidad multilingüe (prueba explícitamente el español y los demás idiomas de tus usuarios) y controles disponibles de razonamiento o esfuerzo.

Factores operativos

Límites de frecuencia en tu nivel, disponibilidad regional, residencia de datos, opciones de retención y contratos de encargo de tratamiento (guía de privacidad), historial de disponibilidad y presencia en varias nubes para tener fallback (guía de fiabilidad).

Abiertos frente a cerrados

Modelos cerrados (API) Modelos de pesos abiertos
Techo de calidad El más alto en razonamiento complejo, programación y agentes Fuertes y mejorando; la distancia varía según la tarea
Control de los datos Condiciones del proveedor, contratos de tratamiento Total, si son self-hosted
Modelo de coste Por token Infraestructura + ingeniería
Personalización Prompting, algo de fine-tuning Fine-tuning completo, cuantización, control de la decodificación
Ciclo de vida Modelos retirados según el calendario del proveedor Tú decides cuándo actualizar

Muchos equipos combinan ambos: modelos de frontera por API para las tareas difíciles y modelos abiertos para las sensibles o de gran volumen; consulta LLM self-hosted.

Routing: rara vez necesitas un solo modelo

Las mejores configuraciones de producción enrutan las peticiones:

  • Por tarea: un modelo pequeño y rápido para clasificación y extracción; un modelo de frontera para razonamiento complejo, programación y planificación de agentes.
  • Por dificultad: prueba primero el modelo más barato y escala cuando la validación falla o las señales de confianza son débiles.
  • Por nivel de usuario o presupuesto de latencia.

El routing convierte la elección de modelo de una apuesta única en una configuración que puedes ajustar. Es también una de las palancas de la arquitectura de agentes de IA.

Evitar la dependencia del proveedor

  • Abstrae el punto de llamada. Una interfaz interna fina (o una librería como el Vercel AI SDK, Spring AI o LiteLLM) mantiene el código específico del proveedor en un solo lugar; consulta chat de IA en Next.js y Spring AI.
  • Guarda los prompts y los evals en tu repositorio. Son el verdadero activo; con ellos, cambiar de modelo es un experimento medido.
  • Evita depender a fondo de funciones propietarias salvo que aporten un valor claro, y cuando las uses (estado de conversación en el servidor, almacenes de archivos propietarios), ten claro cómo migrarías.
  • Reevalúa con un calendario. Cada trimestre o con cada versión importante, ejecuta tu eval sobre los nuevos candidatos. Las retiradas de modelos te obligarán a migrar de todos modos; estar preparado lo convierte en rutina.

Actualizar de modelo es una migración

Pasar a una versión más nueva de la misma familia de modelos no es gratis. Los modelos nuevos pueden seguir las instrucciones de forma más literal, cambiar la longitud o el formato de la salida o gestionar las herramientas de otra manera. Trata cada actualización como un cambio: ejecuta los evals, compara por categoría, lee una muestra de salidas, despliega de forma gradual y mantén el modelo anterior disponible como fallback hasta estar seguro. Los proveedores publican notas de migración; léelas antes de actualizar.

Un proceso de selección que funciona

  1. Define la tarea, los criterios de éxito y las restricciones de latencia y presupuesto.
  2. Haz una lista corta de 3–5 modelos a partir de benchmarks públicos, capacidades y requisitos operativos.
  3. Ejecuta tu eval con el mismo prompt y después con un ligero ajuste del prompt por modelo.
  4. Compara la calidad por categoría, el coste por tarea resuelta y la latencia.
  5. Decide un modelo principal, un fallback y, quizá, un router.
  6. Lanza tras un feature flag y monitoriza la calidad y el coste en producción.
  7. Repite el eval cada trimestre y con cada versión importante.

Preguntas frecuentes

¿Elegimos sin más el primer modelo de LMArena? Es una opción razonable por defecto para un asistente de chat general, pero no para extracción, clasificación, agentes de programación o tareas de un dominio concreto. Prueba con tus datos.

¿Cuántos elementos de eval necesitamos para comparar modelos? Cincuenta elementos bien elegidos revelan las diferencias grandes; hacen falta más de 200 para fiarse de diferencias de pocos puntos. Informa de intervalos de confianza o, al menos, de la varianza entre ejecuciones.

¿Los modelos abiertos ya son lo bastante buenos? Para muchas tareas acotadas, sí. Para agentes complejos y programación, los modelos cerrados de frontera suelen seguir por delante. Evalúa tu caso.

¿Con qué frecuencia tenemos que cambiar de modelo? Solo cuando los evals muestran mejoras significativas o se retira un modelo. Perseguir cada lanzamiento sale caro; basta con una reevaluación programada.

Fuentes

  1. Jimenez et al. (2023). SWE-bench: Can Language Models Resolve Real-World GitHub Issues?; OpenAI (2024). Introducing SWE-bench Verified.
  2. Chiang et al. (2024). Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference; LMArena.
  3. Liang et al. (2022). Holistic Evaluation of Language Models (HELM).
  4. Zhang et al. (2024). A Careful Examination of Large Language Model Performance on Grade School Arithmetic.
  5. Artificial Analysis: comparativas independientes de precio, velocidad y calidad de modelos.
  6. Anthropic. Models overview.