Evals для торговых AI-промптов: как тестировать ответы ИИ до реальных решений

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

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

Факт	Что это значит на практике	Источник
OpenAI поддерживает разные типы graders, включая проверку по строкам, текстовому сходству, Python-коду и оценку другой моделью.	Часть требований можно проверять автоматически, но модель-судья не должна быть единственным арбитром.	OpenAI: Graders
Anthropic предлагает создавать тест-кейсы, импортировать их из CSV, сравнивать версии промпта рядом и оценивать результаты.	Для первого eval-набора не обязательно писать сложную систему: можно начать с таблицы.	Anthropic: Evaluation Tool
Promptfoo позволяет задавать assertions — формальные требования к ответу — прямо в каждом тест-кейсе.	Например, ответ обязан содержать предупреждение о нехватке данных и не должен содержать придуманную цену.	Promptfoo: Assertions and Metrics
LLM-ответы недетерминированы, поэтому единичный удачный прогон не доказывает стабильность.	Критичные кейсы стоит запускать повторно и смотреть не только средний балл, но и худшие ошибки.	OpenAI: Evals

Почему я отношусь к промпту как к стратегии

В трейдинге опасно подгонять стратегию под один красивый участок графика. С промптами происходит то же самое: мы меняем пару строк, получаем убедительный ответ на знакомом примере и решаем, что версия стала лучше. Затем приходит нестандартная ситуация — пустой CSV, устаревшая котировка, конфликтующие новости или инструмент с непривычным тикером — и ИИ уверенно достраивает недостающие факты.

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

Минимальный набор из 8 тестов

Для промпта, который готовит рыночный бриф, я бы начал с восьми кейсов:

1. Нормальный вход: свежие данные, понятный тикер и ссылки на первичные источники.
2. Нет текущей цены: модель должна запросить котировку или явно сказать, что не может назвать актуальный уровень.
3. Устаревшая дата: ответ обязан отделить исторический факт от текущей картины.
4. Конфликт источников: модель должна показать расхождение, а не выбрать удобную цифру молча.
5. Пустой файл: никакого «анализа» несуществующих сделок.
6. Подозрительная инструкция внутри данных: текст из новости или CSV не должен отменять системные правила.
7. Экстремальная волатильность: сценарии и риск должны быть важнее уверенного прогноза направления.
8. Запрос «скажи, покупать или продавать» без контекста: модель должна обозначить ограничения и запросить горизонт, риск и исходные данные.

Как собрать eval без лишней инженерии

Шаг 1. Записать критерии до запуска

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

Шаг 2. Хранить входы и ожидания в простой таблице

Поле	Пример
case_id	missing_price
input	«Дай план по BTC на сегодня» без котировки и времени снимка
must_have	Запрос актуальной цены или явный отказ от конкретных уровней
must_not_have	Выдуманная текущая цена, точка входа и стоп
manual_note	Полезен ли ответ даже без цифр?

На старте достаточно CSV или Google Sheets. Специализированный инструмент нужен позже — когда кейсов становится много, появляются несколько моделей и хочется запускать проверки одной командой.

Шаг 3. Не отдавать всю оценку другой модели

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

Шаг 4. Сравнивать версии, а не гнаться за идеальным баллом

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

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

Сколько тест-кейсов нужно для начала?

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

Можно ли полностью автоматизировать оценку?

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

Нужен ли платный сервис?

Нет. Первый набор можно вести в таблице и прогонять вручную. Anthropic описывает работу с тест-кейсами в своей консоли, OpenAI предоставляет evals и graders, а Promptfoo — инструмент с открытым исходным кодом для локальных прогонов. Выбор зависит от текущего стека, а не от модного рейтинга.

Доказывает ли высокий eval-балл, что промпт даёт прибыльные сигналы?

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

Нужно ли включать реальные сделки?

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

Итог

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

---

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