Максим Петриев: математическая привычка проверять устойчивость системы спасает от наивных архитектурных решений

Сооснователь и экс-СТО The Stage AI, экс-техлид VK, под руководством которого был создан deep-tech-стартап, привлекший $4,5 млн инвестиций для ускорения работы нейросетей без потери точности, о том, почему 90% ИИ-проектов не доходят до продакшена и как опыт построения отказоустойчивых систем на сотни миллионов пользователей помогает проектировать инфраструктуру для ИИ-агентов.

По данным Gartner, до 85% проектов в области искусственного интеллекта не достигают стадии промышленной эксплуатации. Проблема обострилась в 2026 году, когда бизнес начал массово переходить от экспериментов с LLM к попыткам внедрить реальных ИИ-агентов. По мнению аналитиков, основной барьер заключается в сложности инфраструктуры - ИИ-агенты требуют принципиально иной архитектуры: управление памятью, оркестрация длительных процессов, безопасное выполнение действий от имени пользователя, считает сооснователь и экс-технический директор компании Максим Петриев, чей стартап привлек $4,5 млн инвестиций именно на развитие инфраструктуры для ИИ. Прежде, управляя бэкенд-командами в VK и Delivery Hero, он проектировал систему авторизации для рекламного кабинета VK-сервиса, через который проходят бюджеты тысяч рекламодателей, а любая ошибка обходится в миллионы рублей, и понял, где именно ИИ-проекты дают сбой и какие инженерные решения реально работают в продакшене. В интервью обсудили, чем опыт сооснователя deep-tech-стартапа отличается от роли наемного техлида и что индустрии стоит позаимствовать из практики построения классических высоконагруженных систем.

Максим, статистика говорит о 85% прогоревших ИИ-проектов. Вы развиваете технологии около 10 лет, а в ИИ-тематике едва ли не с момента ее перехода в практическую плоскость, плюс, взаимодействовали со стартапами разного уровня. Почему даже проекты с серьезным финансированием системно не доходят до продакшена? В чем корень проблемы?

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

С этой общей проблемой вы столкнулись, когда развивали стартап как сооснователь и CTO. Как писал Forbes, ваша компания, оптимизирующая инференс нейросетей, привлекла $4,5 млн. Какую инфраструктурную задачу вы ставили перед собой?

Мы создавали B2B SaaS, то есть программное обеспечение как сервис для бизнеса, которое продавали другим компаниям. Поэтому было критически важно, чтобы наша платформа работала без падений, отвечала быстро, не теряла данные. Как сооснователь, я работал с партнером над направлением продукта, мы обсуждали выполнимость тех или иных требований, искали баланс между тем, что хочет бизнес, и тем, что реально построить за разумное время. А как CTO выстраивал работу команды инженеров, проектировал архитектуру, следил за тем, чтобы система была отказоустойчивой. То есть главной задачей было общими усилиями обеспечить условия, в которых бизнес-требования клиентов превращались в конкретные технические решения.

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

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

Чем такой опыт отличается от вашей работы техлидом в VK, где вы проектировали авторизацию для рекламного кабинета, ежемесячная аудитория которого приближается к 100 млн пользователей?

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

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

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

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

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

Ваш подход ценят и в профессиональном сообществе. Наряду с представителями Минпромторга, "Ростеха" и других ведущих российских компаний, вы входите в состав экспертного совета Премии в области искусственного интеллекта, цифровых технологий, ИТ-решений и инноваций "ИИ-Олимп". Как оценка проектов в масштабах всей отрасли помогает вам самому развиваться как эксперту?

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

Что должно измениться в индустрии, чтобы ИИ-агенты вошли в каждый бизнес?

Должны появиться стандарты и готовые инструменты, как это было с веб-серверами или базами данных. Сейчас каждая команда изобретает свой велосипед. Это решения для памяти, оркестрации, безопасности. В итоге 85% проектов падают, потому что нет проверенных паттернов. А нужны протоколы для агентской памяти, фреймворки для отказоустойчивой оркестрации, лучшие практики по безопасности. Как только это появится, компании перестанут тратить полгода на инфраструктуру и начнут строить реальные решения. Пока же индустрия в фазе активного поиска.