Что такое Jev и почему это не очередная LLM
Jev от TypeSafe AI вышла 15 сентября 2026 года. Это модель класса System One, которая не пишет текст и не ведёт диалог: на входе у неё состояние и список вариантов, на выходе распределение вероятностей над этими вариантами. Реакция западного AI-сообщества и инженерный разбор модели собраны на Habr (обзор Jev и её архитектурных идей).
Смысл конструкции в том, что модель закрывает мелкие семантические задачи: выбрать вариант, оценить вероятность, присвоить скор. Дальше решает код. Число 0.83 само по себе ничего не делает, но если порог выставлен на 0.7, тикет уходит в отдел возвратов без участия человека.
Типовое обращение в поддержку авиакомпании: «рейс отменили, замену не предложили, верните деньги, и вообще это третий раз за год, а я платиновый клиент». Софт на входе должен ответить сразу на несколько вопросов: это запрос на возврат? насколько клиент раздражён? в какой отдел маршрутизировать? нужен ли живой оператор? Четыре решения, каждое из которых обычной программе не по зубам.
Главная ставка TypeSafe: не отдавать большой LLM весь control flow. State и логика остаются в коде, AI подключается только там, где программе не хватает семантики.
Ключевое отличие от генеративных моделей
Авторегрессионная LLM предсказывает следующий токен и повторяет шаг в цикле, пока не выдаст стоп-сигнал. Jev делает один forward pass и softmax по заданным вариантам, без единого сгенерированного токена.
Пример из карточки decider-2b-vision на Hugging Face: модель принимает изображение (фото, диаграмму, кадр игры) и текстовый вопрос с вариантами под буквами, а возвращает калиброванную вероятность по этим вариантам на одном answer slot, без генерации. Все шесть репозиториев семейства decider используют один интерфейс в формате TypeSafe и один readout: letter logits на answer slot, softmax по вариантам (карточка decider-2b-vision).
Отсюда следствие, о котором легко забыть. Вариант вне заданного списка модель выдать не может, а вот выбрать неверный вариант из списка способна, причём с высокой уверенностью. Формат ответа гарантирован, правильность ответа нет.
Второе отличие касается стоимости. Генерация текста требует декодирования токен за токеном, а один forward pass с softmax по нескольким вариантам укладывается в миллисекунды. Для задач, где решение нужно миллионы раз в сутки, разница между режимами определяет, окупается сценарий или нет. Практические кейсы замены LLM на модель такого класса разобраны отдельно (разбор модели без текста на выходе).
Почему это называется System One
Название отсылает к делению мышления на два режима: быстрый, автоматический и медленный, аналитический. Первый срабатывает мгновенно и почти не тратит ресурсов, второй включается там, где нужна многошаговая работа.
В этой рамке Jev занимает место быстрого режима: классифицировать обращение, проверить команду, оценить риск. LLM остаётся для задач, где нужна цепочка рассуждений и генерация. Класс задач другой, поэтому и требования к задержке, цене и калибровке отличаются.
Архитектура и примитивы: Choice, Noulli, Score
Три примитива закрывают три типа вопросов к состоянию. Choice выбирает один вариант из списка. Noulli даёт вероятность бинарного события, то есть ответ да или нет. Score присваивает оценку по шкале.
Каждый вызов возвращает распределение, а не строку текста. State и control flow остаются в коде: модель отвечает на вопрос, решение принимает программа.
Как работают примитивы на примере кода
Точный синтаксис SDK в публичных материалах не раскрыт, поэтому ниже схема вызова, а не дословный код библиотеки. Она показывает логику работы примитивов.
route = Jev.Choice(
state=customer_message,
options=["возврат", "жалоба", "вопрос"],
)
route.probabilities
# {"возврат": 0.71, "жалоба": 0.22, "вопрос": 0.07}
angry = Jev.Noulli(state=customer_message, question="Клиент раздражён?")
angry.probability
# 0.83
priority = Jev.Score(state=customer_message, scale=(1, 10))
priority.score
# 7
if route.probabilities["возврат"] > 0.7:
open_refund_ticket()
Порог 0.7 задаёт код, а не модель. Здесь проходит граница с агентной архитектурой: в агентном цикле ветвление поручают LLM и получают текстовое обоснование, которое потом нужно разбирать парсером. В схеме с примитивами ветвление остаётся обычным условием, а модель поставляет только вероятность.
Вызовов у такой функции много, и они мелкие. Поэтому важны не только точность, но и накладные расходы на каждый вызов: сериализация состояния, сеть, время ответа. Как это встраивается в готовый фреймворк, показано на примере интеграции с LangChain (TypeSafeClassifier и middleware для Jev).
Франкенштейнинг: как CEO TypeSafe описывает архитектуру
Архитектуру Jev CEO TypeSafe описывает термином «Франкенштейнинг». Речь о сборке из частей: одна часть держит состояние и логику, другая отвечает за семантику на отдельном шаге, связка между ними остаётся явной и типизированной.
У такой сборки есть инженерный плюс. Сбой локализуется: видно, какой примитив вернул подозрительную вероятность и на каком пороге код пошёл не туда. В монолитном агентном цикле причину искать сложнее, потому что шаги решения спрятаны внутри генерации.
RLCD: пост-трейнинг для калиброванных решений
RLCD расшифровывается как Reinforcement Learning for Calibrated Decisions. Этот метод пост-трейнинга настраивает модель под калиброванные решения для программ, а не под человеческие предпочтения, как RLHF (разбор с деталями подхода).
Разница по смыслу большая. RLHF подгоняет ответы под то, что людям нравится читать: полезный тон, развёрнутость, вежливость. RLCD работает с вероятностью: число 0.83 должно означать примерно 83 случая из 100, а не общее ощущение уверенности модели.
Для кода это критично. Порог задаёт инженер, и от порога зависит, сколько запросов уйдёт в автоматику, а сколько к человеку. Если вероятности смещены, любой порог врёт, и подбирать его приходится на глаз.
Технического отчёта по RLCD нет. Остаются описания подхода и заявление, что именно этот пост-трейнинг стоит за Jev. Проверить калибровку без своих данных нельзя, поэтому перед продакшеном нужны собственные замеры.
Сценарии применения: от dark data до real-time intelligence
У модели четыре естественные точки приложения, и все они связаны с массовыми решениями, а не с открытой генерацией.
Dark data: обработка неструктурированных данных
Dark data - это данные, которые лежат в системах, но не участвуют в аналитике: логи, старые тикеты, сканы, письма. Обычные методы их не разбирают, а прогонять миллионы записей через большую LLM дорого.
Здесь работают классификация и скоринг: тип документа, тема обращения, наличие обязательных реквизитов, срочность. Модель возвращает вероятности, код раскладывает их по порогам и сортирует записи.
Verify everything: верификация в реальном времени
Второй сценарий: проверять каждое действие, а не выборку. Соответствие ответа регламенту, корректность аргументов вызова инструмента, запрещённые формулировки, риск транзакции.
Такой режим требует дешёвого вызова с низкой задержкой, иначе проверка в горячем пути становится узким местом. Оценка поведения агентов в этой логике превращается в отдельную задачу: судья, который размечает трейсы по заданным критериям, разобран в материале про System One модель в роли судьи для агентов.
Real-time intelligence и smart software
Третий и четвёртый сценарии идут вместе. Real-time intelligence означает решения прямо в потоке: мониторинг, игры, торговые события, обработка кадров. Smart software возвращает семантику в обычную программу, не переписывая её на LLM.
Цифры из карточки decider-2b-vision: 4 мс на запрос с CUDA graphs на одном GPU и live browser 93% для браузерных агентов. Модель обучена на кадрах Pong, Breakout, CliffWalking, MiniGrid и Super Mario Bros, размеченных скриптовыми политиками, и на задачах с изображениями из The Cauldron. Кадр 256x240 занимает 64 визуальных токена, а softmax по вариантам действий работает как политика. Результаты неровные: Breakout 41, Pong 3, CliffWalking -13, MiniGrid Empty 0.96, а на held-out Freeway и FrozenLake модель результата не показывает (карточка decider-2b-vision на Hugging Face).
Ограничения и риски: что нужно знать перед внедрением
Публичных данных о Jev немного, и это первое, что стоит учитывать. Независимых оценок мало, деталей обучения тоже. Ключевые открытые вопросы: детали RLCD, поведение на многошаговых задачах и доверие к confidence без своих замеров (разбор с перечнем открытых вопросов).
Слабость на многошаговом reasoning
Jev не предназначена для цепочек рассуждений. Она отвечает на один вопрос по текущему состоянию: выбрать, оценить, присвоить скор. Если задача требует спланировать маршрут из пяти шагов, построить доказательство или разобрать противоречивые данные, лучше работает LLM.
Практическое правило простое: один шаг решения - примитив Jev, последовательность шагов - LLM. Промежуточные выводы примитив не удерживает, поэтому ждать от него цепочки рассуждений бессмысленно.
Необходимость собственных эвалов и калибровки
Confidence от модели требует проверки на своих данных. Публичные наборы задач не отражают ваш домен: распределение классов, формулировки, длину входов, долю пограничных случаев. Значит, нужен свой набор примеров с разметкой и замер калибровки, иначе пороги придётся выставлять наугад.
Пример такого замера на открытых и внутренних данных с подбором порогов отбрасывания разобран отдельно (16 000 вызовов Jev на своих данных). Смысл в том, чтобы мерить два разных свойства: точность ответов и частоту случаев, когда модель уверена неправильно.
Критика публичных бенчмарков и версионирование
Бенчмарки вендора удобны для сравнения версий между собой, но плохо переносятся на чужой домен. Числа из карточки модели говорят о классе задач, а не о том, как модель поведёт себя на ваших логистических документах или медицинских выписках.
Вопрос версионирования остаётся открытым. У моделей такого класса смена версии легко сдвигает калибровку, поэтому важно фиксировать, какая версия стоит в продакшене, и хранить свой набор проверочных примеров рядом с релизом. Без этого регресс заметят уже в проде.
Отдельный аргумент за разделение кода и модели связан с контекстом агентов. Кодинговый агент на LLM тащит через каждый шаг всю историю: файлы, диффы, выводы команд. KV-cache растёт, задержка и стоимость вызова растут вместе с ним, и решения принимаются внутри раздутого контекста. Эту зависимость называют «тиранией KV-cache». Замена части таких решений на вызов примитива с текущим состоянием снимает нагрузку с контекста, но проверять эффект нужно на своих метриках задержки и цены.
Как начать использовать Jev: практические шаги
Где скачать и как запустить
Публично доступный ориентир - карточка decider-2b-vision на Hugging Face. Это vision-вариант, а не сама Jev, поэтому метрики и детали обучения относятся к отдельной модели, а не ко всей линейке. Веса трансплантированы в vision-language модель Qwen3.5-2B, а обучение заняло одну эпоху: 80 тысяч примеров, из них 50 тысяч с изображениями, включая игровые кадры от скриптовых политик и multiple-choice задачи с картинками из The Cauldron (карточка decider-2b-vision).
Для запуска нужен GPU с поддержкой CUDA: заявленные 4 мс на запрос получены с CUDA graphs на одном ускорителе. Ориентиры по качеству из той же карточки: hard 0.541 на JevBench, 0.704 на Bespoke suite, 0.89 на Visual7W.
Отдельно стоит посмотреть на версионирование. В карточке указано, что текстовые веса внутри модели относятся к decider-2b, то есть поведение соответствует версии v5, а ретрейн на текущих текстовых весах v6-v10 не выпущен.
Сравнить подход с открытым прототипом на другой архитектуре можно по разбору Jev-подобного API на Ninfer: 84,4% на JevBench v1.2, калибровка ECE 0,045 и 127 мс на RTX 5090 (разбор прототипа на JevBench).
Примеры использования в коде
Схема работы с изображением повторяет логику текстовых примитивов: на вход идёт кадр или документ плюс вопрос с вариантами, на выход вероятность по каждому варианту.
result = Jev.Choice(
state=screen_shot,
options=["A", "B", "C", "D"],
question="Куда ведёт эта кнопка?",
)
if result.probabilities["A"] > 0.6:
click("A")
Ветвление и побочные эффекты остаются в коде приложения. Модель поставляет вероятность, а политика поведения описана обычными условиями, которые можно прочитать, протестировать и залогировать.
Итог: кому стоит присмотреться к Jev
Jev полезна там, где решений много, каждое мелкое и повторяется миллионами вызовов: роутинг обращений, классификация документов, проверка аргументов вызовов инструментов, оценка трейсов агентов, обработка кадров. Плюсы очевидны: один forward pass, калиброванные вероятности, отсутствие генерации и связанных с ней рисков формата.
Для чат-ботов, длинных рассуждений и генерации текста нужна LLM. Модель класса System One такую задачу не решает: она отвечает на один вопрос по текущему состоянию.
Перед запуском в продакшене закройте три вопроса. Какова калибровка на ваших данных, а не на датасете вендора? Где проходит порог между автоматикой и человеком? Какая версия модели у вас стоит и как вы узнаете о её смене? Ответы дают больше, чем любой публичный бенчмарк.