Еще несколько лет назад победа в олимпиаде или хакатоне по искусственному интеллекту считалась главным пропуском в сильную технологическую команду. Сегодня требования изменились. Компании ищут инженеров, которые способны превратить исследовательскую разработку в продукт, решающий реальные задачи бизнеса. По данным Reuters, именно такие специалисты стали одной из самых востребованных категорий AI-рынка в 2026 году. После побед в AIIJC, НТО и AI'm Doctor основана медтех-компания Humarin, а созданная open-source модель Paraphraser набрала более 3,5 млн скачиваний и используется в международных AI-проектах.

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

Генеральный директор АО "Экспертные платформы" Владимир Воробьёв рассказал, в чем соревновательный опыт помогает основателю, почему высокая точность решения не гарантирует спроса и чему сильному инженеру приходится учиться заново при создании собственной компании.

Владимир, что победа в соревновании по искусственному интеллекту действительно говорит о разработчике, а чего она принципиально не может подтвердить?

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

Победа в AIIJC в 2021 году стала точкой входа в индустрию. После соревнования я получил приглашение на стажировку в Сбере по направлению обработки естественного языка. В 17 лет это дало возможность сразу работать над реальными задачами вместе с сильной технологической командой.

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

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

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

В чем соревновательное мышление помогает предпринимателю, а в какой момент начинает его ограничивать?

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

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

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

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

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

Особенно отчетливо это стало понятно после работы над решениями, которые показывали высокие результаты в рамках конкурсов и исследований. Например, в соревновании AI’m Doctor наша система успешно решала поставленную задачу и заняла первое место. Это подтвердило, что выбранные методы работают и я способен построить сложное решение. Победа принесла нашей команде 35 млн рублей призового фонда, а сама разработка в 2025 году получила государственную регистрацию как программа для ЭВМ. Именно этот проект стал технологической основой для создания Humarin.Diagnose&Treat.

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

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

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

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

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

Победа в AI’m Doctor дала возможность сделать выбор: продолжить карьеру по найму или сосредоточиться на собственной компании. Выбрал второе и инвестировал часть призовых средств в развитие Humarin

После соревнований вы работали над корпоративными AI-продуктами, в том числе над юридическим копайлотом GigaLegal. Что промышленная разработка может дать инженеру, чего практически невозможно получить на хакатонах и в собственных проектах?

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

Во время обучения в Высшей школе экономики я снова пришел в Сбер на стажировку, а затем перешел на позицию NLP Engineer и участвовал в разработке GigaLegal. Это был продукт для профессиональных юристов, поэтому недостаточно было просто получить содержательно убедительный ответ. Пользователь должен понимать, на какие нормативные акты и судебную практику он опирается и как этот результат можно проверить. Над проектом я начал работать в 2023 году, и далее в течение двух лет занимался его разработкой.

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

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

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

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

Еще одним этапом стали open-source-проекты. Созданную вами модель парафразера скачали миллионы раз. Что эта цифра действительно подтверждает, а чего она не говорит о технологии?

В 2023 году мы создали Humarin Paraphraser — модель для перефразирования текста. Для ее обучения использовали синтетический набор данных объемом 12,6 миллиона пар перефразировок. Впоследствии модель скачали более 3,5 миллиона раз, она стала применяться в библиотеке Spark NLP, проекте RADAR компании IBM и других разработках.

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

Open source — достаточно жесткая проверка инженерного качества. Пока продукт используется внутри одной команды, многие его недостатки компенсируются знаниями авторов. Они помнят, как правильно подготовить данные, какую версию библиотеки установить и что делать при нестандартном результате. У внешнего пользователя этих знаний нет. Значит, возрастают требования к документации, совместимости, воспроизводимости и понятности ограничений.

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

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

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

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

Соревнования приучают быстро проверять гипотезы. Как организовать R&D в компании, чтобы исследовательская работа не превратилась в бесконечный поиск улучшений?

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

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

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

Например, эксперимент может дать небольшое увеличение качества, но одновременно заметно повысить задержку или потребовать значительно больше ресурсов. С исследовательской точки зрения это результат. С продуктовой — не обязательно.

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

Один из главных навыков зрелой R&D-команды — быстро не только находить перспективные направления, но и аргументированно закрывать бесперспективные. Отказ от гипотезы — не неудача, если он позволяет не тратить месяцы на направление, которое не даст продукту значимого результата.

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

Да. Более того, способность отказаться от самой сложной модели иногда является признаком зрелости команды.

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

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

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

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

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

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

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

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

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