Train ↔ Serve Consistency Audit Report — SoccerPredictAI¶

Date: 2026-04-24 Auditor: GitHub Copilot (Claude Sonnet 4.6) Scope: Расхождения feature pipeline между training, batch inference и online serving Method: анализ src/features/, src/pipelines/features.py, src/pipelines/inference.py, src/app/services/predict.py, src/app/tasks/predict.py, src/app/routers/predict.py

1. Feature Set Consistency¶

1.1 Инвентаризация feature set по точкам¶

Feature columns¶

Training (final_train):
  select_model_features(features_meta, side='diff', window_sizes=[1,3], include_elo=True)
  → diff_*_mean_w1, diff_*_mean_w3 (all/season/tournament/ha × 5 stats × 2 windows = 40)
  + diff_elo_pre (ELO)
  + coverage_w1, coverage_w3 per group × 4 = 8 coverage
  + sex (categorical)

Batch inference (compute_all_match_features):
  Те же: select_model_features(features_meta, side='diff', window_sizes=[1,3], ...)
  → идентичный набор

Online serving (POST /predict/):
  КЛИЕНТ предоставляет dict — нет server-side enforcement

Совпадение training ↔ batch_inference¶

✅ Полностью совпадает. Обе точки используют одни и те же: - функции: build_team_match_table, add_rolling_features, to_match_level, compute_elo_ratings - параметры: из одного params.yaml - feature selector: select_model_features() с одинаковыми аргументами

Training ↔ online serving¶

⚠️ НЕТ SERVER-SIDE FEATURE COMPUTATION. Online POST /predict/ принимает уже готовые фичи от клиента. Это архитектурно задуманная конфигурация (задокументировано в PredictRequest docstring), но создаёт риск:

• Клиент может прислать неправильные фичи (неправильные window sizes, неправильные stats, устаревшие ELO)
• Нет schema validation кроме типов (dict of float/int/None)
• Нет feature completeness check

2. Preprocessing Logic¶

2.1 Feature engineering: Training vs Batch inference¶

2.2 Feature engineering: Training vs Batch inference (критическое различие)¶

⚠️ P1 — Исторический контекст в batch inference:

В feature_engineering (training): фичи для матча m используют только finished матчи до m.

В batch_inference (compute_all_match_features): фичи для future матча m используют все finished + все future матчи в объединённой таблице, отсортированной хронологически. Future матчи имеют zeroed outcome columns (_prepare_future_rows), но их startTimeUtc позиционирует их ПОСЛЕ finished матчей. shift(1) гарантирует что будущий матч не видит свой собственный результат (которого нет).

✅ Нет leakage. Но есть subtle asymmetry:

• При training: rolling stats для финального матча в training set вычисляются на основании предшествующих finished матчей
• При batch inference: rolling stats для future матча используют те же финальные finished матчи плюс любые more recent finished матчи, которые были добавлены после feature_engineering

→ batch_inference фичи fresher чем training фичи (используют более актуальный history). Это корректное поведение, но означает небольшой train/serve skew в coverage.

3. Encoding & Scaling¶

✅ Все preprocessing включён в serialized sklearn Pipeline и загружается через MLflow pyfunc. Нет риска training/serving skew для encoding/scaling.

4. Порядок признаков¶

# select_model_features() возвращает features_meta["name"].tolist()
# Порядок определён порядком строк в features_meta.parquet

5. Model Loading в Serving¶

# PredictionService.predict():
model = mlflow.pyfunc.load_model(f"models:/soccer_clf@champion")
result = model.predict(pd.DataFrame([features]))

• MLflow pyfunc оборачивает sklearn Pipeline → preprocessing применяется автоматически ✅
• Нет ручного preprocessing при serving ✅
• Модель загружается по alias @champion — всегда актуальная registered версия ✅

6. Staleness Risk¶

7. Findings¶