[Перевод] Jev нужна оркестрация, чтобы приносить пользу бизнесу

От переводчика: Зачем читать эту статью?

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

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

Второй повод в цифрах: полсекунды и примерно $1 за 20 000 заявок. На такой экономике ИИ можно встраивать прямо в поток, например проверять заявку еще до подачи. Сам автор честно предупреждает, что 100% точности получено на маленьком сгенерированном датасете, так что для проектов с BPMN/DMN статья полезна как рабочий шаблон, а не как доказательство.

Jev — что за зверь?

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

Jev — это новая модель от TypeSafe AI, стартапа бывшего исследователя OpenAI, который участвовал в создании ChatGPT.

Технически это трансформер, как и LLM, но он ничего не генерирует. Если описывать по функциональному поведению, это вероятностный классификатор или scorer общего назначения: на вход поступает текст и типизированные вопросы, на выходе — откалиброванные вероятности.

Текст ответа она не пишет: ей задают вопрос, а она отвечает вероятностью вроде «да, 92%» или выбирает вариант с оценкой своей уверенности. На ответ уходят доли секунды, а стоит он в сотни раз дешевле, чем у GPT.

Модель вышла 15 сентября, и за две недели ее подключили Vercel, Cloudflare и OpenRouter. Минусы: она не объясняет свои ответы и при повторных запросах может отвечать немного иначе, поэтому ее ставят на массовую первичную классификацию, а окончательные решения оставляют правилам и людям.

Отличная технология, но лишь один кусочек пазла

Роль Jev в бизнес-процессе — оценивать неструктурированные входные данные, например абзац текста, и выдавать структурированные данные с указанием того, насколько модель уверена. Вы даете ей данные и вопросы, на которые хотите получить ответ, и заранее определяете пространство ответов. Можно спросить: «Виновен ли этот человек, судя по его описанию?» — и получить "at-fault": 0.92.

Но не стоит просить его решать, принять заявку, отклонить ее или передать сотруднику.

Jev — это то, что получается, когда у DMN и LLM рождается ребенок: гибрид, чья ниша — запутанная середина между структурированными и неструктурированными данными. Он не может превзойти своих родителей на их территории и не может работать в одиночку. Таблицы решений и FEEL лучше справляются с детерминированными входными данными. Иногда его может подстраховать LLM, а человек-проверяющий может применить свое суждение там, где решение неоднозначно.

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

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

Тестируем проверку автостраховой заявки

Демо — проверка заявки по автостраховке: на входе заполненная заявка, на выходе решение.

Я следовал кук-буку Noul по типобезопасной самосогласованности (Typesafe self-consistency Noul cookbook) с 14 вопросами «да/нет», и тревожный сигнал появился сразу. Как минимум шесть проверок должны были получать на вход структурированные данные: франшиза, лимит покрытия, период действия покрытия, срок подачи заявления, право на аренду автомобиля и суммы по позициям. Jev не должен заменять ПО для таких проверок, потому что ПО быстрее и точнее.

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

Обвязка для Jev

Этот BPMN-процесс показывает, где Jev находится в процессе. В нем 3 шага:

1. Jev отвечает на 14 вопросов «да/нет».

2. DMN превращает ответы Jev в решение.

3. Человек включается там, где уверенность Jev была низкой или где DMN говорит, что нужно человеческое суждение.

Ключевая часть этого процесса — небольшая, но важная диаграмма требований к решениям (Decision Requirements Diagram, DRD), которая принимает решение на основе данных от Jev. DRD — это карта того, как решения DMN зависят друг от друга. Эта состоит из двух частей.

Первый шаг превращает вероятности в факты с помощью языка FEEL (Friendly Enough Expression Language). Вот пример того, как это выглядит в Operate, где он занят преобразованием входных данных от Jev в переменные, нужные таблице решений.

В этом примере диапазон от 0.3 до 0.7 означал «не знаю». Выше — «да», ниже — «нет».

И именно этот шаг проще всего настраивать при выводе в продакшен. Начните с предельно строгих требований к маршрутизации, например 0.1–0.9 для «не знаю», и ослабляйте их по мере того, как растет доверие.

На втором шаге таблица DMN применяет политику к этим производным фактам.

Эта таблица намеренно скучная. Невалидный результат? Передать человеку. Уверенно не выполнено требование? Отклонить. Требования для выплаты выполнены? Принять.

Эту реализацию придумал мой ИИ-агент для написания кода, но если бы я делал это для продакшена, я бы хотел, чтобы политики добавлялись сюда построчно, чтобы не получить расплывчатое правило вроде «сигнал для деликатной проверки».

Последний кусочек пазла — проверка человеком. Когда дело передается сотруднику, вся информация находится на той же платформе:

• исходные документы по заявке;

• оценка заявки от Jev;

• FEEL-скрипт, который сделал ее пригодной для обработки;

• сработавшее правило решения.

Именно здесь Jev и Camunda хорошо дополняют друг друга. Jev читает текст и выдает структурированные сигналы. Camunda делает эти сигналы пригодными для действий, управляемыми и проверяемыми.

Но работает ли это?

Я оценивал это по стоимости, качеству и скорости.

Со стоимостью и скоростью всё просто. В этой конфигурации весь процесс в среднем занимал 0.573 секунды на заявку и стоил $1 за 20 000 заявок. Что это значит?

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

Не стоит преуменьшать эту ценность: можно радикально сократить время обработки заявок, отлавливая ошибки еще до того, как они покинут руки клиента. Это помогает давать обещания вроде «выплата по заявке за 48 часов» и конкурировать с компаниями мирового уровня.

А вот с качеством сложнее. Его можно разделить на две составляющие:

1. Ценность: сколько решений Jev забрал у человека? Это упущенная возможность по сравнению с тем, что рекламируют все вендоры.

2. Риск: сколько неверных решений принял Jev? Это дорогостоящая ошибка, о которой узнаешь из новостей.

Поначалу этот процесс принимал правильные решения лишь в 32% случаев, пока мой ИИ-агент для кода не прогнал систему итерациями до тех пор, пока Jev + DMN не стали идеально проходить обучающие и тестовые данные. 100 из 100 заявок были направлены правильно, что выглядело подозрительно... пока я не увидел, что в промпт добавилась рубрика и конкретика о том, что именно он ищет.

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

Чего это не доказывает

Это один эксперимент на одном небольшом наборе заявок, сгенерированном ИИ.

Это не общее утверждение о качестве Jev, качестве LLM-судей или об автоматизации страхования.

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

Camunda

Сам по себе Jev классный. Он безумно быстрый, до смешного дешевый (по сравнению с LLM) и открывает дорогу моделям с открытыми весами.

В связке с Camunda и BPMN он может помогать управлять бизнес-процессами, превращая неструктурированные данные в структурированные.

Реализуйте политику в DMN. Делайте маршрутизацию и эскалацию в BPMN. Интегрируйте LLM по мере необходимости. Тестируйте, настраивайте и повторяйте, пока процесс не станет скучным и предсказуемым. Относитесь к неуверенности как к сигналу для процесса, а не как к чему-то, что нужно спрятать в ответе модели.

Это часть уроков, которые я извлек, проводя более масштабное исследование качества LLM в сравнении с Jev, Camunda Process Test и бенчмаркинга производительности.

Источник: Eric Lundberg, «Jev needs orchestration to deliver business value», LinkedIn, 25.09.2026.