Forwarded from Information Retriever
ysda_neural_ranking.pdf
1.5 MB
Обещанные слайды лекции
👍5❤🔥2🔥2
Давайте познакомимся.
В IT мне интереснее всего...
В IT мне интереснее всего...
Anonymous Poll
14%
оптимизировать работу сервиса/модели на уровне железа
12%
настраивать доставку данных в хранилище/до модели
8%
Оптимизировать запросы между сервисами
44%
Тренировать классические ml алгоритмы (бустинги, леса, линейные модели...)
54%
Тренировать нейронки
34%
Руководить командой
40%
Масштабировать обучение моделей. Внедрять ml в прод
9%
Настраивать DevOps
Особенность в рекомендательных системах
Контекст
В последнее время основные статьи в рекомендательных системах связанны с применением нейронных сетей.
Выглядит это всегда примерно так для сценария u2i:
1) Есть айтем -> кодируем через nn.Embedding его фичи
2) История пользователя состоит из айтемов -> используем наработку из 1) + encoder/decoder (трансформеры, aka sasrec/bert4rec) для кодирования вектора юзера.
3) Обучаем на задачу близости вектора пользователя со следующим айтемом/множеством айтемов. Возможно доп задачи: sasrec учится на next-item для всей истории, которые в проде он никогда не увидит
И когда пытаешь завести алгоритм для своей задачи - в первую очередь я замечаю popularity bias . Веса соотвествующие векторам наиболее популярных айтемов/фичей айтемов - чаще обновляеются . В первые итерации модель выучивает именно такие объявления рекомендовать - в своих задач я это замечал.
А следующие батчи/эпохи пытается выйти из этого локального минимума состояния и начать показывать более персональный контент. На эту фазу и уходят основные компуты обучения.
Для решения этой проблемы активно используют:
a) random negative sampling
b) in-batch negative sampling
c) и LogQ сверху
На практике мне хватало a) и b) . Добавление c) при существующих a) и b) доп качество не давало
А что в классике
Изначально рекомендательные системы решались на основе матриц соовстречаемости - тык.
Как это выглядело:
1) Есть айтемы и истории пользователя -> строим матрицу как часто 1 айтем встречался с другим айтемом в этой истории
2) К каждому айтему в истории достаем наиболее часто встречающиеся айтемы используя матрицу соовстречаемости - кандидаты айтема.
3) Вместе с айтемом достаем и некий скор (достаем столбец) - меру соовстречаемости. И если для нескольких айтемов в истории совпали кандидаты, то можем сложить/перемножить скоры - и получить финальный скор для каждого кандидата. Потом отобрать топ K
Главная проблема в классике - как сформировать эту матрицу. Хорошее понимание данных и своего домена может помочь в этом. А применение этих методов может дать представление о том, как устроены данные. Примеры простых эвристик:
1) Поделить строчку на сумму в этой строке -> уберем байс популярности айтема (а нужно ли?) -> если ответ да, то будущий трансформер скорее всего не заведется без in-batch ns.
2) Добавить временную составляющую в историю -> учет трендов (а) -> получилось повысить скор - скорее всего трансформер еще выше сможет его выбить
3) Добавить дот продукт от контетных векторов с весом -> возможно колаборативной информации недостаточно и не все паттерны пользователи уже нашли -> скор вырос - в трансформер можно и нужно засунуть контентную часть
Когда что применять
Мне лично легче начать с классики в новом проекте. Буквально за 2-3 часа можно попробовать кучу матриц соовстречаемостей и сформировать представление о данных. Матричный метод легко параллелится на cpu, в отличии от трансформеров, которые ограничены размером батча и гпу памяти.
И когда уже сформирована интуиция как устроены данные, то можно попробовать хитрый трансформер с учетом полученных инсайдов в классике. У меня ходит кратно больше времени (3-4 дня vs 1 день на классику), чтобы завести трансформер. Это связанно с тем, что 1 такая моделька обучается от 3-4 часов , что гораздо медленнее чем матричные методы. Но зато удается выбить качество выше чем у классических алгоритмов.
В заключении
Но стоит ли оно того?
Велком в комменты: А вы часто сравниваете нейронночные методы с матричными в своих проектах? Пытаетесь выбить из классических методов максимум прежде чем тюнить нейронки? Какие другие аномалии замечали при тренировки нейроннок?
Контекст
В последнее время основные статьи в рекомендательных системах связанны с применением нейронных сетей.
Выглядит это всегда примерно так для сценария u2i:
1) Есть айтем -> кодируем через nn.Embedding его фичи
2) История пользователя состоит из айтемов -> используем наработку из 1) + encoder/decoder (трансформеры, aka sasrec/bert4rec) для кодирования вектора юзера.
3) Обучаем на задачу близости вектора пользователя со следующим айтемом/множеством айтемов. Возможно доп задачи: sasrec учится на next-item для всей истории, которые в проде он никогда не увидит
И когда пытаешь завести алгоритм для своей задачи - в первую очередь я замечаю popularity bias . Веса соотвествующие векторам наиболее популярных айтемов/фичей айтемов - чаще обновляеются . В первые итерации модель выучивает именно такие объявления рекомендовать - в своих задач я это замечал.
А следующие батчи/эпохи пытается выйти из этого локального минимума состояния и начать показывать более персональный контент. На эту фазу и уходят основные компуты обучения.
Для решения этой проблемы активно используют:
a) random negative sampling
b) in-batch negative sampling
c) и LogQ сверху
На практике мне хватало a) и b) . Добавление c) при существующих a) и b) доп качество не давало
А что в классике
Изначально рекомендательные системы решались на основе матриц соовстречаемости - тык.
Как это выглядело:
1) Есть айтемы и истории пользователя -> строим матрицу как часто 1 айтем встречался с другим айтемом в этой истории
2) К каждому айтему в истории достаем наиболее часто встречающиеся айтемы используя матрицу соовстречаемости - кандидаты айтема.
3) Вместе с айтемом достаем и некий скор (достаем столбец) - меру соовстречаемости. И если для нескольких айтемов в истории совпали кандидаты, то можем сложить/перемножить скоры - и получить финальный скор для каждого кандидата. Потом отобрать топ K
Главная проблема в классике - как сформировать эту матрицу. Хорошее понимание данных и своего домена может помочь в этом. А применение этих методов может дать представление о том, как устроены данные. Примеры простых эвристик:
1) Поделить строчку на сумму в этой строке -> уберем байс популярности айтема (а нужно ли?) -> если ответ да, то будущий трансформер скорее всего не заведется без in-batch ns.
2) Добавить временную составляющую в историю -> учет трендов (а) -> получилось повысить скор - скорее всего трансформер еще выше сможет его выбить
3) Добавить дот продукт от контетных векторов с весом -> возможно колаборативной информации недостаточно и не все паттерны пользователи уже нашли -> скор вырос - в трансформер можно и нужно засунуть контентную часть
Когда что применять
Мне лично легче начать с классики в новом проекте. Буквально за 2-3 часа можно попробовать кучу матриц соовстречаемостей и сформировать представление о данных. Матричный метод легко параллелится на cpu, в отличии от трансформеров, которые ограничены размером батча и гпу памяти.
И когда уже сформирована интуиция как устроены данные, то можно попробовать хитрый трансформер с учетом полученных инсайдов в классике. У меня ходит кратно больше времени (3-4 дня vs 1 день на классику), чтобы завести трансформер. Это связанно с тем, что 1 такая моделька обучается от 3-4 часов , что гораздо медленнее чем матричные методы. Но зато удается выбить качество выше чем у классических алгоритмов.
В заключении
Но стоит ли оно того?
Велком в комменты: А вы часто сравниваете нейронночные методы с матричными в своих проектах? Пытаетесь выбить из классических методов максимум прежде чем тюнить нейронки? Какие другие аномалии замечали при тренировки нейроннок?
🔥7👍2
Ускорение раннего связывания для моделей ранжирования
База
В двухэтапных рекомендательных системах используются кандидатогенерация (кандген) и ранжирование.
На этапе кандгена простые модели (например, DSSM, двухбашенные архитектуры) отбирают наиболее релевантные айтемы для пользователя. Из-за большого количества айтемов применяется позднее связывание (late interaction) — например, через скалярное произведение векторов пользователя и кандидатов.
На этапе ранжирования более сложные модели (например, CatBoost или нейросети) переупорядочивают кандидатов, учитывая дополнительные фичи, такие как счетчики взаимодействий или контекст пользователя.
Контекст
В последние годы крупные компании (Google, Meta, TikTok, Pinterest ❤️ , LinkedIn, Alibaba ) активно внедряют нейросетевые модели ранжирования, которые учитывают глобальный контекст пользователя.
В статье Amortized Inference предложен метод, улучшающий SOTA-результаты для этой задачи.
Авторы берут за основу две модели с ранним связыванием (early interaction):
BST (Behavior Sequence Transformer) — кандидат добавляется в конец истории пользователя.
TransAct — кандидат конкатенируется к каждому айтему в истории.
Обе модели используют трансформеры, что позволяет оценивать кандидата с учетом всей истории. Однако у них есть ключевая проблема — высокая вычислительная сложность.
Проблема
Для каждого кандидата модель заново обрабатывает историю пользователя.
Сложность:
O(n^2⋅m⋅d+n⋅m⋅d^2)
где:
n — длина истории,
m — число кандидатов,
d — размерность эмбеддингов.
При больших
n и m (например, 1000+ кандидатов) это приводит к высоким задержкам и делает модель непрактичной для прода.
Решение
Авторы предлагают конкатенировать всех кандидатов к истории и прогонять через трансформер один раз, а затем учить модель предсказывать таргет для каждого кандидата отдельно.
Новая сложность:
O((n+m)⋅d^2+(n+m)^2⋅d)
Это дает значительное ускорение, если
m>2 (что почти всегда верно в рекомендательных системах).
Результаты
+0.18% к качеству (A/B-тесты).
+5% к latency (vs. +56% у BST и +52% у TransAct).
Вывод
Метод упрощает инференс, сохраняя качество. Его можно масштабировать с помощью Flash Attention или приближенных вычислений (например, для 3000 кандидатов, как в Авито).
Статья мне понравилась простотой и практичностью — такой подход легче внедрять в продакшене.
База
В двухэтапных рекомендательных системах используются кандидатогенерация (кандген) и ранжирование.
На этапе кандгена простые модели (например, DSSM, двухбашенные архитектуры) отбирают наиболее релевантные айтемы для пользователя. Из-за большого количества айтемов применяется позднее связывание (late interaction) — например, через скалярное произведение векторов пользователя и кандидатов.
На этапе ранжирования более сложные модели (например, CatBoost или нейросети) переупорядочивают кандидатов, учитывая дополнительные фичи, такие как счетчики взаимодействий или контекст пользователя.
Контекст
В последние годы крупные компании (Google, Meta, TikTok, Pinterest ❤️ , LinkedIn, Alibaba ) активно внедряют нейросетевые модели ранжирования, которые учитывают глобальный контекст пользователя.
В статье Amortized Inference предложен метод, улучшающий SOTA-результаты для этой задачи.
Авторы берут за основу две модели с ранним связыванием (early interaction):
BST (Behavior Sequence Transformer) — кандидат добавляется в конец истории пользователя.
TransAct — кандидат конкатенируется к каждому айтему в истории.
Обе модели используют трансформеры, что позволяет оценивать кандидата с учетом всей истории. Однако у них есть ключевая проблема — высокая вычислительная сложность.
Проблема
Для каждого кандидата модель заново обрабатывает историю пользователя.
Сложность:
O(n^2⋅m⋅d+n⋅m⋅d^2)
где:
n — длина истории,
m — число кандидатов,
d — размерность эмбеддингов.
При больших
n и m (например, 1000+ кандидатов) это приводит к высоким задержкам и делает модель непрактичной для прода.
Решение
Авторы предлагают конкатенировать всех кандидатов к истории и прогонять через трансформер один раз, а затем учить модель предсказывать таргет для каждого кандидата отдельно.
Новая сложность:
O((n+m)⋅d^2+(n+m)^2⋅d)
Это дает значительное ускорение, если
m>2 (что почти всегда верно в рекомендательных системах).
Результаты
+0.18% к качеству (A/B-тесты).
+5% к latency (vs. +56% у BST и +52% у TransAct).
Вывод
Метод упрощает инференс, сохраняя качество. Его можно масштабировать с помощью Flash Attention или приближенных вычислений (например, для 3000 кандидатов, как в Авито).
Статья мне понравилась простотой и практичностью — такой подход легче внедрять в продакшене.
❤10
Коллеги, вы как боретесь с item cold start?
Сегодня расскажу про статью от Google: «Item-centric Exploration for Cold Start Problem»
На недавнем RecSys 2025 было много неплохих работ, которые зацепили сходу.
Сегодня хочу рассказать про простую идею, которую можно переиспользовать везде, где важна вероятность.
Например, для кандидатогенерации. В моем докладе про кросскат мы предсказываем не айтемы, а категории товаров. Для каждой категории находим вероятность и пропорционально ей семплируем уже айтемы из этой категории.
Проблемы рекомендательных систем:
Допустим, мы научились предсказывать вероятность клика/контакта от показа — но насколько такой вероятности можно доверять?
Если айтем новенький и по нему мало коллаборативных фичей-счетчиков, то модели ранжирования поставят его сильно ниже. Похожая ситуация и в кандидатогенерации.
Что предлагают авторы:
Давайте не показывать айтемы слепо. Посчитаем честную конверсию для айтема из показа в клик/контакт. Также у нас уже есть обученная модель ранжирования, которая предсказывает персональную вероятность клика S на айтем для конкретного пользователя.
Если персональная вероятность меньше, чем глобальная вероятность клика - 2 * std, то этот айтем можно не показывать пользователю — с большой вероятностью он ему не интересен.
Но получается, что мы уменьшаем пул айтемов, не предлагая ничего взамен?
Тут на арену выходят параметры alpha и beta. Когда мы считаем честную вероятность N+/N (N+ — положительное событие "клик/контакт", N — показы), мы можем добавить в числитель alpha, а в знаменатель — alpha + beta.
Таким образом, если у айтема было много N+, то alpha и beta не внесут большого вклада — мы уверены в истинной конверсии айтема.
Но если айтем холодный, то alpha и beta значительно скорректируют (повысят) его расчетную конверсию.
На картинке представлена полная картина: условия фильтрации (1), перерасчитанная конверсия (2) и поправка для оценки std (3).
Результат:
Метод позволяет без дополнительного обучения модели поднять выдачу для холодных айтемов.
Мои мысли:
Такую поправку очень легко использовать в современных индустриальных рекомендательных системах — расчет количества контактов/кликов и показов это уже решенная задача.
Для ранжирования можно дешево "прогревать" новые категории объявлений, не переобучая модель ранжирования, что обходится кратно дороже.
Для кандидатогенерации — чуть сложнее. Если брать в расчет вероятностные кандгены — например, на базе semantic ids, где можно посчитать вероятность на этапе инференса — то, добавив поправку, можно настроить количество свежих айтемов для пользователя. Для векторного отбора кандидатов — сложнее, так как вероятность будет известна уже после похода в БД за кандидатами.
Вот такие мысли по статье :)
Делитесь, как еще вы решаете cold-start проблему для айтемов.
Сегодня расскажу про статью от Google: «Item-centric Exploration for Cold Start Problem»
На недавнем RecSys 2025 было много неплохих работ, которые зацепили сходу.
Сегодня хочу рассказать про простую идею, которую можно переиспользовать везде, где важна вероятность.
Например, для кандидатогенерации. В моем докладе про кросскат мы предсказываем не айтемы, а категории товаров. Для каждой категории находим вероятность и пропорционально ей семплируем уже айтемы из этой категории.
Проблемы рекомендательных систем:
Допустим, мы научились предсказывать вероятность клика/контакта от показа — но насколько такой вероятности можно доверять?
Если айтем новенький и по нему мало коллаборативных фичей-счетчиков, то модели ранжирования поставят его сильно ниже. Похожая ситуация и в кандидатогенерации.
Что предлагают авторы:
Давайте не показывать айтемы слепо. Посчитаем честную конверсию для айтема из показа в клик/контакт. Также у нас уже есть обученная модель ранжирования, которая предсказывает персональную вероятность клика S на айтем для конкретного пользователя.
Если персональная вероятность меньше, чем глобальная вероятность клика - 2 * std, то этот айтем можно не показывать пользователю — с большой вероятностью он ему не интересен.
Но получается, что мы уменьшаем пул айтемов, не предлагая ничего взамен?
Тут на арену выходят параметры alpha и beta. Когда мы считаем честную вероятность N+/N (N+ — положительное событие "клик/контакт", N — показы), мы можем добавить в числитель alpha, а в знаменатель — alpha + beta.
Таким образом, если у айтема было много N+, то alpha и beta не внесут большого вклада — мы уверены в истинной конверсии айтема.
Но если айтем холодный, то alpha и beta значительно скорректируют (повысят) его расчетную конверсию.
На картинке представлена полная картина: условия фильтрации (1), перерасчитанная конверсия (2) и поправка для оценки std (3).
Результат:
Метод позволяет без дополнительного обучения модели поднять выдачу для холодных айтемов.
Мои мысли:
Такую поправку очень легко использовать в современных индустриальных рекомендательных системах — расчет количества контактов/кликов и показов это уже решенная задача.
Для ранжирования можно дешево "прогревать" новые категории объявлений, не переобучая модель ранжирования, что обходится кратно дороже.
Для кандидатогенерации — чуть сложнее. Если брать в расчет вероятностные кандгены — например, на базе semantic ids, где можно посчитать вероятность на этапе инференса — то, добавив поправку, можно настроить количество свежих айтемов для пользователя. Для векторного отбора кандидатов — сложнее, так как вероятность будет известна уже после похода в БД за кандидатами.
Вот такие мысли по статье :)
Делитесь, как еще вы решаете cold-start проблему для айтемов.
🔥6❤2
Forwarded from Wazowski Recommends
Вместо итогов года, хочу поделиться моим списком лучших — самых значимых или просто понравившихся — статей, которые я прочитал за последние два года (про 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) я рад за Кирилла и команду 😉
Обзор у автора.
На этом всё. Надеюсь, это будет кому-нибудь полезно. Мне самому было бы очень полезно, если бы авторы дружественных каналов позаимствовали такой формат! (только не «лучшие посты года»...)
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) я рад за Кирилла и команду 😉
Обзор у автора.
На этом всё. Надеюсь, это будет кому-нибудь полезно. Мне самому было бы очень полезно, если бы авторы дружественных каналов позаимствовали такой формат! (только не «лучшие посты года»...)
❤9👍5