Как понять, где бизнесу действительно нужен ИИ

Выберите операцию и сравните способы её автоматизации

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

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

Таблицу можно прокрутить по горизонтали.

Поиск с передачей найденных фрагментов языковой модели называют RAG (retrieval-augmented generation). Для поддержки это способ дать модели актуальные инструкции. При оценке отдельно проверяйте, найден ли нужный фрагмент, и правильно ли составлен ответ: ошибки этих двух этапов требуют разных исправлений.

Подготовьте проверочную выборку до настройки модели

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

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

Разделите примеры для настройки и итоговой проверки. Не подбирайте инструкции модели по итоговой выборке и не допускайте туда дубликаты настроечных примеров. Принцип отделения тестовых данных подробно описан в документации scikit-learn. При проверке ответов по базе знаний исходные документы могут быть доступны системе; эталонные ответы и оценки экспертов в неё попадать не должны.

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

Источники: scikit-learn: Data leakage; NIST AI 600-1: Generative Artificial Intelligence Profile.

Измерьте качество вместе с долей охваченных задач

Показатель «90% правильных ответов» мало говорит без знаменателя. Система может отвечать только на самые простые вопросы и передавать остальные человеку. Разделите долю обращений, для которых она предлагает ответ, и долю приемлемых ответов среди предложенных.

Например, из 200 обращений система подготовила 120 черновиков. Эксперт принял 108 без исправления смысла. Доля принятых черновиков составляет 90%, но полезный результат получен для 54% входящего потока. Если черновик ещё нужно читать и отправлять, это помощь сотруднику, а не полностью автоматическая обработка.

До испытания согласуйте правила оценки и форму отчёта:

• Доля принятых черновиков: что считается смысловой ошибкой, а что допустимой редактурой.
• Критические ошибки: раскрытие чужих данных, неверная сумма или обещание несуществующих условий. Считайте их отдельно от стилистических замечаний.
• Время сотрудника на чтение, проверку источника, исправление и повторную обработку. Не ограничивайтесь временем генерации.
• Отказы и технические сбои: сколько обращений вернулось в обычную очередь и какую дополнительную работу это создало.
• Задержка ответа: медиана и 95-й процентиль, то есть время, в которое укладываются 95% измеренных ответов, при указанной нагрузке.

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

Посчитайте эффект с учётом проверки и неудачных ответов

Рассмотрим условную службу поддержки с 10 000 обращений в месяц. Сейчас одно обращение требует 6 минут работы. Для 60% потока подходят ответы по базе знаний. Допустим, из этой группы 75% черновиков полезны и требуют 2 минут проверки, а остальные добавляют минуту проверки к обычным 6 минутам обработки.

Цена часа сотрудника в примере составляет 900 ₽ с учётом расходов работодателя. Время ожидания ответа модели сюда не включено: предполагается, что сотрудник в это время занимается другими обращениями. Если он вынужден ждать, ожидание тоже нужно измерить и учесть.

Таблицу можно прокрутить по горизонтали.

Денежная оценка высвобожденного времени: 275 × 900 = 247 500 ₽ в месяц. Предположим, вызовы модели для всех 6 000 подходящих обращений стоят 25 000 ₽, инфраструктура 10 000 ₽, сопровождение и обновление базы 35 000 ₽. Остаток после этих 70 000 ₽ расходов составит 177 500 ₽ в месяц.

При разовых расходах 600 000 ₽ расчётный срок возврата этих затрат равен 600 000 / 177 500 ≈ 3,4 месяца после выхода на указанный режим. В разовые расходы примера входят подготовка данных, разработка, интеграция и обучение сотрудников. Налоги, финансирование, потери от ошибок и период постепенного запуска в расчёт не включены; в рабочей модели их нужно добавить.

Проверьте чувствительность результата. Если полезны только 50% черновиков, экономия времени снизится до 150 часов, остаток после тех же расходов составит 65 000 ₽, а расчётный срок вырастет до 9,2 месяца. Все цены здесь заданы для примера и не являются рыночной оценкой.

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

Ограничьте доступ и действия модели

Внешний документ может содержать инструкцию, которая меняет поведение модели. Это один из вариантов prompt injection, или внедрения инструкций через входные данные. OWASP указывает, что использование RAG само по себе не устраняет эту уязвимость. Фильтрация текста и запрет в системной инструкции также не заменяют ограничения доступа.

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

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

Источники: OWASP LLM01:2025 Prompt Injection.

Задайте условия запуска, остановки и повторной проверки

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

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

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