Допустим, вы хотите поручить ИИ черновики ответов клиентам. На демонстрации он пишет быстро и убедительно. Перед расширением проекта нужно понять, сколько ответов сотрудник примет, сколько перепишет и как часто система ошибётся в важном условии. Для ИТ-директора это вопрос данных, прав и надёжности. Финансовому директору нужны полные расходы на готовый результат.
Чтобы заказать AI-пилот для бизнеса, выберите одну повторяемую операцию и согласуйте её проверку до настройки модели. В плане нужны текущий способ работы, реальные входные примеры, допустимый результат, критические ошибки и учёт затрат на проверку и переделку. Ниже разберём такой план на примере черновика ответа по базе знаний. По нему можно сравнить предложения подрядчиков и решить, продолжать ли внедрение.
Что должно войти в заказ пилота
Для старта подходит операция, которую сотрудник регулярно завершает и умеет проверить. Например, готовит ответ о правилах доставки по утверждённой базе знаний. Пилот охватывает получение вопроса, поиск нужного правила, подготовку черновика и проверку сотрудником. Отправку клиенту на первом этапе оставляем человеку.
Мы предлагаем зафиксировать этот маршрут в паспорте одной операции. В нём указываем источник действующих условий, ответственного за его обновление и случаи, которые сразу уходят специалисту. Если вопрос касается индивидуальной скидки, а такого правила в базе нет, ожидаем передачу сотруднику без выдуманного обещания.
- Исходный процесс: действия сотрудника, время, ошибки и способ их исправления.
- Проверочный набор: входы, источники, ожидаемое поведение и критерии оценки.
- Ограниченная версия: разрешённые данные, интерфейс проверки, права и обработка сбоев.
- Итоговый отчёт: результаты по случаям, расходы и рекомендация о следующем шаге.
Условия доступа к данным, место их обработки, хранение журналов и удаление копий согласуем до передачи материалов. Для первого обсуждения достаточно обезличенных примеров. Подключение к рабочим системам и возможность записи требуют отдельного согласования.
Источник ответа и результат сотруднику
В примере с доставкой источником истины служит утверждённая версия правил компании. Мы предлагаем показывать рядом с черновиком использованный документ и место, на которое опирается ответ. Сотрудник проверяет срок, территорию и исключения. Если источник недоступен или два документа противоречат друг другу, задача должна перейти человеку с понятной причиной.
В нашем приложении Epicure AI мы связали подбор рецептов, меню и список покупок; отдельный сценарий позволяет распознавать блюдо по фотографии. Пользователь получает конкретные инструкции и ингредиенты. Для корпоративного пилота так же важно определить, какой результат увидит сотрудник и что он обязан проверить перед использованием.
Наш проект
Выбор рецепта и приготовление
В Epicure AI пользователь видит список рецептов и подробную инструкцию для блюда.
Как собрать набор, который проверяет вашу работу
Начните с завершённых операций за период, в котором встречаются разные типы обращений. Сохраните их состав: простые вопросы, уточнения, длинные сообщения, неполные данные. Размер набора выбирайте по разнообразию процесса и риску ошибки. Десяток удобных примеров плохо показывает, как система поведёт себя на потоке.
Мы предлагаем разделять примеры для настройки и контрольные случаи для итоговой проверки. Подрядчик может улучшать решение на первой части. Вторую часть фиксируем и сохраняем без подгонки под полученные ответы. Для каждого случая нужен утверждённый источник и описание допустимого поведения. Иногда правильным результатом будет уточнение или отказ.
Редкие опасные случаи проверяйте отдельным набором: их полезно искать специально. Если смешать их с обычными вопросами в произвольной пропорции, средний процент перестанет описывать реальный поток. В документации Google по оценке генеративных решений проверка строится вокруг своего набора, выбранных критериев и анализа отдельных ответов.
| Входной случай | Ожидаемое поведение | Что проверяем |
|---|---|---|
| Вопрос о доставке в указанный город | Черновик по действующим правилам со ссылкой на источник | Территория, сроки, условия и версия документа |
| Город не назван | Запрос уточнения | Система не обещает условия наугад |
| В базе два противоречащих правила | Передача ответственному сотруднику | Причина передачи и отсутствие случайного выбора |
| Письмо содержит команду раскрыть чужие сведения | Запрещённое действие заблокировано | Права системы и отсутствие чужих данных в ответе |
| Источник недоступен или запрос завершился сбоем | Сообщение о сбое и ручной маршрут | Сотрудник видит незавершённую задачу; повтор не создаёт лишнее действие |
Как оценивать качество и критические ошибки
Для нашего примера одна строка журнала содержит вопрос о доставке, использованный пункт правил, черновик и решение сотрудника: принять, исправить или завершить вручную. Рядом записываем время проверки и правок, версии источника, модели и настроек. Отказы и повторы сохраняем отдельными исходами. По этому журналу считаем полноту и верность условий, долю принятия без правок и время до готового ответа.
Правила оценки согласуйте заранее на нескольких примерах. Иначе один сотрудник примет неточный срок как мелкую правку, а другой забракует весь ответ. Спорные случаи разбирает назначенный владелец процесса. Автоматическая оценка может ускорять разбор, но критические факты сверяют с источником и ответственным специалистом.
Критическую ошибку определяют по последствиям для этой операции. Для ответа клиенту это может быть раскрытие чужих данных или отправка без подтверждения; для агента критическим будет действие вне разрешённых прав. Такой случай требует остановить затронутый сценарий, разобрать причину и повторить проверку после исправления. Его нельзя компенсировать большим числом хороших ответов.
Входящий документ тоже может содержать инструкцию, которая пытается изменить поведение модели. OWASP описывает этот риск как внедрение инструкций через внешние данные. Поэтому проверяем и содержание ответа, и доступные системе действия. Для тестирования AI-агента добавляем повтор после сбоя, отказ инструмента и попытку выполнить запрещённую операцию.
Как посчитать полные расходы на результат
Сравните два законченных маршрута на сопоставимых входах: работу сотрудника сегодня и работу с AI-помощником. Замеряйте активное время людей отдельно от времени ожидания системы. Долгая задержка может мешать клиентскому сервису, даже если сотрудник в это время занят другой задачей.
Для текущего маршрута учитывайте подготовку, проверку и переделки. Для пилота добавьте настройку и очистку данных, разметку примеров, интеграцию, обучение сотрудников, все обращения к модели, поиск по базе, инфраструктуру, наблюдение за работой и поддержку. Повторные запросы и неудачные попытки тоже стоят денег. Разовые вложения показывайте отдельно от ежемесячных расходов.
Стоимость принятой операции: расходы всего маршрута за период делим на число принятых результатов за тот же период, включая результаты полностью ручной работы. В расходах учитываем неудачные попытки, проверку, исправления, ручное завершение и эксплуатацию.
Среди принятых результатов отдельно показываем долю работы с AI и долю полностью ручных операций. Незавершённые задачи учитываем отдельно. Так сравниваем целый процесс.
Условный пример для расчёта труда, без тарифа 13FOX. Допустим, 100 одинаковых по сложности ответов вручную заняли по 10 минут, всего 1 000 минут. С AI каждый черновик потребовал 4 минуты проверки: 400 минут. Для 20 ответов понадобилось ещё по 8 минут исправления: 160 минут. Подготовка входов и разбор сбоев заняли ещё 50 минут. Все ответы приняты. Всего потребовалось 610 минут труда; разница составила 390 минут.
Эти 390 минут ещё нужно превратить в полезный эффект: обработать больше обращений, сократить очередь или отказаться от дополнительных рабочих часов. Они не означают автоматического снижения фонда оплаты труда. Денежную модель стройте по своим затратам на сотрудников, модель и эксплуатацию. Затем проверьте её при меньшем объёме задач и большей доле переделок.
Срок окупаемости можно оценить, когда известны разовые вложения и положительный месячный денежный эффект после всех текущих расходов. Если эффект держится только на исключении ручной проверки из сметы, расчёт нужно пересмотреть. Финансовый директор должен видеть допущения и расход на следующий этап отдельно от уже потраченного бюджета пилота.
Когда продолжать, менять или останавливать пилот
Критерий продолжения закрепите до запуска: допустимые ошибки, скорость, доля ручной работы, предельный расход и условия остановки. Значения выбирает компания для своей операции. Отсутствие критической ошибки на проверочном наборе даёт основание для следующего ограниченного этапа, но не гарантирует её отсутствия в эксплуатации.
- Продолжать: согласованные проверки пройдены, люди принимают результат, полная экономика соответствует цели. Расширяем аудиторию или объём постепенно.
- Изменить: результат полезен на части входов. Сужаем сценарий, исправляем источник или интерфейс и повторяем контрольный запуск.
- Остановить: критическое нарушение, неподходящие данные либо стоимость завершённой работы выше допустимой. Сохраняем ручной маршрут и отчёт о причинах.
После исправления добавляйте обнаруженный случай в постоянный набор проверок и берите свежие контрольные входы: решение должно справляться с новыми задачами. Критические случаи запускайте повторно при зафиксированных версиях, чтобы заметить непостоянное поведение. После смены модели, правил запроса, инструментов или источника повторяйте проверки и сравнивайте результат с принятой версией. В план поддержки включите ответственного за журнал ошибок, обновление базы и решение о возврате к ручной работе.
Что проверить в предложении команды
Попросите показать прикладной проект с похожим путём данных и объяснить, какую часть подрядчик сделал сам. Распознавание текста, интеграция с CRM и автономные действия агента требуют разных проверок. Для нашего состава работ можно начать с разработки ИИ-решений и контролируемого пилота. Если операция ещё не выбрана, сначала пригодится карта процессов для AI-автоматизации.
Сравнивайте предложения по одному паспорту операции. Для компании в Москве, Санкт-Петербурге или другом городе при удалённой работе нужен одинаково понятный порядок доступа, демонстраций и приёмки. Если требуется работа на месте, включите её в состав и смету отдельно.
Практические вопросы перед стартом
Можно ли проверить пилот без доступа к рабочей CRM?
Для первой проверки можно согласовать обезличенные примеры и ограниченную копию источника. Если цель зависит от актуальности CRM или записи в неё, этот путь понадобится проверить отдельно до запуска.
Какой процент качества считать достаточным?
Порог зависит от операции и последствий ошибки. Согласуйте критерии по типам случаев и отдельно проверьте критические нарушения. Средний процент без состава набора не даёт основания расширять внедрение.
Что делать, если пилот не показал экономию?
Разберите, где возник расход: поиск данных, проверка, исправление или эксплуатация. Можно сузить задачу и повторить оценку. Если полезного эффекта при допустимых затратах нет, завершите пилот с отчётом и сохраните текущий процесс.
Подготовим план проверки одной операции
Расскажите, какую операцию хотите проверить. Подготовьте обезличенные входные примеры и ожидаемый результат; канал передачи согласуем после обращения. Мы разберём текущий процесс, предложим план пилота, набор проверок и состав расходов для оценки.