Data Science | Machinelearning [ru]

Четыре истории внедрения ИИ в бизнесе: агент для заявок, RAG по документам и проверка сметы нейросетями «Внедрить ИИ» — формулировка, за которой на практике скрываются совершенно разные по масштабу работы. Одной компании нужен агент, который годами живёт на сервере и разбирает входящие заявки. Другой — разовый прогон одного документа через связку нейросетей перед подписанием акта. Третьей автоматизация вообще ни к чему: важнее, чтобы команда сама умела ставить задачи агенту и проверять результат, без подрядчика на каждое изменение. Читать далее 👉 Data Science | Machinelearning [ru]

ИИ-инфраструктура — это не купил видеокарту и погнал. Да, можно взять NVIDIA H100, поставить PyTorch и думать, что ты король. Будешь как на Ferrari в час пик стоять. Дмитрий Шиченко из Selectel вскрыл тему: без нормального пайплайна и баланса — твой сервер просто греет воздух. Инференс летит в жопу, если не продумать шину, память, архитектуру. Они собрали свой AI-сервер и расписали принципы. Не для галочки — для реальной работы. Коротко: железо — только половина дела. Вторая половина — как ты это упаковал и настроил. Хватит тупить. Читай разбор: ссылка Пошел ботать. 👉 Data Science | Machinelearning [ru]

Selectel запустила третий сезон своего IT-кроссворда, и на этот раз тема — AI и ML. Если ты думаешь, что это просто очередной развлекательный конкурс, ты ошибаешься. Тебя ждут больше 100 вопросов о моделях ИИ, истории AI, безопасности, железе для ML и прочей базе, которую, если ты называешь себя специалистом, должен знать хотя бы на уровне «слышал и могу объяснить». Вопросы разной сложности — от «что такое нейросеть» до «как оптимизировать градиент». Рубрики разбиты по темам, так что даже новичок найдет, где потыкаться, а опытные могут проверить, не заржавели ли знания. Правила простые: отвечаешь, набираешь баллы, попадаешь в топ. Знатоки получат эксклюзивный мерч Selectel и бонусы на аренду серверов. Не ради мерча — ради того, чтобы понять, насколько ты шаришь. Читать далее Не откладывай на вечер пятницы. Открывай, читай, отвечай. 👉 Data Science | Machinelearning [ru]

Как в Яндекс Лавке боролись с замкнутым кругом рекомендаций Рекомендательная система со временем замыкается на привычках пользователя и перестаёт показывать что‑то незнакомое — интересы меняются, а система этого не замечает. Изменить ситуацию удаётся лишь ценой краткосрочных потерь. Рамиль Боярченков из команды Яндекс Лавки рассказывает, как собрали механизм, который подмешивает незнакомые товары персонально — тем, кто к ним расположен, и с какой вероятностью это делать для каждого пользователя. Читать далее: https://habr.com/ru/companies/yandex/articles/1051044/ 👉 Data Science | Machinelearning [ru]

⁣Динамический merge скоринговых реплик TensorFlow и GBDT через online-совместную реоптимизацию сплитов на стыке признаковых пространств Когда в production-пайплайне работают две принципиально разные модели — TensorFlow (нейросеть) и GBDT (бустинг), — и возникает необходимость объединить их скоринговые реплики, стандартные подходы дают сбой. Усреднение выходов без учёта структуры дрейфа данных ломается, а мета-модель устаревает, как только распределение признаков сдвигается. Типичная ошибка — считать, что статическое усреднение или простая мета-модель решают проблему на non-stationary данные. Проблема статического merge Простое взвешенное усреднение (например, 0.5 * прогноз TF + 0.5 * прогноз GBDT) работает только пока валидационное распределение совпадает с production. В моей практике на рекомендательной системе в рекламном RTB-трафике это приводило к падению ROC-AUC на 3-4% при дрифте сезонных паттернов. Каждая переобучение всей связки — неделя времени. Причина — модель не адаптируется к локальным изменениям на стыке пространств. Динамический merge с online-реоптимизацией сплитов Решение — не складывать выходы, а построить общее признаковое пространство из эмбеддингов TF (выходы последнего скрытого слоя) и leaf values GBDT с градиентами. На этом стыке мы запускаем онлайн-дерево, которое пересчитывает сплиты на каждом новом батче. Пример из пайплайна click-through rate prediction: батч пришёл -> вытащили эмбеддинги TF -> предсказали листья GBDT -> склеили в joint-вектор -> прогнали через онлайн-дерево, которое реоптимизирует сплиты на основе градиента. Важно: ни TF, ни GBDT не переобучаются. Это снижает cost на адаптацию на 80% по сравнению с full retrain. Баланс bias/variance и практический совет Самый тонкий момент — не словить шум. Если пересчитывать сплиты на каждом батче без early stopping, модель начнёт подстраиваться под единичные выбросы. Личный опыт: я использую валидационное окно из последних 100 семплов. Как только метрика на окне перестаёт улучшаться — сплиты замораживаются до следующего триггера дрейфа. Это даёт стабильный прирост ROC-AUC на 3-5% на дрифтящих данных. Типичная ошибка и trade-offs Ошибка — пытаться реоптимизировать сплиты без учёта latency. Если joint-пространство получается большим (например, эмбеддинги 512-мерные, листьев 1000), online-дерево может тормозить. Решение: сжимать эмбеддинги через PCA до 32-64 компонент и ресамплировать листья по частоте. Это увеличивает latency всего на 2-3 мс на батч, но снижает cost на 5x. Иначе — перегрузка памяти и просадка throughput. Вывод: Динамический merge через online-реоптимизацию сплитов на стыке признаковых пространств позволяет адаптировать ансамбль из TF и GBDT к дрейфу без полного переобучения, давая устойчивый прирост метрик при контроле bias/variance и latency.

🤣 Мы все ждали когда это начнётся ✖️ xCode Journal

Ну что, пришло время оптимизации на RISC-V? Звучит как что-то для гиков, которые не боятся копаться в регистрах. Ребята из YADRO и НГТУ решили, что детектор углов на OpenCV можно ускорить. И знаешь что? Они это сделали. Никакой магии — алгоритмические костыли, ручная векторизация через RVV и тесты на плате Lichee Pi 4a. Результат: лучшая эффективность. Смотри, в чем соль. Обычно ты берешь OpenCV, запускаешь на x86 и молишься, чтобы все летало. А тут архитектура RISC-V, где каждый такт на счету. Они не просто переписали код — они выжали из алгоритма все соки: убрали лишнее, добавили параллельность, оптимизировали под конкретный чип. Это тебе не курс по ML на коленке, а реальная работа с железом. Для новичков: детектор углов — это база компьютерного зрения, алгоритм находит точки, где картинка меняет контур. Без этого роботы не видят препятствия, а камеры не фокусируются. Для опытных: векторизация RVV — это не SIMD из Intel, здесь свои тараканы, но подход тот же. В общем, читаем статью, если хочешь понять, как выжать максимум из RISC-V, а не просто сохранять туториалы в закладки. Вот ссылка 👉 Data Science | Machinelearning [ru]

Слышал новость? Роботы уже бегают быстрее людей, а ходить ровно всё ещё не могут. За 2026 год двуногие машины пробежали полумарафон быстрее человеческого рекорда, CEO публично резал роботу ногу ножницами, а на презентации за миллионы долларов механизм тупо завалился на ровном месте. Сюрприз: походка теперь делается за 20 минут на одной видеокарте — это дешёвая инженерия. Но "живой" робот упирается в ватты, переполняющийся контекст и отсутствие непрерывного обучения. Простыми словами: база есть, а мозгов нет. Всё упирается не в железо, а в то, как оно учится не падать. Кому вкатываться — сначала разберись, как работает контекст и continuous learning. Без этого любая походка превратится в цирк на собеседовании. Читать разбор Работаем. 👉 Data Science | Machinelearning [ru]

Сравнение методов дообучения LLM: главный показатель качества Исследователи лаборатории научных исследований Т-Технологий представили на ICML 2026 единый подход к сравнению методов дообучения больших языковых моделей, которые учатся на заранее подготовленных парах ответов. Разные методы часто сравниваются в разных условиях: этапы обучения, настройки и способы оценки ответов. Чтобы привести методы к сопоставимым условиям, исследователи разложили одноэтапные подходы (ORPO, ASFT) на два шага: supervised fine-tuning и отдельное выравнивание на парах ответов, а также ввели параметр β, регулирующий силу дообучения на человеческих предпочтениях. Исследователи пришли к выводу: качество сильнее всего зависит не от алгоритма, а от того, сравнивает ли модель ответы напрямую или оценивает их по отдельности.

«Один из главных выводов в том, что модели лучше учатся выбирать ответ, когда напрямую сравнивают два варианта между собой, а не оценивают каждый по отдельности»,

— рассказал руководитель лаборатории Даниил Гаврилов. Так, попарные методы (pairwise) чаще дают результаты лучше, чем поточечные (pointwise), особенно на задачах средней сложности. В работе использовались Llama 3.2 3B, Llama 3.1 8B, Mistral 7B, Qwen 2.5 7B и 14B, обученные на данных Reddit TL;DR, UltraChat и UltraFeedback. 👉 Data Science | Machinelearning [ru]

Koda Pro решила поджарить Claude-sonnet Новая версия Koda Pro на GLM 5.2 выстрелила в SWE-bench Verified. Старая версия показывала 59% — норм, но без фанатизма. Новая — 77.4%. Это на 10% выше старичка и почти догоняет Claude-sonnet-5 с его 78.8%. Что сделали: перелопатили агентные инструменты, натянули системный промпт и докрутили обучение. Результат — дерзкий скачок. Новичкам: не тупите в бездну абстрактных курсов. Откройте SWE-bench, посмотрите, как такие штуки тестируют код. Это сразу покажет, что вы умеете, а что нет. Опытным: если ваши pet-projects не проходят даже половину таких бенчмарков, вы что-то делаете не так. Время подтянуть инструментарий. Пошел читать статью и не ныть. 👉 Data Science | Machinelearning [ru]

⁣Оптимизация распределённого жадного поиска сплитов в GBDT: вычислительное бюджетирование Узкое место любого GBDT под нагрузкой — жадный поиск порогов для сплитов. Когда фич под тысячу, а строк миллионы, строить гистограмму для каждой на каждом узле — взрывной рост стоимости. В распределённой среде это буквально трата времени на заведомо мусорные сплиты. Почему это важно В production ML сценариях с высокой нагрузкой — мониторинг потоковых данных, обучение на Spark, CatBoost в real-time — каждая микросекунда на сплит умножается на число фич и глубину дерева. Типичная ошибка: строить плотные гистограммы для всех фич, даже для разреженных или с низким градиентом, что перегружает сеть и CPU. Идея вычислительного бюджетирования Вводим явный бюджет — лимит на количество гистограмм на узел. Фичи ранжируются по эвристике: сумма абсолютных градиентов или плотность ненулевых значений. Для разреженных фич это особенно спасает — они отсекаются до передачи данных между узлами. Пример псевдокода для распределённой среды:

def allocate_budget(feature_stats, budget=100):
    scores = {feat: len(nonzero_grads[feat]) for feat in feature_stats}
    sorted_feats = sorted(scores, key=scores.get, reverse=True)
    return sorted_feats[:budget]

for tree_level in range(max_depth):
    budget_features = allocate_budget(current_stats)
    parallel_build_histograms(budget_features)

Production-кейс и trade-offs Из опыта внедрения в streaming-обучении: фаза сплита ускоряется на 40-60% при том же качестве. Сетевого трафика меньше — передаём гистограммы только по отобранным фичам. Однако есть нюанс: если бюджет задан без учёта gain от корня, можно отсечь хорошие сплиты в глубине. Слишком агрессивное бюджетирование (меньше 5% фич) — потеря информативности, особенно на сложных узлах с низкой чистотой. Практический совет Используйте адаптивный бюджет под сложность узла: для корневых узлов с большим gain можно увеличить бюджет, для глубоких — уменьшить. Это даёт баланс между скоростью и качеством, особенно в streaming-сценариях с ограничением по latency. Типичная ошибка Фиксированный бюджет на все уровни дерева без учёта распределения градиентов. На ранних узлах это может отсечь потенциально сильные фичи, которые станут доминантными глубже. Лучше динамически пересчитывать budget_features на каждой глубине. Вывод: Вычислительное бюджетирование — простой и эффективный способ снизить latency в GBDT под нагрузкой, но требует адаптивного управления, чтобы не потерять качество из-за преждевременного отсечения фич.

Вечная тема: все хотят "говорить свободно", но в реальном диалоге впадают в ступор через 10 секунд. А продаваны курсов с радостью впарят тебе очередного "AI-тьютора", который отвечает через раз и с пятисекундной задержкой. Парень на Хабре расписал свою Aisha — голосового репетитора английского. Это не просто обертка над GPT. Он реально запарился над архитектурой: голосовой ввод, стриминг, обработка ошибок в моменте, чтобы диалог не превращался в пытку лагами. Суть проблемы, которую он решил: если тупо гонять аудио туда-сюда через API, живой диалог сдохнет на старте. Надо обрабатывать поток, резать payload и не проваливаться в задержки под контекст. Это hard mode, а не игрушки.

Новичкам: не пытайтесь сразу клепать таких монстров. Сначала научитесь гонять через whisper одну фразу и получать осмысленный ответ. Это база.

Для тех, кто шарит: статья — норм разбор того, как резать лаги в реалтайм-диалоге. Полезно, если пилите своего бойца.

Короче, идем читать, а не сохраняем в закладки до лучших времен. Пора разобраться, как это работает, а не просто пользоваться сырым говном от стартапов. Тута ссылка на разбор архитектуры, payload и модели. Поехали. 👉 Data Science | Machinelearning [ru]

⁣Многорукие бандиты с контекстом в микросервисном ранжировании: как не утонуть в сервисах Цепочка ранжирования из нескольких сервисов — это не просто конвейер, а распределенная задача обучения с подкреплением. Типичная ошибка — внедрять бандита на каждый узел изолированно, не учитывая сквозной эффект решений. Проблема фрагментации контекста Каждый микросервис видит только свой контекст: сервис кандидатов знает время суток, сервис фич — нагрузку на вычисления, модель — идентификатор эксперимента, пост-процессинг — бизнес-правила. Если каждый из них принимает жадное или исследовательское решение независимо, цепочка накапливает шум. Контекстуальный бандит на финальном шаге бесполезен, если предыдущие узлы сгенерировали нерепрезентативные состояния. Архитектура с общей обратной связью Рабочее решение — цепочка контекстуальных бандитов, где каждый узел получает два сигнала: глобальное вознаграждение (например, CTR) и локальное (latency, ошибки). Ключевой трюк — смешивание их с фиксированными весами: reward = 0.7 * глобальный CTR + 0.3 * локальный latency Пример из продакшена: - Сервис A выбирает источники кандидатов. Контекст: время суток, тип устройства. - Сервис B решает, делать полный пересчет фич или инкрементальный — это влияет на latency и свежесть признаков. - Сервис C выбирает версию модели: explore или exploit. - Сервис D применяет бусты/дебусты в пост-процессинге. Все бандиты работают с одним session_id (через OpenTelemetry) для трекинга сквозных цепочек. Вознаграждение выплачивается после завершения всего запроса — используем delayed rewards и policy gradient, а не Q-learning, чтобы избежать переобучения на локальных паттернах. Практический совет и типичная ошибка Реализация элементарна: класс с альфой на скользящее среднее и двумя полями под reward. Но главное — не добавлять бандита на узел, который не генерирует измеримого изменения в глобальной метрике. Иначе получите фоновый шум, который только увеличит variance A/B теста. В нашем эксперименте на production: рост CTR +15% при сохранении latency. Сервисы остались автономными, но скоординированными. Добавление нового узла в цепочку — просто протянуть session_id и определить свой reward. Вывод: Цепочка контекстуальных бандитов с общей обратной связью позволяет координировать микросервисы ранжирования без нарушения их изоляции, но требует явного смешивания глобальных и локальных метрик для стабильного обучения.

⁣Динамический выбор алгоритма ветвления GBDT на основе аппаратных счетчиков производительности Когда production GBDT внезапно начинает тормозить на одинаковой нагрузке, корень часто не в модели, а в том, как она ветвится на конкретном железе. CPU последовательно долбит if-else с промахами в prefetch, а GPU простаивает из-за дивергенции варпов. Типичная ошибка — фиксировать стратегию ветвления (left-heavy, depth-first) без учета аппаратных счетчиков. Проблема статического ветвления Классические GBDT-библиотеки (XGBoost, LightGBM) используют фиксированный порядок обхода дерева. На CPU это приводит к cache misses при холодных данных или branch miss penalties при нерегулярных паттернах. На GPU — к warp divergence, когда разные треды в варпе идут по разным веткам. В одном production-кейсе с XGBoost инференс на CPU vs GPU давал разницу в 2x из-за структуры дерева, хотя сама модель была идентична. PMC-управляемое ветвление на CPU Решение — на лету переключать алгоритм ветвления, используя Performance Monitoring Counters (PMC). Следим за: - INSTRUCTIONS RETIRED — нагрузка на ядро; - BRANCH MISS PREDICT — если >5%, переходим на предикаты (вычисляем обе ветки, выбираем результат); - CACHE MISS (L1/L2) — при высоких значениях включаем prefetch и column-wise layout. Пример: если cache miss >10% и branch miss predict <3%, оставляем row-wise traversal. Иначе — переключаемся на column-wise с prefetch-инструкциями через __builtin_prefetch. Мониторинг через libpfc или perf_event_open добавляет 1-3% overhead, но стабильно выигрывается 10-25% latency на стриминге. GPU адаптация: occupancy и дивергенция На GPU ключевой параметр — warp divergence. Порог — 30%: при превышении реорганизуем дерево в SIMD-дружественную структуру. Листья одного уровня упаковываются в плоский массив, а ветвление заменяется на gather/scatter из __shfl_sync. Работает через NVML или cupti для чтения счетчиков. Выигрыш 15-40% времени при стриминге, но портировать на ARM сложно (PMC там другие). Trade-offs и ML-управление Static-библиотеки не учитывают реальную нагрузку. Использование PMC добавляет overhead, но окупается на горячих путях. В production я добавил маленький регрессор (20 признаков из PMC) для предсказания оптимальной стратегии. Overhead тот же 1-3%, но точность подбора выше — снижает branch miss еще на 5%. Минус: портирование между x86 и ARM требует переписывать парсеры счетчиков. Вывод: Динамический выбор алгоритма ветвления GBDT на основе аппаратных счетчиков позволяет выжать 15-40% производительности на CPU и GPU, но требует учета overhead мониторинга и архитектурных различий.

⁣Сидеть и работать в корпорации страшно, жизнь-то мимо проходит. Уходить строить бизнес страшно, а вдруг прогорит. Один из вариантов - разрабатывать свой пет-проект по вечерам. Многие успешные компании, например, Twitter, создавались именно так. Это не значит, что ваш проект обязательно заработает миллиарды, но заработать больше, чем в найме, и получить ценный опыт вполне реально. Перед началом разработки появляется множество вопросов, например: – Как выбрать идею для пет-проекта? – Что нужно знать про маркетинг? – Как запуститься и довести до первых продаж не имея бюджета на рекламу? В телеграм-канале Твой пет проект, Михаил Табунов делится своим опытом с разработчиками и менеджерами. Он рассказывает, где искать идею для нового проекта, что нужно знать о маркетинге, как запустить стартап и привлечь первых 10 клиентов, а также о многих других важных вещах. Подписывайтесь на Твой пет проект получайте пользу от практиков рынка!

⁣Как измерять качество рекомбинации сплитов в GBDT при динамическом изменении числа деревьев в serving: три online-метрики для production Когда в serving число деревьев меняется динамически — из-за A/B-тестов, калибровки композитных моделей или адаптации под latency — классические offline-метрики пасуют. Рекомбинация сплитов, где разные деревья используют одинаковые разбиения, становится скрытой точкой отказа, которую не видят ни AUC, ни logloss. Gradient Overlap Процент деревьев с совпадающими сплитами по признакам на последовательных итерациях. Если overlap выше 70%, рекомбинация стабильна. Ниже — шум или переобучение. Практический совет: используйте Gradient Overlap как триггер остановки добавления деревьев — при overlap менее 50% увеличение числа деревьев скорее всего ухудшит обобщение. Split Importance Drift Корреляция Спирмена топ-10 сплитов по gain при n и n+1 деревьях. Дрифт выше 0.3 — сигнал к корректировке hyperparams. Типичная ошибка: игнорировать этот дрифт и продолжать наращивать деревья, ухудшая как latency, так и качество. Online-AUC на скользящем окне AUC на окне из N=20 деревьев показывает, как рекомбинация влияет на качество при добавлении или удалении. Production-oriented пример: в fraud detection или real-time bidding каждое дерево критично — online-AUC выявляет момент, когда рекомбинация ломается, раньше, чем offline-метрики.

import numpy as np
from scipy.stats import spearmanr

class OnlineSplitTracker:
    def __init__(self, window_size=20):
        self.window_size = window_size
        self.split_gains = []
    
    def update(self, tree_splits, tree_gains):
        self.split_gains.append(tree_gains)
        if len(self.split_gains) > self.window_size:
            current_top = self._get_top_features(-1)
            prev_top = self._get_top_features(-2)
            drift, _ = spearmanr(current_top, prev_top)
            print(f"Split drift: {drift:.3f}")
    
    def _get_top_features(self, idx):
        agg = {}
        for gains in self.split_gains[idx]:
            for feat, gain in gains.items():
                agg[feat] = agg.get(feat, 0) + gain
        return sorted(agg.keys(), key=lambda x: agg[x], reverse=True)[:10]

Вывод: Online-метрики рекомбинации сплитов позволяют вовремя остановить рост числа деревьев и избежать degradation в serving, но требуют учёта overhead по памяти для градиентов и ограничены по глубине деревьев (более 10 — теряют точность).

Инференс и Unity в контейнере: почему X11 стал главным узким местом Казалось бы, что сложного: в YTsaurus есть GPU, джобы пробрасывают /dev/nvidia0. Закинул бинарник, запустил, получил видео. На практике — всё сломалось на этапе инициализации. Проблема: Window System Integration Unity и Unreal Engine используют WSI. Даже для offscreen-рендеринга им нужен X11-сервер. Без него библиотеки XCB/Xlib не создадут VkSurfaceKHR — поверхность для финального кадра. Цепочка зависимостей выглядит так: 1. Vulkan ICD обращается к /dev/dri/renderD128 для аллокации буферов. 2. Движок рендерит кадр и передаёт dma-buf в X-сервер через DRI3. 3. Xorg должен быть запущен с DDX-драйвером nvidia_drv.so на том же GPU. 4. Только тогда драйвер импортирует dma-buf и выведет их на виртуальный монитор. Что нужно пробросить помимо /dev/nvidia0 Для ML достаточно трёх устройств. Для графики список шире:

/dev/nvidiactl
/dev/nvidia0
/dev/nvidia-uvm
/dev/nvidia-modeset
/dev/dri/card0
/dev/dri/renderD128

Плюс в контейнере должны быть библиотеки NVIDIA, DDX-драйвер для Xorg и nvidia-smi для дебага. Как дошли до стабильного запуска Шаг 1. Docker с --gpus all и --privileged. vkcube работает — X11 внутри контейнера поднимается. Шаг 2. Убрали --privileged. Userspace-библиотеки драйвера и DDX ставим вручную. Шаг 3. Переехали в Porto. Экспортировали Docker-контейнер в Porto-слой. Porto поддерживает вложенные контейнеры — это критично для YTsaurus. Шаг 4. «Ванильная» операция в YTsaurus. Драйверы накладываются отдельным слоем, их нельзя класть в образ. Ловили ошибки и понимали, чего не хватает. Шаг 5. Unity с 3DGS-аватарами. После стабильного vkcube перешли к реальной практической задаче. Типичные ошибки - Запускать Xorg без DDX-драйвера nvidia_drv.so. X11 падает с "no screens found". - Не прокидывать /dev/nvidia-modeset. Управление виртуальным дисплеем недоступно. - Забыть про dbus. Unity требует работающую шину для инициализации. Как починили в инфраструктуре Когда пример собрали, стало ясно: без изменений на платформе не обойтись. Передали наработки коллегам из Yandex Infrastructure. Они за несколько часов добавили поддержку Xorg для GPU-хостов, через пару недель раскатили на ML-кластера. Вывод: Графический рендеринг в контейнерах — это не только про проброс GPU. Это про X11, DRM, dma-buf и драйверы. Собери пазл один раз — и рендеринг становится обычной batch-задачей без ручных запусков.

⁣Оптимизация калибровки GBDT в production: как адаптировать вероятности через мониторинг скользящих ошибок второго типа Калибровка вероятностей моделей градиентного бустинга — это не разовая операция, а непрерывный процесс. На serving-данных распределения целевой переменной и признаков могут дрифтовать, и статичная калибровка, выполненная на валидации, теряет точность. Типичная ошибка — полагаться на среднюю log-loss или Brier score, не отслеживая динамику ошибок по классам. Почему FN rate — а не accuracy или AUC В задачах с дисбалансом классов (fraud detection, CVR, credit scoring) глобальные метрики скрывают ухудшение калибровки для редкого класса. FN rate — доля false negatives среди реальных положительных — чувствителен к дрифту, при котором модель начинает систематически недооценивать вероятность редкого события. Именно это поведение критически важно для бизнеса: пропущенный фрод или кредитный дефолт обходится дороже, чем ложное срабатывание. Как организовать мониторинг и онлайн-коррекцию Процесс выглядит так: * На этапе обучения фиксируем эталонный FN rate на валидации при пороге 0.5. * В serving каждые N инференсов (например, 10 тыс. событий) собираем буфер сырых предсказаний (raw logits) и реальных меток (с учетом лагов агрегации). * На каждом окне вычисляем текущий FN rate. * Если отклонение от эталона превышает порог δ (например, 0.05), запускаем адаптивную калибровку на буфере. Реализация Platt scaling на лету Лучший выбор — логистическая регрессия с L2-регуляризацией на буфере последних logits. Алгоритм: * Хранится FIFO-буфер buffer_preds (raw scores) и buffer_labels. * При достижении окна window_size=10000 старые элементы вытесняются. * Функция check_drift(ref_fn_rate) вычисляет FN rate в окне:

buffer_preds, buffer_labels = [], []
window_size = 10000

def update(raw_pred, true_label):
    buffer_preds.append(raw_pred)
    buffer_labels.append(true_label)
    if len(buffer_preds) > window_size:
        buffer_preds.pop(0)
        buffer_labels.pop(0)

def check_drift(ref_fn_rate):
    fn = (np.array(buffer_preds) > 0.5) & (np.array(buffer_labels) == 0)
    current_fn = fn.sum() / max((labels == 0).sum(), 1)
    if abs(current_fn - ref_fn_rate) > 0.05:
        calibrator.fit(buffer_preds, buffer_labels)

Инженерные trade-offs и предупреждения * Isotonic regression на малом окне склонна к переобучению и нестабильна — Platt scaling с регуляризацией надежнее. * Для отложенного таргета (рекомендации, конверсии) окно нужно синхронизировать по времени, а не по событиям, чтобы избежать смещения от старых меток. * Корректируйте только post-hoc калибровку, не трогая веса модели и не нарушая бэкап-совместимость. * Предупреждение: не используйте этот метод, если данные метятся с обратной связью с дрейфом меток — сначала требуется объединение по времени. Когда это особенно полезно * CVR, fraud detection, credit scoring — где дрифт паттернов частотен. * Системы с регуляторными требованиями к точности вероятностей (например, Basel или IFRS 9). * Как дешевая альтернатива ежедневному или еженедельному переобучению модели — метод позволяет жить между ретрайнингами, снижая cost на MLOps. Альтернатива: полный retrain с обновленными данными — более затратно, но гарантирует воспроизводимость. Предложенный подход — компромисс между стабильностью и адаптивностью. Вывод: Мониторинг скользящего FN rate на serving и онлайн-калибровка через Platt scaling — это низкозатратный способ держать вероятности модели GBDT честными без переписывания пайплайна, особенно при дрифте в редком классе.

Mix Hub в свой VST3-плагин: анализ конфликтов между дорожками Привет, Хабр! Меня зовут Артур Валиев. Я продолжаю делать свой VST3-плагин Mix Teacher AI. В прошлый раз я рассказывал про идею плагина: поставить его на дорожку, посмотреть уровни, пики, RMS, примерный LUFS, частотные зоны и получить простую подсказку человеческим языком. Но довольно быстро стало понятно, что анализировать только одну дорожку мало. Потому что в сведении часто проблема не в одной дорожке. Кик сам по себе нормальный. Бас сам по себе нормальный. Вокал сам по себе нормальный. Барабаны вроде тоже нормальные. А вместе всё почему-то не звучит. И вот тут начинается самая интересная часть: конфликты между дорожками. Читать далее

⁣Мониторинг дрейфа в GBDT: контрастивное обучение на эмбеддингах листьев Обычно дрейф в GBDT ловят через PSI на предсказаниях или KS-тест на фичах. Но эти методы не видят внутреннюю структуру ансамбля — сдвиг в распределении leaf-эмбеддингов часто проявляется раньше, чем упадет качество или поплывут предсказания. Типичная ошибка: доверять только output-метрикам и пропускать фундаментальные изменения в том, как модель "читает" данные. Идея: контрастивное обучение на leaf-эмбеддингах Когда объект проходит через GBDT, каждый decision tree возвращает индекс листа. Собирая бинарные индикаторы (попал/не попал) по всем деревьям, получаем разреженный эмбеддинг размерности num_trees * max_leaves. Контрастивное обучение (SimCLR или SupCon) проецирует эти векторы в dense латентное пространство. В проде средний эмбеддинг батча сравнивается с референсным — резкий рост расстояния сигнализирует о дрейфе. Пример кода:

def get_leaf_embeddings(model, X):
    leaf_idx = model.predict(X, pred_leaf=True)
    emb = ...
    return emb

def contrastive_loss(emb_pos, emb_neg, margin=1.0):
    pos_dist = torch.sum((emb_pos - emb_neg)**2, dim=1)
    loss = torch.mean(F.relu(pos_dist - margin))
    return loss

# На проде:
mean_emb = get_leaf_embeddings(model, batch_X).mean(0)
drift_score = torch.dist(mean_emb_ref, mean_emb_new)

Преимущества для production Во-первых, раннее обнаружение: leaf-структура меняется до того, как target поплывет — это дает время на reaction, например, переобучение или fallback-модель. Во-вторых, подход работает с любым GBDT (LightGBM, XGBoost, CatBoost) без доступа к таргету — достаточно признакового пространства. В-третьих, не нужна разметка: контрастивная пара формируется из аугментированных эмбеддингов того же батча, что утилизирует дрейф без ручного контроля. Инженерные trade-offs и типичная ошибка На практике возникает компромисс: latency vs sensitivity. В real-time инференсе батч из N объектов может не успеть пройти через embedder внутри decision path — требуется асинхронный пайплайн (например, ставить мониторинг на отдельном sidecar-процессе). Ошибка — использовать универсальный порог для разных моделей. Подбирать чувствительность нужно эмпирически на production-данных через validation на исторических дрифтах. Также не забывайте про data quality: если в батче 50% missing values, leaf-индексы исказятся, и эмбеддинг укажет на дрейф там, где его нет. Практический совет Для production внедрения используйте window-based мониторинг: считайте средний leaf-эмбеддинг на скользящем окне (например, 1000 объектов) и сравнивайте с эталонным, полученным на train-данных. В качестве метрики дрейфа берите cosine distance между эмбеддингами — она менее чувствительна к масштабу, чем L2. Если distance превышает 95-й перцентиль на baseline — запускайте alert. Это позволит не дожидаться, пока target упадет на 2%. Вывод: Leaf-эмбеддинги с контрастивным обучением дают интерпретируемый, быстрый и независимый от target способ детекции дрейфа в GBDT, но требуют аккуратного подбора порога и учета latency в real-time пайплайнах.