Forwarded from .ml
Инженерная революция и обзывательства со стороны сообщества. Разбор YOLO v4-v6
Начиная с четвёртой версии, разработка перестала быть чисто идейно-эвристической и стала более инженерной.
📌 YOLO v4: Модель превратили в инженерную энциклопедию (2020)
YOLO v4 стала «библией» для улучшения архитектур. В нее вместили максимум трюков, не убив при этом FPS.
💛 Золотая фишка: в новой версии ввели mosaic аугментацию. Она собирает обучающую картинку из нескольких разных, что улучшает работоспособность модели. В результате качество удалось улучшить на +6% mAP по сравнению с YOLOv3, сохранив скорость на уровне 60 FPS.
Другие изменения:
📝 Пирамидальная архитектура (CSPDarknet-53 + PANet + SPP). Вместо простого вырезания кусков из картинки, мультискейл-подход реализовали на уровне самой сети с помощью пирамидального энкодера. Сетка сама извлекала признаки разного масштаба и распознавала контексты.
📝 Трюки и аугментации. В архитектуру интегрировали наработки, такие как Mish-activation, DropBlock и CloU loss. Вместе c mosaic аугментацией они улучшили качество модели на 10%, при этом не меняя её кардинально.
Проблем, которые нужно фиксить, больше нет, поэтому разработчики сосредоточились на улучшениях.
📌 YOLO v5: «Гадкий утенок» и массовое принятие (2020-2021)
YOLO v5 вышла спустя 4 месяца после v4 — версию прозвали «гадким утенком», потому что в ней не было архитектурных прорывов.
💛 Золотая фишка: YOLO v5 переписали на PyTorch и сделали её удобнее для пользователей. Каждый мог интегрировать ее в свой проект и дообучить под свои задачи. Сам PyTorch вскоре стрельнул и задоминировал в области DL, что привело к массовому принятию YOLO.
Других фишек немного — их выпустили, чтобы продвинуть статью о новой версии. Зато появилась куча проблем:
📎 Версия не работала из-за багов. Первые два месяца багнутая имплементация просто не давала пользоваться моделью. Текла память, некорректно уточнялась область по трем кандидатам.
📎Версия не добавляла новизны. Каждая новая YOLO решала либо инженерную проблему, либо идейную. Пятую модель посчитали переписью того, что уже было — просто на другой фреймворк. Сообществу такой подход не понравился.
📎 Версия разрабатывалась компанией Ultralytics. Сообщество относилось к ней с недоверием: раньше над YOLO работала СНГ-шная суперзвезда в области CV — Бачковский, а теперь какие-то ноунеймы. Поэтому разработчики волновались за судьбу полюбившейся модели.
📎 Версия так и не получила статью. Компания обещала выпустить ее в течение нескольких месяцев. Но прошло уже 4 года — статья не появилась. Ограничились парой тех. репортов на архиве.
📌 YOLO v6: Модель сделали удобнее для развертывания (2022)
Компания сосредоточилась на разработке максимально удобного real-time deployment под фреймворки вроде TensorRT и Edge-устройств.
💛 Золотая фишка: ввели Anchor-Free Head. Вместо предсказания сдвигов для кандидатов, модель ищет именно центральную точку объекта. Так быстрее и точнее.
Другие нововведения:
📝 Новая архитектура. В качестве бэкбоуна был выбран EfficientRep — аналог EfficientNet. Еще отказались от DarkNet-бэкбоуна — он давно устарел.
📝 Высокая скорость. Модель стала сверхлегкой и демонстрировала 120 FPS на T4 при разрешении 640x640. Поэтому её использовали в задачах, связанных с тепловизорами и Edge-вычислениями.
В следующем посте разберём, почему YOLO v8 стала самой популярной моделью семейства и как коммерциализация превратила проект в конвейер.
💜 Этот пост написал Никита Алутис, ML-разработчик в Точка Банк
Продолжаем наш цикл постов об эволюции самого популярного семейства моделей для Object Detection.
Начиная с четвёртой версии, разработка перестала быть чисто идейно-эвристической и стала более инженерной.
📌 YOLO v4: Модель превратили в инженерную энциклопедию (2020)
YOLO v4 стала «библией» для улучшения архитектур. В нее вместили максимум трюков, не убив при этом FPS.
💛 Золотая фишка: в новой версии ввели mosaic аугментацию. Она собирает обучающую картинку из нескольких разных, что улучшает работоспособность модели. В результате качество удалось улучшить на +6% mAP по сравнению с YOLOv3, сохранив скорость на уровне 60 FPS.
Другие изменения:
📝 Пирамидальная архитектура (CSPDarknet-53 + PANet + SPP). Вместо простого вырезания кусков из картинки, мультискейл-подход реализовали на уровне самой сети с помощью пирамидального энкодера. Сетка сама извлекала признаки разного масштаба и распознавала контексты.
📝 Трюки и аугментации. В архитектуру интегрировали наработки, такие как Mish-activation, DropBlock и CloU loss. Вместе c mosaic аугментацией они улучшили качество модели на 10%, при этом не меняя её кардинально.
К минусам YOLO v4 можно отнести сложность интеграции модели и ручные гиперпараметры, оставшиеся от предыдущих версий.
Проблем, которые нужно фиксить, больше нет, поэтому разработчики сосредоточились на улучшениях.
📌 YOLO v5: «Гадкий утенок» и массовое принятие (2020-2021)
YOLO v5 вышла спустя 4 месяца после v4 — версию прозвали «гадким утенком», потому что в ней не было архитектурных прорывов.
💛 Золотая фишка: YOLO v5 переписали на PyTorch и сделали её удобнее для пользователей. Каждый мог интегрировать ее в свой проект и дообучить под свои задачи. Сам PyTorch вскоре стрельнул и задоминировал в области DL, что привело к массовому принятию YOLO.
Других фишек немного — их выпустили, чтобы продвинуть статью о новой версии. Зато появилась куча проблем:
📎 Версия не работала из-за багов. Первые два месяца багнутая имплементация просто не давала пользоваться моделью. Текла память, некорректно уточнялась область по трем кандидатам.
📎Версия не добавляла новизны. Каждая новая YOLO решала либо инженерную проблему, либо идейную. Пятую модель посчитали переписью того, что уже было — просто на другой фреймворк. Сообществу такой подход не понравился.
📎 Версия разрабатывалась компанией Ultralytics. Сообщество относилось к ней с недоверием: раньше над YOLO работала СНГ-шная суперзвезда в области CV — Бачковский, а теперь какие-то ноунеймы. Поэтому разработчики волновались за судьбу полюбившейся модели.
📎 Версия так и не получила статью. Компания обещала выпустить ее в течение нескольких месяцев. Но прошло уже 4 года — статья не появилась. Ограничились парой тех. репортов на архиве.
К счастью, Ultralytics модельку не бросили, всячески её дорабатывали и улучшали. Благодаря PyTorch и поддержке от разработчиков, YOLO v5 много где используется как составляющая комплексного решения.
📌 YOLO v6: Модель сделали удобнее для развертывания (2022)
Компания сосредоточилась на разработке максимально удобного real-time deployment под фреймворки вроде TensorRT и Edge-устройств.
💛 Золотая фишка: ввели Anchor-Free Head. Вместо предсказания сдвигов для кандидатов, модель ищет именно центральную точку объекта. Так быстрее и точнее.
Другие нововведения:
📝 Новая архитектура. В качестве бэкбоуна был выбран EfficientRep — аналог EfficientNet. Еще отказались от DarkNet-бэкбоуна — он давно устарел.
📝 Высокая скорость. Модель стала сверхлегкой и демонстрировала 120 FPS на T4 при разрешении 640x640. Поэтому её использовали в задачах, связанных с тепловизорами и Edge-вычислениями.
Явных минусов и проблем у модели не было. Разве что подводила точность в сравнении с v5 и v7. Но зато v6 лучшая для Edge-устройств.
В следующем посте разберём, почему YOLO v8 стала самой популярной моделью семейства и как коммерциализация превратила проект в конвейер.
💜 Этот пост написал Никита Алутис, ML-разработчик в Точка Банк
Forwarded from .ml
Взлёт и падение YOLO. Разбор лучших версий v7-v8 и «конвейера» v9-v12
Нет предела совершенству. Поэтому в игру вернулись учёные, чтобы оптимизировать саму логику обучения. Они помогли Ultralytics создать самую сильную модель на тот момент.
📌 YOLO v7: Самая быстрая среди всех (2022)
В эту версию вернулся Алексей Бачковский (автор v4) и предложил не просто учить веса, а оптимизировать то, как информация течёт по слоям сети, чтобы убрать лишние компоненты.
Что изменили технически:
📝 Ввели E-ELAN / GELAN. Это новый бэкбон, который максимально эффективно агрегирует фичи из всех субэнкодеров и позволяет информации «течь» по сети с минимальными потерями.
📝 Появился re-parameterization. Разработчики разделили структуру для обучения и структуру для инференса. Это позволило ускорить работу модели в продакшене без потери качества.
📌 YOLO v8: Самая популярная и доступная из всех (2023)
На данный момент это самая популярная модель семейства. Секрет успеха v8 не в сказочных метриках, а в том, что всё сделали «по-людски».
Какие новые фишки:
📝 Идея Anchor-Free. Полностью отказались от опорных точек. Разработчики решили просто положить побольше данных в сеть и искать области сразу. Это упростило жизнь юзерам — больше не нужно дебажить параметры точек.
📝 Крутой инструментарий. Модель взлетела благодаря репозиторию Ultralytics. Из коробки, даже не зная глубоко Deep Learning, можно легко запустить обучение, настроить пайплайн и внедрить модель в продакшн.
📌 YOLO v9-v12: Конвейер обновлений (2024–...)
После успеха v8 статей стало экспоненциально больше, но улучшения стали минимальными и итеративными. Разработчики упрощают модель, иногда даже жертвуя качеством, чтобы максимально ее популяризировать.
Что происходило в этих версиях:
📝 YOLO v9. Попытались управлять потоком информации через механизм Programmable Gradient Information (PGI) и GELAN. Сеть сама решает, какие признаки пропускать, а какие блокировать. Что-то вроде аналога гейтинга.
📝 YOLO v10. Полностью отказались от NMS (Non-Maximum Suppression). Модель учится предсказывать области вслепую, без постобработки для удаления дублей, без центроидных точек. В итоге качество иногда просаживалось.
📝 YOLO v11. Перешли к мультимодальности. Вместо одной только детекции сеть стала учить сразу сегментацию, позы и классификацию, чтобы использовать максимум данных для уточнения весов.
📝 YOLO v12. Внедрили FlashAttention и попытались по-другому выстроить механизмы внимания, нащупать еще один аналог гейтинга. Особого хайпа не вызвала, так как про «новые» инструменты из этой версии уже все знали.
Летом 2025 года вышла YOLO v13. Она оказалась на голову выше всех своих предыдущих версий и сразу стала самой востребованной среди разработчиков.
В финальном посте разберём ту самую YOLO v13: узнаем, как Бачковский и Ultralytics переосмыслили фундамент модели.
💜 Этот пост написал Никита Алутис, ML-разработчик в Точка Банк
Продолжаем погружение в историю YOLO. Если v4-v6 были про инженерные трюки, то дальше случились популярность и стагнация.
Нет предела совершенству. Поэтому в игру вернулись учёные, чтобы оптимизировать саму логику обучения. Они помогли Ultralytics создать самую сильную модель на тот момент.
📌 YOLO v7: Самая быстрая среди всех (2022)
В эту версию вернулся Алексей Бачковский (автор v4) и предложил не просто учить веса, а оптимизировать то, как информация течёт по слоям сети, чтобы убрать лишние компоненты.
Что изменили технически:
📝 Ввели E-ELAN / GELAN. Это новый бэкбон, который максимально эффективно агрегирует фичи из всех субэнкодеров и позволяет информации «течь» по сети с минимальными потерями.
📝 Появился re-parameterization. Разработчики разделили структуру для обучения и структуру для инференса. Это позволило ускорить работу модели в продакшене без потери качества.
Результат: YOLO v7 оказалась на 120% быстрее аналогов и стала эталоном оптимизации архитектуры сети. Ее релизнутая идея с увеличенной степенью компрессии использовалась и в других инструментах, став основой в DL.
📌 YOLO v8: Самая популярная и доступная из всех (2023)
На данный момент это самая популярная модель семейства. Секрет успеха v8 не в сказочных метриках, а в том, что всё сделали «по-людски».
Какие новые фишки:
📝 Идея Anchor-Free. Полностью отказались от опорных точек. Разработчики решили просто положить побольше данных в сеть и искать области сразу. Это упростило жизнь юзерам — больше не нужно дебажить параметры точек.
📝 Крутой инструментарий. Модель взлетела благодаря репозиторию Ultralytics. Из коробки, даже не зная глубоко Deep Learning, можно легко запустить обучение, настроить пайплайн и внедрить модель в продакшн.
Результат: модель набрала популярность благодаря своей простоте и удобству. В отличие от крупных компаний вроде Facebook и Apple, репозиторий YOLO v8 подходил для новичков и легко интегрировался в проекты.
📌 YOLO v9-v12: Конвейер обновлений (2024–...)
После успеха v8 статей стало экспоненциально больше, но улучшения стали минимальными и итеративными. Разработчики упрощают модель, иногда даже жертвуя качеством, чтобы максимально ее популяризировать.
Что происходило в этих версиях:
📝 YOLO v9. Попытались управлять потоком информации через механизм Programmable Gradient Information (PGI) и GELAN. Сеть сама решает, какие признаки пропускать, а какие блокировать. Что-то вроде аналога гейтинга.
📝 YOLO v10. Полностью отказались от NMS (Non-Maximum Suppression). Модель учится предсказывать области вслепую, без постобработки для удаления дублей, без центроидных точек. В итоге качество иногда просаживалось.
📝 YOLO v11. Перешли к мультимодальности. Вместо одной только детекции сеть стала учить сразу сегментацию, позы и классификацию, чтобы использовать максимум данных для уточнения весов.
📝 YOLO v12. Внедрили FlashAttention и попытались по-другому выстроить механизмы внимания, нащупать еще один аналог гейтинга. Особого хайпа не вызвала, так как про «новые» инструменты из этой версии уже все знали.
Результат: YOLO дошла до идеала. Уже сложно что-то улучшить или придумать инновационные решения, как это было в первых версиях модели. Хотя идеи все еще были: детектить объекты в разных скейлах, градиенты оптимизировать. Но в тот момент казалось, что круче уже некуда.
Летом 2025 года вышла YOLO v13. Она оказалась на голову выше всех своих предыдущих версий и сразу стала самой востребованной среди разработчиков.
В финальном посте разберём ту самую YOLO v13: узнаем, как Бачковский и Ultralytics переосмыслили фундамент модели.
💜 Этот пост написал Никита Алутис, ML-разработчик в Точка Банк
Forwarded from .ml
Финал эволюции YOLO — как шаг назад порвал все живое. Разбор v13
Завершаем нашу серию постов о самой известной архитектуре в Computer Vision.
Летом 2025 вышла YOLO v13, которая доказала: чтобы сделать качественный скачок вперед, иногда нужно сделать шаг назад и переосмыслить фундамент.
📌 Проводим аналогии: как думает мозг, а как DL-модель?
Вместо того чтобы бесконечно усложнять блоки, авторы v13 задались вопросом: а как мозг связывает признаки?
📎 Мозг не работает линейно, прогоняя информацию через одинаковые операторы, как это делают обычные нейросети. Для каждой микрозадачи в духе «объединить три палочки в треугольник» мозг строит свою уникальную, нелинейную сеть связей.
📌 Как HyperACE и FullPAD сделали v13 самый мощной?
Архитектура v13 держится на двух слонах, которые помогли ей выбиться в лидеры по метрикам и скорости.
📝 FullPAD Tunnel. Это технический хак, похожий на диффузию. Он преобразует все разнородные фичи в одно латентное пространство, то есть один масштаб, чтобы эффективно распределить их по всей сети.
📝 HyperACE (Hypergraph). Это механизм для поиска неочевидных связей. Вместо наложения слоев друг на друга, сеть ищет высокую корреляцию между разными фичами и объединяет их в звенья. То есть отдельные составляющие информации сеть объединяет на основании корреляционных характеристик.
📌 Результат: почему YOLO v13 сейчас топ-1, и какие инсайты доказало это семейство
YOLO v13 превзошла все предыдущие версии и по скорости, и по точности. Но революционные решения других версий тоже стоит учитывать при ведении своего проекта.
Почему стоит внедрить:
📎 Если ваш проект требует максимума от Computer Vision, v13 — это текущий state-of-the-art. Она использует гиперграфы для построения взаимосвязей, что даёт буст там, где обычные CNN буксуют.
Идейные инсайты:
📝 Данные > Архитектура. Качество модели можно сильно выжать за счёт аугментаций и хороших данных. Пример YOLO v4 показал, что 10% качества можно получить одной лишь работой с данными.
📝 Эффективность порождает качество. Если делать модель максимально быстрой и лёгкой, результат тоже улучшится. YOLO начинала как простенькая real-time моделька, а её финальные итерации обходят старые RCNN-овские подходы и методы из детектрона, хоть и с ограничениями.
📝 Сделайте шаг назад. Наш мозг фиксирует контекст, и мы зацикливаемся на текущем уровне решений. Чтобы осознать проблему и найти прорывное решение, нужно избавиться от контекста и посмотреть на задачу глобально, с другой стороны.
Качественные инсайты:
📝 Гиперграфы в Vision-сетях. Они позволяют строить взаимосвязи фичей на таком уровне, с которыми обычные сетки не справляются без дополнительных модов.
📝 Управление потоком информации. Важно углубляться в то, как текут градиенты. Оптимизация потока информации как в v7 или v9 убирает лишние слои — сеть учится эффективнее.
📝 Multiscale решает. Используйте больше мультискейл-подходов, таких как разные размеры входных данных, кропов, контекстных окон. Так модель обобщается на реальные данные. Это работает везде: от СМ до LLM.
📌 Итог серии
Первую версию YOLO создал Джозеф Редмон — обычный аспирант, который считал, что всё уже изобретено до него ребятами из Google и OpenAI. Он сделал это как пэт-проект, чтобы просто поэкспериментировать в удовольствие.
В итоге его проект стал стандартом индустрии и принёс ему премию за прорыв в ML. При этом он только дал старт: продукт развивали другие люди и компании.
💜 Этот пост написал Никита Алутис, ML-разработчик в Точка Банк
Завершаем нашу серию постов о самой известной архитектуре в Computer Vision.
Летом 2025 вышла YOLO v13, которая доказала: чтобы сделать качественный скачок вперед, иногда нужно сделать шаг назад и переосмыслить фундамент.
📌 Проводим аналогии: как думает мозг, а как DL-модель?
Вместо того чтобы бесконечно усложнять блоки, авторы v13 задались вопросом: а как мозг связывает признаки?
📎 Мозг не работает линейно, прогоняя информацию через одинаковые операторы, как это делают обычные нейросети. Для каждой микрозадачи в духе «объединить три палочки в треугольник» мозг строит свою уникальную, нелинейную сеть связей.
YOLO v13 отказалась от обобщенных блоков и решений и внедрила механизм, имитирующий эту биологическую сложность.
📌 Как HyperACE и FullPAD сделали v13 самый мощной?
Архитектура v13 держится на двух слонах, которые помогли ей выбиться в лидеры по метрикам и скорости.
📝 FullPAD Tunnel. Это технический хак, похожий на диффузию. Он преобразует все разнородные фичи в одно латентное пространство, то есть один масштаб, чтобы эффективно распределить их по всей сети.
📝 HyperACE (Hypergraph). Это механизм для поиска неочевидных связей. Вместо наложения слоев друг на друга, сеть ищет высокую корреляцию между разными фичами и объединяет их в звенья. То есть отдельные составляющие информации сеть объединяет на основании корреляционных характеристик.
Пример: сеть понимает, что «палочка» + «кружочек» имеют высокую корреляцию для объекта «леденец», и строит для них жесткую связь. Так строятся сложные признаки, которые обычным сетям недоступны без огромной глубины.
📌 Результат: почему YOLO v13 сейчас топ-1, и какие инсайты доказало это семейство
YOLO v13 превзошла все предыдущие версии и по скорости, и по точности. Но революционные решения других версий тоже стоит учитывать при ведении своего проекта.
Почему стоит внедрить:
📎 Если ваш проект требует максимума от Computer Vision, v13 — это текущий state-of-the-art. Она использует гиперграфы для построения взаимосвязей, что даёт буст там, где обычные CNN буксуют.
Идейные инсайты:
📝 Данные > Архитектура. Качество модели можно сильно выжать за счёт аугментаций и хороших данных. Пример YOLO v4 показал, что 10% качества можно получить одной лишь работой с данными.
📝 Эффективность порождает качество. Если делать модель максимально быстрой и лёгкой, результат тоже улучшится. YOLO начинала как простенькая real-time моделька, а её финальные итерации обходят старые RCNN-овские подходы и методы из детектрона, хоть и с ограничениями.
📝 Сделайте шаг назад. Наш мозг фиксирует контекст, и мы зацикливаемся на текущем уровне решений. Чтобы осознать проблему и найти прорывное решение, нужно избавиться от контекста и посмотреть на задачу глобально, с другой стороны.
Качественные инсайты:
📝 Гиперграфы в Vision-сетях. Они позволяют строить взаимосвязи фичей на таком уровне, с которыми обычные сетки не справляются без дополнительных модов.
📝 Управление потоком информации. Важно углубляться в то, как текут градиенты. Оптимизация потока информации как в v7 или v9 убирает лишние слои — сеть учится эффективнее.
📝 Multiscale решает. Используйте больше мультискейл-подходов, таких как разные размеры входных данных, кропов, контекстных окон. Так модель обобщается на реальные данные. Это работает везде: от СМ до LLM.
📌 Итог серии
Первую версию YOLO создал Джозеф Редмон — обычный аспирант, который считал, что всё уже изобретено до него ребятами из Google и OpenAI. Он сделал это как пэт-проект, чтобы просто поэкспериментировать в удовольствие.
В итоге его проект стал стандартом индустрии и принёс ему премию за прорыв в ML. При этом он только дал старт: продукт развивали другие люди и компании.
Какой вывод? Не упирайтесь в идею, что за вас все всё уже давно придумали. Вы можете создавать инновационные проекты там, где уже, казалось бы, всё сделано. Главное — периодически отходить от контекста и смотреть на картину глобально.
💜 Этот пост написал Никита Алутис, ML-разработчик в Точка Банк
Forwarded from Ночной Писаревский
Ровно год назад я написал пост про то, что не верю в агентов.
Обещал вернуться к нему и оценить, ошибался я или нет.
Очевидно, что есть ниши, в которых агенты просто взорвали:
• Кодинг. Claude Code, Cursor, Lovable, Replit — это ни что иное как агенты, и они полностью поменяли процесс разработки и создания продуктов
• Саппорт. Fin от Intercom растет лютыми темпами и автоматически закрывает 2/3 обращений в саппорт сам. Есть куча решений-конкурентов, которые не сильно хуже. Многие компании успешно внедрили себе разных AI-агентов в саппорт и они закрывают от 20% до 90% тикетов.
• Research. Мало кто задумывается, но Deep Research от ChatGPT — это тоже агент, и он офигенно работает и решает свою задачу. Ну и много других прикладных инструментов для более узких задач.
При этом есть еще куча ниш, где работает пока не так хорошо, но есть потенциал:
• Sales & RevOps. Агенты квалифицируют лиды, ведут initial discovery, отвечают на inbound запросы, назначают встречи, делают follow-ups, обновляют CRM. Дима Сергеев, например, делает data-driven агентов для inbound воронки (надеюсь, у него все получится)
• Marketing & Ads. Агенты делают креативы, анализируют трафик, управляют рекламными кампаниями. Сева Устинов, например, делает AI-агента для управления рекламой (тоже надеюсь, у него все получится)
• Финансы и бэк-офис. Агенты обрабатывают инвойсы, раскидывают расходы по категориям, проводят комплаенс-проверки. Илья Лисин, например, делает AI-агента, который автоматизирует создание компании, бухгалтерию и подачу налогов (тоже надеюсь, у него все получится)
Ну, и куча других ниш, где пока нихрена ничего не работает 🙂
Но, если краткий вывод — то я скорее ошибался.
«Мы часто переоцениваем прогресс на горизонте года, и недооценивает его на горизонте 10 лет»
Думаю, примерно это и происходит сейчас с AI: да, он не заменит нас всех прямо завтра, но через 10 лет мы не узнаем мир, в котором живем
Обещал вернуться к нему и оценить, ошибался я или нет.
Очевидно, что есть ниши, в которых агенты просто взорвали:
• Кодинг. Claude Code, Cursor, Lovable, Replit — это ни что иное как агенты, и они полностью поменяли процесс разработки и создания продуктов
• Саппорт. Fin от Intercom растет лютыми темпами и автоматически закрывает 2/3 обращений в саппорт сам. Есть куча решений-конкурентов, которые не сильно хуже. Многие компании успешно внедрили себе разных AI-агентов в саппорт и они закрывают от 20% до 90% тикетов.
• Research. Мало кто задумывается, но Deep Research от ChatGPT — это тоже агент, и он офигенно работает и решает свою задачу. Ну и много других прикладных инструментов для более узких задач.
При этом есть еще куча ниш, где работает пока не так хорошо, но есть потенциал:
• Sales & RevOps. Агенты квалифицируют лиды, ведут initial discovery, отвечают на inbound запросы, назначают встречи, делают follow-ups, обновляют CRM. Дима Сергеев, например, делает data-driven агентов для inbound воронки (надеюсь, у него все получится)
• Marketing & Ads. Агенты делают креативы, анализируют трафик, управляют рекламными кампаниями. Сева Устинов, например, делает AI-агента для управления рекламой (тоже надеюсь, у него все получится)
• Финансы и бэк-офис. Агенты обрабатывают инвойсы, раскидывают расходы по категориям, проводят комплаенс-проверки. Илья Лисин, например, делает AI-агента, который автоматизирует создание компании, бухгалтерию и подачу налогов (тоже надеюсь, у него все получится)
Ну, и куча других ниш, где пока нихрена ничего не работает 🙂
Но, если краткий вывод — то я скорее ошибался.
«Мы часто переоцениваем прогресс на горизонте года, и недооценивает его на горизонте 10 лет»
Думаю, примерно это и происходит сейчас с AI: да, он не заменит нас всех прямо завтра, но через 10 лет мы не узнаем мир, в котором живем
Forwarded from Red RecSys
Джентельменский набор RecSys статей на начало 2026
Не первый раз меня спрашивают – какой сейчас актуальный пул статей, достаточный для того, чтобы «быть в теме» и «проходить собесы». Моя личная подборка такая:
SASRec
Основа основ, не уходящая с наших слайдов на конференциях
Turning Dross into Gold Loss
SASRec+ Sampled Softmax. Непобедимая SOTA Amazon датасетов и по сей день (но в тексте статьи вы этого не найдёте, можно почитать в eSASRec)
Unified Embeddings
Элегантный и распространённый в индустрии подход для решения проблемы раздутых матриц эмбеддингов для много-миллионных каталогов и большого количества фичей
Sampling-Bias-Corrected Neural Modeling
В деталях опиcывают LogQ коррекцию - незаменимый индустриальный подход при использовании in-batch негативов в обучении (после неё можно почитать Correcting the LogQ Correction)
PinnerFormer
Уже не must-have, но всё ещё классика. Как SASRec адаптировался в индустрии. Pinterest научил нас, что предсказывать можно не только следующий айтем, но и более отдалённый из будущего, и описал свой итоговый рецепт обучения – в том числе с Mixed негативами и LogQ коррекцией.
TransAct
Нейросетевых ранкеров есть большое количество. Здесь описывают вариант от Pinterest времён 2023 под именем Pinnability. Обрабатывают оффлайн (PinnerFormer) и рантайм (TransAct) историю пользователя + фичи пользователя, сверху шапка из DNC-V2 и несколько голов на бинарные таргеты. TransAct использует раннее связывание.
Actions…
Забудьте про чередование токенов - от него откажутся. Забудьте архитектуру HSTU - это не серебряная пуля. Главное здесь – подход к отказу от ручных вещей через масштабирование модели над последовательностями действий пользователей. И само выделение сущностей Item и Action (к ним позже добавится Context). Ещё есть полезная история с инференсом сразу пачки кандидатов target-aware ранкером с помощью кастомной маски внимания. И здесь же хорошо описан общий индустриальный подход Deep Learning Ranking Models.
Argus
Адаптация и развитие идей Actions… в Яндексе. Мы уже не используем feedback prediction в претрейне, но Argus остаётся ключевой технологией в кандгене и ранжировании. А ещё, если я не ошибаюсь, это единственная статья с авторегрессивным двухбашенным ранкером.
Generative Retrieval
Они показали нам Semantic Ids в RecSys. Дали дорогу для одностадийных рексистем (см OneRec). Открыли прямой путь для рекомендаций LLM-ками (см PLUM). И чуть позже (в Better Generalization…) показали профит от использования семантиков фичами в ранжировании.
QARM
Перед заведением Semantic Ids нужно получить сами эмбеддинги для квантизации – и от их качества зависит успех всей затеи. Дообучение на item-item пары массово используется в индустрии для формирования контентно-коллаборативных эмбеддингов с целью их дальнейшей квантизации в семантики. И впервые его описали в QARM.
OneRec
Вы уже видели что-то про One… в каждом RecSys канале, на который только подписаны.
PLUM
LLM генерирует рекомендации. По-настоящему, в индустриальном сеттинге. В Google. Must-read. Такой же рецепт описан в OneRec-Think
Этого списка хватит и для общения со специалистами, и для собесов.
Насколько больше мы читаем в работе? Сейчас выходит около 5 актуальных мне статей каждую неделю. Из них минимум 1 от Kuaishou, и если эти ребята не остановятся в приростах своих App Stay Time, китайские подростки вообще перестанут спать.
Не первый раз меня спрашивают – какой сейчас актуальный пул статей, достаточный для того, чтобы «быть в теме» и «проходить собесы». Моя личная подборка такая:
SASRec
Основа основ, не уходящая с наших слайдов на конференциях
Turning Dross into Gold Loss
SASRec+ Sampled Softmax. Непобедимая SOTA Amazon датасетов и по сей день (но в тексте статьи вы этого не найдёте, можно почитать в eSASRec)
Unified Embeddings
Элегантный и распространённый в индустрии подход для решения проблемы раздутых матриц эмбеддингов для много-миллионных каталогов и большого количества фичей
Sampling-Bias-Corrected Neural Modeling
В деталях опиcывают LogQ коррекцию - незаменимый индустриальный подход при использовании in-batch негативов в обучении (после неё можно почитать Correcting the LogQ Correction)
PinnerFormer
Уже не must-have, но всё ещё классика. Как SASRec адаптировался в индустрии. Pinterest научил нас, что предсказывать можно не только следующий айтем, но и более отдалённый из будущего, и описал свой итоговый рецепт обучения – в том числе с Mixed негативами и LogQ коррекцией.
TransAct
Нейросетевых ранкеров есть большое количество. Здесь описывают вариант от Pinterest времён 2023 под именем Pinnability. Обрабатывают оффлайн (PinnerFormer) и рантайм (TransAct) историю пользователя + фичи пользователя, сверху шапка из DNC-V2 и несколько голов на бинарные таргеты. TransAct использует раннее связывание.
Actions…
Забудьте про чередование токенов - от него откажутся. Забудьте архитектуру HSTU - это не серебряная пуля. Главное здесь – подход к отказу от ручных вещей через масштабирование модели над последовательностями действий пользователей. И само выделение сущностей Item и Action (к ним позже добавится Context). Ещё есть полезная история с инференсом сразу пачки кандидатов target-aware ранкером с помощью кастомной маски внимания. И здесь же хорошо описан общий индустриальный подход Deep Learning Ranking Models.
Argus
Адаптация и развитие идей Actions… в Яндексе. Мы уже не используем feedback prediction в претрейне, но Argus остаётся ключевой технологией в кандгене и ранжировании. А ещё, если я не ошибаюсь, это единственная статья с авторегрессивным двухбашенным ранкером.
Generative Retrieval
Они показали нам Semantic Ids в RecSys. Дали дорогу для одностадийных рексистем (см OneRec). Открыли прямой путь для рекомендаций LLM-ками (см PLUM). И чуть позже (в Better Generalization…) показали профит от использования семантиков фичами в ранжировании.
QARM
Перед заведением Semantic Ids нужно получить сами эмбеддинги для квантизации – и от их качества зависит успех всей затеи. Дообучение на item-item пары массово используется в индустрии для формирования контентно-коллаборативных эмбеддингов с целью их дальнейшей квантизации в семантики. И впервые его описали в QARM.
OneRec
Вы уже видели что-то про One… в каждом RecSys канале, на который только подписаны.
PLUM
LLM генерирует рекомендации. По-настоящему, в индустриальном сеттинге. В Google. Must-read. Такой же рецепт описан в OneRec-Think
Этого списка хватит и для общения со специалистами, и для собесов.
Насколько больше мы читаем в работе? Сейчас выходит около 5 актуальных мне статей каждую неделю. Из них минимум 1 от Kuaishou, и если эти ребята не остановятся в приростах своих App Stay Time, китайские подростки вообще перестанут спать.
Forwarded from Находки в опенсорсе
PEP-814: frozendict
В Python 3.15 появится полноценный иммутабельный словарь.
PEP: https://peps.python.org/pep-0814
Обсуждение: https://discuss.python.org/t/pep-814-add-frozendict-built-in-type/104854
Оригинальный PR: https://github.com/python/cpython/pull/144757
Исходники (да, они с
Зачем?
Главный вопрос: зачем питону вдруг через 35 лет понадобился иммутабельный словарь? Мотивации в ПЕПе явно не очень хватает. Но я докину:
1.
2. С иммутабельными объектами куда проще работать в режиме Free-Threading
3. Многие другие новые идеи вроде Виртуальных Потоков тоже хотели бы иметь аналог иммутабельного словаря
Ну а
И вот у нас появилась точная копия обычного
Примеры
Но не умеет ничего из
Зато умеет в
Как его менять? А вот так, создавая новые:
Детали реализации
Чтобы вы понимали, насколько они похожи:
Интересно, как работает
В C-API тоже добавили функций для работы с новым словарем:
А еще половина stdlib поменяет константы с
Отличный ПЕП, простая реализация, крутая фича. Питон победа!
Обсуждение: как вы относитесь к иммутабельности в питоне и вообще?
| Поддержать | YouTube | GitHub | Чат |
В Python 3.15 появится полноценный иммутабельный словарь.
PEP: https://peps.python.org/pep-0814
Обсуждение: https://discuss.python.org/t/pep-814-add-frozendict-built-in-type/104854
Оригинальный PR: https://github.com/python/cpython/pull/144757
Исходники (да, они с
dict лежат в одном файле на 8к строк)Зачем?
Главный вопрос: зачем питону вдруг через 35 лет понадобился иммутабельный словарь? Мотивации в ПЕПе явно не очень хватает. Но я докину:
1.
frozendict можно будет шарить между разными интерпретаторами без какого-либо оверхеда2. С иммутабельными объектами куда проще работать в режиме Free-Threading
3. Многие другие новые идеи вроде Виртуальных Потоков тоже хотели бы иметь аналог иммутабельного словаря
Ну а
types.MappingProxyType(mapping) был только surface-immutable. Все равно можно было поменять оригинальный объект mapping.И вот у нас появилась точная копия обычного
dict, только иммутабельная:Примеры
frozendict является collections.abc.Mapping и таким же Generic с двумя параметрами:
>>> frozendict.__mro__
(<class 'frozendict'>, <class 'object'>)
>>> obj = frozendict({'a': 1})
>>> frozendict[str, int]
frozendict[str, int]
Но не умеет ничего из
collections.abc.MutableMapping:
>>> obj['a'] = 2
TypeError: 'frozendict' object does not support item assignment
>>> obj.update
AttributeError: 'frozendict' object has no attribute 'update'
Зато умеет в
hash, если все ключи и значения умеют в hash:
>>> hash(obj)
6343282633043897990
>>> hash(frozendict({1: []}))
TypeError: unhashable type: 'list'
Как его менять? А вот так, создавая новые:
>>> obj = frozendict({'a': 1})
>>> id(obj)
4352339472
>>> obj |= {'b': 2} # <- тут мы создали новый frozendict
>>> obj
frozendict({'a': 1, 'b': 2})
>>> id(obj)
4352341680
Детали реализации
Чтобы вы понимали, насколько они похожи:
frozendict просто переиспользует clinic макросы dict для определения своих методов (=использует те же методы):
static PyMethodDef frozendict_methods[] = {
DICT___CONTAINS___METHODDEF
{"__getitem__", dict_subscript, METH_O | METH_COEXIST, getitem__doc__},
DICT___SIZEOF___METHODDEF
DICT_GET_METHODDEF
DICT_KEYS_METHODDEF
DICT_ITEMS_METHODDEF
DICT_VALUES_METHODDEF
DICT_FROMKEYS_METHODDEF
DICT_COPY_METHODDEF
DICT___REVERSED___METHODDEF
{"__class_getitem__", Py_GenericAlias, METH_O|METH_CLASS, PyDoc_STR("See PEP 585")},
{NULL, NULL} /* sentinel */
};
Интересно, как работает
hash: он полностью дублирует алгоритм хеша из frozenset.В C-API тоже добавили функций для работы с новым словарем:
PyFrozenDict_New, PyAnyDict_Check проверяет на dict, frozendict или их подтипы.А еще половина stdlib поменяет константы с
dict на frozendict.Отличный ПЕП, простая реализация, крутая фича. Питон победа!
Обсуждение: как вы относитесь к иммутабельности в питоне и вообще?
| Поддержать | YouTube | GitHub | Чат |
Python Enhancement Proposals (PEPs)
PEP 814 – Add frozendict built-in type | peps.python.org
A new public immutable type frozendict is added to the builtins module.
Forwarded from Не AБы какие тесты
Привет, товарищи-статистики!
Интересный вопрос по базе: почему при средних объемах выборки мы используем t-распределение, если средние уже вроде бы распределены нормально?
Действительно, при некотором объеме выборки (условно 30-50 измерений) у нас соблюдается не только нормальность средних, но и выборочная дисперсия начинает вести себя предсказуемо (моделируется через Хи-квадрат, одно не 1-в-1 с ним совпадает!). Это обеспечивает в принципе t-распределение для большинства случайный величин, то есть что-то универсальное.
Но многих в контексте "среднего объема" выборок ставит в тупик наблюдение о выборочных средних согласно нормальном распределении, значит и перевод в z-score должно давать z-нормальное, однако применение критерия без знания дисперсии генеральной дает именно t-распределение. Почему?
Действительно, наблюдаешь нормальность средних, применяешь z-score = z-нормальное. Но это если есть знания отклонения средних, что на практике невозможно, увы. Однако мы можем использовать оценку отклонения средних, стандартную ошибку: именно это и лежит в критерии в знаменателе.
Сразу скажу, числитель критерия тут почти вообще ни при чём: небольшая выборка может быть весьма непоказательной по среднему, давая большую удаленность, но все-таки львиная доля ответственности в знаменателе, где у нас стандартная ошибка.
И проблема как раз в незнании дисперсии генеральной. Знай мы её, использовали сразу в стандартной ошибке, тогда от выборке к выборке у нас было бы константное значение, константа же тем и хороша, что означает отсутствие вариации. Критерий давал бы z-распределение, так как постоянно бы делили на одно и тоже значение при фиксированном размере для всех наших выборок.
Вместо этого мы вынуждены использовать _оценку_ стандартной ошибки (еще раз: оценку оценки) в знаменателе, где мы используем выборочную дисперсию. При небольших объемах эта выборочная дисперсия очень шумная, она сильно варьируется, при чем достаточно специфическим образом, на уровне приближения мы моделируем ее поведение через Хи-Квадрат, см. картинку (повторюсь сама она не совсем так распределена, но это уже духота), а у этого распределения при малых степенях свободы значения в массе своей лежат у нуля.
То есть: вы подставляете в знаменатель значения, близкие к нулю, а при делении на очень малое значение вы как результат получаете очень большое значения (в пределе бесконечность), вот вам и объяснения длинного хвоста. Но так как у вас бОльшая доля значений дисперсии около нуля, то подставляете в знаменатель близкие к нулю чаще прочих, оттого хвосты не только длинные, но и еще и толстые. Значения числителя, будь они даже около маленькие, "вымываются" из центра кратно меньшей дисперсией (чаще всего), делая центр более приземистым: он будет ниже и менее плотным в сравнении с нормальным, так как все уйдет в хвосты.
В этом смысле t-распределение хорошо абсорбирует шум от выборочной дисперсии небольших выборок, оно естественным образом дает нам необходимый запас осторожности (консерватизма), пока выборка мала. При n -> бесконечность, выборочная дисперсия будет приближаться к истинной, то есть практически не колебаться, а значит от выборки к выборке мы будем делить по сути на саму дисперсию, что и хочет от нас как раз z-критерий, поэтому t станет z! - то, с чего начинался пост.
Можно сказать пафоснее: t статистика это есть нормированная z статистика и при стремлении n в бесконечность у нас нормировка, - отношение дисперсии истинной на дисперсию оцененную, - превращается в 1. Такие дела)
P.S. Что такое средняя выборка вопрос риторический и зависит от природы данных, готовых ответов у меня тут для вас нет: собирайте данные вашего домена, исследуйте.
Интересный вопрос по базе: почему при средних объемах выборки мы используем t-распределение, если средние уже вроде бы распределены нормально?
Действительно, при некотором объеме выборки (условно 30-50 измерений) у нас соблюдается не только нормальность средних, но и выборочная дисперсия начинает вести себя предсказуемо (моделируется через Хи-квадрат, одно не 1-в-1 с ним совпадает!). Это обеспечивает в принципе t-распределение для большинства случайный величин, то есть что-то универсальное.
Но многих в контексте "среднего объема" выборок ставит в тупик наблюдение о выборочных средних согласно нормальном распределении, значит и перевод в z-score должно давать z-нормальное, однако применение критерия без знания дисперсии генеральной дает именно t-распределение. Почему?
Действительно, наблюдаешь нормальность средних, применяешь z-score = z-нормальное. Но это если есть знания отклонения средних, что на практике невозможно, увы. Однако мы можем использовать оценку отклонения средних, стандартную ошибку: именно это и лежит в критерии в знаменателе.
Сразу скажу, числитель критерия тут почти вообще ни при чём: небольшая выборка может быть весьма непоказательной по среднему, давая большую удаленность, но все-таки львиная доля ответственности в знаменателе, где у нас стандартная ошибка.
И проблема как раз в незнании дисперсии генеральной. Знай мы её, использовали сразу в стандартной ошибке, тогда от выборке к выборке у нас было бы константное значение, константа же тем и хороша, что означает отсутствие вариации. Критерий давал бы z-распределение, так как постоянно бы делили на одно и тоже значение при фиксированном размере для всех наших выборок.
Вместо этого мы вынуждены использовать _оценку_ стандартной ошибки (еще раз: оценку оценки) в знаменателе, где мы используем выборочную дисперсию. При небольших объемах эта выборочная дисперсия очень шумная, она сильно варьируется, при чем достаточно специфическим образом, на уровне приближения мы моделируем ее поведение через Хи-Квадрат, см. картинку (повторюсь сама она не совсем так распределена, но это уже духота), а у этого распределения при малых степенях свободы значения в массе своей лежат у нуля.
То есть: вы подставляете в знаменатель значения, близкие к нулю, а при делении на очень малое значение вы как результат получаете очень большое значения (в пределе бесконечность), вот вам и объяснения длинного хвоста. Но так как у вас бОльшая доля значений дисперсии около нуля, то подставляете в знаменатель близкие к нулю чаще прочих, оттого хвосты не только длинные, но и еще и толстые. Значения числителя, будь они даже около маленькие, "вымываются" из центра кратно меньшей дисперсией (чаще всего), делая центр более приземистым: он будет ниже и менее плотным в сравнении с нормальным, так как все уйдет в хвосты.
В этом смысле t-распределение хорошо абсорбирует шум от выборочной дисперсии небольших выборок, оно естественным образом дает нам необходимый запас осторожности (консерватизма), пока выборка мала. При n -> бесконечность, выборочная дисперсия будет приближаться к истинной, то есть практически не колебаться, а значит от выборки к выборке мы будем делить по сути на саму дисперсию, что и хочет от нас как раз z-критерий, поэтому t станет z! - то, с чего начинался пост.
Можно сказать пафоснее: t статистика это есть нормированная z статистика и при стремлении n в бесконечность у нас нормировка, - отношение дисперсии истинной на дисперсию оцененную, - превращается в 1. Такие дела)
P.S. Что такое средняя выборка вопрос риторический и зависит от природы данных, готовых ответов у меня тут для вас нет: собирайте данные вашего домена, исследуйте.
Forwarded from Не AБы какие тесты
Привет, товарищи-статистики! С праздником, днём Красной Армии, днём образования первой регулярной и массовой армии в мире, которая отстаивала интересы трудящихся.
Раз сегодня праздник, то и пост будет несложный, чтоб не прерывал отдых
Когда на курсе я с ребятами дохожу до p-value, мы рассматриваем распределение p-value при верности H0. Оно, распределение, равномерное, и частенько возникает вопрос: но почему оно равномерное? Ведь чаще же значения статистики будут у центра в рамках z-распределения, то есть как будто должно быть больше p-value's около 1 (с перекосом в пользу единицы).
А давайте посмотрим, почему равномерное.
Раз сегодня праздник, то и пост будет несложный, чтоб не прерывал отдых
Когда на курсе я с ребятами дохожу до p-value, мы рассматриваем распределение p-value при верности H0. Оно, распределение, равномерное, и частенько возникает вопрос: но почему оно равномерное? Ведь чаще же значения статистики будут у центра в рамках z-распределения, то есть как будто должно быть больше p-value's около 1 (с перекосом в пользу единицы).
А давайте посмотрим, почему равномерное.