blog

Используйте ИИ разумнее с Jev

NEXTREE.

• 15 min read
Используйте ИИ разумнее с Jev

Введение: не слишком ли часто мы используем LLM?

За последние несколько лет разработка приложений на основе ИИ фактически вращалась вокруг LLM (больших языковых моделей). Когда пользователь задаёт вопрос, мы отправляем его в LLM; когда анализируем документ, отправляем его в LLM; когда классифицируем электронные письма, отправляем их в LLM; а когда Агенту нужно решить, какое действие выполнить следующим, мы снова обращаемся к LLM.

LLM чрезвычайно мощны. Они умеют понимать естественный язык, писать тексты, генерировать код, обобщать и рассуждать о сложном содержимом. Проблема в том, что мы используем LLM даже там, где в них нет необходимости.

Например, предположим, что мы получили от клиента следующее электронное письмо.

"I was charged twice. Please refund the duplicate payment as soon as possible."

Что, если единственные три вещи, которые мы хотим узнать, таковы?

  • Относится ли этот запрос к отделу расчётов или к технической поддержке?

  • Является ли запрос срочным?

  • Насколько раздражён клиент?

Используя традиционную LLM, мы могли бы задать следующий запрос.

Analyze the following customer message.

1. Determine the category.
2. Determine whether it is urgent.
3. Evaluate the customer's frustration level.

Return the result as JSON.

LLM, безусловно, способна решить эту задачу. Но на самом деле нам нужно не длинное объяснение, а такие значения.

category = billing
urgent = 0.91
frustration = 1.7

Иными словами, нам нужно решение, а не генерация. Однако для этого небольшого решения мы вызываем универсальную генеративную модель, составляем промпт, инструктируем её использовать формат JSON, разбираем результат, проверяем схему и даже обрабатываем исключительные случаи.

Jev, выпущенная TypeSafe AI в сентябре 2026 года, — это модель, созданная именно с этой точки зрения. TypeSafe называет Jev своей первой моделью System One. Вместо генерации длинных предложений на основе естественного языка или состояния приложения на входе она возвращает типизированное вероятностное решение, которое программное обеспечение может использовать напрямую — иными словами, определённое типом суждение, основанное на вероятности.

Главная мысль, которую я хочу обсудить в этой статье, проста. Речь не о том, что нам не следует использовать LLM; речь о том, чтобы не заставлять LLM принимать решения, для которых они не нужны. В дальнейшем разработчики, создающие качественные приложения на основе ИИ, вероятно, будут отличаться не использованием самых мощных моделей, а умением определять, какие задачи следует поручать каким типам ИИ.

1. Что такое Jev?

Jev — первая модель System One, выпущенная TypeSafe AI. TypeSafe объясняет, что взяла название System One из концепции System 1, описанной в книге Даниэля Канемана «Думай медленно… решай быстро». В основе лежит идея разделения человеческого мышления на быструю, интуитивную Систему 1 и медленную, рассудительную Систему 2. TypeSafe также утверждает, что название Jev происходит от имени экономиста Уильяма Стэнли Джевонса.

Если значительно упростить типичную LLM, её можно представить следующим образом.

Input
  ↓
LLM
  ↓
Text Generation
  ↓
"Based on the information provided,
 this customer seems to..."

В отличие от неё, Jev ближе к следующей модели.

State
  ↓
Jev
  ↓
Typed Decision
  ↓
billing : 0.97
urgent : 0.91

Заимствуя терминологию TypeSafe, Jev представляет собой разновидность «вызова функции пограничного интеллекта». Иными словами, ИИ используется не как собеседник для людей, а как примитив программирования.

unstructured state
        ↓
      Jev
        ↓
typed probabilistic decisions

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

LLM → Text → Human
Jev → Decision → Code

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

2. Три типа решений, предоставляемых Jev

2.1 Choice

Choice выбирает один вариант из нескольких кандидатов. Например, предположим, что мы классифицируем запросы клиентов следующим образом.

billing
technical
sales
other

Если спросить Jev: «Какой отдел должен обработать этот запрос?», можно получить выбранный элемент вместе с вероятностью каждого варианта.

choice = billing

billing 0.93
technical 0.04
sales 0.01
other 0.02

Choice особенно полезен для таких задач, как классификация запросов, классификация документов, выбор инструментов Агента, маршрутизация моделей, определение намерений и маршрутизация событий.

2.2 Score

Score определяет несколько упорядоченных критериев и вычисляет оценку среди них. Например, уровень раздражения клиента можно определить следующим образом.

0 = Calm
1 = Frustrated
2 = Very Angry

Затем мы спрашиваем: «Насколько раздражён клиент?» Результат не обязан быть равен одному из значений 0, 1 или 2; его можно выразить промежуточным значением, например score = 1.63.

Поэтому Score хорошо подходит для задач, связанных со срочностью, риском, релевантностью, качеством, приоритетом, уровнем раздражения клиента и важностью документа.

if score > 1.5
    → priority queue
else
    → normal queue

2.3 Noul

Самым непривычным термином является Noul. Noul — не опечатка, а название примитива, которое TypeSafe использует в своём реальном API. Проще говоря, он возвращает вероятность ответа Yes для вопросов, предполагающих ответ Yes/No.

Does this customer require an immediate response?

→ 0.92

Вероятностное значение полезнее простого Boolean, поскольку позволяет создавать более детализированные политики приложения.

0.90 이상      → 자동 처리
0.60 ~ 0.90   → 사람이 확인
0.60 미만      → 처리하지 않음

Иными словами, вместо того чтобы заставлять ИИ принимать все решения, ИИ предоставляет вероятность, а фактическая политика определяется кодом. Именно это делает Jev особенно интересной с точки зрения разработчика.

3. Так в чём же различие между LLM и Jev?

Сначала нужно развеять одно важное заблуждение. Было бы неточно упрощать различие, говоря: «LLM возвращают только строки, тогда как структурированные значения возвращает только Jev». Современные LLM поддерживают Structured Output, JSON Schema, Function Calling, Tool Calling и многое другое. С помощью LLM вполне можно создать интерфейс, подобный Choice.

Различие заключается в назначении и структуре модели. Jev с самого начала ориентирована на роль примитива принятия решений, который быстро возвращает суждения в ограниченном формате.

Категория

LLM

Jev

Основное назначение

Генерация, диалог, рассуждение

Решение

Типичный результат

Текст / код / JSON

Choice / Score / Noul

Гибкость вывода

Очень высокая

Предопределённый диапазон

Подходящие потребители

Люди + программы

В основном программы

Написание предложений в свободной форме

Очень сильный

Неподходящий

Классификация/оценка

Возможно

Основное назначение

Вероятность результатов

Часто требует отдельного проектирования

Ядро интерфейса модели

Небольшие решения, принимаемые Agent

Возможно, но может быть относительно ресурсоёмким

Высоко подходит

Творческая работа/суммирование/генерация кода

Подходит

Неподходящий

Проще говоря, LLM — это ИИ, который что-то создаёт, тогда как Jev ближе к ИИ, который определяет, что делать. Разумеется, фактическая роль LLM гораздо шире, но уже одного такого разделения ролей вполне достаточно, чтобы упростить проектирование архитектуры приложения.

4. Главная причина, по которой Jev привлекает внимание: скорость и стоимость

При эксплуатации сервиса на основе ИИ поначалу обычно сосредотачиваются только на интеллекте модели. Однако по мере роста сервиса важными становятся такие эксплуатационные характеристики, как задержка, стоимость, пропускная способность и надёжность. В частности, Agent может вызывать ИИ несколько раз для обработки одного пользовательского запроса.

현재 화면 분석
    ↓
어떤 행동을 할지 판단
    ↓
버튼 선택
    ↓
다음 화면 확인
    ↓
다음 행동 판단
    ↓
...

Для выполнения одной задачи может потребоваться 10, 20 или 50 решений. Если для каждого решения вызывать высокопроизводительную LLM, стоимость токенов и задержка накапливаются.

Цена Jev, объявленная TypeSafe в сентябре 2026 года, на тот момент составляла $0.042 за 1 миллион входных токенов, без отдельной платы за выходные токены. Заявленный компанией диапазон времени ответа составлял примерно 70–500 мс. Однако эти показатели могут различаться в зависимости от окружения, длины входных данных, сети и рабочей нагрузки, поэтому их не следует интерпретировать как гарантию одинаковой производительности в любой ситуации.

Тем не менее структурное различие очевидно. Если приложению нужны только такие значения, как billing, 0.92 и 1.71, более естественным выбором может быть модель, которая не генерирует длинные объяснения. Отказ от генерации ненужного вывода сам по себе является оптимизацией.

5. Где Jev можно использовать на практике?

После выпуска Jev появились различные эксперименты, включая классификацию электронной почты, Browser Agent, анализ рекламы, классификацию научных статей и автоматическую организацию файлов. Приведённые ниже показатели стоимости и скорости опубликованы создателями каждого демо для их собственных окружений, поэтому их не следует рассматривать как стандартные бенчмарки, полученные в идентичных условиях.

5.1 Автоматическая классификация 500 электронных писем

В одном общедоступном демо 500 электронных писем были классифицированы по категории, срочности, необходимости ответа и другим критериям. Создатель сообщил, что стоимость Jev составила примерно $0.035.

Inbox
  ↓
Jev
  ├─ 중요?
  ├─ 답장 필요?
  ├─ 업무 관련?
  └─ 긴급?
  ↓
Priority Queue
  ↓
필요한 메일만 LLM에게 전달
  ↓
답장 초안 생성

Ключ к этой структуре заключается не в устранении LLM, а в сокращении числа вызовов, чтобы использовать её только там, где LLM действительно необходима.

5.2 Browser Agent

Browser Agent — хороший пример для понимания характеристик Jev. В одном общедоступном проекте анализировался DOM веб-страницы, а Jev был настроен на выбор следующего действия.

CLICK
TYPE_TEXT
SELECT
SCROLL_UP
SCROLL_DOWN
WAIT
DONE
BLOCKED

Интересно, что LLM используется только в таких ситуациях, как TYPE_TEXT, когда действительно требуется сгенерировать текст.

Decision        → Jev
Text Generation → LLM
Browser Operation→ Code

В общедоступном демо поиска Google Flights для поездки из Цюриха в Лондон общее время выполнения составило примерно 7.1 секунды, а стоимость Jev — примерно $0.0039. Этот пример ясно показывает, что весь Agent не обязательно должен представлять собой одну огромную LLM.

5.3 Анализ 724 рекламных объявлений

В другом общедоступном демо 724 рекламных объявления 37 брендов анализировались по таким критериям, как Hook, Format, Offer, CTA и Awareness Stage. Создатель сообщил о результате примерно в 40 секунд и стоимости Jev примерно $0.09.

Когда стоимость единичной оценки с помощью ИИ становится достаточно низкой, рабочие процессы могут измениться: вместо анализа только некоторых выборок становится возможным анализировать все доступные данные. Это более значимое изменение, чем простое снижение стоимости, поскольку оно позволяет решать задачи, от которых ранее отказывались из-за затрат.

5.4 Классификация 1 018 научных статей об ИИ

Существует также общедоступный пример, в котором 1 018 статей, посвящённых ИИ, были классифицированы по 24 темам. В этом случае LLM отвечала за суммирование статей, а Jev — за классификацию в соответствии с заранее определённой таксономией.

Paper
   ↓
LLM
   ↓
Summary
   ↓
Jev
   ↓
24개 Topic 중 하나 선택

Создатель сообщил, что стоимость классификации с помощью Jev составила примерно $0.08, а медианная задержка — примерно 256 мс на статью. Однако общий конвейер также включал отдельные расходы на суммирование с помощью LLM. Главный вывод этого примера заключается в том, что не каждую задачу ИИ необходимо решать с помощью одной модели.

6. Используем Jev в коде

TypeSafe выпустила SDK для Python и JavaScript/TypeScript. Пакет SDK для Python называется typesafe-sdk, а в официальном примере состояние и вопросы передаются в system_one().

uv add typesafe-sdk

export TYPESAFE_API_KEY="..."

Ниже приведён пример, который классифицирует обращения клиентов и определяет их срочность и степень раздражения.

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

state = {
    "message": "I was charged twice. "
               "Please refund the duplicate payment today."
}

questions = {
    "category": Choice(
        instructions="What is this customer request about?",
        criteria={
            "billing": "Payment, refund or charge related issue",
            "technical": "Technical problem",
            "sales": "Sales or pricing inquiry",
            "other": "Anything else"
        }
    ),

    "urgent": Noul(
        instructions="Does this request require urgent attention?"
    ),

    "frustration": Score(
        instructions="How frustrated does the customer appear?",
        criteria=["Calm", "Frustrated", "Very angry"]
    )
}

with TypeSafeClient() as client:
    response = client.system_one(
        state=state,
        questions=questions
    )

category = response.choices["category"].choice
urgent = response.nouls["urgent"].noul
frustration = response.scores["frustration"].score

Концептуально предположим, что результаты имеют вид category = billing, urgent = 0.94 и frustration = 1.32. После этого политики можно применять с помощью обычного программного кода.

if urgent > 0.90:
    priority = "HIGH"
elif urgent > 0.60:
    priority = "MEDIUM"
else:
    priority = "NORMAL"

Важно не позволять Jev также определять бизнес-политики. Jev предоставляет сигналы, необходимые для принятия решения, а фактические политики обрабатываются кодом.

AI   → Probability
Code → Business Rule

7. В TypeScript это ещё очевиднее

В SDK для TypeScript форму возвращаемого результата также можно чётко различать в зависимости от типа вопроса. Пример выглядит следующим образом.

import { choice, noul, score, TypeSafeClient }
  from "@typesafe-ai/sdk";

const client = new TypeSafeClient();

const result = await client.systemOne({
  state: {
    message: "I was charged twice. " +
             "Please refund the duplicate payment today."
  },
  questions: {
    category: choice(
      "Which department should handle this?",
      {
        billing: "Payment and refund issues",
        technical: "Product or technical issues",
        sales: "Pricing and sales",
        other: "Anything else"
      }
    ),
    urgent: noul(
      "Does this request need urgent attention?"
    ),
    frustration: score(
      "How frustrated is the customer?",
      ["Calm", "Frustrated", "Very angry"]
    )
  }
});

С точки зрения разработчика структура Typed Question → Jev → Typed Decision → Application может показаться гораздо естественнее, чем структура String Prompt → AI → String Response → Parsing → Validation → Application.

8. Как Java-разработчикам использовать Jev?

Официально выпущенные TypeSafe основные SDK в настоящее время предназначены для Python и JavaScript/TypeScript, а для Java появляются SDK, созданные сообществом, и проекты интеграции со Spring AI. Однако, поскольку сам API Jev использует REST, Java не обязательно требует отдельного SDK.

Основной API имеет вид POST /v1/systemone, а запросы включают model, state и questions. Java-разработчики могут легко обернуть его с помощью HttpClient, Jackson, Spring RestClient или WebClient.

interface DecisionService {
    TicketDecision classify(CustomerMessage message);
}

record TicketDecision(
        String category,
        double urgentProbability,
        double frustrationScore
) {}

Если вместо того, чтобы позволить вызовам API Jev напрямую распространяться по коду приложения, добавить абстракцию, как показано выше, приложению не нужно знать, используется ли за кулисами Jev или другая Decision Model. Это также выгодно при последующей замене модели или провайдера.

9. Лучший способ использовать Jev: не пытайтесь устранить LLM

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

Decision   → Jev
Generation → LLM
Execution  → Code
Review     → Human

Именно это сочетание делает Jev особенно интересным. Каждый инструмент берет на себя ту роль, для которой он подходит лучше всего.

10. Маршрутизация моделей становится более важной в эпоху мультиагентных систем

В будущем агентные системы будут становиться все сложнее. Вместо того чтобы поручать одному Агенту выполнение всех задач, они, скорее всего, будут объединять несколько Инструментов и Моделей.

User Request
     ↓
Jev
     ↓
Task Complexity
     │
     ├── Simple → Small Model
     ├── Medium → General LLM
     └── Complex → Frontier Model

Нет необходимости отправлять каждый вопрос самой дорогой и мощной модели. Вместо этого саму AI-систему можно спроектировать так, чтобы она сначала определяла: «Сложна ли эта проблема?», «Нужен ли поиск?», «Требуется ли одобрение человека?» и «Необходимо ли отправить это высокопроизводительной модели?»

В прошлом разработчики проектировали Классы, Методы, Базы данных, API, Транзакции и События. В эпоху AI им также необходимо проектировать Архитектуру принятия решений. Иными словами, важным станет умение различать, какие решения должны приниматься кодом, какие — Jev, какие — LLM, а какие — человеком.

11. Не будем превращать AI в одну гигантскую функцию

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

isSpam()
    ↓
category()
    ↓
urgency()
    ↓
needsReply()
    ↓
route()
    ↓
generateReply()

Предшествующий этап принятия решения может обрабатываться Jev, route() — кодом, а с помощью LLM можно выполнять только финальную generateReply(). Преимущество такой структуры не только в том, что она дешевле и быстрее, но и в том, что она упрощает отладку и тестирование.

12. Но Jev тоже может ошибаться

То, что Jev предоставляет типизированный результат, не означает, что его решения всегда точны. Например, в вопросе «Является ли это письмо фишинговым?» возврат ответа в правильном формате и точное определение того, действительно ли письмо является фишинговым, — совершенно разные задачи.

Schema correctness ≠ Semantic correctness

Поэтому важно включать значения вероятности в политики приложения.

High Confidence   → Automatic Action
Medium Confidence → Strong LLM / Additional Check
Low Confidence    → Human Review

Истинное преимущество модели, предоставляющей вероятности, заключается не в том, что AI отвечает уверенно, а в том, что программное обеспечение может учитывать неопределенность в своих политиках.

13. Где не следует использовать Jev

Тот факт, что Jev привлекает внимание, не означает, что добавлять его повсюду — хороший подход к проектированию. LLM гораздо лучше подходят для написания документов, таких как отчеты, электронные письма и блоги; обобщения длинных документов; генерации кода; объяснения причин ошибок; а также решения сложных стратегических задач с открытым набором вариантов.

И наоборот, Jev особенно стоит рассматривать для задач, где диапазон возможных ответов относительно ограничен: например, является ли что-либо A или B, к какой Категории это относится, насколько это важно, какой Инструмент следует выполнить, в какую Модель это следует отправить и требуется ли подтверждение человека.

14. Наибольшая ценность Jev с точки зрения разработчика

Если считать, что интерес к Jev объясняется лишь низкой стоимостью токенов, можно упустить самую суть. Гораздо важнее то, как AI внедряется в программы.

기존 방식
Application → Prompt → LLM → Text

Decision Model 방식
Application State → Decision Primitive → Probability → Application Logic

Последняя структура хорошо знакома разработчикам. Мы уже десятилетиями пишем такой код, как if (condition) { execute(); }. Jev можно рассматривать как инструмент, который привносит в программы нечеткие условия, ранее трудно поддававшиеся выражению в коде.

if (jev("Is this request urgent?") > 0.9) {
    escalate();
}

15. Значение выражения «хорошо использовать AI» тоже меняется

До сих пор, когда говорили о человеке, который хорошо использует AI, часто имели в виду специалиста по Prompt Engineering. Однако по мере распространения Агентов и AI-автоматизации, вероятно, будут меняться и навыки, которые имеют значение.

  • Можно ли решить эту проблему с помощью детерминированного кода?

  • Действительно ли здесь необходимо решение AI?

  • Если AI необходим, нужен ли он для генерации или для принятия решений?

  • Будет ли достаточно небольшой модели?

  • Необходима ли Frontier Model?

  • Если вероятность мала, кому следует передать задачу на дальнейшее рассмотрение?

  • Какие решения обязательно должны подтверждаться человеком?

Иными словами, проектирование оркестрации AI в целом станет важнее, чем умение хорошо использовать одну модель.

16. Рекомендуемая архитектура AI

Это можно кратко выразить следующим простым принципом.

LLM   → 생성합니다.
Jev   → 판단합니다.
Code  → 실행합니다.
Human → 중요한 결정을 검토합니다.

В этой структуре ни одна конкретная модель не доминирует во всей системе. Каждый инструмент обрабатывает то, что он умеет делать лучше всего.

Заключение: давайте использовать наиболее подходящий AI, а не самый мощный AI

Jev всё еще является очень новой технологией. TypeSafe открыла Jev для общего доступа в сентябре 2026 года, а ее экосистема, API и инструменты также быстро меняются. Поэтому не следует считать, что текущие цены, производительность или состояние SDK сохранятся в неизменном виде в долгосрочной перспективе.

Тем не менее вопросы, которые поднимает Jev, весьма важны. Почему мы пытаемся решать каждую задачу AI с помощью одной LLM?

LLM — удивительные инструменты. Однако нет необходимости генерировать длинное предложение лишь для того, чтобы решить, в какую папку отправить электронное письмо. Также нет необходимости каждый раз ждать длительного рассуждения огромной Frontier Model, чтобы определить, какую кнопку Агент должен нажать следующей.

Если задача требует лишь выбрать одного кандидата из заранее определенного набора, можно использовать Choice. Если требуется ответ «да» или «нет», можно использовать Noul, а если нужно оценить степень или уровень, можно использовать Score. Затем, когда действительно понадобится написать текст, создать код или решить сложную задачу, можно использовать LLM.

Generation → LLM
Decision   → Jev
Execution  → Code
Review     → Human

Интеллектуальное использование AI не означает, что нужно всегда вызывать самую интеллектуальную модель. Более важным принципом проектирования может стать использование ровно такого объема Интеллекта, который требуется задаче.

Делегирование многочисленных небольших решений быстрым и недорогим Моделям принятия решений при использовании мощных LLM только для действительно сложных задач особенно важно в средах Multi-Agent и AI Orchestration.

В будущем разработчикам, возможно, придется спрашивать не «Какой AI лучше?», а «Какой AI лучше всего подходит для обработки этого решения?» Появление Jev задает нам именно этот вопрос.

Источники

1. TypeSafe AI, «Introducing System One Models & Jev», 2026-09-15. https://typesafe.ai/blog/introducing-system-one-models-and-jev

2. Официальный веб-сайт TypeSafe AI / Jev. https://typesafe.ai/

3. Справочник API TypeSafe. https://api.typesafe.ai/docs

4. Python SDK TypeSafe AI. https://github.com/typesafe-ai/typesafe-sdk-python

5. JavaScript/TypeScript SDK TypeSafe AI. https://github.com/typesafe-ai/typesafe-sdk-js

6. TypeSafe Workflow Evals. https://evals.typesafe.ai/

7. Browser Use, jev-ultrafast. https://github.com/browser-use/jev-ultrafast

8. Демонстрация классификации электронных писем Jev от сообщества. https://madewithjev.com/categories/triage-and-routing

9. Демонстрация классификации Jev на 1k Papers. https://jev.gorock.sh/projects/1k-papers

10. 724 Ads Jev Demo.https://systemonemodels.org/examples/discussions/breaking-down-724-ads-from-37-brands-with-jev/

11. Сообщество Spring AI, проект интеграции TypeSafe/Jev.https://github.com/spring-ai-community/spring-ai-typesafe

※ Информация о ценах, задержке и API в этой статье собрана на основе общедоступных данных по состоянию на 24 сентября 2026 года. Поскольку Jev — сервис, который существует в открытом доступе относительно недолго, при его фактическом внедрении рекомендуется ещё раз проверить последнюю официальную документацию TypeSafe, ценовую политику и версии моделей.

syhan

Site footer