Умеют ли LLM генерировать исполняемые алгоритмические торговые стратегии

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

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

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

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

Для исследования этих вопросов мы разработали QuantCode-Bench — бенчмарк для оценки способности больших языковых моделей генерировать исполняемые алгоритмические торговые стратегии по текстовым спецификациям. В нём оценивается не только техническая корректность кода, но и вся последовательность преобразования торговой идеи в наблюдаемое поведение стратегии.

Код, датасет и скрипты запуска опубликованы в репозитории QuantCode-Bench. Результаты моделей также доступны на публичной странице бенчмарка.

Что именно измеряет QuantCode-Bench

Задача модели формулируется просто: по англоязычному описанию торговой идеи необходимо сгенерировать стратегию для Backtrader.

Но успех определяется не одним тестом, а последовательностью вложенных требований.

Стратегия должна:

• быть синтаксически корректной;
• успешно исполниться в среде бэктеста;
• совершить хотя бы одну сделку;
• соответствовать исходной торговой идее.

Каждый следующий этап усиливает предыдущий.

Синтаксически корректный код может завершиться runtime-ошибкой. Исполняемая стратегия может не сгенерировать ни одного сигнала. Торгующая стратегия может реализовывать не ту логику, которая была указана пользователем.

Поэтому основной метрикой бенчмарка является Judge Pass — доля задач, в которых решение прошло весь пайплайн, включая финальную семантическую проверку.

Почему обычных кодовых метрик недостаточно

В классическом text-to-code бенчмарке прохождение тестов обычно означает, что программа реализовала требуемое преобразование. В алгоритмической торговле между текстовым заданием и наблюдаемым поведением кода появляется несколько дополнительных слоёв.

Неформальное описание нужно превратить в строгие правила

Торговая идея может быть сформулирована как точный набор условий:

Открывать long, когда RSI(14) опускается ниже 30, и закрывать позицию, когда RSI поднимается выше 70.

Но реальное описание нередко выглядит иначе:

Покупать откат в растущем тренде, если импульс сохраняется, а цена возвращается к быстрой EMA.

Во втором случае модель должна самостоятельно решить, как определить тренд, какой индикатор использовать для импульса, что считать откатом и какое событие считать подтверждением входа.

То есть задача включает не только генерацию кода, но и операционализацию естественно-языкового описания.

Нужно знать семантику конкретного API

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

Характерный пример — использование объекта Line как обычного логического значения:

В зависимости от контекста корректная работа требует обращения к текущему значению линии через индекс:

Модель также может смешивать параметры и интерфейсы Backtrader, pandas-ta, TA-Lib и других библиотек.

Условия должны срабатывать на данных

Даже полностью исполняемый код может не совершить ни одной сделки. Причины бывают разными:

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

Поэтому наличие хотя бы одной сделки — отдельный этап оценки.

Торгующая стратегия может не решать исходную задачу

Предположим, пользователь запросил стратегию на основе RSI и уровней перекупленности и перепроданности. Модель вместо неё сгенерировала пересечение двух скользящих средних.

Такой код может компилироваться, проходить бэктест и совершать сделки. С технической точки зрения он работает. С точки зрения задания — нет.

Именно поэтому в QuantCode-Bench используется финальная проверка семантического соответствия.

Как устроен датасет

QuantCode-Bench содержит 400 задач разной сложности.

Источники заметно различаются по стилю.

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

После сбора каждая задача проходила структурное обогащение. Из исходного текста извлекались:

• используемые индикаторы;
• условия входа;
• условия выхода;
• дополнительные правила и ограничения;
• параметры управления позицией;
• уровень сложности.

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

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

Это делает проверку ближе к исходному контексту стратегии и снижает зависимость результатов от одного конкретного рыночного режима.

«Финам API» кардинально меняет подход к инвестициям. Используйте современный API для алготрейдинга, создания приложений и интеграции с сервисами. Он превращает инвестора из пассивного наблюдателя в активного архитектора своей торговой системы. Ключевые отличия «Финам API» — высокая скорость, наличие демосчета и выделенная клиентская поддержка. Сервис предоставляет доступ к российским и зарубежным биржам и предлагает сниженные комиссии для активных алготрейдеров. 

Четыре этапа проверки

1. Compilation

На первом этапе код проверяется на синтаксическую корректность и возможность интерпретации.

Этот тест отсекает незакрытые скобки, неверные отступы, некорректную структуру класса и другие базовые дефекты.

2. Backtest

Затем стратегия запускается на предоставленных бенчмарком исторических данных.

На этом этапе проявляются:

• обращения к несуществующим методам;
• неверные параметры индикаторов;
• ошибки типов;
• неправильная работа с линиями Backtrader;
• выход за границы доступной истории;
• ошибки исполнения и тайм-ауты.

3. Trade

После успешного бэктеста проверяется, была ли совершена хотя бы одна сделка.

Этот критерий не оценивает прибыльность. Он отвечает на более базовый вопрос: реализована ли логика так, чтобы стратегия вообще проявляла торговое поведение на данных.

4. Judge

На финальном этапе LLM-судья сопоставляет код с исходной постановкой.

Проверяется:

• используются ли требуемые индикаторы или допустимая эквивалентная формализация;
• реализованы ли ключевые условия входа и выхода;
• соответствует ли поведение стратегии заданию;
• не заменена ли задача универсальным торгующим шаблоном.

Только прохождение всех четырёх этапов считается полным успехом.

О пяти выводах экспериментов читайте далее в нашем блоге на «Хабре».