Пилот ИИ для бизнеса: как проверить пользу до внедрения

Выберите одну задачу с понятным результатом

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

Представим отдел поддержки, где сотрудник ищет нужный пункт регламента и составляет ответ. Для первого пилота можно поручить системе поиск и подготовку черновика, а отправку оставить сотруднику. Это условный пример, а не описание выполненного проекта DigiHub.

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

Зафиксируйте, как работа устроена сейчас

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

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

• Кто принимает результат и по каким признакам?
• Какие ошибки допустимо исправить при проверке, а какие делают ответ непригодным?
• Как долго пользователь может ждать?
• При каком результате пилот будет продолжен, доработан или остановлен?

Подготовьте набор примеров для проверки

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

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

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

Проверяйте качество и границы действий

Оценивайте не только гладкость текста. Проверяйте факты, соответствие источникам и выполнение задачи. Если система должна создать запись, убедитесь, что запись действительно появилась с правильными полями. Сообщение «готово» само по себе этого не подтверждает.

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

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

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

Посчитайте затраты на весь рабочий сценарий

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

Условный расчёт: команда обрабатывает 1 000 обращений в месяц, на каждое уходит 8 минут. Если с помощником полная обработка, включая проверку, занимает 5 минут, разница составляет 3 000 минут, или 50 часов. Это пример арифметики, а не прогноз экономии.

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

Примите решение по заранее согласованным критериям

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

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

• Продолжить: качество и затраты соответствуют договорённостям.
• Доработать: выявлена конкретная устранимая причина ошибок.
• Остановить: данных недостаточно или ожидаемая польза не оправдывает затраты.

Что подготовить для обсуждения пилота

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

В DigiHub можно обратиться с этой задачей через форму ниже. На первом обсуждении важно определить границы пилота и критерии результата — они помогут оценить работу предметно.

Источник по методике оценки

Принципы проверки результата, повторных прогонов и сочетания автоматической оценки с человеческой сверены с материалом Anthropic «Demystifying evals for AI agents»: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents. Пример расчёта и план пилота в этой статье составлены для иллюстрации подхода и не являются отраслевыми нормативами.

Обсудим вашу задачу

Расскажите, как устроен процесс сейчас и что хотите изменить.