API Jev: как типизированные ответы LLM меняют разработку ИИ-агентов

Запуск собрал около 33 млн просмотров, через два дня появился браузерный агент, ищущий авиабилеты за семь секунд, торговый бот и человек, пересобравший якобы Tesla Full Self-Driving за час. Разберём, что под капотом, а что — чистый хайп.

Контракт: state, questions, ответы под ключами

Jev — не магия и не новая модель. Это интерфейс поверх LLM. На входе у него state — текст или структурированное состояние приложения, и questions — массив типизированных вопросов. Ответы возвращаются под теми же ключами. Всё. Дальше ваш код их разбирает.

Публичных примитивов три:

• Choice — выбор одного из заданных вариантов с распределением по всему списку.
• Score — распределение вероятности по шкале из 2–10 уровней, считается матожидание.
• Noul — отдельный примитив для булевых ответов: «есть срочность», «это спам», «клиент согласен».

Классический кейс из разбора — тикет в поддержку: «с меня дважды списали деньги, исправьте срочно». Одним запросом снимаются три метрики: срочность (Noul), какой отдел берёт тикет (Choice), насколько клиент раздражён (Score). Все вопросы видят общий state, но не видят ответов друг друга. Хотите, чтобы второй зависел от первого, — собирайте зависимость в коде, а не в промпте.

Семь секунд и speculative fan-out

Главный трюк быстродействия — speculative fan-out. Приложение заранее шлёт вопросы для нескольких веток сценария, получает ответы параллельно, а потом отбрасывает лишние. Не ждём следующего вызова API, не гонимся за одним вопросом. Часть работы сгорает впустую, зато latency падает.

Отсюда и те самые семь секунд на авиабилеты, и час на «пересборку FSD» — это не подвиг модели, а параллельные запросы к API. Если вы бэкендер, вы это и так знаете: упреждающая загрузка и speculative execution живут в каждом процессоре лет двадцать. Теперь это обернули в JSON.

«Ноль галлюцинаций» и ловушка confidence

Маркетинговый слоган про отсутствие галлюцинаций верен в узком смысле. Если модель обязана выбрать из {billing, technical, sales}, она не вернёт юридическую справку или стих про возвраты. Типобезопасность держит форму и множество допустимых ответов. Она не держит фактическую правильность.

С confidence та же история. Это характеристика формы распределения, а не вероятность того, что решение верно. 0.9 — это не «ошибка в одном случае из десяти». TypeSafe сама рекомендует калибровать пороги на своих размеченных данных и учитывать цену ошибки. Один порог для модерации комментариев, блокировки платежей и удаления продакшен-базы — это классический костыль, который убьёт вам либо модерацию, либо базу. Если вы привыкли доверять цифре «confidence» в любых системах — вспомните, как то же самое происходит с анализами и симптомами, где значение в бланке тоже не равно диагнозу.

System One, RLCD и чего нет в открытом доступе

Под капотом у TypeSafe — System One и метод обучения RLCD (Reinforcement Learning for Calibrated Decisions). Компания не опубликовала ни весов, ни архитектуры, ни данных, ни функции потерь, ни схемы вознаграждения. Всё, что есть, — описание и опыты вроде Archer Hume, которые подтверждают изоляцию вопросов и влияние списка вариантов, но не доказывают каузальный декодер, KV-кэш, отдельные выходные головы или MoE. Проверить можно только границу «модель ↔ приложение».

И это не страшно: TypeSafe открыла System One адаптер для обычных LLM. Похожий интерфейс собирается за вечер на structured output, constrained decoding или локальном logit-scoring. Вывод простой — выбирайте Jev не из-за хайпа, а из-за качества модели, калибровки и задержки в вашем проде. Всё остальное — маркетинг. Бэкапы делайте в любом случае.