Вторая часть разбора задач Лидеры Цифровой Трансформации 2021 для тебя
В предыдущей части мы разобрали первые пять задач конкурса. В этом разборе – задачи с шестой по десятую. Подробные ТЗ и датасеты организаторы опубликуют в день начала разработки 10 октября, комментарии по задачам – наше мнение.
PS, регистрация на ЛЦТ ещё идёт: http://rhck.me/leaders2021
Привет! На связи Александр Малышев и это вторая часть разбора задач с конкурса Лидеры Цифровой Трансформации. Это вторая часть разбора, где я делюсь своим мнением по задачам для участников, которые планируют зарегистрироваться на конкурс. Почитать первую часть разбора можно по ссылке.
Организатор конкурса: Департамент предпринимательства и инновационного развития города Москвы и Агентство инноваций Москвы, с 10 октября откроет доступ к дата-сетам и расскажет подробнее про задачи. Тем не менее, уже сейчас можно поразмышлять, какие идеи следует воплотить в жизнь для постановщиков задач.
Кстати, в чате конкурса участники поделились обратной связью по первой части разбора – спасибо вам! Если хотите дать обратную связь по разбору – пишите мне в лс, учту каждый комментарий
06. РЕКОМЕНДАТЕЛЬНЫЙ СЕРВИС ПО РАЗМЕЩЕНИЮ ГОРОДСКОЙ ИЛИ ЧАСТНОЙ СОЦИАЛЬНОЙ ИНФРАСТРУКТУРЫ
Описание задачи
Разработайте пользовательский интерфейс и модель определения оптимальных мест размещения городской или частной социальной инфраструктуры в городе Москве (больницы, сады, школы, МФЦ и др.) на основе анализа покрытия существующей инфраструктуры.
Комментарий
Задача на стыке анализа данных и урбанистики должна действительно оказать влияние на город. Вспоминается близкая задача – разработка алгоритмов, которые предсказывают выручку для кафе и ресторанов, прогнозируя поток посетителей, стоимость недвижимости. Эти алгоритмы производят коллосальный эффект на съемщиков коммерческой недвижимости.
В этой задаче похожий эффект – близость социальной инфраструктуры изменяет стоимость недвижимости, делает город удобным, и упрощает жизнь застройщикам. Причём, есть несколько важных задач для команды-участника:
- Построение модели определения оптимальных мест
- Построение интерпретируемых фичей для интерфейса – например, можно продумать, как модель будет отвечать на запросы (query-based): ~"Покажи мне все дома, где детский сад ближе 500 метров"
- Агрегация данных в открытом доступе – а-ля Open Street Map, карты Here/Yandex/Google/Foursquare и т.п., в том числе, раз задача стоит сделать интерфейс –показать интеграцию сервиса в жизнь человека: например, в некоторых ситуациях нужно анализировать не только существующую инфраструктуру, но и актуальность информации о ней, отзывы реальных людей
Правильные вопросы заказчикам будут: кто конечный пользователь продукта, какие трудности есть в определении оптимальных мест, почему эта задача появилась и точечные вопросы про датасеты.
Здесь в команде будет плюсом Data Scientist'ы, работающие в картографии, алгоритмами на графах, Web/Mobile для визуализации интерфейса, дизайнер
07. СЕРВИС ДЛЯ ПОИСКА ПРОПАВШИХ ЖИВОТНЫХ
Описание задачи
Ежегодно на территории Москвы теряются сотни домашних животных. Благодаря сети камер городского видеонаблюдения можно существенно повысить скорость поиска.
Разработайте модель поиска пропавшего животного и определения предполагаемого местонахождения потерянного питомца на основе данных с камер городского видеонаблюдения.
Комментарий
Как вы наверное помните, в Москве уже отлично работает аналогичный сервис для поиска людей. На базе уже имеющихся камер можно добавлять аналогичные алгоритмы для поиска животных. Я попытался изучить основные решения, которые показывали участники на похожих хакатонах и выделил то, что поможет вам в разработке сервиса:
- Сервис должен быть полезным – в данном случае полезность = насколько чётко удаётся определить сбежавших домашних животных. Учитывая специфику, в разработке есть явные подзадачи:
а) Детекция, что у животного есть хозяин – по поводку, отсутствию бирки, внешнему виду
б) Поиск похожего животного в базе данных сервиса
в) Взаимодействие с конечными пользователями – например, если человек нашёл животного и хочет сообщить об этом - Интерпретация фичей
Представим, вы потеряли собаку. Как сервис поймёт как выглядит ваша собака? Хорошо, если у вас есть сотни фотографий вашего любимого пса, но если нет – ваша модель должна иметь ряд фичей, которые интерпретируются – например, размер собаки, цвет и так далее. Просто обучить нейросеть не получится 🙂
3. Технологии
Вероятнее всего заказчику нужна именно готовая модель, поэтому решения на сервисах, вроде Google Vision API не подойдут. С другой стороны, на месте заказчиков, я бы существенно добавлял баллы за работоспособность модели в продакшне – ведь сделать на коленке детекцию – это одно, а другое дело – запустить такой сервис – тут нужны миллионые дата-сеты и готовность парсить интернет на предмет поиска питомцев. Подкину идею – если нет ресурсов разворачивать кубики в Kubernetes, а продакшн-реди хочется, можете попробовать Neu.ro, serverless-GPU, куда можно залить докер-образы и скейлить как хочешь без лишней боли от DevOps. У них есть партнёрка с русскими провайдерами серверов, так что решение отлично подойдёт для Москвы.
4. Приоритеты
Хорошо будет уточнить у заказчиков – что компания хочет получить в итоге. Ответ на этот вопрос, поможет с одной стороны приоритизировать задачи в разработки ML – например, сфокусироваться только на популярных животных (собаки, кошки), сфокусироваться или нет на DevOps, продукте и так далее.
Дрим тим – однозначно, несколько Computer Vision инженеров, DevOps, возможно – Web/Mobile разработчик
08. СИСТЕМА АВТОПРОТОКОЛИРОВАНИЯ КОНФЕРЕНЦИЙ В ОНЛАЙН РЕЖИМЕ
Описание задачи
По результатам конференций сотрудники государственных структур формируют детальные стенограммы, которые требуют ручного труда.
Для автоматизации процесса расшифровки требуется разработать веб-интерфейс, который автоматически в режиме диктофона, либо при загрузке аудиофайла формирует текстовую стенограмму конференций.
Комментарий
В задаче есть два пункта: веб-интерфейс и система автопротоколирования. Важно – спросить заказчика что из этого является приоритетом: в зависимости от ответа вы берёте дизайнера, фронта или дата-саентистов.
Если бы я решал эту задачу и не имел возможности уточнить у заказчика детали, я бы сделал акцент на фронтэнде, UI/UX и киллер-фичах. Во фронэнде за основу положил правило "система может ошибаться, это нормально, ошибки подсвечены и их можно послушать, исправить, система это учтёт и доучится". Основную задачу с транскрибацией я бы переложил на действующие сервисы, вроде Яндекс Speech Kit или sonix.ai. Киллерфичи проработал исходя из заказчиков, но по умолчанию – посмотрел суммаризацию текстов, например, в апреле 2021 года группа исследователей опубликовали бенчмарк и датасет для query-based суммаризации. Подобные статьи можно попытаться адаптировать под эту задачу. По шагам: сперва сервис, который помогает протоколировать живым людям, потом заменяет их.
С точки зрения бизнеса, сервис можно вполне упаковать под русскоязычные нужды. Для англоязычной аналогии: в 2016 году появился стартап Otter AI который занимается автопротоколированием конференций в Zoom, а в феврале 2021 года они подняли раунд B в $50M. Ещё один проект, на который стоит посмотреть – Fireflies представляет из себя AI помощника для видео-встреч. Основные фичи, которые они используют – автопротоколирование, запись звонков, ускорение (1х, 1.5х, 2х), поиск по встрече, API.
09. АВТОМАТИЗИРОВАННЫЙ АЛГОРИТМ ОБЕЗЛИЧИВАНИЯ ДАННЫХ
Описание задач
В обращениях в адрес Правительства Москвы москвичи указывают свои персональные данные. Чтобы работа с такими обращениями осуществлялась максимально безопасно и быстро, необходимо разработать модель автоматической деперсонификации персональных данных (ФИО, дата рождения, адрес и др.), которые указываются в обращениях москвичей с целью дальнейшей безопасной работы с документами сотрудниками Правительства Москвы.
Комментарий
В задаче между строк написано, что нужно сделать сервис, который обезличивает данные из документов. Это означает, что перед вами стоит задача узнать какие именно документы обрабатывать: для текстов подойдёт шифрование, для фото и видео сложность растёт – нужно решать задачи OCR (optical character recognition) для документов. У разных документов свои особенности – у паспортов, скажем, есть MRZ коды, у большинства документов – водные знаки и иные артефакты, мешающие определять символы или даже классифицировать документ. Помимо задачи по ML, важным этапом будет защита обработанных данных с помощью шифрования данных. Я бы учёл следующие подводные камни:
- некоторые данные запрещено и нельзя обратно персонифицировать
- данные могут быть переданы третим лицам (другим ведомствам)
- важно иметь возможность обратно персонифицировать некоторые данные
- данные могут быть совсем в разных форматах (простой пример – word и pdf), не все из них будут хорошо считываться
В команду на эту задачу я скорее всего привлекал 2-3 дата саентистов, один из которых разбирающийся в криптографии/CTF, программиста, занимающегося дата майнингом и Web/Mobile с навыками UI/UX дизайна.
От себя добавлю, что сервисы, которые получатся на выходе имеют хороший бизнес-потенциал. Например, во всём мире, в особенности в Европе (из-за строгости GDPR), активно вводятся новые законы и санкции за раскрытие персональных данных и передачу их третьим лицам. Часто корпорации страдают от того, что они не могут передать свои данные подрядчикам, потому что это будет нарушать законы страны. Количество данных растёт гигантскими темпами (например, из-за закона Яровой) При этом алгоритм деперсонификации и передачи "подготовленных" данных – это золотая жила на растущим рынке
10. РЕКОМЕНДАТЕЛЬНАЯ СИСТЕМА НОВОСТЕЙ ДЛЯ ПОЛЬЗОВАТЕЛЕЙ MOS.RUИ ПРИЛОЖЕНИЯ «МОЯ МОСКВА»
Описание задач
Сейчас медиа mos.ru рассчитано на множество разных сегментов горожан. Необходимо помочь жителям Москвы ориентироваться в новостях и дать возможность выбирать то, что интересно именно им. Командам нужно будет изучить путь пользователей в новостном разделе mos.ru, а также приложении "Моя Москва" и разработать модель, предлагающую новости для новых и действующих пользователей, а также обеспечивающую автоматическую разметку новостей по органам исполнительной власти и их руководителям, тематикам, тегам и др.
Комментарий
Задача довольно стандартная, поэтому в ней очень важно обсудить с заказчиками, какого именно функционала рекомендаций им не хватает.
- Рекомендации
Все рекомендации обычно делятся на три типа: User-based, Content-based и коллаборативные. Первые строятся исходя из знания о пользователях, вторые – о контенте, третье – на основе и того, и того. С точки зрения построения рекомендаций все три вида важны: с одной стороны есть зарегистрированные пользователи, которым можно рекомендовать коллаборативно и user-based, с другой стороны есть новости, которые нужно размечать по тэгам, тематикам (Topic Modelling, Иерархический Topic Modelling)
2. Метрика
Во всех задачах рекомендаций выбрать метрику – одна из ключевых задач. Чаще всего это релевантность контента, которая в свою очередь является производной от CTR, длины сессии юзера, размеченной релевантности на асесорах, "новизны" контента и т.п. Участвуя в этом треке, я бы отдельно обсуждал с заказчиком какая метрика релевантонсти им нужна.
3. Холодный старт
С точки зрения решения подобных задач наиболее частый подводный камень – как решить холодный старт – когда мы ничего не знаем о пользователе, а порекомендовать ему что-то нужно. В том числе, стоит подумать о проценте пользователей, которые читают новости неавторизированными – им рекомендательная система выдаст контент нерелевантно
В этой задаче, есть три разных холодных старта:
I) для пользователей (мы почти ничего про них не знаем)
II) холодный старт для пары (статья, пользователь) – на старте мы почти не знаем какие пользователи читают статьи
III) и более того, есть холодный старт для статей – информацию нужно обрабатывать (в самой формулировке задачи просят продумать авторазметку новостей)
4. Продуктовый подход
Помимо хорошей рекомендательной системы, желательно подумать как интегрировать их на портал, в том числе, агрегацию данных из разных источников (личный кабинет, взаимодействие с сайтом, эмейл рассылками и так далее). Данные для холодного старта тоже можно добавлять через продукт – и для этого нужно придумать эвристики, которые превратить в дополнительные блоки на сайте, которые помогут улучшить ваш сервис рекомендаций. Как вы думаете, на этом треке десятки команд будут показывать похожие алгоритмы рекомендательной системы – выделить себя проработанным продуктом и парой киллер-фичей – хороший плюс?
Напрашивается вывод – за план минимум взять state-of-the-art (SOTA) токенизацию, топик-моделлинг текстов, определить хорошо тематики, тэги и тп., затем добавить план по продукту, эвристики, которые решают холодный старт. При этом, за данное время хакатона, я бы изучил основные SOTA решения и попробовал вытащить в первую очередь на хорошем скоре рекомендаций и одной-двух киллер-фичах. В команде однозначно нужны 2 дата-саентиста, веб-разработчик или дизайнер, продакт
Полезный разбор? Поделитесь обратной связью у нас в Телеграм-канале или чате.
