В работе с моделями важно не только знать их точность, скорость и цену, но и понимать, где им можно доверять, а где нужна дополнительная проверка. Многие ограничения обнаруживаются уже в процессе интеграции — и о них хотелось бы знать заранее.
Тестирование Jev я проводил прежде всего для себя и команды, но объём данных получился масштабным, и я решил поделиться результатами с сообществом. С 19 по 30 сентября 2026 года было проведено 22 эксперимента и отправлено около 160 тысяч запросов к jev-1.13.0 и контрольным моделям OpenAI. Все тесты запускались через API раннего доступа и суммарно обошлись примерно в $18.
Мне было интересно не столько проверить заявленные скорость и цену, сколько найти границы её практического применения. Насколько она точна по сравнению с небольшими GPT-моделями? Можно ли доверять её confidence и строить на нём автоматический роутинг? Что произойдёт при расширении списка классов, появлении длинного контекста, грязного входа или текста на другом языке? У LLM уже известны свои особенности — например, lost in the middle и склонность уверенно ошибаться. Логично было проверить, есть ли собственный набор таких эффектов у System One модели на примере Jev.
Я не буду пересказывать базовое устройство Jev — подробные вводные статьи уже есть на Хабре, а детали API можно найти в документации. Ниже — серия практических проверок. Все цифры привязаны к конкретной версии модели и датам замеров, поэтому ключевая ценность статьи не в абсолютных процентах, а в обнаруженных закономерностях.
Минимум про устройство Jev
Jev не генерирует текст. На вход — текст (state) и набор вопросов к нему, на выход — ответ на каждый вопрос с распределением вероятностей. Типов вопросов три: choice (выбрать один вариант из списка), score (оценить по шкале уровней) и noul (да/нет в виде одной вероятности). Для choice задаются классы и их описания на естественном языке — это и есть вся «настройка».
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": "typed it wrong too many times at the atm and now its locked, how do i fix", "questions": { "intent": { "type": "choice", "instructions": "What is the customer asking about?", "criteria": { "pin": "Problems with the card PIN: forgotten, blocked, needs changing", "transfer": "Sending money, a transfer that failed or is delayed", "support": "Anything else that needs a human agent" } } } }'
В ответе для каждого вопроса — выбранный вариант, confidence и распределение probabilities по всем вариантам (структура сокращена, значения условные):
{ "answers": { "intent": { "choice": "pin", "confidence": 0.98, "probabilities": {"pin": 0.99, "transfer": 0.0, "support": 0.01} } }, "usage": {"input_tokens": 212} }
Платится только вход: $0.042 за миллион входных токенов, выход бесплатен.
TL;DR
Точность Jev — на уровне gpt-4.1-mini, если обеим моделям дать только описания классов. При этом Jev в 2.4 раза быстрее и в 5 раз дешевле.
Главное отличие — калибровка. Один и тот же порог по значению уверенности у Jev отсекает ошибки, у GPT почти не отсекает: 83% ошибок gpt-4.1-mini сделаны с уверенностью выше 0.9, у Jev — 29%. Упорядочивает ответы по риску GPT не хуже — порог для него приходится подбирать по доле трафика, а не по значению.
Порог нельзя переносить между схемами. Добавили классов — тот же порог пропускает больше ошибок.
Сорок вопросов к одному тексту — почти за время одного и до 86% дешевле, чем задавать их по одному.
Качество описаний классов сравнимо по эффекту с выбором модели. С описаниями имя метки почти не влияет на точность, без них — решает всё.
Токены Jev — не токены LLM. Тот же запрос стоит вдвое больше токенов, чем у GPT, русский текст — втрое дороже английского.
Посторонний текст вредит сразу, а не у лимита контекста, и Jev чувствительнее к нему, чем GPT.
Мусор во входе опасен не объёмом, а содержанием: цитата письма тянет ответы в «почтовый» класс.
Для чужого входа явный класс
otherв разы лучше порога.С несколькими сотнями размеченных примеров (около 16 на класс) обычный обученный классификатор Jev догоняет.
Как читать числа
Статья опирается на статистику, но почти вся она сводится к нескольким понятиям:
Точность — доля верных ответов (accuracy): 90% значит, что модель угадала класс в 90 примерах из 100.
п.п., процентные пункты — разница между двумя процентами. Было 90%, стало 87% — это минус 3 п.п. (а не минус 3%).
Интервал в квадратных скобках, например −4.1 [−6.3; −2.0], — 95% доверительный интервал: диапазон значений, с которыми согласуются данные. Если он целиком по одну сторону от нуля, разница есть. Если накрывает ноль, показать разницу не удалось.
p — насколько необычной была бы такая разница, если бы на самом деле её не было. Чем меньше p, тем сильнее довод, что разница настоящая; о том, велика ли она практически, p не говорит. «После поправки» — с учётом того, что гипотез проверялось много и какая-то из них могла «выстрелить» случайно.
«Не обнаружено» не значит «нет». Это значит, что данных не хватило различить. Поэтому рядом обычно стоит интервал: какой эффект данные ещё допускают.
Уверенность — число от 0 до 1, которое модель возвращает вместе с ответом. Порог — правило «ответы с уверенностью выше 0.9 принимаем автоматически, остальные — на дополнительную обработку». Принятые автоматически ответы дальше называются автопотоком.
Latency p50 / p95 — время ответа: половина запросов быстрее p50, 95% запросов быстрее p95.
Как я проводил замеры — коротко
Здесь — минимум, чтобы понимать, насколько верить числам.
Наборы данных.
набор | что это | классов | для чего |
|---|---|---|---|
банковская синтетика | 400 коротких обращений в банк, 30% лёгких / 45% средних / 25% трудных с лексическими ловушками | 10 | основное сравнение с GPT, длинный контекст |
banking77 | реальные обращения, срез 150 | 10 (24 метки сведены) | контроль переносимости |
MASSIVE (EN + 4 языка) | команды голосовому ассистенту | 10 и 30 | трудная задача, языки, схема, грязный вход |
BoolQ, Yelp | вопросы да/нет, отзывы | 2 и 5 уровней | типы вопросов |
Раскрытие. Банковскую синтетику, включая ловушки в трудных примерах, и примеры «банковского, но не по схеме» входа для раздела 10 написал Claude (Opus 5.5); остальные группы чужого входа — субагент на Claude Sonnet. Ни одна из сравниваемых моделей Anthropic не принадлежит. Самый сильный эффект длины контекста и почти всё преимущество Jev над классическими методами держатся именно на этой синтетике.
Правила, которые важны для чтения чисел:
все модели отвечают на одни и те же примеры, сравнение парное (тест Макнемара); при семье сравнений — поправка Холма;
«не значимо» значит «данных не хватило», и рядом всегда интервал: какой эффект данные ещё допускают;
единица наблюдения — пример: если один пример встречается в нескольких длинах, позициях или прогонах, эти ответы усредняются внутри него, а интервалы считаются бутстрэпом по примерам. Уверенность сравнивается парным Уилкоксоном, поправка Холма — внутри семьи сравнений одного эксперимента;
у модели есть собственный шум: два прогона одного и того же запроса расходятся в 0.47% меток. Доля изменившихся ответов сравнивается с этим шумом, а не с нулём;
GPT получал тот же список классов с теми же описаниями, structured output,
temperature = 0; уверенность GPT — вероятность токена-метки изtop_logprobs = 20на позиции первого токена значения метки, нормированная по классам схемы (до нормировки на классы приходилась практически вся масса вероятности: ниже 0.99 — у 0.25% ответов gpt-4.1-nano и ни у одного ответа gpt-4.1-mini). Это один из способов оценить уверенность GPT, а не единственный: просьбу к модели оценить себя или согласие нескольких ответов я не проверял.
Если строите роутинг на GPT. Таким способом — по первому токену метки — вероятности классов можно снять, только если метки различаются уже первым токеном. Метки
lightsoff,lightscolorиlightsonделят первый токен, и на такой схеме уверенность по классам не отделить. Для сравнения калибровки на 30 классах пять меток пришлось переименовать; с описаниями имя метки на результат не влияет (раздел 5).
1. Точность, скорость, цена
Почему именно эти модели OpenAI. У Jev есть confidence, и для сравнения мне нужны были модели с индикатором уверенности — если не таким же, то хотя бы близким. Поэтому я выбрал неризонинговые модели с доступными logprobs: по ним можно оценить вероятности классов и использовать их как индикатор уверенности. Я начал с gpt-4.1-nano и двигался вверх по линейке, пока не увидел ясную границу. Начиная с gpt-5-*, модели у OpenAI рассуждающие и logprobs не отдают, а разделение по калибровке проявилось уже до gpt-5-mini. Её я взял в качестве одной из контрольных точек по точности; дальше перебирать не было смысла.
Первая задача — короткие обращения клиентов банка на английском, 10 классов (перевод, PIN, доставка карты и т.п.), 400 синтетических примеров. Всем моделям я давал только список классов с описаниями, без примеров (так называемый zero-shot):
Jev | gpt-4.1-nano | gpt-4.1-mini | gpt-5-mini | |
|---|---|---|---|---|
точность | 97.8% | 93.5% | 97.0% | 98.8% |
разница с Jev | — | Jev лучше (p = 0.0009) | не обнаружена | не обнаружена |
время ответа p50 / p95 | 346 / 437 мс | 898 / 1454 мс | 846 / 1259 мс | 2715 / 3443 мс |
$ за миллион классификаций | $23 | $29 | $118 | $275 |
Как читать строку «разница с Jev»: у gpt-4.1-nano отставание настоящее — при равном качестве моделей такой разрыв был бы крайне редок (p = 0.0009). У gpt-4.1-mini и gpt-5-mini цифры отличаются от Jev на 1 п.п. в разные стороны, но на 400 примерах такую разницу нельзя отличить от случайности: модели неразличимы, а не «равны».
Время ответа я измерял через OpenRouter у всех моделей, чтобы точка входа была общей, строго последовательно, с машины на Кипре; первые 5 запросов — прогрев, в статистику не шли. Отдельный замер чередующимися парами «через прокси / напрямую» дал разницу около 17 мс у Jev и около 214 мс у gpt-4.1-nano, так что таблица скорее занижает преимущество Jev. Цены — по тарифам на дату замера.
Где расходятся модели, видно по уровням трудности. На лёгких примерах все четыре дают 100%. На трудных — с ловушками вида «слово чужого класса, которое текст затем отрицает» — Jev 98%, gpt-4.1-mini 96%, gpt-4.1-nano 90%. Типичная ошибка GPT на таком примере:
«My transfer was blocked pending checks. I’m not asking about the transfer — I’m asking how to pass the checks»
gpt-4.1-nano и gpt-4.1-mini отвечают transfer с уверенностью 1.0 (верно — identity). Jev отвечает верно, а свои немногие ошибки делает на действительно неоднозначных текстах и с низкой уверенностью (0.31, 0.36, 0.53).
На banking77 ответы трёх наиболее точных моделей совпали на всех 150 примерах. Все три ошиблись на одних и тех же трёх примерах, которые при разборе оказались спорными метками самого набора.
Latency почти не зависит от длины входа ни у одной модели (у Jev 346 → 336 мс на длинном входе). Ожидание, что преимущество Jev вырастет на длинных текстах, не подтвердилось: оно постоянное.
Токенов Jev тратит вдвое больше (553 входных на запрос против 269 у GPT): весь блок описаний классов уходит во вход. И всё равно он самый дешёвый — цена за токен перекрывает разницу. Подробнее о токенах — в разделе 7.
На 10 классах задача упирается в потолок, поэтому главное сравнение повторено на трудной: 30 классов MASSIVE, 2400 примеров.
точность | разница с Jev | |
|---|---|---|
Jev | 89.3% | — |
gpt-4.1-mini | 89.5% | +0.2 п.п. — неотличимо от случайности |
gpt-4.1-nano | 82.5% | −6.8 п.п. — Jev уверенно лучше |
gpt-4.1-mini с подкрученным промптом | 90.4% | +1 п.п. — на грани различимости (p = 0.046) |
Про промпт. Подкрученный вариант — системный промпт и по одному примеру на класс, написан до прогона и после не правился. Он дал gpt-4.1-mini +0.88 п.п. [+0.17; +1.62]. Сравнение при этом асимметрично в пользу GPT: Jev никто не подкручивал, его аналог промпт-инжиниринга — описания классов, и они у обеих сторон одинаковые.
Вывод. Jev стоит на уровне gpt-4.1-mini по точности, будучи в 2.4 раза быстрее и в 5 раз дешевле. Граница применимости: zero-shot, structured output. На банковской задаче наибольшую точечную оценку дала gpt-5-mini, но разница с Jev не значима, а стоит она в 12 раз дороже. Для задач за пределами классификации — извлечение сущностей, обоснование, рассуждение — Jev по устройству не предназначен.
2. Калибровка — главное отличие
Точность — не всё. В реальных проектах важно, можно ли по ответу модели понять, что она ошибается: тогда уверенные ответы уходят в автопоток, а сомнительные — на дополнительную обработку.
Идеально откалиброванная модель ведёт себя так: из 100 ответов, которые она даёт с уверенностью 0.9, верны около 90. Тогда порог 0.9 значит именно то, что написано.
На лёгкой задаче (10 банковских классов) разница видна сразу:
порог 0.9 | трафика в автопоток | точность автопотока | ошибок с уверенностью > 0.9 |
|---|---|---|---|
Jev | 89.5% | 99.7% | 1 из 9 |
gpt-4.1-nano | 97.5% | 94.6% | 21 из 26 |
gpt-4.1-mini | 99.8% | 97.0% | 12 из 12 |
У gpt-4.1-mini, которая по точности идёт вровень с Jev, все двенадцать ошибок сделаны уверенно. Такие ошибки порогом 0.9 не отловить: они уходят в автопоток, выглядя как правильные.
Но на 10 классах у Jev всего 9 ошибок, поэтому я повторил проверку на трудной задаче, где точность Jev и gpt-4.1-mini совпала:
30 классов | ошибок | из них с уверенностью > 0.9 | порог 0.9: трафика в автопоток | точность автопотока |
|---|---|---|---|---|
Jev | 256 | 74 (29%) | 82.9% | 96.3% |
gpt-4.1-mini | 252 | 210 (83%) | 96.9% | 91.0% |
gpt-4.1-nano | 420 | 301 (72%) | 92.5% | 86.4% |
У gpt-4.1-mini 93% ответов приходят с уверенностью не ниже 0.99, и точность среди них — 92.9%. Порог по значению уверенности почти ничего не фильтрует. Подкрученный промпт этого не меняет: уверенных ошибок остаётся 81%.
Важная оговорка — что именно отличается. Если подбирать порог не по значению уверенности, а по доле трафика («отправляем на дополнительную обработку 20% самых сомнительных»), gpt-4.1-mini почти не уступает: если принимать автоматически 80% трафика, точность на нём 96.98% у Jev против 96.67% у GPT. То есть ранжирует примеры GPT не хуже. Отличается абсолютная калибровка: на этой выборке порог 0.9 у Jev отделял ошибки, а у GPT почти ничего не отделял. Порог по значению у Jev работает, но его всё равно надо подбирать на своих данных: confidence не вероятность (ниже), а в средней зоне Jev переоценивает себя (раздел 3). На картинке это видно: кривые Jev и gpt-4.1-mini лежат почти друг на друге, просто точки порогов у GPT сбиты в правый край.
У рассуждающих моделей (gpt-5-mini) вероятностей нет вообще: OpenAI отклоняет logprobs («logprobs are not supported with reasoning models», сентябрь 2026), и проверенный здесь способ роутинга к ним неприменим. Другие способы оценить уверенность — самооценку, согласие нескольких ответов — я не исследовал.
Что такое confidence у Jev
Это не вероятность. По документации вендора, confidence — статистика формы распределения probabilities: 1.0, когда вся масса на одном варианте, и тем ниже, чем равномернее распределение. Точной формулы в документации нет — есть лишь иллюстрация для трёх вариантов. По сохранённым ответам я восстановил общий вид: для choice confidence совпадает с (K·p_max − 1)/(K − 1), где K — число классов. Для 10 и 30 классов расхождение в среднем 0.001–0.003, это округление вероятностей до сотых.
Практические следствия:
шкала зависит от числа вариантов. При двух вариантах
confidence = 2·p_max − 1: заявленные 0.24 — этоp_maxоколо 0.62. На BoolQ 45 ответов из 600 пришли с уверенностью ниже 0.5 (в среднем 0.24), и верных среди них 53%. Выглядит как сильная недооценка себя, но почти целиком это шкала, а не модель. Читатьconfidenceкак вероятность нельзя ни в какую сторону;у двух третей ответов
confidenceравна ровно 1.0 (64–74% в зависимости от задачи). Порог может отсеять только ответы ниже единицы, а среди «единиц» модель ответы не упорядочивает: сравнивать их между собой бесполезно;у
noulполяconfidenceнет: ответ — сама вероятность (см. раздел 6);для сравнения с GPT честнее брать
p_max, а неconfidence. Я пересчитал: у Jev переоценка себя +4.9 п.п. вместо +4.5, уверенных ошибок 29.7% вместо 28.9%. Вывод не меняется.
3. Порог нельзя переносить между схемами
Самый практичный вывод серии — и тот, где первая формулировка оказалась неверной.
Сначала выглядело так: на 10 классах Jev скромничает, на 30 — переоценивает себя, «калибровка переворачивается». Проверка показала, что «скромничает» было свойством банковской синтетики, а не размера схемы. На MASSIVE Jev переоценивает себя и на 10 классах.
Правильный замер — одни и те же примеры со схемой из 30 классов и со схемой только из 10 «своих»:
10 классов | 30 классов | |
|---|---|---|
точность | 93.8% / 91.8% | 90.3% / 87.2% |
порог 0.9: трафика в автопоток | 88.5% / 85.1% | 83.8% / 78.6% |
порог 0.9: точность автопотока | 97.5% / 96.8% | 95.9% / 95.2% |
Два подмножества классов — «близкие» и «различимые» — через косую черту.
Механизм. При 30 классах часть ответов уходит в добавленные классы — либо в близких соседей (setmeeting → viewevents), либо в широкие классы-аттракторы (viewevents → factquestion). Точность падает на 3.6–4.6 п.п., а уверенность — вдвое меньше. Модель переоценивает себя сильнее ровно на ту величину, на которую новые классы забирают ошибки.
Насколько сильно. Возьмём ответы, в которых Jev не уверен полностью, но и не сомневается сильно, — с уверенностью от 0.5 до 0.99. На 30 классах фактическая точность в них на 11–14 п.п. ниже значения confidence: среди ответов с уверенностью 0.7–0.9 верных в среднем на 13 п.п. меньше, чем стоит в поле. Это не вероятностная калибровка в строгом смысле — confidence не вероятность. Но p_max всегда не меньше confidence, так что в пересчёте на вероятности разрыв только больше. Исправление трёх дефектных описаний (раздел 5) разрывы в средней зоне практически не изменило.
Способность ранжировать при этом сохраняется: на 30 классах порог по-прежнему управляет качеством автопотока — примерно от 90% до 98%. Дорожает автоматизация: за 98% приходится отправлять на дополнительную обработку больше трети трафика.
Вывод для интеграции: при каждом изменении схемы порог надо перекалибровывать на размеченной выборке. Тот же порог 0.9 после расширения схемы — тихая деградация автопотока примерно на 1.5 п.п.
4. Fan-out: сорок вопросов почти за время одного
В реальной задаче к одному обращению обычно больше одного вопроса: интент, срочность, тональность, язык, есть ли вопрос… Jev принимает их пачкой в одном запросе и, по заявлению вендора, считает параллельно. Я проверил это буквально.
k вопросов | пачкой p50 / p90 | теми же вопросами по одному | ускорение |
|---|---|---|---|
5 | 304 мс | 1551 мс | ×5 |
10 | 288 / 375 мс | 3140 мс | ×10.9 |
20 | 304 / 404 мс | ~6 с (расчёт) | ×20 |
40 | 346 / 575 мс | ~12 с (расчёт) | ×35 |
Latency не растёт до k = 20. На сорока медиана подрастает на 17%, 90-й перцентиль — в полтора раза: это первый признак предела. Но и сорок вопросов пачкой (346 мс) отвечают почти вдвое быстрее, чем два вопроса подряд (619 мс). Последовательная ветка для 20 и 40 посчитана по времени одиночного запроса (295–315 мс при любом k, проверено замером до k = 10).
Деньги. state оплачивается один раз, а каждый следующий вопрос стоит только свою схему:
вопрос | предельная цена |
|---|---|
| +217 токенов |
| +52 |
| +43 |
Предельная цена не растёт с размером пачки: +49…+68 токенов за дешёвый вопрос и на десяти, и на сорока. Отсюда экономия растёт с длиной текста:
к короткой фразе | к письму в 2000 символов | |
|---|---|---|
2 вопроса | 12.5% | 23.3% |
5 вопросов | 34.7% | 53.3% |
40 вопросов | 74% | 86% |
Сорок вопросов к письму пачкой — 4334 токена против 32 062 по одному, то есть $182 против $1347 на миллион писем.
Ответы не меняются. В пачках до пяти вопросов все пять ответов совпали с ответами на те же вопросы по одному — в пределах собственного шума модели. В больших пачках проверялся основной вопрос: его точность 90.0–90.2% против 90.0% в одиночном запросе. И все 1800 запросов с k = 10…40 вернули полный набор ответов — усечения нет. Верны ли ответы на остальные 39 вопросов и не изменились ли они, в больших пачках не проверялось.
Практически: дешёвый вопрос стоит ~50 токенов и почти ноль миллисекунд (до 20 вопросов в пачке). Вопросы, которые «не настолько важны, чтобы за них платить», теперь окупаются.
Ограничения: проверено в один поток — под параллельной нагрузкой меряется очередь провайдера, а не модель. Проверена одна тяжёлая схема и 39 дешёвых вопросов; сорок схем по 30 классов упёрлись бы в лимит контекста. У 39 из 40 вопросов нет золотой разметки: в больших пачках проверена стабильность только основного вопроса.
5. Схема: описания, имена, порядок
Описания классов влияют не меньше выбора модели
В схеме из 30 классов у трёх описаний нашлись дефекты — они не соответствовали фактическому содержанию интентов в данных:
в
lightscolorбыла записана яркость, хотя тексты про яркость в MASSIVE лежат в интенте включения света;граница
defquestionсfactquestionбыла сформулирована нечётко;musiclikeописан как «выражение предпочтения», а реальные тексты — это просьбы сохранить мнение о песне.
Во всех трёх случаях модель отвечала логично: расходились мои описания, а не её ответы. Исправление на тех же примерах:
до | после | |
|---|---|---|
точность | 86.7% | 90.2% (+3.5 п.п., p = 5e-5) |
класс | 15% | 95% |
класс | 60% | 85% |
Оговорка: исправления проверены на той же выборке, на которой найдены дефекты, — это оценка эффекта правки, а не независимая оценка исправленной схемы. Перенос прироста на новую выборку отдельно не проверялся.
Три исправленных описания из тридцати дали столько же, сколько переход с gpt-4.1-nano на gpt-4.1-mini на банковской задаче (там разница тоже 3.5 п.п.), — а он стоит впятеро дороже.
И улучшилась не только точность, но и роутинг: доля ошибок, остающихся в автопотоке, в среднем по всем порогам стала примерно вдвое меньше (площадь под кривой risk-coverage). От описаний зависит и то, насколько хорошо работает порог.
Нашёл дефекты только потому, что один класс дал аномальные 15%. Более мягкие расхождения себя так не выдают. Отсюда практический приём: смотреть поклассовую точность, а не только общую.
Что показала лестница вариантов:
описания нужны: без них, только по именам меток, 84.5%;
односложные заглушки хуже подробных описаний на 1.9 п.п. (проверено на 2400 примерах), зато экономят 770 токенов на запрос — $32 на миллион классификаций;
схема с тремя неверными описаниями не отличима от схемы без описаний вообще;
пересказ всех тридцати описаний другими словами изменил 8 ответов из 600 и точность не сдвинул: схема не хрупка к формулировкам как таковым. Но это один пересказ одного человека — регрессионную проверку при правке описаний он не отменяет.
Граница проходит между «описание есть и верно» и «его нет или оно неверно», а не между «хорошо написано» и «плохо».
Имя метки: без описаний решает всё, с описаниями — почти ничего
Какую роль играет само имя класса — snoozeinfo, alarm_query или bkw4? Я прогнал одну и ту же схему из 30 классов на 2400 примерах с четырьмя наборами имён: мои метки, исходные имена интентов MASSIVE, мои простые имена по схеме «домен_действие» (alarm_ask, calendar_add) и бессмысленные коды из согласных и цифр. Каждый набор — без описаний и с теми же описаниями.
С описаниями имя почти не влияет на общую точность, даже бессмысленное. Против моих меток при тех же описаниях: имена MASSIVE −0.15 п.п. [−0.73; +0.42], простые имена −0.38 [−0.85; +0.10], коды −0.19 [−0.75; +0.35]. Данные исключают сдвиг общей точности больше 1 п.п. в любую сторону. Уверенность тоже не сдвинулась. Отдельные классы это не страхует: musicinfo с кодом вместо имени потерял 13.8 п.п. (80 примеров) — похоже, имя подстраховывает класс с размытым описанием. Модель, которой вместо setmeeting дали bkw4, работает так же, если рядом написано, что это за класс.
Без описаний имя — это и есть описание. Коды без описаний дают 3.1% — случайное угадывание при 30 классах. Понятные имена лучше моих меток в среднем на 3 п.п., но среднее скрывает качели в обе стороны: у шести классов из тридцати разница не меньше 10 п.п. alarm_ask лучше snoozeinfo на 87.5 п.п., а calendar_add хуже setmeeting на 20.6. Угадать заранее, какое имя модель прочитает «правильно», нельзя. Некоторые классы держатся на одном имени почти идеально — sendmail, lightsoff, fxrate, droplistitem, mathquestion: без описаний они на 97–99 п.п. лучше кодов.
Показательный случай — snoozeinfo. Это имя я выбрал сам, переименовав интент alarm_query из MASSIVE. Без описаний переименование одной этой метки стоило классу 92 п.п.: в каждом из двух прогонов 4–5 верных ответов из 80 против 78 из 80. Ошибки уходят в showlist (95 из 160 ответов за оба прогона) и wakeup (36). С описаниями разницы нет вовсе: 78 из 80 в обоих вариантах, ни один пример не сменил правоту.
При конфликте имени и описания побеждает описание. Я переставил имена внутри групп близких классов, оставив описания на местах: класс «спросить про будильник» получил имя wakeup, и наоборот. Модель пошла за описанием в 89.5% ответов, за именем — в 1.9%; точность не изменилась в пределах 0.8 п.п. Цена конфликта — уверенность: она упала на 0.017, и доля ответов, не прошедших порог 0.9, выросла с 17.4% до 20.8%. Порог по уверенности такой конфликт заметит раньше, чем точность.
Практически: описания обязательны, а имена при них можно выбирать из соображений удобства — читаемости логов, стиля кода, коротких токенов. Но после переименования стоит проверить поклассовую точность. Без описаний имя приходится подбирать как описание, и результат непредсказуем.
Оговорки замера
Замер сделан на одном домене и одной схеме. Исходные имена интентов MASSIVE модель могла видеть при обучении. Если бы она их заучила, выигрыш этих имён был бы больше на train, чем на test. Без описаний он больше на train на +0.61 п.п. [−2.42; +3.58]: интервал накрывает ноль, так что заучивание не исключено, но и не показано. Без описаний уверенность с именами MASSIVE выше, чем с простыми именами, на 0.012. С описаниями поклассово выделяется только musicinfo (−13.8 п.п. с кодом вместо имени, 80 примеров, без поправки на множественность): его ошибки уходят в factquestion.
Порядок классов почти не влиял
Порядок ключей в criteria обычно никто не выбирает — классы попадают туда в том порядке, в каком их придумали. Четыре перестановки (обратный порядок, случайный, разнесение близких классов) меняют 1–2% ответов при собственном шуме модели 0.47%, но точность не двигают нигде: перевороты идут в обе стороны. Класс в начале схемы преимущества перед классом в конце не получает.
Гипотеза, что путаницу между близкими классами подогревает их соседство в схеме, не подтвердилась: условие, разносившее близкие классы максимально далеко, дало наименьшее расхождение.
Самый широкий класс — аттрактор ошибок
Ошибки стекаются в классы с самой общей формулировкой: на 30 классах — в factquestion (121 ошибка), lightscolor (75), defquestion (63); в банковской схеме под давлением длинного контекста — в malfunction. Это стоит учитывать при проектировании схемы: широкий класс «про всё» будет собирать чужой трафик.
6. Типы вопросов: на проверенных задачах тип менял качество слабо
У Jev три типа вопросов. Сравнение построено так, чтобы payload отличался только типом:
метрика качества | вывод | |
|---|---|---|
BoolQ, | 91.7% против 91.2% | различить не удалось |
Yelp, | средняя ошибка 0.389 против 0.399 звезды |
|
Специальный тип качества почти не добавляет. Важнее форма ответа:
noulвозвращает не булев ответ, а одно число — вероятность ответа «да»; уверенность в ответе «нет» — это1 − p. На BoolQ это число оказалось хорошо откалиброванным: среди ответов 0.95–1.00 верных 99.3%, среди 0.60–0.70 — 68%. В среднем заявленное число отличается от фактической доли верных на 3 п.п. Порог по самому ответу — готовая ручка роутинга.scoreвозвращает матожидание уровня, а не выбор. Оно тянется к середине шкалы (единицы завышаются до 1.16, пятёрки занижаются до 4.83), причём одинаково уscoreиchoice— это свойство распределения модели. Нужна звезда — берите максимум распределения; нужна метрика потока — матожидание.Устойчивость к повтору различается. Два одинаковых запроса расходятся у
noulна 0 примерах из 600, уchoiceна 2–4, уscoreна 18: дискретный ответscore— это максимум распределения, и на плоском распределении он прыгает сам по себе.
7. Токены Jev — не токены LLM
У Jev собственная токенизация, и привычная интуиция «32k токенов — это примерно столько-то текста» здесь обманывает.
Тот же запрос стоит вдвое больше токенов. Классификация короткого банковского обращения: 553 входных токена у Jev против 269 у gpt-4.1-*. Большую часть съедает схема: 10 классов с описаниями — 536 токенов, 30 классов — 1511 (запрос дорожает в 2.8 раза). Токены между вендорами несопоставимы — сравнивать надо деньги за классификацию.
Граница — около 33 тыс. входных токенов суммарно, то есть ~32.5 тыс. на
stateза вычетом схемы. В английской прозе это ~148 тыс. символов, а в русском тексте, по коэффициенту ниже, — лишь около 45 тыс.Сколько символов в токене, сильно зависит от типа текста — от 4.6 у английской прозы до 1.4 у русского текста:
На коротких входах язык почти не влияет на цену: 536 токенов у английского против 538–539 у других языков — доминирует схема.
В моих замерах токенизация линейна (R² = 0.99997, без изломов), и
input_tokensрастёт монотонно до самой границы — плато нет.Тихого усечения я не нашёл. Все проверенные запросы сверх лимита вернули честную ошибку
HTTP 400max_tokens_exceeded, а не обрезанный вход.Структурированный вход почти бесплатен: JSON-объект в
stateдороже строки на 0.6%, массив — на 1.7%.
8. Длинный контекст: вредит сразу, а не у лимита
Вендор честно пишет, что Jev подвержен context rot («Accuracy falls as the state grows with content unrelated to the decision»), но без цифр и методологии, а позиционные эффекты не обсуждает вовсе. Я взял 280 банковских обращений средней и высокой трудности и обернул каждое в нерелевантный английский текст — природа, история, кулинария, без банковской лексики. Текст у каждого примера свой и собран из целых предложений. Длины — от 700 символов (примерно одна подпись письма) до 145 000 (у границы контекста). Само обращение ставилось в начало, в середину или в конец. Jev прогнан дважды, контроль — gpt-4.1-mini на тех же входах байт в байт, до 40 000 символов.
Что здесь называется обращением. Короткое сообщение клиента банка — одна-две фразы, по которым модель должна определить класс. Например, «typed it wrong too many times at the atm and now its locked, how do i fix» — класс
pin. Это вся информация, нужная для ответа. Всё остальное вstate— наполнитель: связный английский текст, не имеющий отношения к задаче. Так моделируется реальный вход, где нужная фраза тонет в подписи, цитате переписки или истории диалога.
Точность, среднее по двум прогонам Jev:
наполнитель, символов | обращение в начале | в середине | в конце |
|---|---|---|---|
0 (база) | 96.8% | ||
700 | 94.1% | 92.0% | 92.1% |
2 000 | 93.2% | 90.4% | 92.7% |
10 000 | 91.6% | 91.4% | 93.0% |
40 000 | 91.1% | 90.0% | 91.4% |
145 000 | 91.8% | 88.4% | 91.8% |
Вред виден сразу. Уже 700 символов нерелевантного текста стоят Jev 4 п.п. точности (−4.05 [−6.25; −1.96]). Дальше вред по точечным оценкам растёт медленно — до −6.1 п.п. на 145 000 символов, но интервалы по длинам почти целиком перекрываются. Порога «после N токенов становится плохо» нет: плохо становится на первой же подписи.
У gpt-4.1-mini вред не обнаружен ни на одной длине. В среднем по ячейкам 2 000–40 000: Jev −5.1 п.п., GPT −0.5 п.п. [−2.0; +1.0], разность −4.6 п.п. [−7.4; −2.0], p = 0.004 после поправки на множественность.
Практически: чистка входа важнее беспокойства о лимите контекста. Лимит Jev честный (раздел 7), а вред от постороннего текста начинается задолго до него.
Граница применимости — трудные тексты. Отдельный замер показал, что у лёгких примеров того же домена падения нет вовсе — ни одной смены ответа на 120 примерах. На коротких командах MASSIVE потерь тоже не обнаружено до 3000 символов (больше ~2 п.п. исключено) — ни при 10 классах, ни при 30. Трудные банковские примеры построены на лексических ловушках — словах чужого класса, которые текст затем отрицает («No fraud, no theft, no refund needed. Locked out by my own bad memory»). Правдоподобная, но не проверенная гипотеза: нерелевантный текст размывает это отрицание. Число «−5 п.п.» поэтому нельзя переносить на свою задачу — мерить надо на своей.
Позиция: начало лучше всего
У LLM известен эффект lost in the middle: информация в середине длинного контекста используется хуже, чем в начале и в конце, и точность по позиции рисует U-образную кривую (Liu et al., 2023, arXiv:2307.03172; PDF оригинала, PDF перевода на русский). Естественный вопрос — есть ли что-то подобное у System One-модели.
Уверенность Jev выше всего, когда обращение стоит в начале. Середина ниже начала на 0.033 [0.023; 0.045], конец — на 0.024; середина ниже конца на 0.009. Все различия значимы после поправки. Это не симметричная U-форма «середина хуже краёв», а скорее преимущество начала: primacy заметно сильнее recency.
По точности эффект позиции не установлен. У Jev середина хуже краёв на 1.8–1.9 п.п., но ни одно сравнение не переживает поправку на множественность; данные допускают эффект от нуля до ~4 п.п. У gpt-4.1-mini эффект середины по точности не обнаружен вовсе. Классический lost in the middle по точности на этой задаче я не увидел ни у одной модели.
Разница видна в хвосте. Если обращение в начале, порог 0.9 не проходят 20% ответов Jev; в середине и в конце — по 27%. У самых неуверенных 10% ответов уверенность ниже 0.72, 0.59 и 0.64 соответственно. Это те ответы, которые перестают проходить порог.
Практически: если формат входа позволяет, ставьте само обращение в начало state, а цитаты, подписи и историю переписки — после него, и проверьте точность автопотока на своём пороге. Уверенность так выше, но что дополнительно принятые ответы верны, по точности не установлено.
9. Грязный вход: опасен не объём, а содержание
В предыдущем разделе посторонний текст был нейтральным: природа, история, кулинария. В реальных системах мусор другой. Если классифицируются обращения из почты или чата, модель получает не только саму просьбу клиента, но и всё, что к ней прилипло. Письма приходят не в чистом виде: подпись, процитированный тред, HTML-обвязка рассылки, опечатки, эмодзи. Каждую порчу я сравнивал не только с чистым входом, но и с нейтральным текстом ровно той же длины — иначе замер повторил бы предыдущий раздел.
порча | против чистого входа | сверх своей длины | куда уходят сменившиеся ответы |
|---|---|---|---|
опечатки (12% букв) | −4.8 п.п. | — (длина та же) | |
цитата треда | −2.5 п.п. | −2.6 п.п., значимо | 89 из 125 — в |
HTML-обвязка | −1.9 п.п. | −1.4 п.п., значимо | 54 из 105 — в |
эмодзи | −1.7 п.п., на грани | — | |
подпись письма | −1.1 п.п. | не обнаружено (до 1.3 п.п.) | вразброс |
Столбец «против чистого входа» для опечаток, эмодзи и цитаты посчитан на 600 примерах, для HTML и подписи — на 1800; два правых столбца — везде на 1800.
Две разные картины. Нейтральный текст растаскивает ошибки в самые широкие классы схемы (defquestion, factquestion). А почтовый мусор вставляет конкурирующий интент: цитата и HTML выглядят как «речь о почте», и ответы уезжают в readmail.
Практически: чистить вход стоит не от лишнего объёма, а от фрагментов, похожих на какой-то класс вашей схемы. Цитата и HTML вредят здесь потому, что в схеме есть readmail и им есть на что быть похожими. Поэтому опасность конкретного мусора определяется не только им самим, но и набором классов: в схеме без почтового класса тот же HTML, вероятно, вредил бы иначе — это я не проверял.
Точность меняется мало, но меняется, куда уезжает ошибочный трафик. Если по распределению классов на потоке строится аналитика, счётчик readmail будет завышен за счёт писем с цитатой или HTML. Это отдельный риск, не видный по общей точности.
Опечатки — самая большая потеря в таблице, и они не добавляют ни одного лишнего символа: портится само обращение, а не его окружение. −4.8 п.п. — больше, чем у цитаты и HTML. Оговорка: в замере опечатка приходилась на 12% букв, это много для взрослого носителя языка; на реальном потоке потеря, скорее всего, меньше.
Уверенность замечает то, чего не видно по точности. На этой задаче нейтральный текст длиной до 3000 символов точность не сдвинул ни разу, а средняя уверенность падала монотонно на каждой длине: 0.947 → 0.931 → 0.931 → 0.928 → 0.928 → 0.927. То же повторялось во всех замерах серии, где вход портился (длина, позиция, язык, расширение схемы, мусор). Средняя уверенность на потоке — чувствительный индикатор того, что со входом что-то изменилось. Оговорки: это отчасти эффект мощности теста (непрерывная величина чувствительнее бинарной), и специфичность для мониторинга не измерена — обычный дрейф трафика тоже двигает среднюю.
10. Чужой вход: класс «другое» лучше порога
Схема заставляет выбрать один из классов. Что происходит с обращением, которое не подходит ни под один? Проверил на пяти группах: тот же банковский домен, но тема вне схемы (так чужой вход обычно и выглядит); другая область; бессмыслица; вырожденный вход («hi», «?», одна эмодзи); и контрольная группа неоднозначных, подходящих сразу под два класса.
Уверенность на чужом входе падает, и по ней чужое можно отделить от своего: качество такого разделения (AUROC, где 0.5 — угадывание, 1.0 — идеал) у Jev от 0.90 на близком чужом входе до 0.99 на вырожденном. Но явный класс ловит решительно лучше, при одинаковой цене в потерях на своих обращениях:
ловит чужой вход порогом | ловит классом | из них близкий чужой вход | |
|---|---|---|---|
Jev | 71% | 99% | 39 из 40 |
gpt-4.1-nano | 42% | 94% | 33 из 40 |
gpt-4.1-mini | 75% | 99% | 38 из 40 |
Общая цифра «99%» — среднее по четырём группам, три из которых очевидно чужие; для похожего на реальность случая — банковская тема вне схемы — смотрите последний столбец. Значимого падения точности на своих обращениях после добавления 11-го класса я не обнаружил; при этом 2.7% своих обращений Jev ошибочно отнёс к other.
Почему здесь порог у gpt-4.1-mini не хуже, чем у Jev, хотя в разделе 2 он у неё почти не работал. Это разные задачи: отличить чужой вход от своего — и отличить свою ошибку от своего верного ответа, причём одним и тем же числовым порогом. На чужом входе уверенность gpt-4.1-mini падает настолько, что срабатывает и фиксированный порог; на своих ошибках она в основном остаётся выше 0.9, и работает только порог по доле трафика (раздел 2). Результат одной задачи на другую не переносится.
11. Языки
Вендор пишет, что другие языки поддерживаются, но с более низкой точностью, — без цифр. MASSIVE — параллельный корпус, профессионально локализованный носителями, поэтому сравнение строго парное: один и тот же смысл на пяти языках.
язык | Jev | gpt-4.1-mini | потеря Jev к английскому | потеря gpt-4.1-mini |
|---|---|---|---|---|
en | 90.2% | 90.7% | — | — |
fr | 88.7% | 88.5% | −1.5 п.п., не значимо | −2.2 п.п. |
it | 87.8% | 86.3% | −2.3 п.п. | −4.3 п.п. |
de | 87.7% | 87.0% | −2.5 п.п. | −3.7 п.п. |
nl | 87.3% | 86.8% | −2.8 п.п. | −3.8 п.п. |
На четырёх проверенных языках потеря составила 1.5–2.8 п.п., но это не особенность Jev: gpt-4.1-mini теряет столько же, и языковые ошибки двух моделей падают на одни и те же предложения: если Jev ошибся на примере из-за языка, шансы, что там же ошибётся и GPT, в 25–71 раз выше обычных. По уверенности у Jev просели все четыре языка.
Язык описаний классов, похоже, не важен. На лёгкой задаче из 10 классов перевод схемы на язык текста не дал ничего ни по точности, ни по уверенности. Держать схему в одной английской версии — разумная отправная точка, но на трудной задаче это не перепроверялось.
12. Когда Jev не нужен
Такие задачи давно решают обученными классификаторами. Я сравнил с тремя классическими подходами. Обучались они на размеченных данных самих наборов, а не на ответах Jev.
Проверенные zero-shot альтернативы заметно уступают Jev: NLI (
bart-large-mnli) — 24–49%, косинус с описанием класса на эмбеддингах — 64–88%.Обученная классика на своём распределении Jev догоняет. На MASSIVE логистическая регрессия на
text-embedding-3-largeс подобранной регуляризацией (подбор кросс-валидацией на обучающем пуле; тестовые примеры в подборе не участвовали) сравнивается с Jev около 16 размеченных примеров на класс и обгоняет его на полном пуле: 91.5% против 89.6%. «16» — точка, где пересеклись кривые на этой задаче, а не гарантированный минимум разметки.На сдвинутом входе — нет. На банковской синтетике с ловушками те же методы дают 70–84% против 97.8% у Jev. На реальных banking77 обученный классификатор не хуже Jev.
Честная формулировка: преимущество Jev — zero-shot и устойчивость к сдвигу входа, а не «лучше обученного классификатора». Оговорка: «устойчивость к сдвигу» показана в основном на синтетике Claude с лексическими ловушками. Если у вас есть несколько сотен размеченных примеров того же распределения и вход не меняется, логистическая регрессия на эмбеддингах — дешёвая и сильная альтернатива. Fine-tuning трансформера не проверялся.
Почему нет открытых System One-моделей. После выхода Jev появилось около десятка моделей того же класса с открытыми весами — Laya, Nimble, Kev и другие. Я сознательно не включил их в сравнение: цель серии была практической — решить, что использовать нашей команде. Открытую модель пришлось бы хостить на собственном GPU, а при цене Jev около $23 за миллион классификаций для команды это экономически не оправдано. По той же причине я не стал бы предлагать хостить и сам Jev, будь его веса открыты. Логистическая регрессия на эмбеддингах, напротив, работает на CPU и обходится дёшево, поэтому она в сравнении есть. Я бегло проверил самую заметную из открытых моделей, Laya — у меня она уступала Jev. Это не замер, цифр не привожу. Причина отказа конкретно для нас — не в качестве, а в применимости.
13. Инфраструктура и мелочи
Пул соединений обязателен. TLS-рукопожатие до
api.typesafe.aiстоит ~430 мс из Европы (маршрут в США, ближнего узла нет). Прямой доступ с новым соединением на каждый запрос — 819 мс по медиане, с keep-alive — 309 мс. Без пула прямой доступ вдвое медленнее, чем через OpenRouter.Прямой API и OpenRouter дают одинаковые ответы; накладные расходы прокси для Jev +17 мс.
Модель почти детерминирована по меткам (0.47% расхождений между повторами), но не по уверенности: у 17–30% примеров она при повторе другая, местами 0.69 против 0.90. Не стройте логику на втором знаке.
Чек-лист интеграции
Пул соединений с keep-alive.
Описания классов — главный рычаг качества. Проверяйте поклассовую точность: класс с аномально низкой точностью — повод проверить его описание и разметку.
Описания обязательны: с ними имя метки можно выбирать из удобства, без них — нет. Широкий класс «про всё» будет собирать чужой трафик.
Для входа вне схемы — явный класс
other; порог оставьте для сомнительных ответов внутри схемы.Порог по
confidenceподбирайте на своей размеченной выборке — и заново при каждом изменении схемы.confidence— не вероятность, и её шкала зависит от числа классов.Все вопросы к одному тексту — одним запросом.
Попробуйте ставить само обращение в начало
state, цитаты и подписи — после: в моих тестах это повышало уверенность, выигрыш в точности не установлен.Из входа вырезайте фрагменты, похожие на другой класс вашей схемы (цитаты, HTML), а не просто «лишний текст».
Считайте бюджет в токенах Jev, а не LLM: русский текст втрое дороже английского.
Следите за средней уверенностью на потоке.
Есть сотни размеченных примеров стабильного распределения — сравните с логистической регрессией на эмбеддингах.
Как проверить на своих данных
Статья несколько раз говорит «мерить надо на своей задаче». Четыре приёма, которые в этой серии уберегли от неверных выводов:
Сначала пилот на 30–50 примерах. Если точность выше ~95%, эффекты в 1–2 п.п. на выборке в сотни примеров не будут видны: доверительный интервал окажется шире эффекта. Для сравнения вариантов между собой нужен либо набор больше, либо отдельный стресс-тест на трудных примерах; основную оценку при этом держите на выборке, похожей на рабочий поток.
Шум модели — несколькими прогонами, а не одной парой. Одна пара прогонов дала 0 расхождений из 600, шесть прогонов — 0.47%. И у каждого типа вопроса шум свой.
Качество уверенности — кривой risk-coverage, а не корреляцией. У gpt-4.1-mini корреляция уверенности с правотой 0.09 — почти ноль, — при AUROC 0.965: уверенность почти вся у 1.0, и линейная корреляция на таком распределении бессмысленна. По корреляции вывод получился бы обратным.
Поклассовая точность, а не только общая (раздел 5).
Чему не верить
Домены узкие: банковские обращения, голосовой ассистент, BoolQ, отзывы. На рабочем потоке — реальных письмах и чатах с их обвязкой — я не проверял.
Синтетика написана Claude — см. раскрытие выше.
Одна контрольная модель в большинстве сравнений (gpt-4.1-mini), один подкрученный промпт. Открытые System One-модели не сравнивались (раздел 12).
Latency привязана к географии (Кипр → США) и к нагрузке: на другой машине могут измениться и абсолютные миллисекунды, и соотношения между моделями.
Fan-out проверен в один поток.
Многие «не обнаружено» стоят на 600 примерах, где эффекты в 1–2 п.п. не разводятся. Это нехватка данных, а не отсутствие эффекта.
Порчи входа синтетические, собраны из шаблонов, а не из реальной почты.
Чистота схемы не гарантирована. Остальные 27 описаний проверены той же процедурой, которая в первой версии пропустила два дефекта из трёх.
Чужой вход — по 40 примеров на группу; класс
otherна другом распределении трафика не проверялся.«Jev теряет на языках меньше, чем GPT» — не результат. Направление совпало у всех четырёх языков, но разница не значима.
Версия модели одна —
jev-1.13.0; следующая может вести себя иначе.
Данные
MASSIVE — Amazon, CC BY 4.0.
banking77 — PolyAI, CC BY 4.0.
BoolQ — Google, CC BY-SA 3.0.
Yelp Reviews — по условиям Yelp Dataset; отзывы в статье не цитируются.
Скрипты, схемы, синтетические наборы и сырые ответы моделей планирую опубликовать позже.
