Авторы: @eddiedzhou, @mr_cheu, @MatZhao, @CosmicPegasis19, @manav_ai
Jev — это модель для принятия типизированных решений. Вы отправляете ей контекст вместе с фиксированным набором вопросов и вариантов, а она возвращает выборы, оценки и вероятности вместо генерации текста. Это модель «Системы 1»!
Но классификация — не новость, как и структурированные ответы, небольшие модели или чтение вероятностей из логитов. Эта история отчасти объясняет неоднозначную реакцию на Jev...
У скептиков есть весомые аргументы, но у Jev действительно есть своё место в этой экосистеме. Чтобы разобраться детальнее, стоит рассмотреть всё пространство возможных решений.
Какие есть альтернативы?
Когда системе нужна метка, оценка или ответ «да/нет», есть четыре разумных варианта:
Подход
Зачем использовать
Компромиссы
LLM общего назначения
Zero-shot, гибкость, может также генерировать аргументы или пояснения. Возможно, «более высокий интеллект» за счёт вычислений во время инференса (рассуждений).
Плата задержкой и стоимостью авторегрессионной модели за небольшое решение
Открытый zero-shot-классификатор
Дёшево, локально и под контролем
Нестабильное качество; выбор модели и её развёртывание лежат на вас
Дообученный классификатор
Обычно лучший вариант для стабильной высоконагруженной задачи с качественными разметками
Сбор данных, обучение, деплой, дрейф модели и менее гибкая таксономия
Jev
Гибкость zero-shot через удобный облачный API
Качество зависит от задачи, нет генерации текста, зависимость от провайдера
В чём сила Jev: команда может менять вопросы и варианты ответов без сбора нового обучающего датасета, избегая при этом всей рутины по грамотному развёртыванию модели. Отмахиваться от этого глупо. Фраза «мы могли бы сделать это сами» применима к большинству инфраструктурных продуктов.
Открытые реплики немного сбавляют пафос новизны. Реализации на базе Qwen и SGLang, DiffusionGemma и vLLM, а также Kev воспроизводят значительную часть API или архитектуры модели.
85,7% у Jev и 79,6% у Kev-8B на n=764
Внешние тесты Parallel также показали, что Jev конкурентоспособен в реранжировании, хотя специализированные модели всё же победили в двух задачах классификации.
Что мы увидели в Glean
Остаётся практический вопрос: когда связка zero-shot-гибкости и облачного инференса у Jev реально обходит альтернативы? Мы протестировали в Glean четыре ограниченных задачи принятия решений, где у нас уже был бейзлайн и можно было сравнить реальное корпоративное качество. Большинство этих бейзлайнов — системы на базе LLM, поэтому в таких экспериментах мы ожидаем улучшения стоимости и задержки на два порядка. Результаты варьировались от заметно худших, чем в продакшене, до более быстрых и точных по сравнению с LLM-маршрутизатором.
Классификация запросов
Классификация запросов сопоставляет запрос с общей задачей, которую используют нижестоящие системы. Это естественная нагрузка для Jev: хотя для каждого отдельного запроса пространство меток известно заранее, сама таксономия может меняться быстрее, чем переобучается классификатор.
В этом эксперименте мы сосредоточились на том, насколько предсказания Jev совпадают с нашим продакшен-бейзлайном на базе LLM. Мы ожидали и действительно увидели значительный рост офлайн-пропускной способности с Jev, поэтому используем процент совпадений как простой индикатор качества. Также мы сравнивали результаты с Laya — моделью принятия решений с открытыми весами — и с дообученной версией Laya. Дообучение заняло несколько часов на локальной машине, а сама модель достаточно мала, чтобы работать на компьютере разработчика.
Эксперимент
Совпадение по общим задачам
Производительность
Jev zero-shot
66,8%
~
12 мин (параллелизм 4
)
Базовая Laya
35,9%
~
90 с (локальная машина разработчика)
Дообученная Laya
74,5%
~
90 с (локальная машина разработчика)
Как готовое решение, не требующее обучения, Jev явно превосходит базовую Laya, но, что вполне ожидаемо, дообучение заставляет Laya сиять — особенно с учётом показателей производительности. Расплата за это — усилия на сбор хороших разметок и настройку обучения. Jev, скорее всего, останется привлекательнее, когда задача новая или её метки часто меняются.
Маршрутизация моделей: передача эксперту
Маршрутизация моделей — задача, родственная классификации запросов. Здесь мы рассматриваем её как передачу эксперту (expert transfer), когда система выбирает, какой эксперт или модель должен обработать запрос. Наш текущий продакшен-бейзлайн просит LLM принимать это решение нативно внутри агентного цикла. Хотя это отличная проверка того, может ли Jev заменить генеративный вызов ограниченным решением, важное техническое ограничение заключается в том, что при отказе от передачи Jev строго добавляет ещё один вызов. В отличие от продакшен-бейзлайна, который в таких случаях может начать работу с инструментами прямо в рамках того же первого вызова LLM.
Мы взяли упрощённую версию нашей продакшен-маршрутизации всего с 3 экспертами, прогнали 751 сопоставимый золотой пример через обновлённый маршрутизатор на Jev, сравнили выбранный им путь с нашим существующим промпт-маршрутизатором (на базе традиционной LLM) и измерили точность относительно золотых меток.
Также мы выделили 40 примеров, где текущий подход действительно делал вызов с передачей эксперту (меньшее n), и сравнили задержку вызовов на тех же самых примерах.
Медианное ускорение на один пример составило 8,1×. Это один из лучших внутренних результатов Jev на данный момент: в этой задаче ограниченной маршрутизации Jev оказался и точнее, и существенно быстрее. Масштаб разницы говорит о том, что «блокирующий» налог, который мы платим на запросах без передачи эксперту, может быть оправданным компромиссом. Учтите, что это всё ещё офлайн-сравнение на золотом датасете, а выборка задержек содержит лишь 40 успешных передач, так что предстоит ещё много проверок и тестов!
Реранжирование
Задача, близкая и дорогая сердцу Glean! Ниже наш продакшен-бейзлайн — это порядок, выдаваемый текущим поисковым стеком Glean. В эксперименте мы попросили Jev переупорядочить до 50 результатов.
Мы попробовали четыре способа выразить релевантность через типизированные ответы Jev:
Формулировка
Как выражается релевантность
Pointwise Noul
Для каждого результата задаётся отдельный вопрос о релевантности «да/нет», затем сортировка по вероятности ответа «да».
Shared-state Noul
Jev показывается весь набор кандидатов как общий контекст, затем для каждого результата задаётся тот же вопрос «да/нет».
Score
Jev присваивает каждому кандидату числовую оценку релевантности.
Choice
Все кандидаты рассматриваются как варианты одного решения, затем ранжируются по полученным вероятностям.
Мы запустили тест на внутреннем evalset, где у пользователя нет доступа ко всем каноничным документам, поэтому абсолютные цифры не отражают наше продакшен-ранжирование — но относительные показатели представляют интерес.
Формулировка Jev «Choice» оказалась самой сильной. На парном контроле из 4855 сохранённых поисковых запросов, после исключения продакшен-тай-брейкинг, результат оказался таким:
Jev Choice стоил примерно $0,00044 на запрос и занимал 0,195 секунды на p50 в офлайн-тесте. Но он присваивал одинаковые оценки примерно 37 из 41 кандидата в среднем запросе. Использование продакшен-порядка для разрешения таких ничьих подняло Recall@6 с 40,2% до 44,3%, из-за чего нескорректированный результат выглядит сильнее, чем заслуживают одни только оценки Jev. Как обычно, здесь полно оговорок, но вектор понятен: Jev — это дешёвый и эффективный бейзлайн, а не замена продакшен-ранкеру Glean.
Оценка подтверждения цитатами
Оценка цитирования отвечает на два связанных вопроса: есть ли у утверждений, требующих доказательств, адекватные ссылки (полнота цитирования), и действительно ли указанные источники подтверждают приписываемые им утверждения (точность цитирования)? На первый взгляд, поскольку пространство ответов и меток ограничено (как и в большинстве настроек судей), это кажется идеальной задачей для Jev. Однако рубрика сложная и может потребовать декомпозиции нескольких утверждений. К тому же Jev не формирует обоснование, которое мы часто используем для анализа ошибок, поэтому есть риски и для качества, и для удобства работы.
Мы протестировали Jev на реальном ответе из продакшен-эвала объёмом 1448 слов, зафиксировав сам ответ и доказательства из цитат. Мы сравнили его совместный проход по точности и полноте с GPT-5.6 Luna без рассуждений и с уровнем рассуждений xhigh. Чтобы снизить дисперсию, каждый судья запускался трижды.
Судья
Изначально замеренное время на ответ
Изначально замеренная стоимость на ответ
Jev
6,6 с
$
0,014
GPT-5.6 Luna, без рассуждений
81,3–85,5 с
$
0,030–
$
0,047
GPT-5.6 Luna,
xhigh
227,4–259,7 с
$
0,047–
$
0,060
Обратите внимание, что замеры времени скорее ориентировочные, чем сквозные: Jev сообщает последовательное клиентское wall time, тогда как в строках Luna суммируется длительность вызовов модели. Стоимость учитывает наблюдаемое кэширование.
Мы также сравнили согласованность на одних и тех же 28 абзацах. Изменённый элемент означает, что судья изменил свой вердикт о достаточности покрытия цитатами для абзаца хотя бы в одном из трёх прогонов с идентичными входными данными. Попарные расхождения считаются для каждого абзаца по трём парам прогонов, что даёт 84 сравнения на каждого судью.
Судья
Абзацы с изменённым вердиктом по полноте
Попарные расхождения по полноте
Jev
1 из 28 (3,6%)
2 из 84 (2,4%)
GPT-5.6 Luna, без рассуждений
7 из 28 (25,0%)
15 из 84 (17,9%)
GPT-5.6 Luna,
xhigh
5 из 28 (17,9%)
10 из 84 (11,9%)
Единственное изменение у Jev касалось того, считается ли один абзац нуждающимся в цитате; его итоговая категория полноты не изменилась. Таким образом, вердикты Jev о покрытии цитатами на уровне абзацев оказались более воспроизводимыми, чем у любой конфигурации Luna.
Мы не делаем вывод, что это делает Jev более точным судьёй (системы применяли разные критерии подтверждения и знаменатели при подсчёте, а на независимую ручную разметку у нас не было времени). Но даже с режимом xhigh (который примерно утроил время работы модели Luna) согласованность осталась ниже, чем у Jev. Результат подтверждает, что Jev — это быстрый, недорогой и сравнительно стабильный способ реализации узкой политики цитирования.
Выводы из экспериментов и практическое руководство
В некоторых случаях Jev отлично работает как простая альтернатива и традиционным LLM, и дообученным классификаторам. Когда бейзлайн силён (реранжирование) или легко дообучить меньшую модель (классификация запросов), преимущества слабее. Есть признаки более высокого качества в отдельных задачах (маршрутизация моделей), а также лучшей согласованности и стабильности (судья по цитатам). В ряде наших важнейших рабочих нагрузок он обеспечивает ожидаемый выигрыш по стоимости и задержке по сравнению с традиционными LLM.
Приведённые результаты задают хороший вектор, и в Glean мы в полном восторге от Jev. После нескольких дополнительных шагов (в основном операционной готовности вроде резидентности данных и гарантий) мы планируем внедрить Jev в некоторые из этих сценариев. Кроме того, Jev сыграет важную роль на нашем внутреннем хакатоне на этой неделе, и мы с нетерпением ждём возможности поделиться новыми результатами!
И пара общих советов напоследок: если варианты ответа можно перечислить заранее — тестируйте Jev. Если задача и метки стабильны, а объём большой — тестируйте и дообученный классификатор тоже. Если вызов должен сгенерировать запрос, объяснение или другой динамический текст — оставляйте в контуре генеративную модель. Вызов инструментов — отличный пример: Jev поможет выбрать инструмент, но большинству инструментов Glean всё равно нужны динамически сгенерированные аргументы (например, поисковые запросы).
Jev не отменяет того факта, что классификаторы существовали и раньше. Он просто делает качественный zero-shot-классификатор гораздо проще в использовании. Это крепкий продукт, даже если он не станет новым фундаментом для каждой AI-системы.
