⁣Когда GBDT молча убивает качество: детекция дрейфа на уровне дерева

Ловили такое: модель на продакшене внезапно начинает выдавать аномалии, а метрики ещё зелёные? Концептуальный дрейф в GBDT подкрадывается незаметно. Распределения признаков сдвигаются, и те самые "умные" границы разбиения становятся источником ошибок. Классический мониторинг F1 или AUC срабатывает как CHECK ENGINE — когда уже всё горит. Но есть способ для тех, кто копает глубже: смотреть статистики разбиения деревьев прямо в serving-пайплайне.

Идея: дрейф на уровне узлов дерева
GBDT принимает решения через цепочку бинарных разбиений (split point). Каждое дерево фиксирует конкретные границы на обучении. В онлайне мы считаем:
- сдвиг среднего значения в каждом узле относительно обучения;
- изменение дисперсии выборки, которая попадает в узел;
- резкое падение количества наблюдений на листьях (volume drop).

Реализация в serving-пайплайне
Добавляем в serving-пайплайн сбор статистик по каждому дереву (среднее, std, объём выборки). На каждом батче считаем агрегаты и сравниваем с эталоном через Hellinger distance или CUSUM. Находим "больные" деревья — те, где дрейф превышает порог.

def detect_tree_drift(model, X_online, threshold=3):
    leaf_indices = model.predict(X_online, pred_leaf=True)
    drift_scores = []
    for tree_id in range(leaf_indices.shape[1]):
        freq = np.bincount(leaf_indices[:, tree_id], minlength=model.num_leaves())
        train_freq = model._Booster.dump_model()['tree_info'][tree_id]['leaf_freq']
        h = np.sqrt(np.sum((np.sqrt(freq/sum(freq)) - np.sqrt(train_freq))**2))
        drift_scores.append(h)
    bad_trees = np.where(np.array(drift_scores) > threshold)[0]
    return bad_trees

Когда это критично
- высокочастотная торговля или рекомендации, где концепт меняется за минуты;
- модели с Time2Vec или категориальными фичами, подверженными дрейфу;
- low-latency пайплайны, где переобучение каждые 5 минут дорого. Типичная ошибка — ждать падения метрик качества вместо мониторинга внутреннего состояния дерева.

Практический совет и trade-offs
Лайфхак: если процент плохих деревьев перевалил за 30% — пора бить тревогу. Но не обязательно переучивать всю модель: можно просто снизить веса "больных" деревьев или отключить их. Это даёт выигрыш в latency и cost по сравнению с полным ретренингом. Однако учитывайте, что отключение дерева может изменить композицию ансамбля и снизить interpretability — балансируйте между качеством и надёжностью.

Вывод: Детекция дрейфа на уровне разбиений деревьев даёт раннее предупреждение за 5-10 батчей до падения метрик, позволяя реагировать точечно, а не глобально.