typesafe/jev-1.13: модель решений в API — что умеет, как вызывать и сколько стоит

typesafe/jev-1.13 — это модель решений, а не чат-модель. Вы передаёте описание ситуации и один или несколько именованных вопросов, а на выходе получаете выбранный вариант, распределение вероятностей по вариантам и отдельную оценку уверенности. Её стоит брать там, где решение нужно свести к порогу: направить обращение в нужную очередь, пропустить или остановить автоматическое действие, разложить событие по категориям, проверить, хватает ли данных для вывода. Ниже — как вызвать POST /v1/decisions, как читать ответ, как считается цена, и что мы сами узнали про confidence на тесте с реальными инцидентами.

Когда брать эту модель

Модель решений полезна в сценариях, где нужен не текст, а выбор или оценка:

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

И когда она не подходит — это важная часть честного обзора:

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

Как вызвать

Эндпоинт — POST https://plusvibeapi.ru/v1/decisions. Авторизация обычная: клиентский ключ Authorization: Bearer sk-pv-…, правила баланса те же, что и в остальном /v1. Пример — гейт для автоматического повторного списания:

curl https://plusvibeapi.ru/v1/decisions \
  -H "Authorization: Bearer $PLUSVIBE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "typesafe/jev-1.13",
    "state": "Автоматика хочет повторно списать оплату с карты клиента. За последний час по этой карте уже было три отказа подряд с кодом insufficient_funds. Карта привязана, срок действия не истёк, лимит по карте не превышен. Клиент не менял тариф и не обращался в поддержку.",
    "questions": {
      "allow": {
        "type": "choice",
        "instructions": "Разрешить повторное списание прямо сейчас?",
        "criteria": {
          "yes": "Причина отказа устранена, повторная попытка безопасна",
          "no": "Причина не устранена, нужна ручная проверка или пауза"
        }
      }
    }
  }'

state — это контекст, по которому модель рассуждает. Он принимает строку, объект или массив, поэтому можно передать и связное описание, и уже собранные поля: например, {"failed_attempts": 3, "code": "insufficient_funds", "card_valid": true, "limit_exceeded": false}. questions — словарь с вашими именами вопросов; в одном запросе может быть до 20 вопросов. Поле model можно не передавать, пока модель решений одна; если передаёте, значение проверяется по каталогу, а неизвестное отклоняется.

Каждый вопрос задаёт type, который фиксирует форму ответа:

typecriteriaЧто приходит в ответе choiceобъект «вариант → описание»choice — победивший вариант, probabilities по вариантам, confidence scoreупорядоченный массив уровнейscore, legend, probabilities по уровням, confidence noulне нуженnoul — вероятность того, что ситуацию нельзя определить

Несколько вопросов в одном запросе отправляются одним вызовом и используют общий state. Вот фрагмент с двумя вопросами и проверкой на неопределимость:

"questions": {
  "allow":      { "type": "choice", "instructions": "Разрешить действие?", "criteria": { "yes": "…", "no": "…" } },
  "need_human": { "type": "choice", "instructions": "Звать человека?",    "criteria": { "yes": "…", "no": "…" } },
  "unknown":    { "type": "noul",   "instructions": "Есть ли в данных противоречия, мешающие решению?" }
}

Что приходит в ответ

Ответ на вызов выше выглядит так (значения — пример формата):

{
  "object": "decisions",
  "model": "typesafe/jev-1.13",
  "answers": {
    "allow": {
      "type": "choice",
      "choice": "no",
      "probabilities": { "yes": 0.07, "no": 0.93 },
      "confidence": 0.85
    }
  },
  "usage": { "input_tokens": 581, "output_tokens": 59 }
}

Имена в answers повторяют имена ваших вопросов. Ответ очищен от служебных полей поставщика: внутренний идентификатор запроса, датированная версия модели и её провайдер клиенту не возвращаются.

Для гейтов смотрят не только на choice, но и на probabilities вместе с confidence. Типовая схема — пропустить автоматически только при вероятности выше порога, а всё, что ниже, отправить на ручную проверку. Именно поэтому отдельная оценка уверенности здесь важнее, чем в обычном чате: она позволяет задать порог и не гадать.

Сколько это стоит

Тарифицируются только входные токены; выходные токены записываются для наблюдаемости, но продаются по цене 0. Цена в каталоге на 18 сентября 2026 года:

на plusvibeapi.ru — 5,28 ₽ за 1M входных токенов, выход — 0 ₽;
на getvibeapi.com — $0,0525 за 1M входных токенов, выход — 0.

Для примера выше это 581 входной и 59 выходных токенов: 581 × 5,28 / 1 000 000 ≈ 0,0031 ₽, выход не добавляет ничего. То есть типовое решение по одному вопросу стоит доли копейки.

Практический вывод: основной расход — это state. Если нужно задать десять вопросов по одной и той же ситуации, выгоднее отправить их одним запросом: state уйдёт на вход один раз. Сумма списания приходит в заголовке x-pv-cost-rub. Актуальную цену перед запуском в продакшен всегда сверяйте в справочнике API — она может измениться.

Небольшой тест: чему верить в confidence

Мы прогнали восемь вопросов по реальным инцидентам в продакшене, где правильный ответ знали заранее. На шести вопросах с достаточным контекстом модель ответила верно 6 из 6, часть — с уверенностью 1,0.

Поучительным был провал. Мы спросили: 89 ошибок валидации на одном из наших маршрутов вызваны нашим шлюзом или запросами клиента? На скупом контексте модель ответила «виноват наш шлюз» с уверенностью 0,98 — и ошиблась. Когда мы дали полную разбивку по клиенту, она ответила «виноват клиент» — и снова с уверенностью 0,98. Одинаковая уверенность, противоположные ответы.

А вот низкая уверенность оказалась полезной. Там, где ответа в данных не было вообще, модель вернула 0,34. В кейсе, который она провалила на скупом контексте, — 0,57, и уверенность выросла до 0,76, когда мы дали полные данные.

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

Границы и ошибки

Это не чат: отправка в /v1/chat/completions вернёт 400. Используйте /v1/decisions.
Модель не ищет данные и не вызывает инструменты — качество ответа целиком зависит от state.
Она не ведёт диалог и не переспрашивает: всё, что нужно для решения, должно быть в запросе.
confidence не калибрована статистически: одинаковые значения могут стоять за верным и неверным ответом.
Неизвестные ключи и некорректные вопросы отклоняются с 400.
Ошибки: 400 — некорректный запрос или неизвестная модель; 402 — нет средств; 429 — ограничение частоты; 502 — сбой вышестоящего сервиса; 504 — таймаут.

Итог

typesafe/jev-1.13 — узкий, но полезный инструмент: он превращает уже собранные данные в вероятностное решение с явной уверенностью. Берите его для маршрутизации, гейтов и классификации, где у вас есть контекст и нужен порог. Не ждите от него поиска фактов, диалога или гарантированно точной вероятности — и тогда он честно закрывает свою задачу.

Подробности запроса и ответа — в справочнике API.