Может ли Jev снизить стоимость ИИ-агентов? Полный расчёт от маршрутизации моделей до проверки результатов

Краткое содержание

Один вызов Jev стоит очень дёшево, но добавление недорогой модели принятия решений в ИИ-агента ещё не означает, что вся задача станет дешевле.

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

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

---

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

Запрос «Проверьте статус моего заказа» может потребовать только одного обращения к базе данных. Для запроса «Проанализируйте причины аномалий в заказах за последние полгода» уже может понадобиться сильная модель, которая сведёт данные из нескольких источников. А в некоторых запросах просто не хватает информации, и разумнее не вызывать никакую модель, а сначала уточнить детали у пользователя.

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

Jev предлагает другой подход.

Это не модель для диалога или генерации длинного текста. Разработчик передаёт ей state, задаёт набор типизированных вопросов, а Jev возвращает структурированные решения и вероятности — например Choice, Score или Noul. После этого бизнес-логика решает, вызвать ли инструмент, использовать ли дешёвую модель, повысить ли уровень до сильной модели или передать случай человеку. TypeSafe позиционирует Jev как первую модель System One, то есть модель, созданную специально для быстрых структурированных решений внутри программного обеспечения. (typesafe.ai)

С точки зрения цены такой шаг кажется почти бесплатным.

При запуске TypeSafe указала цену Jev 0,042 доллара за миллион входных токенов, без оплаты выходных токенов. Компания также заявила типичную сквозную задержку 70–500 мс, одновременно уточнив, что эти цифры получены в определённых регионах и условиях тестирования и не отражают автоматически все среды развёртывания. (typesafe.ai)

Но проблема в следующем:

Дешёвое решение ещё не делает дешевле весь рабочий процесс агента.

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

Реальный счёт ИИ-агента состоит не только из платы за модель

Для выполнения одной задачи агент обычно создаёт как минимум шесть видов затрат:

Категория затрат	Что в неё входит
Стоимость принятия решения	Классификация намерения, маршрутизация модели, оценка риска и решение о необходимости инструмента
Стоимость контекста	История диалога, результаты поиска, вывод инструментов, журналы и документы
Стоимость генерации	Входные, выходные и рассуждающие токены основной модели
Стоимость повторов	Тайм-ауты модели, сбои инструментов, ошибки формата и повторная генерация
Стоимость ручной работы	Проверка, исправление, обработка исключений и подтверждение рискованных действий
Стоимость ошибочного решения	Исправление последствий неверной маршрутизации, пропущенной информации или выполнения неправильного действия

Поэтому более полная стоимость одной задачи выглядит так:

Общая стоимость
= стоимость принятия решения
+ стоимость обработки контекста
+ стоимость последующих моделей и инструментов
+ стоимость повторов и резервных путей
+ стоимость ручной проверки
+ стоимость исправления последствий неверных решений

Сам вызов Jev обычно составляет лишь очень небольшую часть этой суммы.

Его реальная возможность для экономии — сократить последующие расходы: не вызывать один раз дорогую модель, не отправлять лишний контекст, не запускать заново неудачную задачу или отдавать людям только действительно неопределённые случаи.

Основные способы экономии можно свести к трём группам:

1. Предварительная маршрутизация: сначала принять решение, затем выбрать, что вызывать.
2. Фильтрация контекста: убрать ненужные данные до вызова основной модели.
3. Последующая проверка: сначала использовать дешёвую модель, а повышать уровень только при провале проверки.

---

Первый способ экономии: поставить Jev перед основной моделью как маршрутизатор

Самая прямая архитектура выглядит так:

Запрос пользователя
   ↓
Jev оценивает намерение, сложность и риск
   ↓
Обычный код / дешёвая модель / сильная модель / человек

Официальная схема маршрутизации TypeSafe устроена так же: не каждый запрос обязан попадать в одну и ту же LLM. Часть можно направить в детерминированный код, часть — в специализированную модель, а сложные или рискованные запросы — в более дорогую модель или человеку. (docs.typesafe.ai)

Например, агент поддержки может сначала определить:

• Это просто запрос статуса заказа?
• Связан ли он с возвратом денег или чарджбэком?
• Должен ли он попасть в биллинг, техническую поддержку или продажи?
• Требуется ли вмешательство человека?
• Нужна ли здесь действительно сильная модель рассуждения?

Jev только принимает эти решения.

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

Насколько дёшево обходится одна маршрутизация

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

• Общий ввод: 2 571 токен;
• Время вызова: около 405 мс;
• Стоимость по публичной цене: около 0,000108 доллара;
• В среднем на одно обращение: около 0,0000108 доллара;
• При том же профиле токенов: около 10,8 доллара за миллион обращений.

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

Точка безубыточности маршрутизации моделей

Предположим:

• C_high — стоимость одного вызова сильной модели;
• C_low — стоимость одного вызова дешёвой модели;
• C_jev — стоимость решения Jev;
• P_code — доля запросов, которые способен завершить обычный код;
• P_low — доля запросов, которые способна завершить дешёвая модель;
• P_error — доля запросов, требующих исправления из-за неправильной маршрутизации.

Если каждый запрос сразу отправляется сильной модели, ожидаемая стоимость равна:

C_direct = C_high

После добавления маршрутизации ожидаемая стоимость становится такой:

C_route
= C_jev
+ P_low × C_low
+ P_high × C_high
+ P_error × C_repair

Следовательно, маршрутизация экономит деньги только при условии:

Сэкономленная стоимость сильной модели
>
стоимость Jev + стоимость исправления ошибок маршрутизации

Поскольку сам Jev стоит мало, итоговая экономика обычно определяется двумя вопросами:

1. Какая доля запросов действительно может обойтись без сильной модели?
2. Насколько дороги последствия ошибок маршрутизации?

Полностью условный расчёт

Следующие цены приведены только для иллюстрации логики и не отражают тарифы конкретных моделей:

• Сильная модель: 0,01 доллара за вызов;
• Дешёвая модель: 0,002 доллара за вызов;
• Jev: около 0,0000108 доллара за вызов;
• Общий объём: 100 000 запросов.

Предположим, после маршрутизации:

• 20% выполняет обычный код;
• 50% уходят дешёвой модели;
• 30% уходят сильной модели;
• Ещё 5% из-за ошибки или сбоя требуют одного дополнительного вызова сильной модели.

Тогда:

Статья	Стоимость
Без маршрутизации: все запросы обрабатывает сильная модель	1 000 долларов
100 000 решений Jev	1,08 доллара
50 000 вызовов дешёвой модели	100 долларов
30 000 вызовов сильной модели	300 долларов
5 000 исправляющих вызовов	50 долларов
Итого после маршрутизации	451,08 доллара

В этих условиях общая стоимость снижается примерно на 55%.

Но если только 10% запросов можно передать дешёвой модели, 90% всё равно доходят до сильной модели, а ещё 5% требуют исправления, общая стоимость составит около 971,08 доллара.

Экономия составит примерно 2,9%.

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

Поэтому сначала нужно измерить не цену Jev, а следующее:

Какая доля вашего реального трафика действительно не нуждается в сильной модели?

---

Второй способ экономии: сократить контекст, отправляемый основной модели

Контекст — ещё одна крупная статья расходов агента.

У долго работающего агента могут накапливаться:

• История диалога;
• Результаты нескольких раундов инструментальных вызовов;
• Журналы Bash или сборки;
• Содержимое веб-страниц;
• Фрагменты, полученные поиском;
• Уже неактуальные планы и промежуточные результаты.

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

Jev можно поставить перед основной моделью, чтобы решить:

• Какие результаты поиска относятся к текущему вопросу;
• Какие выводы инструментов могут понадобиться позже;
• Какие ранние сообщения содержат ограничения или незавершённые задачи;
• Какие фрагменты могут содержать prompt injection;
• Какие данные можно удалить или оставить только в виде краткого представления.

Официальная карта сценариев TypeSafe также включает отбор контекста, семантический поиск, фильтрацию фрагментов RAG и управление контекстом внутри agent harness. (docs.typesafe.ai)

Денежный эффект можно приблизительно выразить так:

Чистая выгода от контекста
= удалённые токены × цена входа основной модели
- стоимость фильтрации Jev
- стоимость повторного поиска и повторов из-за пропущенной информации

Первые две части легко посчитать. Третью чаще всего забывают.

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

Один повторный запуск может поглотить экономию от множества удачных операций фильтрации.

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

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

Для сжатия контекста полезнее считать:

Общее число токенов после сжатия
+ токены повторного поиска
+ токены повторов, вызванных пропусками

а не только «сколько токенов удалось убрать на этом шаге».

---

Третий способ экономии: сначала дешёвая модель, затем проверка Jev

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

Поток выглядит так:

Дешёвая модель создаёт результат
       ↓
Jev проверяет фактическую опору, извлечённые поля, политический риск или полноту выполнения
       ↓
Проверка пройдена: использовать результат
Проверка не пройдена: повторить, повысить до сильной модели или передать человеку

TypeSafe называет этот класс подходов Universal Verification. В официальных материалах перечислены проверка цитат в RAG, проверка вызовов инструментов, оценка качества результата и каскады структурированного извлечения. Официальный пример SDE Cascade использует схему «извлечение дешёвой моделью → проверка каждого поля Jev → повышение до модели рассуждения только при наличии красного флага». Это результаты vendor cookbook, их нельзя трактовать как доказательство одинакового снижения стоимости для любого извлечения. (docs.typesafe.ai)

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

C_cascade
= C_low
+ C_jev
+ P_escalate × C_high
+ C_failure

Главная переменная — P_escalate: доля результатов дешёвой модели, которые всё равно приходится передавать сильной модели.

Если не учитывать стоимость ошибок, каскад дешевле прямого вызова сильной модели при условии:

P_escalate
<
1 - (C_low + C_jev) / C_high

Возьмём те же условные цены:

• Сильная модель: 0,01 доллара;
• Дешёвая модель: 0,002 доллара;
• Jev: около 0,0000108 доллара.

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

Но это точка безубыточности по цене, а не по качеству.

«Почти как сильная модель» и «то же качество, что у сильной модели» — разные цели по стоимости

В одной предварительно зарегистрированной независимой оценке каскад Jev → сильная модель тестировался на выборке CLINC150:

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

Исследователи поэтому подчёркивали, что результат следует понимать как «приблизиться к качеству сильной модели за меньшие деньги», а не как «получить то же качество с меньшим числом вызовов». Эксперимент включал только 200 примеров, один набор данных и один путь обслуживания, поэтому его нельзя напрямую переносить на другие агенты. Тем не менее он показывает важный экономический эффект: небольшое повышение целевого качества может вызвать резкий скачок доли повышений. (github.com)

Поэтому при оценке каскада недостаточно сообщать только:

• Сколько вызовов сильной модели удалось избежать;
• Какую долю трафика удалось обработать автоматически.

Нужно также показывать:

• Точность автоматической части;
• Итоговую сквозную успешность задач;
• Сколько качества потеряно по сравнению с вариантом, где всё получает сильная модель;
• Какие ошибки усиливаются на последующих шагах.

---

Несколько вопросов в одном вызове часто важнее, чем пакетирование самих запросов

Jev позволяет задавать несколько вопросов к одному state и получать ответы параллельно. Официальная документация рекомендует разбивать сложное решение на атомарные вопросы и объединять результаты в коде, а не прятать несколько суждений в одном расплывчатом запросе. (docs.typesafe.ai)

Например, вместо вопроса:

Как обработать это обращение?

задайте отдельно:

• В какую бизнес-очередь его направить?
• Есть ли явное требование возврата денег?
• Упоминаются ли чарджбэк, юридические действия или регулятор?
• К какому уровню срочности оно относится?
• Нужен ли человек?
• Стоит ли вызывать более сильную модель?

В замерах исходных материалов увеличение числа вопросов для одного state с 1 до 8 и затем до 32 после прогрева сохраняло задержку примерно в том же диапазоне 350–400 мс. Число входных токенов росло, но сетевые раунды не увеличивались линейно.

Поэтому разумный шаблон таков:

Задать одним запросом все атомарные вопросы, действительно необходимые на текущем шаге, а не делать отдельный API-вызов для каждого решения.

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

Стратегию пакетирования всё равно нужно проверять на реальном распределении данных приложения.

---

Четыре скрытые статьи расходов, которые легко забыть

1. confidence — это не точность

Типизированный вывод гарантирует соответствие интерфейсу, но не гарантирует правильность бизнес-решения.

В одной независимой оценке на 200 примерах Jev вернул confidence, строго равный 1.0, для 102 примеров, и шесть из них были ошибочными. Исследователи также не обнаружили, что confidence Jev лучше, чем самооценка небольшой LLM, ранжирует собственные ошибки. (github.com)

Поэтому производственную логику нельзя сводить к следующему:

if (confidence === 1) {
  executeDestructiveAction();
}

Более безопасный подход:

• При необходимости конкретного правила опираться на probabilities отдельных вариантов;
• Подбирать пороги на собственном размеченном наборе;
• Использовать разные пороги для разных уровней риска;
• Сохранять ручное подтверждение для платежей, удаления, блокировок и похожих действий;
• Записывать версию модели, вероятности и фактический результат для контроля дрейфа.

Другая предварительно зарегистрированная оценка калибровки также дала смешанный результат: ECE составил 0,0204 на CLINC150 и 0,0936 на Banking77, причём на втором наборе наблюдалась систематическая избыточная уверенность. Это означает, что калибровка зависит от задачи и корпуса; порог, настроенный на одном наборе, нельзя напрямую переносить в другую предметную область. (systemonemodels.org)

2. Ошибки маршрутизации не бесплатны

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

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

Поэтому полезно отдельно отслеживать четыре типа ошибок:

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

Одна агрегированная точность не отражает стоимость этих четырёх типов ошибок.

3. Задержка и сбои — тоже расходы

В исходных материалах последовательные прогретые вызовы в основном занимали около 340–450 мс. В одном тесте с 24 параллельными запросами медианная задержка выросла примерно до 1,2 секунды, а три запроса завершились транспортными сбоями. Это небольшой тест в конкретной среде и не описание общей доступности официального сервиса, но он показывает, что производственная архитектура не может считать слой решений безошибочной локальной функцией.

Как минимум нужно заранее определить:

• Приводит ли тайм-аут к fail-open, fail-closed или передаче человеку;
• Нужно ли повторять вызов и сколько раз;
• Следует ли при недоступности Jev сразу вызывать основную модель;
• Может ли сбой сервиса маршрутизации заблокировать всего агента;
• Укладываются ли p95 и p99 в бюджет интерактивной задержки продукта.

В сторонней предварительно зарегистрированной оценке медианное время вызова Jev составляло около 0,42–0,44 секунды. Авторы отдельно отметили, что это результат конкретного клиента, шлюза, региона и нагрузки, а не чистая скорость инференса модели. (github.com)

4. Если уже есть размеченные данные, Jev может оказаться не самым дешёвым вариантом

Одно из важных преимуществ Jev — холодный старт: при отсутствии размеченных данных он способен принимать zero-shot решения по естественным текстовым описаниям.

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

В предварительно зарегистрированной оценке Banking77 замороженная embedding-модель bge-small с логистической регрессией, обученная на 10 003 примерах, достигла точности 0,933, а Jev — 0,832. На тестовом оборудовании энкодер работал примерно за 9 мс и не имел платы за каждый API-запрос. Исследователи при этом подчеркнули, что условия по информации были разными: энкодер видел большой размеченный набор того же распределения, а Jev оценивался zero-shot. Поэтому это не сравнение способностей при одинаковых условиях, а сравнение реальных вариантов развёртывания. (github.com)

Практическая траектория может выглядеть так:

Этап	Что стоит оценить
Нет размеченных данных, правила часто меняются	Zero-shot модель решений вроде Jev
Накопился небольшой размеченный набор	Jev + настройка порогов + ручная проверка
Метки стабильны и данных много	Локальный энкодер, классификатор или дообученная модель
Длинный хвост задач продолжает меняться	Оставить Jev как резервный вариант

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

---

Как посчитать экономику до запуска

Начните с набора исторических задач реального приложения и офлайн сравните три пути:

A. Все задачи отправляются сильной модели
B. Маршрутизация Jev → код / дешёвая модель / сильная модель
C. Дешёвая модель → проверка Jev → повышение до сильной модели при необходимости

Как минимум фиксируйте следующие метрики:

Метрика	На какой вопрос отвечает
Средняя полная стоимость	Сколько реально стоила каждая успешно завершённая задача?
Доля вызовов сильной модели	Сколько дорогих вызовов Jev действительно предотвратил?
Покрытие автоматической обработкой	Сколько задач обошлись без человека и сильной модели?
Точность автоматической обработки	Какая доля автоматически обработанных задач действительно была решена правильно?
Доля повышений	Сколько задач каскада всё равно дошли до сильной модели?
Доля повторов	Сколько дополнительных вызовов вызвали ошибки маршрутизации или проверки?
Доля ручной проверки	Процесс действительно уменьшил ручную работу или лишь перенёс её в другое место?
p95 задержки	Какую хвостовую задержку реально почувствовали пользователи?
Сквозная успешность	Не упало ли итоговое качество относительно базового варианта?

Наиболее важная метрика — не «точность решений Jev», а:

Стоимость одной успешно завершённой задачи

Даже крайне дешёвый API принятия решений может сделать агента менее экономичным, если увеличит число повторов, ручных проверок или неверных действий.

---

Когда Jev стоит проверить в первую очередь

Чем больше выполняется следующих условий, тем выше вероятность практической ценности Jev:

• Объём запросов большой, решения принимаются часто;
• Границы задач ясны, их можно разбить на одношаговые семантические вопросы;
• Многие запросы способен обработать обычный код или дешёвая модель;
• Пока недостаточно размеченных данных для отдельного классификатора;
• Вызов основной модели заметно дороже вызова модели решений;
• Ошибки можно локализовать повышением, повтором или ручной проверкой;
• Система умеет записывать вероятности, пороги и конечные результаты;
• Критерии решений нужно быстро добавлять или менять.

Напротив, не стоит начинать с добавления Jev, если:

• Почти каждый запрос в итоге требует сильной модели;
• Трафика мало, и API-экономия не окупит инженерную сложность;
• Задача требует многошагового рассуждения, арифметики, сравнения дат или генерации длинного текста;
• Неверное решение может напрямую запустить необратимое действие;
• Уже есть большой стабильный размеченный набор, пригодный для локальной малой модели;
• Невозможно построить надёжные резервные пути и ручную проверку;
• План состоит в прямом переносе порогов из официальной демонстрации в production.

---

Вывод: Jev экономит не на самом решении, а на последующей работе

Вызов Jev действительно дешёвый, но не это определяет, снизит ли он стоимость ИИ-агента.

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

• Простые запросы получает обычный код;
• Рутинные запросы получает дешёвая модель;
• Сложные запросы получает сильная модель;
• Неопределённые запросы получает человек;
• Избыточный контекст не отправляется;
• Дефектные результаты останавливаются до того, как попадут пользователю.

Если Jev стоит перед основной моделью, но каждый запрос всё равно идёт дальше в эту модель, он лишь добавляет ещё один API-вызов.

Если же он надёжно сокращает дорогие вызовы, размер контекста или объём повторной работы, тогда он становится настоящим рычагом экономии.

Поэтому спрашивать нужно не:

Насколько дёшев один вызов Jev?

А так:

Какую дорогую работу система перестала выполнять после этого решения?

Именно такой полный расчёт должен делать ИИ-агент.