Автори: @eddiedzhou, @mr_cheu, @MatZhao, @CosmicPegasis19, @manav_ai
Jev — це модель для прийняття типізованих рішень. Ви передаєте їй контекст разом із фіксованим набором запитань і варіантів, а вона повертає вибір, оцінки та ймовірності замість того, щоб генерувати текст. Це модель «Системи 1»!
Але класифікація — не новина, як і структуровані виводи, малі моделі чи зчитування ймовірностей із логітів. Саме ця історія пояснює неоднозначну реакцію на Jev...

Скептики мають рацію у своїх сумнівах, але Jev справді має своє місце в цій екосистемі. Щоб краще це зрозуміти, варто окреслити весь простір можливих рішень.
Які є альтернативи?
Коли системі потрібна мітка, оцінка або відповідь «так/ні», є чотири адекватні варіанти:
Підхід
Чому варто використовувати
Компроміси
Універсальна LLM
Zero-shot, гнучкість, здатність генерувати аргументи чи пояснення. Можливо, «вищий інтелект» завдяки обчисленням під час інференсу (reasoning).
Затримка та вартість авторегресійної моделі заради дрібного рішення
Відкритий zero-shot класифікатор
Дешево, локально, повний контроль
Нестабільна якість; ви самі відповідаєте за вибір моделі та її хостинг
Доопрацьований (fine-tuned) класифікатор
Зазвичай найкращий вибір для стабільних високонавантажених задач із якісною розміткою
Збір даних, навчання, деплой, дрейф моделі та менш гнучка таксономія
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, адже хоча простір міток для окремого запиту відомий заздалегідь, сама таксономія може змінюватися швидше, ніж вдасться перенавчити fine-tuned класифікатор.
У цьому експерименті ми зосередилися на тому, наскільки прогнози Jev збігаються з нашими продакшн/базовими прогнозами, які працюють на LLM. Ми очікували й зафіксували значне прискорення офлайн-пропускної здатності з Jev, тому використовуємо рівень збігу як зручний індикатор якості. Також ми порівняли результати з Laya — моделлю прийняття рішень із відкритими вагами — та її доопрацьованою версією. Доопрацювання зайняло кілька годин на локальній машині, а сама модель достатньо мала, щоб працювати на комп'ютері розробника.
Експеримент
Збіг за загальною задачею
Продуктивність
Jev zero-shot
66,8%
~
12 хв (паралельність 4
)
Базова Laya
35,9%
~
90 с (локальна машина розробника)
Доопрацьована Laya
74,5%
~
90 с (локальна машина розробника)
Як зручна готова модель, що не потребує навчання, Jev явно перевершує Laya, але, що цілком очікувано, доопрацювання дозволяє Laya сяяти, особливо з огляду на показники продуктивності. Компромісом є зусилля на отримання якісної розмітки та налаштування навчання. Jev, імовірно, залишатиметься привабливішим, коли задача нова або її мітки часто змінюються.
Маршрутизація моделей: передача експерту
Маршрутизація моделей — задача, споріднена з класифікацією запитів. Тут ми розглядаємо її як «передачу експерту», коли система вирішує, який саме експерт/модель має опрацювати запит. Наш поточний продакшн-бейзлайн просить 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 без reasoning та з xhigh reasoning. Щоб зменшити дисперсію, ми запускали кожного суддю тричі.
Суддя
Початковий виміряний час на відповідь
Початкова виміряна вартість на відповідь
Jev
6,6 с
$
0,014
GPT-5.6 Luna, без reasoning
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, без reasoning
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 reasoning (що приблизно потроїло час роботи моделі Luna) вона залишалася менш узгодженою, ніж Jev. Результат підтверджує, що Jev є швидким, недорогим і відносно стабільним способом реалізувати вузьку політику цитування.
Висновки з експериментів і практичний посібник
У деяких випадках Jev чудово працює як низькобар'єрна альтернатива і традиційним LLM, і доопрацьованим класифікаторам. Коли базове рішення вже сильне (переранжування) або коли легко доопрацювати меншу модель (класифікація запитів), переваги менш відчутні. Водночас є ознаки вищої якості для певних задач (маршрутизація моделей), а також кращої узгодженості та стабільності (суддя для цитат). У деяких наших найважливіших робочих навантаженнях він забезпечує очікуваний виграш у вартості та затримці порівняно з традиційними LLM.
Наведені результати дають хороші орієнтири, і в Glean ми дуже радіємо Jev. Після ще кількох кроків (переважно операційної готовності, як-от резидентність даних і гарантії) ми плануємо впровадити Jev у деякі з цих сценаріїв. Крім того, Jev відіграватиме велику роль на нашому внутрішньому хакатоні цього тижня, і ми з нетерпінням чекаємо можливості поділитися новими результатами!
І наостанок кілька загальних порад: якщо можливі виводи можна перелічити заздалегідь — тестуйте Jev. Якщо задача та мітки стабільні, а обсяг великий — протестуйте також доопрацьований класифікатор. Якщо виклик має генерувати запит, пояснення чи інший динамічний текст — залишайте генеративну модель у процесі. Виклик інструментів — хороший приклад: Jev може допомогти обрати інструмент, але більшості інструментів Glean усе одно потрібні динамічно згенеровані аргументи (наприклад, пошукові запити).
Jev не скасовує того факту, що класифікатори існували й раніше. Він просто робить хороший zero-shot класифікатор значно простішим у використанні. Це надійний продукт, навіть якщо він не є новим фундаментом для кожної AI-системи.





