Decision-модели: как AI выбирает действия для бизнеса

Почему decision models обсуждают сейчас

15 сентября 2026 года TypeSafe представила Jev и открыла ранний доступ. System One — название подхода у поставщика. В анонсе он противопоставляет генерации текста типизированные вероятностные решения. Заявления о скорости, стоимости и надёжности относятся к условиям его испытаний; они не доказывают преимущество в вашем процессе.

13 октября Vercel опубликовала разбор включения decision-моделей в приложения. 20 октября вышел материал IBM о доверии к их оценкам, обновлённый 21 октября. Это прикладные публикации после сентябрьского анонса, а не новый запуск Jev. Рост поискового интереса по временному ряду мы не измеряли.

Классификация и оценка вероятностей существовали раньше. В этой статье рассматриваем конкретный интерфейс ограниченного выбора на примере Jev. Более широкое понятие decision intelligence включает и другие способы организации решений; считать его синонимом одного продукта было бы неверно.

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

Choice, Score и Noul: три разных результата

В документации TypeSafe, проверенной 1 ноября 2026 года, описаны три типа вопросов. Это интерфейс конкретного поставщика, а не обязательный стандарт всех decision-моделей.

• Choice — один вариант из списка: например, группа обработки обращения. Возвращает выбранное значение choice, распределение probabilities по вариантам и confidence.
• Score — положение на описанной шкале. Возвращает score, распределение по уровням и confidence. Итоговая оценка — взвешенное по вероятностям среднее номеров уровней, поэтому может быть дробной. Это не вероятность правильного ответа.
• Noul — вероятность ответа «да» на один вопрос. Поле noul лежит от 0 до 1; отдельного confidence здесь нет. Значение около середины означает неопределённость между «да» и «нет», а не среднюю степень свойства.

Для маршрута полезен Choice, для ранжирования по явно описанным уровням — Score, для отдельного признака — Noul. Например, «просит ли клиент оператора?» и «насколько сложен вопрос?» требуют разных критериев. Смешав их в одну оценку, трудно понять, почему система отправила заявку в ту или иную очередь.

Для пилота зафиксируйте доступный способ подключения, условия обработки данных и версию модели. Сентябрьская пометка early access описывает состояние на дату анонса; она не подтверждает доступность сервиса для конкретного аккаунта или проекта сегодня. В этой статье мы не подключали API и не проверяли инференс Jev.

Что выбрать: правила, decision-модель или LLM

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

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

LLM тоже умеет выдавать структурированные ответы: сам факт получения JSON не доказывает преимущество decision-модели. Сравнивайте долю верных решений, пропуски важных случаев, задержку всего процесса и стоимость с учётом ручной проверки.

Выбор компонента отличается от выбора продукта целиком. О границе между настройкой готового решения и разработкой процесса — в статье «Готовый AI-ассистент или заказной агент».

Учебная схема: как направить обращение

Вымышленный пример, не клиентский кейс и не ответы Jev. Возможные маршруты ниже выбраны редакционно. Мы не запускали модель, не создавали тикеты и не присваивали искусственные оценки уверенности.

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

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

Такую постановку можно использовать при обсуждении AI-поддержки. Первый полезный результат пилота — понять, какие категории действительно различимы, а какие операторы трактуют по-разному.

Ещё два сценария: документ и следующий этап

Классификация документа. Возможная задача — отличить счёт, акт и неизвестный тип. Если файл неполный или не читается, путь ведёт к повторному получению документа или сотруднику. Распознавание текста, проверка реквизитов и запись в учётную систему остаются отдельными шагами. Категория «счёт» не подтверждает сумму и не разрешает оплату. Это один из компонентов обработки входящих документов.

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

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

Это гипотезы применения, не описание внедрений Dev Crabs. Передача результата в CRM, ERP или helpdesk относится к интеграции систем по API: там нужны обработка сбоев, журнал и защита от повторного выполнения.

Почему уверенность не гарантирует правильность

TypeSafe определяет confidence для Choice и Score как характеристику распределения вероятностей. Она показывает, насколько определённо модель выделяет ответ, и не тождественна вероятности выбранного варианта. Поэтому нельзя читать confidence=0.9 как обещание «90% таких решений верны».

Разбор IBM ставит вопрос о калибровке: соответствует ли заявленная уверенность наблюдаемой правильности. Для вашего процесса это проверяемое свойство, а не следствие названия модели. Высокая уверенность бывает и у неверного ответа.

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

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

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

Как выбрать узкий пилот

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

1. Опишите решение. Один вход, конечный список исходов и ответственный за каждый. Зафиксируйте смешанные случаи и причины передачи человеку.
2. Подготовьте разрешённые данные. Согласуйте, какой контекст можно передавать выбранному поставщику. Разметьте примеры вместе с владельцем процесса; разногласия между экспертами сначала превратите в уточнения правил.
3. Сохраните базу сравнения. Текущий ручной процесс или правила; при необходимости — LLM с заданной структурой. Отделите примеры настройки от итоговой проверки.
4. Измерьте полезный результат. Верные маршруты по каждой категории, опасные ошибки, ручные передачи, повторные обращения, задержку и полную стоимость. Учтите вызовы, интеграцию, исправления и работу оператора.
5. Проверьте исключения. Недостающие данные, новые формулировки, противоречия, сбои API и повторную доставку. Запишите, кто восстанавливает процесс и как отключить автоматический выбор.
6. Примите решение о расширении. Автоматизируйте только тот участок, где результат принят владельцем процесса. При смене категорий, источников или модели повторите затронутые проверки.

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

Частые вопросы