Нашёл интересный инструмент для бизнес-автоматизации: Jev от TypeSafe.
С ним не пообщаешься как с ChatGPT. Он не пишет посты и не переводит письма. Зато умеет делать вещи, которые постоянно нужны внутри ИИ-систем: сортировать обращения, выбирать подходящий материал, оценивать текст по заданным критериям и помогать определить следующий шаг.
Ты передаёшь контекст, задаёшь конкретные вопросы и получаешь значения, которые дальше использует программа. Без длинного ответа, из которого нужно вытаскивать решение.
И стоимость здесь цепляет отдельно. По тарифу TypeSafe на момент подготовки статьи вход стоит $42 за миллиард токенов. Это $0,042 за миллион. Выходные токены не тарифицируются. При таком тарифе появляется смысл проверять множество небольших вещей по ходу работы системы, а не оставлять ИИ только для редких и дорогих разборов.
Для меня здесь интересен сам подход. Внутри ИИ-сотрудника полно маленьких задач, которым вообще не нужен текст на три абзаца.
Это первичный запрос или сервисное обращение? Этот фрагмент базы отвечает на вопрос? Здесь достаточно данных или нужно уточнение?
А мы иногда вызываем большую разговорную модель, чтобы она написала ответ, который код потом превратит в один флажок.
Как нанять консультанта для сортировки входящей почты. Умеет многое. Только работа сейчас другая.
Что умеет Jev
В официальной документации описаны три типа вопросов.
Choice: выбрать вариант из заранее заданного списка. Например, определить тип обращения.
Score: оценить входные данные по заданной шкале и критериям. Например, насколько найденный фрагмент подходит к вопросу сотрудника.
Noul: вернуть значение от нуля до единицы для утверждения вроде «в этом сообщении есть запрос на обратный звонок».
Choice и Score также возвращают показатели уверенности. Несколько вопросов можно передать в одном запросе; они оцениваются независимо на общем контексте.
Дальше решение о действии принимает код. Он проверяет результат, применяет правила и выбирает следующий шаг.
Если системе нужно написать ответ человеку, генеративная модель всё равно остаётся в цепочке.
Почему это может ускорить систему
Разговорная модель обычно формирует ответ последовательно, токен за токеном. Даже если результат — короткий JSON с категорией и оценкой, она всё равно генерирует текст. Современные LLM тоже умеют работать со схемами; сам по себе структурированный ответ давно не новость.
Интерес Jev в специализации: модель сразу возвращает значения и распределения для заданных вопросов. TypeSafe заявляет типичное время ответа в диапазоне 70–500 миллисекунд. Это показатели разработчика, а задержка в конкретной системе зависит ещё от сети и объёма запроса.
Для бизнеса такая скорость полезна в повседневных действиях. Пришло сообщение — система определила маршрут. Поиск нашёл документы — система проверила их пригодность. Агент собрался вызвать инструмент — система выбрала подходящий из разрешённого списка.
На каждом шаге маленькое решение. За день таких шагов может быть много.
Куда я бы поставил его в реальном проекте
Возьмём компанию с отделом продаж. У менеджеров есть база знаний: услуги, условия, инструкции и скрипты. Отдельная система разбирает клиентские чаты и расшифровки звонков, чтобы руководитель видел проблемные обращения.
У этих задач разная природа. Когда сотрудник задаёт вопрос, ему нужен понятный ответ из актуальных материалов. Когда система разбирает поток диалогов, ей сначала нужно понять, с чем она вообще имеет дело.
В такой системе я вижу несколько конкретных задач для Jev. Дальше — пример того, как можно собрать этот маршрут, и какую пользу стоит проверить на практике.
1. Отбирать материалы для ответа
Поиск по базе может вернуть несколько похожих фрагментов. Слова совпадают, но смысл бывает разный: другая услуга, другой город, другой сценарий клиента.
До генерации ответа можно проверить каждый найденный кусок: он действительно помогает ответить на этот вопрос? В нём есть нужный факт? Есть ли противоречие с другими материалами?
Если такая проверка окажется качественной, отвечающая модель получит более подходящий контекст.
Это не обещание победить все ошибки базы. Jev не обновит старый прайс и не найдёт документ, который никто не загрузил. Но отбор уже найденных материалов — понятная задача для отдельного эксперимента.
Я бы начал именно здесь. Ошибку отбора можно увидеть и разобрать, а результат сравнить с текущим поиском.
Допустим, менеджер спрашивает: «Можем ли мы сделать срочно и сколько это стоит?» Поиск принёс общий прайс, правила стандартной услуги и инструкцию по срочному оформлению.
Можно проверить каждый фрагмент несколькими вопросами: относится ли он к нужной услуге, содержит ли ответ, противоречит ли условиям из запроса. Затем программа собирает для отвечающей модели подходящие материалы и отдельно отмечает противоречия.
В результате менеджер потенциально получает более точный ответ, а большая модель читает меньше лишнего. У TypeSafe есть отдельный технический пример такого отбора между поиском и генерацией ответа.
2. Сортировать диалоги перед глубоким анализом
Полноценный разбор нужен далеко не каждому разговору в одинаковом объёме.
Кто-то впервые спрашивает об услуге. Кто-то уточняет статус документов. Где-то разговор оборвался. Где-то клиент предъявляет претензию.
Для эксперимента можно задать категории: первичная консультация, сервисный вопрос, конфликт, технический сбой, недостаточно данных.
После этого разные категории отправляются по своим маршрутам. Конфликт требует внимания. Короткое уточнение статуса не обязательно оценивать по сценарию первой продажи.
Например, сообщение «Подскажите, мои документы уже готовы?» попадает в сервисный маршрут. «Второй день не могу получить ответ, хочу вернуть деньги» — кандидат на приоритетную проверку. Это вымышленные примеры, а не результаты прогона модели.
Потенциальный профит — меньше ненужных глубоких разборов и отдельная очередь важных обращений. Это можно измерить по пропускам, ложным тревогам и времени руководителя.
Но тут есть цена ошибки: фильтр может пропустить важное обращение. Поэтому сначала он должен работать рядом с текущим анализом. Мы сравниваем решения и разбираем пропуски. Только потом решаем, можно ли поручать ему маршрутизацию.
3. Проверять спорный сигнал
В оценке работы менеджеров мне недостаточно фразы «плохо отработал возражение».
Нужен текст разговора. Конкретный эпизод. Проверка, что возражение осталось без ответа к концу диалога.
В такой системе код может проверять совпадение цитат с расшифровкой. Это полезный барьер, но совпадение текста ещё не доказывает правильность вывода.
Следующая гипотеза: отдельной моделью проверять, поддерживает ли выбранный эпизод конкретное утверждение. Не поручать ей одним вопросом всю оценку менеджера.
Например, фраза «дорого» сама по себе не означает, что клиент потерян. Менеджер мог дальше объяснить варианты, договориться о следующем шаге или закрыть вопрос. Проверять нужно весь доступный контекст.
Даже после второй проверки спорное решение остаётся за руководителем. Две модели могут согласованно ошибиться.
4. Выбирать инструмент или модель под задачу
В одном ИИ-сотруднике могут быть поиск по базе, работа с CRM, календарь, калькулятор и несколько языковых моделей.
Вместо того чтобы каждый раз просить большую модель обдумывать весь список, можно дать Jev конкретный вопрос: какой из разрешённых обработчиков подходит для этого запроса? Добавить вариант «нужно уточнение» или «инструмент не нужен».
Проверить статус обращения — путь к CRM. Найти условия услуги — путь к базе знаний. Подготовить подробное объяснение — путь к генеративной модели.
При этом выбор инструмента не даёт права его запускать. Разрешения и ограничения остаются в коде системы. Jev помогает выбрать маршрут, исполнение проходит свои проверки.
5. Выбирать нужное значение из найденных в тексте
В письме могут быть три телефона: офис, бухгалтерия и личный номер для обратного звонка. Обычный парсер находит все три. Jev выбирает, какой из них соответствует просьбе отправителя. Код переносит исходное значение без переписывания цифр моделью.
Такая схема есть в официальных примерах TypeSafe. Её можно применять к контактам и суммам в документах, когда смысл определяется словами вокруг значения. Если парсер не нашёл нужный вариант, система должна сообщить об этом, а не угадывать.
Для CRM это интересный способ разделить работу: программа извлекает кандидатов, модель понимает их роль, программа проверяет и сохраняет результат.
Как использовать уверенность с пользой
Здесь легко увлечься правилом «больше 90% — делаем автоматически». Я бы сначала посмотрел, что именно мы измеряем и сколько стоит ошибка.
У Noul результат — вероятность положительного ответа. У Choice и Score есть распределения по вариантам и отдельный показатель confidence. Это разные поля; нельзя бездумно превратить их в один универсальный процент надёжности.
Практический принцип простой: понятный результат с проверенной на наших данных уверенностью направляем по разрешённому маршруту. Неоднозначный — на уточнение, более глубокий разбор или человеку.
Порог зависит от действия. Перенаправить заявку в соседнюю очередь и автоматически вернуть деньги — разные решения с разной ценой ошибки.
Польза такого подхода в том, что сложные случаи остаются видны. Можно отдельно считать, сколько система обработала сама, сколько передала дальше и где ошиблась.
«Не галлюцинирует» — формулировка, которую нужно читать внимательно
TypeSafe подчёркивает соответствие результата заданному типу. Модель не должна придумать четвёртую категорию, если ты разрешил только три.
Это полезное свойство для автоматизации. Но неверный вариант внутри правильного списка всё равно остаётся ошибкой.
Уверенность тоже не превращает результат в факт. На наших русскоязычных диалогах её нужно проверять отдельно. Порог нельзя просто скопировать из чужого примера.
Я бы обязательно добавлял вариант «недостаточно данных». Иначе мы сами заставим систему выбирать там, где нормальный сотрудник задал бы уточняющий вопрос.
Где я бы оставил обычные правила
Если нужно проверить, заполнен ли телефон, есть ли задача или прошёл ли срок, модель не нужна.
Это делает код. Быстро и проверяемо.
Jev интересен там, где данные уже текстовые и смысл не укладывается в простое условие: какой это тип обращения, подходит ли документ, есть ли в диалоге нужный признак.
Генеративной модели я бы оставил объяснения, подготовку ответа и сложный разбор. Получается система с разными инструментами под конкретную работу.
Что нужно знать до внедрения
Для версии Jev 1.13 разработчик прямо описывает ограничения. Модель может буквально прочитать неудачно заданный вопрос, ошибиться в числах и датах или отвлечься на лишний контекст. В отдельных случаях на ответ влияет порядок вариантов. Считать суммы и сравнивать сроки лучше кодом.
Вход текстовый. Звонок сначала нужно расшифровать, а изображение или скан — перевести в текст подходящим инструментом. Сам Jev этого не делает.
Английский — основной язык обучения. Качество на русскоязычных обращениях нужно проверять отдельно, особенно на сокращениях, ошибках и неоднозначных формулировках.
И модель не является защитой от всех манипуляций. TypeSafe предупреждает, что специально подготовленные инструкции внутри входного текста могут повлиять на решение. Поэтому я бы не поручал ей единолично разрешать чувствительные действия.
Как проверить пользу без гонки за красивыми цифрами
Чтобы почувствовать порядок цифр, возьмём расчётный пример. Десять тысяч запросов по тысяче входных токенов — десять миллионов токенов. По заявленному входному тарифу это $0,42.
Это расчёт стоимости вызовов Jev по опубликованному тарифу, а не всей системы. В него не вошли расшифровка звонков, генерация ответов, инфраструктура и ручная проверка. В реальном запросе учитывается и контекст, и сами вопросы; повторные вызовы тоже увеличивают расход.
Но даже такой пример объясняет мой интерес: дешёвые смысловые проверки можно встроить в повседневную работу. Отбирать документы, сортировать обращения, выбирать инструмент для агента. Большую модель подключать там, где нужен подробный разбор или текст для человека.
У TypeSafe есть и громкие сравнения скорости с другими моделями. Их я бы не переносил на свой проект. Компания сама оговаривает условия измерений.
Экономику конкретного проекта покажет только контрольная выборка.
Сначала нужно взять обезличенные примеры и согласовать правильные ответы с человеком, который понимает процесс. Включить короткие сообщения, неоднозначные случаи и длинные разговоры, где смысл меняется ближе к концу.
Потом сравнить текущий подход и Jev на одной задаче. Посчитать пропущенные важные случаи, ложные тревоги, задержку, стоимость и количество ручных перепроверок.
Дешёвый запрос не даёт экономии, если руководитель потом полдня разгребает неверные сигналы.
Описанный маршрут — проектная гипотеза. Его потенциальная польза понятна: более подходящие материалы для ответа, меньше лишних глубоких разборов и дополнительная проверка спорных сигналов. А размер экономии и качество решений покажет тест на данных компании.
Меня в Jev цепляет возможность убрать лишнюю работу внутри системы.
Если нужен флажок — проверяем флажок. Если нужен ответ — пишем ответ. А решение о том, что можно сделать с этим результатом, заранее фиксируем в коде.
Вот такую штуку я готов изучать дальше. Она может оказаться полезнее очередного бота, который умеет красиво рассказывать, как он полезен.