La startup de Wang Yunhe lanza NeoHorse, el primer modelo nativo de agente

Después de emprender, Wang Yunhe presentó por primera vez los resultados de su modelo de gran tamaño.

Quantum Bit informa que el exdirector del Laboratorio Noah's Ark de Huawei, Modelo Pangu Yuan Yuan Lüdong, fundada por el director Wang Yunhe, lanza su primer modelo nativo de agente, NeoHorse.

El modelo cuenta con el soporte de infraestructura y capacidades de optimización de Infra proporcionadas por Wuwen Xianqiong, con la participación de los equipos de la Universidad de Tsinghua y la Universidad de Pekín en la investigación de algoritmos y métodos de entrenamiento, explorando conjuntamente formas de mejorar la eficiencia en el uso de datos y los resultados del entrenamiento posterior del agente.

NeoHorse-1 incluye dos versiones, 4B y 9B, diseñadas especialmente para un conjunto de capacidades necesarias durante el proceso de los Agentes, como llamar herramientas, leer retroalimentación del entorno, detectar errores, ajustar rutas y finalizar tareas.

En 10 evaluaciones que cubren Agentic Agent, uso de herramientas, código y cumplimiento de instrucciones, el modelo de 4B después del Agentic Post-Training alcanza o supera ligeramente el rendimiento general del modelo base de 9B.

¿Por qué una empresa que siempre ha enfatizado la colaboración entre modelos comienza a entrenar sus propios modelos? ¿Está Primordial Rhythm lista para unirse a la mesa de modelos base?

Según la respuesta de NeoHorse, la dirección no ha cambiado de esta manera.

Este modelo incorpora por primera vez la experiencia acumulada en la ejecución de múltiples modelos de Primitive Rhythm.

Durante mucho tiempo, las puntuaciones han sido el principal criterio para comparar modelos.

Pero cuando los modelos comienzan a integrarse en sistemas de agentes y asumen tareas completas, la capacidad explicativa de una sola puntuación disminuye.

En una tarea, el modelo no solo debe proporcionar una respuesta que parezca razonable, sino también leer continuamente las retroalimentaciones del entorno durante la ejecución, manejar errores y ajustar los caminos siguientes según el progreso real; los distintos componentes requieren diferentes capacidades del modelo.

Por lo tanto, el equipo de Primal Rhythm llegó a una conclusión.

Que los modelos no estén normalizados será una estructura persistente en la industria de la IA.

Cuanto más modelos haya y más especializada sea la división del trabajo, más marcadas serán las diferencias en precio y capacidad, y más necesaria será una sistema que responda varias preguntas—

¿Qué modelo debería usarse en este paso? ¿Qué etapas pueden delegarse a modelos de menor costo? ¿Cuándo es necesario actualizar a un modelo con mayor capacidad de inferencia y ejecución? ¿Quién debería tomar el relevo si una ruta de ejecución se bloquea? ¿Pueden varios modelos generar soluciones en paralelo y luego consolidar los resultados?

El equipo de Wang Yunhe denomina a este sistema Routing Harness (el proyecto de código abierto relacionado, OpenSquilla, ya se ha integrado con varios modelos, permitiendo enrutamiento fino, cambio de modelos y colaboración entre múltiples modelos durante la ejecución del Agent).

De la misma manera, basándose en esta idea, Primitive Rhythm parece no tener una razón sólida para entrenar sus propios modelos. Ya existe una oferta suficientemente rica de modelos en el mercado, y llamarlos según sea necesario parece más flexible.

A medida que el sistema de programación continúa funcionando, otro tipo de activos comienza a acumularse, como “¿qué tareas requieren qué habilidades?”, “¿en qué paso falla fácilmente el modelo?”, “¿qué rutas de reparación son efectivas?” y “¿qué resultados pueden pasar la validación del entorno?”.

Esta información, por un lado, puede mejorar el juicio de enrutamiento y, por otro, comienza a tener valor de entrenamiento.

Es un poco como una plataforma que conecta una gran cantidad de marcas con consumidores. La demanda, las reseñas y los comentarios de uso acumulados durante las transacciones pueden ayudar a que los productos encuentren usuarios más adecuados, y también pueden retroalimentarse en el desarrollo del producto.

El proceso del mercado de servicios de la plataforma se convierte así en una fuente de datos para la próxima iteración de mejora del producto.

NeoHorse se encarga de transformar parte de la experiencia de ejecución acumulada en Harness en capacidades del modelo.

La fuente de datos de NeoHorse es digna de mención.

Su corpus principal consiste en combinar las señales de ejecución de agente generadas por Routing Harness con datos públicos para construir un sistema de datos orientado al entrenamiento posterior del agente.

Cuando un agente completa una tarea en Harness, deja un registro completo de la ejecución.

1. Ingresar tarea → El enrutador determina qué habilidades se necesitan
2. → Seleccionar un modelo
3. El modelo realiza inferencia y llamadas a herramientas
4. → Resultado devuelto por el entorno
5. → El modelo continúa ejecutándose o se produce un error
6. → El sistema cambia de modelo o ajusta la ruta
7. → La tarea se completó o falló finalmente

Los datos de preguntas frecuentes suelen centrarse en los extremos de "pregunta" y "respuesta".

Los datos de Routing Harness también contienen otras capas de información: qué capacidades requiere la tarea, qué decisiones de ejecución tomó el sistema y qué retroalimentación proporcionó finalmente el entorno.

Por ejemplo, el enrutador inicialmente determina que una tarea requiere solo un modelo estándar, pero tras fallos consecutivos durante la ejecución, se actualiza a un modelo más potente, lo que permite completar la tarea.

This trajectory contains far more information than just a failure.

El sistema puede saber que la evaluación inicial de la capacidad podría haber sido demasiado baja, en qué paso surgió el problema con el modelo, qué estrategia adoptó el modelo más potente, qué ruta de ejecución finalmente pasó la validación del entorno, y cuántos tokens y tiempo adicionales se consumieron para completar la tarea.

Un punto más importante es que el ritmo primordial observa no el juicio de un solo modelo sobre sus propias capacidades, sino el rendimiento transversal dejado por múltiples modelos frente a tareas similares.

Incluye tanto rutas exitosas como registros de ejecución que fallaron en el camino y luego fueron asumidos por otros modelos.

Desde la perspectiva del entrenamiento, las trayectorias fallidas incluso podrían proporcionar más información.

La respuesta final puede indicar al modelo una ruta viable, mientras que los procesos de fallo y reparación complementan otros dos tipos de conocimiento: dónde es fácil cometer errores y cómo ajustarse tras ellos.

Además de los resultados proporcionados por múltiples modelos, también se aprenden las rutas reales recorridas por estos modelos en el entorno de la tarea, lo cual es uno de los aspectos más distintivos de NeoHorse.

Invertir todos los registros en el entrenamiento no conducirá naturalmente a un modelo de agente más fuerte.

La trayectoria del agente suele ser muy larga, y contiene indicaciones del sistema, solicitudes del usuario, parámetros de herramientas, resultados de ejecución, intentos repetidos, mensajes de error y una gran cantidad de salidas intermedias.

Algunos pasos tienen valor de entrenamiento, otros son más cercanos al ruido. Además, algunas trayectorias son completas, pero los resultados en sí mismos no son correctos.

El ritmo primordial primero debe abordar la pregunta: "¿Qué datos merecen que el modelo los aprenda?"

Según el informe técnico, cada trayectoria pasa por una verificación estructural para confirmar que la solicitud, la respuesta del modelo, la llamada a la herramienta y los resultados del entorno coincidan.

Luego, el sistema evaluará la calidad de la ejecución en seis dimensiones: si se cumplió el objetivo del usuario, si se respetaron las instrucciones, si el uso de herramientas fue razonable, si las conclusiones están respaldadas por evidencia, si se pudo recuperar tras un error y si el modelo finalizó la tarea en el momento adecuado.

Aquí también se incluyen problemas que suelen confundirse en el entrenamiento de Agentes.

Finalizar la tarea no equivale a que el objetivo del usuario haya sido satisfecho: que el modelo indique "tarea completada" solo significa que el proceso de ejecución se detuvo, pero no demuestra que el resultado cumpla con los requisitos del usuario.

Por lo tanto, el estado de finalización, el grado de cumplimiento de los objetivos, las pruebas del entorno y los comentarios del usuario deben registrarse como señales distintas.

Una vez completada la filtración de datos, la señal de enrutamiento comienza a desempeñar otro papel.

El router estima las capacidades requeridas para la tarea y genera señales en diferentes niveles de capacidad. NeoHorse organiza el orden de los ejemplos durante el entrenamiento según esto, comenzando con tareas que requieren menos capacidad y aumentando gradualmente la complejidad de las trayectorias de ejecución, mientras mantiene la cobertura de las tareas básicas.

Este método se denomina Routing-Guided Curriculum, es decir, aprendizaje curricular guiado por enrutamiento.

En términos más sencillos, la señal de enrutamiento decide en línea qué tarea se asigna a quién, y durante la fase de entrenamiento puede indicar al modelo qué tareas son más adecuadas para aprender primero y cuáles mejor para después.

Además del ajuste fino supervisado convencional, NeoHorse también utiliza la destilación on-policy.

Se puede entender como permitir primero que los estudiantes resuelvan los problemas a su manera, y luego que el profesor les brinde orientación basada en los pasos reales que han seguido.

De esta manera, el modelo docente aborda los problemas que el modelo estudiante encontrará en su distribución actual, en lugar de un conjunto predefinido de errores estándar.

Tras estos procesos, la experiencia acumulada en tareas de ejecución prolongada con múltiples modelos comienza a utilizarse en el postentrenamiento de NeoHorse.

Según los resultados presentados en el informe técnico actual, el Agentic Post-Training proporciona mejoras estables en ambas escalas de 4B y 9B.

Entre ellos, el rendimiento general de NeoHorse-1-4B (la puntuación promedio macro aumentó de 58.94 a 64.87) ya alcanza el SOTA de su tamaño: supera a su modelo base Qwen3.5-4B en todos los benchmarks comparables y lidera en conjunto entre los modelos de 4B de tamaño similar.

Pero SOTA no significa que la capacidad esté distribuida uniformemente.

Al desglosar los resultados con mayor detalle, se puede ver que la mejora del modelo 4B se concentra principalmente en un tipo de tarea.

Este tipo de tareas generalmente tiene un flujo de trabajo relativamente claro, los comentarios del entorno pueden observarse, el éxito y el fracaso pueden verificarse, y los criterios de entrega final también son bastante claros.

Por ejemplo, en una tarea de programación de un proyecto, el modelo base encontró los archivos en el directorio de trabajo, pero no continuó leyendo un correo que contenía las restricciones de dependencia más recientes.

Como resultado, generó el plan según información que ya había expirado y guardó el archivo en la ubicación incorrecta.

El modelo después del entrenamiento continuará leyendo nuevas evidencias, detectará que los requisitos han cambiado, recalculará la programación, validará los resultados y guardará los entregables en la ubicación correcta.

La diferencia se manifiesta en la cadena de ejecución del agente.

Un modelo tiene una idea general de cómo debe realizarse la tarea, mientras que otro modelo ya puede encadenar de manera más completa el flujo de trabajo que incluye obtener evidencia, actualizar restricciones, ejecutar, validar y entregar.

Alcanzar el SOTA del mismo tamaño no significa que NeoHorse-1-4B deba asumir todas las tareas. Primal Rhythm se centra más en cómo delimitar con precisión los límites de capacidad de diferentes modelos.

Las tareas que pueden completarse de forma estable con un modelo de 4B pueden reducir la necesidad de llamar a modelos más grandes; las tareas que pueden realizarse con modelos más potentes no requieren actualizaciones constantes al modelo insignia más caro; cuando la dificultad siga aumentando, se asignarán a modelos con mayor capacidad dentro del conjunto de modelos.

Aquí se conecta perfectamente la relación entre Routing Harness y el modelo desarrollado internamente.

El modelo continúa ampliando el rango de costos de las tareas que puede asumir, y el sistema de enrutamiento coloca las distintas capacidades en las posiciones adecuadas según la dificultad de la tarea y su ejecución.

At this point, the relationship between the various product lines of Primal Rhythm has also become clearer.

La primera capa es la versión abierta de OpenSquilla.

Primitives Pulse reduce la barrera de entrada para que los desarrolladores utilicen Agentes de múltiples modelos mediante productos gratuitos, de código abierto, de implementación local y de escritorio, conectando al mismo tiempo a los desarrolladores con los puntos de entrada de tareas.

La segunda capa es la API de TokenRhythm.

Su posición es similar a la de "OpenRouter versión china", que proporciona capacidades de llamada a diferentes modelos a través de una interfaz unificada, satisfaciendo las necesidades de desarrollo y empresariales de uso de modelos, al mismo tiempo que ayuda a los fabricantes de modelos a conectar más escenarios de aplicación.

Las empresas pueden evaluar, seleccionar e intercambiar modelos con mayor facilidad sin necesidad de adaptar por separado numerosas interfaces de modelos.

La tercera capa es el servicio y la capacidad de implementación orientados a empresas.

Los sectores financieros, manufactureros y otros tienen diferentes requisitos en cuanto a permisos, estabilidad, despliegue privado y garantía de servicio, lo que genera espacios comerciales adicionales.

La cuarta capa es NeoHorse.

NeoHorse primero verificó una conexión clave: las experiencias válidas generadas durante la ejecución de Harness, tras ser filtradas y entrenadas, realmente tienen la posibilidad de convertirse en capacidades del modelo mismo.

Así, el modelo de la rueda comercial propuesta previamente por Primitive Rhythm mostró resultados a nivel de modelo por primera vez.

Esto también abre la posibilidad de optimizar la contabilidad económica del razonamiento.

Si NeoHorse logra establecerse posteriormente como un receptor estable de una serie de tareas de Agent de alta frecuencia y con criterios relativamente claros, la plataforma adquirirá una capacidad adicional de suministro de recursos que puede gestionar de forma autónoma.

Estas tareas pueden optimizarse aún más en términos de costo de inferencia, velocidad de respuesta y estabilidad, y también permiten una configuración más flexible de la oferta de modelos. A medida que los modelos sigan iterando, su alcance de tareas cubiertas aún tiene margen para ampliarse.

Desde este punto de vista, lo que Primitive Rhythm intenta hacer es un poco como la acumulación de procesos en la manufactura.

El ecosistema de modelos externos proporciona distintas capacidades, mientras que Harness se encarga de organizar y ejecutar; la experiencia adquirida durante la ejecución se incorpora en la siguiente ronda de mejora del modelo.

Desde conectar modelos y proporcionar servicios, hasta transformar la experiencia generada en esos servicios en capacidades del modelo y mejorar aún más la eficiencia y la calidad, esto representa un paso adicional que Primal Rhythm da más allá de la plataforma de agregación de API.

Los ciclos en la idea de Primal Rhythm se pueden conectar aproximadamente con varias líneas de negocio:

1. Routing Harness conecta a los desarrolladores con tareas de Agent
2. → Modelo de conexión API de TokenRhythm para suministro y demanda de llamadas
3. → Ejecutado por Harness, acumulación de rutas y trayectorias de tareas
4. Las trayectorias disponibles han sido filtradas para el entrenamiento del modelo
5. → El modelo actualizado devuelve Harness, participa en la tarea de adaptación
6. → Mejora la experiencia de la tarea, explora una mayor velocidad de respuesta y eficiencia de costos
7. → Uso continuo, pago y mejora de la eficiencia operativa
8. → Apoyar la próxima ronda de mejora del servicio e inversión en I+D

Uno de los cambios clave es que las trayectorias generadas por el modelo ya no se limitan a los procesos de consumo y llamada, sino que también pueden convertirse en fuente para el próximo ciclo de entrenamiento del modelo.

Cada vez que el agente completa una tarea, Harness obtiene una observación adicional sobre los límites de su capacidad.

Un modelo falló, y el sistema sabe dónde podría estar la brecha de capacidad; otro modelo asumió con éxito el control, y el sistema obtuvo una nueva ruta de corrección; el usuario finalmente acepta o rechaza el resultado, proporcionando una capa adicional de retroalimentación externa.

Cuanto más acumules tareas, más preciso puede volverse el enrutamiento; una vez que el enrutamiento sea más preciso, las trayectorias de entrenamiento seleccionadas también se acercarán más a las tareas reales; y cuando el modelo sea más adecuado para las tareas, el servicio API tendrá la oportunidad de ofrecer mejores costos y experiencias.

Si este ciclo puede mantenerse a largo plazo, la diferencia entre el pulso primordial y las plataformas convencionales de agregación de API también evolucionará gradualmente desde reglas de enrutamiento y listas de modelos hacia el diseño de tareas de entrenamiento, métodos de entrenamiento y parámetros del modelo.

Finalmente, se manifestará a través del rendimiento del producto.

Lo anterior es el contexto en el que Primal Rhythm comienza a hablar sobre el RSI (Recursive Self-Improvement, mejora automática recursiva).

El ritmo primordial actualmente verifica el rango del RSI, que se asemeja más a un ciclo de ingeniería cerrado y se puede dividir en dos partes.

El primero es Data-RSI.

El modelo ejecuta tareas continuamente en Harness, y cada enrutamiento, llamada a herramienta, recuperación de fallos y resultado final genera un nuevo registro estructurado.

Después de ser filtrados y procesados, estos registros pueden ingresarse al conjunto de datos para el entrenamiento posterior. Por lo tanto, los datos de entrenamiento no necesitan depender completamente de la preparación manual previa, sino que pueden aumentar con el uso continuo del sistema.

El segundo es Model-RSI.

El sistema identifica las debilidades del modelo actual según los resultados de la evaluación, ajusta la distribución de los datos de entrenamiento para la próxima ronda, actualiza el modelo y vuelve a colocar el nuevo modelo en Harness para su ejecución.

Es decir, el modelo aprende de la experiencia de ejecución, y el modelo actualizado realiza nuevas tareas para generar nuevos comentarios para la próxima ronda de entrenamiento.

Sin embargo, con la información actualmente pública de NeoHorse, aún no se puede considerar este sistema como un RSI completo.

El informe técnico actual valida un ciclo cerrado de "ejecución-evaluación-selección-actualización". El diseño de señales, el diseño de recompensas y el proceso de entrenamiento siguen siendo establecidos por humanos, y se necesitan más experimentos para confirmar si los modelos de múltiples generaciones pueden seguir obteniendo mejoras estables.

Por lo tanto, una expresión más precisa es que este lanzamiento de NeoHorse completó dos capas de verificación.

La primera capa es comercial: los datos acumulados por el sistema pueden ingresarse en el entrenamiento del modelo y convertirse en mejoras medibles de capacidad.

Otro nivel es técnico: Wang Yunhe lideró al equipo de emprendedores para completar una verificación de ingeniería única orientada hacia la dirección RSI.

Of course, for the story of Primal Rhythm to hold, it still needs to overcome several hurdles.

Primero, ¿puede el ecosistema de código abierto convertirse continuamente en uso de API e ingresos?

En segundo lugar, a medida que aumentan los tipos de tareas, el sistema puede seguir obteniendo suficientes trayectorias de agente de alta calidad para el entrenamiento.

Tercero, una vez mejoradas las capacidades del modelo, ¿pueden convertirse de forma estable en una mejor experiencia y eficiencia en la ejecución de tareas, y reflejarse aún más en los datos operativos?

Cuarta, ¿cuánto tiempo seguirá aumentando la capacidad después de múltiples iteraciones del modelo?

These questions require more time to observe.

Y también hay otra variable inevitable: DeepSeek 、Qwen、 MiniMax Los proveedores de modelos también están extendiéndose hacia los productos Harness y Agent, y la tendencia hacia la integración vertical de modelos e infraestructura de Agentes se vuelve cada vez más evidente.

Tomando como ejemplo el principio de ritmo, una de las diferencias actuales de esta empresa es la neutralidad del modelo y los datos de comparación horizontal generados durante la ejecución entre modelos.

Pero si la diferencia de capacidad entre los modelos es lo suficientemente grande, la programación entre modelos podría convertirse en un negocio independiente; si los modelos líderes van cubriendo progresivamente más tareas, o si los fabricantes integran ellos mismos el enrutamiento, la llamada a herramientas y el marco de agentes, el espacio disponible para la capa intermedia se reducirá.

Cuando las capacidades de la capa superior se vuelven cada vez más fuertes y más baratas, ¿por qué aún necesita existir esta capa intermedia?

Para Primitive Rhythm, NeoHorse al menos añade una nueva perspectiva a este problema.

Antes demostró que sabía "usar modelos"; ahora comienza a intentar demostrar que los datos acumulados con el uso prolongado de modelos también pueden consolidarse como capacidad modelada propia.

Si este camino tiene éxito, la ventaja competitiva de Elemental Rhythm no se limitará a la estrategia de enrutamiento; si no tiene éxito, aún deberá enfrentar los problemas comunes a todos los niveles intermedios de los modelos.

GitHub: https://github.com/TokenRhythm/NeoHorse

Abrazo facial: https://huggingface.co/collections/TokenRhythm/neohorse-1

Este artículo proviene del canal de WeChat "Quantum Bit", autor: Heng Yu