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

После начала своего предпринимательства Ван Юньхэ впервые представил результаты работы над крупной моделью.

Quantum Bits сообщает, что бывший руководитель лаборатории Ноя Арки Хуавей, Pangu Large Model Основатель YuanYuan Rhythm, Ван Юньхэ, представил первую модель, нативную для агентов — NeoHorse.

Модель поддерживается инфраструктурой и технологиями оптимизации Infra от Wuwen Xinqiong, а команды Тсингхуа и Пекинского университетов участвуют в исследовании алгоритмов и методов обучения, совместно изучая способы повышения эффективности использования данных и результатов пост-обучения агентов.

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

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

Компания, которая всегда подчеркивала сотрудничество нескольких моделей, почему вдруг начала обучать собственные модели? Primal Rhythm собирается присоединиться к игре базовых моделей?

Согласно ответу NeoHorse, направление не изменилось таким образом.

Эта модель впервые интегрировала опыт многомодельного исполнения, накопленный Primordial Rhythm.

Всегда оценки становились основным критерием для сравнения моделей.

Но когда модель начинает использоваться в системе агентов и берет на себя полные задачи, объяснительная сила单一分数 снижается.

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

На основе этого команда Primal 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.

На основе результатов, представленных в текущем техническом отчете, агентное пост-обучение обеспечило стабильное улучшение как на масштабе 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.

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

Второй уровень — это TokenRhythm API.

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

Предприятиям не нужно отдельно адаптировать множество интерфейсов моделей, чтобы удобно оценивать, выбирать и переключать модели.

Третий уровень — это услуги и возможности развертывания для предприятий.

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

Четвертый уровень — это NeoHorse.

NeoHorse сначала подтвердил ключевую связь: эффективный опыт, генерируемый в процессе выполнения Harness, после отбора и обучения действительно может быть преобразован в способности модели.

Таким образом, ранее предложенный бизнес-колесо Primal Rhythm впервые показал результаты на уровне модели.

Это также открывает возможность оптимизации экономики выводов.

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

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

С этой точки зрения, то, что Primitive Rhythm хочет сделать, немного похоже на накопление технологий в производственной системе.

Внешняя экосистема моделей предоставляет различные возможности, а Harness отвечает за организацию и выполнение; опыт, накопленный в процессе выполнения, используется для улучшения следующей версии модели.

От подключения моделей и предоставления услуг до преобразования опыта, полученного в ходе обслуживания, в способности моделей и дальнейшего улучшения эффективности и качества — это еще один шаг, который Primordial Rhythm делает за пределами платформы агрегации API.

Цикл, задуманный в рамках Primal Rhythm, можно примерно связать несколькими бизнес-линиями:

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

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

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

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

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

Если этот цикл сможет сохраняться в долгосрочной перспективе, различия между элементарной динамикой и обычными агрегирующими API-платформами постепенно перейдут от правил маршрутизации и списков моделей к проектированию обучающих задач, методам обучения и параметрам моделей.

Наконец, это будет отражено в производительности продукта.

Выше приведен контекст начала обсуждения RSI (Recursive Self-Improvement, рекурсивное самоусовершенствование) элементом Линейного ритма.

Primal Rhythm currently verifies the RSI range as closer to a closed engineering loop, which can be divided into two parts.

Первый — Data-RSI.

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

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

Второй — Model-RSI.

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

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

Однако, исходя из текущей открытой информации о NeoHorse, эту систему нельзя считать полной RSI.

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

Таким образом, более точным будет сказать, что этот выпуск NeoHorse прошел двухуровневую проверку.

Первый уровень — коммерческий: данные, накопленные системой, могут быть использованы для обучения моделей и преобразованы в измеримое повышение эффективности.

Еще один аспект — технический: под руководством Ван Юньхэ команда стартапа провела однократную инженерную проверку в направлении RSI.

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

Во-первых, сможет ли открытая экосистема постоянно преобразовываться в использование API и доход.

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

В-третьих, после улучшения возможностей модели, можно ли стабильно преобразовать это в лучший опыт выполнения задач и повышенную эффективность, что дополнительно отразится на бизнес-показателях.

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

На эти вопросы нужно больше времени, чтобы наблюдать.

И еще одна неизбежная переменная — DeepSeek 、Qwen、 MiniMax Производители моделей также расширяются в направлении продуктов Harness и Agent, и тенденция к вертикальной интеграции моделей и инфраструктуры Agent становится все более очевидной.

На примере Primal Rhythm, одним из текущих отличий этой компании является нейтральность к моделям и поперечные сравнительные данные, сформированные в процессе выполнения между моделями.

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

Почему этот средний уровень всё ещё нужен, когда верхние возможности становятся всё сильнее и дешевле?

Для Primal Rhythm NeoHorse по крайней мере добавил новый угол зрения на этот вопрос.

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

Если этот путь окажется успешным, защитный барьер Primal Rhythm будет выходить за рамки стратегии маршрутизации; если же он не сработает, он всё равно столкнётся со всеми проблемами, характерными для промежуточных слоёв моделей.

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

Обнимашки: https://huggingface.co/collections/TokenRhythm/neohorse-1

Эта статья взята из официального аккаунта WeChat «Quantum Bit», автор: Хэньюй