AI VK отказались от бустинга в рекомендациях в пользу нейросетей. Вместо одного итогового скора новый ранкер отдельно предсказывает вероятность лайка, дизлайка и время просмотра. Затем эти сигналы объединяются через Learning to Rank, который отвечает за финальную сортировку ленты. В основе ранкера собственная архитектура DCDN, построенная поверх Deep & Cross Network. В нее на уровне архитектуры добавили операцию деления, поэтому модель сама выучивает признаки вроде CTR из сырых счетчиков, без ручного feature engineering.  Интересно решили предсказание времени просмотра. Вместо MSE и одного среднего значения модель учит распределение, разделяя быстрые скипы и долгие просмотры. После внедрения такого подхода в VK Клипах общее время просмотра выросло на 5,5%, лайки на 5%, шеры на 15%. Инженерам из рексис рекомендуем почитать полный разбор.

KDD’26, день четвертый. Сегодня в основном вел закулисные разговоры, про которые не могу ничего рассказать. А вот про что могу: 1. Доклад от команды YouTube и GDM. Классический формат выступления, когда они рассказывают про свои новые статьи. Судя по всему, у них прям очень жестко цензурируются любые рассказы наружу, ничего лишнего упоминать нельзя, поэтому они придерживаются формата пересказа уже опубликованных статей. Держите еще одно название для кандгена — nomination. А для преранжирования — prescoring. А группировку айтемов в выдачу в докладе нарекли packing. В рамках доклада выступало поочередно четыре человека. Сначала был рассказ про knowledge distillation в ранжировании: * упоминали две свои более старые работы — Bridging the Gap: Unpacking the Hidden Challenges in Knowledge Distillation for Online Ranking Systems и Zero-shot Cross-domain Knowledge Distillation: A Case study on YouTube Music * и как раз на KDD’26 у них вышла новая статья — Addressing Intent Dissonance in Cross-Domain Distillation on YouTube. Кто первый прочитает, напишите в комментариях что там :) Затем был раздел про анализ последовательностей: * упоминали нашу любимую Top-K Off-Policy Correction for a REINFORCE Recommender System, а также оригинальный YoutubeDNN, в котором впервые предложили next watch prediction * затем показали свою новую работу ClockRoPE: Random Fourier Rotations for Temporal Routine Modeling, в которой, как я понял, сделали time-aware RoPE, то есть учли время при анализе последовательности * и еще одну новую работу Tokens are All You Need: Dual-purpose Semantic IDs for Achieving LLM-Level I/O Efficiency in recommendation systems. Заменили в рекомендательной нейросети эмбеддинги на семантические айдишники Потом говорили про LLM x RecSys: * упомянули TIGER, а также статью про semantic IDs для ранжирования в YouTube, PLUM, STATIC * Token Factory: Efficiently Integrating Diverse Signals into Large Recommendation Models. Заменили в LLM семантические айдишники на эмбеддинги :) * LLM-Based User Personas for Recommendations at Scale. Используют LLM для exploration с помощью генерации новых для пользователя интересов * TokenMinds: Pretrained User Tokens and Embeddings for User Understanding in Large Recommender Systems. Делают семантический айдишник пользователя. У меня в этом году студент такую дипломную работу в бакалавриате вышки защитил)) Последняя, четвертая секция называлась Gemini Commercial Intelligence: * это как раз работы команды Derek Cheng, подарившей миру DCN-v2 * как и писал в прошлом посте, делают ИИ-ресерчера, который их заменит (ну и нас тоже, за компанию). Прикладываю статьи ниже * AgenticTagger: Structured Item Representation for Recommendation with LLM Agents * PACEvolve: Enabling Long-Horizon Progress-Aware Consistent Evolution * PACEvolve++: Improving Test-time Learning for Evolutionary Search Agents * также активно занимаются бенчмарками для этого ИИ-ресерчера. Статья Evo-Memory: Benchmarking LLM Agent Test-time Learning with Self-Evolving Memory * еще делают модель, которая по набору товаров будет генерировать рекламу, в которой эти товары присутствуют. Звучит немного рандомно, но в тему коммерциализации укладывается 3. Был доклад от Федора Борисюка про эволюцию ранжирования в Линкедине. Подсвечу лишь статью Semantic Search At LinkedIn; вроде как это их главная работа про ранжирование на текущий момент. Федор, как всегда, первый автор :)

Отделяем текстовый скоринг от продуктового ранжирования Как оказалось, научить поисковый движок находить релевантные документы = только половина задачи. Следующий вопрос в том, какие из найденных совпадений важнее для конкретного продукта. Окей, движок уже умеeт строить индексы по нескольким полям (title, abstract и т.д.) и поддерживает разные типы поиска: например term, phrase, prefix, фразовый поиск. Но после поиска вклад каждого совпадения просто добавлялся в итоговый вес документа. Например, для запроса`title:diabetes abstract:"type 1" abstract:insulin*` мы находили три независимых совпадения: • term - diabetes в title; • phrase - "type 1" в abstract; • prefix - insulin* в abstract. Для каждого совпадения BM25 считал свой вес, после чего все веса просто суммировались: BM25 total doc score = BM25(title:diabetes) + BM25(abstract:"type 1") + BM25(abstract:insulin*) Базово текстовая релевантность оценена за счет частоты термина, его редкости среди всех документов, длине поля. И это ок, но продуктово мы помимо всего знаем, что совпадения в заголовке обычно важнее совпадения в abstract, и что точная фраза часто ценнее совпадения по одному слову (или хотя бы по префиксу). Поэтому я подсмотрела идею с Rank Profiles - добавлением правил ранжирования по заданым критериям, который добавляет веса нужным докам без переиндексации. Пример профиля из конфига: rank_profile: name: debug-weights field_weights: title: 1.5 query_type_weights: term: 1.5 phrase: 1.7 prefix: 0.5 Теперь BM25 по-прежнему считает базовый score каждого совпадения, но перед суммированием вклад умножается на коэффициент: document score = BM25(title:diabetes) × 1.5 × 1.5 + BM25(abstract:"type 1") × 1.0 × 1.7 + BM25(abstract:insulin*) × 1.0 × 0.5 Поскольку индекс уже хранит информацию о каждом найденном совпадении (поле, тип запроса и базовый вес), политику ранжирования теперь можно менять прямо во время поиска - без переиндексации документов с явным разделением ответственности: • основная retrieval часть находит совпадения и сохраняет их контекст; • BM25 считает базовую текстовую релевантность; • Rank Profile задает правила, по которым совпадения влияют на итоговый вес документа; • Explain разбивка помогает понять, почему документ получил именно такой вес. Чтобы было проще отлаживать ранжирование, добавила Explain-панель. Для каждого документа можно посмотреть, из каких вкладов сложился итоговый вес: какое совпадение сработало, в каком поле, какой базовый вес посчитал BM25, какие коэффициенты применились и какой вклад каждое совпадение внесло в итоговый результат. На скрине из TUI (который, кстати, был тщательно причесан и допичкан инфо панельками) как раз видно такую разбивку по весам для каждого найденного документа. Сейчас Rank Profile умеет учитывать поле документа и тип совпадения. В дальнейшем список сигналов можно расширить: например, добавить свежесть документа, популярность или поведенческие сигналы (клики пользователей). Главное, чтобы поисковый движок умел вычислить такой сигнал - тогда его можно включить в ranking pipeline без изменения индекса. В итоге базовый текстовый скоринг остается отдельным слоем, а продуктовая логика ранжирования начинает жить поверх него. Это позволяет менять стратегию ранжирования, не меняя сам индекс.