Что такое Jev: руководство Vercel по ограниченным решениям с типами и вероятностями
Jev — это System One-модель от TypeSafe AI, доступная через Vercel AI Gateway. В отличие от обычной LLM, она не генерирует текст: на вход принимает состояние и вопросы, а на выходе возвращает типизированные решения с вероятностями. Пространство возможных ответов задаёт ваше приложение — и ваш же код решает, действовать ли по полученному результату. Jev может, например, выдать решение о маршрутизации, но применить его или нет — определяет ваша логика.
Что значит System One
Название отсылает к различению Даниэля Канемана между быстрым интуитивным мышлением (System 1) и медленным обдумыванием (System 2). Для разработчика важнее не метафора, а интерфейс: вы формулируете вопрос с ограниченным пространством ответов, а потом решаете, как приложение использует результат.
Что такое ограниченное решение
Представьте отчёт об инциденте: после изменения конфигурации перестали проходить запросы на оформление заказа, дежурный приложил фрагмент лога и отметил, что просмотр каталога работает. Команда хочет автоматически назначать ответственного, не заставляя человека читать каждый входящий алерт.
Сначала разделите свидетельства и вопрос. Отчёт и фрагмент лога — это свидетельства. Вопрос может звучать так: какая команда должна разбираться — с заранее заданным списком команд. Тогда у приложения появляется ответ, который можно сравнить с правилами маршрутизации.
Jev принимает текст, JSON-объекты и массивы. Для примера можно собрать запись с текстом отчёта и наблюдениями дежурного. К каждому наблюдению стоит добавить метку времени, чтобы более поздний отчёт не выглядел описанием того же момента. Формулировку сомнительных наблюдений сохраняйте как есть: если дежурный подозревает проблему с конфигурацией, это гипотеза, а не подтверждённая причина.
Расплывчатый вопрос вроде «разберись с этим инцидентом» оставляет слишком много неопределённым. Что значит «разобраться» — назначить владельца, вызвать дежурного или менять прод? «Выбрать владельца» — ограниченное решение, потому что у ответа есть определённое место в приложении. Хороший тест: вопрос сформулирован достаточно узко, если два ревьюера согласились бы, как выглядит правильный ответ.
Важно: массив, переданный как состояние, остаётся одним общим состоянием. Это не превращает вызов в батч независимых оценок. Список наблюдений с метками времени относится к одному событию, поэтому их можно передать вместе. А вот разные инциденты в этот список класть не стоит — размывается, к какому свидетельству относится вопрос. Каждому несвязанному инциденту — свой контекст оценки.
Как задавать возможные ответы
Описания категорий пишите до сбора предсказаний. Для инцидента предположим: payments отвечает за сбои, когда запрос уже дошёл до платёжного сервиса, а storefront — за сбои, из-за которых запрос вообще не покидает страницу. Это различие можно проверить по наблюдаемым фактам. А вот метки вроде urgent и important пересекаются и вопрос владения не решают.
Если рабочий процесс этого требует, добавьте вариант «недостаточно данных». В нашем примере отчёт никак не говорит, дошёл ли запрос до платёжного сервиса. Принуждать выбирать между payments и storefront значило бы скрыть этот пробел — категория на ревью даёт способ его сохранить.
Формулировка вопроса должна соответствовать категориям. «Какая команда должна разбираться первой?» допускает предварительное назначение. «Какая команда вызвала сбой?» требует вывода, который свидетельства могут не подтверждать. Это разные решения, даже если в обоих случаях ответы — названия команд.
Какие типы ответов можно запрашивать
Через native API AI Gateway и AI SDK доступны следующие типы:
| Тип | Смысл | Вопрос из инцидента |
|---|---|---|
| Choice | Выбор опции | Какая команда владеет разбором? |
| Score | Оценка по рубрике | Насколько критично воздействие? |
| Boolean | Вероятность истинности | Описывает ли отчёт неуспешные покупки? |
Вопросы решают разные задачи. Метка владельца указывает адресата. Для рубрики критичности нужно определение «критично» — например, может ли клиент завершить оформление. Boolean-вопрос касается конкретного утверждения в свидетельствах. Не позволяйте одному ответу подменять остальные: то, что отчёт назначен команде payments, ещё не доказывает, что клиенты потеряли деньги.
Jev оценивает независимые вопросы вместе: владение и критичность можно спросить по одним свидетельствам, и ни одному вопросу не нужен ответ другого.
Как выглядит инспектируемый след решения
Продолжим тот же инцидент с новым наблюдением: дежурный видит, что запросы на покупку доходят до платёжного сервиса, а следом возникают ошибки. Концептуальная запись ниже использует придуманные значения, чтобы показать, как может выглядеть проверяемый результат. Это не формат API-ответа.
| Часть записи | Гипотетическое значение | Что проверяет ревьюер |
|---|---|---|
| Свидетельства | Запросы на покупку доходят до платёжного сервиса и падают | Приложенный фрагмент лога и его метка времени |
| Вопрос | Какая команда должна разбираться первой? | Спрашивается владение или доказанная причина |
| Допустимые ответы | payments, storefront, недостаточно данных | Описания категорий команды |
| Предложенный ответ | payments | Следует ли выбор из определения владения |
| Иллюстративные вероятности | payments 0.70; storefront 0.20; недостаточно данных 0.10 | Как вероятность распределена по опциям |
| Итог приложения | Отчёт попал в очередь ревью payments | Записанное правило маршрутизации |
Такая запись отделяет правдоподобное первичное назначение от диагноза. Она же делает понятной последующую коррекцию: если выяснится, что фрагмент лога относится к более раннему деплою, ревьюер сможет указать, какие именно устаревшие свидетельства повлияли на назначение. Храните свидетельства вместе с ответом — тогда метка владельца не превратится в неподтверждённый факт при копировании в другую систему.
Чем это отличается от structured output LLM
AI SDK evaluation поддерживает нативную TypeSafe-оценку и адаптеры для моделей со структурным выводом. Адаптеры складывают все вопросы в один промпт и не сохраняют семантику независимых вопросов TypeSafe.
Совпадение формы результата, таким образом, не означает совпадения поведения оценки. В примере с инцидентом команда может оставить поле владельца без изменений, просто сменив модель, на которую оно указывает. Сравнивать приложение станет проще, но ревью всё равно нужно проверять назначения: неизменное имя поля ничего не говорит о том, получит ли тот же неоднозначный отчёт тот же ответ.
Гарантирует ли типизация правильность решения
TypeSafe заявляет, что выходы Jev соответствуют заданной схеме. Эта гарантия касается структуры ответа. Семантическая правильность требует отдельной оценки.
Пусть допустимые владельцы — payments и storefront. Ответ payments удовлетворяет ограничению типа, но если реальная причина — сломанный скрипт storefront, разбор уйдёт не в ту команду.
Прежде чем автоматизировать маршрутизацию, оцените назначения владельцев на уже разобранных инцидентах — включая отчёты с недостающими свидетельствами и неоднозначным владением. На этих результатах можно выбрать порог маршрутизации, балансирующий ошибки назначения и нагрузку на ручное ревью.
Когда Jev встроен в цикл агента, политику и исполнение держит код приложения. Например, предложенный владелец может попадать во внутреннюю очередь, но любое изменение прода требует подтверждения дежурного. Такое правило живёт в приложении: выбор владельца не должен незаметно получать право откатывать деплой.
Границы Jev
- Jev не генерирует прозу. Для письменного обновления об инциденте используйте генеративную модель, передав ей свидетельства и утверждённые решения отдельно. Ответа о маршрутизации недостаточно, чтобы объявить, что сбой устранён.
- Входы сейчас текстовые: картинки и аудио напрямую не анализируются. Подготовьте текстовое описание или транскрипт.
- Вызывается через Vercel AI Gateway с помощью экспериментального evaluation API из AI SDK. Документация описывает, как передавать контекст, определять вопросы и читать результаты.
Полезные ссылки:
Источник: https://vercel.com/i/what-is-jev