AI-модель анализа потока ордеров Order Flow

Order Flow анализ: где ломается картина потока

Свеча на графике показывает, где закрылась цена, но не показывает, кто её туда привёл. Поэтому Order Flow анализ часто строят на агрегированном объёме: он усредняет поток заявок и скрывает дисбаланс между лимитными и рыночными ордерами. Модель видит ровную картину там, где в реальном потоке был явный перевес одной стороны.

Основное узкое место — не алгоритм, а подготовка данных. Снимок стакана берут реже, чем приходят события, метки времени у разных источников нормализуются по-разному, а при сведении ленты теряется порядок заявок. После агрегации восстановить, кто стоял в очереди первым и снимал ликвидность, уже нельзя.

Качество сигналов падает незаметно: дельта объёма растёт, формально подтверждая спрос, хотя перевес создан снятием крупных лимитных заявок. На ликвидных площадках, например при разборе данных CME Group, один и тот же интервал даёт разную картину — усреднение по снимкам или последовательность отдельных заявок с сохранённой очередностью.

В итоге решения о входе, размере позиции и остановке принимаются вслепую по метрике, которая не описывает поток заявок. Дальше разбираем, как это закрывается: восстановление порядка событий, признаки потока заявок и проверка сигналов на исторических данных.

Что меняется после внедрения модели потока ордеров

Точность модели растёт не за счёт более сложной архитектуры, а за счёт смены предмета анализа. Вместо цены и её производных модель читает поведение участников: перекос между агрессивными и лимитными заявками, скорость набора объёма, снятие крупных заявок до исполнения. Сигнал формируется до движения цены, а не подтверждает его постфактум.

Практический эффект виден на доле ложных срабатываний. Раньше всплеск объёма давал сигнал и на технических выбросах: тонкий стакан, единичная заявка, которая снимается через мгновение. Теперь такие ситуации отсекаются фильтром по устойчивости потока — чувствительность к реальным аномалиям при этом сохраняется.

Время реакции меняется радикально. Ручное наблюдение за потоком не успевает за темпом поступления заявок: аналитик видит аномалию, когда она уже отработана. События попадают в Apache Kafka и обрабатываются по мере поступления, поэтому сигнал приходит одновременно с аномалией, а не после неё.

Отдельно уходит целый класс отказов — реакция на вымышленный объём. Учитываются отменяемость заявок, их агрессивность и распределение исполнения по уровням: вместо правила «объём вырос → сигнал» решение опирается на несколько независимых признаков. Каждое срабатывание пишется в журнал вместе с признаками и фактическим исходом, поэтому точность и доля ошибок измеряются на истории, а не оцениваются на глаз.

Режимы расчета потока заявок: сравнение подходов

Режим расчета задаёт, что именно модель видит в потоке заявок: намерение участников рынка или уже сложившуюся картину книги. От этого зависят задержка реакции, устойчивость к разрывам соединения и объём данных, который нужно хранить для повторных прогонов и обучения.

На практике выбор сводится к трём вариантам: поток событий, периодический срез стакана и гибридная схема. Ниже — их ограничения без рекламных упрощений.

Обычно срез стакана берём как базовый режим расчета, поток заявок — там, где без микроструктуры теряется смысл сигнала, гибридную схему — когда нужны оба и есть чем покрыть нагрузку на синхронизацию. Формат данных и разметку фиксируем до старта, чтобы при смене источника модель не пришлось переучивать с нуля.

Как проходит внедрение модели анализа потока

Порядок работ выстроен так, чтобы модель встретилась с реальным рынком только после того, как мы поймём качество данных и поведение сигнала на истории. Ниже — этапы, которые внедрение Order Flow анализа проходит от первого разбора до передачи в эксплуатацию.

Порядок работ

1. Аудит данных. Проверяем глубину истории стакана, наличие сделок и меток времени, расхождения между источниками, пропуски в записи. Отдельно сверяем синхронизацию часов: рассинхрон смешивает причину и следствие в потоке ордеров и обесценивает обучение.

2. Схема интеграции. Фиксируем, откуда идёт поток — шлюз брокера, биржевой интерфейс или архив — и как он приводится к единому событию: время, инструмент, сторона, цена, объём. Здесь же описываем буферизацию и поведение системы при разрыве канала.

3. Признаки и горизонт. Из потока собираются дисбаланс сторон, интенсивность и размер агрессивных заявок, поведение крупных участников. Горизонт прогноза и порог срабатывания задаём из задачи, а не по умолчанию.

4. Тестовый контур. Прогон на исторических сессиях в режиме воспроизведения, затем на живом потоке без выдачи сигналов. Считаем долю ложных срабатываний, устойчивость на разных режимах рынка и задержку от события до сигнала.

5. Регламент внедрения. Вывод сигналов с ограничением доли капитала, журнал решений, мониторинг расхождения между прогнозом и фактом. План отката к предыдущей версии модели описан заранее.

6. Передача в эксплуатацию. Отдаём конфигурации, схему потока, инструкции по переобучению и пороги, при которых модель останавливается. Дальше — сопровождение и контроль дрейфа.

Артефакты проекта: схемы, правила, регламенты

Проект сдан не тогда, когда модель выдала первые сигналы на живом потоке, а тогда, когда ваша команда может менять её без нас. Поэтому вместе с работающим сервисом передаём комплект артефактов — по каждому можно провести приёмку и дальше сопровождать решение своими силами.

• Документация модели — какие признаки потока ордеров участвуют в расчёте, с каким окном агрегации, какие пороги срабатывания и как отличать всплеск объёма от разворота.
• Схемы потоков данных — путь от источника до витрины: где нормализация и дедупликация, на каком участке накапливается задержка, какие поля обязательны.
• Правила доступа — роли по подразделениям: кто видит сырой поток, кто только агрегаты, как журналируются запросы к модели.
• Регламент сопровождения — периодичность проверки метрик, действия при дрейфе модели, порядок переобучения и откат на предыдущую версию.
• Описание контуров и приёмки — тестовый стенд на исторических данных, чек-лист проверок перед выкаткой, критерии допустимой деградации.
• Инструкция по инцидентам — что смотреть при пропаже потока, кому эскалировать, за какое время реакция считается нормальной.
• Журнал решений — почему выбран такой горизонт сигнала и от каких вариантов калибровки отказались; через месяцы это экономит дни на разборе.

Комплект остаётся у вас и обновляется по мере изменений в контуре. Опишите задачу — вернёмся с оценкой и планом.

Кейс: ложные сигналы модели и что мы изменили

Что было

Модель обучалась на агрегированных минутных свечах: признаки считались по факту закрытия бара, и всплеск ликвидности она видела уже после движения цены. На спокойном рынке точность держалась около 58%, а в окне выхода макростатистики доля ложных сигналов доходила до 41% — почти каждая вторая сделка закрывалась по защитному ордеру.

Что изменили

Пересобрали набор признаков на сырых данных потока заявок: дисбаланс объёма на ближних уровнях стакана, скорость поглощения лимитных заявок, поведение крупных участников. Исторические срезы стакана брали из Databento, разметку делали по фактическому исполнению, а не по свечам.

Добавили фильтр волатильности, который отключает сигналы в узком окне вокруг новостей, и калибровку порога вероятности. Обучающую выборку сбалансировали по режимам рынка, чтобы модель не переоценивала спокойные периоды.

Что стало

Точность на вневыборочном интервале выросла с 58% до 76%, доля ложных сигналов упала с 41% до 13%. Средний срок удержания позиции сократился почти вдвое — выход стал раньше и по факту, а не по расписанию. Число дней с отрицательным результатом уменьшилось примерно на треть.

Метрики — на исторических данных, прошедших проверку на скользящем окне; на живом рынке результат зависит от режима и ликвидности инструмента. Правила пересмотра модели фиксируем заранее, чтобы деградация ловилась до того, как проявится в результатах.

Анализ потока заявок против объема сделок: в чем разница

Разница здесь в природе данных, и путать эти источники в одной модели дороже всего. Объем сделок — регистрация факта: сделка исполнена, рынок уже отреагировал. Поток заявок — регистрация намерения: заявка выставлена, изменена или снята, а сделки по ней может не быть вовсе.

Срез стакана — моментальная фотография книги заявок: что стоит по каждой цене прямо сейчас. Поток заявок — событийный журнал во времени: кто и как эту книгу менял. Модель на срезах видит состояние, но не видит, за счет чего оно сложилось, и потому не отличает плотность, которую держат осознанно, от плотности, которая исчезнет через мгновение.

Для прогноза это принципиально. Опережающий сигнал — дисбаланс между скоростью выставления и снятия ликвидности на стороне покупки и продажи. По исполненным сделкам он проявляется с задержкой: пока объем накопился, цена уже прошла большую часть движения. Поток заявок дает более ранний горизонт, объем сделок — подтверждение, что давление реально, а не осталось намерением.

На практике источники не конкурируют: поток заявок работает как опережающий признак, объем сделок — как фильтр ложных срабатываний. Разница есть и в требованиях к данным: поток заявок в разы объемнее, чувствителен к точности меток времени и пропускам событий, лента сделок короче и устойчивее к разрывам. Поэтому мы сводим оба ряда в общую временную шкалу и проверяем на исторических данных, какой из них дает прирост точности именно на вашем горизонте прогноза.

Технические сомнения перед стартом проекта

На старте проекта по анализу потока ордеров чаще всего всплывают три инженерных сомнения: задержка данных, качество истории и переобучение модели. Разбираем, как мы закрываем каждое из них в контуре заказчика.

Насколько полной должна быть историческая лента?

Реальная история почти всегда идёт с разрывами, дублями и разной глубиной стакана по инструментам. Восстанавливаем стакан по инкрементальным обновлениям, сверяем с независимым источником и помечаем интервалы, где данные неполные. Обучение идёт только на участках с подтверждённым качеством: на выходе получаете набор данных с метками достоверности, а не «как получилось».

Как убедиться, что модель не переобучена?

Проверяем на скользящем окне: обучение на одном периоде, проверка на следующем, который модель не видела, и повтор на разных режимах рынка — тренд, боковик, высокая волатильность. Смотрим не только долю верных сигналов, но и устойчивость признаков между периодами. Если результат держится на одном участке истории — переделываем модель, а не подгоняем порог срабатывания.

Обсудим задачу и вернемся с оценкой и планом

Чтобы оценка проекта опиралась на данные, а не на общие соображения, к разговору достаточно принести то, что уже есть в работе. Готовое техническое задание не нужно — обсудим задачу в том виде, в котором она стоит сейчас.

• Историю потока ордеров: снимки стакана и ленту сделок за период, который захватывает и спокойный рынок, и резкие движения. На таком наборе видно, отличается ли давление покупателя от обычного шума.
• Текущую логику решений: по каким правилам сейчас читается дисбаланс, где выставлены пороги, что в вашей практике считается ложным срабатыванием.
• Целевые метрики: какую долю ложных сигналов готовы терпеть, насколько критична задержка между событием в стакане и выдачей сигнала.
• Ограничения контура: где будет считаться модель, есть ли ускорители, как сигнал попадает в торговую систему и кто его подтверждает.
• Формат выдачи: нужна ли числовая оценка вероятности, метка на графике или готовое событие в вашей инфраструктуре.

Дальше мы разбираем выгрузку и проверяем, воспроизводится ли в ней сама гипотеза сигнала. Затем возвращаемся с оценкой и планом внедрения: этапы, точки контроля, требования к данным и к тому, где считается модель. Если данных для проверки гипотезы не хватает, скажем об этом до старта, а не в середине работы.

Опишите задачу в свободной форме — где сигнал должен срабатывать и что мешает сейчас. Этого достаточно, чтобы вернуться с оценкой и планом.