⁣Distributed SHAP-агрегация для real-time интерпретации предсказаний GBDT в сервинге с гарантированной консистентностью

Когда GBDT-модель висит под 100k RPS в продакшене, интерпретация каждого предсказания — не опция, а необходимость. Особенно если регулятор или compliance просят объяснить, почему клик засчитали именно этому юзеру. Но стандартный SHAP для GBDT — это O(T * 2^max_depth). Для глубины дерева 10 — 1024 комбинации на одно дерево. В real-time это не взлетит.

Я часто вижу, как команды кладут SHAP-векторы в Kafka, а потом Spark их аггрегирует. И тут начинается классическая проблема: временные метки расходятся, значения теряются, и вместо объяснения получается каша. Особенно когда на разных worker-ах модель чуть по-разному обновляется.

Архитектура агрегации

Мы пошли другим путём. Каждый worker считает локальный SHAP через TreeSHAP (сложность O(T * D²), для глубоких деревьев всё ещё дорого, но терпимо, если резать глубину). Для real-time используем приближение: берём глобальный baseline (среднее предсказание по train), и worker отправляет в Redis Cluster не весь вектор, а агрегат: feature_name → (sum_shap, count, глобальный timestamp).

Проблема консистентности

Главная проблема — консистентность. Если два worker-а видят модель в разном состоянии, их SHAP-ы несопоставимы. Тут в игру входят Hybrid Logical Clocks (HLC). Они дают causal consistency: мы знаем, какое событие произошло раньше, и можем детерминированно смержить данные без конфликтов. Никаких векторных часов вручную — HLC встроен в Redis Cluster через CRDT.

Детали агрегатора

На стороне Reducer (у нас Flink) мы считаем: avg_shap[i] = sum_shap[i] / count[i], но только если временные метки всех worker-ов для этого фичи сходятся в пределах окна. Если расходятся — дропаем точку. Вот пример кода агрегатора:

// Псевдокод агрегации в Flink
select feature_name,
       sum(shap_value) / count(*) as avg_shap,
       max(timestamp) as ts
from shap_stream
group by feature_name, tumble(ts, interval '1' minute)
having count(distinct worker_id) = expected_worker_count;

Типичная ошибка: не проверять количество worker-ов в окне. Без этого вы мержите SHAP-ы от разных версий модели, и интерпретация становится бессмысленной.

Production-oriented результаты

Что получилось на практике. При 50k RPS задержка интерпретации — меньше 50 мс. Глобальная важность фич обновляется в реальном времени, без переобучения модели. Потеря в точности SHAP — около 0.05 единиц при 95% аппроксимации. Для прода это нормально. Регулятору плевать на сотые доли, ему важно — почему.

Главный trade-off, как всегда: точность против latency. Если вам нужны доли процента — готовьтесь к latency в секунды. Но для fraud detection или credit scoring 50 мс — это разница между блокировкой мошеннического перевода и его пропуском.

Код аггрегатора — простой, как грабли. Redis Streams, пара ключей, HLC в payload. Ничего сложного. Сложность в том, чтобы не сломать консистентность, когда модель обновляется на лету.

Вывод: В production ML для real-time интерпретации GBDT используйте распределённую SHAP-агрегацию с HLC и окном по timestamp, чтобы гарантировать causal consistency без потери в точности, приемлемой для регулятора.