TRACK 02 / ODDS SYSTEMS

Odds systems: вероятность, цена и операционное состояние

Опорный материал о том, как модельная вероятность превращается в публикуемую цену, где возникает margin, зачем нужен suspend и почему version/freshness важнее красивого среднего latency.

PRIMARY SIGNALprice age / suspend / version
Технологическая инфраструктура и рабочие экраны
OPERATING QUESTION

Где заканчивается оценка вероятности и начинается публикация цены как операционное состояние?

probabilities, margin, trading state, suspend, model validation

Вероятность и публикуемая цена — разные сущности

Модель может оценивать вероятность исхода, но пользователь видит уже операционное состояние рынка. Между ними находятся правила маржи, ограничения, ручные или автоматические trading decisions, suspend и версия входных данных. Смешивание этих слоёв затрудняет и валидацию модели, и расследование инцидента.

Полезно хранить отдельно model version, input snapshot, calculated probability и published price version. Тогда при резком изменении коэффициента можно выяснить, поменялась модель, данные, margin policy или trading rule. Без такой линии происхождения любое объяснение быстро превращается в догадку.

Suspend — часть safety-модели

Когда freshness потеряна или спортивное событие находится в неоднозначном состоянии, временно остановить публикацию/подтверждение может быть правильнее, чем продолжать выдавать устаревшую цену. Поэтому suspend нельзя автоматически считать downtime. Нужны причины и контекст: planned, data-quality, manual risk decision, provider gap или иной понятный класс.

Overround не следует трактовать как одну «истинную» формулу

Нормализация коэффициентов зависит от выбранной модели. Для сравнения рынков важно фиксировать метод де-маржирования, временной срез и набор исходов. Сопоставление коэффициентов из разных моментов без контроля snapshot создаёт красивую, но методологически слабую аналитику.

Модель валидируют во времени

Backtest должен имитировать реальный исторический момент: использовать только те признаки и версии данных, которые были доступны тогда. Иначе leakage улучшает метрики, не улучшая production-качество. Помимо discrimination полезно смотреть calibration и сегменты, где вероятность систематически завышена или занижена.

Операционный контроль соединяет model и SRE

Для production нужны сигналы не только качества прогноза, но и serving: какая версия модели активна, когда обновились признаки, сколько времени прошло от нового event state до новой published price, почему рынок ушёл в suspend. Так становится видно, где закончилась модельная часть и началась проблема доставки или trading state.

Смежные досье: валидация моделей и аналитика, карта regulated betting-инфраструктуры и контракт состояния.

МАТЕРИАЛЫ

Маршрут от модели к published price

Очередь построена от контракта и состояния к диагностике, восстановлению и проверке результата.

CONTROL MATRIX

Контрольные точки odds-system

Authority

Где хранится authoritative state и как определяется версия?

Freshness

Как измеряется возраст состояния, а не только latency запроса?

Recovery

Что происходит после gap/reconnect/retry и как доказывается reconciliation?

Evidence

Какие trace/audit идентификаторы позволяют восстановить решение?

ПРАВИЛО ПРОВЕРКИ

Модельная метрика, margin и published price фиксируются как разные слои. Числа сравниваются только на совместимых snapshots и версиях.

СЛЕДУЮЩИЙ МАРШРУТ

Дальше: observability цены

Открыть индекс материалов