×Закрыть
ML Engineer в MEGOGO
  • Как мы создавали новостные заголовки на русском языке с помощью Deep Learning

    АБ тест запилили?

  • Как мы создавали новостные заголовки на русском языке с помощью Deep Learning

    сгенерировать довольно интересный тайтл

    Качество обобщения и CTR — всё же разные целевые функции.

    Поддержал: Иван Мазепов
  • Создание рекомендательной системы Megogo: использование неявных сигналов. Часть 1

    1) какие есть реально рабочие альтернативы?
    2) Вот mAP и показывает точность попадания видимой области ленты в реальные просмотры юзера с деградацией веса по позиции. Это очень логичная метрика с точки зрения реального UX. Но! Повторюсь. Любая метрика в контексте конкретно нашей задачи — вещь в себе. Опираться на неё конечно же стоит, но нужно понимать, что выбор юзера по-сути ограничен тем, что мы ему предлагаем в рекомендашках или форсим через рекламу. Это вносит огромный bias. Кроме того, юзер может воспользоваться поиском или зайти в линейный каталог контента. Реальную картину может показать только А/Б тест. И то... Комплексная модель зависит от массы сигналов, рекламные блоки сегментированы, etc. Нельзя просто взять и побить пополам аудиторию и «что-то измерить». Группы должны быть стратифицированы. Следующий вопрос — как? :) Тут не работают подходы а-ля кэггл.
    6) Архитектура — это всё же не о слайдах. Это целостное видение системы, изложенное в такой форме, чтобы бизнесу не пришлось начинать всё сначала, если автора вдруг собьёт автобус )) Поэтому: контракты микросервисов, устойчивые пайплайны, оркестрация, логирование, выкатка, альтернативы, планы итеративного развития, бюджет. Это важно зафиксировать для последующей долгосрочной командной работы.

  • Создание рекомендательной системы Megogo: использование неявных сигналов. Часть 1

    1) Разреженные данные — это как раз то, для чего и предназначен SVD. Лучше могут зайти только ембеддинги. Но это уже другая тема.
    2) Давайте смотреть правде в глаза: все метрики кроме результатов А/Б тестов имеют смысл только на Kaggle :) И даже А/Б тесты не очень репрезентативны потому что есть проблема достижимости контента, о которой говорится в соседнем треде. Так что, дискуссия может быть бесконечной. Но факт в том, что теоретическая математика и продакшен с реальными данными и потребностями бизнеса — два разных мира как бы. Всегда приходится искать компромисс.
    4) Опять таки, как оценивается качество результатов? Абстрактными оффлайн метриками или онлайн конверсией по АБ тесту между Spark vs Python.
    На самом деле implicit щупался в том числе, но он сразу отпал в виду объёма данных. Вопрос даже не в качестве, а в неприменимости на проде.
    5,6) В соревновании, которое мы организовываем (упоминается в статье), есть два бейслайна. Один посчитан по ТОП самых популярных фильмов, другой — очень тупой ALS без тюнинга. Разница по метрике MAP@10 — в 3 раза. Легко угадать, в чью пользу :)
    6) Один только трекер — 20 листов текста без деталей, чисто архитектура. Крайне сложно это всё упаковать в читабельный и компактный вид. И без лишних подробностей о нашей сугубо внутренней кухне. Но потихоньку это будет делаться.

    насчет RL не совсем понял как и зачем, ощущается как стрельба по воробьям из пушки. Да и думаю с полиси будет куча проблем учитывая специфику. А учитывая что как вы описали рук у вас мало, я бы в это не влазил.

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

  • Создание рекомендательной системы Megogo: использование неявных сигналов. Часть 1

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

    www.netflixprize.com/...​ressPrize2008_BellKor.pdf
    www.netflixprize.com/...​essPrize2008_BigChaos.pdf
    Естественно, в победном решении был дикий ансамбль. Но именно факторизация и k-NN были основными опорными алгоритмами, которые в разных вариациях участвовали во всех блендах. И считается, что именно после этого конкурса факторизация стала одним из промышленных стандартов в рекомендашках.

  • Создание рекомендательной системы Megogo: использование неявных сигналов. Часть 1

    Это отличный вопрос! Учитывая, что большая часть данных приходит из SmartTV, куда вообще невозможно попасть напрямую погуглив название фильма, достижимость контента на конкретной платформе становится ключевым фактором, который на данный момент никак не учитывается. Причина банальна: отсутствие трекинговой системы, достаточно интеллектуальной для сбора необходимой информации и её трансформации в цифры, пригодные для использования как penalty. Но сейчас ведётся активная работа в этом направлении.
    В ближайшем будущем будет использоваться информация о внутренних каналах, с которых зрители приходят в плеер, и какие в целом у них были альтернативы. В каком виде эта модель пойдёт до прода, пока говорить не готов. Нет данных-нет исследований-нет результатов. Есть только идеи и пачка whitepapers :)

  • Создание рекомендательной системы Megogo: использование неявных сигналов. Часть 1

    1 — субъективно
    2 — MAP, NDCG, MRR — это стандарт для систем ранжирования с учётом позиции. Идеально ещё экспоненциальным снижением весов, т.к. после 5-10 элемента уже в принципе не важно, угадали мы или нет. Precision, Recall совсем не о том.
    3 — об этом добрая половина статьи. Считается ряд метрик и находится компромисс.
    4 — «Уступает» по каким критериям? В основе лежит довольно простая факторизация матриц, сломать которую весьма сложно. Вопрос исключительно в подготовке данных и тюнинге гиперпараметров. И да, данных «очень много».
    5, 6 — Мы в курсе всего state of art :) Но в реальной жизни, когда что-то создаётся с чистого листа и бизнесу нужно «на позавчера», то сначала выкатываются максимально простые и точно работающие модели. И только после этого появляется время и возможность делать более комплексные модели.
    6 — Нет, мы говорили конкретно об ALS. На данный момент весь пайплайн только по этой модели от получения данных до выдачи конечному юзеру результатов — 11 последовательных шагов: ETL, просчёт ALS рекомендашек по 3 периодам, bagging, предсказание повторных просмотров (xgboost) и перевзвешивание рекомендашек, доставка результатов в in-house DC. Плюс оркестрация, мониторинг и тесты. Подробнее об этом будет в следующей части. Учитывая размер нашей команды, только это — уже большая работа.
    Кроме того, в проде работают рекомендашки для холодных юзеров, рекомендашки на основании мета-информации, на основании лайков, на основании покупок. Сейчас идёт работа в сторону reinforcement learning для учёта неявного негативного фидбека, создания поведенческих профилей юзеров (привет эмбеддингам) и более точной работы с сериальными объектами и франшизами.

  • 12 ошибок при построении архитектуры ПО

    Синглтон? Щаз набегут архитекторы, объяснят... :)

  • 12 ошибок при построении архитектуры ПО

    Кривовато — это когда ORM отправляет 1К запросов на справочник, когда его нужно сджойнить с коллекцией сущностей :)

  • 12 ошибок при построении архитектуры ПО

    В общем-то это сарказм был :)
    Просто я эту мантру о простоте переезда между БД благодаря DTO уже лет 15 периодически слышу. Так не бывает. Как и универсальных рецептов, что и где использовать.
    Я думаю, что DTO — уместный архитектурный инструмент для гетерогенных сред, где нужно унифицировать и атомизировать единицу данных. Всё остальное — это «любая архитектурная проблема решается дополнительным слоем абстракции». Если без этого можно обойтись — так и нужно поступать.

    Поддержал: Valeriy Shvets
  • 12 ошибок при построении архитектуры ПО

    Это на тот случай, если, например, Deutsche Bank вдруг решит переехать с Oracle на MSSQL. В случае использования DTO достаточно будет в конфиге connection string заменить. Очевидно же.

  • Релокейт в Європу. Частина 3: адаптація в Нідерландах

    Пятница же!

    Поддержал: Dmitry Derevyagin
  • Архитектура видеосервиса Megogo: варианты решений и переход от монолита к микросервисам

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

  • Машинное обучение в повседневной жизни: типы ML и способы их применения

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

    Поддержал: Alexander Konduforov
  • Как развиваться в IT и разочарования в IT

    Ещё лучше — лет 20. Без работы. На яхте. Можно немного экономить на шампанском и тогда не будет проблем с зарплатой команде.

  • Рейтинг работодателей 2018: анализируем оценки

    И потом хвастаются Ревизору количеством квадратных метров на сотрудника, не раскрывая деталей целевого назначения этих квадратов.
    ИМХО это всё равно что хвастаться новой квартирой на 200 квадратов из которых открытая терраса занимает 190. Никто умным же не назовёт... Но вряд ли это беспокоит счастливого обладателя этих квадратов, если он, наконец, исполнил свою мечту :)

  • Рейтинг работодателей 2018: анализируем оценки

    Вопрос «Зачем?» перед принятием решения не привыкли задавать на всех уровнях.

  • DOU Проектор: OurSQL — реплікація баз даних MySQL із використанням Blockchain

    Вы какую задачу решаете? Натянуть сову на глобус через создание очередного коина или реальную задачу надёжной мульти-мастер репликации в гетерогенной среде? При чём тут вообще криптовалюты?

  • DOU Проектор: OurSQL — реплікація баз даних MySQL із використанням Blockchain

    Алгоритм консенсуса:
    cwiki.apache.org/...​/display/ZOOKEEPER/Zab1.0

    Поддержал: Dmitry Derevyagin
  • DOU Проектор: OurSQL — реплікація баз даних MySQL із використанням Blockchain

    О, боги... А прочитать чуть дальше первой строчки?
    «The Apache ZooKeeper system for distributed coordination is a high-performance service for building distributed applications.»

← Сtrl 123456...18 Ctrl →