Jev від TypeSafe: модель, яка повертає типізовані рішення замість тексту
Jev не генерує текст: за один швидкий виклик він видає типізований вибір, оцінки й відкалібровані ймовірності. Розбираємо, як працює API, що знайшли тестувальники і де модель не дотягує.
Нова модель від TypeSafe взагалі не генерує текст. Вона повертає типізоване рішення з доданою ймовірністю, і це змінює те, в яких місцях вашого коду взагалі може жити ШІ-модель.
Модель називається Jev, і це перша з лінійки, яку компанія називає System One Models. Назва відсилає до поділу за Канеманом на швидке, автоматичне мислення та повільне, виважене. Jev бере на себе швидку половину, а виважена лишається за великими мовними моделями.
Анонс на typesafe.ai піднявся на Hacker News майже до тисячі балів і зібрав понад 300 коментарів, приблизно половина з яких сперечалася про заголовок. Виглядає це як черговий запуск маленької, швидкої та дешевої моделі, але це не так. Jev узагалі не пише: текстового виводу в нього немає. Тож він майже не конкурує з чат-моделями, якими ви вже користуєтеся. Він конкурує з оператором if.
Оператор if, за який усі постійно перепрошують
Майже в кожному пайплайні є одне гниле місце. Десь посередині треба ухвалити рішення на око. Чи варто цьому тікету пройти поза чергою? Чи не звучить ця відповідь грубо? Чи варто залишати цей рядок?
Роками це місце заповнювали правилами: списки ключових слів, регулярні вирази, поріг, підібраний якогось вівторка й більше жодного разу не переглянутий. Усе це ламається, щойно клієнт пише ввічливо, але в люті.
Тож команди почали ставити туди LLM. Це працює, але заодно ламає пайплайн. Одне рішення може тривати близько восьми секунд, а парсинг JSON падає на чотирьохсотому рядку. Запускати таке на кожен елемент великого датасету чи всередині циклу не вийде, і вже точно не там, де користувач чекає на відповідь.
Проблема ніколи не була в інтелекті
Справжній біль у тому, де стоїть модель, а не в тому, що моделі надто дурні для цієї роботи. Найрозумніші моделі сидять на краях софту, а внутрішній цикл досі забитий регулярками.
Що випустила TypeSafe
Засновник формулює це одним реченням: виклик функції з інтелектом рівня фронтир-моделей, який приймає неструктурований стан і повертає типізовані ймовірнісні рішення.
Ви передаєте state, чи то тікет підтримки, документ або кадр гри, серіалізований у текст, плюс словник запитань. У відповідь приходять типізовані відповіді. Типів запитань лише три, і це вся поверхня API:
- Choice обирає один варіант із набору. Повертає вибір, імовірність для кожного варіанта та значення впевненості.
- Score оцінює щось за впорядкованими рівнями з описами й повертає той самий набір значень.
- Noul — запитання «так/ні», відповіддю на яке є ймовірність того, що відповідь «так».
Усі запитання в одному виклику обробляються паралельно, кожне ізольовано, за тим самим станом за один прохід. Тому, за словами TypeSafe, додаткові запитання майже не впливають на час відповіді. Платите ви за виклик, а не за запитання.
Заявлена затримка — від 70 до 500 мс від початку до кінця, а ціна — $42 за мільярд вхідних токенів, вивід безкоштовний. Чи означає ця цифра те, що здається, розберемо нижче.
Увесь API
Швидкий старт починається з одного імпорту:
from typesafe_sdk import Choice, Noul, Score, TypeSafeClient
Далі на вхід іде тікет підтримки, а назад приходять три рішення:
client = TypeSafeClient()ticket = "Hi, I've been trying to connect my Stripe account for 3 days and it keeps failing. I'm losing sales. Please help ASAP."response = client.system_one(
state=ticket,
questions={
"department": Choice(
instructions="Which team should handle this",
criteria={
"billing": "Payment or subscription issues",
"technical": "Bugs or integration problems",
"sales": "Pricing or account questions",
},
),
"frustration": Score(
instructions="How frustrated the customer appears",
criteria=[
"Calm, just stating facts",
"Frustrated but civil",
"Very angry, strong language",
],
),
"is_urgent": Noul(
instructions="The message conveys urgency or time-sensitivity",
),
},
)
Жодного промпт-інжинірингу, жодних інструкцій «відповідай лише валідним JSON» і жодних обгорток із повторними спробами. Три рішення приходять за один запит. SDK для Python і JavaScript працюють поверх одного POST-ендпоінта.
Те, що змінює підхід до написання коду
Відповідь LLM звучить однаково впевнено, хоч модель знає, хоч вгадує. Jev натомість повертає розподіл.
Метод навчання називається RLCD, Reinforcement Learning for Calibrated Decisions, і його мета — щоб ці ймовірності відповідали тому, як часто модель справді має рацію. А отже, можна розгалужуватися за мірою сумніву:
- Вище 0.9 — маршрутизувати елемент автоматично.
- Від 0.6 до 0.9 — передати більшій моделі.
- Нижче — показати людині.
Таку гілку багато команд хотіли роками. Досі її підробляли через упевненість, про яку LLM повідомляє сама, а передбачувальна сила в неї приблизно як в астрології.
Що тестувальники зробили першого ж дня
Перші користувачі провели серію експериментів, і один із них показує суть продукту краще за будь-яку таблицю бенчмарків. Автор із медіакомпанії згодував Jev усі 27 своїх опублікованих статей і ще 10 підробок, навмисно написаних у стилі ШІ. Він поставив 21 паралельне запитання про типові ознаки машинного тексту. Загалом вийшло 777 рішень за 37 документами. Усі вони надійшли менш ніж за 0.7 секунди й коштували приблизно чверть цента.
CEO компанії продовжив чотирма перевірками на 12 фрагментах, запустивши їх наввипередки з фронтир-LLM. Jev знадобилося в середньому 0.35 секунди на фрагмент, а LLM — 8.83. Це приблизно в 25 разів швидше і, за їхніми підрахунками, приблизно в 580 разів дешевше.
Демо з Doom
Саме одне демо змусило публіку Hacker News усе зрозуміти. TypeSafe під'єднала Jev до гри в Doom. Модель не читала пікселі: вона отримувала стан гри, серіалізований у структурований текст, приблизно десять запитів на секунду. Інженер, який це зібрав, кажуть, хвилювався через таку частоту запитів, а вона коштує приблизно $7 на годину.
ШІ всередині ігрового циклу — це весь пітч, утілений буквально.
Де модель провисає
На головній сторінці обіцяють «Zero Hallucinations», і саме з цим твердженням варто посперечатися насамперед. Гарантовано лише те, що вивід відповідає вашій схемі, тобто Choice завжди потрапить в один із ваших варіантів. Але це не те саме, що мати рацію. Jev може повернути валідну й упевнено хибну відповідь, і в треді на Hacker News про це говорили докладно.
Експеримент автора це підтверджує. У тестовий набір заклали сім дефектів. Jev знайшов шість і пропустив один — абзац про спільний календар, за яким батьки й працівники «навчають разом». Порівняльна LLM його помітила. Його власний вердикт був чесним: якщо справа йде до продакшену, спершу треба ретельніше перевірити точність.
Жорсткі обмеження теж цілком реальні:
- Контекстне вікно — 32k токенів, тож про роботу з цілим репозиторієм можна забути.
- У Choice максимум 255 варіантів.
- Зображення на вхід поки не приймаються.
- Архітектуру тримають у секреті. Ні статті, ні незалежної оцінки RLCD немає, лише ранні відгуки.
Ціна — це не та заміна, про яку ви думаєте
$42 за мільярд вхідних токенів виглядає смішно дешево на тлі фронтир-моделі, але одиниця виміру інша. Ви купуєте рішення, а їх ви ухвалюватимете набагато частіше, ніж будь-коли робили виклики LLM. Низька ціна за токен якраз і дає змогу робити десять викликів на секунду. Це не просте віднімання від вашого поточного рахунку.
До того ж це ранній доступ зі списком очікування, тож прочитати про модель ви, можливо, встигнете раніше, ніж спробувати.
Чи варта вона вашої уваги?
Так, але не через множники швидкості. Jev вирізняється тим, що чесно окреслює свої межі. Він не базікає, не міркує вголос, не пояснює себе й не вдає, що вміє.
Його єдине завдання — перетворювати неохайний ввід на типізоване рішення, яке може перевірити ваш компілятор, і робити це досить швидко, щоб жити всередині циклу. Можливо, у вашому продукті чат-модель встромлена туди, де насправді потрібне рішення. Для такої ситуації Jev пропонує справді інший вихід. Будувати систему доведеться радше навколо значення впевненості, ніж навколо затримки.
Проженіть його на своїх даних, перш ніж підпускати до чогось важливого, — цю пораду ранні тестувальники повторюють постійно. Багато хто й так сумнівається, що одна текстова модель на всі випадки — правильний інструмент для вузьких завдань, і це перша серйозна спроба зробити щось інакше.