Разбор Jev — модели, которая не умеет писать

Утро началось с того, что ко мне в личку пришел друг и спросил: «Кто это такой, этот Jev? Ты работаешь с ИИ, должен знать».

К этому моменту я уже видел десятки постов в ленте о том, насколько он крут, какие задачи решает, и призывы переносить все свои флоу на Jev. Давайте разбираться.

Что такое Jev

Пока вендор в этой категории один — TypeSafe, он же и главный разработчик. Модель залистили на OpenRouter 18 сентября 2026, модальность выхода в каталоге — decisions.

Jev представляет класс моделей решений (decisions). На вход подается список вариантов и вопрос/критерии к ним. А, на выходе вероятности по каждому из элементов в зависимости от того на сколько хорошо элемент списка соостветствует критериям или отвечает на вопрос. Модель закрытая, контекст составляет 32 000 токенов, цена за вход — 0,042 $ за миллион токенов и бесплатный выход, которого по факту практически нет.

Вопросы бывают трех типов — noul (булев), choice и score. Примеры выглядят так:

// вопросы задаются словарем: ключ — имя решения, значение — критерии и тип
"is_bug": { criteria: {
    false: "Клиент задает вопрос или просит новую функциональность.",
    true:  "Клиент описывает поломку или неожиданное поведение продукта." },
  instructions: "Клиент сообщает о дефекте?", type: "noul" }
"team": { criteria: { "account": "Доступы, биллинг, учетная запись",
    "frontend": "Интерфейс, верстка, поведение в браузере",
    "payments": "Платежи, списания, возвраты" },
  instructions: "Какая команда должна забрать тикет?", type: "choice" }

"urgency": { criteria: [ "Может подождать следующего релиза",
    "Надо починить на этой неделе", "Прямо сейчас режет выручку" ],
  instructions: "Насколько срочный тикет?", type: "score" }

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

res.answers.is_bug.probabilities   // { false: 0.07, true: 0.93 }
res.answers.team.probabilities     // { account: 0.06, frontend: 0.11, payments: 0.83 }
res.answers.urgency.probabilities  // [ 0.12, 0.61, 0.27 ] — по уровням шкалы

Все это быстро и дешево: на моих замерах медиана вызова — 418 мс (с учетом прокси в виде OpenRouter), а 1 000 запросов стоит 33 цента. Числа и методику приведу ниже.

Дополнительно про модель

Это новый класс моделей, и метод обучения авторы описывают в анонсе как «Reinforcement Learning for Calibrated Decisions (RLCD)». Работу Jev можно эмулировать обычной LLM: попросить ее вернуть JSON с оценкой по каждому варианту. Получится то же самое по смыслу, но медленнее и дороже. 

Насколько именно, я померил в этой же статье: LLM-промпт на том же входе дал медиану 2 129 мс против 418 и 2,16 $ за 1 000 запросов против 0,33 $. Ответ приходит текстом, и его надо парсить - это может сломаться если LLM модель начнет галлюцинировать или сыпать артефактами. Придется посылать запрос заново что приведет к х2 по времени и х2 по затратам на LLM, класс Jev - архитектурно сделан так, чтобы избежать проблем.

Для каких задач

Где применять? Везде, где варианты известны заранее, но неизвестен правильный: классификация, роутинг, выбор из множества, гейты, оценка качества и другие похожие задачи.

В своих сценариях я думаю использовать его как быструю систему принятия решений, а LLM — как главный мозг. Модель на выходе дает вероятности, а это хороший инструмент, чтобы алгоритмически принимать решения: например, при a = 0,8 и b = 0,7 решение может отличаться от случая, когда a = 0,8 и b = 0,3. 

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

Вендор обещает разницу в десятки и сотни раз. У меня получилось скромнее, но в ту же сторону. На одной и той же задаче реранкинга медиана Jev — 418 мс против 2 129 мс у LLM с промптом, то есть впятеро, а по 99-му перцентилю — 976 мс против 10 секунд. Для realtime это разница между «успеваем» и «не успеваем», но счет идет на разы, а не на сотни раз (в измерение входят пинг и задержки OpenRouter).

За счет высокой скорости некоторые умельцы уже научили модель играть в Doom, змейку или T-Rex-игру из Chrome. Если передать текущий стейт игры и управление, то можно научить ее играть практически в любую игру. Для более сложных вариантов, скорее всего, понадобится LLM, чтобы задавать долгосрочный план.

В реальных задачах

Когда я увидел Jev, мне сразу в голову пришла идея заменить реранкер в моем RAG — ведь это прямо то, что нужно. Посчитаем, какие чанки валидны для запроса пользователя, а какие нет. И будто должно получиться дешевле.

Что такое реранкер и где он стоит

RAG (retrieval-augmented generation) — это когда модель отвечает не из весов, а по найденным в вашей базе кускам текста. 

Реранкер в этой схеме работает валидатором: пересортировывает найденное и отсекает лишнее, чтобы не тащить в контекст LLM мусор. 

Путь запроса такой:

1. запрос пользователя;

2. query expander — разворачиваем запрос и убираем опечатки;

3. search — ищем блоки текста;

4. reranker — переранжируем блоки, чтобы оставить только валидные;

5. ответ — генерируем ответ пользователю.

Пример кода использования Jev в пайплайне RAG:

const res = await client.alpha.decisions.create({
  model: '~typesafe/Jev-latest',
  state: { query, documents },        // 20 чанков одним куском
  questions: Object.fromEntries(
    documents.map((_, i) => [doc_${i}, {
      type: 'score',
      criteria: ['not relevant', 'weakly relevant', 'relevant', 'highly relevant'],
    }]),
  ),
});

const score = (i) => res.answers[doc_${i}].probabilities; // score = EV по уровням

Еще до прогона видна деталь формата: вероятности возвращаются округленными до сотых, и если мерить релевантность бинарно — «релевантен/нерелевантен» — score принимает всего 100 возможных значений.

На 20 документах tie score неизбежны, а при равных score такие документы будут попадать в LLM в случайном, относительно друг друга, порядке.

Поэтому я сразу взял ординальный score-вопрос с четырьмя уровнями релевантности: score считается как математическое ожидание по распределению, и шкала расширяется до сотен уникальных значений — tie score становится вдвое с лишним меньше.

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

Округление никуда не делось и на ординальной шкале: одинаковые score получают около 17% документов против 42% на бинарной. Это уже терпимо, но держать в голове стоит.

ИИ‑роутер — доступ к 300+ моделям из одной панели

Подключите OpenAI‑совместимый шлюз по единому API‑ключу. Настраивайте сквозную аналитику, отслеживайте лимиты и квотируйте ресурсы.

Запустить ИИ‑роутер →

Как я мерил

50 вопросов по публичной документации, у каждого вопроса один ожидаемый документ. Для каждого вопроса заготовлены топ-20 блоков из гибридного поиска, одни и те же для всех методов, — так что сравниваем мы реранкер, а не поиск. Четыре вызываемых конфигурации × 50 вопросов × 3 раунда = 600 вызовов.

Участники:

• qwen3-reranker-8b — кандидат под замену, нативный /rerank;

• Jev — Decisions API, вызовы шли через OpenRouter;

• gemini-2.5-flash с промптом «оцени релевантность каждого чанка, верни JSON» — в двух конфигурациях, с обрезкой документа до 2 000 и до 500 символов. В таблице ниже — вариант с 2 000; вариант с 500 оказался не хуже (и даже чуть лучше по MRR — 0,861), его числа есть в паке;

• baseline — исходный порядок поиска, без реранка. Вызовов не делает, поэтому в 600 не входит.

Реранкинг ложится на Decisions API двумя способами, и я померил оба. Бинарный choice-вопрос на документ — это основной прогон. Ординальный (порядковый) score-вопрос с четырьмя уровнями, про который я писал выше, — отдельные три раунда на тех же кандидатах. 

В таблице стоит ординальный, потому что именно его я и хочу использовать; бинарный на тех же данных дает hit@1 0,767 и MRR 0,830, то есть разницу внутри шума. Ординальный прогон — это еще 150 вызовов сверх 600. Оба лежат в паке целиком, пересчитать можно любой.

Потолок называю сразу: ожидаемый документ есть в кандидатах только у 47 вопросов из 50. Выше 0,94 по hit@10 не прыгнет никто.

Как читать таблицу, объясняю ниже.

hit@k — доля вопросов, где ожидаемый документ в первых k позициях. hit@1 — точность верхней строки, hit@10 — «не потеряли ли вовсе» (в топ-10 попадает то, что уедет в контекст LLM). Пример: Jev hit@10 = 0,94 — у 47 из 50 вопросов документ в десятке, это потолок набора.

MRR — среднее 1/позиция первого релевантного: нашел на 1-й — 1,0, на 3-й — 0,33. Чувствителен к высоте попадания, а не только к факту.

NDCG@10 — качество порядка всей десятки: чем выше релевантный документ, тем больше вклад. Важно, когда генератору важен весь контекст, а не одна верхняя строка.

baseline — порядок поиска без реранкера; главный ориентир, добавляет ли реранкер вообще (по hit@1 добавляет +0,12…+0,14, статистически значимо). Различия между реранкерами при 50 вопросах статистически незначимы: p по всем парам и метрикам лежит между 0,32 и 1,0.

Экономика и хвост латентности

Половина выводов дальше опирается на деньги и время, поэтому вот они — по тем же 150 вызовам каждого метода:

Jev дешевле Qwen в три раза, а LLM-промпта — в шесть раз. Абсолютные числа маленькие, и это важно для выводов дальше: экономия в 0,74 $ на тысячу запросов — реальная, но ее надо сравнивать не с ценой реранка, а с ценой всего запроса.

Ортогональный сигнал

Самое интересное, что я нашел, — попарные корреляции Спирмена между векторами score:

Корреляция Спирмена (ρ) — мера того, насколько совпадают два порядка. 1 — порядки совпадают полностью, 0 — связи между ними нет, −1 — они противоположны.

Qwen с Gemini согласуются на 0,67 — то есть делают похожие выводы, а Jev с кем угодно дает 0,34–0,37, он стоит особняком. Модель оценивает релевантность принципиально иначе: она не повторяет ошибки ни поиска, ни классических реранкеров. Туда же, вероятно, и ее чуть более высокий hit@10.

Score, пороги и калибровка

Реранкер можно использовать в двух режимах: сортировать чанки по score или фильтровать — выкидывать все, что ниже порога. С сортировкой все понятно, а вот можно ли по score отсекать массив чанков? Я прогнал каждый score как классификатор: чанк из ожидаемого документа — «релевантный», остальные — «нерелевантные» (50 вопросов × 20 чанков × 3 раунда = 3 000 точек на метод).

Как читать таблицу:

• Порог лучшего F1 — граница «score выше → считаем релевантным», подобранная так, чтобы точность (precision) и полнота (recall) были максимальны одновременно. Порог 0 у Qwen и Gemini значит: как ни отсекай чанки, лучше ничего не выкидывать;

• P / R на нем — точность и полнота на этом пороге. У Qwen recall 1,00 и precision 0,45 — это «пропустить все»: фильтр не работает;

• Average Precision — площадь под PR-кривой, качество score как «релевантен/нерелевантен» в целом, без выбора порога.

Вывод: у двух методов из трех порог лучшего F1 — около нуля. Единственная стратегия, которую подтверждает перебор порогов, — не фильтровать вовсе: их score годятся только как ключ сортировки. Score Jev — единственный, которым можно отсекать чанки.

Что это значит на практике. У нас порог фильтрации — 0,3, подобранный под шкалу обычного реранкера. Шкала Jev сдвинута вверх, поэтому 0,3 для нее ничего не значит: выше порога проходят почти все чанки — и релевантные, и мусор. Резать надо примерно посередине: в диапазоне 0,49–0,51. Но и там разделение скромное: релевантные чанки в среднем score 0,68, нерелевантные — 0,55. Разница невелика.

И про сами числа score. Честная ли это вероятность? Нет: ECE 0,170, Brier 0,245 — до «score 0,9 = девять из десяти релевантных» далеко. Score 0,97 реально означает релевантность примерно в 8 случаях из 10, в средней зоне (0,4–0,7) модель стабильно завышает. Вывод: сортировать по score — можно, верить абсолютному значению — нельзя.

Доходит ли это до пользователя

Ранжирование — не самоцель, поэтому финальный замер на реальных запросах: 4 метода × 50 вопросов × 2 раунда = 400 сгенерированных ответов и 400 слепых судейств по шкале 1–5. Контексты собраны репликой прод-логики из записанных score, промпт один в один прод-промпт сервиса сборки контекста, судья не знает, какой метод оценивает.

Шум между двумя раундами одного и того же метода — средняя абсолютная разница оценки 0,32–0,42 балла, одинаковую оценку судья ставит в 62–70% случаев. Это сопоставимо с разницей между методами: Jev↔Qwen (0,12, p=0,54) тонет в нем полностью. Значимо лучше baseline оказался только вариант с LLM-промптом — тот самый, который уже похоронен по цене.

Зато вот что видно отчетливо: когда ожидаемый документ доехал в контекст, оценка ответа 4,21–4,49, когда не доехал — 1,6–1,8. Разрыв около 2,6 балла, корреляция позиции первого нужного чанка с оценкой ответа −0,66…−0,80. Генератор соберет нормальный ответ и с третьей позиции; он не соберет никакого, если документа в контексте нет.

Вывод формулирую прямо: разница между реранкерами почти не доходит до пользователя. Выбор реранкера — решение про цену и хвост латентности, а не про качество ответов. Решает же то, доехал документ в контекст или нет, то есть recall поиска важнее тонкостей топ-1.

В прод?

Дешевле, быстрее, с таким же качеством как было — можно лить в прод? Думаю, пока не стоит спешить, конкретно на моей задаче с RAG:

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

Выигрыш реальный, но не той величины, чтобы окупить зависимость. Втрое дешевле — это 0,74 $ на 1 000 запросов, и только на шаге реранка. Реранк — не пренебрежимая часть запроса (на его вход уходит около 8 000 токенов против 4 500 на вход генерации), но и не та статья расходов, ради которой заводят зависимость от вендора на раннем доступе: доля экономии в цене всего запроса зависит от того, какой моделью вы генерируете ответ. Со временем та же история: по медиане выигрыш у реранка составляет 150 миллисекунд, и на фоне генерации ответа их не видно.

Юридическая рамка еще не готова к проду. Опубликованного SLA нет. Вместо него в Master Customer Agreement (далее MCA): «TYPESAFE не гарантирует, что использование Клиентом Сервисов будет бесперебойным или безошибочным. Сервисы предоставляются «КАК ЕСТЬ» (AS IS) и «ПО МЕРЕ ДОСТУПНОСТИ» (AS AVAILABLE).». Возможно, для энтерпрайза есть непубличный документ — публично его нет.

Право менять API прописано явно: «Такие изменения могут привести к несовместимости API.». Справедливости ради, там же вендор обязуется прилагать «коммерчески разумные усилия» к предупреждению заранее.

Хранение. «TypeSafe не несёт обязанности по хранению или удержанию Данных Клиента и вправе удалять Данные Клиента в любое время по своему единоличному усмотрению.». Срока хранения в privacy policy нет — только «в той мере, в какой это разумно необходимо».

Потолок ответственности — «БОЛЬШЕЕ ИЗ: (A) СУММЫ, УПЛАЧЕННОЙ… И (B) 50 ДОЛЛАРОВ США». Обратите внимание на конструкцию: 50 $ здесь не потолок, а пол, и для заметно платящего клиента реальный предел выше. Но если вы только пробуете — какой бы ущерб ни случился, вы получите пятьдесят долларов.

Хостинг только в США: «Сервисы размещаются на территории Соединенных Штатов Америки (США).». Для части компаний это самостоятельный стоп-фактор. Я не юрист, весь legal проверял нейронкой, но выглядит не очень хорошо, по крайней мере на данный момент.

Задачи, для которых Jev должен подойти лучше

Задачу для замеров я взял из своего текущего пайплайна — давайте подумаем, где Jev может раскрыться лучше.

Agentic RAG

В классическом RAG Jev конкурирует с реранкером. Но есть место, где его свойства могут раскрыться лучше — Agentic RAG. И почти в каждой точке нужно ровно то, что делает decision-модель:

• Self-RAG — модель сама решает, когда ходить в поиск, и оценивает релевантность найденного и подкрепленность своего ответа. Для этого ее дообучают на спецтокены рефлексии;

• CRAG (Corrective RAG) — перед генерацией score ретрива проверяется порогами: нашлось хорошо → отвечаем, плохо → переписываем запрос и ищем заново, неоднозначно → идем в веб-поиск;

• Adaptive-RAG — простые запросы идут коротким путем (один ретрив), сложные — многошаговым. Классификатор сложности выбирает стратегию заранее.

Такой контракт уже исследован — только «изнутри» модели. Self-RAG дообучает модель под спецтокены рефлексии (Retrieve ∈ {yes, no, continue}, IsRel ∈ {relevant, irrelevant}, IsSup ∈ {fully, partially, no support}) — это буквально choice и noul. CRAG пропускает score ретрива через два порога — Correct / Ambiguous / Incorrect. 

Decision-модель делает то же самое, но без дообучения и с вероятностью на выходе. А сегодня такая точка в цикле — вызов LLM с просьбой вернуть JSON: медленно, парсинг ломается (если принять ходовую отраслевую оценку в 97% успешных вызовов со схемой, то цикл из десяти шагов пройдет без единой ошибки валидации в 0,97¹⁰ ≈ 74% случаев).

Почему Jev тут может раскрыться: решений в цикле много, каждое на горячем пути — значит, важны плоская латентность и цена втрое ниже; дальше по коду ветвление, а не текст — значит, важен типизированный ответ. Это гипотеза которая приходит мне на ум — на практике нужно тестить.

Пак данных

Все, на чем построены числа выше, лежит в данных: golden set из 50 вопросов, кандидаты с исходными score поиска, 600 замеренных вызовов со score, латентностью и стоимостью, агрегаты, статистика, пять исследований модели и результаты E2E-судейства. Оба маппинга реранкинга — и бинарный, и ординальный, на котором построена главная таблица, — лежат там целиком, так что любую строку можно пересчитать с нуля.

Если пересчитаете и получите другое — напишите, мне интересно.