Что такое Jev и какие задачи принятия решений стоит перенести с LLM: разбор тестов, сценарии и границы интеграции

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

Она не ведёт диалог, не пишет код и не генерирует длинные объяснения. Вы передаёте ей state, задаёте несколько вопросов и допустимые варианты ответа, а она возвращает результаты Choice, Score или Noul вместе с соответствующими распределениями вероятностей. TypeSafe называет такие модели System One Models: их задача — не строить длинную цепочку рассуждений, а быстро и многократно принимать решения с чёткими границами.[1][3]

Поэтому Jev не стоит считать «более дешёвым ChatGPT». Её естественное место — между детерминированным кодом и генеративными LLM:

• код обрабатывает суммы, даты, счётчики, права доступа, конечные автоматы и другие правила, которые можно вычислить точно;
• Jev отвечает за неоднозначные семантические решения: «к какой категории относится этот текст», «связана ли запись с задачей», «насколько срочен запрос»;
• генеративные LLM формируют открытые ответы, строят сложные планы, выполняют многошаговые рассуждения, создают код и текст;
• человек разбирает исключения с высоким риском, необратимыми последствиями или низкой уверенностью модели.

Jev была представлена 15 сентября 2026 года основателем TypeSafe Диогу Алмейдой. По информации TypeSafe, ранее Алмейда работал в OpenAI над методами, благодаря которым языковые модели лучше следуют инструкциям и поддерживают диалог. Название System One отсылает к «Системе 1» из книги «Думай медленно… решай быстро», а Jev — к парадоксу Джевонса: если одно интеллектуальное решение дешевеет на порядок, спрос может не уменьшиться пропорционально — вместо этого появляются новые задачи, для которых раньше вызов модели был неоправдан.[1]

По состоянию на 21 сентября 2026 года в документации TypeSafe стабильной версией значилась jev-1.13.0. Прямой API стоил 0,042 доллара за миллион входных токенов, выходные токены не тарифицировались; опубликованные стандартные лимиты составляли 250 000 токенов в секунду и 1200 запросов в минуту. Максимальный объём одного запроса — 64k токенов, при этом суммарный объём state и самого длинного вопроса ограничен 32k. Модель принимает только текст. Основной язык обучения — английский, и именно на нём текущая точность выше всего.[2]

В публикации о запуске указан диапазон сквозной задержки 70–500 миллисекунд. TypeSafe также утверждала, что на запросах, подходящих для System One, Jev может быть в 40–200 раз быстрее сопоставимых генеративных моделей. При этом компания уточнила, что публичные оценки обычно запускались с ноутбука на западном побережье США. Поэтому эти значения следует считать результатами поставщика для конкретных задач и сетевых условий, а не гарантированной задержкой для любого региона и любого ввода.[1]

Параметры выглядят привлекательно, но сами по себе не доказывают пользу миграции. Главный вопрос другой: снижает ли дешёвое решение стоимость и число ошибок всего процесса или лишь переносит ошибки на более дорогую модель, ручную проверку либо бизнес-инцидент.

Сначала выберите правильный слой: что поручать коду, Jev и генеративной LLM

Для первичного отбора задач можно использовать эту таблицу.

Задача	Наиболее подходящий исполнитель	Почему
Рассчитать сумму возврата, сравнить даты, посчитать события	Детерминированный код	Есть единственный правильный результат; код быстрее, дешевле и проще тестируется
Определить, относится ли обращение к оплате, технической поддержке или аккаунту	Choice в Jev	Набор ответов ограничен, но требуется понимание естественного языка
Определить, связан ли фрагмент поиска с текущей задачей	Noul в Jev	По сути это вероятностное семантическое решение «да или нет»
Оценить силу жалобы, уровень риска или качество ответа	Score в Jev	Подходит упорядоченная шкала, объяснение генерировать не нужно
Написать письмо, сгенерировать код, составить многошаговый план	Генеративная LLM	Пространство ответов открыто, требуется создавать и организовывать новый материал
Рассуждать по нескольким документам, проводить сложный причинный анализ	Генеративная или reasoning-модель	Нужны многошаговые рассуждения, а не одно атомарное решение
Автоматически вернуть деньги, удалить данные, выполнить перевод средств	Кодовые правила плюс подтверждение или человек	Результат классификации не заменяет авторизацию, контроль риска и окончательное подтверждение

Задачу стоит в первую очередь тестировать с Jev только при одновременном выполнении трёх условий:

1. Результат можно перечислить заранее. Например, billing / technical / account / other, а не свободный текст.
2. Решение можно разложить на атомарные вопросы. Во входе уже есть нужная информация; от модели не требуется длинная цепочка рассуждений или точные вычисления.
3. Для ошибки предусмотрен безопасный откат. Результат с низкой уверенностью можно передать более сильной модели или человеку, а не использовать для необратимого действия.

Именно поэтому способность отвечать только на «вопросы с вариантами» — не недостаток. Свободный текст в программной системе всё равно приходится разбирать, проверять и при необходимости запрашивать повторно. Типизированный результат из ограниченного набора можно сразу передать в ветвление, очередь, движок правил или систему мониторинга.

Почему нельзя просто заменить model ID чат-модели на Jev

Нативный интерфейс Jev — не Chat Completions. Используется endpoint:

POST https://api.typesafe.ai/v1/systemone

Запрос состоит из трёх основных частей:[3]

• model: например, зафиксированная версия jev-1.13.0;
• state: текст, объект или массив, который нужно оценить;
• questions: именованный вызывающей стороной набор типизированных вопросов.

Ответы возвращаются под теми же идентификаторами вопросов. Несколько вопросов к одному state можно отправить одним запросом и получить параллельные результаты, вместо того чтобы сначала просить модель сгенерировать текст, а затем извлекать из него JSON.[1][3]

В Jev есть три нативных типа вопросов:

Тип	Для каких вопросов подходит	Основные поля ответа	Типичная ошибка
noul	Истинно ли утверждение	noul, от 0 до 1	Отдельного поля confidence нет; 0,8 означает 80-процентную вероятность ответа «да», а не доказанную 80-процентную точность в вашем бизнесе
choice	Выбрать один вариант из конечного набора	choice, probabilities, confidence	Это относительный выбор между вариантами; порог бинарного Choice нельзя механически переносить на Noul
score	Оценить по упорядоченной шкале	score, legend, probabilities, confidence	Результат — взвешенный по вероятностям уровень, а не точная сумма, количество или физическая величина

choice поддерживает до 255 вариантов, а score — от 2 до 10 упорядоченных уровней.[3] Если вариантов больше, обычно следует сначала сузить набор кодом или разбить задачу на два этапа, а не передавать модели тысячи вариантов одновременно.

Есть и ещё одно важное отличие: confidence рассчитывается по форме распределения вероятностей Choice или Score. Чем сильнее распределение сосредоточено на одном результате, тем выше уверенность; плоское распределение означает, что правдоподобны несколько ответов. Noul возвращает только вероятность «да», без отдельного дополнительного поля.[5]

Полный пример распределения обращений

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

Характер примера: сконструирован редакцией. Поля запроса соответствуют документации API TypeSafe на 21 сентября 2026 года. Пороговые значения показывают принцип многоуровневого отката, но не являются универсальной рекомендацией и не представляют собой запись выполненного вызова.

from __future__ import annotations

import os
from typing import Any

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

API_URL = "https://api.typesafe.ai/v1/systemone"
MODEL = "jev-1.13.0"  # Фиксируем версию, чтобы обновление alias не сделало пороги незаметно невалидными


def build_session() -> requests.Session:
    retry = Retry(
        total=3,
        backoff_factor=0.5,
        status_forcelist=(429, 529),
        allowed_methods=frozenset({"POST"}),
        respect_retry_after_header=True,
    )
    session = requests.Session()
    session.mount("https://", HTTPAdapter(max_retries=retry))
    return session


def evaluate_ticket(ticket: dict[str, Any]) -> dict[str, Any]:
    api_key = os.environ["TYPESAFE_API_KEY"]

    payload = {
        "model": MODEL,
        "state": {
            "subject": ticket["subject"],
            "message": ticket["message"],
            "plan": ticket["plan"],
            "account_status": ticket["account_status"],
        },
        "questions": {
            "department": {
                "type": "choice",
                "instructions": "Какая команда лучше всего подходит для обработки этого обращения?",
                "criteria": {
                    "billing": "Списания, счета, инвойсы или возвраты",
                    "technical": "Сбои, ошибки API, производительность или интеграция",
                    "account": "Вход, права доступа, профиль или состояние аккаунта",
                    "other": "Ни одна из перечисленных категорий не подходит",
                },
            },
            "urgent": {
                "type": "noul",
                "instructions": "Нужно ли обработать это обращение приоритетно в течение текущего рабочего дня?",
                "criteria": {
                    "true": "Проблема продолжает останавливать работу, создаёт финансовый риск или имеет явное ограничение по времени",
                    "false": "Обращение можно обработать в обычной очереди, срочности в пределах текущего рабочего дня нет",
                },
            },
            "frustration": {
                "type": "score",
                "instructions": "Насколько клиент недоволен в данный момент?",
                "criteria": [
                    "Тон спокойный, клиент в основном запрашивает информацию",
                    "Клиент явно недоволен, но готов сотрудничать при диагностике",
                    "Клиент крайне недоволен; есть риск жалобы, ухода или эскалации",
                ],
            },
            "requests_refund": {
                "type": "noul",
                "instructions": "Просит ли клиент прямо вернуть деньги или отменить повторное списание?",
                "criteria": {
                    "true": "Клиент прямо просит вернуть деньги, оформить возврат или отменить повторное списание",
                    "false": "Клиент только выясняет причину, пытается устранить проблему или не просит о возврате",
                },
            },
        },
    }

    response = build_session().post(
        API_URL,
        headers={
            "Authorization": f"Bearer {api_key}",
            "Content-Type": "application/json",
        },
        json=payload,
        timeout=10,
    )
    response.raise_for_status()
    return response.json()


def route_ticket(ticket: dict[str, Any], evaluation: dict[str, Any]) -> dict[str, Any]:
    answers = evaluation["answers"]
    department = answers["department"]
    urgent_probability = answers["urgent"]["noul"]
    refund_probability = answers["requests_refund"]["noul"]

    # Choice с низкой уверенностью передаём человеку; порог нужно калибровать на собственной размеченной выборке.
    queue = department["choice"]
    if department["confidence"] < 0.75:
        queue = "human_triage"

    # У Noul нет поля confidence. Средний диапазон вероятности отражает бизнес-неопределённость.
    priority = "normal"
    if urgent_probability >= 0.85:
        priority = "high"
    elif 0.35 < urgent_probability < 0.65:
        priority = "needs_review"

    tags: list[str] = []

    # Точный подсчёт выполняет код, а не модель.
    if ticket["duplicate_charge_count"] >= 2:
        tags.append("possible_duplicate_charge")

    # Jev распознаёт намерение получить возврат, но решение зависит от правил, полномочий и подтверждения.
    if refund_probability >= 0.80:
        tags.append("refund_requested")

    return {
        "queue": queue,
        "priority": priority,
        "tags": tags,
        "requires_human_approval": "refund_requested" in tags,
        "model_version": evaluation["model"],
    }


if __name__ == "__main__":
    ticket = {
        "subject": "Повторное списание, вопрос нужно решить сегодня",
        "message": "С одной и той же покупки списали деньги дважды. Я уже жду сутки, пожалуйста, как можно скорее верните лишнее списание.",
        "plan": "pro",
        "account_status": "active",
        "duplicate_charge_count": 2,
    }

    evaluation = evaluate_ticket(ticket)
    decision = route_ticket(ticket, evaluation)
    print(decision)

В этом примере Jev не возвращает команду «вернуть клиенту 99 долларов». Она выдаёт только сигналы, нужные бизнес-логике: в какую очередь отправить обращение, срочно ли оно, насколько силён негатив и просит ли клиент возврат. Сумма, число списаний, состояние аккаунта и права на подтверждение остаются в тестируемом коде.

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

Три сценария, которые стоит проверить в первую очередь

1. Маршрутизация моделей и инструментов: сначала оценить, затем выбрать исполнителя

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

В архитектуре с Jev маршрутизацию лучше разложить на атомарные решения:

• intent: это поиск, программирование, перевод, анализ данных или обычный вопрос?
• complexity: задача простая, стандартная или требует глубоких рассуждений?
• requires_realtime_data: зависит ли она от актуальной информации?
• risk_level: включает ли она запись, деньги, права доступа или чувствительные данные?

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

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

В сообществе проект pi-jev уже реализовал похожую идею для маршрутизации по каждому ходу: Jev оценивает сложность запроса и при достижении порога переключает его на более дешёвую или более сильную модель, а при низкой уверенности и исключениях сохраняет исходную модель.[12] Это показывает, что архитектуру можно реализовать в коде, но стандартные пороги и показанные результаты относятся только к этому проекту и не являются прогнозом выгоды для других систем.

2. Фильтрация контекста и фрагментов поиска: измеряйте выполнение задачи, а не только число удалённых токенов

В длинных диалогах, RAG и траекториях агента значительная часть истории может уже не влиять на текущую задачу. Jev может оценивать каждый фрагмент:

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

Сжатие контекста не должно превращаться в правило «удалить всё с низкой вероятностью релевантности». Код обязан сохранять структурную целостность: вызов инструмента и его результат должны оставаться парой; системные ограничения, текущая цель и незавершённые действия нельзя удалять отдельно. Фрагменты из зоны неопределённости можно оставить или передать более сильной модели.

fast-jev-compaction — ранняя реализация, которую полезно изучить. Она решает, нужно ли сохранять вызовы инструментов и их результаты, старается оставлять выбранный текст в исходном виде и возвращается к прежней схеме суммаризации при ошибке Jev или слишком малой выгоде от сжатия.[11] Такой консервативный откат ближе к требованиям производственной системы, чем подход «удалять всё, что предложила модель», но его всё равно нужно проверять по доле успешно завершённых собственных задач.

TypeSafe также предупреждает, что большое количество нерелевантной информации в state снижает точность Jev. Поэтому то, что можно отфильтровать кодом — тип файла, временной диапазон, область прав, известные ID и другие точные признаки, — следует удалить заранее, а Jev оставить только семантическую релевантность.[4]

Финальным критерием приёмки не должно быть «мы сократили 70% токенов». Нужно проверить, может ли агент после сжатия выполнить исходную задачу, сохранены ли ключевые ограничения, выросло ли число восстановительных попыток и превышает ли экономия на последующих вызовах стоимость фильтрации и откатов.

3. Классификация обращений и ручное распределение: модель понимает смысл, правила исполняют действие

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

Граница остаётся понятной:

• «просит ли пользователь возврат» можно передать Noul;
• «какому отделу принадлежит обращение» — Choice;
• «насколько высок риск эскалации» — Score;
• «сколько вернуть», «соблюдён ли срок в семь дней», «есть ли у оператора право» — задачи для кода;
• фактический возврат, блокировка, удаление или перевод средств по-прежнему требуют подтверждения или согласования.

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

Как читать результаты Jev и не поддаться одному красивому множителю

TypeSafe опубликовала оценки четырёх типов рабочих процессов: инциденты безопасности, наблюдаемость траекторий агентов, обработка счетов и клиентский сервис. Общий подход заключался в том, чтобы разложить бизнес-процесс на узкие вопросы и правила в коде, а затем сравнить это с вариантом, где «один большой промпт делает всё».[6]

Из этих оценок можно вынести два полезных направления:

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

Однако эталонные метки TypeSafe получены как среднее предсказаний сильных внешних моделей, а не как независимая ручная gold-разметка. Указанные в публикации ускорение до 193,6 раза и снижение стоимости до 444,6 раза сама компания описывала как верхнюю границу практической выгоды и признавала, что оценки подготовлены её командой model capabilities и могут содержать смещение.[1]

Поэтому эти цифры подходят для формулирования гипотезы, но не для прямого переноса в собственный расчёт ROI.

20 сентября 2026 года LangChain опубликовала независимый, но очень узкий эксперимент Jev Evaluator. В нём были зафиксированы пять трасс погодного агента, один человек присвоил им эталонные метки, после чего Jev, GPT-5.6 Luna, GPT-5.6 Terra и Claude Sonnet 4.6 по 100 раз оценили одни и те же трассы. Во всех 500 бинарных решениях Jev совпала с этой ручной разметкой, показала минимальную наблюдаемую дисперсию непрерывной оценки и стоимость 0,00035 доллара за одно решение.[7]

Результат даёт дополнительный сигнал, что ограниченные решения могут быть стабильнее генеративного judge, однако речь идёт лишь о пяти фиксированных примерах, одной области и одном рецензенте; в метаданных также не указана точная версия сервиса Jev. LangChain отдельно предупреждает: низкая цена так же легко масштабирует оценщик, который систематически ошибается, поэтому производственной системе по-прежнему нужны сверка с человеком и повторная проверка.[7]

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

Полезный тест сравнивает весь процесс, а не один вызов API

При проверке Jev нужно оставить как минимум три группы сравнения:

• текущие правила или ключевые слова;
• используемую сейчас недорогую генеративную модель;
• зафиксированную версию Jev.

Для задач с высоким риском нужны и ручные метки. В набор следует включить обычные примеры, редкие классы, пограничные формулировки, отрицания, длинные тексты, prompt injection, а также реальные китайские, русские и английские тексты. Каждую из трёх языковых групп нужно считать отдельно: английский порог нельзя автоматически переносить на китайский или русский.

Метрики качества

Для классификации общей accuracy недостаточно. Полезнее отслеживать:

• precision, recall и F1 по каждому классу;
• дорогие ошибки, например отнесение рискованной операции записи к низкому риску;
• связь между долей автоматической обработки и ошибками автоматической обработки;
• калибровку вероятностей: действительно ли среди примеров с прогнозом около 0,8 примерно 80% оказываются истинными на ваших данных;
• результаты по языкам, типам клиентов, длине текста и атакующим примерам.

Для Choice и Score можно настраивать откат по confidence. У Noul такого поля нет, поэтому диапазоны вероятностей определяются по собственной калибровке. Например, значения около 0,5 можно отправлять на проверку, а автоматическое ветвление разрешать только при заметном удалении от 0,5. Конкретные границы должны зависеть от стоимости ошибки, а не быть скопированы из примера документации.[5]

Системные метрики

Задержка Jev у поставщика измерялась в определённых сетевых условиях и при конкретном размещении сервиса. В собственной системе следует записывать:

• чистую задержку API и сквозные P50, P95, P99 с учётом сети, очереди, повторов и разбора ответа;
• долю 429, 529, таймаутов и повторных попыток;
• долю результатов с низкой уверенностью, переданных генеративной модели или человеку;
• итоговую успешность задачи после отката;
• дрейф до и после изменения версии, языка, шаблона вопроса или порога.

Один средний показатель вроде 380 миллисекунд скрывает хвост распределения и стоимость отката. Для продукта реального времени P95 часто лучше отражает пользовательский опыт, чем среднее значение.

Полная стоимость

Стоимость одного бизнес-решения можно представить так:

Полная стоимость
= стоимость вызова Jev
+ вероятность повтора × стоимость повтора
+ вероятность отката × стоимость резервной модели
+ стоимость последующего инструмента или модели
+ стоимость ручной проверки
+ ожидаемый ущерб от ошибочной классификации

Если Jev стоит мало, но из-за ошибок 15% запросов повторно уходят в дорогую модель или требуют большого объёма ручной проверки, она может не дать экономии. И наоборот, даже при небольшой разнице в цене одного вызова внедрение может быть оправдано, если заметно уменьшаются рискованные ошибки и стабилизируется хвостовая задержка.

Наиболее безопасный запуск начинается с shadow evaluation: Jev только записывает решения и не влияет на реальный процесс. После стабилизации порогов можно постепенно включать ветки с низким риском и возможностью восстановления; для высокорискованных действий всегда сохраняются авторизация и подтверждение.

Главные текущие ограничения Jev

1. Правильный тип ответа не гарантирует правильный смысл

Jev может гарантировать возврат заранее заданного типа вместо внезапного непарсируемого текста; это решает проблему структуры интерфейса. Но модель всё ещё способна неверно классифицировать счёт, неправильно прочитать отрицание или попасть под влияние атакующего содержания во входе. В документации TypeSafe среди рисков прямо указаны буквальное толкование, противоречивые criteria, нерелевантный контекст и prompt injection.[4]

Поэтому фразу «не создаёт ошибок типа» нельзя превращать в «не ошибается в решениях».

2. Математику, даты и точный подсчёт оставьте коду

score — это уровень, взвешенный по вероятностям, а не калькулятор. Сложение сумм, порядок дат, длительность, число символов и количество товара должны вычисляться кодом. Jev может определить, выражает ли текст срочность, но не должна рассчитывать, что «до срока осталось 17 часов».[4]

3. Разбивайте многошаговые рассуждения

Двойные отрицания, связи через несколько шагов и несколько решений в одном вопросе снижают надёжность. Вместо вопроса «является ли клиент одновременно не пользователем без возврата и не аккаунтом с низким риском» лучше отдельно определить намерение получить возврат, риск аккаунта и состояние прав, а затем объединить результаты кодом.

4. Нельзя переносить пороги между Noul, Choice и Score

Вероятности для одного естественного вопроса, сформулированного как Noul и как бинарный Choice, не обязаны иметь простое взаимодополняющее соотношение. Choice отвечает «какой из вариантов подходит лучше», а Noul — «истинно ли утверждение». Их статистический смысл различается.[4]

После смены типа вопроса или версии модели пороги нужно калибровать заново.

5. Неанглийские задачи требуют отдельной проверки

В официальной документации прямо сказано, что лучший текущий результат достигается на английском. Другие языки, включая CJK, поддерживаются, но качество не обязано совпадать.[2] Для китайских, русских и смешанных обращений нужны отдельные наборы и отдельные пороги; небольшой переводной пример не заменяет реальные локальные формулировки.

6. Фиксируйте версию и записывайте фактически возвращённую модель

jev-latest меняется с выходом новой версии. Если производственные пороги калибровались на jev-1.13.0, следует закрепить эту версию и записывать model из каждого ответа. При обновлении нужно снова запустить регрессионный набор, а не позволять alias автоматически измениться при сохранении старых порогов.[2]

Текущие варианты интеграции и региональные условия

При выпуске Jev 15 сентября 2026 года TypeSafe обозначила прямой сервис как early access. Разработчики могли использовать нативный /v1/systemone либо обращаться к модели через AI SDK Evaluation в Vercel AI Gateway. В Vercel использовался model ID typesafe-ai/jev, требовалась версия AI SDK 7.0.105 или новее. Вызов выполнялся через experimental_evaluate, а не через OpenAI-compatible Chat Completions.[1][8]

TypeSafe заявляла, что запросы и ответы клиентов не используются для обучения моделей, а корпоративные клиенты могут запросить Zero Data Retention. Фактическое логирование, сроки хранения и обязанности по соответствию требованиям всё равно определяются договором конкретного аккаунта.[2][10]

Что касается географии, в условиях использования TypeSafe сказано, что сайт предназначен для посетителей из США и компания не заявляет о его доступности за пределами США. Командам вне США перед производственным внедрением следует подтвердить право на аккаунт, договор, передачу данных и местные требования, а не считать возможность открыть документацию доказательством долгосрочной производственной доступности.[9]

Вывод: Jev — не ослабленная чат-модель, а новый слой инфраструктуры решений

Успех ChatGPT надолго связал понятие «интеллект» с «генерацией контента». Jev предлагает другую форму: модель не пишет ответ, а сжимает понимание смысла до ограниченного решения, которое программа может выполнить немедленно.

Её потенциал не в замене всех LLM, а в выделении множества задач, которые сейчас выполняются дорогими генеративными моделями, хотя требуют только Yes/No, A/B/C или оценки 1–5. Маршрутизация, фильтрация, скоринг, сигналы риска, оценка агентов и ветвление процессов могут получить меньшую задержку и более прозрачную наблюдаемость.

Однако пригодность для production определяют не цена 0,042 доллара за миллион токенов и не отдельный показатель ускорения в сотни раз, а четыре вопроса:

1. Можно ли разложить задачу на ясные атомарные решения?
2. Откалиброваны ли вероятности и уверенность на ваших данных?
3. Есть ли надёжный откат для низкой уверенности и высокого риска?
4. Становится ли весь процесс лучше после учёта повторов, откатов, последующих вызовов, ручной проверки и ошибок?

Jev можно представить как «супер-if» с семантическим пониманием. Но надёжная автоматизация по-прежнему строится совместно из решений модели, ограничений кода, контроля полномочий и человеческой подстраховки.