Почему мне противно от хакатонов, но все равно в них участвую
Привет! Эта статья будет о нашем «экспертном» взгляде на хакатоны, где мы вкинем пару холиварных тейков и, кстати, расскажем о нашем решении для 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
Отдельно мы хотим выразить свои поздравления остальным участникам хакатона и поблагодарить за возможность послушать другие решения, а так же посмотреть на задачу под иным углом! Спасибо так же ребятам из МТС за интересное мероприятие и неплохую организацию;
