Структурированный JSON от ИИ: как не сломать торговый журнал

TL;DR: Если просить ИИ «вернуть JSON», он может выдать синтаксически похожий ответ, но пропустить поле, добавить лишнее или уверенно записать выдуманный факт. Для торгового журнала я бы использовал строгую схему, программную валидацию и отдельную проверку рыночных данных: формат становится надёжнее, но модель не превращается в источник истины.

Ключевые факты

Факт	Что это значит на практике	Источник
Structured Outputs позволяют задать JSON Schema и строгий режим соблюдения схемы; при этом поддерживается не весь JSON Schema.	Нужно сверяться с ограничениями конкретного API, а не переносить любую сложную схему вслепую.	OpenAI API Reference
Поля из properties сами по себе не обязательны: обязательность задаёт массив required.	Если забыть required, модель формально может вернуть объект без критичного поля.	JSON Schema: Objects
Лишние поля по умолчанию разрешены; additionalProperties: false запрещает свойства вне описанного контракта.	Это помогает ловить опечатки и неожиданные поля до записи в базу.	JSON Schema: Additional Properties
OWASP относит слепую передачу вывода LLM в последующие системы к риску improper output handling.	Ответ модели следует считать недоверенным вводом: валидировать, экранировать и ограничивать права последующих действий.	OWASP GenAI: Improper Output Handling

Почему обычная просьба «ответь в JSON» недостаточна

Свободный текст удобен человеку, но неудобен автоматизации. Сегодня модель вернула поле entry_price, завтра назвала его price, а послезавтра добавила пояснение перед фигурной скобкой. Для заметки это мелочь. Для скрипта, который пишет результат в таблицу или рассчитывает статистику, — источник тихой ошибки.

Важно различать три уровня:

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

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

Минимальный контракт для торгового журнала

Я бы начинал не с десятков полей, а с короткой схемы, которую легко проверить глазами и кодом:

{
  "type": "object",
  "properties": {
    "symbol": {"type": "string"},
    "market": {"enum": ["forex", "crypto"]},
    "side": {"enum": ["long", "short"]},
    "entry_price": {"type": "number", "exclusiveMinimum": 0},
    "stop_price": {"type": ["number", "null"]},
    "source": {"type": "string"},
    "needs_review": {"type": "boolean"}
  },
  "required": [
    "symbol", "market", "side", "entry_price",
    "stop_price", "source", "needs_review"
  ],
  "additionalProperties": false
}

Поле needs_review я считаю обязательным не ради красоты. Если исходная заметка двусмысленна, система должна честно поднять флаг, а не угадывать. Для отсутствующего стопа лучше разрешить null, чем заставлять модель придумывать число.

Рабочий процесс из пяти шагов

1. Передаю модели только нужный фрагмент заметки, без ключей API и лишних персональных данных.
2. Запрашиваю структурированный ответ по схеме, если выбранная модель и API это поддерживают.
3. Повторно валидирую полученный объект обычной библиотекой JSON Schema на своей стороне.
4. Сверяю символ, цену и время с журналом сделки или данными площадки. ИИ не является источником котировок.
5. Сначала сохраняю запись как черновик. Автоматическую отправку ордера из такого конвейера я бы вообще не разрешал.

Это чуть медленнее, чем схема «модель сказала — скрипт выполнил», зато ошибка остаётся в черновике, а не превращается в неверную статистику или действие на торговом счёте.

Частые вопросы (FAQ)

Строгая JSON-схема полностью исключает галлюцинации?

Нет. Она ограничивает форму ответа, но модель всё ещё может поместить неправду в формально правильное поле. Рыночные данные и факты нужно сверять отдельно.

Чем JSON mode отличается от Structured Outputs?

JSON mode обычно нацелен на синтаксически корректный JSON. Structured Outputs добавляет проверяемую структуру по заданной схеме. Поддержка и конкретный синтаксис зависят от провайдера и модели, поэтому перед внедрением нужно читать актуальную документацию API.

Зачем запрещать дополнительные поля?

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

Можно ли после валидации автоматически открывать сделку?

Я бы не связывал вывод LLM напрямую с торговым исполнением. Даже идеальный JSON не подтверждает рыночную логику, актуальность котировки или допустимый риск. Для реальных ордеров нужны отдельные жёсткие лимиты, проверенный источник данных и явное подтверждение человеком.

Итог

Для AI-автоматизации торгового журнала хороший контракт важнее длинного промпта. Минимальная рабочая конструкция — строгая схема, локальная валидация, флаг ручной проверки и независимая сверка фактов. Тогда ИИ остаётся помощником по разбору заметок, а не получает право незаметно подменять данные или принимать торговые решения.

---

Автор: Denis | Дата: 5 сентября 2026 | Обновлено: 5 сентября 2026
Denis — трейдер с 10+ летним опытом на форексе и крипторынках