Jev: Decision Models как альтернатива генеративным LLM в агентах
Модель Jev, разработанная TypeSafe, представляет собой новый класс «систем первого типа» (System One Models), ориентированных на быструю оценку вероятностей заранее заданных вариантов. В отличие от традиционных LLM, генерирующих текст, Jev работает как механизм принятия решений, предоставляя выбор, оценку или вероятность ответа. Автор статьи исследует применение модели для маршрутизации запросов, создания гвардов перед вызовом инструментов (guardrails) и повышения надежности агентов за счет проверки достаточности данных.
# Jev: Decision Models как альтернатива генеративным LLM в агентах
Недавно сообщество разработчиков начало активное обсуждение модели Jev, разработанной компанией TypeSafe. Некоторые источники описывают её как потенциальную замену большим языковым моделям (LLM), но это преувеличение. Jev не заменяет LLM, а дополняет их, выполняя узкоспециализированные задачи принятия решений, где важна скорость и предсказуемость, а не креативность генерации текста.
Автор статьи подчеркивает, что Jev относится к классу System One Models. Эта отсылка к работе Даниэля Канемана указывает на фундаментальное различие в работе: система 1 обеспечивает быстрые, интуитивные реакции, тогда как традиционные LLM имитируют более глубокий анализ (систему 2), но медленнее. Jev жертвует свободной генерацией в пользу определения вероятности заранее определенных исходов.
Принципы работы: выбор вместо текста
Ключевое отличие Jev от OpenAI или других провайдеров LLM заключается в структуре запроса. Пользователь не просит модель «написать ответ», а задает вопрос в контексте сформулированных ограничений.
Работа модели строится на трёх компонентах: 1. State (Состояние): Контекст диалога или текущие данные (например, история сообщений агента). 2. Questions (Вопросы): Строго определённые задачи, где на каждый вопрос есть предопределенный список вариантов ответа. 3. Outputs (Выходные данные): Вместо текста модель возвращает choice (выбранный вариант), score (оценку) или noul (вероятность числового значения).
Ограничение модели составляет 64K токенов на запрос, из которых 32K отводится на состояние и сам вопрос. Это делает её эффективной для обработки параллельных запросов к одному состоянию, что удобно для многозадачных агентов.
Автор приводит пример тестирования через OpenRouter, где задача заключалась в оценке риска выполнения конкретного tool_call. Вместо того чтобы спрашивать у модели «Опасно ли это?», разработчик задал жесткие критерии: «Истинно, если действие удаляет данные или отправляет информацию наружу» против «Ложно, если действие лишь читает локальные данные».
Маршрутизация и Guardrails: безопасность агентов
Одним из самых практических применений Jev, продемонстрированных в статье, является использование в качестве middleware (посредника) в цепочках агентов.
Выбор модели (Routing) Вместо того чтобы отправлять каждый запрос в самую мощную и дорогую модель (например, GPT-4), агент может сначала использовать Jev для оценки сложности задачи. Если модель считает задачу простой, она направляет её в бюджетную версию, а сложные — в премиальные модели. Это позволяет оптимизировать расходы.
Проверка безопасности (Safety Guardrails)
Перед вызовом любого инструмента агент может отправлять запрос в Jev с целью подтверждения безопасности действия. В примере с кодом автор создает middleware JevGuardMiddleware, который:
* Перехватывает попытку вызова инструмента.
* Запрашивает у Jev вероятность риска (risk_probability).
* Если вероятность превышает порог (например, 0.3), блокирует выполнение и возвращает сообщение об ошибке.
В тестовом сценарии модель успешно заблокировала вызов функции удаления файла с базой данных клиентов (C:/important/customer_database.db), оценив риск в 0.75. Также был заблокирован вызов отправки письма с пугающим содержанием («База удалена»), которое расценилось как потенциально вредоносное.
Проверка достаточности данных Другой кейс применения — проверка того, предоставил ли пользователь достаточно информации. Модель Jev оценивает вероятность наличия всех необходимых данных в запросе. Если вероятность достаточности данных низка (ниже 0.7), агент запрашивает уточняющие вопросы у пользователя, предотвращая галлюцинации или выполнение действий по умолчанию.
Автор отмечает, что, хотя Jev работает быстрее и не страдает от привычных «галлюцинаций» в генерации текста, она всё равно может ошибаться. Уверенность модели не гарантирует правильность ответа, поэтому разработчики должны самостоятельно подбирать пороги принятия решений.
Ограничения и проверка знаний
В статье приведена интересная проверка на знание факта («сколько букв R в слове strawberry?»). Модель Jev выбрала вариант «2» (83% уверенности), хотя правильный ответ «3». Это демонстрирует, что даже в задачах с ограниченными вариантами ответов модель может демонстрировать неполное понимание семантики или допускать ошибки в арифметике/логике, если не обучена специально на таких задачах.
Также упоминается потенциальное использование Jev в системах RAG (Retrieval-Augmented Generation) для сортировки кандидатов (reranking) или проверки актуальности фрагментов информации, однако автор предполагает, что это возможно, но требует дополнительной интеграции.
Заключение
Jev не является «убийцей» LLM, а представляет собой специализированный инструмент для принятия решений. Её сила лежит в области классификации, валидации и безопасности. Для разработчиков агентов она предлагает способ снизить задержки, повысить безопасность действий инструментов и оптимизировать расходы на генерацию текста, делегируя простые оценочные задачи быстрым decision models.