Митап IT_ONE Cup. ML Challenge: «Главное – чтобы решение работало и демонстрировало свою ценность»

IT_ONE Cup. ML Challenge – создай AI-ассистента, который будет помогать в работе дизайнерам, системным и бизнес-аналитикам.

Регистрация открыта до 13 апреля.

В преддверии старта прошел митап с экспертами:

• Татьяна Кочеткова, директор по работе с партнерами Sk FinTech Hub, рассказала подробнее про соревнование. 
• Максим Сячин, руководитель направления развития инноваций, поделился информацией про треки IT_ONE Cup. ML Challenge и ответил на вопросы участников. 

Мы подготовили текстовый вариант митапа. Из него вы узнаете:

1. Какие модели можно использовать.
2. В каком формате предоставить решение. 
3. Как подойти к разработке интерфейса. 
4. Где брать данные для обучения ИИ. 

Запись митапа

О соревновании

Мы с коллегами организуем IT_ONE Cup с 2022 года. На данный момент проведено уже пять мероприятий, а шестое – IT_ONE Cup. ML Challenge. За это время на наши хакатоны зарегистрировались почти 3 000 участников из 120 городов России и не только. Общий призовой фонд, который был распределен среди победителей за всю историю соревнований, превысил 2 500 000 рублей.  Я искренне рада тому, что вокруг IT_ONE Cup формируется настоящее сообщество единомышленников. 

Татьяна Кочеткова, директор по работе с партнерами Sk FinTech Hub

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

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

Татьяна Кочеткова, директор по работе с партнерами Sk FinTech Hub

Этапы IT_ONE Cup. ML Challenge:

• до 13 апреля. Регистрация участников.
• 12 апреля. Открытие соревнования.
• 12-25 апреля. Работа над проектами.
• 29 апреля. Питчинг и награждение победителей.

Треки соревнования: 

• Трек 1. Динамические контекстные подсказки для системного аналитика.
• Трек 2. AI-генератор дизайн-макетов по описанию требований.
• Трек 3. Система визуализации BPMN-диаграмм.

Эксперты 

Задачи соревнования

Максим Сячин, руководитель направления развития инноваций и автор задач IT_ONE Cup. ML Challenge, рассказал подробнее о том, что ждет участников в каждом из треков. Сейчас главный фокус работы команды IT_ONE – помощь разработчикам. Команда стремится не заменить программиста и не автоматизировать его работу, а именно аугментировать человека.  

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

Максим Сячин, руководитель направления развития инноваций

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

Трек 1. Динамические контекстные подсказки для системного аналитика

Задача вдохновлена инструментами наподобие GitHub Copilot, которые помогают программистам писать код. 

 А почему бы не сделать так же для аналитиков?

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

1. Пользователь начинает писать текст или код.
2. Система периодически предлагает подсказки (интервал времени между подсказками нужно определить самостоятельно).
3. Аналитик может принять подсказку, нажав соответствующую кнопку, или проигнорировать ее и продолжить писать.

С помощью такого подхода собирается статистика релевантности предложений: 

• Если аналитик сразу применяет подсказку, это считается 100% точностью.
• Если ни одна из подсказок не применяется, это говорит о том, что система работает плохо.
• В реальности, конечно, идеальных 100% быть не может, но цель — максимизировать процент принятых подсказок.

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

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

Что можно сделать в этой ситуации? Есть два варианта: 

1. Использовать открытые тендеры. В интернете публикуются тендеры, где часто размещаются технические задания. Вы можете взять одно из таких ТЗ и использовать его в качестве данных для обучения модели. 
2. Использовать техническую документацию open source проектов. Многие из них публикуют свою документацию в открытом доступе. Она может быть на иностранных языках (чаще всего на английском), но иногда встречается и на русском. Такая документация также подойдет для решения задачи. 

Оба варианта допустимы, хотя они могут немного отличаться с точки зрения того, как модель будет обучаться и работать. Мы учтем это при анализе вашей работы. Например, если вы скажете, что все данные для обучения брали из issues на GitHub или из документации определенных open source проектов, мы примем это во внимание и будем оценивать результаты с учетом этих особенностей. 

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

Трек 2. AI-генератор дизайн-макетов по описанию требований

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

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

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

Трек 3. Система визуализации BPMN-диаграмм

Задача, пожалуй, проще остальных, но это не значит, что там нет места для творчества. Наверное, вы сталкивались с тем, что приходится рисовать диаграммы. Иногда это C4, иногда это UML, а аналитики очень часто используют BPMN. Цель решения – дать возможность не рисовать диаграмму, а просто объяснить, что нужно построить. 

Мы выбрали BPMN, потому что это одна из самых простых диаграмм для генерации из текста. Главное, чтобы аналитик мог просто надиктовать бизнес-процесс, и LLM нарисовала бы его в виде картинки. Может быть, потом еще стоит эту картинку как-то поправить. Например, голосом сказать: «Ой, вот здесь мне процесс не нравится, надо добавить еще один подпроцесс». И диаграмма перерисовывается. 

В идеале должно получиться интерактивное решение, например, редактор диаграммы с интегрированным чатом. Однако стоит учитывать, что реализация такого проекта – это уже довольно сложная задача. Если вы решите создать интерактивный редактор, вам придется либо разработать его самостоятельно, что требует значительных усилий, либо использовать готовые библиотеки, такие как X6 или X7 из Ant Design.

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

Если же у вас команда сильных разработчиков, то интерактивный редактор будет выглядеть очень круто. Однако, если такой возможности нет, и диаграмма будет просто статическим изображением (JPEG, PNG или другим форматом) – это тоже допустимо. Для рендеринга статической картинки достаточно использовать BPMN-движок, который легко найти для Python или других языков программирования. 

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

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

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

Ответы на вопросы

В конце митапа Максим Сячин ответил на вопросы участникам и дал советы.

Какие модели или ИИ-сервисы можно использовать на соревновании?

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

Можно ли использовать No-code платформы, или решение должно быть на коде?

Решение должно быть основано на open source. Использование закрытых продуктов недопустимо из-за сложности их повторяемости. Поэтому No-code платформы допустимы, если они являются открытыми. Например, если она свободно устанавливается и справляется с задачей, такое решение принимается. Но хотелось бы все-таки посмотреть на код. 

Поэтому Low-code – да. No-code… Я в это не верю, но вы можете меня переубедить. 

Будут ли кейсы продуктовыми или нужно создавать модель, оцениваемую по метрикам?

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

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

Именно это станет точкой, за которой заканчивается работа на хакатоне и начинается полноценное экспериментальное исследование. Такая работа требует не две недели, а значительно больше времени. Для такого уровня задач нужно использовать серьезные вычислительные мощности, такие как кластеры GPU типа H100 или A100, и проводить обучение на них.

В каком виде нужно предоставить финальный результат? 

Финальный результат должен быть представлен в виде работающего Proof of concept. В идеале — это MVP. То есть это должна быть система, приложение или что угодно, что можно запустить, предоставить входные данные и получить результат. 

Учтите, что мы можем тестировать ваше решение не только на тех примерах, которые вы подготовили для демонстрации, но и на наших собственных. 

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

В каком формате должен быть разработан интерфейс проекта?

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

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

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

Можно ли развернуть решение на localhost?

Да, можно использовать localhost, чтобы протестировать приложение локально на своем компьютере. 

Анекдот про программиста: «У меня все работает. А у тестировщика – нет». Чтобы избежать таких ситуаций, решение должно быть переносимым. 

Вот несколько вариантов: 

1. Docker. Вы можете собрать свое приложение в Docker-контейнере и предоставить его жюри. Эксперты запустят этот контейнер у себя для проверки. 
2. Хостинг. Если хотите, можете разместить приложение на любом хостинге, чтобы оно было доступно через интернет, а не только на localhost. 
3. Локальный запуск с инструкцией. Если вы все же оставляете решение на localhost, убедитесь, что предоставляете четкие инструкции по запуску. Это позволит жюри легко развернуть ваше приложение на нашем компьютере. 

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

Обязательно ли посещать чекпоинты?

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

Максим Сячин, руководитель направления развития инноваций

Регистрация на IT_ONE Cup. ML Challenge открыта до 13 апреля.