Не любил программировать, но ушёл в машинное обучение. Не хотел бросать инженерный бэкграунд — и не бросил. Работал с АЭС, фтором, флотомашинами и оптимизацией реального производства, где ошибка — это не падение метрики, а выброс ядовитого газа. Сегодня внедряю AI в промышленности, руковожу несколькими командами, пишу статьи, веду уникальный тг-канал про ИИ в промышленности.

Меня зовут Юрий Кацер. Я работаю руководителем направления анализа данных в компании Rocket Control. Мы занимаемся оптимизацией промышленных процессов и внедрением машинного обучения в индустриальные задачи.

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

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

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

В промышленный ML через хакатоны

Когда я учился, мы с друзьями заинтересовались хакатонами. Мы не были программистами, но тем не менее, решили попробовать. Наш первый хакатон назывался «2025» и проходил в Сколково. Мы, конечно, ничего не выиграли, даже в тройку не попали (хотя нам намекали, что были близко), но нам очень понравилась атмосфера.

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

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

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

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

Хакатоны бывают совершенно разными. Например, я участвовал в хакатоне, который длился несколько месяцев, и стал одним из победителей. Но это, скорее, исключение. В большинстве случаев всё устроено классически: 48 часов, с вечера пятницы по воскресенье, команда из 3–5 человек и бизнес-задача, которую нужно решить с помощью программирования или анализа данных.

Как правило, просто «анализ данных» не встречается в чистом виде. Если ты сделал модель машинного обучения или ИИ, тебе нужно её обернуть в продукт: это может быть сервис, софт, веб-приложение. И этим продуктом должны уметь пользоваться не только дата-сайентисты, но и обычные люди. То есть важно сделать понятное и работающее решение, а не просто модель.

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

Зачем участвовать в хакатонах

Причин участвовать в хакатонах — много. Например:

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

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

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

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

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

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

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

И ещё кое-что важное. Хакатоны — про навык видеть полную картину. Это тоже софт-скилл: умение фокусироваться на главном и правильно распределять время и силы (в том числе эффективно управлять командой).

Есть хорошая иллюстрация:

Ты заходишь на хакатон с планом: «Сейчас я нарисую идеального леопарда». Начинаешь с мелочей — рисуешь пятнышки, всё детализируешь, доводишь до идеала. А потом остаётся полчаса до конца, и ты понимаешь, что у тебя нет самого леопарда — ни туловища, ни головы, ни лап. Есть только точки.

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

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

Как побеждать в хакатонах (и не только)

У нашей команды есть набор правил, которым мы всегда следуем. Это не какая-то магия, а работающая система.

1. Прочитать критерии оценки. Первое, с чего мы начинаем — изучаем положение хакатона и особенно внимательно читаем критерии оценки. Это кажется банальным, но большинство команд этого не делает. А там всё написано: что важно, а что нет. Если в критериях, например, указаны дизайн, питч и финансовая модель, а не машинное обучение, — значит, не надо упираться в ML. Не надо изобретать лишнее — делайте по критериям. Это работает почти всегда.

2. Делать MVP, а не «идеальный продукт». Важно помнить: вам не нужно создать полноценный продукт за 48 часов. Вам нужно сделать рабочий MVP. Пусть он будет урезанным, пусть с багами, пусть с минимальной функциональностью — главное, чтобы он работал от начала до конца. И вы должны объяснить, что вы понимаете, как довести его до готового решения, если будет больше времени.
Если же вы приносите план разработки на год, у которой сейчас есть только интерфейс — это не сработает.

3. Грамотное распределение ролей. В команде должны быть чётко распределены роли. Если есть пять критериев оценки — у вас должно быть минимум пять человек, чтобы каждый отвечал за свой кусок.

Типовая команда:

• Капитан — управляет задачами, общается с экспертами, собирает презентацию, держит команду в фокусе. Это можно совместить с другой ролью (например, фронтом).

• Хипстер — дизайнер, UI/UX, презентация, фронт.

• Хакер/техлид — отвечает за код, техническую реализацию.

• Дата-сайентист — если нужен ML или анализ данных.

• Бизнес-аналитик — если в критериях есть экономика, сравнение с конкурентами и т.п.

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

4. Подготовка. Если готовиться к хакатону можно — значит, нужно. Если известна тема — изучите её. Даже если по правилам «нельзя», проверить это никто не сможет, но здесь на свой страх и риск. Хотя бы посмотрите видео по теме, почитайте статьи, сделайте заготовку.

Многие команды делают черновик презентации и заготовку продукта заранее, а на хакатоне просто допиливают и тюнят. Это допустимо, если это не запрещено.

Есть три варианта:

1. Нельзя приносить готовое — рискуете, если нарушаете.

2. Можно приносить, но надо показать, что сделано на хакатоне — будьте честны.

3. Правила не регламентируют — значит, можно приносить.

Если можно — приносите. Но не переигрывайте: вас могут поймать, если не видно прогресса.

5. План и чекпоинты. У нас есть жесткое расписание: чекпоинт 1, чекпоинт 2, чекпоинт 3. В воскресенье утром — финальная сборка, ничего не доделывается «в последний момент». Это важно, потому что времени всегда меньше, чем кажется.

6. Сон. Многие думают: чтобы победить — нужно не спать 48 часов. Мы так не делаем. Да, кто хочет — может не спать, но мы считаем, что если ты не выспался, ты бесполезен. В субботу у тебя 12 часов активной работы, и если ты не в ресурсе — можешь подвести команду. Мы всегда спали, и при этом в 14 из 18 случаев выигрывали или брали призовые места.

7. Репетиции питча. Выступление — это 50% успеха. Можно сделать хороший продукт и всё провалить на питче. Репетируйте. Хоть один раз, но лучше два. Новичкам — до 10 раз.

Лучший приём — капитан утром в воскресенье занимается только питчем, без переключений. Я ставлю таймер, чтобы не выбиваться из регламента. Если тебе дали три минуты, а ты заговариваешься на пять — тебя остановят, не дослушав. Да, и выступать лучше одному человеку, а то постоянно происходят казусы при передаче слова - то громкость разная, то микрофон у кого-то не работает, то начинаются проблемы с переключением слайдов. Но на случай болезни/технических проблем имейте замену спикера.

8. Структура презентации. Презентация должна быть цельной. Не просто «вот бэкенд, вот фронт, вот график». А связный рассказ: кто мы, что сделали, как это работает, почему это круто, что будет дальше. Жюри хотят поддержать — не мешайте им. Сделайте всё понятно, уложитесь в тайминг, поздоровайтесь, расскажите уверенно — и вам поставят хорошие баллы.

9. «Fake it till you make it» — но осторожно. Иногда бывает, что ты не успеваешь доделать. Тогда можно сделать заглушку — либо ее не заметят, либо вы объясняете свое решение и план действий. Например, «ML пока нет, но вот кнопка, вот результат, вот как это будет работать в будущем». На нормальных хакатонах проверяют функционал, но если вы честно сказали — всё нормально.

Фейлы случаются

Конечно, за годы участия были и забавные истории. Я даже как-то написал про них статью — она называется «5 историй с хакатонов». Эти истории и забавные, и немного болезненные. Я сейчас вспоминаю их с иронией, но тогда бывали ситуации, когда кто-то из команды всерьёз злился, кто-то уходил в слезах, были и истерики. Но мы старались всё это воспринимать как опыт и возможность чему-то научиться.

История про отсутствие данных

Это, наверное, одна из самых запомнившихся ситуаций. Мы пришли на хакатон, где нужно было построить модель машинного обучения для предсказания поломок лифтов. Но для построения ML-модели нужны данные. Мы приходим, а нам говорят: данных нет. Точнее, выдали описание данных, но не сами данные. Типа «есть лифт, есть датчики» — и всё. Ни одного значения, ни одной метки времени.

Мы пошли разбираться с организаторами, пытались объяснить, что без самих значений — это не данные. Через какое-то время они попытались найти хоть что-то, но было уже понятно: побеждать придётся за счёт креативности. Мы купили Arduino, прикрутили к ней датчики и буквально собрали систему сбора данных — прямо на лифте в Москве на Красном Октябре. Наша система ездила с лифтом вверх-вниз. Да, это был не промышленный продукт, но мы принесли хоть какие-то реальные данные. Это очень понравилось организаторам — мы в итоге заняли первое место.

Обещания после хакатона

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

На хакатоне все говорят: «Мы возьмём ваш стартап, вложим в него деньги, поможем с реализацией». А потом просто ничего не происходит. Это почти классика жанра. Поэтому не стоит ждать золотых гор, лучше относиться к обещаниям без завышенных ожиданий. Мы просто относимся с пониманием и пропускаем такие обещания мимо ушей.

Невыполнимая задача

Была ещё история с промышленным хакатоном. Мы выбрали один из треков, на него пришло три команды. Нам выдали огромное количество неструктурированных Excel, CSV, каких-то логов — несколько гигабайт. За 48 часов мы только и успели, что разобраться в этих данных. Никакого полноценного решения сделать не удалось. И не только нам — все три команды в этом треке снялись. Просто задача была объективно нерешаемой за отведённое время. А организаторы, похоже, даже не удосужились адаптировать данные для участников. Зато это отличная подготовка для работы в индустрии — до 70% времени датайсайентиста уходит именно на обработку данных.

Не всё зависит от усилий

Например, Kaggle (площадка для проведения ML соревнований) — это не про хакатоны, а про ML соревнование по метрике. Там не нужно делать продукт или презентацию, там важна только точность. Если твоя модель показывает точность 99%, а кто-то добился 99.4% — он и победил. Вот здесь можно послушать про формат Kaggle более подробно.

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

А вот хакатоны больше про быструю сборку MVP, про софт-скиллы, про взаимодействие в команде, выступление, продуктовое мышление. Это две разных вселенных. Я участвовал и там, и там, и думаю, полезно знать обе стороны.

Где искать информацию о предстоящих хакатонах:

• Telegram-каналы с анонсами хакатонов — их довольно много, постоянно появляются новые, там публикуются как крупные федеральные мероприятия, так и локальные инициативы.

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

• Блог сообщества Russian Hackers. Это некоммерческая инициатива, они проводят хакатоны (иногда на платной основе), пишут статьи: как участвовать, как организовать, зачем это нужно бизнесу. Статей немного, но по качеству они хорошие.

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

Со временем я перестал участвовать в хакатонах — во-первых, в эру онлайна стало сложнее получать удовольствие от процесса. А во-вторых, просто времени стало меньше: больше работы, больше ответственности, смена приоритетов. Ну и, честно говоря, мотивации меньше, потому что на каком-то этапе всё это стало рутиной. Мы с командой поставили хакатоны «на поток», просто штамповали решения. Если первые пару хакатонов мы проиграли, то потом из семи шесть заканчивали в призах. Это уже перестало быть вызовом и стало ремеслом.

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

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

Это объяснимая несправедливость: студентов можно пригласить на стажировку, предложить оффер, показать результат HR-отделу. Это банально про KPI внутри компании. Если хакатон проводится в том числе для найма, то HR-отделу проще «привести» десять джунов, а не двух сеньоров, которых ещё непонятно как удержать. Джуны — это сразу стажировка, дальше штат, попадание в отчётность. С сеньорами всё дольше, сложнее, не факт, что они вообще перейдут в эту компанию. Поэтому даже идеальное выполнение задачи не гарантирует победу. Надо быть к этому готовым.

В Data Science из инженера-физика

Как уже упоминал выше, я окончил Бауманку, учился на инженера-физика. Где-то на 4–5 курсе понял, что не хочу быть инженером в классическом понимании. Это интересно, но не настолько, чтобы я занимался этим всю жизнь. Тогда я попал в свою первую компанию — это было примерно на пятом курсе. Начал погружаться в новую для себя тему и довольно быстро понял: это круто. Компания занималась диагностикой АЭС — это близко к моей специальности, но там я понял, что можно заниматься анализом данных, работая с ядерными реакторами, а не проектировать их в качестве инженера.  То есть я могу не выкидывать свой технический бэкграунд, а использовать его в новой, современной области. Машинное обучение и DS тогда активно развивалось, и мне показалось, что я нашёл интересную мне и актуальную сферу.

Хотя, если честно, программирование я раньше не любил и был уверен, что никогда не буду этим заниматься. В Бауманке на первом курсе у нас было программирование на Delphi, но меня совсем не увлекло. А на первой работе, ближе к пятому курсу, понял, что без программирования в Data Science не обойтись. Python оказался проще и интереснее. Но, самое главное, в DS программирование — это только инструмент и одно из требований. Здесь и математика, и знания предметной области, и понимание промышленных процессов. Это как раз сплав всех моих интересов и моей технической базы. Так я и пришёл в сферу DS в промышленности.

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

Осязаемый результат

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

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

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

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

Если коротко и простыми словами: флотация — это промышленный процесс обогащения полезных ископаемых. Выглядит он как работа с огромными бочками, 6-8 метров в высоту и 4–5 метров в диаметре. В эти ёмкости поступает уже измельчённая руда, которую до этого добывают в карьерах. На этом этапе в массе материала в основном обычные камни, но среди них есть небольшое количество металла. Задача — отделить металлы от неметаллов, другими словами, увеличить концентрацию металла в этой массе: например, с 0,1% до 20%, то есть в сотни раз.

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

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

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

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

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

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

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

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

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

Участие в жизни сообщества

Членство в программном комитете Industrial++ стало продолжением моего хобби — участвовать в жизни ИТ-сообщества, особенно в области искусственного интеллекта, а ещё точнее — в ИИ для промышленности. Я активно интересуюсь этой темой, знаю многих людей из индустрии, публикую материалы, пишу статьи на Хабре, на VC, веду канал — в общем, сильно вовлечён.

Стараюсь не пропускать события, которые касаются искусственного интеллекта, особенно на стыке с промышленностью. Когда я узнал, что запускается новая специализированная конференция — Industrial++ — сразу стало интересно. У нас таких мероприятий немного. Я написал организаторам, предложил свою помощь, и меня пригласили в программный комитет. С удовольствием согласился — так всё и началось.

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

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

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

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

На конференции Industrial++ всегда много интересных докладов. К некоторым из них я сам приложил руку — был куратором спикеров, помогал готовиться. Особенно запомнились доклады по фотограмметрии — это, по сути, разновидность компьютерного зрения, когда с помощью дронов анализируется пространство с воздуха. Например, это может быть стройплощадка, лесной массив или какой-то другой сложный объект. Тематика для промышленности не совсем стандартная, но очень технически насыщенная — в таких задачах много нюансов и сложностей, особенно по обработке данных и имплементации решений.

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

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

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

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

 P.S. Если вам близко то, о чём мы говорили — приходите 25 сентября на конференцию Industrial++. Здесь обсуждают не абстрактный AI, а машинное обучение, которое управляет производством, спасает оборудование от поломок и работает в реальных цехах, а не в презентациях. Будет много кейсов, экспертов, людей, у которых действительно кипит — и не только во флотомашинах.