Axion 1.0-35B obtiene un 52,2% en HLE y sus creadores publican el código de entrenamiento del agente

Si tu agente debe encontrar información en varias fuentes, contrastarla y calcular una respuesta, no basta con conectarle una herramienta de búsqueda. También hay que enseñar al modelo a utilizar lo que encuentra. Axion 1.0 ofrece una receta abierta para ese entrenamiento. Para los desarrolladores, es una oportunidad de estudiar la preparación de los datos y probar el enfoque en sus propias tareas.

El proyecto presenta una cifra llamativa: Axion 1.0-35B obtuvo un 52,2% en Humanity’s Last Exam con herramientas. Pero para un equipo que está desarrollando un producto, resulta más útil otra pregunta: ¿qué partes de ese resultado se pueden reproducir y cuánto costarán en su caso de uso?

Qué se ha publicado exactamente

Según el repositorio del proyecto, el modelo más pequeño tiene 35.000 millones de parámetros, de los cuales 3.000 millones están activos durante el cálculo. Allí se publican el código de generación y filtrado de datos, las instrucciones, el entrenamiento y la evaluación. Sin embargo, el README remite a una reproducción comunitaria de los pesos y aclara expresamente que no se trata de un checkpoint oficial de Axion. La promesa de «descargar el modelo de los autores y reproducir el resultado» todavía requiere una verificación independiente.

El entrenamiento consta de dos etapas con ejemplos preparados y una etapa de aprendizaje por refuerzo. Primero, el modelo resuelve tareas con la información disponible en el enunciado; después aprende a obtener los datos que faltan mediante herramientas. En la última etapa recibe recompensas por el resultado y por avances intermedios verificables. Esta secuencia se describe en el artículo de los autores.

El interés práctico está en poder analizar el proceso por partes. Por ejemplo, a un equipo podría resultarle más útil el método para reunir tareas verificables que el propio modelo. Esto es especialmente pertinente si el agente ya sabe invocar herramientas, pero selecciona con frecuencia datos incorrectos para los cálculos.

Cómo se aplica a una tarea real

Imaginemos un asistente de compras. Debe elegir al proveedor con el menor coste total del pedido que cumpla un plazo de entrega determinado. Tiene que buscar ofertas, comprobar la disponibilidad, convertir los precios a una misma moneda y sumar los gastos de envío. Una respuesta bien redactada no sirve de nada si el agente ha comparado configuraciones de producto distintas.

Para entrenar a ese asistente, se puede preparar de antemano una tabla de ofertas y calcular mediante código la opción correcta. Después, se proporciona al modelo únicamente la pregunta y acceso a las fuentes autorizadas. Se guarda la solución correcta junto con la secuencia de acciones. Es un ejemplo de cómo trasladar la idea de las tareas verificables a un producto; los autores no afirman disponer de un agente de compras listo para usar.

Conviene comprobar algo más que el importe final. ¿Se ha elegido la configuración correcta? ¿Se cumplen los plazos? ¿Se ha incluido el envío? Estas comprobaciones intermedias ayudan a identificar el punto exacto en el que falla la cadena. Si la respuesta correcta se ha obtenido por casualidad, es preferible no considerar ese ejemplo una muestra de funcionamiento fiable.

Se puede empezar sin entrenar un modelo propio. Reúne un pequeño conjunto de consultas habituales, deja registradas las fuentes y las respuestas correctas, y pon a prueba al agente actual. Este paso ya mostrará qué le falta: capacidad de búsqueda, de cálculo o de comprensión de los requisitos. Después será más fácil decidir si hace falta un nuevo conjunto de datos.

Por qué un 52,2% no basta para elegir un modelo

En la descripción de la evaluación, los autores presentan el mejor resultado de una ejecución individual, no la media. Para la evaluación principal de HLE se restringe el acceso a determinados sitios web. Algunos resultados de competidores proceden de informes externos, por lo que las condiciones de comparación no coinciden por completo. La igualdad con GPT-5.5 en la tabla no puede extrapolarse a todas las tareas reales.

Tener 3.000 millones de parámetros activos tampoco significa que baste con la memoria necesaria para alojar un modelo convencional de ese tamaño. Hay que tener en cuenta todos los pesos, el contexto y el método de ejecución elegido. Además, el coste de una tarea resuelta incluye las búsquedas, la ejecución de código y los reintentos.

En una prueba piloto, compararía Axion con la solución actual usando las mismas herramientas y los mismos límites. Mediría la proporción de respuestas correctas, el tiempo de ejecución y el coste por tarea completada. También comprobaría por separado los casos con una fuente inaccesible o datos contradictorios. Si la ventaja se mantiene en esas condiciones, habría motivos para plantearse su implantación. Por ahora, la principal aportación práctica de este lanzamiento es un proceso de entrenamiento de agentes disponible para su estudio.