Две скорости ИИ-агента: стратегия, быстрые решения и жёсткие правила

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

Roan предложил другой способ разделить работу. В его схеме Claude Opus 5.5 исследует рынок и помогает строить стратегию, Jev отвечает на частые вопросы с заранее заданными вариантами ответа, а программный код проверяет ограничения и исполняет разрешённое действие. Автор рассказывает о торговом эксперименте. Мы разберём его как архитектурную идею, а затем посмотрим, как тот же принцип может помочь в обычных бизнес-процессах.

1. У системы есть несколько разных задач

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

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

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

Отсюда и две скорости. Сильная модель работает в медленном исследовательском контуре: формулирует и пересматривает гипотезы. Модель для ограниченных решений работает в частом контуре: получает состояние и отвечает на конкретные вопросы. Третий слой — обычная программа — проводит результат через правила и фиксирует последствия. Скорость ответа модели сама по себе ничего не говорит о скорости всего пути от данных до исполненного действия.

2. Почему Jev подходит для ограниченного решения

TypeSafe AI представляет Jev как модель для типизированных решений внутри программы. Разработчик заранее описывает допустимые ответы и передаёт текущее состояние. В ответ приходят структурированные значения, вероятности и оценка уверенности. Это удобно для вопроса вроде «к какой категории относится ситуация?» или «насколько выражен признак?», когда программа уже знает, что делать с каждым возможным исходом.

Такой ответ отличается от обычного текста языковой модели. Если агент написал: «Я склоняюсь к покупке, но есть признаки риска», программе ещё нужно понять, считать ли это приказом, предположением или просьбой подождать. Когда пространство ответов определено заранее, это различие можно зафиксировать до запуска. Варианты «действовать», «наблюдать» и «передать на проверку» имеют разные последствия в коде.

Но тип результата не делает само суждение правильным. Jev может ошибиться в оценке рынка или входящего обращения. Вероятность не является обещанием будущего события, а оценка уверенности не заменяет разрешение на действие. Важно выяснить, что именно предсказывает каждый вопрос, как проверяется его ответ и что система делает при сомнении. На 27 сентября 2026 года TypeSafe AI описывает Jev как продукт в раннем доступе.

Для медленного контура Roan выбрал Claude Opus 5.5. Anthropic позиционирует модель для сложных задач с кодом, агентами и документами. Её роль здесь — помочь исследовать гипотезу и подготовить проверяемую спецификацию. Ни название модели, ни убедительность написанного ею анализа не доказывают, что стратегия заработает.

3. Как проходит один полный цикл

Чтобы увидеть границы между слоями, пройдём один цикл экспериментальной торговой системы. Это описание устройства, а не инструкция запускать торговлю на реальные деньги.

Снимок состояния. Программа собирает данные, необходимые для заранее определённых вопросов: текущие заявки, недавние изменения цены, собственную позицию, доступные средства и состояние соединений. Вместе с числами она сохраняет время получения и источник. Если данные устарели или разные источники противоречат друг другу, цикл должен остановиться до вызова модели. «Быстрое» решение по старой информации не становится полезным из-за скорости вычисления.

Типизированное решение. Модель получает именно этот снимок и несколько ограниченных вопросов. Например: соответствует ли ситуация одному из описанных рыночных режимов; есть ли признаки повышенного риска; какой вариант действия предпочтителен из разрешённых. Возвращённый вариант и распределение вероятностей сохраняются целиком. Нельзя оставить в журнале только финальное «купить» и потерять сомнения, которые были видны в ответе.

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

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

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

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

4. Как проверить вероятности и качество решений

TypeSafe AI говорит о калиброванных вероятностях Jev. Проверять это утверждение для своего процесса всё равно нужно на собственных примерах. Калибровка означает простой вопрос: среди случаев, которым модель приписывала похожую вероятность, насколько часто соответствующий ответ действительно оказывался верным? Для этого заранее определяют проверяемый исход, сохраняют ответ модели до того, как исход стал известен, и затем сравнивают прогноз с результатом.

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

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

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

5. Что съедает результат и когда нажимать стоп

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

Отдельная ловушка — симуляция. Тест на истории и dry run показывают, как система вела бы себя по заданным правилам и предположениям об исполнении. Они полезны для поиска ошибок, но не подтверждают, что реальные заявки исполнятся так же. Сначала проверяют воспроизводимость на истории, затем работу в режиме наблюдения, затем последствия ограниченного действия под контролем ответственного. Каждая ступень отвечает на свой вопрос.

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

6. Что подтверждают источники, а что пока нет

Roan сообщает, что работал с системой три дня и получил очень хорошие результаты. В доступном посте нет полной истории решений, методики расчёта доходности и независимой проверки с учётом издержек и риска. Поэтому это заявление автора об эксперименте, а не доказательство прибыльности стратегии. Упоминание «HFT» также не подтверждает соответствие системы требованиям высокочастотной торговли: для такого вывода надо измерять весь цикл, а не отдельный вызов модели.

Публичный репозиторий jev-trader помогает понять устройство похожего цикла: состояние книги заявок, решение, отправка заявки и журнал событий. Но README прямо указывает, что публично развёрнутая версия — dry run с mock-моделью по умолчанию. Jev включается отдельной настройкой. Симулированное исполнение этого примера нельзя выдавать за подтверждённую автономную торговлю на Jev или за результат системы Roan. Это разные материалы, объединённые архитектурной темой.

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

7. Что из этой идеи полезно компании

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

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

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

Это проектный пример, а не заявление, что Pragma уже внедрила такую систему у клиента. Для нас интересен сам способ работы: сложную гипотезу исследовать отдельно, частый вопрос задавать в проверяемой форме, а право на действие закреплять правилами и ответственным человеком. В клиентском процессе начальная последовательность остаётся простой: черновик → согласование → отправка.

8. С чего начать проверку

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

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

В этом и состоит сильная часть идеи Roan. Полезный агент — не одна модель, которая всегда отвечает. Это система, в которой ясно, кто исследует, кто оценивает текущий случай, кто имеет право действовать и как команда узнаёт об ошибке.