¡Ya disponible! Investigación de Telegram 2025 — los principales insights del año 
Интересное что-то
Ir al canal en Telegram
Материалы и мысли, понадерганные отовсюду Блог: https://t.me/asisakov_channel Чат: https://t.me/youknowds_chat
Mostrar más594
Suscriptores
Sin datos24 horas
+27 días
+930 días
Archivo de publicaciones
Repost from Время Валеры
Прочитал интересную (и применимую) статью Rethinking Early Stopping: Refine, Then Calibrate.
Часто в курсах по машинному обучению говорят, что ошибку системы можно разложить на bias, variance, noise. На некоторых редких курсах даже учат, как это считать и что с этим делать дальше.
Попробуем посмотреть на эту проблему с другой стороны. В задачах вероятностной классификации loss для proper scoring rules можно разложить на: calibration и refinement.
Калибровка — мы сказали, что вероятность 80%. Сколько из взятых образцов будут принадлежать к классу 1? (Считать это можно через ECE — Expected Calibration Error).
Refinement — насколько хорошо модель разделяет классы. Допустим, модель выдала скор 0.9, все образцы оказались класса 1, а все, что ниже — класса 0. Модель откалибрована так себе, но разделяет классно. Собственно, если бы модель была откалибрована, мы могли бы выбирать отсечку вероятностно через саму вероятность.
Легко представить и обратную ситуацию: модель прекрасно откалибрована, но разделяет плохо. Например, модель, которая всегда предсказывает вероятность 50% для честной монетки, идеально откалибрована, но её разделяющая способность минимальна.
Из чего делаем вывод, что в какой-то момент улучшение функции потерь, из тех что относятся к семейству proper scoring functions, может происходить лишь за счет улучшения калибровки или даже ухудшать разделение, но за счет большого по величине улучшения калибровки выдавать лучший скор.
Это плохо. Калибровку часто можно существенно поправить потом post-hoc методами, поэтому остановка обучения по лоссу на валидации может привести к ситуации, что мы взяли далеко не лучший чекпойнт.
Что делать?
Сохранить несколько чекпойнтов модели.
Откалибровать каждый из них одинаковым методом.
Только после этого сравнивать их по loss.
В таком случае для каждого чекпойнта мы отдельно минимизируем доступную calibration error выбранным post-hoc методом (ссылка на запись вебинара), а разница в loss начинает лучше отражать именно качество разделения классов. Соответственно, мы выбираем модель с лучшей разделяющей способностью, а не ту, которая случайно оказалась лучше откалибрована на данном этапе обучения.
Проверили на датасетах для computer vision и 196 табличных датасетах — так и оказалось, победа.
Может ли это хотя бы частично объяснять эффекты вроде grokking или double descent?
Там мы тоже наблюдаем нетривиальную динамику loss во времени. Возможно, на ранних этапах обучения модель в основном улучшает калибровку, затем временно жертвует ей ради построения более качественной разделяющей поверхности, а потом начинает улучшать уже обе составляющие одновременно.
#ArticleReview
Repost from Denis Sexy IT 🤖
⚙️ Меня немного запарило, что все кодинг агенты не умеют из коробки делать актуальных на сегодня агентов, потому что внутри – модели еще не обучены всем современным агентским трюкам – поэтому я прошелся по исходникам Codex, Claude Code и других популярных уроков по созданию агентов, работу с кешами, авто-сжатием контекста и тп, и собрал скилл agents-best-practices который чинит эту проблему – причем, там отдельно прописано, что эти знания для всех видов агентов, не только для кодинга:
Там нет кода, есть текстовые справочники на темы – мне помогло:
Архитектура агентного harness Как устроить runtime вокруг модели: контекст, инструменты, permissions, память, наблюдаемость и остановочные условия. Agentic loop Базовый цикл: модель → tool call → валидация → permission check → выполнение → observation → следующий шаг или финальный ответ. System prompts и инструкции Как проектировать слои промптов: global, workspace, domain-specific, task-level и runtime reminders. Tools и permissions Как делать инструменты узкими, типизированными, безопасными, проверяемыми и разделёнными по risk class. Planning mode Как отделять планирование от исполнения: read-only exploration, план-артефакт, approval и потом мутации. Goal-like loop Как задавать долгоживущие цели с budget, checkpoints, validation criteria и stop condition. Это вместо Ralph Loop. Context, memory и auto-compaction Как управлять контекстом, делать retrieval, сохранять рабочее состояние и сжимать историю без потери критичных данных. Prompt caching и cost-aware context Как строить стабильные prompt-prefixes, deterministic tool ordering и cache-friendly agent runtime. Skills и progressive disclosure Как подключать reusable workflows: короткий skill index сначала, полные инструкции только при необходимости. MCP и external connectors Как подключать внешние системы через governed connectors: namespacing, auth, permissions, audit logs и least privilege. Security, approvals и sandboxing Prompt injection, secrets, approval flows, draft-vs-commit, sandbox для open-world tools. Observability и evals Как логировать agent runs, tool calls, approvals, compactions, failures и тестировать harness на реальные failure modes. Provider API patterns Практики для OpenAI, Anthropic и OpenAI-compatible API без привязки к одному провайдеру. Checklists и coverage audit Готовые списки для проверки: перед запуском, перед добавлением tools, перед подключением skills/connectors и перед продом.
Repost from Голос из-под шторки
Апгрейд мака
Сегодня получил новый макбук на работе. Обычно дают неделю на то чтобы переместить все данные со старого ноута, но мне потребовалось всего лишь несколько команд. Ладно, лукавлю, конечно же я воспользовался этой миграцией чтобы почистить всякое старье из своего сетапа на старом ноуте, но на новом реально всё завелось очень быстро. Расскажу как всё было.
Homebrew
Первая же команда которую выполняешь на любом макбуке после того как обновляешь систему и устанавливаешь
xcode-select --install — это поставить brew. За редким исключением в виде игр стима и корпоративных программ, всё что стоит на моём макбуке — всё поставлено и управляется через brew. Поэтому я просто дампнул на старом ноуте Brewfile, удалил оттуда программы, которыми я не пользуюсь и поставил всё из него brew bundle --file Brewfile. Кстати этим же способом можно поставить приложения из AppStore, а также go/cargo/uv пакеты.
Chezmoi
Вот поставили мы все программы — а с конфигурацией что делать? Руками копипастить конфиги? Завести всю home директорию под git? Лучшее решение — использовать dotfiles менеджер. Почему так называется? Потому что конфиги обычно лежать в домашней директории в папочках начинающихся с точки. .gradle, .config, .zshrc — вот эти все ребята. Я раньше пользовался Stow для такого, но давно хотел переехать на chezmoi и вот представился повод. Восстановить все конифги = скачать приватный гит репозиторий со всеми моими настройками и прожать chezmoi --source ~/.dotfiles apply. Прелесть chezmoi что он не только прилинкует файлы конфигурации но и вызовет нужные команды для сетапа.
Zinit
Chezmoi конечно менеджер конфигов, но для zsh нужен свой удобный фреймворк конфигурации. Чтобы были комплишены и нормальный поиск по истории. Кто-то ставит себе oh-my-zsh или zsh-for-humans. Я же терпеть не могу эти миллионы алиасов которые они насыпают. А ещё миллисекунды которые они добавляют на старт шелла. Поэтому я пользуюсь zinit и уже раньше писал про него в канале.
Asdf
Раз уж мы говорим про всякие менеджеры конфигураций, не могу не упомянуть asdf — под таким дурацким названием скрывается менеджер SDK и рантаймов. С небольшой конфигурацией он будет с лёгкостью одной и той же командой обновлять и переключать хоть текущую джаву, хоть ноду, хоть питон.
macos-defaults. sh
Это просто скрипт который выставляет настройки в system settings. Биндинги клавиш и всякое такое. Я обычно прошу это сделать агента, чтобы ещё и обновил этот скрипт. А то некоторые штуки очень легко потерять при переезде и потом искать.
На этом на сегодня всё, в следующих постах расскажу что же я оставил в своём Brewfile как абсолютно необходимое для работы. Честно говоря без одной из этих программ я вообще как без рук, мне физически тяжело пользоваться макбуком. Угадаете — какой?Repost from ML for Value / Ваня Максимов
The art of a strong baseline
За последнее время все чаще понимаю, что создать сильный бейзлайн - это не просто база, с которой нужно начинать любой ml/ai продукт, а прям полноценная часть системы. Даже когда в проде уже давно есть трансформеры и агенты, бейзлайн дает прям много метрик
Вот учите вы трансформер для персональных рекомендаций (sasrec, argus, pinnerformer, hstu - неважно).
И если в лоб его применить, то вероятно получите рекомендации из истории кликов. Потому что простой бейзлайн "уже изучал товар - покажи еще раз" чаще всего почти по любым метрикам релевантности будет лучше
Окей, пофильтровали историю кликов / занизили таким позитивам вес в лоссе / сделали еще что-то - получили очень-очень похожие товары на последние 30-50 действий. Вот буквально товар того же бренда-категории, но чуть другого цвета условно. А это уже похоже на другой сильный бейзлайн - realtime slim/als/ease на последних 30-50 действиях
На самом деле можно еще и дальше продолжать с бейзлайнами в этом кейсе или в других. Частые бейзлайны:
- Персональные рекомендации - популярное, история, уже купленное для повторных покупок
- item2item рекомендациях (похожие товары) - популярные товары того же бренда в той же категории
- Поиск - tfidf/bm25. Да, даже в эру dense retrieval и search agents если аккурфтно подтюнить bm25, то можно выбить sota. Есть даже подходы на основе Sparse autoencoderse , которые позволяют генерить не эмбеды запросов/документов, а их токены - и дальше применять обычный bm25
- Прогноз временных рядов - среднее значение в тот же день недели
↔️ Я всегда стараюсь строить сильные бейзлайны, а потом учить более сильные модели для улучшения поверх них, а не для замены. Потому что какой толк учить условный sasrec/argus для запоминания истории кликов пользователя? Пустая трата компьюта + модель тратит свою капасити на тривиальные зависимости = что-то нетривиальное (и самое полезное + ожидаемое от нее) не учит
Интересно, как не только я сам, но и другие люди в в индустрии / рисерче к этому подходят: я видел очень мало подобных работ. Если есть личные опыт или ссылки на полезные статьи - кидайте, с интересом почитаю!)
Repost from VF | Science
6. Дальше RL. В речи RL зашёл быстро, потому что есть объективные метрики. TTS-1 берёт α·R_WER + β·R_SIM + γ·R_DNSMOS, считает всё через Whisper/WavLM/DNSMOS и катит GRPO. Без разметчиков. Плюс хитрость - conditional activation: reward на эмоции активен только на сэмплах с тегом эмоции, иначе он бессмысленно штрафует базовые сэмплы. Qwen3-TTS делает DPO, потом GSPO для стабильности на разных задачах.
В музыке всё сложнее, потому что объективных метрик там нет. Musicality, harmony, запоминаемость - субъективщина. Два разных подхода. LeVo делает multi-preference DPO: три оси (lyric alignment через PER, соответствие промпту через MuQ-MuLan, musicality через human seed -> reward model -> 60К пар), под каждую обучают отдельный DPO, потом линейно интерполируют веса трёх моделей. Если оптимизировать одну ось - другие проседают. Интерполяция обходит этот конфликт.
ACE-Step v1.5 пошёл дальше всех. Они отказались от внешних reward моделей вообще и придумали intrinsic rewards - модель сама себе judge через свои внутренние свойства. Attention Alignment Score считается прямо из кросс-атенншн карт диффузии: насколько внимание покрывает все lyric-токены, насколько оно монотонно движется по времени, насколько уверенно сидит в осмысленных регионах. Через DTW аггрегируется в один скаляр, корреляция с человеческой оценкой выше 95%. Далее Pointwise Mutual Information: одна и та же LM играет роль Composer (текст -> audio codes) и Listener (audio codes -> текст). Reward - это насколько Listener восстанавливает исходный промпт. Если модель сгенерила что-то общее, Listener даст generic caption, PMI будет около нуля. Если сгенерила что-то конкретное и попадающее в промпт - PMI большое. Никаких внешних judge'ов, никакого bias, никакого дрифта на странных генерациях.
И ещё ACE-Step применяет RL не только к генератору. У них GRPO ещё и на captioner'е в пайплайне разметки. Улучшается captioner - улучшается весь корпус - улучшается финальная модель.
#audio #perfomances
Repost from VF | Science
👀 Audio Generation 2024-2026
Недавно собрался силами провести семинар в МИСиС от AIKC. Рассказал как сейчас делают генерацию музыки и речи. От подготовки данных из большых сырых корпусов, до применения RL. Поделился своими инсайдами и направлениями ресерча. Презу приложил к посту. Запись выложат на Stepic. Тут поделюсь сухой выжимкой без моих размышлений и комментариев)
Структура семинара поделилась на общие паттерны для речи и музыки, и специфичные для речи и музыки. Некоторые идеи отлично ложатся с одного домена на другой, но еще не были применены для речи/музыки.
1. Говоря о данных, а у нас корпуса могут доходить до 5М часов как в Qwen3-TTS, или 1М часов как в Inworld TTS-1, или 27М семпов музыки как в ACE-Step-1,5... Хочется уметь автоматически и качественно отбирать данные для претрейна/CPT/SFT. В речи есть объективные метрики типа WER/PER, SIM, всякие MOS'ы. Это более приятный сценарий, в отличие от музыки, где нет объективных метрик. Поэтому сейчас хороший сценарий для музыки - использовать frontier LLM модели типа Gemini 2.5 Pro. Авторы ACE-Step предложили занятный self-evolving pipeline.
2. Говоря о репрезентациях аудио, сейчас идет смещение к аудио кодекам. В речи главный приоритет - стриминг. Низкий битрейт 12-25Hz, casual-only decoder для реалтайма, а попытки сжать битрейт еще ниже до 5Hz обычно неудачны, НО недавно вышел SiTok. В музыке стриминг не нужен, нам скорее хочется сделать кодек работающий с 48kHz аудио и длинным контекстом. Длина последовательности при 25Hz ~= 7500*количество кодбуков, бюджет растет до десятков тысяч токенов. Плюс хочется учитывать когерентность между треками: вокал и разные инструменты аккомпанемента. Авторы LeVo придумали классный кодек для этого. А для работы с длинным контекстом хорошее решение предложили авторы Qwen3-TTS, сделали curriculum по контексту с 8 до 32к токенов. Конечно сейчас также мейнстрим разными способами добавлять семантику в кодеки, стандарт - стиль Mimi Codec.
3. Собрав данные и определив репрезентации, подумаем о архитектуре. Тут мне нравится схема от BLIP3o-Next, хоть тут и про картинки. Их AR+Diffusion пайплайн. Накидывают RL на AR для хорошего понимания сцены, позиционирования объектов, прочей семантики. Потом через кросс-атеншн в DiT блоки добавляют инфу из AR блока. Почитайте работу) В речи подобный паттерн нарастает.
Впрочем, говоря про pure AR: готовый стек LLM, in-context learning — voice cloning «из коробки», законы масштабирования, но бывает exposure bias, hallucinations, repetitions и качество ограничено codec bottleneck. Иначе гововря про Non-AR: параллельная генерация — нет последовательной задержки, continuous latents — нет codec bottleneck, нет exposure bias, но alignment text-audio — центральная сложность, long-form coherence хуже, чем у AR, тяжелее применять RL
4. Переходя к обучению, конечно увидим пайплайн PT->CPT->SFT->RL, а говоря про инференс и стримнг обратите внимание на техрепорт Iworld TTS-1. В музыке говоря про long-context снова обратите внимание на curriculum по длине от Qwen3-TTS, про структурное сегментирование у YuE/ACE-Step, dual-treck+mixed tokens generation от LeVo.
5. Для управляемости генерацией мейнстрим - LM как планировщик. Вместо промпт -> output делают промпт -> LM blueprint -> output. В речи это thinking pattern из Qwen3-TTS, активируется для сложных voice description промптов, как ризонинг в LLM. Плюс emotion/non-verbal tags ([whispering], [breathe]), которые в Inworld TTS-1 учат через LoRA на парных (neutral, stylized) данных - полный FT теряет базовую cloning capability. В музыке размах больше: ACE-Step делает Composer Agent, который раскладывает «sad jazz ballad» в YAML с BPM, key, structure, instruments, mood - DiT-рендерер занимается только акустикой. YuE добавляет structural progressive conditioning - генерация по сегментам [verse][chorus][bridge] с передачей контекста, авторы явно называют это CoT для музыки.
#audio #perfomances
Repost from Валера Ковальский
Сравнение топовых harness на локальных моделях
Совместно с rnd отделом red_mad_robot подготовили и провели данный бенчмарк, отдельное спасибо Андрею Иванову за подготовку стендов и проведение бенчмарка!
Модели взяли LLM хаба https://hub.neuraldeep.ru/
Сохраняйте ссылку на бенчмарк, теперь это буде регулярная страничка которую мы будем обновлять!
Бенчмарк: https://hub.neuraldeep.ru/#harness
Лидерборд будет пополнятся моделями
Drift планируется к open source в этом году!
gpt oss 120b | Qwen3.6-35B-A3B
Все модели были развернуты на rtx 6000 pro/4090(48gb x2)
Как вывод абсолютный лидер сегодня это hermes agent
Даже удалось погонять на PAC1 от Рината!
Repost from N айтишниц заходят в бар
В прошлом году в мы брали интервью у Насти из Avaturn, а сегодня мы принесли вам потрясающий релиз от ребят💃
Команда Avaturn.live выложила в опенсорс AVTR-1 - фреймворк, который позволяет вести видео диалог с аватаром в реалтайме.
Загружаете фотку, и болтаете с героями любимых мемов!
(если конечно у вас есть видеокарта)
🐰В релиз входят:
— веса модели
— инференс-стек, оптимизированный под TensorRT
— бэкенд для запуска живой диалоговой сессии end-to-end
💅Насколько мы знаем, это первый публичный опенсорс-релиз, где в комплекте идёт не только модель, но и серверный стек для интерактивной сессии.
Производительность:
— RTX 3070 / 4060 Ti — реал-тайм
— A100 / L40 — более чем 2× быстрее реал-тайма
💻 То есть вам хватит обычной игровой карты, чтобы поговорить с кастомным аватаром, а если лень настраивать локально - с демо версией.
💻 https://github.com/avaturn-live/avtr-1
🌐 https://avaturn.live/demo
🤗 https://huggingface.co/avaturn-live/avtr-1
С вас лайки и звездочки на гит!
Оставляйте ваши технические вопросики в комментах, вам ответят авторы этого шикарного дропа 🎉
Repost from Тимлид Очевидность | Евгений Антонов
Я принес. Почему новички получают больше, чем старые сотрудники?
Казалось бы, никогда такого не было и вот опять. https://t.me/grade_practicum/1106
Не абы кто, а сам Harvard Business Review сделал исследования и установил, что новичкам платят больше, для их привлечения, пока недоиндексированные до этого уровня старички про это узнают, расстраиваются и уходят.
Вроде бы и не новость никакая. Ну кто такого не видал?
Я еще 5 лет назад (звучит-то как – 5 лет!) писал про добавочную стоимость старожилов.
Потом, спустя полгода, уточнял, что у новичков тоже есть польза, которой нет у старослужащих, так сказать.
На всё это намазываем хороший разбор про финансовую мотивацию и демотивацию от Александра Клименко.
Приправляем согласием с авторами исходного поста, что ничего не утаишь и если не все всё знают, то многие.
И получаем сложную управленческую дилемму, которую мы в Трех тимлидах разбирали аж в двух частях. В один не уложились. Часть 1 и часть 2.
Какой посыл у сегодняшнего поста, распадающегося на кучу связных тематических материалов?
Он в том, что если решение, что новички получают больше, чем старые сотрудники обосновано, осмыслено и приняты все риски – это нормальная (тут «нормальное» – не синоним слова «хорошее», а производное от «норма») в бизнесе история.
А вот если это просто потому что «ну они молчат, есть не просят, вот и пусть дальше молчат, либо скажут, и мы там подумаем, какого размера кость в будку кинуть», то будет всё как в изначальном исследовании. Первыми разойдутся самые толковые. Будете новичками, да засидевшимися дела делать.
Repost from Статистика и R в науке и аналитике
Материалы для подготовки к продуктовой секции
Выше писала как прокачивать продуктовое мышление самостоятельно, а сегодня будет список источников, что почитать и послушать на эту тему.
Книги:
🟡Lean Analytics, это классика, но написана немного тяжелым языком и есть только на английском, сама тоже читаю сейчас.
🟡Доверительное АБ тестирование, больше про тесты, но для общего понимания тоже полезно. Я писала даже небольшой обзор на нее
🟡Спроси маму (Роб Фитцпатрик) – небольшая книга про эмпатию и правильные вопросы пользователям, есть кстати у нас на Литрес. Я прочитала, интересно, хотя и напрямую на собеседовании не факт что поможет)
Фреймворки для структурирования метрик:
🟡AARRR – пиратские метрики. Фреймворк описывает путь пользователя через воронку: Acquisition → Activation → Retention → Revenue → Referral. Помогает понять, какой этап воронки самый проблемный и где может быть наибольший рост. Подробнее почитать можно здесь и здесь.
🟡HEART – фреймворк от Google для продуктов, больше про пользовательский опыт. Расшифровывается как Happiness, Engagement, Adoption, Retention, Task Success. Неплохая статья тут, а оригинальная статья от гугл по этой ссылке.
🟡CJM (Customer Journey Map) – карта пути пользователя. Помогает разложить метрики с точки зрения юзера. Шаблон в Miro
🟡Дерево метрик, иерархия метрик – декомпозиция North Star Metric на составляющие. Это довольно часто спрашивают на собеседованиях, могут попросить накидать дерево метрик для конкретного продукта. Ознакомиться подробнее можно здесь.
Я считаю, что классификации и фреймворки выше не охватывают все многообразие метрик с точки зрения философии 😁 (а точнее правил деления, писала здесь).
Однако перефразируя классику, все классификации неверные, но некоторые полезные. Поэтому рекомендую ознакомиться с источниками выше, для всех интересующихся продуктовой аналитикой.
База по юнит экономике:
Лекция Ильи Красинского. Материал топ, но признаться честно с первого раза не осилила, смотрела в несколько подходов.
Еще очень рекомендую статьи на gopractice, много всего полезного по теме продуктового мышления. Например, статья про метрики роста и метрики продукта.
#analytics #собес_PA
