Jev, модель от TypeSafe AI, на вход получает состояние (state), а на выходе отдаёт типизированные ответы и вероятности. Текста в ответе нет вообще. Агенту такой формат подходит для быстрых решений: выбрать инструмент, оценить риск, классифицировать обращение, понять, срочный ли запрос.
Цифры, которые приводит TypeSafe AI: до 200x более быстрый инференс и до 400x меньшая стоимость по сравнению с сопоставимыми LLM на задачах классификации. Это данные вендора, независимых замеров в открытых источниках нет. Обучение шло методом reinforcement learning for calibrated decisions (RLCD), а вопросы делятся на три типа: choice, score и noul.
Место Jev в стеке определяется просто: она не заменяет LLM. Генеративная модель рассуждает, пишет и планирует. Jev принимает узкие структурированные решения внутри агентного цикла, где важны миллисекунды и цена вызова. Для LangChain есть готовый путь подключения через TypeSafeClassifier и middleware.
Что такое Jev и почему это не очередная LLM
System One модель: что это за класс моделей
Термин System One model ввела команда TypeSafe AI. Так называют класс AI-моделей, построенных для быстрых структурированных решений, которые софт использует напрямую. Такая модель оценивает состояние и возвращает типизированные ответы и вероятности.
Ключевое отличие от привычной LLM лежит в контракте. Языковая модель принимает текст и порождает текст токен за токеном, а результат потом нужно разбирать и валидировать. System One модель принимает state и вопросы, а отдаёт значения заданных типов: вероятность для каждого варианта, непрерывный балл, вероятность истинности утверждения. Разбирать вывод не нужно, он уже структурирован.
Второе отличие: нет последовательного декодирования. Jev не ограничена генерацией текста или последовательным принятием решений; состояние оценивается как единое целое. На этом строится выигрыш по задержке ответа. Практическую сторону подхода, кейсы, где такая модель уже заменяет языковую, и ограничения метода разбирает отдельная статья о Jev.
Зачем Jev нужна в агентных системах
Агентный цикл состоит из череды мелких решений. Какой инструмент вызвать, хватит ли данных, безопасен ли запрос, отвечать сразу или уточнить. Типичная реализация прогоняет каждое такое решение через LLM: дорого, медленно, а на выходе всё равно текст, который надо парсить. Внутри цикла это заметная доля задержки и счёта за API.
Jev закрывает именно этот участок. Компания описывает модель как дополнение к LLM, а не как замену: генеративную модель логично использовать для открытых рассуждений, а Jev для быстрых решений. Аналогия простая: LLM размышляет, Jev реагирует.
Если вы собираете агента с нуля, роли стоит разделить сразу. Оркестрацию, память и инструменты с практическими метриками latency и cost разбирают в материале о самописном AI-агенте на Python.
Как работает Jev: state, questions и три типа вопросов
Вызов строится на двух частях: state (контекст) и questions (вопросы об этом состоянии). Никаких ролевых инструкций вида «ты полезный ассистент» и разбора свободного текста. Вопросы формулируются как строгие задачи, ответы приходят значениями заданных типов. Разбор Jev в блоге LangChain описывает три типа вопросов.
Choice: выбор из вариантов с вероятностями
Choice просит выбрать один вариант из набора. Модель возвращает вероятность для каждого варианта и общую оценку уверенности. Типичные задачи: выбрать инструмент из списка, определить маршрут обработки запроса, отнести обращение к категории. Вероятности калиброваны за счёт RLCD, поэтому порог можно задавать осознанно: пока уверенность ниже порога, решение передаётся дальше, например в LLM.
Score: оценка по уровням с непрерывным баллом
Score оценивает вход по упорядоченным уровням, скажем low, medium и high. На выходе не метка, а непрерывный балл, распределение и значение уверенности. Так удобно оценивать тональность, срочность, качество ответа или релевантность документа. Распределение важнее метки: по нему видно, насколько модель колеблется между уровнями, и это подсказывает, где ставить порог.
Noul: ответ да/нет с вероятностью
Noul отвечает на вопрос да/нет и возвращает вероятность истинности утверждения. В гайде LangChain есть пример: state - сообщение клиента о проблеме с подключением Stripe, вопрос is_urgent с пояснением «The message conveys urgency or time-sensitivity». Ответ - вероятность 0.999, то есть 99,9%, что сообщение срочное. Бинарная проверка с числом на выходе позволяет гибко настроить порог срабатывания: «Содержит ли запрос персональные данные», «Нужно ли вызывать внешний API», «Можно ли выполнить действие без подтверждения».
Параллельная обработка нескольких вопросов
Один запрос может содержать несколько вопросов об одном состоянии. System One модели обрабатывают их параллельно: добавление вопросов почти не меняет время ответа и стоит только токены за эти дополнительные вопросы, которые дёшевы.
Практический эффект на примере. Вместо трёх отдельных обращений к LLM (какой инструмент выбрать, насколько запрос срочный, безопасен ли он) уходит один вызов Jev с тремя вопросами к одному state. Пользователь пишет в поддержку: choice выбирает очередь, score оценивает срочность, noul проверяет, нужен ли живой оператор. Три ответа приходят за время, близкое к одному.
Производительность и стоимость: насколько реальны 200x и 400x
Заявленные числа: до 200x более быстрый инференс и до 400x меньшая стоимость по сравнению с сопоставимыми LLM на задачах классификации. Источник этих метрик - сама TypeSafe AI, и это важно держать в голове: независимых бенчмарков по Jev в открытом доступе нет.
Почему классификация быстрее генерации
Порядок величин объясняется механикой. Генерация текста требует последовательного декодирования: каждый следующий токен зависит от предыдущих, время растёт с длиной ответа. Jev выполняет один проход по состоянию и отдаёт вероятности. Чем длиннее вывод у LLM, тем сильнее разрыв.
Что стоит за 400x экономией
Стоимость вызова складывается из вычислений и объёма сгенерированных токенов. У Jev второго слагаемого нет, а дополнительные вопросы в одном запросе стоят лишь токены за эти вопросы, которые дёшевы. Отсюда кратная экономия на классификации.
Границы применимости тоже понятны. Экономия относительна: её считают против LLM, решающей ту же задачу. Если задача требует генерации текста или многошаговых рассуждений, Jev не поможет, и сравнивать нечего. В реальном проекте выигрыш снижают накладные расходы: подготовка state, сериализация контекста, сетевые вызовы, логика на стороне приложения. На коротких состояниях именно они могут съесть всю разницу.
Интеграция с LangChain: TypeSafeClassifier и middleware
LangChain описывает свою модель как провайдер-агностичную и считает её подходящей для поддержки Jev рядом с тысячами других интеграций и провайдеров моделей. Практический гайд по Jev опубликован в блоге LangChain.
TypeSafeClassifier: как вызывать Jev из LangChain
TypeSafeClassifier вызывает Jev из узлов и middleware LangChain. Он принимает state и questions и возвращает типизированные ответы. Смысл в том, что Jev встраивается в существующий пайплайн без переписывания логики: там, где раньше стоял вызов LLM с парсингом ответа, появляется вызов классификатора. Публичный текст источника обрывается на разделе про использование с LangChain, поэтому детали API стоит сверять по актуальным материалам проекта.
ModelRouterMiddleware: маршрутизация моделей на лету
ModelRouterMiddleware показывает, как применить Jev для маршрутизации моделей. Middleware перехватывает запрос, отправляет состояние в Jev, получает решение вида choice и по нему выбирает, какую LLM вызвать: дешёвую или мощную. Сложный запрос уходит на дорогую модель, рутинный на лёгкую. Для агентов на LangChain это способ сократить счёт за API: разбор похожих подходов к middleware есть в материале про Deep Agents v0.7.
AutoModeMiddleware: блокировка рискованных инструментов
AutoModeMiddleware блокирует рискованные вызовы инструментов до их выполнения. Jev оценивает состояние и решает, безопасен ли вызов: сюда подходит noul с порогом по вероятности или choice с вариантами «выполнить», «спросить подтверждение», «запретить». Проверка идёт до самого действия, поэтому агент не успевает навредить. Слой не панацея: он ограничен качеством состояния, которое вы ему подаёте, и порогом, который вы выставили. Это дополнительная защита рядом с остальными, а не замена им.
Jev vs LLM: когда что использовать
| Задача | LLM | Jev |
|---|---|---|
| Генерация текста, объяснений, кода | Да | Нет |
| Открытые рассуждения, планирование | Да | Нет |
| Классификация и выбор из списка | Можно, но дороже | Да |
| Бинарные проверки (PII, безопасность) | Можно, но дороже | Да |
| Оценка по шкале с вероятностью | Возможна | Да |
| Несколько решений по одному контексту | Отдельные вызовы | Один вызов, параллельно |
Рабочая схема чаще гибридная. LLM генерирует план или ответ, Jev оценивает каждый шаг: безопасен ли вызов инструмента, к какой категории отнести запрос, какую модель подключить. Правило простое: если на выходе нужен текст, это работа LLM. Если нужен ответ из заданного набора значений, это работа Jev. Категоричных рекомендаций тут не бывает: при низкой нагрузке обычная LLM справится с классификацией, и отдельный компонент только добавит сложности в стек.
Ограничения и подводные камни Jev
- Нет генерации. Творческие задачи, длинные объяснения, работа с кодом сюда не входят.
- Метрики от вендора. 200x и 400x заявлены TypeSafe AI; независимой проверки в открытых источниках нет.
- Зависимость от калибровки. Доверие к вероятностям держится на RLCD и обучающих данных. Точность на вашем домене нужно проверять на своих примерах.
- Подготовка state. Качество решения зависит от того, что вы положите в контекст, и от того, насколько чётко сформулированы вопросы.
- Ниша. Для сложных многошаговых рассуждений Jev не подходит и не претендует на это.
Заявленные вендором числа стоит проверять, а не принимать на веру. Как читать такие показатели и где метрики из карточки модели могут завышать реальную картину, разбирается в материале про model card и evaluation awareness.
Практические сценарии: где Jev уже применяется
- Маршрутизация моделей. Jev решает, какую LLM вызвать под запрос, и снижает стоимость инференса (ModelRouterMiddleware).
- Блокировка рискованных инструментов. Проверка вызова до выполнения, по вероятности из noul или по выбору из вариантов (AutoModeMiddleware).
- Классификация обращений. Разбор тикетов по категориям, очередям и приоритету одним запросом с несколькими вопросами.
- Оценка контента. Тональность, срочность, релевантность и токсичность по шкале score с распределением на выходе.
- Бинарные проверки в цикле агента. Наличие персональных данных, необходимость внешнего API, нужен ли живой оператор.
Это сценарии, а не готовые рецепты. Каждый требует своих вопросов, порогов и набора тестовых примеров, на которых проверяется калибровка.
Стоит ли пробовать Jev сейчас
Jev окупается, когда вы строите агента на LangChain и упираетесь в стоимость или задержку решений, которые повторяются тысячи раз: классификация, маршрутизация, проверки безопасности. Если в проекте только генеративные задачи, брать её незачем.
Порог входа зависит от того, насколько аккуратно вы формулируете state и вопросы, и есть ли у вас набор примеров для проверки калибровки. Начать логично с одной задачи внутри цикла, замерить latency и стоимость до и после, и только потом расширять область применения.