Фазовый переход в использовании памяти: что это открытие значит для AI-разработчиков? 🟪 Вы когда-нибудь замечали, что в одних задачах LSTM или Transformer с памятью работают идеально, а в других – только жгут ресурсы без улучшения качества? Оказывается, выбор между «хранить историю» и «действовать по текущему моменту» – это не плавная настройка, а настоящий фазовый переход первого рода (как таяние льда). И его можно предсказать аналитически. 🪨 Новая статья в Physical Review Letters (плюс 19 страниц матана в Supplemental) даёт чёткие критерии, когда память выгодна, когда нет, а когда возможен гистерезис. Гистерезис – это когда состояние системы зависит не только от текущих параметров, но и от того, как вы к ним пришли (от истории изменения). Модель в двух словах. Попытался 📦 всю жесть из материала сублимировать 😐, вышло, как вышло. Не обессудьте. Итак... Есть скрытое состояние x(t) – например, концентрация питательного вещества. Вы получаете зашумлённое наблюдение: y(t) = x(t) + шум. У вас есть внутренняя переменная z(t) – память, которая эволюционирует по закону: z = v(t) + шум памяти, где v(t) – это управление: вы сами решаете, как менять память. За использование управления вы платите штраф Mv^2, прям как кинетическая энергия, чем больше вы «дёргаете» память, тем дороже. Одновременно вы хотите минимизировать ошибку оценки E[(x - x') ^2] с весом Q. Итоговая функция потерь: J = Q×ошибка + M×затраты на управление. Задача – выбрать стратегию v(y,z), которая минимизирует J в стационарном режиме. В машинном обучении мы часто добавляем L2-регуляризацию: loss = ошибка + lambda*|w|^2. При увеличении lambda веса плавно стремятся к нулю. Здесь параметр M играет роль lambda: чем больше M, тем дороже использовать память, и казалось бы, при больших M коэффициент при памяти должен плавно уменьшаться до нуля. Но здесь есть две связанные переменные (текущее наблюдение и как память на себя же влияет), которые влияют на поведение системы и друг на друга. Они не независимы. Оптимизация потерь J по этим двум переменным приводит к тому, что на их плоскости, могут существовать два локальных минимума – с памятью и без. Между ними – горный хребет (седловая точка). Когда параметры (например, M) меняются, один из минимумов может исчезнуть или стать глобальным. В момент исчезновения система скачком перескакивает из одной ямы в другую – это и есть фазовый переход. Суть открытия на пальцах. Представьте агента, который наблюдает за шумным сигналом и может хранить внутреннее состояние z. Обновление z стоит ресурсов (штраф M). Задача – минимизировать ошибку оценки при ограниченном бюджете. Авторы доказали: · Существуют два порога Thet_Q и Theta_M: · Если Theta_Q < 1 — память точно бесполезна (даже локально). · Если Theta_M >=1 — память всегда выгодна (глобальный оптимум). · Между ними – бистабильность: обе стратегии локально оптимальны, выбор зависит от истории (гистерезис). А теперь разбираем, что из этого можно вынести для AI. 🥴 1. Оптимизация архитектур с памятью (LSTM, Transformer, RNN) Современные модели с памятью, например, трансформеры с окном внимания или LSTM, всегда используют память, даже когда она не нужна. Результаты подсказывают: · При высоком шуме в данных память становится бесполезной – лучше полагаться только на текущий вход. Это объясняет, почему в некоторых задачах обрезка контекста (например, короткое окно внимания) не ухудшает качество. · При быстро меняющейся среде прошлая информация устаревает – нужно динамически уменьшать размер буфера или использовать забывание, как в LSTM, но с адаптивным коэффициентом. 2. Регуляризация и штраф за сложность в RL. В RL агент часто хранит внутреннее состояние например, в PPO. Штраф Mv^2 в статье – аналог штрафа за изменение скрытого состояния. Это можно использовать: · Как регуляризатор в функциях потерь, чтобы поощрять агента использовать память только когда это действительно выгодно. · Аналитические пороги Theta_Q,Theta_M помогают автоматически подбирать коэффициент регуляризации M без дорогой сетки гиперпараметров – просто по статистике шумов среды. Это особенно полезно в Meta-RL, где среда меняется между эпизодами. 3. Continuous Learning и катастрофическое забывание. В задачах continual learning модели должны сохранять знания о прошлых задачах, но обновление памяти (весов) стоит ресурсов. Аналогия: · Параметр M – штраф за изменение весов. · Фазовый переход означает, что при превышении порога штрафа модель перестаёт обновлять веса вообще – т.е. замораживает их. Это даёт критерий, когда лучше полностью остановить обучение (если среда не меняется) или, наоборот, разморозить (если волатильность растёт). На практике это позволяет строить адаптивные стратегии обновления – не тратить ресурсы на веса, которые не нужны. Вот такое интересное исследование. Читайте полную версию, применяйте открытие, и stay tuned 🦾

​​Talk: breaking into machine learning - recording Пару дне назад я уже писал, что я буду делать доклад для пакистанских студентов. В общем получилось так, что на него зарегистрировалось 450+ человек, несмотря на то, что это был праздник - день независимости. Встреча была в google meets, но там лимит в 100 человек, так что все желащие не влезли. В результате делали трансляцию в linkedin, запись можно посмотреть тут https://www.linkedin.com/events/liveaugust147494045235434594306/ Вопросы были в основном про карьеру - как её начинать, что делать в текущей ситуации с засилием AI, как вкатываться в сферу и так далее. Думаю, скоро напишу блогпост про это, чтобы мысли были не только в записи. Сам доклад шёл 40 минут, потом я ещё 40 минут отвечал на вопросы. #career #ai #datascience

Вышел технический репорт о Sona – модели, которая заменила весь рекомендательный стек Яндекс Музыки https://arxiv.org/abs/2608.11015 Эта модель – итог целого года работы. И это лучшее внедрение трансформеров в истории А/B-тестов в Яндекс Музыке. Но главное здесь, что Sona – это одна модель. До этого продакшн-каскад рекомендаций Яндекс Музыки включал в себя 15+ генераторов кандидатов плюс ранжирование на сотнях ручных фич. И это все заменили единой моделью, обучаемой end-to-end. Это даже звучит сложно, а на деле несет за собой еще больше проблем и нюансов, чем может показаться на первый взгляд. Вот три центральных момента: 1️⃣ Раньше, в подходах типа OneRec, ранжирование считала отдельная модель на ручных фичах. Sona же должна была стать единым рецептом обучения и инференса, то есть декодер (который генерирует кандидатов) и ранкер (который их ранжирует) должны использовать один и тот же энкодер user-эмбеддингов, которые рассчитываются один раз за запрос. А значит – надо обходиться без ручных фич. Но проблема в том, что явный сигнал (лайки, репиты) довольно редок, чтобы выучить ранжирование напрямую. Поэтому тут встроена дистилляция. Сначала обучали Teacher Ranker. Это большая, медленная, но очень умная модель, которую тренили аж на годе логов. Она не используется в проде и нужна для того, чтобы научить шустрый Ranking Module воспроизводить ее скоры. 2️⃣ Так как Sona – это encoder-decoder, обучаемый хронологически на Next Token Prediction, каждый трек нужно представить в виде токенов. Это называется Semantic ID. И тут кроется парадокс: чем больше растет словарь токенов, тем модель должна быть умнее, но на самом деле она просто не успевала эффективно использовать возросшее пространство и деградировала. Поэтому одной из самых сложных частей было сделать рецепт токенизации, который бы обеспечивал рост качества при росте словаря. Дьявол кроется в деталях. 3️⃣ Ну и, конечно же, инфраструктура. Переход на одну модель потребовал фактически нового движка рекомендаций, включая сложный online learning pipeline. Кроме того, авторегрессивная генерация с длинными историями – это дорого, и поэтому пришлось прорабатывать отдельные архитектурные трюки (History Compression, кастомные CUDA-кернелы, radix top-k), просто чтобы уложиться в приемлемую латентность. Ради чего была вся эта огромная работа? На этот вопрос хорошо отвечают метрики. Sona принесла: +4,53% Active Users, +6,30% Total Listening Time и +11,42% Likes. Причем это прирост поверх улучшений от предыдущих внедрений, которые оставались в контрольной выборке в продакшне. В планах у команды – масштабирование, добавление RL и, конечно, раскачивание Sona на полный трафик. Поздравляем ребят с грандиозными результатами!

KDD’26, день первый. На конференции собралась индустриальная тусовка — приехали ключевые рекомендательные команды из вообще ВСЕХ больших компаний. 1. Сходил на первую половину Tutorial on Generative Recommendation: Foundations and Frontiers от Kuaishou и City University of Hong Kong. Выделили два (будущих?) тренда: * если изначально все использовали encoder-decoder модели для генеративного ретривала, потому что в них было удобно впихивать богатый контекст; то сейчас двигаются в сторону decoder-only моделей, которые лучше скейлятся * диффузионные подходы, при которых мы предсказываем сразу все семантические токены целевого айтема — очень перспективное направление, которое позволяет избавиться от аккумуляции ошибок при авторегрессивной генерации токенов После кофе-брейка я на туториал не вернулся, потому что: * были супер энциклопедические слайды, на которых просто перечислялось много статей по паре минуток каждая, очень поверхностно, без инсайтов, с неточностями * при этом не было живого рассказа - весь текст просто зачитывался. Надеюсь, потом выпустят с этим текстом техрепорт)) Ну а если серьезно, то проще потом слайды полистать, наверняка какие-то инсайты все-таки будут ближе к концу рассказа 2. Пообщались с Федором Борисюком. Когда возле него осталась только наша русская компашка, Федор сам первый перешел на русский язык :) Что рассказывал: * если я все правильно понял, он сейчас руководит тремя командами. Что-то возле поиска и рекомендаций * статьи пишут по выходным. К процессу привлекается большое количество коллег. Федору просто нравится писать статьи и прокачивать репутацию, а у коллег есть мотивация участвовать как минимум чтобы получить грин-карту)) * сам Федор сторонник того, чтобы на работе со всеми уважительно и дружелюбно обращаться, налаживать хорошие отношения. И максимально коллаборироваться, делать совместные проекты. Но говорит, что это иногда приводит к плохим последствиям, во время политических игрищ * у него всегда часть проектов долгосрочные, а часть краткосрочные. Долгосрочным как правило занимается небольшая команда из 2-3 человек. Если проект планируется на год-полтора (больше бизнес вряд ли вытерпит), то расставляются майлстоуны на каждые полгода с оффлайн-метриками * если попался плохой руководитель, то надо просто ротироваться и не мучаться :) * через полтора месяца должен быть дроп крутой новой статьи от Линкедина 3. Воркшоп Two-sided Marketplace Optimization: Search, Discovery, Matching, Pricing & Growth. Было выступление от Director of Research @ Spotify, Paul Bennett — From User Needs to Ecosystem Design: How AI Is Reshaping Discovery. Рассказывал про разные сценарии, в которых применяют LLM: * steerable recommendations — тюнят модель с помощью контрольных токенов выдавать familiar (пользователь уже взаимодействовал с подкастом >10 минут за последний месяц) и unfamiliar (обратная ситуация) контент в рекомендациях. Похоже на мою идею с обуславливанием, про которую рассказывал на Turbo ML Conf 2025 * Intent-aware search — в поиске есть разные сценарии; иногда нужно просто включить рекомендации с какими-то настройками, иногда запустить реальный поиск, иногда просто найти артиста, иногда что-то еще. LLM можно использовать как router, который определяет в какой api (recs/search/etc) нужно отправлять запрос * Conversational discovery — часто пользователь сначала сам не понимает какие ему нужны рекомендации; и только в процессе взаимодействия с рекомендательной системой начинает понимать чего все-таки хочет. И для этого как раз multi-turn диалог, в котором он может и промежуточные рекомендации получить, и пообщаться с рексистемой 4. Что еще: * на конференции 70+ русскоговорящих участников, это очень много. Много людей со статьями, а еще есть студенты с ИИ360 программы. Жутко им завидую, меня бы кто на первом-втором курсе на конференцию отправил! Говорят, что ничего непонятно, но все очень вдохновляет) * все офигевают от джетлага * даже в Линкедине (!) разработчики слушают наш DeepRecsys курс :)

🍏 MLX: как Apple меня купила и почему я переплатил за 32 GB MacBooka Вы могли заметить последнее время, что абсолютно все в интернете сошли с ума с этими mac mini и мне кажется, что нам стоит поговорить почему. Как уже понятно из названия имя этому почему MLX — фреймворк для машинного обучения, разработанный командой Apple Machine Learning Research 🧠 В чем магия? Если вы когда-нибудь работали с PyTorch на NVIDIA, вы знаете про вечную боль: .to('cuda'). Вы постоянно перекладываете данные из оперативной памяти (RAM) в видеопамять (VRAM). Шина PCIe — это узкое горлышко. В Apple Silicon архитектура объединенная (Unified Memory Architecture). И MLX — это первый фреймворк, который использует её «нативно»: 1. Zero-copy: В MLX нет копирования данных. Массив (mlx.core.array) просто лежит в памяти, и CPU, и GPU работают с одними и теми же байтами по одному адресу. Это убирает огромный оверхед на передачу данных. 2. Lazy Evaluation: Как и JAX (the Google Python library for machine learning and array computing, хз почему именно такая аббревиатура), MLX «ленив». Он не считает ничего, пока вы не попросите результат. Он строит граф вычислений и оптимизирует его: например, объединяет несколько операций в одно ядро (kernel fusion), чтобы лишний раз не дергать память. 3. Metal-First: Библиотека написана на C++ специально под Metal API. Она умеет выжимать максимум из AMX (Apple Matrix Extensions) — секретных блоков внутри чипа, которые созданы исключительно для перемножения матриц. Так что даже я, как былой адепт запускания чего угодно на чем угодно и потом кручения моделек на этом был просто вынужден купить мак на 32 гб, так как убежден, что это прожиточный минимум, а по цене более мощных мини я уже могу себе на тенсоррентах побаловаться #AI @techn0danya

​​Time Series with PyTorch — Graeme Davidson, Lei Ma Мне прислали очередную книжку от Packt на прочтение и ревью - на этот раз про time series forecasting на PyTorch. Тема мне близкая: временные ряды — одна из самых сложных для меня областей ML, и при этом большинство книг по deep learning относятся к ним как к чему-то второстепенному после CV и NLP. Книга идёт начинает с базовых вещей (что делает временные ряды сложными, как правильно оценивать модели, PyTorch с нуля), демонстрирует современные архитектуры (RNN, transformers, N-BEATS, N-HiTS, foundation models, diffusion) и выходит за пределы точечного прогноза — классификация, кластеризация, anomaly detection, self-supervised learning. Мне понравилось, что тема правильного качества моделей разбирается в деталях: например, показывают как заведомо худшая модель выигрывает по MAPE, и есть целая глава про data leakage. Отдельно порадовали объяснения через физику: один из авторов физик, и он объясняет RNN через качели на детской площадке, а diffusion — через каплю чернил, которая расплывается в воде, пока не превратится в гауссиану. Ещё мне понравилось, что примеры построены вокруг соревнования M5 на Kaggle. Я в нём когда-то участвовал и зафейлился, так что было интересно посмотреть на разные модели и подходы к оценке на данных, с которыми в своё время намучился. Из минусов — про time series foundation models (Lag-Llama, TabPFN, Chronos, TimeGPT) рассказывают, но не запускают их на практике, а это как раз то, что хотелось бы попробовать руками. Amazon Author's website Code Мои обзоры: Personal blog Medium #bookreview

Где-то два с половиной года назад на конференции по рексистемам в Вышке, куда я пришел слушателем (так появилась секция кулуары, которой, кстати, давно не было), мне задали вопрос — почему у нас нет научных публикаций. Я ответил, что у ребят в Яндексе, занимающихся рексистемами, нет KPI на статьи — только KPI на внедрения. При этом я, конечно, не воспринимал вопрос лично, но сам уже долгое время горел идеей писать статьи, публиковаться на конференциях, участвовать в жизни научного сообщества. Через год я съездил на свою первую большую конференцию ACM RecSys’24. Про эту поездку есть целая серия постов; нетрудно понять, что мне очень понравилось)) Был даже маленький забавный моментик, когда я во время выступления Эда Чи что-то спросил, а он ответил “А может, вы про это статью и напишете” :) После всего этого я еще больше укрепился в решимости начать писать статьи. KPI не то чтобы после этого поменялся, но как будто подвернулся хороший момент, чтобы попробовать. Мы разработали и внедрили в Яндекс Музыку большую рекомендательную трансформерную модель (тот самый Аргус); и казалось логичным превратить это внедрение в статью. Затем, при подготовке лекции для ШАДа про LogQ коррекцию для двухбашенных моделей, я обнаружил ошибку в широко используемой по всему миру формуле. Когда я принес своим ребятам выкладки, далеко не все сразу поверили, что такое вообще возможно)) Было крайне нетривиально одновременно работать фуллтайм, преподавать новый курс в ШАДе и при этом еще и писать сразу две статьи. Но каким-то образом все получилось, и примерно год назад у нас сначала приняли на ACM RecSys’25 статью про LogQ коррекцию, а затем спустя еще полгода приняли на ACM KDD'26 статью про Аргуса. И вот я радостный стою уже 7 часов возле постера на рексисе и рассказываю всем окружающим про LogQ коррекцию)) А потом ночью в караоке пою Radiohead Creep в толпе рексисоидов И самое крутое, что мы на этом не остановились: * на тот же ACM RecSys’25 была принята работа про датасет Yambda, в которой я лично не участвовал, но поучаствовали ребята из нашей команды — Влад Тыцкий и Владимир Байкалов * на ACM SIGIR приняли статью Владимира Байкалова и его студентов из ИТМО про дообучение семантических айдишников * туда же на ACM SIGIR приняли статью от ребят из нашей (бывшей) команды — Артёма Матвеева, Влада Тыцкого, Сережи Макеева и Сережи Лямаева, про улучшение архитектуры энкодер-декодера для generative retrieval Ну и вот сейчас у нас приняли статью на воркшоп ACM KDD’26, продолжающую линию ресерча из статьи Top-K REINFORCE (я периодически шучу, что надо было её назвать "Correcting the Off-Policy Correction" в духе нашей LogQ статьи) и скрещивающую ее с generative retrieval. Про нее я написал в прошлом посте. Кроме того, на архиве появились препринты, про которые смею надеяться, что они дойдут до публикации: * мой Variable-Length Semantic IDs * Gryphon от ребят из Яндекса, в котором поучаствовали Олег Сорокин и Влад Додонов из нашей бывшей команды (читайте подробности про статью на канале Даши @redrecsys) И все это произошло только за последний год! Хочется верить, что мы только в начале нашего пути и нас всех ждет еще миллиард параметров приключений и публикаций :)

Подборка методов улучшения LLM На этот раз собрали несколько статей на тему обучения и инференса LLM. Ожидаемо, эта область на ICML 2026 — самая популярная и обсуждаемая. Rethinking the Trust Region in LLM Reinforcement Learning Сингапурские учёные рассматривают проблему нестабильности GRPO-like-алгоритмов. Авторы связывают её с асимметричностью применяемого клиппинга относительно абсолютного значения правдоподобия сгенерированной траектории. Разброс значений IS (очень шумной оценки trust region в PPO) снижается с ростом вероятности, вследствие чего клиппинг чаще срабатывает на высокоэнтропийных генерациях. Эту проблему уже частично лечили в DAPO, повышая правую границу клиппинга. Здесь же предлагают перейти к более точным оценкам trust region: через KL-отклонение по полному словарю, по top-K или через альтернативную, но более подходящую односемпловую оценку. В экспериментах показывают более стабильное обучение. Кроме того, в статье много аблейшнов и интересных выводов. Don't Force the Fit: Bounded Log-Likelihood Loss for Enhanced Reasoning in Large Language Models Очный доклад о модификации SFT-лосса для обучения на ризонинг-задачах. Предлагают перейти от классической кросс-энтропии L = - log p к ограниченной в нуле: L = log (2 - p). На высоковероятных токенах градиент нового лосса приближается к классическому CE, а вот на низковероятных — не улетает в бесконечность, а ограничен небольшим значением. Мотивация такого подхода в том, что в ризонинг-цепочках есть множество высокоэнтропийных токенов, которые отвечают скорее за «стиль» рассуждения, но не влияют на его качество. При этом они отбирают значимую часть обучения, не давая как следует обучиться действительно важным токенам. Приросты на графиках выглядят неправдоподобно большими. Sparser Block-Sparse Attention via Token Permutation Ресёрчеры решают проблему long-context-префилла: full attention дорогой, а обычный block-sparse attention не всегда хорошо работает, потому что важные key-токены размазаны по разным блокам. Идея PBS-Attn: перед block-sparse attention переставить K/V-токены так, чтобы важные токены оказались рядом. Аттеншн не меняется при одинаковой перестановке K/V, зато sparse-блоки становятся более плотными и полезными. Из-за каузальной маски нельзя перемешивать всё подряд, поэтому авторы делают перестановку внутри сегментов. Это сохраняет авторегрессивность, но всё ещё позволяет «дефрагментировать» матрицу аттеншна. Плюс в том, что это не новая архитектура. Можно взять предобученную модель, добавить permutation и block-sparse-кернел и ускорить long-context-инференс. На LongBench качество почти такое же, как у full attention, и лучше, чем у других бейзлайнов. По скорости заявляют до 2,75× ускорения на long-context-префилле. Critique-GRPO: Advancing LLM Reasoning with Natural Language and Numerical Feedback Ещё один подход к тому, как делать критику в GRPO. На сложных бенчах обучение в какой-то момент начинает стагнировать. Авторы предлагают добавить reward-модель, которая будет писать критику ответа актора. Затем эта критика подаётся модели вместе со старым ответом, и модель пишет ответ лучше. После этого даунсемплят такие аугментированные примеры и конкатят их с обычными. На сете семплов с критикой модель учат сразу на улучшенный ответ — без промежуточной критики и первого ответа, как будто это изначально была такая генерация. На математических и научных бенчах (AIME, MATH, GPQA) получают приросты от 7 до 12 пунктов. Спросил автора, как бы он внедрял это в агентный RL. Он сказал, что, по его мнению, у модели должна быть тула «покритикуй мою текущую траекторию». Интересный подход. Личное мнение: непонятно, насколько вообще критика в RL полезна. Как будто правильнее решать проблемы, которые она пытается закрыть, другими способами. Увидели интересное ❣ Алексей Зотов, Влад Тыцкий и Тимофей Смирнов #YaICML2026 Душный NLP

В большинстве своем при поиске latency метрик мы находим общую latency = написал текст/сказал текст и получил аудио обратно. Однако за этим стоит не только большая доля инженерии, но и модули модели. Метрики, которые мы здесь рассмотрим: • FTL - first packet latency • TPP - first packet decode • DEC - mean packet decode • FPL - first packet latency • RTFx - audio_duration / processing time - общий throughput пайплайна Чаще всего работаем с пайплайном: текст -> LM based TTS - - - > audio codebook tokens - - - -> Codebook based Vocoder FTL - это путь от текста к первому audio codebook token. Это может быть как и один токен, который генерит большая модель, так и sequence токенов, которые генерит какой-то depth transformer, а может быть вообще multi-token generation от главной модели. Так или иначе на выходе только дискретный токен / латентный вектор. На эту метрику влияют кроме всех прочих приколюх модели и параметры интеренса. Например, сколько буковок вообще нужно ждать, чтобы начать генерить. Или сколько буковок передавать как lookahead, чтобы аудиотокены получались лучше. TPP - это путь только вокодера. Получили аудио токены - получили первый audio patch. У этого пути может быть отдельный cuda stream. Здесь также главную роль играют "accumulation" параметры. Например, сколько токенов нужно подсобрать чтобы сделать один pass вокодера? —— Но также именно здесь есть важный дизайнхук, который всегда люди делают по-разному. Как декодировать последовательность, чтобы не было странных звуков между патчами😒 Многие это делают декодируя всю предыдущую последовательность. Кто-то собирает n прошлых секунд и отправляет именно их. Кто-то использует kv cache, что часто идентично. Каждый из них влияет на latency. Именно это design choices отражаются на DEC метрики, так как один пасс через vocoder может потом линейно вырости и будет казаться, что вокодер вместо 50ms почему-то стал тратить 200ms, а все потому что мы передали ему весь предыдущий контекст. —— Все метрики выше влияют на FPL, как раз то, что большинство юзеров называют latency. Или вот эта задержка между тем как вы что-то сказали и бот ответил вам в ответ (здесь мы считали только TTS часть). Большинство компаний стремятся к тому, чтобы это значение latency было меньшее 100ms 😌 В борьбе за этим что только можно и нельзя использовать. При этом важно и смотреть на общий RTF, так как многие (в том числе и я) могут занижать FPL с помощью более маленького контекста, lookeahead'a и тд, а потом уже кормить модель нормальным контекстом🙂. Ну и конечно мы оставляем за большими скобками хитрые вещи по типу filler words или заготовленные фразы, чтобы не казалось что модель долго думает.

А с каким latency говорите вы? Я иногда с 300ms, а иногда с -100ms (ну знаете когда собеседник уже слишком тянет и ты все уже понял)

В силу своей работы в Okko я всегда с большим интересом читаю статьи от Netflix. Эта показалась мне особенно любопытной - как минимум сама идея. Главная страница Netflix представляет собой двумерную сетку: горизонтальные полки и айтемы внутри каждого. В базовом варианте главная собирается мультистадийно: отдельно ранжируются коллекции, отдельно - элементы внутри них, и далее все это сшивается по базовым правилам. Зачастую у каждой стадии своя модель и свой таргет - между ними нет связи: нельзя модельно определить, если верхний row уже содержит новинки, значит в следующем нужно подобрать нишевый контент. Отсюда идея GenPage: Towards End-to-End Generative Homepage Construction at Netflix: пусть всю страницу формирует одна авторегрессионная модель. Промпт - история и контекст юзера, ответ - вся страница целиком: row_id, item_id и их порядок в одном сиквенсе. Тогда каждое следующее предсказание принимается с оглядкой на все, что уже простроено на странице выше - ровно та связность, которой нет в классическом варианте. На этапе претрейна обычный next-token prediction. В обучающих цепочках лежат показы с позитивной интеракцией с главной страницы - таким образом модель уже на этапе предобучения начинает понимать специфику формирования main page. Дообучение представлено в двух вариантах. Первый, Weighted Binary Classification, смотрит на каждый показанный айтем на главной по-отдельности: если полный досмотр - большой вес, если watch time небольшой -  вес меньше. Модель учат для каждой позиции оценивать, насколько ценно поставить туда именно этот айтем. Правда такой подход все еще не решает проблему совместного формирования главной. Второй вариант (через офлайн RL) оптимизирует reward всей страницы целиком. Сначала обучают отдельную модель, которая предсказывает, насколько хороша любая сгенерированная страница. Регрессионная модель обучается на таргет суммы зависящих от watch time reward значений (досмотр до конца - большой плюс, скип - большой минус). Дальше для одного юзера сэмплируют несколько кандидатских страниц и оптимизируют модель с учетом такой прокси оценки reward. В АБ подход с WBC дал статзначимый прирост неназванной метрики engagement +0.24% и заодно оказался на 20% быстрее, из-за того что выкинули несколько стадий ранжирования, плюс авторегрессионно предсказывают только часть айтемов, оставшиеся - одним forward pass. RL в АБ не завели, утверждают что на офлайн оценках растет разнообразие и средний reward. Что имеем по итогу? Техрепорта конечно ждать не стоит, как и подробностей реализации. Результаты не прорывные и выглядят немного наспех собранными - не довели RL модель до АБ, хотя это такая же обученная модель в офлайне, подозреваю что в АБ-тесте просто были плохие метрики. Опять же, мне откликается идея генеративного UI на основе персонализации, ведь на стриминговых площадках обложки айтемов это и есть по сути главный визуал. Таким образом можно улучшать не только качество рекомендаций, но и пользовательское восприятие сервиса.