С начала 2012 года (где-то в период «map к новому году») я начал заниматься одним из любимых видов спорта (чем-то напоминающим спортивное программирование) — хождением по собеседованиям. В ту пору бигтех-компании периодически приезжали в Москву с hiring event-ами. Сначала я успешно прособеседовался в Бинг (и отказался потом от оффера). А вот с Амазоном у меня не получилось. Во-первых, в этот раз они прицельно нанимали в AWS, а я на каждом собеседовании на вопросы общего характера отвечал, что хотел бы заниматься ML. Во-вторых, я провалил оба систем-дизайна (не уверен, что он тогда уже так назывался): не спроектировал ни систему парковки, ни диспетчеризацию лифтов. Даже не понял, что вообще от меня хотят. И очень негодовал от таких бессмысленных секций.

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

Месяца через три меня обрадовали оффером. А я «обрадовал» Макса и Лену Бунину тем, что хочу уходить. Макс понимал, что меня надо отпустить из команды YT (на самом деле, его и самого в это же время хантили в Гугл). Но Лена не была готова отпустить меня просто так из Яндекса и попыталась найти мне более удачное место.

Несколько недель я встречался с разными командами Яндекса, а также несколько раз ездил в офис Гугла, чтобы узнать, что же конкретно мне предлагают там.

Среди команд в Яндексе чего-то зажигательного для меня не нашлось.

А вот в Гугл меня звали в команду Пети Митричева (первая ракетка мира в спортивном программировании на тот момент). Но только на вопрос, каким проектом я буду там заниматься, всё, что мне смогли ответить: это проект, связанный с ML. И на вопрос, хотя бы на каком языке надо будет программировать, ответили, что в Гугле, как известно, используют C++, Java и Python (Go тогда ещё не было), поэтому — «на каком-то подмножестве из этих трёх языков». Ладно, потом Петя сжалился и раскрыл страшный секрет, что Java в этом подмножестве нет.

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

Но Волож, прочитав его, высказал только претензию Лене:

Почему у вас сильные разработчики занимаются какой-то фигней, а не качество поиска улучшают?

А могли бы сейчас жить в мире с нормальной системой рекомендаций!

И всё-таки Лена смогла найти одну команду, которая как раз в перспективе хотела заниматься рекомендациями — рекомендациями фильмов.

Настал первый в моей карьере момент серьёзного выбора — выбора 2012. Пойти в компанию мечты, в сильную команду, но заниматься неизвестно чем на «каком-то подмножестве из трёх языков», или же остаться в Яндексе и заниматься задачей, о которой давно мечтал.

Компания мечты или задача мечты?

Я выбрал задачу.

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

#lifestories

Канал Коли, из которого два предыдущих поста, обещает быть интересным.

Когда я уходил из Яндекса почти три года назад, Коля приходил (возвращался) практически как моя замена. С тех пор служба рекомендательных технологий выросла раза в два и продолжает демонстрировать весьма достойные результаты.

Экс-Экс

Многие из вас могут помнить, как почти год назад я расписывал, насколько классно мне работалось в X.

И вот, это путешествие подошло к концу — я больше не работаю в Х.

Сейчас у меня небольшой отдых, а что будет дальше — stay tuned.

На этой неделе я начал работать в организации-которую-нельзя-называть-без-звёздочки.

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

От области рекомендаций я ушёл совсем недалеко: буду заниматься рекламой. Причём одной из моих любимых тем — long-term value optimization.

Мой менеджер пытался меня нанять ещё с 2021 года. На третий раз я всё-таки согласился 😊

Регрессия и распределение шума

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

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

Если у вас есть задача регрессии, вы можете построить гистограмму ошибок и проверить, похожа ли она на нормальное распределение.

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

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

Но у этих подходов есть проблема — они не mean-proper. Mean-proper функции ошибок — это у которых минимум достигается, когда предсказание равно матожиданию таргета. Например, L2 (MSE) или Binary Cross-Entropy (в случае бинарных таргетов) — mean-proper. А вот L1 (MAE), MAPE, MSE логарифмов — нет. Попросту говоря, при использовании таких лоссов предсказания будут смещенными. Я когда-то уже писал про это для логарифмов.

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

Поэтому я к этим трюкам с преобразованием таргета всегда относился скептически — не хочется терять калиброванность из-за того, что шум как-то не так распределен. И вообще, казалось бы, как бы ни был распределен шум, практика нас обычно учит: что вы хотите улучшить на test set — то и оптимизируйте на train set. Хотите MSE — используйте MSE. Просто разные лоссы ведут к разным компромиссам, когда не получается точно описать данные. Так ведь?

Оказалось — нет. За последние несколько дней я провёл небольшой эксперимент на искусственных данных. Пусть у нас одномерный случай, x распределен равномерно на [0, 1], «настоящая» зависимость выглядит как z = exp(a*x + b), а наблюдаемые таргеты сэмплируются не из нормального, а из экспоненциального распределения с матожиданием z(x). Обучаем модель y_pred = exp(a*x + b), т.е. просто подбираем параметры a и b по датасету, используя либо обычный L2 loss, либо специальный экспоненциальный лосс log(y_pred) + y / y_pred — это negative log-likelihood экспоненциального распределения (он тоже mean-proper!).

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

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

Эксперимент показал, что лосс, адаптированный к настоящему распределению шума, ведёт именно к лучшей генерализации — а не просто к другому компромиссу.

Иллюстрация (cherry-pick) — ниже. Типичная чувствительность L2 к выбросам.

P.S. Эксперимент выглядит очень простым. Но пока я его делал, я напоролся на несколько удивительных подводных камней. Оказалось, что использование
1) линейной зависимости z = a*x + b (без exp)
2) оптимизаторов Adam и (S)GD
3) mean(x) ± 2 * std(x) / sqrt(N) в качестве доверительного интервала среднего
— всё это делает эксперимент очень нестабильным. Угадайте, почему 😉

Вместо итогов года, хочу поделиться моим списком лучших — самых значимых или просто понравившихся — статей, которые я прочитал за последние два года (про 2024 раньше не писал). В порядке прочтения.

Unified Embedding
Статья DeepMind о том, что можно использовать одну универснальную таблицу эмбеддингов для многих sparse фичей. Полезная практическая статья.
Обзоры в Рекомендательной и у Дани.

Actions Speak Louder than Words
Громкая статья от Meta. Первая показала, что можно обучать огромные модели для рекомендаций. Ввела HSTU и новое представление истории. Лично для меня это был первый намёк на то, что когда-нибудь мы сможем отказаться от всех ручных фичей.
Обзоры в Рекомендательной и у Даши.

Revisiting Neural Retrieval on Accelerators
Meta показала, что retrieval можно делать на GPU без индекса. Также вводят для второй стадии модель mixture-of-logits (MoL), которая является более выразительной, но всё ещё относительно дешевой в вычислениях функцией. Для меня это была первая статья, показавшая, что retrieval можно делать лучше, чем всем привычным HNSW. И я сам потом работал над этим подходом. Обзоры у меня и у Саши.
А в последующей статье показали, что можно всё-таки и с индексами и без GPU напрямую искать топ по MoL. Обзор в Рекомендательной.

Серия Semantic IDs от DeepMind
- Generative Retrieval (обзоры у Саши и в Рекомендательной)
- Better Generalization (обзор у Дани)
- PLUM (обзоры у Кирилла и в Рекомендательной)
Номер 1 по значимости, самый существенный сдвиг парадигмы последнего времени. Токенизатор рекомендательного мира, представляющий контентную информацию об объектах в виде кодов из конечного словаря, полученного из иерархической кластеризации (RQ-VAE). Использование этой токенизации для нового метода retrieval, для более эффективных эмбеддингов в ранжировании и для связи с LLM. Уже повлияло на всю индустрию. Must read.

Streaming Vector Quantization Retriever
Одна вещь, которая меня больше всего смущала в Semantic IDs, — что RQ-VAE обучается отдельно, не end-to-end совместно с рекомендательной задачей. В этой статье ByteDance как раз исправили это. Правда, тут не иерархический RQ-VAE, а одноуровневый VQ-VAE. Зато real-time.
Обзор в Рекомендательной.

Stop Regressing
Единственная статья не про рекомендации, хотя и в рекомендациях тоже может быть полезной. DeepMind о том, как в задачах регресии (на примере value function в RL) моделирование распределения таргета (вместо точечной оценки) с помощью Histogram Loss улучшает масштабируемость. Про сам Histogram Loss можно прочитать и в оригинальной статье. Для меня это теперь достаточно близкая тема.
Про статью я узнал из выступления Дмитрия Бабаева на ICML Recap (а также в ML Underhood).

Серия OneRec от Kuaishou
- OneRec
- OneRec Technical Report
- OneRec-V2 Technical Report
- OneRec-Think
(и ещё какое-то количество статей, но я, признаюсь, даже последние две ещё только собираюсь прочитать)
Не называю это номером 1 по значимости только лишь потому, что оно во многом является продолжением Semantic IDs. Но всё же доводит их до того, что многие уже называют революцией — первая индустриальная end-to-end рекомендательная система, без нескольких стадий ранжирования. Вот примерно так будут выглядеть системы нового поколения. Must read.
Обзоры у Саши, в Рекомендательной и у Коли (1, 2, 3).

Correcting the LogQ Correction
Приз моей личной симпатии, потому что
1) улучшили знаменитую технику Гугла LogQ-коррекции,
2) я сам какое-то время думал на эту тему,
3) я рад за Кирилла и команду 😉
Обзор у автора.


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

Давно не писал — много работы, не хватало ни сил, ни вдохновения. Но сейчас лечу на неделю в командировку в Сан-Франциско, и в самолёте наконец-то появилось время.

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

Я начал очень активно использовать Claude Code и стал его большим фанатом. Я больше не пишу код руками, 100% за меня пишет Claude. В большинстве случаев это не вайб-кодинг, а вполне себе вдумчивая разработка. Но бывают места (и на работе, и в домашних проектах), где и вайб-кодить уместно.

Второй инструмент, который я начал активно использовать (хотя изначально был настроен скептически) — это Superwhisper. Он распознаёт голос и делает это хорошо. Он ещё запускает LLM поверх распознанного текста (можно выбрать, какую). Я теперь даже частенько в опен-спейсе, когда народу вокруг немного, немножко бубню себе под нос. А если нужно наговорить более серьёзно — просто ухожу в переговорку. Для задач, где текста нужно немало, это настолько удобнее и реально облегчает работу, что уже сложно перестать пользоваться. Черновик к этому посту я тоже надиктовал в самолёте и распознал через Superwhisper.

Расскажу ещё про пару экспериментальных техник, которые я пока исследую. Обе — от Андрея Карпаты. Кстати, если вы за ним не следите — очень рекомендую.

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

Он использовал это в своём проекте nanochat, в котором пытается на скорость обучить LLM до уровня GPT-2. И он собрал бенчмарк, в котором обучает модель 5 минут и смотрит на метрики. Оказалось, что этого достаточно, чтобы агент автоматически предлагал разумные улучшения. Качество улучшилось не только в игрушечном сетапе пятиминутного обучения, но и в полноценном обучении.

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

Сейчас я пробую применять это для своего основного проекта — и параллельно хочу как-то улучшить эту технику. В частности, я пытаюсь скрестить её с другим известным подходом в мире Claude Code — Ralph loop (Ralph Wiggum, Ralphex). Он про то, чтобы не одной большой сессией агента решать большую задачу, а решать её итеративно. На каждой итерации запускается агент с небольшим начальным контекстом и пытается совершить небольшой прогресс. И вот так в цикле, итерация за итерацией, решает задачу.

Ещё одна техника от Карпаты — это LLM Wiki. Она про то, как агенты могут вести, поддерживать и обновлять базу знаний. Я использовал это в своём основном проекте, собирая знания и про проект, и вокруг него. Также я стал прогонять через это все статьи, которые читаю (хотя сейчас это не очень много, но стало больше, благодаря llm wiki). Каждую новую статью, которую я хочу изучить, агент суммаризирует, пытается разбить на разные концепты, связывает её с другими статьями — и собирает такой граф знаний. Получается интересно, но я только начал.

Я ещё хочу попробовать LLM Wiki применить и для домашних задач, где нужно что-то изучить. Попробую, например, в личных финансах.

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