Meet speakers from Tinder, IBM, Siemens, Indeed and other QA Rockstar’s on …Testing Stage, Save $30 till 28/02
×Закрыть
ML Engineer в MEGOGO
  • Кофе в домашних условиях

    О боги! Я, наконец, лайкнул Кожаева! ))) Надеюсь, мне за это ничего не будет.
    Продолжим же вечер гурманов...
    Мой абсолютный фаворит — три воды. Карамелизовать чуть-чуть сахар с каплей воды, добавить кофе и половину турки воды, разогреть, добавить ещё воды и специи, и довести до готовности.
    Это же магия!

  • DevOps дайджест #29: Kubernetes на F-16, Git для Monorepo, ClickHouse как Макгрегор

    Для поведенческой аналитики и репортинга. Что-то вроде доморощенного GA, но со специфическими для OTT входящими данными и метриками, некоторые из которых считаются на последовательностях событий очень нетривиальным образом.
    А для ML используются данные, которые лежат в data lake уровнем ниже. Одна из основных причин, по которым строится своя аналитика, — это владение полным объёмом данных, не платя при этом все деньги мира. Чтобы иметь возможность работать с этими данными чуть глубже, чем это позволяет BI. Но это уже другая история.

    Поддержал: Oleg Korol
  • DevOps дайджест #29: Kubernetes на F-16, Git для Monorepo, ClickHouse как Макгрегор

    Как только я найду время написать статью на ДОУ — тегну вас персонально, обещаю ))
    На данный момент я не понимаю, кому и зачем мне что-то доказывать. Ребята попросили рассказать, кто как использует ClickHouse. Я отметился — используем. Если будут дополнительные вопросы по теме — с удовольствием отвечу. Ввязываться в бессмысленные холивары — увольте.
    В наших конкретных условиях ограниченности по ресурсам и поставленным задачам, ClickHouse действительно является очень удачным и по-сути безальтернативным на данный момент решением, закрывающее большинство текущих потребностей. Если интересно — можно задать дополнительные вопросы. Но попытки доказать, что Druid лучше на каких-то абстрактных задачах, выглядят немного странно.

  • DevOps дайджест #29: Kubernetes на F-16, Git для Monorepo, ClickHouse как Макгрегор

    Надеюсь, Вы обратили внимание на ключевое «по соотношению»? Если на секунду предположить, что это соотношение базируется на анализе всех доступных альтернатив на рынке, то общаться становится сильно проще.
    Druid — это дичайший монстр, который может себе позволить саппортить разве что суровый энтерпрайз. Если вы оттуда — поздравляю, скорее всего компания сделала правильный выбор ))

    Поддержали: Oleg Korol, Dmitry Derevyagin
  • DevOps дайджест #29: Kubernetes на F-16, Git для Monorepo, ClickHouse как Макгрегор

    Уточнение по ClickHouse: 685 GB SSD для хранения данных. А то «память» может трактоваться двояко.
    Мы используем CH для аналитики по сырым данным + матвьюхи в качестве витрин нижнего уровня. По соотношению количества фичей к стоимости эксплуатации альтернатив я не знаю.
    Если разобраться как CH работает внутри, правильно создать схемы данных и вдумчиво писать запросы, то действительно на полудохлом сервере можно считать агрегаты с группировками со скоростью вычитки 500+М строк в секунду.
    Но это всё манипулятивные цифры. )) Т.к. CH — база колоночная, есть трюки по хранению данных. И нужно чётко понимать, что на самом деле происходит под капотом, что означает «500М строк в секунду» и как это сравнивать с другими БД. Потому что сравнение влоб ClickHouse и ScyllaDB — это как бы тёплое с мягким. О чём, в принципе, автор статьи упомянул.

  • Нужны ли программисту алгоритмы и структуры данных

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

    Далее идея превращается в продукт из говна и палок. Для того, чтобы довести свои мега-идеи до прода нужны скорее огромные яйца, чем знания алгоритмов. Конечно, очень странно не знать алгоритмы и не уметь рисёрчить, если фундаменте продукта инновационный алгоритм. Но это лишь часть общей картины продукта.

    И только после того, как появляется кэш-флоу, через топкодер нанимается армия ботанов, которые посредством своих узкоспециализированных знаний уменьшают суммарную стоимость владения продуктом, улучшая его в тех местах, которые наиболее болезненны для бизнеса. Если повезёт, некоторые из них даже будут добавлять ценность продукту, впиливая новые фичи.

    ИМХО основная польза от ботания алгоритмов состоит в том, что мозг — штука крайне пластичная и, загружая его подобной деятельностью, человек формирует его таким образом, что решение подобных задач у него не вызывает когнитивного диссонанса. Главный вопрос же не в том, знает ли человек в деталях определённый алгоритм (который он никогда в жизни так и не иплементит в реальной задаче), а как у человека сформировано мышление, умеет ли он мыслить как инженер.

  • Как мы создавали новостные заголовки на русском языке с помощью 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
← Сtrl 123456...19 Ctrl →