Jev: Просте Пояснення

Ми використовували LLM як молоток для вирішення будь-яких задач ШІ, навіть простих рішень. Jev обробляє такі рішення за мілісекунди та значно дешевше. Давайте розберемося, як це працює і де це доречно.

TypeSafe AI випустила Jev 15 вересня 2026 року, і реакція була незвично сильною для моделі, яка не може вести діалог, писати код чи генерувати жодного корисного абзацу тексту.

Ну, саме в цьому обмеженні й полягає суть.

Більшості програмного забезпечення не потрібен черговий чат-бот. Йому потрібно приймати тисячі невеликих рішень, наприклад: Чи цей тікет терміновий? Яка модель має обробити цей запит? Чи небезпечна ця команда оболонки (shell command)? Чи відповідає знайдений уривок на поставлене питання?

Команди часто відправляють кожне таке рішення до універсальної LLM. Модель генерує відповідь токен за токеном, додаток аналізує її, валідує та повторює спробу, якщо формат неправильний. Це працює, але повільно й дорого для рішення з п’ятьма можливими варіантами.

Jev створено спеціально для таких рішень. TypeSafe називає його моделлю «Системи 1» (System One): на вході — неструктурований стан, на виході — типізовані відповіді та ймовірності.

Давайте розберемо, що це означає, де це доречно, а де маркетингу варто проявити стриманість.

Спочатку про проблему, яку вирішує Jev

LLM стало набагато легше інтегрувати в програмне забезпечення після появи викликів інструментів (tool calling) та структурованих виводів.

Виклики інструментів дозволяють моделі запитувати функцію у передбачуваному форматі. Структуровані виводи дозволяють повертати JSON, який відповідає схемі. Обидва підходи усунули величезну кількість крихкого парсингу.

Але базова модель залишається генеративною. Навіть якщо відповідь складається лише з одного слова «billing», вона виробляє токени послідовно. Ви платите за вхідні дані, чекаєте на генерацію та часто платите більше за вихідні дані.

Тепер уявіть це всередині циклу агента.

1while not done:
2    action = llm(context)
3    result = run_tool(action)
4    context += result

Модель можуть викликати повторно для вибору інструменту, оцінки результату, виявлення ризиків, визначення того, чи завершено завдання, та вибору наступної моделі. Один цикл роботи агента може містити багато викликів, які потребують судження, але не генерують текст.

Jev орієнтований саме на такі виклики.

Їхня ставка проста: мовна генерація — це неправильний інтерфейс, коли код вже знає можливі відповіді.

Що таке Jev насправді

Найкоротший точний опис — це семантичний рушій прийняття рішень.

Ви надсилаєте Jev дві речі:

• Стан: текст або JSON, що описує поточну ситуацію.
• Питання: рішення, які ви хочете отримати щодо цього стану.

Кожне питання заздалегідь оголошує форму своєї відповіді. Jev підтримує три примітиви:

• Choice обирає один варіант зі списку, який ви визначаєте, і повертає ймовірність для кожного варіанта.
• Score розміщує вхідні дані на впорядкованій шкалі, яку ви визначаєте, наприклад, низький, середній, високий.
• Noul відповідає на питання «так/ні», повертаючи ймовірність того, що твердження є істинним.

Noul — це назва TypeSafe для булевого примітиву. Незвичайна назва менш важлива, ніж вихідні дані (число між 0 і 1, з яким ваш код може працювати).

1{
2  "model": "jev-latest",
3  "state": "The deploy failed twice and customers are seeing 500s.",
4  "questions": {
5    "urgent": {
6      "type": "noul",
7      "instructions": "Does this need attention right now?"
8    },
9    "owner": {
10      "type": "choice",
11      "instructions": "Which team should handle this?",
12      "criteria": {
13        "engineering": "Product failures and outages",
14        "billing": "Charges, invoices, and refunds",
15        "sales": "Pricing and new accounts"
16      }
17    }
18  }
19}

Відповідь містить ймовірність терміновості та розподіл ймовірностей по трьох командах. Тут немає абзацу для інтерпретації та четвертої команди, яку модель могла б вигадати.

Ваша програма зберігає контроль:

1if urgent > 0.9 and owner == "engineering":
2    page_on_call()
3elif confidence < 0.6:
4    send_to_human_review()
5else:
6    add_to_queue(owner)

Саме тому люди продовжують називати Jev «розумним оператором switch». Цей вислів звучить зневажливо, але він точно передає корисну частину дизайну. Звичайний код володіє гілками. Модель надає розмите судження, яке звичайний код не може надійно обчислити.

Важлива відмінність від LLM

Традиційна LLM і Jev можуть класифікувати тікет підтримки. Але вони досягають відповіді по-різному і корисні в різних частинах системи.

TypeSafe стверджує, що Jev оцінює всі питання в запиті паралельно. Це змінює підхід до проектування робочого процесу. Замість того, щоб ставити одне питання, чекати відповіді та вирішувати, яке питання наступне, ви можете задати всі незалежні питання щодо одного й того ж стану в одному запиті та дозволити коду використовувати потрібні йому відповіді.

Компанія повідомляє про кінцеву затримку (latency) від 70 до 500 мілісекунд та ціну $0.042 за мільйон вхідних токенів, при безкоштовному виході. Їхні головні заяви свідчать про те, що це приблизно в 200 разів швидше та в 400 разів дешевше порівнянних робочих процесів LLM.

Ці великі коефіцієнти походять із власних оцінок робочих процесів TypeSafe і знаходяться на найвигіднішому кінці порівняння. Сприймайте їх як верхню межу, а не як гарантію для кожної програми. Базова перевага все ще є правдоподібною: Jev уникає довгих ланцюжків міркувань та генерованого виводу, оскільки він був спроектований для обмежених рішень.

Чому ймовірності мають значення

Типізована відповідь вирішує лише половину проблеми.

Припустимо, Jev направляє тікет до відділу білінгу. Вибрана мітка каже вам, хто переміг. Розподіл ймовірностей показує, наскільки близькою була боротьба.

1{
2  "choice": "billing",
3  "probabilities": {
4    "billing": 0.52,
5    "technical": 0.46,
6    "sales": 0.02
7  },
8  "confidence": 0.18
9}

Автоматичне маршрутизування такого тікета було б безвідповідальним. Білінг переміг, але з мінімальною перевагою. Відповідь з низькою впевненістю повинна активувати іншу гілку.

Це дає розробникам практичний шаблон:

• Висока впевненість: діяти автоматично, якщо наслідки незначні.
• Середня впевненість: запросити підтвердження або викликати більш потужну модель.
• Низька впевненість: передати справу людині або зібрати більше інформації.

Порогові значення належать коду, де їх можна переглядати та змінювати. Мітка на панелі моніторингу може допускати слабке передбачення. Команда, яка видаляє дані, повинна вимагати набагато вищої планки.

TypeSafe навчає Jev за допомогою навчання з підкріпленням для каліброваних рішень (Reinforcement Learning for Calibrated Decisions, RLCD). Мета полягає в тому, щоб впевненість відображала точність у багатьох передбаченнях. Якщо модель надає набору відповідей 90-відсоткову ймовірність, приблизно 90% цих відповідей мають бути правильними.

Заява про галюцинації потребує точності

TypeSafe стверджує, що Jev не може галюцинувати. Це твердження вірне лише за вузького визначення.

Jev не може повернути варіант поза схемою. Якщо ви визначили billing, technical та sales, відповідь не може вигадати legal. Також вона не може виробити неправильно сформований текст там, де ваш код очікував мітку.

Але він може впевнено обрати неправильний, але валідний варіант.

Типобезпека запобігає недійсним форматам. Вона не гарантує правильність судження. Ця відмінність важлива, оскільки помилка, що відповідає схемі, все одно може призвести до повернення коштів не тому клієнту, неправильного маршрутування інциденту або схвалення небезпечної команди.

Безпечніше сказати: «Jev не може порушити оголошену схему виводу, але він все ще може помилятися».

Де Jev доречний всередині агента

Jev найкраще працює, коли використовується разом з LLM, а не замість неї.

LLM виконує роботу, яка потребує мови або глибшого міркування. Вона планує, пише, пояснює та використовує інструменти. Jev обробляє часті рішення навколо цієї роботи.

Особливо привабливі три сценарії використання.

Маршрутизація моделей

Простий пошук не потребує тієї ж моделі, що й архітектурний огляд. Jev може оцінити запит і обрати найдешевшу модель, яка, ймовірно, виконає його.

1route = jev.choice(
2    state=user_request,
3    options={
4        "fast": "Lookups, extraction, and small local edits",
5        "powerful": "Architecture, ambiguity, and high-stakes work",
6    },
7)
8
9model = fast_model if route == "fast" else powerful_model

Роутер не відповідає на запит. Він вирішує, яка модель це має зробити.

Обмеження ризиків інструментів

Перш ніж агент виконає команду оболонки, Jev може класифікувати її як доступ тільки для читання, оборотну або руйнівну. Окремі питання можуть перевірити, чи видаляє вона файли, змінює історію Git, впливає на продакшн або залишає репозиторій.

Дії з високим рівнем впевненості, які є операціями читання, можуть продовжитися. Руйнівні або невизначені дії можуть бути поставлені на паузу для людського схвалення. Інтеграція Jev у LangChain застосовує цей патерн через middleware, який перевіряє виклик інструменту перед виконанням.

Верифікація та нагляд

Агент може стверджувати, що завдання виконано, навіть якщо тести все ще падають. Jev може перевірити стан і відповісти на обмежені питання: Тести пройшли? Агент повторює ту саму дію? Вивід відповідає політиці? Цей результат потребує перегляду?

Він не замінить жорсткий тест, якщо такий існує. Він додає семантичну перевірку там, де правило залежить від змісту.

Проблеми, які Jev може вирішити сьогодні

Найкращі випадки використання мають три спільні властивості. Ви можете назвати можливі відповіді, уважна людина може швидко оцінити вхідні дані, і рішення приймаються достатньо часто, щоб затримка або вартість мали значення.

Підтримка та операції

• Класифікувати наміри, терміновість, відділ, спам та роздратування клієнтів.
• Маршрутизувати повернення коштів та винятки з політики через кілька невеликих перевірок.
• Ранжувати логи та інциденти за семантичною серйозністю до того, як їх прочитає людина.

Один запит може поставити всі ці питання щодо одного й того ж тікета. Код потім комбінує відповіді з фактичною політикою маршрутизації компанії.

Пошук та отримання даних (Retrieval)

• Переупорядковувати отримані уривки за тим, чи відповідають вони на запит.
• Перевіряти, чи підтверджує цитата твердження.
• Фільтрувати нерелевантні фрагменти перед надсиланням контексту до дорогої LLM.

Ембеддинги чудово знаходять семантично пов’язаний текст. Jev може прийняти вужче рішення про те, чи корисний конкретний уривок для цього питання.

Якість та безпека

• Екранувати промпти на предмет джейлбрейків або ін’єкцій промптів.
• Перевіряти згенерований контент проти політики або критеріїв оцінювання.
• Позначати ризиковані зміни коду або виклики інструментів перед їх виконанням.

Ці перевірки мають перебувати поруч із детермінованими контролями. Семантичний класифікатор корисний для розмитих ризиків, тоді як дозволи, пісочниці (sandboxes) та тести забезпечують правила, які програмне забезпечення може перевірити точно.

Класифікація великих обсягів даних

• Маркувати документи, наукові статті, товарні позиції або повідомлення клієнтів.
• Перетворювати вільний текст на ознаки (features) для традиційної моделі машинного навчання.
• Оцінювати кожен елемент у великому корпусі за тими самими критеріями.

Саме тут низька вартість одного виклику стає більше, ніж просто цифрою в бенчмарку. Судження, яке було занадто дорогим для запуску на кожному рядку, може перейти у стандартний конвеєр даних.

Інтерфейси реального часу

• Обирати наступну дію браузера з відомих елементів сторінки.
• Оцінювати тон або ясність під час написання людиною.
• Вибирати дію зі структурованого стану гри або симулятора.

Наразі Jev працює лише з текстом, тому ці системи повинні спочатку конвертувати середовище в текст або JSON. Він не дивиться на екран і не грає на основі пікселів.

Коли Jev — неправильний вибір

Jev стає менш корисним, щойно простір відповідей перестає бути відомим.

• Він не може написати відповідь, узагальнити документ, згенерувати код або пояснити свої міркування.
• Він ненадійний для арифметики, підрахунку, порівняння дат або точної маніпуляції рядками. Залиште ці операції в коді.
• Він погано справляється, коли рішення вимагає кількох прихованих кроків міркування. Розбийте судження на менші питання або використайте модель для міркувань.
• Він не може безпосередньо витягнути невідоме значення. Спочатку знайдіть кандидатів, а потім дозвольте Jev обрати серед них.
• Нерелевантний контекст може знизити точність. Надсилайте лише той стан, який необхідний для прийняття рішення.
• Закриті ваги, ранній доступ, текстовий вхід та обмежені незалежні дані калібрування роблять сліпу довіру передчасною.

Є також простіше правило: якщо детермінований код вже правильно вирішує проблему, залиште код. Звичайний оператор if швидший, дешевший і легший для тестування, ніж будь-яка модель.

Як використовувати Jev, не створюючи нових режимів відмов

Дешева модель все ще може бути дорогою, якщо її помилки створюють повторні спроби, ручний перегляд або інциденти на продакшні. Вимірюйте весь робочий процес, а не ціну за токен.

Розумне впровадження виглядає так:

1. Оберіть одне обмежене, низькоризиковане рішення з чіткими можливими відповідями.
2. Напишіть критерії оцінювання перед викликом моделі. Визначте, що належить кожному варіанту.
3. Зберіть репрезентативні приклади з очікуваними відповідями, включаючи неоднозначні та ворожі випадки.
4. Запустіть Jev у режимі тіні (shadow mode) поруч із поточним робочим процесом, не дозволяючи йому змінювати поведінку.
5. Побудуйте графік залежності точності від впевненості та встановіть пороги на основі ваших даних.
6. Автоматизуйте найбезпечнішу гілку першою і залиште людину або сильнішу модель для невизначених випадків.
7. Зафіксуйте або зареєструйте версію моделі, питання, критерії та пороги, щоб зміни можна було відтворити на тому самому наборі для оцінювання.

Питання є частиною програми. Ставтеся до них як до коду: контролюйте версії, переглядайте та тестуйте їх щоразу, коли змінюється модель або критерії.

Фактичний зсув

Jev цікавий не тим, що перемагає LLM у написанні тексту. Він відмовляється писати.

Його внесок — це інтерфейс моделі, сформований за зразком програмного забезпечення: фіксовані типи відповідей, явна невизначеність, паралельні питання та гілки, контрольовані кодом.

Це робить його корисним супутником генеративних моделей. LLM створює план, пояснення або код. Jev маршрутизує запит, блокує ризиковані дії, перевіряє результат і вирішує, коли невизначеність достатньо висока для ескалації.

Ширша ідея важлива, навіть якщо інша модель врешті-решт замінить Jev. Ми роками просили генеративні моделі виконувати будь-який вид інтелекту через текст. Багато продуктивних систем не потребують більше слів. Їм потрібне маленьке, швидке судження, яке звичайне програмне забезпечення може безпечно використати.

Це категорія, яку Jev намагається побудувати.

З чого почати

Не починайте з перебудови свого агента навколо Jev. Знайдіть одне рішення, яке зараз вимагає повільного виклику LLM або регулярного виразу, який постійно ламається.

Надайте Jev мінімальний стан, визначте можливі відповіді та логуруйте його ймовірності поруч із поточним результатом. Дозвольте йому довести, що він заслуговує на одну гілку, перш ніж передати йому весь робочий процес.

Найкорисніша ментальна модель залишається найпростішою → Jev додає судження там, де звичайний оператор if розуміє значення, але не їхній сенс.

Джерела та додаткове читання

• TypeSafe AI: Представлення моделей Системи 1 та Jev
• LangChain: Створення каркаса (Harness) з Jev
• Flavio Copes: Глибоке занурення в Jev

Сподіваюся, вам було цікаво читати.

До зустрічі в наступному матеріалі.

Бувай! :)