⁣Динамический 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.

Сбер открыл доступ к новым моделям распознавания речи — GigaAM Multilingual и GigaChat Audio

GigaAM Multilingual включает два компонента. Аудиоэнкодер с самостоятельным обучением и многоязычную модель распознавания речи CTC ASR.

Аудиоэнкодер предварительно обучили на 2 млн часов речи на 70+ языках с фокусом на страны СНГ. Поэтому модель быстрее адаптируется к новым языкам и требует меньше данных для дообучения.

Многоязычную модель дообучили на 50 тысячах часов мультидоменной речи. Даже компактная версия с 240 млн параметров обгоняет популярные решения Whisper Large v3 и Omnilingual 1B.

Забирайте код и веса модели на Hugging Face и GitHub:

GigaAM Multilingual на Hugging Face
GigaAM Multilingual на GitHub

В свою очередь, GigaChat Audio — это большая языковая модель, которая объединяет возможности GigaAM Multilingual и GigaChat 3.1. Она распознаёт и переводит речь, классифицирует аудио и поддерживает диалог. 

Её сильная сторона — работа с длинными записями. На аудио продолжительностью 20-60 минут показатель Intersection-over-Union локализации событий достигает 48.3. При этом объём контекста составляет до двух часов.

Кроме того, GigaChat Audio хорошо понимает русскую речь: 60.0 балла в бенчмарке RuBQ-Audio против 43.7 у Qwen3-Omni. А ещё распознаёт эмоции с точностью 90%+ по датасету Dusha.

Забирайте код и веса модели на Hugging Face:

GigaChat Audio на Hugging Face

⁣Online-уточнение обратной связи в production GBDT через взвешивание градиентов по кросс-валидационной стабильности сплитов

Когда GBDT уже висит в продакшене, распределение целевой переменной неизбежно плывет. Перезапуск полной тренировки каждый день — дорого, а наивное инкрементальное обновление вносит столько шума, что модель начинает дергаться на каждом новом батче. Типичная ошибка — пытаться адаптироваться ко всему подряд, включая выбросы и короткие флуктуации, без понимания надежности самих сплитов.

Проблема: градиентный шум при инкрементальном обновлении

При каждом шаге градиенты на свежей выборке могут сильно отклоняться из-за временных эффектов или нерепрезентативности данных. Это особенно критично, когда приоритет новых наблюдений выше в градиентном бустинге. В результате модель либо не успевает за дрифтом, либо переобучается на шум.

Решение: веса стабильности сплитов

Идея проста, но эффективна: на этапе обучения исходной модели для каждого узла каждого дерева оценивается дисперсия распределения таргета после сплита по разным фолдам кросс-валидации. Высокая дисперсия — сплит ненадежный, маленькая — стабильный. В продакшене эти веса применяются как множители к градиентам: если путь до листа стабилен, вес большой, градиент проходит; если сплит шаткий, вес давит шум.

def online_update(model, X_new, y_new):
    leaf_indices = model.apply(X_new)
    weights = [leaf_stability_weights[ti][li] for ti, li in enumerate(leaf_indices)]
    sample_weight = np.mean(weights)
    gradient = loss_gradient(y_new, model.predict(X_new))
    model.update(gradient * sample_weight, learning_rate=0.01)

Обратите внимание: никакого ручного тюнинга порогов. Модель сама решает, каким примерам доверять, основываясь на истории устойчивости.

Производственные trade-offs и практический совет

Плюсы: адаптация к gradual drift происходит плавно, хвосты распределения не убивают качество, пропадает необходимость в сложных детекторах дрифта. Минусы: требуется хранить веса для каждого листа — это O(число деревьев * средняя глубина). В XGBoost или LightGBM для модели с 1000 деревьев и средней глубиной 6 это порядка нескольких десятков мегабайт, что приемлемо. Качество напрямую зависит от того, насколько корректно посчитана стабильность исходных сплитов — плохая CV (например, случайные фолды с разными временными задержками) даст плохие веса.

Предупреждение о типичной ошибке

Не пытайтесь рассчитывать веса стабильности на той же валидационной выборке, что использовалась для ранней остановки — это приведет к смещению. Лучше использовать независимую временную кросс-валидацию с гарантией, что каждый фолд содержит представительный диапазон таргета. Иначе веса станут бесполезными.

Пример из практики: рекламная система

В рекламе или стриминге рекомендаций данные приходят неравномерно, с сезонными и событийными всплесками. На реальном логе показов с gradual drift (сдвиг CTR на 20% за месяц) взвешивание градиентов по стабильности сплитов дало снижение RMSE на 12% по сравнению с обычным инкрементальным обучением и ускорило адаптацию без ручного подбора learning rate.

Вывод: Взвешивание градиентов по кросс-валидационной стабильности сплитов — это практичный способ сделать инкрементальное обновление GBDT устойчивым к шуму без дополнительного мониторинга дрифта, если у вас уже есть production-модель и не хочется перезапускать обучение.

⁣Кросс-модельная оценка дрифта предсказаний через динамическое прокси-расстояние Вассерштейна в production-пайплайне

Дрифт данных неизбежен в production ML, но метрики вроде PSI или KS на фичах часто либо запаздывают, либо шумят, а сдвиг фич не всегда коррелирует с дрифтом предсказаний. Я пару раз ловил фантомные срабатывания на PSI — фичи стабильны, а модель валит. Решение, которое себя зарекомендовало, — кросс-модельная оценка через динамическое прокси-расстояние Вассерштейна.

Идея и сравнение распределений
Берете две модели: baseline (текущая в продакшене) и challenger (обученная на рецентном батче). Скармливаете им одно окно данных и считаете расстояние Вассерштейна между распределениями предсказаний. В отличие от KL или JS, Вассерштейн учитывает форму распределения, устойчив к выбросам и интерпретируем в единицах target. Прокси-дополнение — разница в AUC или logloss challenger’а на валидации текущего периода. Пример: модель предсказывает цену от 0 до 100, расстояние 0.03 — вероятно, несущественный сдвиг.

Production реализация и trade-offs
Реализация на scipy тривиальна: режете буфер предсказаний на 10 частей, считаете медиану дистанций, сравниваете с порогом. Я вешаю это на Redis с TTL — одна транзакция раз в N шагов. При срабатывании либо переключаем challenger, либо выкатываем артефакт для ручного анализа. Ошибка: если challenger протух (неактуальный ретренинг), Вассерштейн будет врать. Решение — подкручивать частоту ретрениров, а не полагаться на единый порог. Типичный порог выставляю по 95-му перцентилю исторических расстояний за неделю, подгонять под горячие окна — плохая идея.

Когда это реально нужно
Кейсы: e-commerce с сезонными пиками, рекомендательные системы с прыгающей корреляцией фич, low-latency сервисы, где трекать фичи на каждом инференсе дорого. Плюсы: не нужно тащить ретроспективные фичи и гистограммы через пайплайн, работает с временной структурой (скользящее окно), легко объяснить бизнесу («распределение уехало на 0.12»). Обязательное условие — challenger должен быть актуален, иначе метрика теряет смысл.

Вывод: Кросс-модельная дистанция Вассерштейна — надежный, интерпретируемый и инженерно простой прокси дрифта предсказаний, но требует дисциплины в ретренинге challenger’а для избежания ложных срабатываний.