Привет! Эта статья будет о нашем “экспертном” взгляде на хакатоны, где мы вкинем пару холиварных тейков и, кстати, расскажем о нашем решении для True Tech Hack.
В Иннополисе невероятно скучно жить. Настолько, что в нашей айти-деревне за три года построился только еще один, никому не нужный в постковидный период удаленки, технопарк. Поэтому мы решили поехать развеяться. А выбор пал на хакатон True Tech Hack, приуроченный к недавнему ребрендингу MTC. Само собой, чтобы посетить заключительный этап хакатона (еще и совпавший по датам с одноименной конференцией, что определенно вкусно) нужно пройти в десятку финалистов, но об этом позже.
В этом году были представлены оргами две задачи и обе неплохие на самом деле. Вот вам краткий конспект:
1. Адаптация фильмов для людей с особыми потребностями (предполагается какая-то вариативность настроек фильтров и отображения контента в видеоплеере). Рассматриваются решения в виде дополнительного меню к существующему функционалу Kion;
2. Аудиосопровождение происходящего на экране для людей с нарушением зрения (в формате тифлокомментирования). Рассматриваются решения как с предобработкой, так и с обработкой видео потока в реальном времени; важным критерием отмечена кроссплатформенность предложенного решения;
Конечно же, мы взяли вторую! Посмотрите сами, здесь можно и попытаться усидеть на двух стульях, поддержав и стримминг и препроцессинг видео-контента, и посмотреть на узкое горлышко кроссплатформы в реальном кейсе, не говоря уже о громозкой, но крайне занимательной таске на обработку данных. И все это в одном реквайрменте на неделю, красивое…
Выбор формата командой МТС был крайне оправдан — целых 5 дней с несколькими чекпоинтами на имплементацию и тестирование идей для такой обширной задачи подходит идеально. Ребята так же выделили всем командам промокоды для доступа в MTS Cloud и подготовили репозитории для работы над решениями в гитлабе. За это команде оргов определенно лайк.
Вот мы четко обозначили, как много хорошего в initial коммите у флоу проведения хакатона. Отряхнули руки, взглянули и подумали — команды начнут писать решения и никаких проблем. Но это не так. Что-то же обязательно пойдет не по плану.
Давайте-ка остановимся здесь, посмотрим вокруг и обстоятельно порассуждаем о хакатонах, как о концепции в общем.
Мы много раз видели, как менторы не проявляют никакого интереса на техническом питчинге, если стек-технологий решения не смэтчился с их основным. В их голове вероятно звучит что-то в стиле “я в этом не разбираюсь, зачем мне вникать в подробности”. Когда видишь такое, сразу думаешь — ну тут все по делу, а зачем тогда менторить команды на хакатоне? Эта ситуация довольно быстро вытекает в проблему: мидлам на хакатоне делать нечего. Они абсолютно не растут в скилах, работая в формате быстро выкатить много фичей за пару дней. Ведь вы не зовете разносторонне-компетентных разрабов в эксперты. Туда чаще всего попадают люди желающие почиллить и пообщаться в командировке за деньги компании.
Еще хуже для разрабов расклад, когда команда экспертов и/или менторов целиком и полностью состоит из PMов, продактов, сейлсов, лидов и других менеджеров, слабо относящихся к технической части проекта. Тогда это и вовсе не хакатон. Это иллюзия, в которую мы играем, потому что на самом деле мы и не хотим делать никакое решение. Мы хотим играть в стартапщиков. Но радует, что они все добрые и позитивные. Ведь тут soft-скиллы решают.
На одном из хакатонов в нашей команде был дизайнер, он долго думал какого цвета должны быть кнопки и в каком формате юзеру показывать карточки. В итоге глобального импакта от него было не слишком много. А вот его мнения о каждой вьюхе разрабы ждали подолгу. Каждый человек причастный к решению — увеличивал очередь и время выполнения задуманных фич. Ведь создать распределенный флоу работы практически невозможно. Есть куча практик, чтобы бороться с этим — мы дробим все задачи на спринты, формулируем сроки, заводим специальных людей, чтобы следить за текучкой тасок. И в долгосрочной перспективе похода в прод это неплохо работает, а вот на хакатоне нет. Здесь нет жиры и скрам мастера, времени ждать новых правок или обновленной версии дизайна.
Мы в процессе разработки решений делаем мудборды. И это гораздо продуктивнее для брейншторма и/или создания полноценного дизайна.
Работать вот так — легко. Можно потратить время и написать что-то неочевидное, пощупать пределы любимого ui-фреймворка. По заветам комьюнити. Или бросить и не тратиться на нелепые кастомные контролы. Перевести силы на что-то более значительное для решения задачи, и взять все реализации вьюх из популярных купертино/материал либ.
Многие тимы думают, что единственно верная задача на хакатоне — решать бизнесовый кейс. И они правы, но на практике мы все это ненавидим. А ведь для нас это проявляется во всем. Ты сначала забиваешь на стайлгайды и линтер, и код перестает быть приятным для всех членов команды. На этапе проектирования игнорируешь важность удобства апи, и пишешь код, считая его в целом черновым вариантом. И потом мержишь все в мастер, так и не успевая вернуться и поправить уже образовавшийся техдолг, чтобы код остался читаемым и масштабируемым. Проблема в том, что ваш небольшой проект на несколько дней быстро вырастает в огромную неподдерживаемую, закрытую к модификациям кодбазу сомнительного качества. И это не фиксится. Потому что большинство постоянных участников хакатонов не привыкли писать понятный и гибкий код сразу. Они пишут код, способный решать только проблему бизнеса.
Страшнее всего то, что побеждают решения не из-за качества. Менеджеры захватили хакатоны и сделали soft-скиллы важнее и значительнее хард-скиллов. Презентация решения — это очевидно работа для экстраверта. Красивые слайды должны включать шутки и убедительно рассказывать о важности проблемы, которая уже заявлена бизнесом, даже если обсуждали несколько раз. И в тиме всегда должен быть общительный человек, который сможет покрыть эту роль. Ведь то, как ваша команда себя проявит определяет не то, сколько HRов к вам подойдет взять контакты. А именно то, сколько баллов получит в итоге ваше решение от экспертов.
Если вы дочитали до этого момента, вы либо с нами согласны, либо собираетесь на хакатон, и скоро ощутите все тейки на своей практике. Но мир не черно-белый, и даже в навозной куче иногда попадаются жемчужины. Хакатон — это возможность зеленому джуну обрасти связями, а бородатому сеньору попробовать новый стэк. И зная все подводные камни, которые мы постарались подсветить выше, вы еще и скорее всего сможете побеждать, так же флуктуационно, как волки успешно проходят технические собесы.
приЗа примерами далеко ходить не надо — достаточно посмотреть на наше решение для тифлокомментирования в кионе. Как мы придумывали идею и дизайн вы уже читали выше. Так что теперь мы можем поговорить о том, как у нас вышла реализация.
Мы разработали систему, которая дополняет тишину во время просмотра фильма комментариями от модели посредством мультимодального анализа кадров. Это позволяет получить схожий опыт от просмотра фильма людям как с нарушениями зрения так и без. А еще созданная система использует различные нейросети заточенные под решение конкретных задач. Таким образом она остается легко расширяемой и достаточно точной.
Оргами было предложено взять за основу любой доступный медиаплеер с открытым исходным кодом. Поэтому мы решили взять популярный плагин от флаттеровой команды с пабдева.
Сам UI/UX максимально приближен к оригиналу Kion. А для TV версии мы даже купили телек с определенной операционкой и запустились там с той же кодбазой, что для мобильной и веб версии. Клево же!
Давайте поговорим, как это работает поэтапно:
Распознаем что на картинке и описываем детали.
Что происходит под капотом? Обработка одного кадра видео создаёт задержку 40 +- 2 мсек, из-за чего было принято решение обрабатывать видео фрагментами заранее, а также кэшировать текстовый формат субтитров для дублирующей озвучки. При сохранении фрагмента накладываются две аудиодорожки с amix фильтром, что позволяет не приглушать искусственно ни одну из дорожек. Обработка кадров производится раз в фиксированное количество секунд (по умолчанию = 3), остальные кадры пропускаются. Озвучивание сцен рассчитано на конкретные моменты времени и реплики вставляются с перерывами, если время нужного кадра не подошло.
Если видим человека, пытаемся узнать персонажа, а так же его эмоцию. (модель для распознавания лиц и соотнесения их с лицами известных заранее персонажей и модель для определения эмоций героев)
Используем текстовую модель которая соединяет факты в лаконичное описание.
Здесь используются генеративные трансформеры для преобразования типа image2text (описание происходящего на сцене), модели взяты с hugging face
Преобразуем ответ в человеческую речь.
Здесь используется генеративный трансформер для преобразования типа text2text (перефразирование происходящего на сцене с учётом героев, их эмоций, возраста). Подключено api ChatGPT 3, без перевода с английского языка.
Добавляем аудиодорожку в стрим или файл.
Сервис работает в режиме стриминга, задержка 42–76ms (при использовании локально поднятых текстовых моделей), но появляется только в начале или при слабом интернете, в дальнейшем видео буферизируется , опыт как на youtube. Также возможна предобработка, при этом менять исходный файл фильма нет необхомости, мы написали кастомный плеер в котором возможно использовать отдельный аудиопоток.
ТВУ предложенного нами решения много минусов с точки зрения количества необходимых ресурсов. И просто закрыть на них глаза — не получится.
Дисковое пространство: веса для нейросети требуют места, как и сгенерированные субтитры и голосовая запись.Однако, в сравнении с весом самих фильмов, это сравнительно малый объем.
Вычислительная мощность: обработка фильма нейросетью требует значительных вычислительных ресурсов, однако, они требуются лишь при первом стриминговом просмотре фильма или во время предварительной обработки. В дальнейшем, благодаря буферизации и сохранению результата работы, нагрузка будет на том же уровне что и при просмотре фильма без сопровождения.
Пропускная способность: для стримингового сервиса очень важна доступность трансляции для всех пользователей. Обработка на лету подразумевает, что алгоритм будет тоже “смотреть” трансляцию, это необходимо единожды для каждого фрагмента фильма. Поэтому, когда N человек откроют разные временные отрезки в новом (необработанном) фильме, пиковая нагрузка на сеть будет порядка 2N. Однако, будем объективны, зритель наиболее часто смотрит фильм последовательно и, особенно по отношении к новому фильму, такая ситуация маловероятна.
Тренировочные данные: для улучшения точности распознавания, необходим значительный набор тестовых данных. Это опционально, по желанию площадки.
Работа модераторов: результат работы искуственного интеллекта не гарантированно соответствует ожидаемому. Несмотря на то, что можно очень тонко и грамотно настроить результат, модерация рекомендуема.
Стоимость: ресурсы, указанные выше, необходимо приобретать или поддерживать, так что, возможно, услугу по созданию аудиосопровождения имеет смысл предоставлять к определенному набору фильмов.
Мы все любим жаловаться, что все происходит не так, как мы ожидаем. Но в этом “не так” уже заложено на самом деле и много положительных вещей. Наша тима выкатила именно такое решение, каким мы видели его в моменте тех пяти дней на протяжении хакатона. Сейчас мы, конечно же, видим в нем безумного много проблем и активно занимаемся рефакторингом и по сути все переделываем. Но таковы хакатоны и в том числе за эту спонтанность и скорость разработки мы их и любим. C’est la vie
Отдельно мы хотим выразить свои поздравления остальным участникам хакатона и поблагодарить за возможность послушать другие решения, а так же посмотреть на задачу под иным углом! Спасибо так же ребятам из МТС за интересное мероприятие и неплохую организацию;
