Стартап Ван Юньхе запускає NeoHorse — першу модель, нативну для агентів

Після створення бізнесу Ван Юньхе вперше представив результати великої моделі.

Quantum Bit з’ясував, що колишній керівник лабораторії Нойя Huawei, Модель Pangu Засновник YuanYuan Rhythm, Ван Юньхе, представив першу модель, нативну для агентів — NeoHorse.

Модель підтримується нижньою інфраструктурою та технологіями оптимізації Infra від Wuwen Xinqiong, а команди Цинхуа та Пекінського університетів беруть участь у дослідженнях алгоритмів та методів навчання, спільно вивчаючи шляхи підвищення ефективності використання даних та результатів післянавчання агента.

NeoHorse-1 містить дві версії: 4B і 9B, які спеціально розроблені для набору здібностей, необхідних у процесі роботи агентів, включаючи виклик інструментів, читання відгуків середовища, виявлення помилок, коригування шляху та нарешті завершення завдання.

У 10 оцінках, що охоплюють Harness Agent, використання інструментів, код та дотримання інструкцій, після агентного пост-навчання загальна продуктивність моделі 4B досягла/трохи перевищила базову модель 9B.

Чому компанія, яка завжди підкреслювала співпрацю багатомодельних систем, знову почала навчати власні моделі? Чи збирається Primordial Rhythm приєднатися до гри з базовими моделями?

З відповіді NeoHorse видно, що напрямок не змінився таким чином.

Ця модель більше схожа на досвід багатомодельного виконання, накопичений Primordial Rhythm, і вперше потрапила до параметрів моделі.

Завжди балли ставали основним критерієм для порівняння моделей.

Але коли модель починає використовуватися в системі агентів і виконує повні завдання, пояснювальна здатність однієї оцінки знижується.

У завданні модель має не лише надавати здається правдоподібну відповідь, а й постійно отримувати зворотний зв’язок від середовища під час виконання, обробляти помилки та коригувати подальші дії залежно від реального прогресу; різні етапи вимагають різного рівня здібностей моделі.

Таким чином, команда Primordial Rhythm сформувала висновок.

Ненормалізація моделей буде структурою, що триватиме довгий час у індустрії ШІ.

Чим більше моделей і детальніше розподіл обов’язків, тим більш вираженими стають різниці в цінах і здатностях, і тим більше потрібна система, щоб відповісти на кілька питань —

Яку модель слід використовувати на цьому етапі? Які етапи можна передати моделям з нижчою вартістю? Коли потрібно перейти на модель з більш сильними можливостями виведення та виконання? Якщо один шлях виконання заблокований, хто повинен прийняти управління? Чи можуть кілька моделей одночасно пропонувати рішення, а потім результати об’єднуватися?

Команда Ван Юньхе називає цю систему Routing Harness (відповідний відкритий проект OpenSquilla вже інтегрований з кількома моделями, забезпечуючи дрібнозернисту маршрутизацію, переключення моделей та спільну роботу кількох моделей під час виконання агента через єдиний інтерфейс).

Так само, згідно з цією ідеєю, Primitive Rhythm не має сильних підстав для навчання власних моделей. На ринку вже достатньо багато моделей, і виклик їх за потребою здається більш гнучким.

Зі збереженням роботи системи планування, починають накопичуватися інші типи активів, такі як «які завдання вимагають яких здібностей», «на якому етапі модель найчастіше зазнає невдачі», «які шляхи виправлення є ефективними» та «які результати проходять перевірку середовищем».

Ця інформація з одного боку покращує прийняття рішень щодо маршрутизації, а з іншого — починає набувати навчальної цінності.

Це трохи схоже на платформу, яка з’єднує велику кількість брендів і споживачів. Потреби, відгуки та зворотний зв’язок щодо використання, які накопичуються під час торгівлі, можуть допомогти знайти більш відповідних користувачів для продуктів, а також надати додатковий зворотний зв’язок для розробки продуктів.

Процес ринку послуг платформи стає джерелом даних для наступного циклу покращення продукту.

NeoHorse завдання полягає у перетворенні частини досвіду виконання, накопиченого раніше в Harness, у модельні здібності.

Джерело даних NeoHorse варте згадки.

Його основним корпусом є поєднання сигналів виконання агента, згенерованих Routing Harness, з відкритими даними для створення системи даних для післятренування агента.

Агент у Harness після виконання завдання залишає повний журнал виконання.

1. Введення завдання → маршрутизатор визначає, які здібності необхідні
2. → Виберіть певну модель
3. Модель виконує висновки та виклики інструментів
4. → Результати середовища
5. → Модель продовжує виконання або виникає помилка
6. → Система переключає модель або змінює шлях
7. → Завдання завершено або провалено

Дані з питань та відповідей зазвичай зосереджені на обох кінцях — «питання» та «відповідь».

Дані Routing Harness також містять додаткові рівні інформації: які здібності потрібні для завдання, які рішення щодо виконання прийняла система та який фінальний відгук надав оточуючий середовище.

Наприклад, маршрутизатор спочатку вважав, що завдання вимагає лише звичайної моделі, але після послідовних невдач у процесі виконання він перейшов на більш потужну модель, і тільки тоді завдання було завершено.

Цей шлях містить більше інформації, ніж просто невдача.

Система може визначити, чи початкова оцінка здібностей була занадто низькою, на якому етапі виникла проблема з моделлю, яку стратегію використовувала більш потужна модель, який виконавчий шлях успішно пройшов перевірку середовищем, а також скільки додаткових токенів і часу було витрачено на завершення завдання.

Ще важливішим є те, що примітивна динаміка спостерігає не оцінку моделлю власних здібностей, а поперечну продуктивність кількох моделей під час виконання подібних завдань.

У ньому є як успішні шляхи, так і виконавчі записи, які зазнали невдачі по дорозі, а потім були передані іншим моделям.

З точки зору навчання, невдалий шлях може навіть надавати більше інформації.

Остаточна відповідь може повідомити моделі про придатний шлях, тоді як процес невдачі та виправлення додає дві інші категорії знань: де найчастіше виникають помилки та як їх виправляти.

Крім результатів, що надаються кількома моделями, важливо також враховувати шляхи, які ці моделі фактично пройшли в середовищі завдання — це одна з найбільш відмінних рис NeoHorse.

Використання всіх логів для навчання не призведе автоматично до створення сильнішої моделі агента.

Траєкторія агента зазвичай довга і містить системні підказки, запити користувача, параметри інструментів, результати виконання, повторні спроби, повідомлення про помилки та велику кількість проміжних виводів.

Деякі кроки мають навчальну цінність, інші ближчі до шуму. Деякі траєкторії повністю завершені, але сам результат є неправильним.

Примітивний ритм спочатку повинен вирішити питання: «Які дані варто вивчати моделі?»

Згідно з технічним звітом, кожна траєкторія проходить структурну перевірку, щоб переконатися, що запит, відповідь моделі, виклик інструментів і результати середовища відповідають один одному.

Потім система оцінить якість виконання за шістьма аспектами: чи було досягнуто цілі користувача, чи було дотримано інструкцій, чи було раціонально використано інструменти, чи підтверджено висновки доказами, чи можливо відновитися після помилки та чи модель правильно завершила завдання у відповідний момент.

Тут також виникають проблеми, які легко плутаються під час навчання агента.

Завершення завдання не означає, що ціль користувача досягнута — вивід моделі «завдання виконано» може свідчити лише про зупинку виконавчого процесу, але не підтверджує, що результат відповідає вимогам користувача.

Тому статус завершення, рівень досягнення цілей, докази середовища та відгуки користувачів потрібно реєструвати як різні сигнали.

Після завершення фільтрації даних, сигнали маршрутизації починають виконувати іншу функцію.

Роутер оцінює вимоги до здібностей, необхідних для завдання, і формує сигнали різних рівнів здібностей. NeoHorse під час навчання впорядковує зразки відповідно до цього: спочатку вивчає завдання з нижчими вимогами до здібностей, поступово переходячи до більш складних траєкторій виконання, зберігаючи при цьому охоплення базових завдань.

Цей метод називається Routing-Guided Curriculum, тобто маршрутизоване навчання з курсы.

Простіше кажучи, сигнал маршрутизації в онлайн-режимі вирішує, хто виконуватиме завдання, а на етапі навчання може повідомляти модель, які завдання краще вивчати спочатку, а які — пізніше.

Крім звичайного донастройки з наглядом, NeoHorse використовує On-Policy Distillation.

Можна уявити це як те, що спочатку учні розв’язують задачі власним способом, а потім вчитель надає рекомендації, орієнтуючись на ті кроки, які учні вже зробили.

Таким чином, модель-вчитель обробляє проблеми, з якими зіштовхнеться модель-учень у поточному розподілі, а не наперед визначений набір стандартних помилок.

Після цих етапів досвід, накопичений під час довгострокового виконання завдань з використанням багатомодельних систем, почав використовуватися для пост-навчання NeoHorse.

Згідно з результатами, наведеними в поточному технічному звіті, Agentic Post-Training забезпечує стабільне покращення на обох розмірах — 4B і 9B.

При цьому загальна продуктивність NeoHorse-1-4B (средній макро-бал зрос з 58,94 до 64,87) досягла рівня SOTA того ж розміру — вона перевершує свою базову модель Qwen3.5-4B за всіма порівнянними бенчмарками та є лідером серед моделей розміром 4B.

Але SOTA не означає, що здібності рівномірно розподілені.

Детальніший розбір результатів показує, що покращення моделі 4B зосереджене переважно на одному типі завдань.

Ці завдання зазвичай мають відносно чіткий робочий процес, зворотний зв’язок середовища можна спостерігати, успіх і невдачу можна перевірити, а кінцеві стандарти доставки також досить ясні.

Наприклад, у задачі розкладу проекту базова модель, хоча й знайшла файли у робочому каталозі, не продовжила читання листа з останніми обмеженнями залежностей.

В результаті він створив план на основі застарілих даних і зберіг файл у неправильному місці.

Після до навчання модель продовжує аналізувати нові докази, виявляє зміни в обмеженнях, повторно обчислює розклад, перевіряє результати та зберігає вихідні дані у відповідне місце.

Різниця проявляється в ланцюжку виконання агента.

Одна модель приблизно розуміє, як виконувати завдання, інша модель вже може поєднати отримання доказів, оновлення обмежень, виконання, перевірку та доставку в більш повний робочий процес.

Досягнення SOTA на тому ж рівні масштабу не означає, що NeoHorse-1-4B має брати на себе всі завдання. Primitive Rhythm більше зацікавлений у тому, як тонко розділити межі здатностей різних моделей.

Завдання, які можна успішно виконати за допомогою 4B, дозволяють зменшити використання більш масштабних моделей; завдання, які можуть виконати потужніші моделі, не вимагають постійного оновлення до найдорожчої флагманської моделі; коли складність зростає далі, їх передають моделям з більш високими можливостями у пулу.

Тут ідеально пояснюється зв’язок між Routing Harness та власною моделлю.

Модель постійно розширює діапазон витрат на виконання завдань, а система маршрутизації розміщує різні можливості у відповідних місцях залежно від складності завдання та результатів виконання.

Коли йдеться про це, взаємозв’язок між кількома лінійками продуктів Primal Rhythm поступово стає зрозумілим.

Перший рівень — це відкрита версія OpenSquilla.

За допомогою безкоштовних, відкритих, локально розгорнутих і настільних продуктів Primitives Rhythm знижує бар’єри для розробників щодо використання багатомодальних агентів, одночасно з’єднуючи розробників і вхідні точки завдань.

Другий рівень — це TokenRhythm API.

Його позиціонують як «китайську версію OpenRouter», надаючи єдиний інтерфейс для виклику різних моделей, задовольняючи потреби розробників і підприємств у використанні моделей, а також допомагаючи виробникам моделей підключитися до більшої кількості сценаріїв застосування.

Підприємствам не потрібно окремо адаптувати велику кількість інтерфейсів моделей, щоб зручно оцінювати, вибирати та переключати моделі.

Третій рівень — це сервіси та можливості розгортання для бізнесу.

Фінансовий, виробничий та інші сектори мають різні вимоги до прав доступу, стабільності, приватного розгортання та гарантій обслуговування, що створює додаткові комерційні можливості.

Четвертий рівень — це NeoHorse.

NeoHorse спочатку підтвердив ключовий зв’язок: ефективний досвід, що генерується під час виконання Harness, після відбору та навчання, дійсно має шанс бути перетвореним на здатності моделі.

Отже, перший результат на рівні моделі з’явився у бізнес-циклі, запропонованому Primitive Rhythm.

Це також створює можливість оптимізації економічних розрахунків для висновків.

Якщо NeoHorse зможе стабільно приймати серію високочастотних, з чітко визначеними стандартами завдань агента, платформа отримає додаткову здатність до автономного розподілу ресурсів.

Ці завдання можна додатково оптимізувати щодо витрат на обчислення, швидкості відповіді та стабільності, а також забезпечити більш гнучку конфігурацію надання моделей. Зі збереженням подальшої ітерації моделей, діапазон завдань, які вона може охоплювати, також має потенціал для подальшого розширення.

З цієї точки зору те, що Primitive Rhythm хоче зробити, схоже на накопичення технологій у виробничій системі.

Екосистема зовнішніх моделей надає різні можливості, а Harness відповідає за організацію виконання; досвід, набутий у процесі виконання, використовується для наступного покоління покращення моделей.

Від підключення моделей та надання послуг до перетворення досвіду, отриманого в процесі надання послуг, на здібності моделей та подальшого покращення ефективності та якості — це ще один крок, який Primitive Rhythm робить поза межами платформи агрегації API.

Цикли, запропоновані в Primordial Rhythm, можна з’єднати кількома лініями бізнесу:

1. Routing Harness з’єднує розробників із завданнями агента
2. → Модель підключення API TokenRhythm для постачання та виклику запитів
3. → Виконано організацією Harness, накопичення маршрутів та треків завдань
4. → Відібрані траєкторії для навчання моделі
5. → Оновлена модель повертає Harness, участь у завданні адаптації
6. → Покращте досвід виконання завдань, дослідіть кращу швидкість відповіді та ефективність витрат
7. → Постійне використання, оплата та підвищення ефективності бізнесу
8. → Підтримка наступного етапу вдосконалення сервісу та інвестицій у дослідження та розробки

Однією з ключових змін є те, що траєкторії, створені моделлю, більше не обмежуються лише етапами споживання та виклику — вони також можуть стати джерелом для наступного навчання моделі.

Після того як агент виконує завдання, Harness отримує ще одну спостереження щодо меж здібностей.

Певна модель зазнала невдачі, і система знає, де може бути розрив у здібностях; інша модель успішно прийняла завдання, і система отримує новий шлях виправлення; користувач у кінцевому підсумку приймає або відхиляє результат, надаючи додатковий зовнішній відгук.

Чим більше завдань накопичується, тим точнішими можуть бути рішення щодо маршрутизації; після того як маршрутизація стає точнішою, відібрані тренувальні траєкторії стають ближчими до реальних завдань; коли модель краще підходить до завдань, сервіс API отримує можливість забезпечити кращу вартість та досвід.

Якщо цей цикл зможе довготривало підтримуватися, різниця між елементарними ритмами та звичайними агрегаційними платформами API поступово перейде від правил маршрутизації та списків моделей до проектування завдань навчання, методів навчання та параметрів моделей.

Нарешті, це відобразиться у продукті.

Вище наведено контекст початку розмови Primal Rhythm про RSI (Recursive Self-Improvement, рекурсивне самовдосконалення).

Принцип ритму зараз перевіряє діапазон RSI, який ближчий до інженерного замкненого циклу, і його можна розбити на дві частини.

Першим є Data-RSI.

Модель постійно виконує завдання в Harness, і кожен маршрут, виклик інструменту, відновлення після помилки та кінцевий результат генерують нові структуровані записи.

Після фільтрації та обробки цих записів вони можуть бути додані до пулу даних для подальшого навчання. Таким чином, навчальні дані не повинні повністю залежати від попередньої ручної підготовки, а можуть збільшуватися зі збільшенням використання системи.

Другий — Model-RSI.

Система виявляє слабкі місця поточної моделі на основі результатів оцінки, налаштовує розподіл даних для наступного циклу навчання, оновлює модель і знову запускає нову модель у Harness для виконання.

Тобто модель вчиться на досвіді виконання, а оновлена модель через виконання нових завдань генерує нові відгуки для наступного циклу навчання.

Проте, на основі поточної відкритої інформації про NeoHorse цю систему не можна вважати повноцінним RSI.

Поточний технічний звіт підтверджує замкнений цикл «виконання — оцінка — вибір — оновлення». Проектування сигналів, проектування нагород та процес навчання все ще визначаються людиною; чи зможуть моделі після кількох ітерацій продовжувати стабільно отримувати приріст, також потребує додаткового підтвердження експериментами.

Тому більш точним формулюванням буде те, що цей випуск NeoHorse пройшов двохрівневу перевірку.

Перший рівень — це бізнес-аспект: дані, накопичені системою, можуть бути використані для навчання моделей і перетворені на вимірюване підвищення продуктивності.

Інший аспект — технічний: під керівництвом Ван Юньхе команда стартапу провела однокрокову інженерну перевірку у напрямку RSI.

Звичайно, щоб історія про первісний ритм виявилася правдоподібною, потрібно подолати кілька перешкод.

По-перше, чи зможе відкрита екосистема постійно перетворюватися на використання API та дохід.

Друге, чи зможе система постійно отримувати достатню кількість високоякісних траєкторій агента, придатних для навчання, зі збільшенням кількості типів завдань.

Третє, чи зможе покращення здібностей моделі стабільно перетворитися на кращий досвід виконання завдань та ефективність, що далі відобразиться в оперативних даних.

Четверте, як довго буде тривати зростання здібностей після кількох ітерацій моделі.

На ці питання потрібно спостерігати довше.

А ще є ще одна невід’ємна змінна — DeepSeek , Qwen, MiniMax Також провайдери моделей розширюють свої продукти до Harness та Agent, і тенденція вертикальної інтеграції моделей та інфраструктури Agent стає все більш очевидною.

Наприклад, на основі принципу ритму, одна з поточних відмінностей цієї компанії — це нейтральність до моделей та поперечні дані, отримані в процесі виконання між моделями.

Але якщо різниця в здатностях між моделями достатньо велика, міжмодельне планування може стати окремим бізнесом; якщо лідери-моделі поступово охоплюватимуть більше завдань або виробники самі об’єднають маршрутизацію, виклик інструментів та фреймворк агента, простір для проміжного рівня буде скорочуватися.

Коли здатності верхнього рівня стають все сильнішими і дедалі дешевшими, чому цей середній рівень все ще потрібен?

Для Primitive Rhythm NeoHorse принес ще один новий погляд на цей питання.

Раніше він довів, що вміє «використовувати моделі», зараз починає спробувати довести, що дані, накопичені під час тривалого використання моделей, також можуть перетворитися на власні модельні здібності.

Якщо цей шлях вдасться пройти, оборонна лінія Primitive Rhythm буде охоплювати не лише стратегії маршрутизації; якщо ні — він все одно стикнеться з усіма проблемами, з якими зустрічаються всі проміжні шари моделей.

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

Обійми: https://huggingface.co/collections/TokenRhythm/neohorse-1

Цей матеріал зі сторінки WeChat «Quantum Bit», автор: Хеньюй