Чем рекомендации в Лавке отличаются от маркетплейсов

На связи Артур Ильичёв, руководитель группы рекомендательных и поисковых сервисов Яндекс Лавки. Мы продолжаем рубрику «Обучено Яндекс Лавкой»: в ней мы заглядывали под капот персональных скидок и делились увлечениями команды. На этот раз поговорим про особенности рекомендательных систем в нашем сервисе, которые создают интересные технические и продуктовые челленджи.

Собрали все эти фичи ниже

Небольшой размер основного каталога

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

Регулярные покупки

В отличие от маркетплейсов, в Лавке пользователи часто покупают одни и те же товары в рамках разных заказов. Нужно искать баланс между рекомендациями для регулярного сценария и для чего-то новенького. А также предлагать качественные замены для товаров, которые закончились на складе, — иначе пользователь может полностью отказаться от заказа. Важно учиться измерять и учитывать долгосрочные эффекты, например LTV и лояльность.

Много товаров в заказе

Важно строить рекомендации так, чтобы помогать пользователю собирать корзину: учитывать её содержимое и сочетаемость товаров, напоминать пользователю о том, что он мог забыть.

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

Гиперлокальность

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

Сезонность

Спрос на продукты может сильно меняться в зависимости от времени года, времени суток и даже погоды. Поэтому grocery-рекомендации сильнее зависят от контекста, чем многие другие рекомендательные сервисы.

Быстрый заказ

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

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

Подписывайтесь:
@Yandex4ML
@YandexML

Как мы автоматизировали переход Браузера на новые версии Chromium

Каждые четыре недели Браузер переезжает на новую версию Chromium. Для пользователя это почти незаметно, но для команды разработчиков обновления стабильно превращаются в испытание. Каждый переход — человеко-месяцы работы, тысячи коммитов апстрима, конфликтов кода и ошибок компиляции. Простой авторезолв справляется только с тривиальными случаями.

Всё это — очень трудозатратная рутина, поэтому мы решили её автоматизировать. В этом посте расскажем, как мы использовали LLM-агента, чтобы разрешать конфликты и чинить компиляции. Разберёмся по порядку

Шаг 1. Учим модель разруливать конфликты кода

Первый подход был прямолинейным: скормить LLM целый файл и попросить «починить конфликты». Это не сработало, потому что контекст слишком велик: в Chromium есть файлы на 20 тысяч строк C++. Модели не хватает сил всё запомнить, и качество ответов падает.

Мы перешли к локальному контексту: небольшие файлы подавали целиком. Для больших находили блоки с конфликтами и добавляли ограниченный контекст до и после, а далее отправляли в LLM с промптом.

Затем мы взяли кейсы, с которыми не справлялась старая авторезолвилка, и превратили их в размеченный набор примеров. Данные разделили на train и бенчмарк. Train разбили на блоки и для каждого просили LLM вывести «не более 10 общих правил решения конфликтов» на основе человеческих резолвов. Результат прогнали через суммаризацию, а в финальный промпт добавили «пролог и эпилог» из «банка памяти» по браузеру.

Если решение LLM совпадало с тем, что дала бы старая авторезолвилка, код вливали сразу. В 98% таких случаев дополнительные правки не требовались. Для остальных оставили одного ревьюера вместо двух.

Как мы оценивали качество

Точное совпадение с человеческим резолвом (byte-to-byte). На бенчмарке 63% решений полностью совпали с тем, как конфликт решал разработчик

«Смысловая» проверка через LLM-as-a-Judge. Для каждого конфликта описали аспекты корректного решения (убраны маркеры, сохранены локальные правки, учтены изменения апстрима). По этой метрике получился 81% успешных решений

Шаг 2. Учим модель чинить компиляции

Чтобы пофиксить ошибку, нужно найти релевантное изменение в Chromium, понять, что именно поменялось, и учесть локальный контекст.

Мы разобрали и сгруппировали ошибки прошлых мерджей. Оказалось, что 10 крупнейших кластеров покрывают около 99% проблем. Это позволило перейти к типологии.

В основе агента — поиск нужного изменения в апстриме. Мы добились, чтобы по тексту ошибки он стабильно находил релевантные коммиты. Показатель HitRate вырос с 32% до 57%. Для половины кейсов также потребовался поиск по локальному репозиторию для учёта контекста.

Чтобы сократить число итераций, ввели двухуровневую схему: быстрые попытки для типовых случаев и сложный флоу — для остальных. Это снизило среднее количество шагов с 60 до 20. Генерацию кода изолировали от поиска: утверждённый план разбили на атомарные задачи и отправили в ноду на базе Aider. Теперь можно чинить ошибки параллельно.

Итоги в цифрах

Конфликты считали через FTE — сколько полной занятости удалось высвободить за цикл мерджа. Получилось примерно 50%. Это заметная экономия усилий команды.

С починкой компиляции метрики другие. На ранних версиях инструмент исправлял 50–60% ошибок из датасета прошлых мерджей. После того как мы добавили агентский поиск и планирование, доля выросла примерно до 80%. В реальной работе инструмент автоматически исправляет около 70% переданных ему ошибок. При этом он экономит примерно 32% времени на починке.

А в полной статье на Хабре рассказываем:

Почему ошибки компиляции становятся основной нагрузкой
Что происходит при мердже Chromium
Какой урок мы усвоили из этой истории и где LLM действительно помогает

Подписывайтесь:
@Yandex4ML
@YandexML

А вы успели подать заявку на Data Fest?

24 мая в Белграде и 31 мая в Москве мы откроем двери своих офисов для гостей конференции Data Fest. Активностей будет много: нетворкинг, доклады экспертов, игра «Слабое звено: ML Edition» и гонки на роверах 🏁

А в зале «Экстрополис» в Москве пройдёт наша фирменная секция — Practical ML. Смотрите, какие доклады мы в ней собрали:

X-split ARGUS: авторегрессивный энкодер-декодер для ранжирования рекламы. Александр Плошкин, руководитель команды распространения рекомендательных технологий, Яндекс R&D

AI-агенты для оптимизации бизнеса Яндекс Лавки. Алёна Зайцева, руководитель службы AI-сервисов, Яндекс Лавка

Контролируемая генерация многокамерного видео для симуляции сенсорных данных автономного транспорта. Анастасия Демидова, ML-разработчик в группе симуляции сенсоров, Автономный транспорт и роботы

Гибридная генеративно-ранжирующая модель на базе Semantic IDs в рекомендациях Яндекс Музыки. Дарья Тихонович, руководитель группы экосистемного семантического моделирования, рекомендательные технологии Яндекс R&D

AgentOps в продакшене: инфраструктура для LLM-агентов и автоматизация поддержки Персональных сервисов Яндекса. Иван Насонов, руководитель группы SupportAI, Персональные сервисы Яндекса

Как ускорить мультимодальную разметку в четыре раза без потери качества: обучение компактной VLM на сложных данных и доменных проектах. Александр Мандров, ML-разработчик, Yandex Crowd

Closed-loop RL для задачи автономного вождения. Павел Лукьянов, старший разработчик, Автономный транспорт и роботы

ARGUS: большой рекомендательный трансформер в системе с сотнями тысяч RPS. Георгий Смирнов, руководитель группы рекламных рекомендаций, Яндекс Реклама

Регистрируйтесь:

Москва
Белград

До встречи на Data Fest

Подписывайтесь:
@Yandex4ML
@YandexML

Знакомимся с командой ML Лавки, приоритизируем обучение моделей с точки зрения сети и вызываем вас на ML Challenge. Всё это и многое другое — в новом ML-дайджесте

Куда сходить

Data Fest × Яндекс 31 мая в Москве и 24 мая в Белграде. Открываем двери наших офисов для гостей и спикеров конференции. Послушаем доклады, посоревнуемся в гонках на роверах и сразимся в игре «Слабое звено: ML Edition»

4 июня — infra.conf’26 в Москве и онлайн. Собираемся вновь, чтобы обсудить создание и эксплуатацию высоконагруженных систем и инфраструктуры. Обсудим платформы, инструменты и архитектуру, а ML уделим особое внимание

19 сентября — Practical ML Conf 2026. Поговорим про ML-технологии, которые уже помогают бизнесу. Программный комитет отбирает доклады по нескольким критериям: польза и новизна для сообщества, применимость на практике и хардовый уровень сложности. Подавайте заявки на конференцию до 22 мая

Что случилось

Открыли регистрацию на Weekend Offer ML 30–31 мая. Ищем ML- и DL-инженеров с опытом в доменных областях NLP, CV, RecSys и Classic ML. Регистрируйтесь до 20 мая, пройдите всего две технические секции вместо трёх в обычном найме и ловите офер, если всё пройдёт успешно

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

Yandex Research побывал на ICLR 2026 в Рио! Инженеры и исследователи Яндекса привезли на международную конфу шесть крутых научных статей. Внутри — новые методы, технологии и подходы: от parameter-free-оптимизации до помасштабной дистилляции диффузионных моделей

Что почитать

«Обучено Яндекс Лавкой». Запустили новую рубрику в канале: в ней наши друзья из команды ML Лавки делятся тем, чем живут и над чем работают. Они уже рассказали, как модели помогают выдавать персонализированные скидки пользователям и какими хобби увлекается команда: от яхтинга и головоломок до алмазной мозаики

QoS InfiniBand: приоритизация ML-обучения с точки зрения сети. Развитие ML увеличивает нагрузку на внутренние облака, а мы хотим обеспечивать предсказуемые SLO для внутренних пользователей и сохранить удобство ML-инфраструктуры. Показываем, как в этом помогает технология InfiniBand и концепция Quality of Service

Подписывайтесь:
@Yandex4ML
@YandexML

Weekend Offer ML, или Как я попал в команду Алисы за одни выходные

Привет! Меня зовут Максим Ставцев. Я ML-инженер в лаборатории прикладного подкрепления, где создают RL-алгоритмы Алисы.

Всё началось с того, что в самый разгар активного закрытия дедлайнов в ШАДе я решил испытать свои навыки и отправил заявку на Weekend Offer.

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

Кстати, ближайший Weekend Offer ML — уже 30–31 мая. Сейчас мы ищем ML- и DL-инженеров с опытом в доменных областях NLP, CV, RecSys и Classic ML. Узнали себя? Регистрируйтесь до 20 мая, проходите обе секции собеседований за выходные и получите офер, если всё пройдёт успешно.

Оставить заявку на Weekend Offer

Подписывайтесь:
@Yandex4ML
@YandexML

Яхты, судоку, гантели и другие хобби ML-инженеров Лавки

Сегодня в рубрике «Обучено Яндекс Лавкой» поговорим о том, чем команда любит заниматься в свободное время и почему хобби и работа (порой очень неожиданно) так тесно связаны друг с другом

В карточках ребята рассказали:

Какие навыки тренирует бадминтон
Почему работа и яхтинг так похожи
Как тренажёрный зал помогает решать рабочие задачи

А как хобби помогает в работе вам? Делитесь в комментариях

На случай, если вы пропустили: вот первый пост из рубрики «Обучено Яндекс Лавкой». В нём рассказали про ML-модели, которые помогают нам предлагать персональные скидки в сервисе.

Подписывайтесь:
@Yandex4ML
@YandexML

Инфраструктура, платформостроение и AI на infra.conf’26 🏗

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

В этом году на конференции мы уделим ещё больше внимания ML и обсудим:

Как использовать KServe для ML- и LLM-инференса
Какой путь прошла Алиса AI
Как организовать observability для агентов
Зачем нужна телеметрия обучений LLM

Полный список тем и спикеров ищите на сайте конференции. Для тех, кто будет офлайн, дополнительно подготовили экспозону и несколько мастер-классов.

Участие бесплатное, но нужно зарегистрироваться: приглашение или ссылку на трансляцию пришлём на почту.

4 июня
Москва и онлайн

Зарегистрироваться

До встречи на infra.conf’26

Подписывайтесь:
@Yandex4ML
@YandexML

RAG-системы в трёх наших кейсах

Всем привет, это Андрей Соколов, руководитель команды обучения моделей с внешним контекстом в Яндекс R&D. В этом посте я на примере трёх наших продуктов расскажу, как устроены RAG-системы и какие подходы работают на практике.

Алиса

Это универсальный ассистент, который работает с пользовательскими запросами. Здесь RAG используется как дополнительная веб-выдача: прежде чем дать ответ, Алиса идёт в поиск за актуальной информацией.

Как мы оцениваем качество

У нас есть три типа бенчмарков:

Multi-Hop QA — насколько модель хорошо работает с несколькими документами одновременно
Атрибуция — умеет ли она цитировать текст и понимать, откуда именно взята информация
Подтверждённость — как она выделяет релевантные данные среди всех остальных

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

Поэтому мы проводим замеры: асессоры размечают ответы модели по разным критериям. Проблема в том, что показывать им весь контекст очень дорого и долго. Но как тогда оценивать его утилизацию?

Решение — искать баланс

Если асессорские метрики растут, а подтверждённость падает, модель перестаёт утилизировать контекст. Когда происходит обратная ситуация, модель просто занимается копипастом. Так что нужна золотая середина.

Затем наступает черёд end-to-end-замеров: A/B-экспериментов и улучшений на конечном пользователе. Кроме этого, мы оцениваем робастность и проверяем, не теряем ли мы качество, когда контекста становится больше.

Нейросаппорт

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

Поэтому в контексте можно выделить небезопасные и приватные чанки, а затем собрать бенчмарк и оценить процент инцидентов. Дообучать будем с SFT: соберём репрезентативный набор из 10 тысяч семплов с описанием поведения.

Затем подключаем RLHF: собираем пары хороших/плохих ответов, учим ревард-модели детектить инциденты, запускаем условные PPO/GRPO. В итоге получаем примерно 19% роста качества относительно промптируемых моделей.

Нейроюрист

Очень похож на саппорт, но с нюансом: баз знаний очень много. Это правовые акты, прецеденты, разные юридические источники, которые нужно глубоко анализировать. Получается очень сложная композитная система.

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

Походы в базы знаний
Обращение к документам
Рассуждение

Модель получает observation и выдаёт ответ. Всё сохраняется в виде трейса, который отправляется на оценку ревардов: правильно ли дёрнулись тулы, насколько хорошо написан ответ, не ходила ли моделька по кругу. Затем всё агрегируется, а модель обновляется через policy update.

Какие выводы я сделал

Каждая RAG-система уникальна

Изменения одного компонента влияют на все остальные

Не существует универсального способа оценивать качество

Один из ключевых аспектов RAG — устойчивость и безопасность

LLM нужно продолжать обучать и модифицировать

А полную запись моего доклада смотрите на ютубе и в VK Видео.

Подписывайтесь:
@Yandex4ML
@YandexML

«Вам −20%»: заглядываем под капот персональных скидок

Этим постом мы открываем новую рубрику в канале — «Обучено Яндекс Лавкой». В ней наши друзья из команды ML Лавки будут делиться кейсами, как они применяют модели в сервисе, какие задачи решают и какие подходы используют. А иногда — просто рассказывать о своей жизни за пределами работы. Погнали!

Привет, это Ваге Брсоян, руководитель группы экономической эффективности Яндекс Лавки. Если открыть наше приложение, в правом нижнем углу главной страницы может появиться плашка «Вам −20%». При клике пользователь получает персональную подборку из девяти товаров со скидкой. Снаружи это просто маленькая фича. Но внутри — место, где сошлись сразу несколько ML-моделей из разных проектов и довольно много продуктовой чуйки.

Из чего состоит задача

Цель простая — собрать пользователю пачку из девяти товаров со скидкой. Но внутри она делится на прогноз эластичности, ранжирование на конверсию и uplift.

Для начала нужно отобрать кандидатов. Отсекаем то, на чём 20% скидки просто сожгут маржу. Потом добиваем фильтром по эластичности из соседнего проекта: выкидываем товары, на которых скидка всё равно не двигает спрос. До ранжирования доходят только те, на ком есть смысл что-то крутить.

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

Дальше включается ранжирующая модель на конверсию. Кандидатов делим на две кучки: что пользователь уже покупал и что нет. У них слишком разная природа «релевантности», чтобы валить в один пул. Ранжируем их отдельно.

В итоговую подборку едут два топа из истории и семь новинок. Пропорция продуктовая: немного знакомого, чтобы зацепить и не выглядеть случайно, и побольше нового, чтобы человек не упирался в свой стандартный чек.

А сверху лежит классическая user-level-uplift-модель

Она появилась не сразу: первая итерация фичи поехала в A/B вообще без неё, и уже на данных этого эксперимента мы обучили uplift поверх. Сейчас она отрезает ≈10% пользователей, которым скидка ничего не двигает. Так мы превращаем «скидку всем» в чуть более таргетированный инструмент, причём ровно на тех данных, которые сама фича и сгенерировала.

Скидка живёт только внутри подборки

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

Что в итоге

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

Подписывайтесь:
@Yandex4ML
@YandexML

Вызываем вас на Yandex ML Challenge

21 мая стартует наше соревнование для всех, кто готов к самым серьёзным вызовам в ML. После длинного онлайн-тура 100 человек с самой высокой суммой баллов пройдут в финал — победителей наградим на главной сцене фестиваля Young Con в Москве.

Только актуальные темы машинного обучения: CV, LLM и RL

Свобода экспериментов: у вас будет 40 попыток на каждую задачу тура, чтобы протестить самые смелые идеи

Высокие ставки: победитель заберёт 1 миллион рублей, а топ-15 финалистов — набор умных устройств

Регистрация и Q&A

Подписывайтесь:
@Yandex4ML
@YandexML