Что такое Jev и почему это не очередной LLM-судья
Jev - модель от TypeSafe AI, и устроена она иначе, чем привычные языковые судьи. Компания LangChain поставила её в роль оценщика поведения AI-агента и сравнила с тремя LLM-судьями: GPT-5.6 Luna, GPT-5.6 Terra и Claude Sonnet 4.6. Ключевое отличие в том, что Jev не генерирует текст. Он принимает структурированное состояние и возвращает типизированные ответы вместе с вероятностями.
Результаты вышли заметными. Разброс оценок качества у Jev оказался в 92-913 раз ниже, чем у LLM-судей. Средний вызов длился 0,44 секунды и стоил $0,00035, а весь прогон обошёлся в $0,34 против $28,17 у Claude. Авторы сразу оговаривают: тест узкий и наблюдательный, результаты ранние, переносить их на произвольные агенты и продакшен-сценарии пока рано.
Дальше разберём, что стоит за цифрами, почему LLM-судья шумит и дорожает, и как такой оценщик встроить в собственный пайплайн эвалов.
System One vs генеративная LLM: в чём разница на уровне входа и выхода
System One-модели - это класс моделей, которые делают быстрые структурированные решения. Такая модель оценивает состояние и возвращает типизированные ответы и вероятности. Jev относится именно к этому классу: на выходе не текст, а поля с заданными типами и число уверенности для каждого варианта.
LLM-судья работает по-другому. Он принимает вопрос пользователя, трейс агента и доказательства как неструктурированный вход, а затем через промпт генерирует текстовую оценку. Такая конструкция недетерминирована по своей природе: один и тот же вход может дать разные формулировки и разные баллы.
Разницу удобно описать через аналогию. Jev ведёт себя как функция с типизированной сигнатурой: подали структуру, получили структуру. LLM-судья ближе к свободному тексту, который потом приходится разбирать регулярками или вторым вызовом модели. Подробнее про то, как Jev устроен и почему выходные варианты задаёт пользователь, мы писали в отдельном разборе модели.
Почему LangChain вообще взялась за этот эксперимент
Оценка агентов сегодня живёт в двух форматах: code-based и LLM-as-a-judge. У каждого свои ограничения. Кодовые проверки дешёвы, быстры и надёжны, но требуют детерминированных входов. Поведение агента стохастично, поэтому обычная функция уверенно отвечает лишь на узкий класс вопросов.
Пример из материала LangChain: функция легко проверит, вызвал ли агент инструмент при первом запуске. Сложнее оценить, использовал ли агент результат этого инструмента, чтобы ответить на вопрос пользователя. В открытой задаче может быть несколько допустимых способов применить один и тот же результат, и кодировать каждый вариант как детерминированную логику быстро становится нереально.
LLM-судья закрывает гибкость: он принимает неструктурированный трейс и рассуждает над ним. Цена гибкости - скорость, стоимость и нестабильность. LangChain искала третий путь и проверила Jev как кандидата в блоге LangChain.
Что именно показало сравнение Jev с GPT-5.6 Luna, Terra и Claude Sonnet 4.6
Материал LangChain вышел 20 сентября 2026 года. Судей сравнивали по трём измерениям: согласованность оценок, задержка и стоимость. Ниже то, что опубликовано, и то, каких выводов из этого делать не стоит.
Согласованность: почему разброс в 92-913 раз - это главный аргумент
Variance решает, работает ли метрика вообще. Если судья выдаёт разный балл на одном и том же трейсе, вы не отличите реальную регрессию агента от шума оценщика. Метрика перестаёт быть сигналом, а CI-пайплайн начинает падать или зеленеть случайным образом.
В эксперименте LangChain Jev оказался заметно стабильнее при непрерывном скоринге: разброс его оценок качества был в 92-913 раз ниже, чем у GPT-5.6 Luna, GPT-5.6 Terra и Claude Sonnet 4.6. Именно этот показатель авторы называют ключевым результатом.
Цифру 92-913x не стоит переносить на другие задачи. Она получена на конкретном наборе трейсов и конкретной схеме оценивания, а не в общем случае.
Скорость и цена: 0,44 с и $0,00035 против $28,17 у Claude
Jev оказался самым быстрым и дешёвым среди протестированных судей: в среднем 0,44 секунды и $0,00035 за вызов. Суммарно прогон на Jev стоил $0,34, тогда как на Claude Sonnet 4.6 - $28,17, то есть примерно в 83 раза дороже.
Арифметика на масштабе простая. При 10 000 прогонов Jev по измеренной цене обойдётся примерно в $3,50, и разница с LLM-судьёй растёт линейно. На больших объёмах LLM-судья становится узким местом и по бюджету, и по времени ожидания, особенно когда эвалы гоняются на каждый pull request.
Цифра 0,44 секунды - среднее по эксперименту LangChain на конкретной задаче, а не гарантия для любого сценария. Отдельно держите в голове заявления самого TypeSafe AI: по данным компании, Jev даёт до 200x более быстрый инференс и до 400x меньшую стоимость по сравнению с сопоставимыми LLM на задачах классификации. Это заявления вендора, а не независимо измеренные цифры.
Почему LLM-as-a-judge вообще нестабилен и дорог
Причина шума лежит в природе генеративной модели. LLM-судья сэмплит токены, поэтому один и тот же вход даёт разные формулировки, а вместе с ними и разные баллы. Добавьте чувствительность промпт-судьи к формулировкам: перестановка примеров или переписанный критерий способны сдвинуть распределение оценок.
Каждый прогон - это полноценный инференс большой модели, отсюда латентность и стоимость. Есть и третий источник ошибок, о котором забывают: выход судьи - свободный текст, который нужно распарсить в структуру. Модель может вернуть «7 из 10» с пояснением, а может просто «хорошо», и парсер ломается.
У LLM-судей есть сильная сторона, ради которой их и держат в пайплайнах: они принимают неструктурированный вход и умеют рассуждать над сложными критериями. Там, где нужен разбор открытого текста, они вне конкуренции. Кейс такого применения, с оценкой длинных исследовательских отчётов и ошибкой калибровки критериев, разобран в материале про Similarweb и LangSmith.
Где Jev встаёт между code-based evaluation и LLM-судьёй
Три подхода удобно сравнить в одной рамке.
| Подход | Вход | Выход | Сильные стороны | Ограничения |
|---|---|---|---|---|
| Code-based evaluation | Детерминированные данные | Флаг или число | Дёшево, быстро, воспроизводимо | Узкий класс задач с заданными входами |
| LLM-as-a-judge | Неструктурированный трейс, вопрос, доказательства | Свободный текст с оценкой | Гибкость, работа со сложными критериями | Недетерминирован, медленный, дорогой, требует парсинга |
| Jev (System One) | Структурированное состояние | Типизированный ответ с вероятностью | Стабильность, низкая цена, предсказуемый формат | Нужна схема состояния, узкая проверка в эксперименте |
По гибкости Jev ближе к LLM-судье, по предсказуемости - к коду. При этом он не заменяет кодовые проверки там, где задача детерминирована: если правило формулируется обычным условием, дешевле и надёжнее написать условие. И не заменяет LLM-судью там, где нужен свободный разбор неструктурированного текста. Это отдельный слой, который закрывает свой класс задач, а не универсальная замена.
Как встроить Jev-as-a-Judge в пайплайн оценки агента
Схема работы выглядит так: Jev принимает структурированное состояние и возвращает типизированный ответ с вероятностью. Значит, перед вызовом трейс агента нужно нормализовать в схему, а после - задать порог вероятности для бинарного решения.
Какие данные нужны на вход и что возвращает модель
Нужны две схемы. Первая описывает состояние: что именно из поведения агента вы подаёте на оценку. Вторая описывает ответ: какие поля и типы ожидаете получить. Конкретных полей и сигнатур в опубликованном материале LangChain нет, поэтому их состав придётся выводить из своей задачи.
Общий принцип простой: чем чище нормализован трейс, тем стабильнее оценка. Если в состояние попадает мусор, лишние поля или неполный контекст, судья будет ошибаться независимо от класса модели.
Как использовать вероятности вместо текстовых оценок
Вероятность даёт градуированный сигнал вместо бинарного «прошло/не прошло». Из него собирают гибридный подход: уверенные случаи закрываются автоматически по порогу, спорные уходят на ручной разбор или на дорогой LLM-судья как второй уровень проверки. Так стоимость остаётся низкой, а качество - под контролем.
Пороги - вопрос калибровки под конкретную задачу. Универсальных значений нет: на одной задаче 0,8 отсекает мусор, на другой тот же порог пропустит половину ошибок.
Встраивается такой судья в регрессионные тесты и CI так же, как обычный детерминированный чек: прогон на наборе трейсов, сравнение с порогом, падение сборки при выходе за границы. Оговорка: LangChain тестировала Jev на узкой задаче, поэтому схемы и пороги придётся подбирать под свой кейс, готовых рецептов в источнике нет.
Кому стоит смотреть на Jev, а кому пока рано
Смотреть в сторону Jev имеет смысл, если:
- у вас большой объём прогонов эвалов, и стоимость либо латентность LLM-судей уже бьют по бюджету и скорости CI;
- задача сводится к непрерывному скорингу или классификации поведения агента, а не к разбору свободного текста;
- вы готовы сами нормализовать трейсы в схему состояния и поддерживать эту схему.
Пока рано, если:
- нужен свободный текстовый разбор неструктурированных данных;
- нет ресурса на проектирование схемы состояния;
- вы ждёте готовое продакшен-решение с гарантиями.
Оговорка авторов звучит прямо: тест узкий, результаты ранние, переносить выводы на произвольные агенты и продакшен-сценарии пока рано, о чём сказано в публикации LangChain. Категоричной рекомендации «переходите на Jev» из этого материала не следует.
Что дальше: куда движется оценка агентов
Главный сигнал от LangChain не в том, что Jev победил. Появился третий путь между code-based проверками и LLM-as-a-judge: System One-модель с типизированным выходом и вероятностями, которая хорошо ложится в CI и регрессионные тесты.
Практический шаг: если у вас уже есть пайплайн эвалов и болит стоимость или разброс оценок LLM-судьи, поставьте небольшой эксперимент на своём датасете. Не переносите цифры LangChain напрямую, они получены в узком тесте на другой задаче. Сравните свой variance, цену и время на одном и том же наборе трейсов, прежде чем что-то менять в рабочем стеке. Как оценивать новые модели без шума вокруг релизов, разобрано в отдельном чек-листе.