Сам по себе рост времени мы действительно не считаем достаточным доказательством того, что рекомендации стали лучше. Мы смотрим на набор метрик одновременно: лайки, подписки, скипы, жалобы и другие сигналы. Важно не просто, что TS вырос, а как меняется взаимодействия с контентом.
Например, в том же эксперименте с композитным мультитаргетом вместе с ростом времени выросли лайки и другие положительные действия, а скипов стало меньше. Если бы время росло на фоне роста скипов или негативного фидбэка, интерпретация результата была бы совсем другой.
Поэтому +11% здесь скорее суммарный продуктовый результат, а не единственный критерий качества. В самой статье как раз пытались показать, какие изменения в рекомендациях стоят за этой цифрой.
Доля токенов реального аудио. Вы были бы правы, при условии, что у нас большое кол-во агентов под разные типы токенов. Однако у нас их кол-во сильно ограничено, поэтому ожидается, что мы разделим всё наше пространство токенов на равные части (с учётом их распределения во время обучения)
Здесь используется гибридный подход: в DCDN применяются эпсилон и сглаживание, чтобы снизить влияние нестабильных значений при делении. Дальше полученные признаки поступают в Hiformer, который уже определяет их значимость в общей архитектуре.
При этом специально закладывать в Hiformer и DCDN механизм подавления именно таких шумных признаков мы не стали. Однако при анализе запусков увидели, что признаки, более склонные к шуму, действительно получают меньший вес. То есть на практике Hiformer дополнительно снижает их влияние, хотя изначально это не было отдельной архитектурной целью.
Мы смотрим на развитие рекомендаций шире, чем на улучшение отдельных моделей. Нам важно, чтобы система хорошо работала для всех: пользователю предлагала интересный контент, авторам помогала находить свою аудиторию.
В ближайших планах сделать рекомендации более гибкими и дать пользователю больше возможностей влиять на то, что он видит. Мы уже работаем над этим и чуть позже расскажем подробнее.
Мы пока не переводим наши приложения на Kotlett целиком, но уже пишем на нём большую часть новых фичей. По перформансу на текущем этапе полёт нормальный.
Так как весь рендеринг у нас остаётся в нативной части, его производительность и отзывчивость UI не уступают нативным фичам и превосходят возможности WebView. Также Kotlett позволяет размещать множество независимых фичей на одном экране без потери производительности, благодаря переиспользованию между ними одного инстанса JS рантайма. WebView всё-таки достаточно тяжеловесная сущность, чтобы размещать на экране большое количество её экземпляров.
Помимо этого мы уже сталкивались с проблемами, когда у некоторых пользователей Android-устройств WebView просто не работало. Подробнее об этом мы писали в статье Как и зачем мы затащили GeckoView в Почту.
В нашем случае от идеи WebView + бандлы решили отказаться, чтобы весь цикл разработки мобильной фичи мог остаться в руках одного разработчика. При использовании WebView для подобной разработки нужны двое - мобильный разработчик для реализации бриджей между JS и нативом и Web-разработчик для написания самой фичи. В случае с Kotlett весь функционал может быть написан одним мобильным разработчиком.
Потенциально DSL Kotlett для описания UI ничем существенно не ограничен и позволяет реализовать любые UI решения, доступные при нативной разработке. На текущем этапе, конечно же, он требует доработок, но при необходимости всегда может быть расширен. Kotlin Multiplatform нами был выбран как уже неоднократно опробованный в деле кроссплатформенный инструмент, а сам по себе язык уже является стандартом для Android разработчиков и дружелюбен для iOS (Swift) разработчиков. Адаптивность дизайна достигается за счёт специального сервиса (моста между JS и нативом), который передаёт в код фичи всю информацию о текущем контексте выполнения (размер, разрешение и ориентация экрана/тёмная тема/язык устройства и т.д.). На основании этих параметров формируются ресурсы с помощью которых и строится адаптивный дизайн. Этот механизм очень схож с механизмом ресурсов и адаптивного дизайна в нативной разработке Android.
Бандл загруженный в приложение по HTTPS кэшируется приложением и при последующих запусках уже может работать без подключения к сети. На случай отсутствия сети при первом запуске в приложении также есть вшитый бандл - когда сеть появится, бандл сможет обновится до более актуального. При такой схеме в приложении всегда имеется бандл с функционалом, который может работать в оффлайне
Если говорить про использование DivKit в чистом виде не только для отрисовки UI, но и для полного цикла работы фичи, возникает вопрос в том, как выполнять бизнес-логику (запросить данные из кеша/запросить обновление данных в кеше с сервера/считать состояние remote config'а и т.д.). Тут мы видим два варианта:
вынести всю бизнес-логику на бэкенд, который будет присылать только слепки экранов в приложение,
либо в схеме DivKit иметь экшны, которые будут запускать эту логику в нативе. В первом случае мы получаем схему описанную в статье, во втором мы можем доставлять динамически логику формирования UI, но лишаемся возможности доставлять всю бизнес-логику.
Сам по себе рост времени мы действительно не считаем достаточным доказательством того, что рекомендации стали лучше. Мы смотрим на набор метрик одновременно: лайки, подписки, скипы, жалобы и другие сигналы. Важно не просто, что TS вырос, а как меняется взаимодействия с контентом.
Например, в том же эксперименте с композитным мультитаргетом вместе с ростом времени выросли лайки и другие положительные действия, а скипов стало меньше. Если бы время росло на фоне роста скипов или негативного фидбэка, интерпретация результата была бы совсем другой.
Поэтому +11% здесь скорее суммарный продуктовый результат, а не единственный критерий качества. В самой статье как раз пытались показать, какие изменения в рекомендациях стоят за этой цифрой.
Доля токенов реального аудио. Вы были бы правы, при условии, что у нас большое кол-во агентов под разные типы токенов. Однако у нас их кол-во сильно ограничено, поэтому ожидается, что мы разделим всё наше пространство токенов на равные части (с учётом их распределения во время обучения)
Здесь используется гибридный подход: в DCDN применяются эпсилон и сглаживание, чтобы снизить влияние нестабильных значений при делении. Дальше полученные признаки поступают в Hiformer, который уже определяет их значимость в общей архитектуре.
При этом специально закладывать в Hiformer и DCDN механизм подавления именно таких шумных признаков мы не стали. Однако при анализе запусков увидели, что признаки, более склонные к шуму, действительно получают меньший вес. То есть на практике Hiformer дополнительно снижает их влияние, хотя изначально это не было отдельной архитектурной целью.
Мы смотрим на развитие рекомендаций шире, чем на улучшение отдельных моделей. Нам важно, чтобы система хорошо работала для всех: пользователю предлагала интересный контент, авторам помогала находить свою аудиторию.
В ближайших планах сделать рекомендации более гибкими и дать пользователю больше возможностей влиять на то, что он видит. Мы уже работаем над этим и чуть позже расскажем подробнее.
Мы пока не переводим наши приложения на Kotlett целиком, но уже пишем на нём большую часть новых фичей. По перформансу на текущем этапе полёт нормальный.
Так как весь рендеринг у нас остаётся в нативной части, его производительность и отзывчивость UI не уступают нативным фичам и превосходят возможности WebView. Также Kotlett позволяет размещать множество независимых фичей на одном экране без потери производительности, благодаря переиспользованию между ними одного инстанса JS рантайма. WebView всё-таки достаточно тяжеловесная сущность, чтобы размещать на экране большое количество её экземпляров.
Помимо этого мы уже сталкивались с проблемами, когда у некоторых пользователей Android-устройств WebView просто не работало. Подробнее об этом мы писали в статье Как и зачем мы затащили GeckoView в Почту.
В нашем случае от идеи WebView + бандлы решили отказаться, чтобы весь цикл разработки мобильной фичи мог остаться в руках одного разработчика. При использовании WebView для подобной разработки нужны двое - мобильный разработчик для реализации бриджей между JS и нативом и Web-разработчик для написания самой фичи. В случае с Kotlett весь функционал может быть написан одним мобильным разработчиком.
Потенциально DSL Kotlett для описания UI ничем существенно не ограничен и позволяет реализовать любые UI решения, доступные при нативной разработке. На текущем этапе, конечно же, он требует доработок, но при необходимости всегда может быть расширен.
Kotlin Multiplatform нами был выбран как уже неоднократно опробованный в деле кроссплатформенный инструмент, а сам по себе язык уже является стандартом для Android разработчиков и дружелюбен для iOS (Swift) разработчиков.
Адаптивность дизайна достигается за счёт специального сервиса (моста между JS и нативом), который передаёт в код фичи всю информацию о текущем контексте выполнения (размер, разрешение и ориентация экрана/тёмная тема/язык устройства и т.д.). На основании этих параметров формируются ресурсы с помощью которых и строится адаптивный дизайн. Этот механизм очень схож с механизмом ресурсов и адаптивного дизайна в нативной разработке Android.
Бандл загруженный в приложение по HTTPS кэшируется приложением и при последующих запусках уже может работать без подключения к сети. На случай отсутствия сети при первом запуске в приложении также есть вшитый бандл - когда сеть появится, бандл сможет обновится до более актуального. При такой схеме в приложении всегда имеется бандл с функционалом, который может работать в оффлайне
Если говорить про использование DivKit в чистом виде не только для отрисовки UI, но и для полного цикла работы фичи, возникает вопрос в том, как выполнять бизнес-логику (запросить данные из кеша/запросить обновление данных в кеше с сервера/считать состояние remote config'а и т.д.). Тут мы видим два варианта:
вынести всю бизнес-логику на бэкенд, который будет присылать только слепки экранов в приложение,
либо в схеме DivKit иметь экшны, которые будут запускать эту логику в нативе. В первом случае мы получаем схему описанную в статье, во втором мы можем доставлять динамически логику формирования UI, но лишаемся возможности доставлять всю бизнес-логику.