**Серия: Бэкенды на Node.js и TypeScript**

Несколько дней назад TypeSafe AI представила [Jev](https://typesafe.ai/blog/introducing-system-one-models-and-jev) — новую модель, предназначенную для быстрых структурированных решений, которые ПО может использовать напрямую.

Прочитав анонс, я задался вопросом: хайп это, полезный инструмент или угроза для разработчика? Jev также напомнил мне эндпоинты «structured outputs» из REST API OpenAI. Мне стало интересно, даёт ли Jev какие-либо преимущества перед OpenAI.

## Что на самом деле делает Jev

Jev (от TypeSafe AI) относится к классу узкоспециализированных моделей, которые возвращают структурированные результаты, а не просто текст. На вход он принимает состояние приложения, а на выходе выдаёт структурированные решения. Возможные результаты и их типы задаются заранее.

Например, приложение может передать данные о клиенте и попросить Jev классифицировать риск оттока, определить, в какой отдел поддержки направить запрос, или оценить потенциальную бизнес-возможность.

TypeSafe AI заявляет, что Jev даёт несколько преимуществ:

- Время отклика 70–500 мс. - Стоимость входных токенов \$0,042 за миллион. - Гарантированное соответствие предопределённым типам выходных данных. - Откалиброванные вероятности и оценки уверенности, сопровождающие решения.

Компания также утверждает, что по скорости и стоимости Jev существенно превосходит существующие LLM, выполняющие аналогичные задачи.

Заявленные характеристики — от самой компании, я Jev пока не тестировал.

## Jev против Structured Outputs от OpenAI

OpenAI представила Structured Outputs в августе 2024 года: с параметром strict: true можно задать JSON Schema и получать ответы по схеме. Классифицировать данные, выбирать значения из перечислений, извлекать структурированную информацию — для этих сценариев Jev даёт по сути те же возможности.

Механизм генерации, лежащий в основе Jev (он генерирует выходные решения параллельно и предоставляет связанные вероятности — оценки уверенности), интересен, но судить о преимуществе Jev по деталям реализации особых оснований нет.

Практический вопрос для бэкенд-инженера — выдаёт ли Jev решения сопоставимой точности, быстрее и дешевле. Они заявляют, что да. Но с OpenAI тоже можно выбрать значительно более дешёвую модель, которая хорошо справляется со структурированными результатами при кэшированном контексте.

## Jev: полезен ли в реальных бэкенд-системах?

В стартапе по аналитике я строил LLM-конвейеры, которые классифицировали входящие данные через контролируемые словари и выдавали структурированные результаты. Я использовал детерминированные валидационные шлюзы для проверки выходных данных модели. Jev мог бы вписаться сюда — например, для классификации записей или расчёта оценок.

С [GPT-4o Mini](https://developers.openai.com/api/docs/models/gpt-4o-mini) (дешевле, чем GPT Luna, с которой сравнивают Jev) я получил отличные результаты по скорости и стоимости.

Оценки уверенности Jev могут пригодиться там, где приложению нужно решить — принять решение модели или направить на дальнейшую обработку. Но они могут вводить в заблуждение, а значит, потребуют дополнительных валидационных шлюзов и усложнят рабочий процесс.

Мой вывод: Jev заслуживает A/B-тестирования на продакшен-нагрузках в сравнении со Structured Outputs от OpenAI. При миллионах запросов он может дать преимущество.

## Инструмент или замена инженера

Это был мой изначальный вопрос. Работа старшего бэкенд-инженера — это архитектура, API, базы данных, распределённые системы и бизнес-процессы с классификацией и скорингом.

Jev мог бы автоматизировать часть решений — как и Structured Outputs от OpenAI. Но угрозы инженерному процессу он не представляет. Ответ — «инструмент», альтернативы которому существуют уже около двух лет.

## Мой вывод

Изучив Jev и сравнив с Structured Outputs от OpenAI, я вижу в нём потенциально полезное дополнение к бэкенд-арсеналу — но преимущества ещё предстоит доказать на реальных бизнес-нагрузках и сопоставить с затратами на замену существующих вызовов LLM.