Влад Луцкий

Что такое Jev Пока вендор в этой категории один — TypeSafe, он же и главный разработчик. Модель залистили на OpenRouter 18 сентября 2026, модальность выхода в каталоге — decisions. Jev представляет класс моделей решений (decisions). На вход подается список вариантов и вопрос/критерии к ним. А, на выходе вероятности по каждому из элементов в зависимости от того на сколько хорошо элемент списка соостветствует критериям или отвечает на вопрос. Модель закрытая, контекст составляет 32 000 токенов, цена за вход — 0,042 $ за миллион токенов и бесплатный выход, которого по факту практически нет. Вопросы бывают трех типов — noul (булев), choice и score. Примеры выглядят так: Ответ приходит по тем же ключам, и главное в нем — распределение: Все это быстро и дешево: на моих замерах медиана вызова — 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 — ведь это прямо то, что нужно. Посчитаем, какие чанки валидны для запроса пользователя, а какие нет. И будто должно получиться дешевле. Что такое реранкер и где он стоит Реранкер в этой схеме работает валидатором: пересортировывает найденное и отсекает лишнее, чтобы не тащить в контекст LLM мусор. Путь запроса такой: 1. запрос пользователя; 2. query expander — разворачиваем запрос и убираем опечатки; 3. search — ищем блоки текста; 4. reranker — переранжируем блоки, чтобы оставить только валидные; 5. ответ — генерируем ответ пользователю. Пример кода использования Jev в пайплайне RAG: Еще до прогона видна деталь формата: вероятности возвращаются округленными до сотых, и если мерить релевантность бинарно — «релевантен/нерелевантен» — score принимает всего 100 возможных значений. На 20 документах tie score неизбежны, а при равных score такие документы будут попадать в LLM в случайном, относительно друг друга, порядке. Поэтому я сразу взял ординальный score-вопрос с четырьмя уровнями релевантности: score считается как математическое ожидание по распределению, и шкала расширяется до сотен уникальных значений — tie score становится вдвое с лишним меньше. Tie score — это когда двум документам модель выставила одинаковый score. Порядок между ними тогда не определен и решается тем, как отработала сортировка: обычно остается исходный порядок поиска. Чем грубее шкала, тем чаще такое случается и тем меньше от реранкера пользы. Округление никуда не делось и на ординальной шкале: одинаковые score получают около 17% документов против 42% на бинарной. Это уже терпимо, но держать в голове стоит. Как я мерил 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 не прыгнет никто. Метрикаbaselineqwen3-reranker-8bJevgemini-2.5-flashhit@10,680,820,800,80hit@30,820,880,920,90hit@50,860,880,920,90hit@100,880,900,940,92MRR0,7540,8560,8490,848NDCG@100,6710,6740,6830,700 Как читать таблицу, объясняю ниже. 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 вызовам каждого метода: qwen3-reranker-8bJevgemini-2.5-flash$/1000 запросов1,07 $0,33 $2,16 $p50595 мс418 мс2 129 мсp951 4605403 188p991 77697610 072max3 5671 23318 191 Jev дешевле Qwen в три раза, а LLM-промпта — в шесть раз. Абсолютные числа маленькие, и это важно для выводов дальше: экономия в 0,74 $ на тысячу запросов — реальная, но ее надо сравнивать не с ценой реранка, а с ценой всего запроса. Ортогональный сигнал Самое интересное, что я нашел, — попарные корреляции Спирмена между векторами score: Параρqwen ↔ gemini0,67Jev ↔ gemini0,37Jev ↔ qwen0,34 Qwen с Gemini согласуются на 0,67 — то есть делают похожие выводы, а Jev с кем угодно дает 0,34–0,37, он стоит особняком. Модель оценивает релевантность принципиально иначе: она не повторяет ошибки ни поиска, ни классических реранкеров. Туда же, вероятно, и ее чуть более высокий hit@10. Score, пороги и калибровка Реранкер можно использовать в двух режимах: сортировать чанки по score или фильтровать — выкидывать все, что ниже порога. С сортировкой все понятно, а вот можно ли по score отсекать массив чанков? Я прогнал каждый score как классификатор: чанк из ожидаемого документа — «релевантный», остальные — «нерелевантные» (50 вопросов × 20 чанков × 3 раунда 3 000 точек на метод). МетодAverage PrecisionПорог лучшего F1P / R на немJev0,6630,510,54 / 0,85gemini-2.5-flash0,562≈0 (тривиальный)0,48 / 0,94qwen3-reranker-8b0,553≈0 (тривиальный)0,45 / 1,00 Как читать таблицу: Порог лучшего 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, промпт один в один прод-промпт сервиса сборки контекста, судья не знает, какой метод оценивает. МетодJudge score (из 5)Δ vs baselinep (парный bootstrap)baseline (порядок поиска)3,96——Jev4,01+0,051,0qwen3-reranker-8b4,13+0,170,23gemini-2.5-flash4,26+0,300,023 Шум между двумя раундами одного и того же метода — средняя абсолютная разница оценки 0,32–0,42 балла, одинаковую оценку судья ставит в 62–70% случаев. Это сопоставимо с разницей между методами: Jev↔Qwen (0,12, p0,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-модель: РешениеТип ответаОткуда паттернНужен ли ретривchoice (yes/no/continue)Self-RAGРелевантен ли документnoulSelf-RAG, CRAGПодкреплен ли ответ источникамиchoice (full/partial/none)Self-RAGЧто делать при неуверенностиchoice (Correct/Incorrect/Ambiguous)CRAGКакая стратегия под сложность запросаchoiceAdaptive-RAGНужен ли еще hopnoulIRCoTВ какой источник идтиchoicerouting, RAGRouteКакой инструмент дернутьchoiceReAct 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-судейства. Оба маппинга реранкинга — и бинарный, и ординальный, на котором построена главная таблица, — лежат там целиком, так что любую строку можно пересчитать с нуля.

Влад Луцкий

Материалы автора

Как сэкономить инференс с помощью Jev

От ресерча до продакшена: когда использовать внешние модели, а когда self-hosted