BHFT: Техническое собеседование

В fashion важны визуальная похожесть, размер/пол/стиль, сезонность, availability и cold-start; pure co-click similarity часто ловит popularity bias.

Item-to-item в одежде нельзя сводить только к "что часто покупают вместе". Нужно разделять заменители и complements, учитывать размеры, gender/fit, бренд, цвет, стиль, цену, сезонность и наличие на складе.

Классические риски: popularity bias, устаревшие товары, нехватка истории для новых SKU, leakage из будущих заказов, плохая персонализация и отсутствие diversity. Хорошая схема часто смешивает collaborative signals, content/image embeddings и business constraints, а offline метрики дополняет online CTR/conversion и user satisfaction.

Первое - leakage, random split, неверный prediction horizon, признаки из будущего и train/test режим, который не имитирует реальный момент решения.

Для временных рядов offline должен имитировать будущее: train на прошлом, validation на будущем. Нужно проверить rolling features, normalization, joins, target shift и любые признаки, которые используют данные после момента решения.

Хороший random split почти ничего не доказывает: соседние точки временного ряда похожи, окна могут пересекаться, а scaler или агрегаты могли быть fit на full dataset. Отдельно проверяют drift, costs/latency и gap между моментом наблюдения признаков и моментом предсказания.

Confidence можно брать из calibrated probability, uncertainty estimate или empirical reliability по бинам score; score модели сам по себе не всегда является уверенностью.

Важно отделить score модели от настоящей уверенности. Для классификации проверяют calibration curve, Brier/log loss, reliability bins и expected calibration error. Для регрессии можно строить prediction intervals, quantile models или ансамбли.

В trading confidence обычно связывают с threshold и размером позиции, но это нужно проверять out-of-time: бины с большим confidence должны иметь лучший realized outcome. Иначе модель может быть уверена только на train distribution.

Нужно сначала зафиксировать target и горизонт прогноза, затем строить признаки только из прошлого, валидироваться по времени и отдельно проверять leakage, latency и устойчивость на новых периодах.

Для HFT/time-series задачи нельзя начинать с модели. Сначала нужно понять, что именно предсказываем: направление цены, доходность, вероятность движения, spread или другой target. Потом фиксируем горизонт прогноза и момент времени, в который модель должна принять решение.

Дальше признаки: лаги цены/объема, rolling statistics, imbalance, spread, volatility, агрегаты по окнам и признаки микроструктуры рынка. Все они должны считаться только из информации, доступной до момента предсказания.

Валидация должна быть временной: train на прошлом, validation на будущем, без random split. Для финансовых рядов особенно важно проверить leakage через нормализацию, rolling features, future joins и неявное использование будущих строк.

Baseline: простой rule-based или линейная модель/GBDT на лаговых признаках. Только после него имеет смысл обсуждать sequence-модели, если есть достаточно данных и понятная latency/cost граница.

Из стакана берут bid/ask, spread, mid-price, depth/imbalance; из trades - signed volume, intensity, VWAP и агрегации по коротким окнам.

Order book дает состояние ликвидности: best bid/ask, mid-price, spread, объемы на уровнях, imbalance между bid/ask, slope/depth и изменения этих величин. Trades дают фактическую агрессию рынка: price, size, side/sign, trade count, volume, VWAP и burst intensity.

Так как события нерегулярные, признаки часто выравнивают на регулярную временную сетку: forward-fill для состояния стакана, rolling aggregations для сделок и lag features. Критично фиксировать момент доступности каждого признака, иначе легко заглянуть в будущее.

Нужно зафиксировать decision time, horizon и форму target: future return, direction, thresholded move или no-trade/up/down с учетом spread и costs.

Target должен соответствовать действию модели. Например, можно предсказывать relative change mid-price через 100 ms или 1 s, знак движения после учета spread/cost, или вероятность движения выше threshold.

Нельзя строить target так, чтобы признаки случайно видели будущее окно. Для шумных HFT-данных часто вводят no-trade class или threshold, чтобы не заставлять модель предсказывать микрошум, который не покрывает транзакционные издержки.

Сетка задает decision timestamps; state features forward-fill-ятся из последнего стакана, trades агрегируются только из прошлого окна.

Сначала выбирается регулярная сетка timestamp-ов, например каждые 100 ms. Для order book state на каждую точку берется последний известный snapshot не позже timestamp: best bid/ask, mid, spread, imbalance и depth. Для trades считаются rolling или bucket aggregations за прошлые окна: count, volume, signed volume, VWAP, max/min price.

Нельзя использовать события после decision timestamp. Target должен быть смещен в будущее, например future mid-price return через заданный horizon. Для train/test split нужен temporal split с gap, иначе rolling windows и forward-fill могут протащить leakage между выборками.

CatBoost ловит нелинейности и interactions, но его нужно сравнить с naive, linear/ridge и простыми rules на temporal validation.

Сильный ответ не продает CatBoost как магию. Сначала baseline: константа, last value, линейная модель на лагах и простые rules. Потом GBDT, если есть нелинейные зависимости, разные масштабы признаков и interactions.

Улучшение должно быть на temporal validation, без leakage. Для HFT/time-series также важно проверить стабильность по периодам, sensitivity к drift и связь offline metric с trading proxy или PnL after costs.

MSE имеет смысл только относительно baseline, масштаба target, variance и бизнес-метрики; маленький MSE не гарантирует полезный trading signal.

Нужно сравнить MSE с константным прогнозом, last value, линейной моделью и variance target. Без baseline число MSE почти невозможно интерпретировать.

Для trading маленький MSE не гарантирует прибыль: важны направление, ranking, threshold, calibration и proxy-PnL после costs. Также стоит смотреть стабильность по периодам и slice metrics, потому что средняя ошибка может скрывать деградацию на волатильных режимах.

Проверяем, что все признаки считаются только из прошлого, split идет по времени, а между train/test есть gap при пересекающихся окнах.

Типовые ошибки: rolling по всему датасету, scaler fit на full data, target-window пересекается с feature-window, random split, join будущих данных и использование признаков, которые в production станут доступны позже.

Gap нужен, если target или rolling features используют соседние интервалы и иначе train косвенно видит test. Хорошее ревью также проверяет reproducibility, backtest slices, feature freshness и связь offline score с proxy business или trading metric.

Для последовательностей можно предложить TCN/LSTM/Transformer, но выбор зависит от длины истории, latency, объема данных и требований к интерпретируемости. Часто стартуют с агрегированных временных признаков и легкой sequence-модели.

Ответ должен идти от данных. Если есть временной ряд или последовательность событий, можно использовать LSTM/GRU, TCN или Transformer. Для длинных зависимостей и большого объема данных Transformer гибче, но дороже. Для latency-sensitive задач часто разумнее TCN или компактная recurrent модель.

Нужно объяснить вход: сырые события, агрегированные окна, признаки стакана/каталога/пользователя, временные embeddings, маски, normalization. Если данные очень частые, их обычно агрегируют до разумного resolution, иначе модель будет дорогой и шумной.

Сравнение с GBDT важно: deep learning имеет смысл при больших данных, сложных последовательных паттернах и достаточной инфраструктуре. Иначе бустинг на аккуратных rolling features может быть сильнее и проще в production.