Jev проти агентів: інтеграція примітивів прийняття рішень у ПЗ

Якщо ви не жили під каменем останнього тижня, то напевно бачили Jev від @typesafeai.

https://x.com/CompleteSkeptic/status/2099925682726002904

Вони описують свої моделі так:

Клас моделей ШІ, створених для швидкого прийняття структурованих рішень, які програмне забезпечення може використовувати безпосередньо. Модель System One оцінює
стан і повертає типізовані відповіді та ймовірності.

Згідно з бенчмарками TypeSafe, Jev працює в 20–200 разів швидше та коштує в 40–400 разів дешевше за LLM.

Але чому це взагалі важливо? Ми вже тренували класифікатори раніше (автокорекція в телефоні, фільтрація пошти в Gmail тощо), але, судячи з Twitter, Jev — це щось особливе.

У цій статті я хочу пояснити вам, що таке Jev, навіщо він існує і як можна інтегрувати його у ваші продакшн-системи.

Отже, що саме таке Jev?

«Уявіть Jev як виклик функції передового інтелекту: неструктурований стан на вході, типізовані ймовірнісні рішення на виході» - TypeSafe

Jev надає три примітиви: Choice, Score та Noul.

Choice — це тип питання, який обирає один варіант із заданого набору (максимум 255), де відповідь містить обраний варіант, ймовірність для кожного варіанта та рівень впевненості.
Score оцінює контент за впорядкованими, описовими рівнями, де відповідь містить бал, ймовірність для кожного рівня та рівень впевненості.
Noul просить модель оцінити запитання «так/ні» та повернути ймовірність того, що відповідь буде «так».

Ось приклад вхідних даних та результату для кейсу служби підтримки клієнтів:

json

1// Вхідні дані
2{
3  "model": "jev-latest",
4  "state": "Привіт, з мене двічі списали гроші за місячну підписку. Чи можете ви повернути зайву суму? Мій акаунт працює нормально.",
5  "questions": {
6    "department": {
7      "type": "choice",
8      "instructions": "Яка команда має опрацювати це повідомлення?",
9      "criteria": {
10        "billing": "Платежі, розрахунки, підписки та повернення коштів",
11        "technical": "Баги, помилки та несправні функції",
12        "account": "Логін, паролі та доступ до акаунту"
13      }
14    },
15    "requests_refund": {
16      "type": "noul",
17      "instructions": "Чи явно клієнт просить про повернення коштів?"
18    },
19    "frustration": {
20      "type": "score",
21      "instructions": "Наскільки роздратовано звучить клієнт?",
22      "criteria": [
23        "Спокійний: ввічливо описує проблему без виявлення роздратування",
24        "Роздратований: висловлює незадоволення або невдоволеність",
25        "Дуже роздратований: висловлює сильний гнів або погрожує піти"
26      ]
27    }
28  }
29}
30// Результат
31{
32  "model": "jev-1.13.0",
33  "answers": {
34    "department": {
35      "type": "choice",
36      "choice": "billing",
37      "confidence": 1,
38      "probabilities": {
39        "technical": 0,
40        "account": 0,
41        "billing": 1
42      }
43    },
44    "requests_refund": {
45      "type": "noul",
46      "noul": 0.99
47    },
48    "frustration": {
49      "type": "score",
50      "score": 0,
51      "legend": {
52        "0": "Спокійний: ввічливо описує проблему без виявлення роздратування",
53        "1": "Роздратований: висловлює незадоволення або невдоволеність",
54        "2": "Дуже роздратований: висловлює сильний гнів або погрожує піти"
55      },
56      "confidence": 1,
57      "probabilities": {
58        "0": 1,
59        "1": 0,
60        "2": 0
61      }
62    }
63  },
64  "usage": {
65    "input_tokens": 442,
66    "output_tokens": 72
67  },
68  "request_id": "playground_12bbfa4198be5ca4de9818a45c0906a2055",
69  "evaluation_time_ms": 163.01120699790772
70}

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

Хіба це не просто класифікатор?

Ну, і так, і ні. Це скоріше схоже на те, якби LLM і класифікатор народили дитину.

Традиційні класифікатори добре підходять для задач із великим обсягом даних та фіксованою таксономією. Подумайте про LeNet-5, який може визначити, яку цифру зображено на картинці. Однак класифікатори зазвичай надзвичайно спеціалізовані та прив’язані до конкретної предметної області. LLM добре генерують послідовності. Вони гнучкі та чудово підходять для відкритих задач, визначених під час виконання, але вони також повільніші (порівняно з класифікаторами), дорожчі та менш передбачувані.

Jev — це «фундаментальна модель для класифікації», яка поєднує гнучкість природної мови LLM з обмеженим, ймовірнісним виведенням класифікатора. Ви можете виконувати широкий спектр задач без необхідності тренувати нову модель, зберігаючи при цьому експертність у різних предметних областях (код, текст, логи, стани UI, події тощо). Jev також може генерувати вивід паралельно, що робить його набагато швидшим за LLM, обмежену послідовною генерацією.

Коротко: це дуже розумний узагальнений класифікатор.

Навіщо існує Jev?

Генеральний директор та співзасновник TypeSafe Diogo Almeida працював в OpenAI, допомагаючи створювати RLHF (навчання з підкріпленням на основі зворотного зв'язку від людей) та продукт ChatGPT. RLHF дозволив нам навчити LLM бути дійсно хорошими у слідуванні інструкціям та запитам, що відповідає їхній авторегресивній природі.

Потім він покинув OpenAI, щоб заснувати TypeSafe та тренувати інший клас моделей для створення програмного забезпечення з елементами ШІ, а не агентів. Jev навчається за допомогою RLCD (навчання з підкріпленням на основі каліброваних рішень), що науковою мовою означає тренування моделі на вміння видавати точну впевненість та ймовірності, а не просто відповіді.

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

Це не зовсім нова ідея: дослідники у 2017 році виявили, що висока точність прогнозування не означає надійних оцінок впевненості (тому LLM тут не є ідеальним рішенням).

Чому RLCD, а не RLHF?

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

Це також призводить до колапсу мод (mode collapse): RLHF змушує LLM сходитися до однієї відповіді, хоча іноді кілька траєкторій можуть бути «правильними».

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

Колапс мод з документації Jev

Jev НЕ був створений для побудови агентів

На противагу тому, що ви бачите у своїх стрічках, Jev не дуже добрий як окремий агент. Ми намагалися створити його версії, як тільки Jev, так і комбінацію LLM + Jev.

https://x.com/kylejeong/status/2100622054945095934

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

Модель на кшталт Jev призначена для програмного забезпечення з елементами ШІ; вона може допомогти вам приймати рішення, скомпоновані в детермінованому коді. Використовувати її як окремого агента без можливостей міркування чи генерації — це просто незнання.

Програмне забезпечення з елементами ШІ

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

Цифри

Їхня перша модель Jev 1.13.0 коштує $42 за мільярд токенів входу (або $0.042 за мільйон токенів) і $0 за токени виходу. Для порівняння, Fable 5.1 коштує $10 за мільйон токенів входу, що становить $10,000 / млрд токенів. Типові корпоративні навантаження мають співвідношення вхідних та вихідних токенів 3:1 або 4:1, тому вартість Fable зростає приблизно до ~$20,000/млрд токенів (при вартості виходу $50/млн токенів).

Вікно контексту становить 64k токенів на запит, причому стан і найдовше запитання повинні вміститися в 32k токенів.

Однак у їхніх внутрішніх бенчмарках вони перевершують усі моделі за показниками точність/вартість та точність/швидкість від OpenAI, Anthropic та Deepseek (через Fireworks для інференсу).

точність/вартість

Досить балаканини, як це використовувати?

Тепер у вас має бути достатнє розуміння Jev, щоб придумати кілька кейсів застосування для поточних проектів. (Якщо ні, ось список рекомендованих TypeSafe кейсів).

Замість того, щоб обмежувати вашу креативність щодо того, як саме використовувати Jev, я покажу, як ми адаптували його до нашого фреймворку Stagehand.

Протягом останніх 2 років Stagehand розвивався як фреймворк для ШІ та агентів для керування віддаленим браузером. До того, як агенти стали достатньо досконалими, ми створили примітиви ШІ: Act (виконати дію), Extract (витягнути структуровані дані) та Observe (виявити можливі дії на сторінці), щоб допомогти розробникам писати самовідновлювані скрипти для автоматизації вебу.

Замість використання Playwright (або інших застарілих фреймворків) та ручного аналізу DOM для надання селекторів у діях, Stagehand A/E/O дозволяє використовувати природну мову для створення автоматизацій.

typescript

1// Playwright
2await page.click('button[type="submit"]');
3
4// Stagehand
5stagehand.act("натисни кнопку submit")

Це корисно при написанні скриптів вперше (швидкість розробки значно вища), але особливо корисно для підтримки скриптів. Якщо вебсайт змінюється і селектори DOM оновлюються, скрипти Playwright потрібно переписувати відповідно до нової сторінки. Stagehand обирає селектори та дії під час виконання, тому вони є «самовідновлюваними».

Ви вже можете здогадатися, куди ми рухаємось. Jev ідеально вписується в ці примітиви. Спочатку ми використовували LLM (з контекстом про вигляд сторінки та мету), щоб вирішити, що робити. Завдяки Jev ми можемо використовувати Choice для визначення того, з якими селекторами взаємодіяти.

Давайте розглянемо процес на прикладі Action. Зазвичай ми б давали LLM лаконічне представлення сторінки, використовуючи гібридне дерево доступності (a11y-tree). З Jev ми спочатку позначаємо вузли у дереві доступності як такі, що дозволяють взаємодію (навіть редактори форматованого тексту), або ні.

Коли викликається stagehand.act функція:

Jev класифікує інструкцію в дію (наприклад, click, fill або scroll)
Stagehand аналізує аргументи та будує список кандидатів для цієї дії (що включає контекст навколишньої сторінки)
Jev відповідає на запитання «який кандидат найкращий» та «чи відповідає будь-який кандидат», маючи поріг прийняття 0.7
Якщо дія кандидата приймається, Stagehand бере на себе виконання
Якщо ні, Stagehand повертається до використання LLM

Потік Action

У ранньому тестуванні медіана затримки Action знизилася з 1.97 секунди до 0.46 секунди, що приблизно в 4.3 раза швидше (або на 77% менше часу). Перегляньте повний стек PR.

У випадку з використанням комп'ютера Jev є частиною пазла, але не самостійним рішенням. Тепер ми можемо будувати більш детерміновані програмні інструменти, які можуть використовувати агенти.

Коли використовувати Jev

Впровадження ШІ у реальному світі

Чи зможе Jev створити продакшн-агентів для використання комп'ютера? Ні. Чи є він корисною частиною пазла? Я думаю, що так.

Відчувається, що з'явилася безліч ідей, які не мали сенсу до появи Jev. Я бачив, як люди створюють миттєвий пошук, розумне копіювання-вставляння та інші прості, але надзвичайно корисні інструменти.

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

-> Kyle