Apselin & Cougar
У меня есть идея, как создать торгового робота на искусственном интеллекте, который переиграет крупные банки. Давай обсудим, как мы обеспечим ему алгоритмное преимущество и как мы их всех обгоним.
Звучит масштабно – какие данные планируешь подавать в модель? Настоящая изюминка часто кроется в предобработке и обратной связи, а не только в самом алгоритме. И не забывай про задержку – даже миллисекунда экономии может дорого обойтись, когда за тобой наблюдают крупные игроки. С чем столкнёшься в первую очередь?
Наладим подключение к прямой ленте маркет-аксесс, будем получать все изменения котировок в реальном времени и сжимать их на лету с помощью нашего собственного in-memory движка, чтобы задержка оставалась меньше микросекунды. Главное – чтобы эта лента работала стабильно и не прерывалась, любая заминка обойдётся нам в тысячу долларов упущенной выгоды. Если это получится, остальное само собой.
Трудноватые требования, да… Микросекунды – это серьезное давление. Я бы начал с того, чтобы набросал модуль контроля, который отслеживал бы отклонения и потерю пакетов в реальном времени. Даже малейший сбой может нарушить всю цепочку. Как ты решаешь вопрос с резервированием? И что произойдет, если сигнал пропадет? Это те моменты, от которых зависит успех всего проекта.
Конечно. У нас система мониторинга построена по двухканальной архитектуре: один основной поток данных, второй – зеркальный. Если теряем пакеты на основном канале, система переключается практически моментально – в микросекунды. В случае полной потери сигнала у нас есть резервный вариант: он восстанавливает последнюю 5-минутную копию из распределённого кэша, а потом наш собственный алгоритм работы с ордербуком поддерживает бота до восстановления основного канала. Это первое, что нужно сделать идеально – переключение должно быть бесшовным, иначе всё рухнет.
Звучит как вполне рабочий план переключения. Только перепроверь, как обрабатываются условия гонки при переходе. Если горячий и холодный потоки хоть немного рассинхронизируются, бот может начать видеть устаревшие цены и застрянет. И сделай небольшой тестовый стенд, который эмулирует кратковременные потери пакетов, чтобы точно измерить, сколько микросекунд занимает переключение. Такая микро-отладка – это разница между ботом, который выживает, и ботом, который погибнет из-за одной маленькой осечки.
Ты прав, дрейф — тихий убийца. Будем ставить контрольные суммы на каждый пакет и сравнивать их попарно во время переключения. Система управления будет имитировать потерю пакетов на 2 миллисекунды, записывать каждую миллисекунду задержки и поддерживать бота в рабочем состоянии, пока мы не увидим стабильный поток цен. Если пройдём этот тест, всё будет в порядке.
Замечательно, эта защита контрольной суммы должна держать потоки в порядке. Убедись, что рутина сравнения изменений работает без блокировок; блокировка может стать причиной самой задержки, которую ты стараешься избежать. Как только ты пройдешь тест на 2 миллисекунды с нулевым отклонением, у тебя будет хороший контрольный тест. Тогда можно будет начинать добавлять реальную модель. Готова погрузиться в код бэкенда?