Иван Никитин, генеральный директор и сооснователь Fortytwo — интервью

Иван Никитин — генеральный директор и сооснователь Fortytwo, где он разрабатывает технологию роевого инференса, которая объединяет несколько моделей ИИ, чтобы они рассуждали и оценивали работу друг друга. Его опыт охватывает игры, разговорный ИИ, генеративный ИИ и интерактивные системы, над которыми он работал в Temporal и Sensorium. В 2011 году он вместе с Владом Лариным основал Temporal; теперь Ларин — сооснователь и технический директор Fortytwo. Там Никитин получил опыт работы с развивающимися популяциями агентов и системами, объединяющими специализированные модели.

Fortytwo создает инфраструктуру для ИИ, которая позволяет моделям взаимодействовать во время инференса. В Fortytwo Engine используется Swarm Decoder, который направляет общий процесс рассуждения по мере его развития, стремясь повысить точность и сократить ненужную генерацию токенов при решении продолжительных задач. Компания предлагает разработчикам API через Fortytwo Engine, а также возможность развертывания решений на собственной инфраструктуре заказчика через Fortytwo Harbor.

До основания Fortytwo вы несколько лет создавали продукты на основе разговорного ИИ, генеративного ИИ и интерактивных систем в Sensorium и Temporal. Как этот опыт повлиял на ваше представление о слабых сторонах отдельных больших языковых моделей и в конечном итоге привел вас к роевому подходу, лежащему в основе Fortytwo?

Многие в нашей команде, в том числе и я, пришли в ИИ через игры. Игры стали колыбелью персональных компьютеров и современного ИИ: именно благодаря им появились графические процессоры, а игровые задачи стали первой серьезной испытательной площадкой для обучения с подкреплением. Игровые миры дали нам практическую среду для создания агентов, способных учиться, адаптироваться и соревноваться. В Temporal, которую я основал в 2011 году вместе с Владом Лариным, ныне сооснователем и техническим директором Fortytwo, мы начали с идеи развивающегося интеллекта: популяций агентов, соперничающих в условиях давления отбора. Нас интересовало, как популяция может добиться большего, чем отдельный агент, если есть эффективный механизм выявления наиболее ценных достижений и развития на их основе. Отбор и оценка стали центральными элементами нашего подхода к интеллекту.

Когда появились модели-трансформеры, мы расширили работу на область разговорного ИИ и создали платформу с персонажами на базе ИИ, способными вести открытые, не ограниченные сценарием беседы, обладая памятью и индивидуальностью. Это было за пару лет до появления ChatGPT, а у моделей, с которыми мы работали, контекстное окно составляло всего от 512 до 1 024 токенов. Рассчитывать, что одна ранняя языковая модель сможет надежно справляться со всеми разнообразными требованиями такого взаимодействия, было невозможно. Нам пришлось создать собственный конвейер из специализированных моделей, каждая из которых отвечала за более узкую задачу, а также разработать логику объединения их результатов. Ранжирование и отбор ответов стали необходимы для полноценной работы всей системы. Этот опыт показал нам, насколько мощной может быть хорошо спроектированная система, объединяющая модели с ограниченными возможностями.

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

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

Главное отличие в том, что роевой инференс встроен непосредственно в разработанный нами механизм инференса. Мы называем его Swarm Decoder: несколько моделей-участников непрерывно влияют на единую траекторию рассуждения по мере ее формирования. Оценка и управление происходят в рамках этого процесса, поэтому модели могут повлиять на его направление еще до того, как ответ будет готов.

Альтернативные подходы устроены иначе. При ансамбле на уровне ответов модели генерируют отдельные варианты, которые затем ранжируют, отбирают или объединяют. В первоначальной архитектуре Fortytwo, реализованной в 2025 году, завершенные ответы ранжировались по оценкам других моделей. Это существенно повысило точность ответов, но увеличило задержку и вычислительные затраты. Во многих традиционных мультиагентных системах задачи распределяются между агентами, а их вклад координируется с помощью оркестратора и сообщений на естественном языке. Такая передача задач может потребовать дополнительных вызовов инференса, повторной передачи контекста и принятия решений о том, какую информацию передавать от одного агента другому. В Swarm Decoder передача задач между участниками не требуется: все они работают над одной траекторией и обмениваются только оценками того, какое направление лучше.

Swarm Decoder предназначен для выявления слабых допущений в процессе генерации, прежде чем на их основе будет проделана значительная работа. Цель — сократить число ошибок, возвратов к предыдущим этапам и ненужных генераций; выигрыш в эффективности достигается тогда, когда благодаря проверке удается избежать большего объема работы, чем требуется на саму проверку. Именно поэтому задержка не увеличивается: процесс идет более прямым путем, поэтому Engine выполняет задачи быстрее, чем та же модель самостоятельно, и расходует меньше токенов в общей сложности с учетом всех участвующих моделей.

Вы назвали дрейф модели при выполнении длительных задач одной из серьезных проблем. Что именно вызывает этот дрейф и как он проявляется на практике — например, в разработке программного обеспечения, исследованиях или автономных ИИ-агентах?

Дрейф возникает, когда контекст модели постепенно перестает быть связанным с задачей. При длительном запуске контекст заполняется собственными ответами модели, результатами работы инструментов, содержимым файлов и повторными попытками. Исходная инструкция занимает все меньшую долю того, на чем сосредоточена модель, а ее прежние ошибки становятся частью входных данных, на основе которых она рассуждает. В результате ошибки накапливаются, а не взаимно компенсируются. Кроме того, современные модели рассуждения обучают с подкреплением выполнять задачи, и они осваивают обходные пути, которые лишь выглядят как завершение работы: пропустить вызов инструмента, объявить об успехе, пересказать результат вместо проверки. Мы называем это ленью; ей подвержены как передовые модели, так и модели с открытыми весами. Корень проблемы в том, что у отдельной модели нет внешней проверки. Она сама оценивает свою работу, а модели плохо умеют точно оценивать себя.

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

Это можно выразить в цифрах. Мы запустили Qwen 3.8 27B на 450 задачах DeepSWE — реальных задачах по разработке программного обеспечения с использованием инструментов и большим объемом контекста, — сначала отдельно, а затем через Fortytwo Engine. При самостоятельной работе модели в среднем требовалось 16,3 миллиона токенов на запуск, всего — 7,4 миллиарда. При работе через Engine той же модели в среднем требовалось 12,3 миллиона токенов на запуск, всего — 5,6 миллиарда, то есть на 24,7% меньше. При этом она решила больше задач: 47,8% против 42,2%. Сама модель не изменилась. Четыре миллиона токенов на запуск, которые удалось сэкономить, приходились на дрейф: перечитывание, повторные попытки и возвращение к уже пройденным шагам — все то, чем вынуждена заниматься отдельная модель, если никто не замечает ее неверных действий в процессе. Рой обнаруживает такие ошибки, и поэтому платить за них токенами не приходится.

Раньше Fortytwo использовала модели для оценки ответов друг друга уже после их завершения, тогда как нынешняя архитектура позволяет им влиять на ход рассуждений непосредственно в процессе генерации. Какие выводы вы сделали из прежнего подхода и почему управление в реальном времени эффективнее?

Архитектура 2025 года доказала, что можно приблизиться к возможностям передовых моделей за счет горизонтального масштабирования — подключая больше моделей, а не стремясь найти самую крупную. Рой моделей с открытыми весами, ранжирующих полные ответы друг друга, превзошел лучшую отдельную модель в рое с преимуществом до 17 процентных пунктов. Кроме того, он оказался устойчивее отдельной модели к шумным запросам, внедренным инструкциям и ситуации, когда большинство ответов неверны.

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

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

В испытаниях с Qwen 3.8 27B Fortytwo сообщает о снижении расхода токенов на 24,7% в 450 запусках DeepSWE и об улучшении результатов по шести бенчмаркам. Что происходит внутри роя, позволяя ему одновременно повышать качество результатов и сокращать расход токенов?

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

Что касается точности, речь идет о неравномерности интеллекта. Улучшения моделей обычно распределяются неравномерно: в одной области они рассуждают на уровне обладателя докторской степени, а в другой выдают полную бессмыслицу. Это происходит потому, что тонкая настройка, обучение с подкреплением (RL) и другие этапы посттренировки улучшают модель на данных, на которых ее обучали, а достигнутый эффект уменьшается по мере того, как реальные задачи все дальше отходят от этих данных. Swarm Decoder не изменяет саму модель. Он стабильно улучшает процесс рассуждения, поэтому шесть бенчмарков — это не шесть областей, под которые мы оптимизировали систему, а шесть способов измерить одно и то же. В целом модель становится умнее и внимательнее, а когда другие модели проверяют каждый ее шаг, создается впечатление, что она уделяет вашей задаче гораздо больше усилий. Именно поэтому мы можем устанавливать для Engine ту же цену за токен, что и для базовой модели: клиент платит не за больший бюджет, а за более короткий путь к правильному ответу.

Разработчики ИИ всё больше обеспокоены затратами на инференс, поскольку модели рассуждения генерируют всё более длинные цепочки токенов. Как вы думаете, может ли повышение эффективности самого процесса рассуждения в конечном счёте оказаться столь же важным, как уменьшение размера отдельных моделей, повышение их скорости или снижение стоимости их работы?

Да, и я бы сказал, что это уже более действенный рычаг. Уменьшение размера моделей, повышение их скорости и снижение стоимости их работы удешевляют токен. Но токены никто не покупает. Покупают готовый результат, а в эпоху агентов число токенов на задачу резко выросло: на реальной задаче по программированию модель рассуждения расходует миллионы токенов, и значительная их часть уходит на повторное прохождение уже пройденного. Сокращение числа токенов на задачу на 25% даёт ровно такой же эффект, как снижение цены на 25%, но при этом эффект суммируется с каждым улучшением оборудования, квантования и ядер, а наш подход можно применять к любой модели с открытыми весами на рынке.

У отрасли есть три рычага. Улучшение моделей за счёт обучения — а это дорого. Удешевление токенов за счёт оборудования и обслуживания моделей — возможности здесь постепенно сближаются, потому что у всех одинаковые графические процессоры. И сокращение числа токенов на задачу за счёт того, как выполняется инференс, — это направление почти не исследовано. До сих пор масштабирование означало увеличение моделей и удлинение цепочек рассуждений, и в обоих случаях от одной модели требуют выполнить всё за одну последовательность действий. Мы считаем, что следующим направлением станет коллективная работа: несколько моделей рассуждают вместе, распределяя между собой оценку решений, благодаря чему сама последовательность действий становится короче и надёжнее. Это иной вид масштабирования — не за счёт числа параметров или вычислений во время тестирования, — и именно на него мы делаем ставку. Мы называем это ставкой на взаимодействие равноправных моделей, а не на параметры.

Fortytwo Engine совместим с OpenAI API и работает на моделях с открытыми весами. Насколько важна была совместимость с существующими стеками разработки ИИ и насколько легко разработчикам перенести приложение с обычного API для одной модели на роевую архитектуру?

Совместимость принципиально важна. Экосистема агентов — агенты для программирования, обвязки, фреймворки и средства оценки — построена вокруг формата OpenAI API. Поэтому для разработчиков, использующих Fortytwo Engine, переход ничем не отличается от смены одного поставщика инференса на другого: в совместимом приложении, агенте, обвязке или сервисе обычно достаточно внести одно изменение в конфигурацию — указать конечную точку, ключ API и модель.

Меняется поведение, а не интеграция. Разница заметна при длительных запусках агентов, где затраты токенов и точность с первой попытки определяют стоимость: одна и та же модель при работе через Engine выполняет задачи быстрее, расходует меньше токенов и справляется с большим их числом. Мой совет — относиться к этому как к любой замене модели: запустить уже используемую для своего агента оценку, сравнить число токенов на задачу и долю успешного выполнения, а затем оставить вариант, который покажет лучшие результаты.

Спасибо за прекрасное интервью. Читателям, которые хотят узнать больше о роевом инференсе и о том, как взаимная оценка может повысить эффективность рассуждений, стоит заглянуть на Fortytwo.