Jev стоит ставить перед LLM там, где нужно выбрать, а не написать

Jev принимает решения из списка, а не ведёт разговор

Jev относят к моделям «системы 1». На вход она получает описание ситуации и заранее заданные варианты ответа. На выходе возвращает выбранный вариант и уровень уверенности. Свободный текст она не пишет.

Это важное ограничение. Jev не заменит ChatGPT, Claude или Gemini в задаче, где надо объяснить, спроектировать, написать письмо или код. Зато она годится для момента, в котором системе нужно быстро выбрать один путь из нескольких.

Пример из поддержки: есть сообщение о проблеме с подключением Stripe, потере продаж и срочности. Модели задают несколько независимых вопросов: куда направить обращение, насколько клиент недоволен, какой сценарий обработки выбрать. Она может ответить на них параллельно. В примере запрос ушёл в биллинг с уверенностью 64%, а тон был определён как умеренно недовольный.

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

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

Скорость и цена имеют смысл только в повторяющемся контуре

Для структурированных решений заявлены 3 преимущества: скорость, низкая стоимость и стабильный формат ответа. Утверждается, что Jev может быть в 20-200 раз быстрее и в 40-1000 раз дешевле LLM на похожих задачах. Также заявлено 0% отказов структурированного вывода: ответ не превращается в некорректный JSON, который ломает следующий шаг автоматизации.

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

Но сам принцип здравый. Если агент делает сотни однотипных выборов, постоянный вызов LLM становится дорогим и медленным. Особенно когда генерация текста вообще не нужна. Решение можно принять отдельно, а рассуждение и создание результата оставить LLM.

Маршрутизация убирает глубокую проверку там, где она не нужна

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

Такой же подход работает с несколькими LLM. Jev получает запрос пользователя и выбирает маршрут: сильная, кодинговая, открытая или быстрая модель. В демонстрации глубокий вопрос был направлен сильной модели со 100% уверенностью, а задача перевести Bash в PowerShell - кодинговой с уверенностью 98%.

Десятки подобных решений, по приведённому примеру, обошлись в 0,4 цента, а среднее время выбора составило 0,2 секунды. Это не обещание для любой системы. Но это хорошая причина измерить собственную маршрутизацию, если сейчас роль диспетчера выполняет ещё одна LLM.

Каркас маршрута можно записать так:

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

Агенту нужен выбор следующего действия, а не новый монолог

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

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

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

Универсальная классификация не отменяет проектирование правил

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

Это удобно, но не снимает инженерную работу. Нужно определить:

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

Начинать нужно с одной развилки, которая съедает вызовы LLM

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