La startup de Wang Yunhe lance NeoHorse, premier modèle natif agent

Après avoir créé son entreprise, Wang Yunhe a présenté pour la première fois les résultats de son modèle de grande taille.

Quantum Bits apprend que l'ancien directeur du laboratoire Noah's Ark de Huawei, Pangu Large Model Fondé par Wang Yunhe, Ji Yuan Lü Dong lance son premier modèle Agent-Native, NeoHorse.

Ce modèle est soutenu par des infrastructures de base et des capacités d'optimisation Infra fournies par Wuwen Xianqiong, avec la participation des équipes de l'Université Tsinghua et de l'Université de Pékin à la recherche sur les algorithmes et les méthodes d'entraînement, dans le but commun d'améliorer l'efficacité d'utilisation des données et les résultats de l'entraînement postérieur des agents.

NeoHorse-1 comprend deux versions, 4B et 9B, conçues pour les capacités nécessaires lors du travail des agents, notamment l'appel d'outils, la lecture des retours de l'environnement, la détection d'erreurs, l'ajustement des chemins et la finalisation des tâches.

Dans les 10 évaluations couvrant l'agent Harness, l'utilisation d'outils, le code et le respect des instructions, le modèle 4B, après un post-entraînement agentic, atteint ou dépasse légèrement les performances du modèle de base 9B.

Une entreprise qui a toujours mis l'accent sur la collaboration entre plusieurs modèles, pourquoi commence-t-elle maintenant à entraîner ses propres modèles ? Primer Liveness prépare-t-elle à rejoindre la table des modèles de base ?

Selon la réponse de NeoHorse, la direction n'a pas changé de cette manière.

Ce modèle incorpore pour la première fois les expériences accumulées par Primitive Rhythm dans l'exécution multi-modèles.

Les scores ont toujours été le principal critère de comparaison des modèles.

Mais lorsque le modèle est intégré dans un système d'agent et chargé de tâches complètes, la capacité explicative d'un seul score diminue.

Dans une tâche, le modèle doit non seulement fournir une réponse apparemment raisonnable, mais aussi lire en continu les retours de l’environnement, gérer les erreurs et ajuster les chemins suivants en fonction de l’avancement réel ; les exigences en matière de compétences varient selon les différentes étapes.

Ainsi, l'équipe Primitive Rhythm a établi un jugement.

Le fait que les modèles ne soient pas normalisés sera une structure persistante dans l'industrie de l'IA.

Plus il y a de modèles et plus la répartition des tâches est fine, plus les différences de prix et de capacité deviennent marquées, et plus il est nécessaire d'avoir un système pour répondre à plusieurs questions —

Quel modèle doit être utilisé à cette étape ? Quelles étapes peuvent être confiées à des modèles moins coûteux ? À quel moment faut-il passer à un modèle avec une capacité d'inférence et d'exécution supérieure ? Si un chemin d'exécution est bloqué, qui doit prendre le relais ? Plusieurs modèles peuvent-ils proposer en parallèle des solutions, puis regrouper les résultats ?

L'équipe de Wang Yunhe appelle ce système Routing Harness (le projet open source associé, OpenSquilla, a déjà été intégré à plusieurs modèles, permettant un routage fin, des changements de modèles et une collaboration entre plusieurs modèles pendant l'exécution de l'Agent via une interface unifiée).

De même, en suivant cette logique, Primitive Rhythm n'a pas de raison forte de former ses propres modèles. Le marché propose déjà une offre suffisamment riche de modèles, et les appeler selon les besoins semble plus flexible.

Alors que le système d'ordonnancement continue de fonctionner, une autre catégorie d'actifs commence à s'accumuler, telle que « quels types de tâches nécessitent quelles compétences », « à quel stade les modèles échouent-ils », « quelles voies de correction sont efficaces » et « quels résultats passent la validation de l'environnement ».

Ces informations permettent d'améliorer la prise de décision en matière de routage tout en commençant à acquérir une valeur d'entraînement.

C'est un peu comme une plateforme qui relie un grand nombre de marques à des consommateurs. Les demandes, évaluations et retours d'utilisation accumulés lors des transactions peuvent aider les produits à trouver des utilisateurs plus adaptés, et fournir des retours supplémentaires au développement produit.

Le processus du marché des services de la plateforme devient ainsi une source de données pour la prochaine itération de l'amélioration du produit.

NeoHorse consiste à transformer une partie de l'expérience d'exécution accumulée dans Harness en capacités de modèle.

La source des données de NeoHorse mérite d'être mentionnée.

Son corpus principal consiste à combiner les signaux d'exécution d'agent générés par Routing Harness avec des données publiques pour construire un système de données dédié à l'entraînement post-agent.

Lorsqu'un agent effectue une tâche dans Harness, il laisse un enregistrement complet de l'exécution.

1. Entrer la tâche → Le routeur détermine les compétences nécessaires
2. → Sélectionner un modèle
3. Le modèle effectue une inférence et appelle des outils
4. → Résultat renvoyé par l'environnement
5. → Le modèle continue d'exécuter ou une erreur se produit
6. → Le système bascule sur un modèle ou ajuste le chemin
7. → Tâche terminée ou échouée

Les données de FAQ se concentrent souvent sur les deux extrémités : « question » et « réponse ».

Les données du Routing Harness contiennent également plusieurs autres couches d'informations : les compétences requises par la tâche, les décisions d'exécution prises par le système, et les retours finaux fournis par l'environnement.

Par exemple, le routeur a initialement jugé qu'une tâche nécessitait uniquement un modèle standard, mais après des échecs consécutifs lors de l'exécution, il a été mis à niveau vers un modèle plus puissant, permettant ainsi la réalisation de la tâche.

This trajectory contains far more information than just a failure.

Le système peut déterminer si la jugement initial des capacités était trop faible, à quelle étape le modèle a rencontré un problème, quelle stratégie le modèle plus puissant a adoptée, quel chemin d'exécution a finalement été validé par l'environnement, ainsi que le nombre supplémentaire de tokens et le temps consommés pour accomplir la tâche.

Plus important encore, le rythme fondamental observe non pas un jugement d'un modèle sur ses propres capacités, mais une performance horizontale laissée par plusieurs modèles face à des tâches similaires.

Il existe à la fois des chemins de réussite et des exécutions ayant échoué en cours de route, puis reprises par d'autres modèles.

Du point de vue de l'entraînement, les trajectoires d'échec peuvent même fournir davantage d'informations.

La réponse finale fournit au modèle un chemin viable, tandis que les échecs et les processus de correction complètent deux autres types de connaissances : les endroits où il est facile de faire des erreurs et la manière de les corriger.

Apprendre non seulement les résultats fournis par plusieurs modèles, mais aussi les chemins réels empruntés par ces modèles dans l’environnement de la tâche » est également un point distinctif de NeoHorse.

Ne pas investir tous les journaux dans l'entraînement ne conduira pas naturellement à un modèle d'agent plus puissant.

Les traces d'agent sont généralement longues et contiennent des instructions système, des demandes utilisateur, des paramètres d'outils, des résultats d'exécution, des tentatives répétées, des messages d'erreur et de nombreuses sorties intermédiaires.

Certaines étapes ont une valeur d'entraînement, d'autres sont plus proches du bruit. Certaines trajectoires sont complètes, mais les résultats eux-mêmes ne sont pas corrects.

L'oscillation fondamentale doit d'abord résoudre la question « quels données méritent d'être apprises par le modèle » ?

Selon le rapport technique, chaque trajectoire est soumise à une vérification structurelle pour s'assurer que les demandes, les réponses du modèle, les appels d'outils et les résultats de l'environnement sont cohérents entre eux.

Ensuite, le système évaluera la qualité de l'exécution selon six dimensions : la réalisation de l'objectif de l'utilisateur, le respect des instructions, l'utilisation appropriée des outils, la justification des conclusions par des preuves, la capacité à se rétablir en cas d'erreur, et le moment approprié où le modèle termine la tâche.

Ici, il s'agit également d'un problème souvent confondu dans l'entraînement des agents.

La fin de la tâche ne signifie pas que l'objectif de l'utilisateur a été atteint — la sortie du modèle indiquant « la tâche est terminée » ne montre que l'arrêt du processus d'exécution, sans prouver que le livrable répond aux exigences de l'utilisateur.

Ainsi, l'état d'achèvement, le niveau de satisfaction des objectifs, les preuves environnementales et les retours utilisateurs doivent être enregistrés comme des signaux distincts.

Une fois le filtrage des données terminé, le signal de routage joue un autre rôle.

Le routeur estime les compétences requises pour la tâche et génère des signaux correspondant à différents niveaux de compétence. NeoHorse organise l'ordre des échantillons pendant l'entraînement en commençant par les tâches nécessitant moins de compétences, puis en augmentant progressivement la complexité des trajectoires d'exécution, tout en conservant la couverture des tâches de base.

Cette méthode est appelée Routing-Guided Curriculum, soit l'apprentissage curriculé guidé par le routage.

Pour comprendre simplement, le signal de routage décide en ligne à qui confier la tâche et, pendant la phase d’entraînement, peut indiquer au modèle quelles tâches il est préférable d’apprendre en premier et lesquelles il vaut mieux aborder plus tard.

Outre le fine-tuning supervisé classique, NeoHorse utilise également la distillation on-policy.

On peut le comprendre comme laisser d’abord les élèves résoudre les problèmes à leur manière, puis fournir des conseils par l’enseignant en fonction des étapes réellement atteintes par les élèves.

Ainsi, le modèle enseignant traite les problèmes que le modèle étudiant rencontrera dans sa distribution actuelle, et non un ensemble préétabli d'erreurs standards.

Après ces étapes, l'expérience accumulée au fil de l'exécution de tâches à long terme par des modèles multiples commence à être utilisée pour le post-entraînement de NeoHorse.

Selon les résultats présentés dans le rapport technique actuel, l'Agentic Post-Training apporte une amélioration stable à la fois à l'échelle 4B et à l'échelle 9B.

Parmi ceux-ci, la performance globale de NeoHorse-1-4B (le score moyen macro passant de 58,94 à 64,87) atteint l'état de l'art pour sa taille : elle surpasse son modèle de base Qwen3.5-4B sur tous les benchmarks comparables et est globalement en tête parmi les modèles de taille 4B.

Mais SOTA ne signifie pas que les capacités sont réparties uniformément.

En analysant plus en détail les résultats, on constate que les améliorations du modèle 4B sont principalement concentrées sur un type de tâche.

Ces tâches possèdent généralement un processus de travail relativement clair, des retours d'environnement observables, une vérification du succès ou de l'échec, et des critères de livraison finaux bien définis.

Par exemple, dans une tâche d'établissement d'un calendrier de projet, le modèle de base a bien trouvé les fichiers dans le répertoire de travail, mais n'a pas continué à lire un courriel contenant les dernières contraintes de dépendances.

En conséquence, il a généré un plan selon des informations périmées et a enregistré le fichier à un emplacement incorrect.

Le modèle après entraînement continue d'analyser les nouvelles preuves, détecte les changements dans les contraintes, recalcul les calendriers et valide les résultats, puis enregistre les livrables à l'emplacement approprié.

La différence réside dans la chaîne d'exécution de l'Agent.

Un modèle a une idée générale de la manière dont la tâche devrait être effectuée, tandis qu'un autre modèle parvient déjà à relier de manière cohérente l'acquisition de preuves, la mise à jour des contraintes, l'exécution, la validation et la livraison.

Atteindre l'état de l'art pour une échelle similaire ne signifie pas que NeoHorse-1-4B doit prendre en charge toutes les tâches. Primal Rhythm s'intéresse davantage à la manière de délimiter précisément les limites des capacités de différents modèles.

Les tâches pouvant être effectuées de manière stable par un modèle de 4B peuvent réduire la nécessité d'appeler des modèles plus volumineux ; les tâches pouvant être accomplies par des modèles plus puissants n'ont pas besoin d'être systématiquement transférées au modèle phare le plus coûteux ; lorsque la difficulté augmente encore, elles sont ensuite attribuées aux modèles les plus performants du pool.

Cela relie précisément le Routing Harness au modèle interne.

Le modèle élargit continuellement la plage de coûts des tâches qu'il peut assumer, tandis que le système de routage place les différentes compétences aux emplacements les plus adaptés en fonction de la difficulté et de l'exécution des tâches.

À ce sujet, la relation entre les différentes lignes de produits de Primitive Pulse devient également plus claire.

Le premier niveau est la version open source OpenSquilla.

En offrant des produits gratuits, open source, déployables localement et de bureau, Primitive Pulse réduit la barrière à l'entrée pour les développeurs utilisant des agents multi-modèles, tout en reliant les développeurs aux points d'accès aux tâches.

La couche deux est l'API TokenRhythm.

Il est positionné comme la « version chinoise d'OpenRouter », offrant une interface unifiée pour l'accès à différents modèles, répondant aux besoins des développeurs et des entreprises en matière d'utilisation de modèles, tout en aidant les fabricants de modèles à se connecter à davantage d'applications.

Les entreprises peuvent évaluer, sélectionner et basculer entre des modèles plus facilement sans avoir à adapter séparément de nombreux interfaces de modèles.

Le troisième niveau concerne les services et les capacités de déploiement destinés aux entreprises.

Les secteurs financiers, de la fabrication, etc., ont des exigences différentes en matière d'autorisations, de stabilité, de déploiement privé et de garantie de service, ce qui crée de nouvelles opportunités commerciales.

Le quatrième niveau est NeoHorse.

NeoHorse a d'abord validé une connexion clé : les expériences valides générées pendant l'exécution de Harness, une fois filtrées et entraînées, ont effectivement la possibilité d'être transformées en capacité du modèle lui-même.

Ainsi, le modèle de la roue commerciale proposée précédemment par Primitive Rhythm a produit des résultats au niveau du modèle pour la première fois.

Cela ouvre également la possibilité d'optimiser la comptabilité économique des inférences.

Si NeoHorse parvient à assumer de manière stable un ensemble de tâches d'agent à haut volume et aux critères relativement clairs, la plateforme acquerra une capacité supplémentaire de gestion autonome des ressources.

Ces tâches peuvent être encore optimisées en termes de coût d'inférence, de vitesse de réponse et de stabilité, tout en offrant une plus grande flexibilité dans la configuration des modèles. À mesure que les modèles continuent d'évoluer, leur champ d'application pourra encore s'étendre.

From this perspective, what Primordial Rhythm aims to do is somewhat like the process accumulation in manufacturing systems.

L'écosystème de modèles externes fournit différentes capacités, tandis que Harness est chargé d'organiser et d'exécuter les tâches ; les expériences acquises pendant l'exécution sont ensuite intégrées à la prochaine itération d'amélioration des modèles.

Passer de la connexion de modèles et de la fourniture de services à la transformation des expériences générées par ces services en capacités de modèles, et ainsi améliorer encore l'efficacité et la qualité, représente une étape supplémentaire que Primal Rhythm franchit au-delà de sa plateforme d'agrégation d'API.

Les cycles dans l'idée de Primal Rhythm peuvent être reliés par quelques lignes d'affaires :

1. Routing Harness relie les développeurs aux tâches Agent
2. → Modèle de connexion API TokenRhythm pour l'offre et la demande d'appels
3. → Exécuté par l'organisation Harness, accumulation des itinéraires et des traces de tâches
4. → Les trajectoires disponibles ont été filtrées pour l'entraînement du modèle
5. → Le modèle mis à jour retourne Harness, participe à la tâche d'adaptation
6. → Améliorez l'expérience des tâches, explorez une meilleure vitesse de réponse et une efficacité coûts
7. → Utilisation continue, paiement et amélioration de l'efficacité opérationnelle
8. → Prend en charge l'amélioration des services et les investissements en R&D pour le prochain cycle

L'une des modifications clés réside dans le fait que les trajectoires générées par le modèle ne se limitent plus aux étapes de consommation et d'appel, mais peuvent également devenir une source pour l'entraînement du modèle suivant.

Chaque fois qu'un agent termine une tâche, Harness obtient une nouvelle observation sur les limites de ses capacités.

Un modèle a échoué, le système sait où se trouvent les lacunes de capacité ; un autre modèle a pris le relais avec succès, offrant au système un nouveau chemin de correction ; l'utilisateur accepte ou rejette finalement le résultat, apportant ainsi un retour externe supplémentaire.

Plus il y a de tâches accumulées, plus le routage peut être précis ; une fois le routage plus précis, les trajectoires d'entraînement sélectionnées seront plus proches des tâches réelles ; une fois le modèle mieux adapté aux tâches, le service API aura à nouveau l'occasion d'offrir de meilleurs coûts et une meilleure expérience.

Si ce cycle peut être maintenu à long terme, les différences entre le principe de résonance et les plateformes d'agrégation API classiques s'étendront progressivement des règles de routage et des listes de modèles à la conception des tâches d'entraînement, aux méthodes d'entraînement et aux paramètres du modèle.

Enfin, il sera reflété à travers la performance du produit.

Ci-dessus est le contexte de l'initiation de Primal Rhythm à la discussion sur l'RSI (Recursive Self-Improvement, amélioration récursive de soi).

L'oscillateur RSI actuel vérifie une plage plus proche d'une boucle d'ingénierie fermée, qui peut être décomposée en deux parties.

Le premier est Data-RSI.

Le modèle exécute continuellement des tâches dans Harness ; chaque routage, appel d'outil, récupération en cas d'échec et résultat final génère de nouveaux enregistrements structurés.

Après filtrage et traitement, ces enregistrements peuvent être ajoutés au pool de données pour l'entraînement. Ainsi, les données d'entraînement ne dépendent plus entièrement de la préparation manuelle préalable et peuvent s'enrichir progressivement avec l'utilisation continue du système.

Le deuxième est Model-RSI.

Le système identifie les lacunes des performances du modèle actuel en fonction des résultats de l'évaluation, ajuste la distribution des données d'entraînement pour la prochaine itération, met à jour le modèle, puis le réintègre dans Harness pour exécution.

Autrement dit, le modèle apprend à partir de son expérience d'exécution, et le modèle mis à jour effectue de nouvelles tâches pour générer de nouveaux retours pour la prochaine session d'entraînement.

Cependant, sur la base des informations actuellement publiques concernant NeoHorse, ce système ne peut pas encore être considéré comme un RSI complet.

Le rapport technique confirme actuellement une boucle fermée « exécuter-évaluer-sélectionner-mettre à jour ». La conception des signaux, la conception des récompenses et le processus d'entraînement sont toujours déterminés par des humains ; il faut davantage d'expériences pour confirmer si les gains stables peuvent être maintenus après plusieurs itérations de modèles.

Ainsi, la formulation la plus précise est que cette publication de NeoHorse a accompli deux niveaux de vérification.

Le premier niveau est commercial : les données accumulées par le système peuvent être utilisées pour l'entraînement des modèles et se traduire par une amélioration mesurable des performances.

Un autre niveau est technique : sous la direction de Wang Yunhe, l'équipe d'entrepreneurs a mené avec succès une validation technique unique orientée vers la direction RSI.

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

First, can the open-source ecosystem continue to be converted into API usage and revenue?

Deuxièmement, à mesure que le nombre de types de tâches augmente, le système peut-il continuer à obtenir suffisamment de trajectoires d'agent de haute qualité, utilisables pour l'entraînement.

Troisièmement, une fois les capacités du modèle améliorées, pourra-t-il se traduire de manière stable par une meilleure expérience et une efficacité d'exécution des tâches, et cela se reflétera-t-il davantage dans les données opérationnelles ?

Quatrièmement, après plusieurs itérations du modèle, pendant combien de temps les gains de capacité persisteront-ils ?

Ces questions nécessitent une observation plus longue.

Et il y a encore une variable incontournable — DeepSeek 、Qwen、 MiniMax Les fabricants de modèles s'étendent également vers les produits Harness et Agent, et la tendance à l'intégration verticale des modèles et de l'infrastructure Agent devient de plus en plus évidente.

À titre d'exemple de l'oscillation des éléments de base, l'un des avantages actuels de cette entreprise est la neutralité des modèles ainsi que les données de comparaison horizontale générées lors de l'exécution entre modèles.

Mais si les différences de capacité entre les modèles sont suffisamment importantes, l'ordonnancement inter-modèles pourrait devenir un métier indépendant ; si les modèles leaders couvrent progressivement davantage de tâches, ou si les fabricants intègrent eux-mêmes le routage, l'appel d'outils et le cadre Agent, l'espace laissé aux couches intermédiaires sera réduit.

Lorsque les capacités en amont deviennent de plus en plus puissantes et moins chères, pourquoi cette couche intermédiaire doit-elle encore exister ?

Pour Primitive Rhythm, NeoHorse apporte au moins une nouvelle perspective à cette question.

Autrefois, il a prouvé qu'il savait « utiliser des modèles » ; maintenant, il commence à essayer de démontrer que les données accumulées par une utilisation prolongée des modèles peuvent également se transformer en capacité de modèle propre.

Si ce chemin aboutit, le fossé compétitif de Primitive Rhythm ne se limitera pas à la stratégie de routage ; s'il échoue, il devra toujours faire face aux problèmes communs à toutes les couches intermédiaires de modèles.

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

Bonne chance : https://huggingface.co/collections/TokenRhythm/neohorse-1

Cet article provient du compte WeChat « Quantum Bit », auteur : Heng Yu