AIM-Decision: Jev frente a Kev frente a LLMs

Los modelos de decisión, también llamados modelos de Sistema 1,¹ puntúan un conjunto fijo de opciones en lugar de generar texto token por token. Probamos 22 modelos de decisión en 1.655 preguntas de clasificación, como calificar una vulnerabilidad de seguridad o el retiro de un producto, y ejecutamos 19 de ellos en 50 tareas de navegador.

Resultados del benchmark de clasificación

• decider-12b obtuvo 46.4 en vulnerabilidades de seguridad y 62.4 en retiros, a $0,06 por cada 1.000 decisiones. Ningún modelo de decisión obtuvo una puntuación significativamente mayor en ninguna de las dos tareas.
• Jev 1.13 costó $0,039 por cada 1.000 decisiones y obtuvo 47.9, aproximadamente un punto por debajo de Kev-9B y Nimble 9B, que costaron alrededor de 7 y 9 veces más.
• Eikos-27B, con 27 mil millones de parámetros, costó $0,075 por cada 1.000 decisiones. Tev1 4B, con 4 mil millones, costó $0.34.
• GLiDE obtuvo 46.5 en vulnerabilidades de seguridad frente al 46.4 de decider-12b, pero tardó 15,7 segundos por decisión frente a 0.13 y costó $0,48 por cada 1.000 decisiones. Clef promedió 51.0 a $0,17 a través de la Cloudflare API.

Tasas de éxito de la automatización del navegador

Un intento por tarea; los LLMs se ejecutaron con el ajuste de bajo esfuerzo de razonamiento de su API.

• Solar Decide, Nimble 9B y los dos modelos Tev1 no están clasificados: sus servicios aceptan como máximo 26 opciones por pregunta, y 17 de las 50 tareas se abren en una página con más. Laya tampoco está clasificado, porque sus límites de entrada rechazaron solicitudes que los demás modelos recibieron completas.
• Kev-27B completó 40 tareas, dos menos que Gemini 3.8 Flash y siete menos que GPT-6 Astra, a un costo estimado de $0,006 por tarea completada frente a $0,026 para Gemini y $0,226 para Astra.
• Los modelos de decisión en conjunto completaron 44 de las 50 tareas, incluidas dos de las tres que Astra falló.
• decider-12b, primero en clasificación, completó 16 tareas del navegador; Kev-27B, que obtuvo una puntuación inferior a Jev en clasificación, completó 40.

Consulta 10 tareas de ejemplo y el resultado de cada modelo en Hugging Face, y cómo ejecutamos el benchmark en la metodología.

Modelos de decisión frente a LLMs en tareas de navegador

La mayoría de los LLMs escriben su respuesta token a token, y cada token cuesta cómputo y tiempo. En la mayoría de los pasos del navegador, el agente solo elige una operación y un control en la página.

Un modelo de decisión lee la página y las opciones, puntúa cada opción y devuelve la más probable. Devuelve una probabilidad para cada opción en lugar de texto generado, por lo que un paso no necesita una salida larga. Si los modelos de decisión se vuelven suficientemente precisos, la misma automatización podría ejecutarse mucho más rápido y a una fracción del costo de los LLM.

Los modelos de decisión, tal como los servimos, devuelven puntuaciones de opciones y ningún texto, por lo que un modelo de texto independiente, Mercury 2.5,² escribe los valores que se introducen en los campos del formulario. Lo llamamos el asistente de texto y estuvo disponible para todos los modelos.

Ejecutamos todos los modelos en el runtime de código abierto jev-ultrafast de browser-use,³ que fue creado para Jev 1.13 de TypeSafe.⁴ GPT-6 Astra sirve como referencia de LLM de gama alta y Gemini 3.8 Flash como uno de bajo costo. Todos los modelos se enumeran en la metodología.

Cinco modelos en la misma tarea

En Wikipedia, todos los modelos excepto Laya escribieron en el cuadro de búsqueda, el asistente de texto escribió “Ada Lovelace” y el modelo eligió la sugerencia correcta. Jev llegó al artículo en 8,1 segundos, Gemini en 11.0, Astra en 18.9 y Kev-9B en 43.8. Laya declaró la tarea completada en la página principal sin realizar ninguna acción.

La tarea de filtrado necesita dos menús desplegables y un botón de búsqueda. Jev, Gemini y Astra siguieron los mismos cuatro pasos y terminaron en 4.6, 10.7 y 20,3 segundos. Laya hizo clic en el logotipo del sitio y declaró la tarea completada. Kev-9B falló esta tarea en el benchmark y, en la demostración, seguía haciendo clic después de 11 minutos, por lo que se lo dejó fuera de este clip.

Los subtítulos muestran la operación y el objetivo elegidos por cada modelo y, para los modelos de decisión, la probabilidad de esa operación. Los clips provienen de una ejecución de demostración independiente a velocidad 1×, no del benchmark puntuado, y cada página final se verificó con el evaluador del benchmark.

Cómo fallaron los modelos

Jev y Kev-9B completaron juntos 26 tareas distintas. Ambos completaron las dos tareas de Wikipedia y la tarea de menú desplegable de Web Scraper, al igual que ambos LLMs. En Books to Scrape, donde cada tarea pasa de una lista de categorías a una página de producto, Jev no completó ninguna de las seis y Kev-9B completó tres. Kev-27B, Eikos-27B y AutoJev-27B completaron las seis.

• Jev declaró la tarea bloqueada en 24 de sus 33 fallos, 16 veces antes de realizar cualquier acción.
• Kev-9B realizó una mediana de 9.5 acciones en las tareas fallidas, frente a 3 en las tareas que completó. Diez intentos alcanzaron el límite de acciones o de llamadas de decisión, y cinco más se detuvieron después de que tres acciones seguidas dejaran la página sin cambios.
• Kev-4B, del desarrollador de Kev-9B, declaró la tarea bloqueada en su primera decisión en 29 de las 50 tareas.
• Kev-27B, Eikos-27B y GLiDE fallaron las siete tareas en común. Declararon cuatro de ellas bloqueadas, dos búsquedas de productos de ScrapeMe y dos tareas de Web Scraper, y ninguno de los tres terminó la casilla de verificación ni el formulario de calculadora.
• GPT-6 Astra falló 3 tareas. Marcó una tarea de categoría de ScrapeMe como bloqueada, siguió escribiendo en el mismo campo de la calculadora hasta que lo detuvieron y, en la tarea de formulario T02, el asistente de texto no devolvió ningún valor válido después de que Astra hubiera completado y enviado el formulario.
• Gemini 3.8 Flash falló 8, incluida la misma terminación de T02. Cuatro fallos llegaron a la página correcta pero no terminaron, dos fueron detenidos por nuestra salvaguarda de costes cuando OpenRouter no informó una tarifa, y uno alcanzó el límite de acciones.

Por qué algunos modelos obtuvieron 0/50

GLiNER2.5-Decide

GLiNER2.5-Decide de Fastino⁵ declaró las 50 tareas completadas demasiado pronto, 49 de ellas en su primera decisión. En las 37 tareas que comparten una página de inicio con otra tarea, sus probabilidades de operación difirieron en no más de 6 puntos entre objetivos.

Fastino describe GLiNER2.5-Decide como un clasificador para decisiones como el enrutamiento de tickets, la intención, la urgencia y si un agente ha terminado, y afirma que el modelo no razona. El modelo está diseñado para entradas de hasta 512 tokens, pero acepta entradas más largas. Nuestras solicitudes del primer paso tenían una mediana de 1.915 tokens.

CLM-v0.1-8B

CLM-v0.1-8B de Contrastive-LM⁶ eligió esperar en 2.199 de sus 2.288 decisiones de operación, por lo que 36 intentos se quedaron sin acciones. En las mismas páginas de inicio, sus probabilidades difirieron como máximo 13 puntos entre objetivos.

Contrastive-LM afirma que CLM-v0.1-8B, sin fine-tuning, rinde a la par de Jev en tareas de uso de computadora, juegos y llamadas a herramientas, y que acepta el formato de solicitud de Jev sin cambios.⁷ Le enviamos solicitudes en ese formato.

Velocidad y éxito

Kev-27B, Eikos-27B y AutoJev-27B completaron entre el 68 % y el 80 % de las tareas con una mediana de aproximadamente 7 segundos por intento, más rápido que Gemini con 12,7 segundos y Astra con 17.4. decider-4b, decider-12b y Jev tardaron de 2.5 a 4,2 segundos por intento y declararon bloqueadas de 19 a 24 tareas.

GLiDE completó el 72 % con una mediana de 46,8 segundos por intento, la más lenta de todos los modelos, y 3 de sus intentos alcanzaron el límite de 900 segundos.

GLiNER2.5-Decide (0,2 segundos) declaró 49 de 50 tareas completadas en su primera decisión, y Kev-4B declaró 29 tareas bloqueadas en la suya.

Kev-9B tuvo una mediana de 38,3 segundos por intento, cinco veces la de Kev-27B. Cada decisión de Kev-9B tomó una mediana de 3,7 segundos de tiempo de servidor, frente a aproximadamente 1 segundo para una llamada completa a la API de Jev. La sobrecarga de la solicitud añadió aproximadamente medio segundo.

Kev-9B promedió 26 decisiones por intento, frente a aproximadamente 4 para Jev, y el 90 % de ellas se produjeron en intentos fallidos.

Costo

Costo de la automatización del navegador

† Estimación: costo de A100 por token de entrada según la prueba de rendimiento de clasificación, multiplicado por los tokens de entrada del navegador, más las tarifas del asistente de texto. Método en metodología.

‡ La cifra más alta suma 17 solicitudes que fallaron sin informar tokens, contadas a 120.000 tokens de entrada cada una; Fastino podría no facturarlas.

Astra, Gemini y Jev utilizaron entre 3.150 y 3.470 tokens de entrada por decisión. El precio de entrada de Astra es aproximadamente 240 veces el de Jev.⁸⁹

Con razonamiento bajo, Astra produjo 6.599 tokens de salida en 307 decisiones, frente a 968.376 tokens de entrada. El precio de salida de Jev es $0.

Al precio de entrada de Jev, los 968.376 tokens de entrada de decisiones de Astra habrían costado aproximadamente $0,04 en lugar de $9.68. Kev-27B quedó a siete tareas de Astra por un costo estimado de $0,25 en las 50 tareas, frente a los $10,63 de Astra.

Según estas estimaciones, todos los modelos de decisión de la tabla que completaron una tarea, excepto Kev-9B, costaron menos por tarea completada que Gemini. Ninguno costó menos que Jev.

• Kev-9B costó aproximadamente 3 veces lo de Gemini y 46 veces lo de Jev por tarea completada. Su costo estimado de A100 fue de aproximadamente $0,47 por millón de tokens de entrada, 11 veces el precio de la API de Jev, y realizó 1.321 decisiones frente a las 185 de Jev.
• El costo estimado de GPU por token de Kev-4B fue aproximadamente 6.5 veces su precio en OpenRouter.

El tiempo de A100 que alquilamos para la ejecución de Kev-9B, 3.32 horas incluyendo configuración y tiempo inactivo, ascendió a aproximadamente $5.31. Una tarifa de Jev y dos tarifas de Gemini no se registraron y faltan en la tabla.

Costo de clasificación

Los modelos alojados se valoran según los precios de lista de su API, excepto Solar Decide según sus tarifas facturadas. Los modelos locales se valoran por cada 1.000 decisiones al mayor rendimiento que medimos en una A100 alquilada.

Una A100 alquilada cuesta aproximadamente $40 al día, esté ocupada o inactiva. A la tasa que registramos, $40 compra alrededor de un millón de decisiones de Jev.

No te pierdas nuestros análisis comparativos e insights basados en datos. El botón abre Google; seleccionar AIMultiple confirma que deseas ver AIMultiple con más frecuencia en los resultados de búsqueda de Google.

Añadir como fuente preferida

Entrenamiento de modelos de decisión

Ajustamos Kev-9B y Laya con fine-tuning en decisiones que GLM-5.3-Flash, el modelo de etiquetado, tomó en tareas de navegador de ocho sitios web fuera del benchmark. Luego volvimos a ejecutar las 50 tareas. Cada modelo con fine-tuning se compara con su versión original, ejecutada el mismo día y en el mismo hardware.

El Kev con fine-tuning y ambas Laya versiones están en Hugging Face.

El valor p proviene de una prueba pareada en las mismas 50 tareas (McNemar exacto), y un p inferior a 0.05 se considera significativo. El Kev original completó 21 tareas en esta comparación, una más que en los resultados anteriores. Una de las 12 ganancias de Kev, C02, fue un tiempo de espera del navegador en la ejecución original más que un fallo del modelo. Sin ella, Kev ganó 11 tareas y perdió 1 (p = 0.006).

• El Kev con fine-tuning ganó tareas en seis de los nueve sitios web, tres en cada uno de Quotes to Scrape y Scrape This Site. Sus resultados en Web Scraper, Wikipedia y los formularios de TestPages no cambiaron.
• El Kev con fine-tuning terminó 5 intentos bloqueados frente a 12 y alcanzó el límite de acciones 6 veces frente a 11. Declaró completada una tarea sin terminar 7 veces, frente a 4.
• En 41 tareas de los sitios web de entrenamiento que se dejaron fuera del entrenamiento, Kev completó 21 frente a 13 antes. En 101 decisiones individuales de 19 de esas tareas, eligió la operación del modelo de etiquetado el 94 % de las veces, frente al 62 % anterior.
• El primer fine-tuning de Laya eligió la operación del modelo de etiquetado en el 75 % de las 88 decisiones que pudo leer, frente al 19 % del Laya original. Declaró completada una tarea en una página que aún necesitaba una acción 2 veces en lugar de 53.
• En el benchmark, el primer fine-tuning de Laya declaró completada una tarea sin terminar 36 veces, una vez antes de realizar cualquier acción. El Laya original lo hizo 32 veces, 17 de ellas antes de cualquier acción.

Casos de uso de los modelos de decisión

• Comprobación de la señal de finalización de un agente. En la última página que un agente de navegador vio antes de declarar una tarea completada, 13 de los 22 modelos de decisión obtuvieron más de 90 al distinguir entre terminado y no terminado, y AutoJev-27B, Clef y Kev-27B obtuvieron 99.5. No probamos comprobaciones en páginas anteriores de una ejecución.
• Triaje con etiquetas fijas, como calificar avisos de seguridad o retiros. decider-12b superó las respuestas aleatorias por 21 puntos en gravedad y 29 en retiros. En temas de artículos, un clasificador por palabras clave entrenado con 28.595 artículos etiquetados obtuvo 70.4, y ningún modelo de decisión obtuvo una puntuación significativamente mayor; el mismo tipo de clasificador obtuvo cerca del azar en gravedad y retiros.
• Elección de cada acción en la automatización del navegador. El mejor modelo de decisión, Kev-27B, completó 40 de 50 tareas, frente a 42 y 47 de los dos LLMs. Aplicar fine-tuning a Kev-9B con 606 decisiones de otros sitios web lo elevó de 21 a 32.

En las dos tareas principales de clasificación, los modelos de decisión locales costaron entre $0,014 y $0,36 por cada 1.000 decisiones en una GPU alquilada y promediaron menos de un segundo por decisión. En las tareas de navegador, el precio de entrada de Jev fue aproximadamente 1/240 del de GPT-6 Astra.

Cada respuesta también incluye una probabilidad por opción, que una aplicación podría usar para derivar casos inciertos a un LLM. No probamos en qué medida esas probabilidades coinciden con la precisión real. Diecisiete de los 22 modelos se ejecutaron en una sola GPU alquilada; Jev, Solar Decide, GLiDE, Clef y Clef-Flash son APIs alojadas.

Metodología

Benchmark de automatización del navegador

Todos los modelos utilizaron el mismo runtime de navegador jev-ultrafast. En cada paso, convertía la página actual en texto de página más una lista numerada de controles visibles. El modelo elegía una operación, como clic, escribir, seleccionar, completado o bloqueado, y un objetivo de esa lista. El runtime ejecutaba la acción y volvía a leer la página.

Los modelos de decisión ordenan las opciones proporcionadas y no devuelven texto. Cuando cualquier modelo elegía escribir, el asistente de texto escribía el valor en el campo del formulario. Cada intento comenzaba en una sesión de navegador nueva.

GPT-6 Astra, Gemini 3.8 Flash, Jev, Kev-9B y Laya se ejecutaron el 22 de septiembre de 2026, con el navegador en una Mac y Kev-9B en una GPU A100 alquilada.

GLiNER2.5-Decide y CLM-v0.1-8B se ejecutaron el 25 de septiembre en GPUs RTX 4090 alquiladas con Chrome en Linux. Kev-4B se ejecutó el 29 de septiembre en una GPU RTX A6000 alquilada. Solar Decide se ejecutó el 30 de septiembre a través de OpenRouter desde la misma Mac, y Nimble 9B y los dos modelos Tev1 se ejecutaron el mismo día mediante Ollama 0.35.0 en una GPU RTX A6000 alquilada con Chrome en Linux.

GLiDE, Clef y Clef-Flash se ejecutaron el 2 de octubre a través de las APIs de sus proveedores desde la misma Mac, con Chrome 154 en lugar de 153. Kev-27B, AutoJev-27B, Eikos-27B, Eikos-4B, decider-4b y decider-12b se ejecutaron el 2 y el 3 de octubre en GPUs A100 alquiladas con Chrome en Linux.

Ninguna solicitud se acortó para adaptarse a un modelo. La API de Solar Decide y Ollama aceptan de 2 a 26 opciones por pregunta. Una solicitud fuera de esos límites terminaba el intento, como ocurría con las solicitudes demasiado grandes para Laya. Ollama acepta descripciones de opciones solo como texto, por lo que las opciones estructuradas se enviaron como texto JSON compacto. Tev1 incluye un contexto de 2.050 tokens; lo aumentamos a 8.194, el ajuste propio de Nimble, para que las páginas no se cortaran.

El servicio de Cloudflare lee solo los primeros 2.048 tokens del texto de la página para Clef y Clef-Flash. No enviamos páginas más largas, lo que terminó un intento para cada modelo.

Clef, Clef-Flash, decider y Eikos requieren al menos dos opciones por pregunta. Una pregunta con una opción, como el único campo de texto de una página, se enviaba con esa opción dos veces, y la respuesta se asignaba de nuevo a ella.

Ejecutamos Kev-9B con el código de referencia del productor en precisión completa de 32 bits. No se instalaron dos paquetes de kernel opcionales que aceleran su modelo base, por lo que el modelo recurrió a kernels de referencia más lentos. No probamos una configuración de GPU más rápida.

El propio código de CLM convierte cada solicitud en texto. GLiNER recibió el mismo texto, con el objetivo y las reglas de cada pregunta como su prompt. Kev-4B también se sirve en OpenRouter a través de SiliconFlow con precisión de 8 bits.¹⁰ Ejecutado a través de él desde la Mac el 29 de septiembre, Kev-4B completó 6 tareas.

Modelos de navegador

El razonamiento bajo es un ajuste de esfuerzo definido por el proveedor. Las 307 decisiones de Astra incluyeron 791 tokens de razonamiento informados. Kev-9B¹¹ y Kev-4B¹² provienen del mismo desarrollador, y Nimble 9B es de Bespoke Labs.¹³ GLiDE proviene de Fastino, el desarrollador de GLiNER2.5-Decide,¹⁴ y Clef y Clef-Flash de Cloudflare.¹⁵

Dataset

Las 50 tareas cubren nueve sitios web: ocho sitios de práctica creados para scraping y pruebas, más Wikipedia. Las tareas incluyen navegación por catálogos, búsqueda, ordenación, paginación, opciones de productos, formularios y consultas de artículos. Cada tarea comienza desde una URL fija y establece el estado final en una oración, por ejemplo: “Cambia a Ciencia Ficción, encuentra Dune (Dune #1), abre los detalles de su producto y detente.”

Antes de que se ejecutaran los modelos, una ejecución guionizada completó las 50 tareas utilizando solo las acciones admitidas por el runtime. Cada tarea se puede resolver sin contraseñas, CAPTCHAs ni la tecla Enter.

Tareas de ejemplo

Diez de las 50 tareas están publicadas en Hugging Face con las instrucciones, la URL de inicio, las condiciones de aprobación y el resultado de cada modelo. Las otras 40 se reservan para ejecuciones posteriores.

Evaluación

Una tarea se consideraba aprobada cuando el modelo la declaraba completada dentro de los límites y una comprobación independiente de la página final confirmaba todas las condiciones: una URL final aceptada, los hechos de la tarea visibles en la página, más de 100 caracteres de texto de página y una página completamente cargada.

Cada intento tenía 900 segundos, 60 acciones de navegador y 120 llamadas de decisión. Los errores de la API se contaban como fallos. El tiempo se mide desde la primera página cargada hasta la comprobación final.

Los modelos no podían ver el estado de carga de la página que requería la comprobación. Jev en B05 y Gemini en M04 llegaron al contenido correcto, pero fallaron solo esa comprobación, y se cuentan como fallos.

Costo

El costo de la API cubre las llamadas de decisión y el asistente de texto, para los 50 intentos por modelo. OpenRouter informó las tarifas de GPT-6 Astra, Gemini y Mercury. El costo de Jev son sus tokens informados al precio de lista del 22 de septiembre de 2026: $0,042 por millón de tokens de entrada y sin cargo por la salida.⁴ GLiDE, Clef y Clef-Flash también se valoran a sus precios de lista.

Las ejecuciones de navegador autoalojadas utilizaron una A100, A6000, RTX 4090 o una Mac. Las valoramos todas con la A100 de la prueba de costo de clasificación, a $1,673 por hora: el costo por token de entrada de cada modelo allí, multiplicado por sus tokens de entrada del navegador, más las tarifas del asistente de texto.

Ambas cargas de trabajo son casi en su totalidad de entrada, porque estos modelos devuelven puntuaciones de opciones o unos pocos tokens. La estimación supone que el costo crece en proporción a los tokens de entrada. Las entradas del navegador promediaron entre 2 y 12 veces la longitud de las preguntas de clasificación del mismo modelo, y no pasamos las páginas del navegador por la prueba de rendimiento.

Fine-tuning

Las 327 tareas, 286 para entrenamiento y 41 reservadas, provienen de ocho sitios web que no están en el benchmark, incluidos Demo Web Shop, Automation Exercise y Project Gutenberg. Cada tarea se comprobó en un navegador: su página de inicio falla el evaluador y, cuando la tarea termina en una URL diferente, esa página lo aprueba.

GLM-5.3-Flash, un modelo de pesos abiertos bajo la licencia MIT,¹⁶ intentó 300 de las tareas en el runtime del benchmark con razonamiento bajo. Los errores del proveedor le impidieron realizar las otras 27. No usamos GPT-6 Astra ni Gemini para esto, porque los términos de OpenAI y Google prohíben usar su salida para construir modelos competidores.¹⁷¹⁸

Las 184 ejecuciones de entrenamiento exitosas generaron 606 registros de decisión. Una ejecución se consideraba exitosa cuando el evaluador la aprobaba, o cuando llegaba a la página de producto correcta mediante la búsqueda del sitio y solo fallaba la comprobación de URL exacta, como hicieron 11 ejecuciones en todas las tareas.

La prueba de decisión única reproduce 103 decisiones grabadas de 19 tareas reservadas y cuenta con qué frecuencia un modelo elige la operación del modelo de etiquetado. Kev pudo leer 101 de ellas. Laya pudo leer 88 cuando se le enviaban solo las preguntas que cada paso necesita, y 34 en la solicitud completa que envía el benchmark. En esas 34, el Laya original coincidió el 29 % de las veces, el primer fine-tuning el 71 % y el segundo el 41 %.

Ambos modelos partieron de los pesos originales que evaluamos y utilizaron las recetas de entrenamiento de sus productores con los límites de entrada del benchmark. Kev también entrenó durante dos épocas en lugar de una, sin los registros de repetición del productor. Cada ejecución de entrenamiento duró menos de 20 minutos en una H100 GPU.

El primer fine-tuning de Laya usó los mismos 606 registros, omitiendo los que eran demasiado largos para Laya. El segundo conservó solo los 292 que cabían en la solicitud completa que envía el benchmark y añadió 102 de las propias ejecuciones de Laya, donde GLM-5.3-Flash tomaba el relevo después de que Laya declarara una tarea completada o bloqueada. Kev no tuvo una segunda ronda.

El par de Kev y el primer par de Laya se ejecutaron en una H100 alquilada en Francia, con Chrome en Linux. El segundo par de Laya se ejecutó en la Mac del benchmark principal. Cada par utilizó las 50 tareas del benchmark principal, el runtime, los límites y el evaluador, con un intento por tarea.

Benchmark de clasificación

Cada elemento es una decisión con un conjunto fijo de opciones. Los elementos provienen de registros publicados entre julio y septiembre de 2026 y de capturas no publicadas de páginas finales de nuestras propias ejecuciones de navegador. No se puede descartar el solapamiento con el entrenamiento.

Las tres primeras tareas piden a un modelo que reproduzca una decisión registrada por una institución, solo a partir del texto. GitHub y la FDA pueden haber usado evidencia que el texto no contiene. Los niveles de gravedad de GitHub son los cuatro niveles de CVSS, el sistema estándar de puntuación de vulnerabilidades.¹⁹

Todos los modelos recibieron las mismas instrucciones y definiciones de opciones para una tarea: las definiciones de clase de la FDA, las bandas de gravedad de GitHub y las descripciones de categorías de arXiv. El orden de las opciones se barajaba por elemento y era el mismo para todos los modelos. La gravedad de la vulnerabilidad de seguridad y el nivel de peligro del retiro son las tareas principales, fijadas antes de cualquier ejecución; los temas de artículos y la comprobación de tarea completada son complementarios.

La puntuación es exactitud equilibrada: la tasa de éxito dentro de cada respuesta posible, promediada entre las respuestas.

Un modelo que siempre da la respuesta más común obtiene 25 en gravedad, 33 en retiros y 5 en temas de artículos. La puntuación del gráfico es el promedio de las dos tareas principales, donde esa respuesta obtiene aproximadamente 29. Los intervalos son intervalos bootstrap del 95 % que remuestrean juntos elementos relacionados: avisos del mismo paquete, retiros del mismo evento de retiro y páginas de la misma tarea de navegador.

Dos LLMs, Qwen 3.8 Max y Claude Opus 5.5, etiquetaron una muestra de 350 elementos de prueba, 100 por tarea y 50 páginas de navegador, sin ver la respuesta registrada.

Coincidieron entre sí en 62 de 100 avisos, 69 de 100 retiros, 84 de 100 artículos y 49 de 50 páginas de navegador. Cuando no coincidieron con el registro en avisos y retiros, en su mayoría se desviaron un nivel, hacia los niveles intermedios. Coincidieron con la gravedad de GitHub en 55 y 56 de 100 avisos.

Ambos jueces dieron la misma respuesta, diferente del registro, en 54 elementos. Comprobamos los 53 registros de GitHub, la FDA y arXiv con la fuente en vivo, y todos coincidieron, por lo que no cambió ninguna etiqueta.

La única página de navegador se etiquetó como completada porque el evaluador contó al menos 40 reseñas en la página completa, mientras que la captura que ven los modelos muestra alrededor de nueve. La eliminamos junto con los otros 48 elementos de tarea completada cuya respuesta dependía de contar 10 o más elementos, lo que deja 155.

Los costes locales son válidos para la configuración que probamos en esa GPU; otra configuración de servidor u otra GPU los cambiaría. Entre la ejecución puntuada y la ejecución de costo, CLM-v0.1-8B cambió el 3,7 % de sus respuestas, Shisa DE-1 el 2,2 % y Tev1 0.8B el 1,2 %, por lo que sus costes provienen de una configuración que no reprodujo exactamente sus puntuaciones. Los otros 14 modelos locales cambiaron menos del 1 %.

Excepciones a la ejecución de cada modelo tal como se publicó:

• Laya se ejecutó con un contexto de 8.192 tokens en lugar de los 512 publicados (1.024 para typed-decisions), y Tev1 con 8.194 en lugar de 2.050, igual que en nuestras ejecuciones de navegador.
• Cuando el propio código de Laya habría recortado una opción o entrada larga, nuestro conector rechazaba la solicitud en su lugar, y un rechazo cuenta como una respuesta incorrecta. Todas las solicitudes de temas de artículos fueron rechazadas porque las descripciones de los temas superan los 48 tokens que Laya lee por opción.
• El contexto del codificador de CLM se aumentó de 2.048 a 16.384 tokens; GLiNER se ejecutó más allá de su entrada documentada de 512 tokens. Shisa usó un contexto de 32.768 tokens para caber en la memoria de la GPU.
• No pudimos ejecutar Decision-1.0-Lux-9B: su runtime solo ejecuta este modelo en AMD (ROCm) GPUs, y usamos una NVIDIA GPU.
• Together AI no había publicado una licencia para los pesos de Tev1 antes del 30 de septiembre de 2026.
• El servicio de Cloudflare lee solo los primeros 2.048 tokens del texto del elemento para Clef y Clef-Flash, aunque los modelos aceptan 65.536. Los 12 elementos más largos, 9 de gravedad y 3 de retiros, cuentan como respuestas incorrectas.

Limitaciones

Cada modelo intentó cada tarea de navegador una sola vez, por lo que una diferencia de unas pocas tareas entre dos modelos no demuestra cuál es mejor.

Las 50 tareas provienen de nueve sitios web, y las tareas del mismo sitio comparten diseños de página. Los modelos se ejecutaron en sitios web en vivo, que pueden cambiar entre ejecuciones.

El formato de paso, una lista de operaciones más listas de objetivos, se creó primero para Jev. Todos los modelos recibieron el mismo formato. No probamos si otro formato cambiaría los resultados. Laya se ejecutó con límites de entrada superiores a sus ajustes publicados para que las páginas largas no se cortaran.

En el benchmark de clasificación, cada modelo respondió cada elemento una vez. Las respuestas de GitHub y la FDA son las decisiones registradas de esas instituciones, que pueden basarse en evidencia que el texto del aviso o del retiro no contiene.

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},
  title  = {{AIM-Decision: Jev frente a Kev frente a LLMs}},
  year   = {2026},
  month  = oct,
  howpublished    = {\url{https://aimultiple.com/decision-models}},
  note   = {AIMultiple. Recuperado el 5 de octubre de 2026}
}

Enlaces de referencia

1.

Introducing System One Models & Jev - TypeSafe AI Blog

2.

Introducing Mercury 2.5 – Inception

3.

GitHub - browser-use/jev-ultrafast: Fastest and cheapest web agent · GitHub

4.

Models - TypeSafe AI

Mintlify

5.

fastino/GLiNER2.5-Decide · Hugging Face

6.

Contrastive-LM/CLM-v0.1-8B · Hugging Face

7.

GitHub - Contrastive-LM/CLM · GitHub

8.

GPT-6 Astra - API Pricing & Benchmarks | OpenRouter

OpenRouter

9.

Gemini 3.8 Flash - API Pricing & Benchmarks | OpenRouter

OpenRouter

10.

Kev 4B - API Pricing & Providers | OpenRouter

OpenRouter

11.

jaredpalmer/kev-9b · Hugging Face

12.

jaredpalmer/kev-4b · Hugging Face

13.

bespokelabs/Bespoke-Nimble-9B · Hugging Face

14.

Pricing - Fastino API Docs

Mintlify

15.

clef (Cloudflare) · Cloudflare AI docs · Cloudflare Workers AI docs

Cloudflare

16.

zai-org/GLM-5.3-Flash · Hugging Face

17.

OpenAI Services Agreement | OpenAI

18.

Gemini API Additional Terms of Service  |  Google AI for Developers

19.

GitHub Advisory database - GitHub Docs

Berk Kalelioğlu

Investigador de IA

Síguenos

Berk es Investigador de IA en el equipo de benchmark de AIMultiple, centrándose en IA agéntica, aprendizaje automático y los models de lenguaje grandes y pequeños (LLMs y SLMs).

Ver perfil completo

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.

Nombre

Dirección de correo electrónico

Comentario

0/450

Publicar comentario