Jev: модель, которая не пишет текст, а принимает решения

15 сентября 2026 года компания TypeSafe AI вышла из режима тишины и открыла доступ к модели Jev. За неделю о ней написали все профильные каналы, и почти везде она подаётся как «новый тип ИИ». Это тот редкий случай, когда формулировка не преувеличение: Jev действительно не делает того, что делают ChatGPT, Claude или Gemini. Она не пишет ни одной буквы.

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

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

Что произошло и кто за этим стоит

TypeSafe AI основана в 2024 году и до сентября 2026-го работала в закрытом режиме. Основатель и генеральный директор: Диогу Алмейда, до этого исследователь OpenAI и соавтор работы про InstructGPT, то есть один из тех, кто в своё время учил модели следовать инструкциям человека. Под запуск компания объявила о привлечении 40 миллионов долларов.

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

Это смена адресата. Обычные языковые модели затачивались под то, чтобы человеку нравился ответ. Jev затачивалась под то, чтобы программа могла на ответ положиться.

Чем Jev отличается от обычной нейросети

Если вы когда-нибудь просили модель «верни JSON с категорией заявки», вы знаете весь набор проблем: иногда приходит текст вокруг JSON, иногда категория, которой нет в списке, иногда вежливый отказ, иногда просто «конечно, вот результат». Всё это приходится обкладывать проверками и ретраями.

Что значит «модель системы 1»

Название отсылает к Даниэлю Канеману и его двум системам мышления. Система 2 это медленное осознанное рассуждение: так человек считает налог или выбирает ипотеку. Система 1 это быстрые автоматические реакции: узнать знакомое лицо, понять по тону, что собеседник раздражён, отдёрнуть руку.

Вся индустрия последние годы строила системы 2: цепочки рассуждений, agentic-циклы, модели, которые «думают подольше и отвечают получше». Jev идёт в другую сторону. Ей запрещена скрытая цепочка рассуждений вообще. Сложное поведение предлагается собирать не из длинных размышлений, а из множества простых быстрых решений, как это делает нервная система.

Практический смысл в том, что 80 процентов решений внутри бизнес-процессов это именно система 1. «Это заявка или спам», «срочно или подождёт», «какому отделу отдать», «этот товар относится к категории А или Б». Гонять такие вопросы через модель, которая умеет писать стихи, всё равно что вызывать грузовик, чтобы перевезти папку с документами.

Как устроено принятие решения

Технически Jev это трансформер, но не языковая модель. Компания говорит о новой архитектуре (детали не раскрывает), параллельном сэмплере и собственном методе обучения RLCD: Reinforcement Learning for Calibrated Decisions, обучение с подкреплением под калиброванные решения.

Отличие от привычного RLHF принципиальное. RLHF оптимизирует «чтобы человеку понравилось» и, по словам Алмейды, приводит к схлопыванию режима: модель становится чрезмерно осторожной, теряет разнообразие и начинает отказываться. RLCD оптимизирует эпистемически честную вероятность. Если модель говорит 0,7, то примерно в семи случаях из десяти она должна оказаться права. Это и называется калибровкой, и именно её обычным моделям не хватает: там 0,9 и 0,6 часто означают одно и то же.

Ещё два решения, которые стоит знать:

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

Публичных бенчмарков компания не публикует. Позиция Алмейды: смотрите на свою задачу и свои данные, а не на чужие таблицы. Для нас это означает простое: любой заявленный выигрыш проверяем сами.

Три типа вопросов

Весь интерфейс модели состоит из трёх примитивов. Они комбинируются: в одном запросе можно задать сразу несколько вопросов, и все они считаются параллельно.

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

Как выглядит запрос и ответ

У API один рабочий эндпоинт, и тело запроса состоит из трёх полей: state (что оцениваем), model (какая версия) и questions (какие решения нужны). Вот живой пример: входящее обращение из формы на сайте, и нам надо понять, кому его отдать и насколько оно горит.

curl https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-1.13.0",
    "state": "Третий день не проходит оплата заказа, клиент ждёт.",
    "questions": {
      "otdel": {
        "type": "choice",
        "instructions": "Какой отдел должен взять обращение?",
        "criteria": {
          "oplata": "Платежи, счета, возвраты",
          "tehpodderzhka": "Ошибки сайта и интеграций",
          "prodazhi": "Цены, условия, новый заказ"
        }
      },
      "srochno": {
        "type": "noul",
        "instructions": "Клиент прямо сейчас теряет деньги"
      }
    }
  }'

Ответ приходит сразу в том виде, в котором его можно положить в переменную:

{
  "model": "jev-1.13.0",
  "answers": {
    "otdel": {
      "type": "choice",
      "choice": "tehpodderzhka",
      "confidence": 0.75,
      "probabilities": { "tehpodderzhka": 0.84, "oplata": 0.16, "prodazhi": 0.0 }
    },
    "srochno": { "type": "noul", "noul": 0.91 }
  },
  "usage": { "input_tokens": 423, "output_tokens": 73 }
}

Дальше это обычный код: если confidence выше вашего порога, заявка уходит в нужный отдел автоматически, если ниже, она падает человеку на проверку. Никакого разбора текста, никаких регулярных выражений.

Кроме собственного API модель доступна через OpenRouter, эндпоинт /api/alpha/decisions, идентификатор модели typesafe/jev-1.13. Это удобнее, если у вас уже есть аккаунт и не хочется ждать очереди раннего доступа.

Скорость, цена, лимиты

По замерам разработчиков тысяча решений в задаче классификации с восемью вариантами обходится примерно в полтора цента. В сравнениях с GPT-5.6 Terra компания заявляет выигрыш почти в 200 раз по цене и более чем в 400 раз по скорости. Цифры внутренние, но порядок понятен и без них: модель не генерирует текст, а значит не платит за самую дорогую часть работы.

Семь сценариев для бизнеса

Правило отбора задачи простое: решение должно быть простым, повторяемым и с заранее известным набором ответов. Чем чаще оно принимается, тем больше выигрыш. Вот где это работает прямо сейчас.

1. Маршрутизация обращений. Заявка с сайта, письмо, сообщение в мессенджере, комментарий. Модель определяет отдел, тему и срочность за треть секунды, и обращение сразу уходит нужному человеку. Для компании с несколькими направлениями это снимает с администратора всю сортировку.

2. Квалификация лидов и отсев мусора. Целевой или нет, горячий или холодный, спам или живой человек. Ответ приходит числом, а не словами, поэтому порог отсечения вы настраиваете один раз и потом двигаете по факту, а не на ощупь.

3. Разбор звонков. Расшифровку по-прежнему делает speech-to-text, но дальше начинается набор типовых решений: тема обращения, стадия воронки, записался клиент или нет, был ли менеджер вежлив, назвал ли цену. Это ровно choice и score. На сотнях звонков в месяц разница в цене и скорости против обычной модели становится заметной.

4. Модерация и реакция в соцсетях. Комментарий под постом: вопрос о цене, жалоба, спам, нейтральное одобрение. Решение принимается быстрее, чем человек успевает открыть вкладку, и менеджера дёргают только там, где это нужно.

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

6. Товарные каталоги и фиды. Категория товара, цвет, соответствие справочнику маркетплейса. Ограничение в 255 вариантов покрывает большинство реальных классификаторов, а для больших справочников задача разбивается на два шага: сначала группа, потом подкатегория.

7. Обвязка ИИ-агентов. Выбор инструмента, выбор навыка, проверка входов и выходов другой модели на опасное содержимое. Сюда же относится управление браузером: клики, переходы и прокрутку отдают быстрой модели, а рассуждения и проверку результата оставляют большой.

Считаем экономику

Возьмём реальную задачу: компания получает 30 000 обращений в месяц из всех каналов, каждое надо разметить по теме и срочности. Один запрос это примерно 300 токенов самого обращения плюс 200 токенов инструкций и вариантов, итого около 500 токенов.

30 000 × 500 = 15 млн входных токенов. При цене 0,042 доллара за миллион это 0,63 доллара в месяц. Выходные токены не тарифицируются. Суммарное время обработки при 300 мс на запрос: около двух с половиной часов машинного времени, которое при параллельных запросах превращается в минуты.

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

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

Где Jev не поможет

Модель не пишет строк вообще. Поэтому мимо:

• тексты, статьи, письма, описания товаров, ответы клиентам словами;
• чат-бот и голосовой помощник, любой диалог с человеком;
• задачи, где нужно объяснение, почему принято такое решение. Jev возвращает числа, а не аргументы, и это отмечают как главный вопрос к прозрачности;
• арифметика и работа с датами. Считать и сравнивать даты надо в коде, модель читает их как текст;
• всё, что требует творчества или незапланированного варианта ответа. Если правильного ответа нет в вашем списке, его не будет и в ответе модели.

Как начать за один вечер

Порядок, который я советую для любого внедрения такого рода:

Шаг 1. Выберите одну задачу. Одно решение, которое у вас принимается руками сотни раз в месяц. Не пять задач сразу.

Шаг 2. Соберите тестовую выборку. 100-200 реальных обращений или записей, где правильный ответ уже проставлен человеком. Без этого вы не сможете измерить качество, а значит и не узнаете, стоит ли внедрять.

Шаг 3. Получите ключ. Регистрация в консоли TypeSafe (ранний доступ идёт по очереди) или через OpenRouter, если аккаунт уже есть.

Шаг 4. Прогоните выборку и посчитайте точность. Отдельно посмотрите, как распределился confidence на верных и на ошибочных ответах. Это главный график всего внедрения.

Шаг 5. Настройте пороги. Рабочая схема из документации: уверенность от 0,9 и выше решение исполняется автоматически, от 0,5 до 0,9 показывается человеку как подсказка, ниже 0,5 уходит человеку без подсказки.

Шаг 6. Запускайте в режиме подсказки. Пару недель модель только советует, человек решает. Копится статистика расхождений, и уже на ней принимается решение об автоматизации.

Грабли внедрения

Часть из них авторы называют сами, часть вылезает у всех, кто внедряет автоматическую классификацию:

• Длинный state снижает точность. Подавайте только то, что нужно для решения, а не всю переписку целиком.
• Двойные отрицания в формулировках. «Не является ли это нецелевым обращением» модель поймёт плохо. Формулируйте прямо.
• Версию в продакшене надо пинить. jev-latest хорош для экспериментов, в рабочей системе ставьте точную версию вроде jev-1.13.0, иначе поведение однажды поменяется само.
• Варианты нужно описывать. Поле criteria принимает не только названия, но и пояснения к ним. Пояснения заметно влияют на качество.
• Ошибки API разделяйте. 429 и 529 повторяйте с нарастающей паузой, а 401 и 422 повторять бессмысленно, это ошибка в вашем запросе.
• Точность никогда не будет 100 процентов. Считайте заранее, во что обойдётся ошибка. Заявка, ушедшая не в тот отдел, это мелочь. Автоматический отказ клиенту это уже не мелочь.

Русский язык и персональные данные

Два вопроса, которые в англоязычных обзорах не поднимают, а для нас они решающие.

Русский язык. Отдельной поддержки в документации нет, заявлений о качестве на русском тоже. Это не значит, что модель его не понимает, но значит, что проверять надо на своих текстах. В моей практике разрыв между английским и русским на задачах классификации у разных моделей доходит до 10-15 процентных пунктов точности, и вслепую тут рассчитывать не на что.

Если данные вообще нельзя выпускать из контура, есть открытая локальная альтернатива: модель Laya на 421 млн параметров, тоже под структурированные решения. Работает менее чем в гигабайте памяти, запускается на ноутбуке и даже на телефоне, лежит на Hugging Face. По качеству она слабее облачной, но для простых бинарных решений внутри своего сервера этого часто достаточно.

Что это меняет

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

Для бизнеса вывод практический. Значительная часть того, что сегодня отдают большим моделям, это не задачи для большой модели. Разметка, сортировка, оценка, отсев. Если у вас такие операции идут потоком, связка «быстрая модель на решения плюс большая модель на текст» уже сейчас дешевле и отзывчивее любого монолитного варианта.

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