Компания TypeSafe AI, разработчик ИИ-моделей, представила Jev, ИИ-модель для выбора и оценки внутри программ. Jev читает обычный текст, но её результатом становятся выбранные варианты и вероятности.
Чем Jev отличается от привычной LLM
Привычная генеративная LLM (большая языковая модель) строит ответ последовательно, токен за токеном. Токены - это фрагменты, на которые ИИ-модель разбивает текст. Такой способ выдачи результата позволяет писать письма, объяснения и код.
В описании обучения TypeSafe Jev показана как отдельное направление последующего обучения предобученных языковых моделей. Цель обучения Jev - выбирать значения и выдавать вероятности правильности выбора. Программа получает, например, категорию документа или оценку по заданной шкале. Вероятность должна помогать определить, когда ответу ИИ можно доверить автоматическое действие; правильность конкретного ответа всё равно нужно проверять.
По описанию разработчика в анонсе Jev, результаты Jev выдаются параллельно. В одном обращении к Jev можно задать несколько отдельных вопросов; каждый вопрос оценивается по переданным данным. Именно на такую короткую работу по выбору и оценке TypeSafe ориентирует Jev.
У привычных LLM тоже есть структурированные ответы. OpenAI ещё в августе 2024 года описала Structured Outputs, режим с соблюдением заданной схемы данных. Ответ такой LLM продолжает строиться последовательной генерацией токенов. Для Jev TypeSafe описывает обучение на выборе значений и оценке вероятностей вместе с параллельным получением ответов на несколько отдельных вопросов.
Что известно о скорости и стоимости Jev
В анонсе Jev, доступном в октябре 2026 года, TypeSafe указывает время ответа от 70 до 500 миллисекунд (от 0,07 до 0,5 секунды). Это данные разработчика из анонса. Время ответа на инфраструктуре конкретной компании нужно замерять отдельно.
На сайте TypeSafe в октябре 2026 года также стоят показатели 193,6 раза быстрее и 444,6 раза дешевле. Они относятся к собственным испытаниям TypeSafe на заданных программных цепочках задач, где другие языковые модели тоже возвращали структурированные ответы с вероятностями. Сам разработчик отмечает, что для LLM получение таких вероятностей обычно медленнее и дороже, чем выбор без вероятностей.
Есть ещё одна существенная оговорка. В сравнительных испытаниях TypeSafe эталоном служат вероятностные ответы других ИИ-моделей. Такое сравнение не показывает, сколько ошибок Jev допустит на документах или заявках конкретной компании. Поэтому эффектные множители дают повод испытать Jev, но готовый расчёт экономии для покупателя из них не получается.
В тарифе Jev на октябрь 2026 года указано 0,042 доллара за миллион входных токенов. Выходные токены бесплатны. Это цена обработки текста ИИ-моделью. В бюджет автоматизации отдельно входят подключение к системам компании, проверка ответов и работа с ошибочными результатами.
Для каких задач задумана Jev
Наиболее естественный сценарий Jev - это частый выбор из заранее заданных вариантов по тексту. Нужно определить категорию, оценить по фиксированной шкале или проверить конкретное утверждение. От ИИ-модели требуется небольшой результат, по которому можно продолжить обработку данных.
По форме это, например, такие задачи:
- Определить тип документа (счёт, договор или накладная) и передать выбранную категорию программе, которая распределяет документы.
- Оценить заполненность карточки товара по шкале с заранее описанными требованиями и вернуть оценку для дальнейшей проверки.
- Оценить вероятность того, что в переданном тексте есть условие о сроке поставки, чтобы программа могла направить документ специалисту.
Это примеры постановки вопросов, без результатов испытания Jev на документах реальной компании. Выигрыш такой специализации стоит искать там, где много повторяющихся коротких оценок и не требуется писать развёрнутый ответ.
Jev не генерирует письма клиенту, код и текстовые объяснения своего выбора. Сложные задачи TypeSafe рекомендует делить на отдельные вопросы и объединять ответы программными правилами; при необходимости в систему добавляется ИИ-модель для развёрнутого рассуждения.
У русского текста есть отдельное ограничение. В той же документации Jev разработчик пишет, что основной язык обучения и лучшего качества сейчас английский. Для русскоязычных документов и обращений нужны свои испытания, даже если тип задачи подходит интерфейсу Jev.
Для поддержки интернет-магазина первым результатом обработки обращения часто становится выбор ответственного отдела (доставка, возвраты или расчёты). Подготовка письма клиенту будет следующим этапом. На сортировке обращений удобно рассмотреть, что даёт такой способ получать ответы ИИ и чего он ещё не доказывает.
Какой результат нужен для сортировки обращений
Представим поддержку интернет-магазина. Клиент пишет, что товар пришёл повреждённым, просит вернуть деньги и сообщает новый адрес. Это условная сцена, без истории реального клиента.
В одном письме несколько просьб. Единственная метка возврат ещё не определяет, что делать с каждой просьбой. Можно потерять вопрос об адресе, а поручение вернуть деньги требует отдельной проверки заказа и полномочий сотрудника или программы.
Поэтому до выбора ИИ полезно описать результаты каждого этапа.
| Задача обработки обращения | Что нужно получить |
|---|---|
| Распределить обращение по отделам | Один ответственный отдел или несколько отдельных задач, если просьб несколько |
| Определить срочность | Категорию срочности по правилам компании |
| Подготовить ответ клиенту | Текст с учётом обращения и сведений о заказе |
| Выполнить возврат денег | Проверенное основание, сумму и разрешение на операцию |
Для первых двух задач возможные категории можно перечислить заранее. Для письма клиенту нужен текст. Для возврата денег требуется доступ к учётной системе и правило, кто вправе подтвердить операцию. Эти результаты проверяются по-разному.
Классификация - это отнесение обращения к категории. Маршрутизация - это назначение ответственного или передача заявки в нужный отдел. Первая задача даёт входные данные для второй, но выбранная категория сама по себе ничего в учётной системе не меняет.
Что обещает структурированный ответ ИИ
В документации Jev, доступной в октябре 2026 года, выбор категории оформлен отдельным типом вопроса Choice. Программа получает выбранный вариант и распределение вероятностей по заданным вариантам. Среди примеров разработчика как раз есть выбор отдела, который должен обработать обращение.
Программа получает название отдела в заранее согласованном поле ответа ИИ; допустимые названия отделов берутся из заданного списка.
У режима Structured Outputs, описанного OpenAI, есть оговорки, в том числе отказ отвечать и незавершённая генерация. OpenAI также предупреждает, что ошибки в значениях внутри ответа остаются возможными.
Получить допустимое название отдела и получить правильное назначение - это разные результаты. Отдел возвратов может существовать, ответ может быть оформлен безупречно, а обращение на самом деле нужно отделу доставки.
Поэтому сравнивать стоит оба результата. Сколько ответов программа смогла обработать без технической ошибки? И сколько обращений компания действительно направила нужному исполнителю? Ошибки доступа, превышение лимита запросов и недоступность сервиса тоже требуют заранее предусмотренного пути обработки заявки.
Почему 99% точности классификации обращений могут скрыть пропуск всех срочных заявок
Возьмём учебный пример, придуманный для объяснения. В тысяче обращений 990 обычных и 10 срочных. Допустим, программа каждое обращение относит к обычным.
Тогда программа правильно классифицирует 990 обращений из 1000. Общая доля правильных ответов составляет 99%. При этом программа пропускает все 10 срочных обращений.
| Что проверяется в учебном примере | Результат |
|---|---|
| Правильно определённая категория среди всех обращений | 990 из 1000, или 99% |
| Обнаруженные срочные обращения | 0 из 10 |
| Пропущенные срочные обращения | 10 из 10 |
Все числа в примере придуманы. Результатов испытания Jev или другой ИИ-модели в этой таблице нет.
Общая доля правильно классифицированных обращений здесь почти ничего не говорит руководителю, которого беспокоят срочные заявки. Нужен отдельный счёт пропусков срочных обращений.
В реальном испытании сначала надо определить, какие ошибки особенно дороги компании. Для логистики это может быть обращение об изменении адреса до отправки посылки. Для интернет-магазина критичной может оказаться жалоба, которую система отправила в отдел, не работающий с претензиями. Последствия зависят от правил конкретной компании, поэтому одинаковая общая точность ещё не означает одинаковую полезность двух систем.
Как использовать уверенность ИИ при передаче заявки оператору
Кажется заманчивым разрешить автоматическое назначение, если ИИ-модель высоко оценила уверенность в ответе. Но сначала нужно выяснить, что именно означает этот показатель.
В документации TypeSafe об уверенности, прочитанной в октябре 2026 года, поле confidence для Choice вычисляется из распределения вероятностей по вариантам ответа. Значение зависит от наибольшей вероятности и количества вариантов. Это отдельный показатель, его нельзя автоматически читать как долю правильных назначений на обращениях конкретной компании.
Для допуска к автоматической работе полезнее наблюдать, сколько ошибок ИИ-модель делает на проверенных специалистом заявках при разных порогах уверенности. Порог подбирается на примерах для настройки, затем фиксируется до проверки на отдельной контрольной выборке.
У двух ИИ-моделей могут быть разные шкалы уверенности. Поэтому один и тот же числовой порог не обеспечивает одинакового риска. Сравнение строится вокруг общего требования компании к ошибкам, например к пропускам срочных заявок. Каждая система получает свой порог, при котором проверяется соблюдение этого требования.
Передача оператору тоже должна иметь определённый результат. Недостаточно указать, что ИИ не уверен. Нужно назначить очередь, исполнителя и срок обработки заявки. Иначе осторожная автоматизация превращается в накопитель обращений без ответственного.
Какие способы классификации обращений стоит сравнить
Для выбора ИИ можно начать с нескольких кандидатов:
- Правила по полям формы и явным признакам обращения. Подходящий вариант для проверки, если клиент уже выбрал тему, а дальнейшее назначение определяется заполненными полями.
- Классификатор, настроенный на размеченных специалистами обращениях компании. Кандидат для задачи с устойчивым набором категорий.
- Языковая модель со структурированным ответом. Кандидат для обработки свободно написанных обращений, в том числе когда рядом нужна подготовка текста.
- Специализированная ИИ-модель с выбором из заданных вариантов, как Jev. Кандидат для отдельной задачи классификации, если конкретный сервис подходит по условиям использования и обработки данных.
Такой список нужен для сравнения на заявках компании. Само название подхода победителя не определяет. Если задача решается правилами по заполненной форме, это тоже результат выбора способа автоматизации.
Jev здесь служит примером специализированного способа получать результат ИИ. Выбор сервиса для российских компаний требует отдельной проверки условий поставки, места обработки данных и допустимых прав системы. Зарубежный анонс такой проверки не заменяет.
Что должно остаться у компании после испытания ИИ
Чтобы сравнение не закончилось впечатлением от демонстрации, до запуска полезно договориться о составе отчёта:
- Перечень категорий и правило назначения ответственного. В нём отдельно описаны обращение вне списка и письмо с несколькими просьбами. Примеры из разных категорий согласованы со специалистом компании.
- Примеры для настройки и отдельные обращения для контрольной проверки. На контрольных обращениях не подбираются инструкции, категории и пороги уверенности. Повторные письма по одной заявке лучше держать в одной части набора, чтобы одна история не попала одновременно в настройку и проверку.
- Ошибки по каждой категории и отдельно по критичным заявкам. Для срочных обращений в отчёте видны число обнаруженных и число пропущенных заявок. К ним приложены сами ошибочно направленные обращения и правильные назначения специалиста.
- Доля заявок, обработанных автоматически, и работа, оставшаяся людям. Сколько обращений отправлено оператору, сколько назначений исправлено и какое время ушло на исправление. Это нужно считать вместе с расходами на использование ИИ.
- Правила дальнейших действий и отказов сервиса. Кто принимает заявку при недоступности ИИ, кто подтверждает возврат денег, кто отвечает за письмо, в котором несколько задач.
В отчёте полезно видеть, какую долю обращений каждая система обрабатывает автоматически при соблюдении заданного требования к критичным ошибкам. Если ошибок слишком много, автоматическое назначение придётся ограничить. Если почти все заявки всё равно проверяет оператор, это тоже должно быть видно до покупки.
Расходы на ИИ и время сотрудников стоит оценивать вместе. Этому посвящена отдельная статья БизнесМатики об окупаемости внедрения ИИ.
Для сортировки обращений полезен тот ИИ, после которого заявка оказывается у нужного исполнителя в нужный срок. Вежливый ответ, допустимая категория и высокий показатель уверенности ещё не подтверждают, что компания получила именно такой результат.
