Привет! Эта статья будет о нашем “экспертном” взгляде на хакатоны, где мы вкинем пару холиварных тейков и, кстати, расскажем о нашем решении для 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

Отдельно мы хотим выразить свои поздравления остальным участникам хакатона и поблагодарить за возможность послушать другие решения, а так же посмотреть на задачу под иным углом! Спасибо так же ребятам из МТС за интересное мероприятие и неплохую организацию;