Wazowski Recommends

Из необычных, но прикольных примеров рекомендательных систем в повседневной жизни: динамические обои на лок-скрине iPhone.

Конечно, это огромная натяжка — называть это рекомендательной системой. Технологии там совсем другие, и никакой персонализации на самом деле нет (персонален контент, а не ранжирование).

Но эффект как раз тот, который и хочется получать от такого рода штук. Ничего не делаешь, даже не задумываешься — а периодически что-то радует.

Я снимаю ненулевое количество фото, но разбирать их мне всегда лень. (Иногда вот только жена проходится по ним и лайкает что-нибудь.)

А если поставить такие обои, то айфон будет сам выбирать лучшие (по его мнению) фотографии и вырезать из них удачный кроп. И у него вполне неплохо получается. Я частенько, видя что-то новое, пытаюсь узнать — а когда же это я такое снимал. Не зря съездил в отпуск, оказывается!

Если кто хочет тоже себе такое настроить: Settings -> Wallpaper -> Add New Wallpaper -> Photo Shuffle -> выбрать интересующие категории фото (например, я выбрал и природу, и города, и свою семью). Для Android такое тоже наверняка есть, да?

Обычно у рекомендательных сервисов есть главная метрика, которую они пытаются растить, north star. Насколько я могу судить (и когда-то я уже писал об этом), в большинстве случаев это одна из четырех:
1) Time spent (сколько времени пользователи проводят на сервисе)
2) Транзакции (количество или суммарная стоимость, GMV)
3) Подписки
4) DAU (или похожие метрики user retention)

Конечно же, это исходит от бизнес-модели сервиса.

У меня есть мнение (или лучше сказать — гипотеза), что среди этих метрик самая близкая к «чистому качеству» рекомендаций (user satisfaction, «счастью пользователей» и т.п.) — это именно DAU.

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

Не очень сложно представить, как можно накрутить time spent. GMV — наверно, тоже (хотя тут слово «накрутить» не обязательно означает что-то плохое, деньги же тоже нужно зарабатывать, просто это может быть не сонаправленно с user satisfaction). Подписки — легко, если на сервисе есть контент, доступный только подписчикам (а если нет, то и оптимизировать эту метрику будет на порядок сложнее, чем остальные).

Для DAU тоже есть известный простой способ накрутки — присылать пуши (не говоря уже про дистрибуцию). Но это всё-таки немного про другой сценарий. А вот может ли система (или команда), которая управляет только тем, какой контент она рекомендует, накрутить DAU (т.е. заставить пользователей больше возвращаться в последующие дни), но понизить при этом user satisfaction? Я простых способов не знаю.

(Есть технический нюанс, что на границе дней системе может оказаться выгоднее локально оптимизировать time spent, чтобы сессия захватила и следующий день, но эти мелочи несложно исправить.)

Расскажите, знаете ли вы способы накрутки DAU и что вообще думаете про метрики верхнего уровня для рекомендаций?

Школа Анализа Данных славится в первую очередь тем, что готовит специалистов по машинному обучению. Но когда я в неё пошёл в 2007, я и слов-то таких не знал. Я шёл туда, чтобы изучать computer science, просто потому что было очень интересно. (Хотя ещё за год до этого я и про словосочетание computer science ухмылялся: что это ещё за наука такая — о компьютерах?)

И вот только к концу моего обучения в ШАД пригласили Константина Воронцова читать лекции по машинному обучению. У нашего потока оставался всего один семестр, поэтому Воронцову пришлось для нас ужать курс вдвое. Но мне этого хватило, чтобы понять, что это именно то, чем я и хотел бы заниматься.

Семинары по ML тогда вёл Александр Дьяконов и делал это, надо сказать, не очень хорошо. Многим не нравилось. И когда я закончил ШАД, внезапно оказалось, что Дьяконов уходит писать докторскую и больше вести семинары не будет. Надо искать нового семинариста. И Воронцов вместе с Леной Буниной подумали-подумали и почему-то решили, что никого лучше свежего выпускника ШАД, прошедшего только укороченный курс и ещё даже не окончившего мехмат, с неуспешным опытом применения ML в рабочем проекте, но зато с горящими глазами — им на эту роль не найти!

Так я и стал семинаристом. Совсем без опыта. Пришлось учиться по ходу самому, по бразильской системе. Это было довольно сложно и очень трудоёмко. В целом, получилось даже не так плохо. Кажется, лучше, чем у моего предшественника. Но сильно хуже, чем стали вести ML несколько лет спустя.

Меня хватило на два года. После этого я понял, что быть преподавателем — это не совсем моё, удовлетворения от процесса я получаю сильно меньше, чем трачу сил на подготовку к семинарам и проверку домашек. Но была и польза: меня стали узнавать почти все студенты ШАДа, что помогло мне получить неплохую репутацию в Яндексе (у вас тоже так бывает, что с вами здороваются незнакомые вам люди?) и, в частности, лучше нанимать к себе в команду.

Но только я перестал быть семинаристом, как Лена нашла мне новую роль в ШАДе: я стал вести научный семинар по машинному обучению и информационному поиску, где мы со студентами разбирали статьи. В результате чего у меня появилось несколько студентов в научном руководстве. И один из них (не будем показывать пальцем; привет, Рома!) даже весьма успешно защитил магистерскую.

Года через два мне и эта роль надоела.

И я стал вести спецкурс по алгоритмам на мехмате «от ШАДа», уже в роли лектора. Оказывается, лектором (по теме с уже имеющейся понятной и стабильной программой) быть намного проще, чем семинаристом.

А еще через год я попал в учёный совет ШАДа и пробыл там ещё много лет.

А находясь в совете, я даже слегка зацепил движуху по открытию ФКН ВШЭ.

А в 2015 я выступил на конференции ШАД в Берлине, где получил от коллег прозвище «Доктор Майкл Ройзнер».

А ещё я всё это время ходил вольнослушателем на разные курсы ШАДа. Оказалось, что после моего выпуска появилось даже ещё больше интересных курсов, чем было вначале. Причем настолько интересных, что можно даже отвлечься от работы и пойти в соседнее здание послушать лекцию раз в неделю.

Одним словом, трудно переоценить, сколько полезных знаний и знакомств мне дал ШАД. Я не знаю, как бы сложилась моя карьера (да и личная жизнь, чего уж там 😁), если бы не он. Наверняка не так интересно.

💛🔴⬛

#lifestories

Я уже пару раз писал про счётчики и про то, как убирать из них смещение. Но так и не затронул некоторые важные технические моменты. А именно — что счётчики занимают место в профилях пользователей и объектов. (Профиль объекта — это вся накопленная информация про объект; он не обязательно должен быть физически одной структурой.) И это значит, что мы не можем хранить бесконечное число счётчиков. Например, если профиль пользователя занимает 1 Мб, то с этим уже довольно сложно работать в realtime-системе.

Поэтому обычно настраивают лимит по количеству счётчиков каждого типа. Когда достигаем этого лимита, то выбрасываем самые «ненужные» счётчики — либо самые старые (давно не обновлявшиеся), либо с наименьшим значением (а при экспоненциальном затухании значение само учитывает и время обновления).

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

Если хочется просто отфильтровать объекты, то можно использовать широко известную вероятностную структуру — фильтр Блума. Иногда он будет отфильтровывать лишнее, но редко, и нас это обычно устраивает. А чтобы он не рос и не «засорялся» бесконечно с историей пользователя (удалять-то из него нельзя), можно сделать очередь фильтров: когда в последнем фильтре становится слишком много элементов, заводим новый фильтр и новые элементы добавляем уже в него, а когда фильтров в очереди становится много — удаляем самый старый.

Кстати, в нашей платформе в Яндексе мы сделали более эффективную по месту реализацию фильтра — quotient filter.

По сравнению со счётчиками, фильтры занимают меньше места, но у них есть два недостатка:
1) они выдают только бинарное значение,
2) элементы в фильтре нельзя перечислить, а можно только спросить про каждый конкретный элемент, есть ли он в фильтре. В частности, по фильтрам нельзя делать генерацию кандидатов или составлять более сложные фичи.

А можно ли избавиться от первого недостатка? Можно ли сделать структуру, которая будет хранить небинарные значения, как у счётчиков, но делать это приближенно (нам же это для фичей в основном нужно) и за счёт этого — более компактно?

Можно! Это называется count-min sketch, и это простое обобщение фильтра Блума (counting Bloom filter) с той же самой идеей использовать несколько хеш-функций. И, кстати, с экспоненциальным затуханием прекрасно совмещается.

К сожалению, у меня нет практического опыта с этим, чтобы сказать — эффективнее ли для фичей использовать count-min sketch или обычное обрезание счётчиков.

Невероятно.

Разработчик Алексей рассказал в комментах, что Стихолюб до сих пор жив!

Удивительно, но тот стихолюб на C++ до сих пор работает в проде.

После неудачи с первым проектом мы решили заняться чем-то ещё. И снова у Ильи Сегаловича возникла прекрасная идея: давайте сделаем специальный поиск по стихотворениям! Обычный поиск здесь не очень хорошо справляется, потому что стихи нужно искать в меньшей степени по смыслу, а в большей — по совпадению последовательности слов. И так зародился проект Стихолюб.

С этим проектом у нас пошло сильно лучше, потому что его можно было писать отдельно от существующей кодовой базы. А так как мы были группой исследовательских проектов, свой исследовательский прототип мы решили писать на том языке, который и я, и Макс знали лучше всего. На C#.

За полгода получилось сделать отличный поиск стихов, в котором были и расстояние Левенштейна, и суффиксные массивы, и алгоритм Ахо-Корасик, и фильтр Блума. И это даже неплохо работало.

И вот в конце апреля 2009 приходит к нам снова Сегалович и говорит:
— Слушайте, тут такое дело... 6 июня юбилей Пушкина. Очень хочется к этой дате что-то прикольное запустить. Нельзя ли теперь быстро ваш прототип превратить в продакшен?

Мы слегка удивились.

Я работал на четверть ставки.
Впереди меня ждала сессия.
C++ я знал очень плохо.

Учитывая это, быстро всё переписывать на православные технологии мы всё-таки отказались.

И тогда Сегалович решил договориться со всеми, чтобы проект выкатили в продакшен прямо в таком виде. На C#. На виндовых серверах.

От одного из виндовых админов мы получили новое прозвище. «Эти стихоблуды опять чего-то странное делают», — написал он на общую рассылку.

А руководитель качества поиска Денис усмехнулся:
— Вы что, с ума сошли? На C#? Как вы вообще собираетесь 5K RPS держать на своём дот-нете?

Когда провели нагрузочное тестирование, наш поиск выдержал и 10K, а дальше закончились патроны. 🤷‍♂️

Но на всякий случай решили написать отдельное правило на верхнем поиске, которое бы фильтровало трафик к нам. (Именно там и был фильтр Блума.) Правда, потом это правило просто забыли включить, и мы получили весь поисковый трафик.

Но перед самым запуском нас встретила ещё пара неожиданных проблем.

Во-первых, по соображениям безопасности, нельзя было где-либо показывать наружу, что поиск работает на винде. Поэтому Максу пришлось быстро патчить какую-то виндовую библиотеку, чтобы IIS притворялся nginx-ом в каких-то заголовках.

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

Я как раз прослушал новый курс в ШАДе под названием Machine Learning. Мы собрали ответы нашего поиска и разметили их на мусор. Получили целых 300 примеров! И дальше я несколько дней пытался обучить на этом SVM с разными фичами. И feature selection написал. Но почему-то всё равно получилось плохо.

В итоге наш продакт-менеджер Рост просто сам придумал decision tree, с которым мы и запустились.

Это был единственный раз, когда я работал несколько ночей подряд.

А ещё, за пару дней до запуска к нам пришли Антон с ником pg@ и его руководитель и сказали:
— Ребят, вы, конечно, молодцы. Но мы не хотим потом поддерживать ещё один поиск, да ещё на C#.

И после запуска мы специально наняли в команду ещё одного разработчика Алексея — преподавателя C++ в ШАДе, — вместе с которым я всё-таки переписал это, заодно и подучив язык хоть немного.

А переписанный Стихолюб проработал ещё несколько лет. Пока его не отключили за ненадобностью.

#lifestories

Попав в Яндекс, мы получили проект от Ильи Сегаловича. Илья умел очень классно делиться идеями и объяснять суть. Он нам рассказал, что на самом деле Гугл в своё время выиграл у всех предыдущих поисковиков за счёт хорошо сделанных сниппетов. А теперь для нас самое главное — сделать так, чтобы поисковые результаты не были сплошь одинаковыми. Надо бороться с полу-дублями.

Только сделать это у нас не удалось. Зато мне удалось получить свою первую психологическую травму на работе.

В Яндексе тогда не было почти никакой документации. Даже как собирать проект — было тайным знанием, передающимся из уст в уста.

Когда нужно было разобраться в каком-то куске поискового кода, Макс сказал:
— Ну давай посмотрим, кто автор этого кода... Ага, некий Антон с ником pg@. Просто сходи и спроси у него, что здесь происходит.

Я сходил и спросил. Антон с ником pg@ ответил мне, чтобы я просто прочитал код.

Прочитать и понять код у меня не получилось. А так как работали мы на четверть ставки, то в следующий раз мы с Максом встретились примерно через неделю. Узнав, что прогресса особо нет, Макс сказал:
— Нет, ну так дело не пойдёт. Пойдём вместе сходим и спросим.

Сходили и спросили. На что Антон с ником pg@ просто накричал на нас обоих: какого чёрта какие-то стажёры его отвлекают и не могут даже за неделю самостоятельно прочитать код?!

С тех пор ни я, ни Макс уже больше никогда не хотели работать в Яндекс.Поиске.

#lifestories

Летом прослушал выпуск подкаста с Максимом Страховым, а затем и подписался на его канал. Он рассказывает про то, как определяются уровни инженеров в FAANG-like компаниях.


Junior
Активно учится и растёт. Выполняет задачи под присмотром. Нужно рассказать, как делать. Пользы приносит меньше, чем на него тратят сил. По сути — инвестиция.

Middle
Независимо выполняет задачи. Может сам придумать, как делать, но нужно рассказать, что делать.

Senior
Достигает цели. Сам может придумать, что делать для достижения.

Staff
Разрабатывает стратегию и ставит цели.

Senior Staff
Запускает проекты с импактом крупного масштаба.

Principal
Трансформирует индустрию.


Конечно, это переупрощенное определение. Есть море нюансов. Очень многое зависит от компании, от конкретного отдела в компании и даже просто от везения (если говорить о повышениях и офферах). Что такое «импакт крупного масштаба»? Где четкая граница между задачами и целями? Почему в этой шкале только тип выполняемой работы, но нет её качества?

Тем не менее считаю это крайне полезным ориентиром. На нём можно основываться, дополнять и уточнять.

Если бы у меня был такой референс несколько лет назад, мне было бы чуть-чуть проще — и на калибровках, и направлять своих подчиненных, а может быть, и для собственного роста.

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

Работать я начал ещё до первого курса. После завершительных школьных экзаменов папа взял меня работать к себе в отдел в филиале РЖД. Моим первым рабочим языком (Паскаль не в счёт) стал VB.NET. К счастью, потом стали переписывать всё на C#. Занимался я тренажёром машиниста, но это не помешало в последствии друзьям подшучивать надо мной: «Миш, у меня сайт РЖД не работает, почини!» Задачи у меня были не очень сложные, поэтому вся энергия выливалась в перфекционизм: пытался заставить остальных писать код хорошо — по канонам ООП и без транслита в названиях.

В 2007 году я закончил второй курс на мехмате и пошёл на кафедру алгебры, в научное руководство к Лене Буниной. Тем летом её пригласили в Яндекс открывать Школу Анализа Данных, куда она меня и позвала учиться. Я как раз очень хотел научиться алгоритмам, поэтому с радостью пошёл. Причём так как Лена меня уже хорошо знала, то взяли меня без собеседований, по блату. Вместо собеседования, она просто покормила меня в столовой Яндекса (еще на Самокатной).

Учиться в ШАДе мне очень понравилось, было много всего интересного. Например, курс алгоритмов, который вёл Макс Бабенко. Мы были первым набором ШАДа, поэтому на нас как раз была отладка в продакшене. К примеру, лекции Ширяева только человека 3-4 с курса могли понять. И из-за этого после первого семестра нам устроили специальный туториал, где объясняли понятнее. А на том же курсе алгоритмов ещё пока не было той самой жесткой системы код-ревью.

Важно понимать, что это были те времена, когда самой крутой IT-компанией в мире, куда хотели попасть все вокруг, была компания Google. И я, конечно, тоже хотел. Да и Макс Бабенко тоже говорил, что если вдруг он решит всё-таки пойти работать в индустрию (для чего ему пришлось бы частично пожертвовать научной работой), то тоже скорее пойдёт в Google.

Во втором семестре у нас с ребятами из ШАДа завелась традиция — каждую вторую пятницу после занятий ходить вместе ужинать в какой-нибудь бар неподалёку. И Лена тоже с нами ходила. На одном из таких вечеров у нас завёлся примерно такой разговор:
— Ой, да ну этот Яндекс, вот вырастим, закончим ШАД и пойдём лучше в Google, — соглашались мы с товарищем, обсуждая вопрос, идти ли в Яндекс на стажировку (как делали многие однокурсники по ШАДу).
— Да? — спросила Лена, — А вот если, например, вы бы пошли не просто в Яндекс, а пошли бы туда работать с Максом?
— С Максом?.. — Задумались мы. А Макса мы считали не просто отличным лектором по алгоритмам, но и профессионалом, у которого хотелось поучиться на практике, — Ну, с Максом, пожалуй, можно даже в Яндекс.

И через пару месяцев мы все, включая Макса, оказались в Яндексе.

Без собеседований, по блату.

#lifestories

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

Когда я закончил первую версию слайдов и решил прогнаться по ним, у меня на это ушло примерно 5 часов. А доклад был рассчитан на час-полтора. Поэтому пришлось всё сильно сокращать. В том числе выкинуть и какие-то занятные истории и байки. В итоге смог уложиться.

А в процессе подумал, что про многое из этого можно было бы написать и сюда в канал. Чуть ли не каждый слайд. Да и один знакомый высказал такую же мысль. Вот только я снова не уверен, что это будет многим интересно, особенно людям, не связанным с Яндексом. Ведь основная часть этого карьерного пути (больше 14 лет!) прошла именно там.

В общем, выскажите своё мнение:
❤️ — да, с интересом будете читать
🤨 — нет, не надо такого

P.S. Если наберётся 100 сердечек Порога нет, всё равно потом сам решу :)

P.P.S. ⭐️ тоже засчитываются как положительные голоса :D

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

А теперь давайте подумаем, в какой момент времени относительно времени показа (T_impression) и времени разных взаимодействий (T_click, etc.), о которых говорили в прошлом посте, наша модель должна получить новый сэмпл для обучения (т.е. каким должен быть T_ingest в обучатор модели). Конечно, нам хочется, чтобы это происходило как можно раньше, чтобы мы могли быстро выявлять очень популярные новости. Но сделать это прямо в момент показа мы не можем, так как еще не знаем, произойдёт ли клик.

Самый простой вариант — подождать X времени (скажем, несколько минут) после показа и соответствующим образом решить, положительный ли этот сэмпл или нет. Тогда модель будет предсказывать, с какой вероятностью пользователь кликнет/полайкает/… документ за время X. Если X будет слишком большим, реакция системы будет медленнее. Если X будет слишком маленьким, то мы упустим часть положительных взаимодействий из-за того, что они не успели произойти за X. Эта часть может оказаться совсем не нулевой, больше, чем кажется на первый взгляд, особенно для более сложных таргетов (например, подписался ли пользователь на источник новости). У каждого таргета есть своё вероятностное распределение времени, через которое он случается после показа. И у этих распределений тяжелые хвосты.

Есть ли способы эффективнее?

Например, можно было бы завести несколько разных событий с разными X: кликнул ли за 30 секунд, за 2 минуты, за 5 минут и т.д. Но тогда мы увеличим объём данных для обучения в несколько раз, хотя информации для обучения мы будем выдавать не сильно больше, чем раньше. Это очень большая нагрузка на инфраструктуру и на обучение.

Можно было бы сразу же в момент показа использовать негативный сэмпл, а потом в случае, если какое-то действие произойдёт, сделать новый сэмпл, «уточняющий» предыдущий. (А если еще одно действие произойдёт — то еще одно уточнение, и так далее.) Так как уточнений будет на порядок меньше, чем показов, то нагрузка на инфраструктуру возрастёт не слишком сильно. Понятно, как обрабатывать такие уточнения для счетчиков. А вот как это делать для обучающихся эмбеддингов? Т.е. как «отменить» действие предыдущего негативного сэмпла? Возможно, можно просто сделать обратный шаг — шаг по градиенту (т.е. шаг градиентного подъёма вместо градиентного спуска). Но параметры модели на этот момент уже не те, которые были при прямом шаге, поэтому это не будет совсем точной его отменой. Не разнесёт ли модель от этого? Кроме того, как только новость появляется, она сразу получает много негативных сэмплов, а позитивные придут только с задержкой, из-за чего получается сильное смещение в негативную сторону.

Можно также комбинировать этот способ с изначальным простым — сначала чуть-чуть подождать (маленькое X), использовать первый сэмпл и уже только после этого начинать делать уточнения. Это снизит степень проблем, связанных с уточнениями. Но решит ли полностью? Да и сложновато получается.

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

Что думаете?

В рекомендательных системах, как и в некоторых других областях ML, практически во всех данных присутствует важное поле — таймстемп. Почти всё, с чем мы работаем, — это события, и нам важно, когда они произошли. И на этом можно было бы не заострять внимание. Но есть нюансы.

Почему важны таймстемпы? Во-первых, конечно, самый правильный способ измерять качество моделей в офлайне — разделяя trainset и testset по времени (причём глобально, а не для каждого пользователя отдельно, как любят делать в научных статьях). Потому что в реальной жизни всё будет работать именно так: мы обучаем модель, потом выкатываем её, и потом уже она работает на пользователях. А вообще-то, чаще всего у нас модели постоянно инкрементально дообучаются, поэтому и тестировать хорошо бы в таком же инкрементальном/онлайн режиме, а не с отложенным тестсетом.

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

Но всё-таки иногда приходится фичи вычислять заново («вычисление» может быть и очень простым — просто подджойнить таблицу), например, когда это новая фича и нам надо её сначала протестировать перед тем, как выкатывать на логирование. В этом случае надо строго следить за тем, чтобы при вычислении мы использовали данные, максимально похожие на те, которые были бы в онлайне. В том числе — не заглядывать в будущее. Иногда для надежности делают некоторое отставание в несколько минут или часов.

Этот механизм — приджойнить или вычислить фичи ретроспективно, с заданным отставанием по времени — достаточно общий, и его имеет смысл реализовать один раз в обобщенном виде.

Есть ещё и специальный вид вычисления — обучение и применение подмодели. (Например, фичи от трансформеров мы хотим использовать в верхней ранжирующей модели, а трансформеры постоянно дообучаются.) Вся логика тут сохраняется, при применении нужно брать последние известные данные (историю пользователю) и последнюю обученную подмодель (трансформеры). Это, кстати, показывает, что это примерно одно и то же — вычисление ретроспективных фичей и тестирование моделей в онлайн-режиме. Для тестирования сначала надо просто посчитать фичу — предсказание модели.

Отдельно скажу про избитый вопрос — клиентское или серверное время. Всегда используйте серверное. Клиентское время может быть в другом часовом поясе, а главное — просто битым (привет прослушиваниям в Яндекс Музыке из 2099 года). Его можно использовать как сопутствующую информацию (в том числе и для фичей), но не для основного механизма тестирования моделей.

Наконец, мало где можно встретить такое параноидальное внимание к деталям, но всё-таки уточню, что у пользовательских событий (взаимодействий с объектами) есть не один таймстемп и не два, а много:
T_req_start — пришёл пользовательский запрос на рекомендации;
T_req_end — мы построили рекомендации;
T_impression — пользователь увидел (начал смотреть/слушать) порекомендованный объект;
T_click, T_like, ... — пользователь совершил какое-то действие с объектом;
T_ingest — наша система узнала про всё это (что в свою очередь, конечно, зависит от конкретной части системы, которая узнала).

С точки зрения правильного тестирования модели, самые главные из этих таймстемпов — T_req_start и T_ingest. Но, к сожалению, не часто их разделяют, а вместо этого используют один таймстемп и иногда добавляют отставание. Так проще, а разница между ними обычно незначительная. Но думаю, что чем сложнее и мощнее становятся наши модели, тем больше проблем будет у неправильного учёта таймстемпов. С транформерами, например, это уже стало выстреливать намного чаще, чем раньше.

В моей жизни не так много было периодов, когда мне нравилась моя работа.

Было много периодов, когда мне текущее место работы нравилось намного больше, чем всё остальное вокруг, и никуда переходить не хотелось. Чаще всего — за счёт очень интересного проекта и/или хорошей команды. Но при этом обычно было и что-то, что очень сильно разочаровывало и не давало быть полноценно счастливым.

Однако были и исключения.

И вот с моим последним переходом мне как раз очень повезло — работать в 𝕏 мне очень нравится. Команда маленькая, нет никаких согласований и прочей бюрократии, нет булшита, люди вокруг умные (а некоторые — настолько, что с ними даже поговорить интересно 😁). Главное — можно вот прямо взять и поменять (желательно — в лучшую сторону) рекомендации в одной из самых больших соцсетей в мире. И не то что «можно», а создаётся активное здоровое давление, так как это core часть продукта.

Всё это очень повышает осмысленность работы и способствует большой продуктивности. За первые несколько месяцев я, как ML-инженер, сделал больше, чем за годы до этого (по собственным ощущениям).

Так вот, если вдруг вы хотите так же, — наша команда нанимает. На все уровни. Можно релоцироваться в Лондон или Калифорнию (рекомендую к нам в Лондон 😉). Ну и другие вакансии тоже можете посмотреть: https://careers.x.com/en (надеюсь, у вас не составит труда обойти блокировку при необходимости).

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

Но, на удивление, ни там, ни там не было настоящего работающего механизма feature selection.

Уточню, что я называю «настоящим». Все градиентные бустинги предоставляют feature importance — насколько они каждый признак использовали и насколько это помогло оптимизации лосса. Также бывают SHAP values. Но все грамотные ML-инженеры знают, что всё это совсем не настоящая полезность фичей. Их нужно использовать так: если importance нулевая (или очень маленькая), то фича бесполезная, ее можно убрать. Но не в обратную сторону.

В Яндексе был (есть) настоящий feature evaluation — убрать фичи и посмотреть, как меняется качество, да еще и стат-тест запустить. И даже была (есть) более дешевая приближенная модификация.

Но вот именно полноценного feature selection не было. Точнее, при мне даже была попытка его сделать, но вроде как большого успеха (распространения) она не достигла. Может быть, спрос на этот инструмент был недостаточным, а может, сделать его эффективным очень сложно. Задача же нетривиальная — есть N (тысячи) фичей, нужно среди 2^N наборов выбрать оптимальный (с точки зрения качества и какого-то понятия стоимости — например, количества фичей). А протестировать каждый набор может занимать часы.

Год назад я над этим размышлял-размышлял... И подумал, что можно это попробовать сделать сильно более эффективно с помощью Random Forest. Предлагаю вам оценить. (Я уже с бустингами перестал работать и вряд ли буду тестировать.) Сразу оговорюсь, что я никогда ничего про feature selection для random forest не читал и не слышал. Вполне вероятно, что уже давным-давно придумали либо то же самое (тогда почему не используют? не работает?), либо что-то ещё получше. Расскажите в комментах, если знаете.

Итак, идея:
- Предположим, что для отбора фичей можно временно заменить бустинг на random forest. (Это слишком сильное предположение?)
- Обучим random forest на всех фичах с раз в сто большим количеством деревьев. (Его же обучать дешевле, чем бустинг, он очень легко параллелится.)
- Затем запускаем любой стандартный алгоритм отбора фичей. И когда тестируем очередной набор, то не обучаем модель заново, а просто выбираем те деревья, которые не используют выкинутых фичей.
- Обычно нас интересуют наборы, в которых большая часть фичей не выкинуты, поэтому таких деревьев должно быть не слишком мало. И можно оценить, какое качество будет у модели с ровно M такими деревьями.
- ...
- Profit.

Что думаете?

Не так давно я узнал, что в нашей индустрии появился новый тренд. Причем там, где, казалось бы, и так всё неплохо работает и улучшить не так-то просто.

Как мы уже не раз обсуждали, для генерации кандидатов лучше всего работают двух-башенные сети и ANN-индексы для быстрого поиска, например HNSW.

Так вот, сначала Meta, а потом LinkedIn (и по слухам — ТикТок тоже) показали, что в современном мире это можно делать лучше.

Двух-башенные сети на первой стадии всё ещё остаются. Но вот складывать в ANN-индекс не нужно. А нужно… Просто использовать GPU!

При небольшой размерности эмбеддингов, да ещё и в квантизованном виде, на одной карточке A100 можно хранить порядка 100 миллионов документов (а этого хватит, конечно же, всем... ну почти) и успевать с ними со всеми посчитать скалярное произведение за несколько десятков миллисекунд. А для хорошего throughput запросные эмбеддинги стоит собирать в батчи (матрицы), чтобы всё это можно было сделать одним матричным перемножением.

Какие у этого преимущества?

1) Полнота поиска выше. Как бы мы ни любили ANN, их полнота на практике выше 95%, но всё-таки не 100%. А тут мы считаем произведение со всеми объектами в базе.

2) Если обычно мы отбираем одну или несколько тысяч кандидатов из ANN, то здесь можно выдавать сразу 100'000. ANN с таким количеством работают уже не очень хорошо. Только вот что делать дальше с этими 100000? Мета предлагает на следующей стадии ранжировать их моделью потяжелее, mixture-of-logits, MoL (всё ещё двух-башенная, но в конце не произведение, а более сложная сеть), тоже на GPU. И уже результат этого выдавать в тяжелое ранжирование, как и раньше.

3) А ещё такой подход позволяет намного быстрее и чаще обновлять эмбеддинги документов. Их же просто нужно обновить в памяти GPU. В ANN-индексе же это сложнее, поэтому обычно так часто не обновляют.

Выглядит перспективно.

Больше года назад я начал второй сезон в этом канале. Но в последние полгода случилось много всего: переезд, новая работа (а работать здесь и правда надо и хочется побольше, это вам не Майкрософт 😁). Времени регулярно писать не было, поэтому пришлось снова уйти на каникулы.

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

По традиции, тишину прерываю дружеским пиаром рекомендациями. Мы с авторами нескольких каналов о рекомендательных системах (и не только) собрали папку, на которую можно подписаться.

Подключайтесь!

Из личных новостей: сегодня я начал работать в 𝕏 (как обычно приписывают — formerly known as Twitter). Теперь буду там улучшать качество рекомендаций.

Почему именно X? За последние полгода мне не раз приходилось отвечать на этот вопрос и для себя, и для других.

В мире не так много крупномасштабных рекомендательных систем. И практически все они принадлежат большим корпорациям. Я несколько устал от корпораций (особенно после Microsoft), мне очень хотелось в компанию поменьше. И вот как раз таким исключением и является X. И там уже даже работает пара моих бывших коллег: Сева @yalinter и недавно вышедший туда Саша @knowledge_accumulator. Поэтому я приблизительно знал, на что иду. И надеюсь, что со временем еще больше наших бывших коллег присоединятся.

Рекомендации — это core функциональность для X, и я вижу в них большой потенциал.

К Маску можно по-разному относиться. Наверняка с ним будет непросто работать. Но результаты его управления мне, в целом, нравятся.

А Саша недавно писал более подробно про свои причины, и с ними я тоже согласен.

Надеюсь, у нас получится.

Хотя и не все соглашаются с таким подходом, но я считаю, что в рекомендациях надо исходить из того, что главная цель любой рекомендательной системы — оптимизация суммарного value. Это value может измеряться разными метриками. Главные четыре типа, которые я видел: DAU, time spent, транзакции (GMV) и подпиcки. Кроме того, иногда это value не только обычных потребляющих пользователей, но и других сторон — провайдеров контента.

Как я писал в предыдущем посте, основная часть рекомендательной системы — это engagement-модель E(engagement | item, user, context), которая предсказывает это самое value (или какое-то его осмысленное упрощение) для одного порекомендованного объекта. И можно строить рекомендации, просто сортируя по предсказаниям этой модели, не обращая внимания ни на что другое. Назовём этот бейзлайн циничным ранжированием.

Циничное ранжирование не является оптимальным для заявленной цели оптимизации суммарного value. Вы часто можете услышать про разные "beyond accuracy" аспекты рекомендаций вроде exploration, diversity, novelty, serendipity. Давайте переведём эти понятия с языка ощущений и "продуктового видения" на язык оптимизации суммарного value.

В этом посте начнём с exploration. Все слышали о дилемме exploration vs. exploitation. Это о том, что зачастую выгодно пожертвовать value (наградой) в текущем моменте ради того, чтобы узнать что-то новое и в будущем действовать более оптимально.

Довольно важно разделять user exploration и system exploration, потому что работать с ними надо по-разному. В первом случае мы жертвуем value пользователя в моменте ради него же самого, чтобы узнать о нём больше. Проверить, насколько хорошо нам это удаётся, можно с помощью обычных A/B-тестов. Только иногда нужно увеличивать их длительность, чтобы уловить более долгосрочные эффекты.

В system exploration же мы хотим узнать больше о всей системе. Одним важным частным случаем является item exploration — узнать больше про недоисследованные объекты (особенно недавно появившиеся в системе). Также можно исследовать разные области в пространстве признаков любой из использующихся моделей (model exploration). Про это уже был пост от Саши.

В отличие от user exploration, в system exploration всё сильно сложнее с замерами. Мы приносим пользователя в жертву ради остальных, а остальные могут оказаться в другой выборке A/B-теста.

При этом какие-то простые и полезные метрики item exploration всё же можно использовать: доля объектов, которые получают не меньше X показов/кликов за первые Y часов, — как метрика на дашборде, и доли кликов и показов на такие "недоисследованные" (новые с малым числом показов) объекты — как метрики в A/B. Эти метрики позволяют сравнить уровень exploration, но не отвечают на вопрос, какой уровень был бы оптимальным.

У YouTube есть попытки более принципиального подхода, но нельзя назвать эту область решённой.

Персонализация и popularity bias

Распространённая проблема в рекомендательных системах — недостаток персонализации, когда показываются в основном популярные и не очень релевантные пользователю документы.

В сообществе есть известная проблема popularity bias. Но что это в точности такое? Bias — это системное смещение. А где здесь смещение? И есть ли оно вообще?

Если общими словами, то под popularity bias понимается ситуация "the rich get richer", когда популярные документы рекомендуются системой непропорционально чаще непопулярных. Причины у этого могут быть разные, и в литературе освещаются разные аспекты этого явления. Важно разделять эти причины, потому что это сильно помогает дебажить систему.

В работе над рекомендациями очень полезно выделять два важных шага:
1) Обучение модели предсказания отклика пользователя на рекомендованный объект. В простом случае это просто вероятность клика, в более общем — E(engagement | item, user, context).
2) Собственно, построение рекомендаций с помощью этой модели. Простое ранжирование по предсказаниям — не самый оптимальный, хотя и хороший бейзлайн.

Во многих случаях, говоря о popularity bias, подразумевают неоптимальность шага 2. То есть, даже если более популярный объект вызовет у пользователя с большей вероятностью позитивный отклик, может быть лучше порекомендовать ему менее популярный объект. Причин тут тоже может быть несколько — как пользователецентричные (долгосрочно клик на популярный объект менее ценен для этого пользователя, чем клик на непопулярный), так и с точки зрения всей экосистемы (этому пользователю станет чуть хуже, но зато мы выровняем распределение потребления по всей базе объектов). Это, в целом, разумные мысли, но надо честно себе признаться: мы жертвуем engagement-ом в момент конкретного запроса ради светлого будущего.

Самый простой способ имплементировать эту идею (и, по-моему, другие способы не очень-то далеко ушли от этого) — пенализировать за популярность объекта. Это очень тесно связано с PMI, который мы обсуждали в посте про двух-башенные сети.

В других же случаях popularity bias относят к первому пункту: дисбаланс объектов мешает нам хорошо обучить модель E(engagement | item, user, context). В частности, она может плохо учитывать пользовательские фичи и, по сути, просто выучить E(engagement | item), тесно связанную с популярностью (кстати, в этом посте я тоже иногда под популярностью имею в виду не P(item), а E(engagement | item)). Вот это уже очень ощутимая проблема. Хотя я не очень понимаю, почему её называют баисом.

Тут советы зависят от конкретной модели. Вот несколько:
- Убедитесь, что у модели есть информативные персональные фичи.
- Введите отдельный член внутри модели, отвечающий за популярность, чтобы оставшаяся часть модели могла сфокусироваться на специфичности.
- Если модель выучивает эмбеддинги объектов, проверьте, хорошо ли они выучились. Например, посмотрев на самые похожие объекты на данный.
- Если используется negative sampling, то учитывайте в нём популярность. Только не забудьте при применении обратно умножить на неё, чтобы получить E(engagement | ...), как обсуждали в том же посте.
- Ну и просто проверьте, что модель нормально выучилась. Да, это не так-то просто. Это часть довольно сложной, но критически важной темы ML Debugging.

Кстати про "непропорционально чаще". Никто ведь не обещал, что при простом ранжировании вероятность быть порекомендованным будет пропорциональна популярности или CTR документа. Это совсем не так. Может быть, поэтому это и называют bias-ом?

На моей же практике было очень много случаев, когда команды
а) не задумываются, что именно они называют popularity bias-ом и в чём его причины,
б) имеют проблемы с недостатком персонализации просто из-за плохо обученной модели E(engagement | ...).

Очень важно понимать — это мир так устроен, что у популярных, но менее релевантных объектов действительно в среднем лучше отклики, или просто мы модель плохо обучили.

Намного чаще popularity bias — это просто популярный миф, скрывающий баги системы.

Не стоит недооценивать важность хорошей engagement-модели.

Когда этим летом запускался Threads, большая часть ленты состояла из ВП — взаимного пиара.

Так вот, не могу не порекомендовать 😁
Если вам нравится этот канал, то вам обязательно понравится и канал Кирилла Хрыльченко: https://t.me/inforetriever

Один из типов постов там (не единственный!), который лично для меня очень полезен: Кирилл раз в неделю выкладывает дайджест свежих статей с arxiv на тему рекомендаций, ранжирования и прочего information retrieval. Он это уже делает больше года, но только сейчас это стало публичным.

И про negative sampling, например, Кирилл тоже рассказывает в одном из недавних постов, можете сравнить. (И на меня тоже ссылается, куда ж без взаимности 😉)

А теперь обсудим, как именно на практике можно измерять качество кандидато-генерации (или ранних стадий ранжирования), согласно тому самому принципу.

Сначала разберём упрощенный, но довольно важный случай: когда ранжирование производится просто по скорам одной финальной модели. Как я уже упоминал в предыдущем посте, мы просто можем сравнить средние скоры этой модели на двух наборах кандидатов. Если один метод находит кандидатов, которым финальная модель выдаёт бОльшие предсказания, чем у другого метода, то первый метод лучше.

Брать ли средние предсказания по всей выдаче, или только по топовым позициям, или с каким-то затуханием по позициям (получается что-то вроде IDCG — знаменателя в NDCG) — кажется, не очень принципиально. Можно выбрать любое по вкусу.

Есть технический нюанс. Если измерять такую метрику в офлайне, то надо уметь запускать ранжирование (или весь рекомендательный стек) на кастомных кандидатах. Это можно сделать либо через симуляцию (offline replay — т.е. пытаться ретроспективно воспроизвести всю информацию про все сущности) на исторических запросах, либо через scraping — "обстрелять" сервис рекомендаций новыми запросами, чтобы он при этом использовал интересующие методы кандидато-генерации. В обоих случаях получаются результаты (предсказания финальной модели) для разных методов генерации для одних и тех же запросов. Это хорошо для чувствительности метрики.

Если же измерять эту метрику в онлайне, на продакшен-сервисе, то можно всё посчитать просто по залогированным предсказаниям модели. Это сильно проще, но не так гибко, и сравнение будет на разных запросах. Чувствительность метрики снижается (вдруг одному из методов просто достались более сложные запросы).

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

Но когда-то я придумал способ для этого, который получился очень простым и полезным. И до сих пор нигде не видел его упоминания.

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

Конечно, тут мы предполагаем, что добавление случайных кандидатов не сильно ухудшает систему: большинство из них не порекомендуется, а те, которые порекомендуются, не сильно ухудшат жизнь пользователей, да ещё и добавят exploration как пользователям, так и модели ранжирования (она дообучится на этих примерах). Если это не так, то сначала стоит "починить ранжирование". 😉

Самое прикольное в этом методе — что он может служить не только метрикой кандидато-генерации, но и мониторингом здоровья всей системы, в том числе и финального ранжирования. Он проверяет, насколько кандидато-генерация согласована с ранжированием (оптимизирована под ранжирование). Если само ранжирование по каким-то причинам деградирует, то и кандидаты становятся не такими уж хорошими для него. Мы это видели на практике, когда одна из компонент поломалась, доля рандомных кандидатов в ответе увеличилась.

Кстати, случайность этого специального источника можно настраивать. Если использовать не равномерную, а пропорциональную популярности документа, то это будет более сильный "adversarial" игрок (что тоже может увеличить чувствительность). Зато при равномерном сэмплировании можно дать аналитическую оценку того, в какой доле запросов наша кандидато-генерация была идеальной (т.е. результат бы не поменялся, даже если бы мы добавили в кандидаты всю базу).

Из забавного:
Google Discover порекомендовал мне прочитать мою же статью, опубликованную в Towards Data Science 😁

Всех с 1700000000!

Как и зачем делать exploration в рекомендациях

В схеме Learning to Rank мы обучаем модель Score(user, item), выдающую оценку релевантности каждого из кандидатов. Рассмотрим пример сценария применения такой модели:

Этап кандидатогенерации, к примеру, HNSW, принёс нам 1000 кандидатов. К каждому мы применили нашу модель релевантности и получили 1000 чисел. В качестве результата выполнения запроса мы должны отдать пользователю 10 объектов. Простейшая опция - это отдать пользователю 10 объектов с наибольшей релевантностью. Но у этого есть проблема.

Дело в том, что для качественного обучения модели Score(user, item) у неё должен быть разнообразный набор данных. Если мы всем пользователям выдаём только самые релевантные треки, то может образоваться много треков, которые вообще не попадали в выдачу никому, и тогда модель на них может выдавать нереалистично маленький или большой результат - обе эти ситуации нежелательны и могут привести к плохой выдаче в будущем.

Возникает trade-off - с одной стороны, мы хотим формировать релевантную выдачу, с другой, мы хотим её немного разнообразить для улучшения качества датасета. Этот баланс на практике можно регулировать таким образом:
1) 1000 скоров кандидатов превращаются в вероятности попадания в выдачу: p = exp(score/T) / Z, где T - температура, а Z - нормировочная константа.
2) Применяется специальный алгоритм по генерации выборки из такого распределения.
Если T равна 0, мы получаем просто топ-10, и чем она больше, тем больше всё сглаживается в сторону равномерной выдачи.

Самая большая проблема этой схемы заключается в подборе значения T. Я уже объяснял, что когда один элемент влияет на все компоненты системы, для тестирования необходимо дублировать вообще всю систему - здесь именно такой случай, и почти всегда мы не можем этого себе позволить. Как же тогда быть?

Сначала предполагаем на глаз, какой уровень "гладкости" выдачи мы хотим. А затем уже подгоняем T, чтобы был нужный эффект, и по надобности иногда переподгоняем. Вот такая наука.

@knowledge_accumulator

Какое-то время назад я писал о том, как можно использовать внешние эмбеддинги. Сегодня поговорим на связанную (даже пересекающуюся) тему: как использовать внешнюю историю пользователей, т.е. историю на другом сервисе. Типичный пример у поисковых гигантов: поисковая история, довольно богатый источник информации про пользовательские интересы (если privacy policy позволяет).

Если у этой внешней истории пространство объектов совпадает с основным пространством рекомендуемых объектов (или сильно пересекается, или явным образом связанно), то этот случай простой: мы просто можем добавить в нашу систему ещё один тип событий — внешнее взаимодействие — и во всех моделях учитывать ещё и историю этого типа с рекомендуемыми объектами. Даже если рекомендуемые и внешние объекты явно не связаны, иногда их можно связать неявно — обучив контентную модель, которая будет "матчить" внешние объекты и внутренние.

Если же внешние и внутренние объекты совсем разные, то тут интереснее. Могут существовать статистические закономерности, которые можно выучить. Можно либо явным образом их искать ("пользователи, взаимодействующие с внешним объектом A, чаще других пользователей взаимодействуют с внутренним объектом B"), либо обучать модели, похожие на SLIM, — линейные с кросс-фичами [пользователь взаимодействовал с объектом A, мы оцениваем объект B].

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

Можно обучить отдельную сеть для внешней истории или же просто добавить внешнюю историю как дополнительный сигнал на вход одной двух-башенной сети. Второй вариант, вероятно, более мощный, т.к. внешняя и внутренняя истории могут нетривиальным образом друг на друга повлиять (особенно если использовать self attention), Но его и сложнее обучать: сеть может просто "забить" на дополнительный, менее информативный и более шумный сигнал. Поэтому я бы начинал с первого варианта. К тому же, сильно проще проверить, что он выучивает что-то разумное.

Отдельный вопрос: а как именно использовать дополнительную модель с внешней историей? Есть несколько вариантов:
1) фичи в ранжирующей модели,
2) кандидаты,
3) продуктовые правила (бустить рекомендации от таких моделей),
4) более изощренные техники вроде модификации лоссов/таргетов ранжирования.

Я сильно рекомендую всегда начинать с пункта 1 — с фичей. Даже если это не самый эффективный способ, без него остальные варианты будут работать совсем не оптимально. Более того, зачастую они могут даже вредить системе.

При этом иногда добавление фичей совсем не помогает (они просто не используются моделью) из-за того, что в датасете просто нет исторических примеров, когда система рекомендовала что-то связанное с внешней историей. Поэтому способ такой: внедряем фичи, добавляем кандидатов, при необходимости бустим этих кандидатов в течение ограниченного времени, после этого уже фичи начинают учитываться в модели, и буст можно отключать. У нас такой способ хорошо работал.