Jev: как работает модель для решений и для каких задач она подходит

В автоматизации часто требуется небольшое решение по тексту. Кому передать обращение? Поможет ли найденный фрагмент ответить на вопрос? Просит ли клиент возврат денег? Соответствует ли описание товара выбранной категории?

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

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

Что в Jev особенного

TypeSafe называет Jev моделью System One. Название отсылает к быстрым суждениям в противоположность долгому рассуждению. В практическом смысле это специализация на ограниченном вопросе с заданным форматом ответа: выбрать категорию, оценить признак, поставить балл. Jev не пишет объяснение своего выбора или ответ пользователю. Концепция System One.

Обычная языковая модель тоже может классифицировать обращение и вернуть результат по схеме. Поэтому сам факт ответа «финансовый отдел» ещё не объясняет интерес к Jev. Сравнение этих подходов есть и у Vercel.

По описанию TypeSafe, Jev дообучают методом RLCD — reinforcement learning for calibrated decisions. Цель такого обучения — решения с вероятностями, которые соответствуют частоте правильных исходов. Если хорошо откалиброванная модель много раз оценивает вероятность события примерно в 80%, то среди таких случаев событие должно происходить примерно в восьми из десяти. Это свойство группы предсказаний, а не гарантия для одного ответа. Как TypeSafe описывает обучение.

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

Как получается одно решение

Представим сообщение в поддержку:

«Оплата прошла, но я не могу войти в аккаунт. Помогите восстановить доступ».

Чтобы решить, куда его отправить, нужны три вещи: само сообщение, вопрос и правила распределения. Например, финансовый отдел занимается списаниями и возвратами, технический — входом и работой приложения. Для обращений вне этих правил предусмотрен отдельный разбор.

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

Весь процесс можно описать так:

Сообщение и контекст → вопрос с критериями → оценка Jev → действие агентской системы.

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

Отсюда важная граница: сообщение «деньги списали дважды» позволяет оценить, на что жалуется клиент. Чтобы выяснить, было ли двойное списание на самом деле, нужно получить сведения о платежах. Модель не добавляет отсутствующие подтверждения только потому, что вопрос сформулирован уверенно.

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

Три формы ответа

У Jev есть три типа вопросов. Их удобно различать по тому, какое решение требуется.

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

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

Noul возвращает вероятность положительного ответа от 0 до 1. Условные 0,9 означают, что модель скорее отвечает «да», 0,1 — скорее «нет», а около 0,5 — что модель считает ответы «да» и «нет» примерно одинаково вероятными. Низкое число здесь не означает низкую уверенность вообще. В некоторых интеграциях, включая AI SDK, этот тип называется boolean. Описание Noul.

Score требует описать уровни шкалы. Например: косметический дефект; функция сломана, но есть обходной путь; основная работа заблокирована. Уровни получают номера 0, 1 и 2. Итог может быть дробным: это среднее номеров уровней с весами из вероятностей. Оценка 1,4 показывает положение на этой шкале; размер убытков или долю пострадавших клиентов она не измеряет. Описание Score.

Одни данные можно оценить сразу по нескольким вопросам. По документации TypeSafe, вопросы обрабатываются независимо на общем контексте. Ответ на один вопрос не становится автоматически основанием для другого. Агентская система объединяет результаты — например, «есть просьба о возврате и недостаточно сведений о заказе» — и выбирает следующий шаг. Работа с несколькими вопросами.

Что дают вероятности

Один выбранный вариант скрывает неоднозначность. Допустим, в двух случаях модель выбрала финансовый отдел, но распределила вероятности по-разному:

В первом случае один ответ явно преобладает. Во втором два отдела почти равны, хотя формально победитель всё равно есть. Если читать только название отдела, это различие потеряется.

Для Choice и Score TypeSafe дополнительно возвращает confidence — показатель определённости, рассчитанный из распределения вероятностей. Он не равен просто вероятности выбранного варианта. У Noul отдельного confidence нет. Как устроен confidence.

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

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

Для каких задач это полезно

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

01

Распределение обращений

На входе

Сообщение и правила отделов

↳ Решение Jev

Кому передать или нужен ли отдельный разбор

02

Классификация

На входе

Текст документа или товара и описание категорий

↳ Решение Jev

Какую категорию присвоить

03

Отбор контекста

На входе

Вопрос пользователя и найденный фрагмент

↳ Решение Jev

Полезен ли этот фрагмент для ответа

04

Проверка утверждения

На входе

Утверждение и исходный текст

↳ Решение Jev

Подтверждает ли источник сказанное

05

Редакционные правила

На входе

Текст и конкретное требование

↳ Решение Jev

Есть ли нарушение, которое нужно показать редактору

06

Следующий шаг агента

На входе

Текущая ситуация и описания доступных шагов

↳ Решение Jev

Какую ветку работы предложить

Такие направления есть в карте применений TypeSafe. Это кандидаты для проверки на своих данных; наличие примера в документации не доказывает качество в конкретном процессе.

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

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

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

Качество вопроса определяет полезность ответа

Самые сложные вопросы часто выглядят короткими: «задача готова?», «клиент недоволен?», «можно закрывать?». В каждом спрятано несколько возможных смыслов.

«Можно закрывать обращение?» может означать, что сотрудник дал ответ, что клиент подтвердил результат или что проблема действительно устранена. Для каждого смысла нужны свои данные. Одно число не разрешит это расхождение за автора процесса.

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

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

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

Где модель будет не к месту

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

Для подготовки письма, объяснения ошибки или разработки плана нужен генеративный шаг. Jev возвращает ответы заданных типов и не создаёт развёрнутое объяснение своего суждения. Это ограничивает его роль в задачах, где человеку важно разобрать ход рассуждения. Возможности System One.

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

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

Что я вынес из собственных опытов

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

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

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

Замеры работы сервиса при этом остались полезными. В трёх наборах сохранилось 828 успешных вызовов. Медианы составляли от 383 до 477 мс. В одном наборе 90-й процентиль доходил до 8,7 секунды — примерно десятая часть успешных вызовов занимала столько или дольше. Встречались ограничения частоты запросов (429) и ошибки сервера. Я измерял время клиентских вызовов через Vercel AI Gateway — сервис доступа к моделям. Паузы, которые мой скрипт делал между попытками, в замеры не входили.

На успешные вызовы пришлось около 1,45 миллиона входных токенов. По ставке $0,042 за миллион из расчёта в проекте это примерно шесть центов. Фактическое списание этим расчётом не подтверждено; текущие условия зависят от провайдера и доступны у TypeSafe и в AI Gateway.

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