Artificial Analysis detecta pérdidas de calidad en 24 de 103 endpoints de API

El nombre del modelo en la configuración de la API no garantiza la calidad esperada. Un agente puede elegir la herramienta correcta, pero el proveedor puede enviarle los argumentos en un formato incorrecto. O el modelo puede agotar todo el espacio disponible para la respuesta en el razonamiento, sin llegar a un resultado. Para el usuario, ambos casos se ven igual: el producto no ha resuelto la tarea.

Artificial Analysis ha actualizado su Endpoint Accuracy Index a la versión 1.1. De los 103 endpoints de servidor evaluados, 24 rindieron estadísticamente por debajo del despliegue de referencia del modelo correspondiente. Eso supone alrededor del 23% de la muestra. La conclusión práctica para los equipos: al elegir una API, hay que probar al proveedor concreto, aunque el modelo ya haya superado las pruebas internas.

Dónde se pierde calidad

GLM-5.3 Flash ofrece un ejemplo revelador. Dos endpoints limitan la respuesta máxima a unos 32 mil tokens. Aproximadamente la mitad de sus respuestas a las preguntas difíciles de HLE-250 alcanzaron ese límite antes de llegar a un resultado. El porcentaje de respuestas correctas fue del 22,3% y del 28,5%, frente al 55,4% del despliegue de referencia.

También hay restricciones menos evidentes. Otros dos endpoints del mismo modelo generaron alrededor de un 30% menos de tokens de razonamiento sin que se apreciara una interrupción de la respuesta. Sus resultados en HLE-250 fueron del 48,4% y del 48,6%. Esta observación por sí sola no permite determinar la causa interna, pero la diferencia es importante para los desarrolladores: solicitar la misma configuración no produjo el mismo comportamiento.

Con las herramientas, el problema puede ser muy básico. Imaginemos un servicio de reservas en el que el identificador de la reserva debe enviarse como una cadena de texto. Dos endpoints de Muse Spark Open devolvían esos argumentos como números. En un flujo de varios pasos, eso basta para que una llamada incumpla el contrato de la herramienta. En BFCL-500 obtuvieron un 49,9% y un 50,7%, frente al 59,1% de la referencia.

Otros fallos detectados incluían nombres de parámetros alterados, objetos representados como cadenas JSON y la reutilización de identificadores de llamadas a herramientas. En un endpoint de Kimi K3, las solicitudes se interrumpían al cabo de unos diez minutos: alrededor del 9% de las tareas de HLE-250 terminaban sin una respuesta del modelo.

Qué mide el índice

Cada endpoint pasa por tres pruebas: llamadas a herramientas, preguntas científicas difíciles y búsqueda de información en un contexto largo de unos 100 mil tokens de entrada. La puntuación de cada prueba se divide entre la del despliegue de referencia, se expresa como porcentaje y se promedia con el mismo peso para las tres pruebas.

Por tanto, un valor del índice del 100% indica un rendimiento al nivel de la referencia, no un 100% de respuestas correctas. Un valor superior al 100% tampoco demuestra que el proveedor sea mejor: hay que considerar el intervalo de incertidumbre. Los autores consideran que un endpoint rinde por debajo de la referencia cuando todo su intervalo de confianza del 95% queda por debajo del 100%.

En la versión 1.1, el número de repeticiones de la prueba de contexto largo aumentó de 10 a 25, se corrigieron las claves de respuesta de dos preguntas y se actualizó el modelo que evalúa las coincidencias. En el conjunto de la muestra, el margen de error medio de esta prueba se redujo de ±4,7 a ±2,6 puntos porcentuales. Los resultados de distintas versiones no se pueden comparar directamente.

Sin embargo, sería un error atribuir todas las pérdidas a la cuantización. Los tres endpoints de GLM-5.3 Flash con pesos FP4 estuvieron estadísticamente al nivel de la referencia FP8. Y los 22 endpoints evaluados de DeepSeek V4.1 Flash 1017 igualaron la referencia dentro de los márgenes de incertidumbre.

Qué comprobar antes de conectar una API

Para los equipos, el índice resulta útil como filtro previo a sus propias pruebas. Conviene comprobar la longitud máxima de respuesta, el tiempo de espera de las solicitudes, si la transmisión termina correctamente y los tipos reales de los argumentos de las herramientas. Después, hay que ejecutar de principio a fin varias tareas representativas del producto: desde la solicitud del usuario hasta la última acción del agente. Probar una respuesta aislada no revela qué fallará en la tercera llamada a una herramienta.

El estudio tiene limitaciones importantes. Tres pruebas no abarcan todas las cargas de trabajo, y la ausencia de un rendimiento inferior estadísticamente significativo no garantiza una equivalencia total. Las mediciones se realizaron del 8 de octubre al 4 de noviembre de 2026; la configuración de los proveedores puede haber cambiado desde entonces. El precio y la latencia siguen siendo criterios importantes, pero ahora la calidad de un endpoint concreto se puede comprobar por separado e incorporar esa comprobación al procedimiento de cambio de proveedor.