«Это не вопрос о том, какая модель умнее»: Jev AI объяснила, когда решение должно уходить отдельному слою решений

Что вышло

Официальное руководство «What Is Jev AI? A Practical Guide to System One and Executable Decisions» компания Jev AI опубликовала на своём сайте 20 сентября 2026 года. На следующий день в блоге Hugging Face появилась его версия в формате сравнения — «Jev AI vs LLMs: When Should You Use a Decision Model Instead of a Chat Model?» — с той же аргументацией и датой исследования 20 сентября.

Поводом авторы называют практический вопрос, который возникает у команд при первом знакомстве с Jev: чем эта модель отличается от ChatGPT, Claude и других больших языковых моделей, если те уже умеют возвращать JSON. Официальная документация TypeSafe, для которой Jev — флагманская модель и первая модель класса System One, формулирует разницу так: языковые модели созданы производить текст для людей, а Jev делает суждение, которое код потребляет напрямую.

Генератор против слоя решений

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

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

Пять измерений для сравнения

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

Когда выбирать слой решений

Авторы перечисляют пять условий, при которых стоит сначала протестировать Jev: множество вариантов ответа конечно и его можно перечислить заранее; вопрос один и ясный, а не составной; результат управляет кодом — очередью, правами, выбором модели, вызовом инструмента или эскалацией человеку; нужна автоматизация, которая учитывает неопределённость; бизнес-политика остаётся в приложении.

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

Когда остаётся языковая модель

Генерацию маркетинговых текстов, писем, объяснений и кода, пересказ длинных документов, открытое исследование с несколькими вариантами ответа и диалог с переписыванием по обратной связи авторы оставляют генеративным моделям. В сценариях с большим контекстом и длинным ответом ценность языковой модели перевешивает несколько сотен миллисекунд, тогда как отдельный слой решений имеет смысл там, где за секунду принимается много маленьких решений.

Как их сочетать

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

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

Как проверять

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

Что сказано в официальной документации

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

Инженерная документация продукта повторяет то же разделение ролей: традиционные языковые модели в основном производят текст, который читают люди, а Jev отдаёт решения, которые код использует напрямую — ветвится по ним, сортирует и маршрутизирует. На главной странице продукта заявленный диапазон задержки — 70–500 мс, а на площадке можно бесплатно и без ограничений прогнать собственный сценарий и посмотреть типизированное решение с вероятностями.

Оговорки и границы применимости

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

Использовать его без языковой модели можно, если продукту нужны только классификация, оценка, маршрутизация и ответы «да/нет»; если нужна генерация или открытые объяснения, добавляется генеративная модель. Отдельная оговорка — цифры: задержка 70–500 мс относится к вызову и зависит от сети, размера запроса и нагрузки, а не является гарантией уровня сервиса.