TI agéntica: ¿Pueden los agentes de IA diseñar un benchmark?
Probamos 16 modelos en un diseño de benchmark de texto a SQL y llamada de herramientas. Cada modelo creó un benchmark por tema, para un total de 32 envíos. Ningún envío superó todos los criterios de la rúbrica. Los agentes pudieron construir y ejecutar pruebas, pero ninguno demostró a la vez una prueba de respuesta en blanco y una prueba de respuesta correcta de su propio evaluador.
Resultados del diseño del benchmark
El texto a SQL convierte una pregunta en lenguaje natural en una consulta de base de datos. La llamada de herramientas selecciona una función y completa sus argumentos.
Calificamos cada envío según una rúbrica que los agentes no vieron. La rúbrica de texto a SQL tiene 78 puntos, y la de llamada de herramientas tiene 74. Las puntuaciones muestran el porcentaje de puntos aplicables de la rúbrica. Las etiquetas de las barras se redondean a números enteros.
- Texto a SQL: Claude Opus 5 y Grok 4.6 empatan con 78,2 %. Al remuestrear los criterios de la rúbrica, el 95 % central de sus posiciones se sitúa entre 1st y 5.
- Llamada de herramientas: GPT 5.6 Sol lidera con 74,3 %. El 95 % central de sus posiciones remuestreadas se sitúa entre 1st y 4. Las horquillas de posiciones proceden del remuestreo de los criterios de la rúbrica.
En los 16 modelos, las puntuaciones de los dos temas correlacionan con 0.42 (Pearson). La puntuación media combina dos rúbricas con criterios distintos, por lo que no es una comparación equivalente.
Controles de calidad ausentes
Ningún envío superó estas cuatro comprobaciones:
- Prueba de respuesta en blanco: Las respuestas vacías pasan por el evaluador. Un evaluador que funcione debería otorgar cerca de cero puntos.
- Prueba de respuesta correcta: Las respuestas de referencia pasan por todos los pasos de extracción y puntuación. Un evaluador que funcione debería otorgar la puntuación completa.
- Prueba de referencia ausente: Los casos se repiten sin el esquema de la base de datos ni las definiciones de las herramientas.
- Objetivo de dificultad: El modelo más fuerte debería puntuar entre 40 % y 60 %. Superó el 60 % en 30 de 32 envíos.
Veinte envíos tampoco alcanzaron la diferencia requerida de al menos 20 puntos entre los modelos más fuerte y más débil.
- Calibración: Dos envíos superaron la comprobación de calibración: GLM 5.3 en texto a SQL y Claude Opus 5 en llamada de herramientas. Para aprobar, un envío debía conservar sus revisiones y explicarlas después de no alcanzar el objetivo de dificultad.
- Predicciones: Seis de 32 envíos superaron la comprobación de predicción. Para aprobar, había que nombrar los mejores y peores modelos y situar al menos dos de sus cuatro puntuaciones dentro de los intervalos predichos. Cada agente también predijo el intervalo de puntuación y el puesto de un quinto modelo reservado. Dos envíos acertaron ambas cosas: Gemini 3.8 Flash y Grok 4.6, ambos en texto a SQL.
- Afirmaciones sin respaldo: Veintidós de 32 informes no superaron la comprobación del panel de jueces sobre afirmaciones sin evidencia de respaldo.
Coste y tiempo
Los registros de coste cubren 16 modelos y los de tiempo transcurrido cubren 15. El gráfico utiliza los 15 con ambos registros y omite Grok 4.6 porque su duración no está registrada.
Los costes cubren la inferencia del agente de autoría por tema, incluidos los reintentos registrados. Excluyen las llamadas a API realizadas por los programas de benchmark generados, por lo que subestiman el coste completo de construir y ejecutar un benchmark.
Las ejecuciones utilizan distintos programas de agente e incluyen intentos de reemplazo. Los datos no pueden mostrar si un mayor gasto o ejecuciones más largas conducen a puntuaciones más altas.
Los intervalos de puntuación obtenidos al remuestrear los criterios de la rúbrica tienen una amplitud media de 32.7 puntos. Excluyen la variación que añadirían ejecuciones de autoría repetidas.
Lo que los modelos hicieron bien
Cada fila de resultados de los 32 envíos principales enlaza a una respuesta guardada del modelo. Volver a ejecutar el evaluador de cada envío sobre esas respuestas guardadas reprodujo su tabla de resultados. La puntuación es repetible, pero la reproducción no autentica las respuestas guardadas.
Además, eliminamos y corrompimos por separado archivos de respuesta muestreados. Los 32 evaluadores cambiaron su salida y distinguieron una respuesta eliminada de una corrupta. La prueba no comprueba todas las reglas de puntuación.
Veintidós de 32 informes no superaron la comprobación del panel sobre afirmaciones sin respaldo.
Qué significan los resultados para la TI agéntica
En las operaciones de TI, un agente de IA lee el estado de un sistema y actúa sobre él, por ejemplo instalando un parche o reiniciando un servicio. Después, una comprobación separada debe confirmar que la acción funcionó. Las pruebas de control del evaluador de este benchmark desempeñan el mismo papel en la calificación: confirman que el evaluador funciona antes de usar sus resultados. Ninguno de los 32 envíos principales superó esas pruebas.
Este benchmark cubre texto a SQL y llamada de herramientas. No es una prueba de aplicación de parches, clasificación de tickets ni otras tareas de TI.
Probamos las herramientas de gestión de TI por separado, en sistemas en vivo. Resultados seleccionados:
Añadir como fuente preferidaPlataformas de TI agéntica
Los 16 modelos de este benchmark son LLMs. Las plataformas que figuran a continuación no lo son. Se sitúan por encima de estos modelos y añaden datos de TI, flujos de trabajo y controles.
Un sistema agéntico decide su siguiente paso a partir del estado que observa, mientras que la automatización basada en reglas sigue pasos definidos de antemano. Los productos de TI combinan ambos, por lo que cada entrada siguiente indica qué parte es cuál.
Creatio
Creatio ejecuta agentes de IA dentro de una plataforma de CRM y flujos de trabajo, de modo que un agente actúa sobre los registros propios de la empresa en lugar de sobre una transcripción de chat.
Modelos: OpenAI, Azure OpenAI o cualquier proveedor compatible con la biblioteca LiteLLM, incluidos modelos en los propios servidores de la empresa. Cada agente puede usar uno distinto.
Los equipos crean sus propios agentes: Un agente se define en la interfaz, no en código: sus instrucciones, luego lo que no debe hacer, a qué datos no puede acceder, qué habilidades puede invocar y qué acciones puede realizar sobre un registro.
Agentes de codificación crean las aplicaciones: Claude Code, Codex y GitHub Copilot se conectan a la plataforma mediante un plugin, habilidades de agente y MCP herramientas, y pueden crear modelos de datos, páginas, reglas de negocio y datos de prueba.
ServiceNow
ServiceNow es una plataforma de gestión de servicios de TI (ITSM).
Modelos: La orquestación de agentes puede ejecutarse en Azure OpenAI, Claude en AWS, Google Gemini o Now LLM, el modelo propio de ServiceNow.
Confirmación antes de la acción: Los agentes de ITSM pueden iniciarse manualmente desde el panel Now Assist o ejecutarse automáticamente cuando se crea o actualiza un registro. Los administradores deciden qué acciones necesitan la confirmación de una persona.
NinjaOne
NinjaOne es una plataforma de gestión de endpoints que cubre monitorización, parcheado, copia de seguridad y acceso remoto.
Modelos: NinjaOne no documenta una elección de modelo para sus funciones de IA. Se ejecutan como parte de la plataforma, a diferencia de las opciones anteriores, donde un administrador elige el proveedor.
Riesgo de parches puntuado a partir de informes de la comunidad: Patch Intelligence IA revisa la telemetría del proveedor y los informes públicos de otros administradores sobre actualizaciones de Windows, luego marca las actualizaciones que rompieron sistemas en otros lugares y resume el contexto. Las demás plataformas de esta sección leen los registros propios de una empresa; esta función lee lo que ocurrió en otras empresas.
Detección de CVE sin escaneo: El módulo de vulnerabilidades identifica CVE a partir de la telemetría de software analizada en la nube de NinjaOne, de modo que no se ejecuta ningún escaneo en el endpoint y los hallazgos pasan al módulo de parcheado para su corrección.
Metodología
La tarea
Para cada tema, todos los modelos recibieron el mismo prompt fijo. El prompt pedía al agente:
- elegir un tema de negocio,
- escribir al menos 24 casos de prueba en cuatro categorías,
- escribir un ejecutor (el programa que envía casos a los modelos) y un evaluador (el programa que califica las respuestas),
- ejecutar cuatro modelos designados dos veces en cada caso.
Un quinto modelo se reservó. El agente predijo primero sus resultados y luego lo probó.
El prompt pedía a cada agente decidir qué estándares de calidad necesita un benchmark antes de su publicación y demostrar que los cumplía. El prompt no indicaba el objetivo numérico de dificultad ni nombraba ninguna prueba del evaluador.
Agentes y envíos
Los envíos se ejecutaron entre julio y septiembre de 2026. La mayoría usó opencode, un programa de agente que da al modelo una terminal y un sistema de archivos.
La versión anterior cubrió 14 modelos y 28 envíos. Nuestros datos históricos también incluyen siete modelos más antiguos que ya no están en la lista.
También ejecutamos cinco configuraciones piloto para GPT 5.5, lo que dio lugar a 10 envíos adicionales. Sus prompts difieren de la tarea principal, por lo que los gráficos los excluyen. En total, esta actualización incluye 42 envíos y califica 40. Dos envíos piloto no alcanzaron el tamaño mínimo del dataset, por lo que el panel de jueces no los calificó.
Calificación
El código comprueba los archivos enviados, reconstruye las bases de datos, vuelve a ejecutar los evaluadores y coteja las filas de resultados con los archivos de respuesta. Un panel de modelos califica los criterios que requieren interpretación. El código enviado se ejecuta en una copia aislada sin acceso a la red.
Excluimos una reejecución en vivo de las llamadas a modelos muestreadas para cada envío porque los ejecutores tienen interfaces diferentes y algunos carecen de configuraciones de proveedor utilizables. Sin ese criterio, las rúbricas suman 78 puntos para texto a SQL y 74 para llamada de herramientas.
Los 32 envíos de los gráficos superan las comprobaciones requeridas de archivos y tamaño del dataset. Los prompts de la tarea no se editaron para esta actualización y los resultados usan un envío conservado por modelo y tema.
Pruebas de control del evaluador
La prueba de referencia ausente comprueba si los modelos pueden responder sin la información que se supone que necesitan. Si aun así puntúan bien, las preguntas pueden revelar la respuesta o los modelos pueden haber visto los datos durante el entrenamiento. Una puntuación alta por sí sola no prueba ninguna de las dos cosas.
Un prompt piloto nombró las tres pruebas del evaluador, y ese piloto las ejecutó en ambos temas. Volver a ejecutar sus archivos de prueba guardados sin acceso a la red reprodujo las cifras registradas.
Los prompts de los 32 envíos principales dejaron estas pruebas en manos del agente, y ninguno de esos envíos superó ninguna de las tres. Un único prompt del estudio nombró las pruebas, por lo que su efecto entre modelos sigue sin probarse.
El panel de jueces
5.6 Sol y Claude Opus 5 califican cada criterio enviado al panel. Cuando no están de acuerdo, Grok 4.6 emite el voto decisivo.
Los jueces se ejecutan con temperatura 0 (el ajuste menos aleatorio), con un alto esfuerzo de razonamiento y un límite de 32.000 tokens. Si un juez devuelve JSON incompleto o no válido, no se registra ningún veredicto y la llamada se reintenta.
En 672 criterios, incluidos los pilotos, los dos jueces principales discreparon en 195. Sol aprobó el 54,8 %, y Opus el 82,6 %. Grok aprobó 133 de los criterios en disputa.
Los proveedores de los jueces también tienen envíos calificados en este benchmark: cuatro de OpenAI, cuatro de Anthropic y uno de xAI. Los prompts de los jueces omiten los nombres de los autores y eliminan las rutas de archivo que podrían identificar un modelo. El estilo de redacción aún puede revelar al autor.
En envíos de proveedores distintos de OpenAI y Anthropic, Sol puntúa 13.9 puntos por debajo de Opus. En envíos de OpenAI, la diferencia fue de 9.1 puntos, es decir, 4.8 puntos menor. En envíos de autoría de Anthropic, la ventaja de Opus sobre Sol es 0.1 puntos menor que en el trabajo de otros proveedores. Los prompts piloto difieren, por lo que la auditoría no establece favoritismo. Grok solo juzga disputas, incluidas las disputas sobre sus propios envíos, y sus votos quedan fuera de esta auditoría.
Intervalos
Los intervalos de puntuación y el 95 % central de las posiciones del ranking usan 4.000 extracciones pareadas de criterios de la rúbrica con reemplazo. Cada envío se vuelve a puntuar con los mismos criterios extraídos que los demás de su tema. Los intervalos describen la dependencia de la rúbrica y excluyen la incertidumbre por muestreo de tareas y entre ejecuciones. Las correlaciones son de Pearson.
Cita este benchmark
Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.
@misc{kalelioglu2026,
author = {Kalelioğlu, Berk and Alper, Şevval},
title = {{TI agéntica: ¿Pueden los agentes de IA diseñar un benchmark?}},
year = {2026},
month = sep,
howpublished = {\url{https://aimultiple.com/agentic-it}},
note = {AIMultiple. Recuperado el 18 de septiembre de 2026}
}Resultados y marcas de tiempo de 21 puntos de datos. Descargue los datos resumidos que se muestran en los gráficos y las tablas de este artículo como un archivo ZIP que contiene 2 archivos CSV y un README.
¿Quieres los datos granulares que hay detrás? Únete a Premium
Şevval se centra en herramientas de codificación con IA, agentes de IA y tecnologías cuánticas.
Sé el primero en comentar
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.