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

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

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

Сначала выделите операцию, за которую кто-то отвечает

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

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

Назначьте владельца процесса. Он определяет, какие ошибки мешают работе, предоставляет сотрудников для проверки и принимает решение о внедрении. ИТ отвечает за техническую реализацию, но не может самостоятельно решить, допустимо ли отправлять клиенту ответ с неуточнённой датой поставки.

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

Сравните ИИ с самым простым рабочим решением

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

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

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

Подготовьте испытания до настройки подсказок

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

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

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

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

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

Разведите качество, охват и тяжесть ошибки

Одна «точность 95%» почти бесполезна без знаменателя. Система могла правильно ответить на большинство простых вопросов и ошибиться во всех запросах, связанных с индивидуальными условиями. Она также могла отказаться от половины задач, повысив качество оставшихся ответов.

Для пилота с черновиками удобно вести несколько показателей:

Для каждой метрики закрепите числитель, знаменатель и правила учёта. Если из 200 заданий помощник подготовил 150 черновиков, а 120 приняли без исправлений, охват составил 75%, приёмка среди предложенных результатов — 80%, а доля всех заданий, закрытых без редактирования черновика, — 60%. Это три разных ответа на три управленческих вопроса.

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

NIST описывает конфабуляцию как уверенную генерацию ошибочного или ложного содержания; внешне убедительное объяснение само по себе не подтверждает ответ. Поэтому субъективное ощущение «звучит профессионально» нельзя использовать как критерий фактической правильности. Профиль рисков генеративного ИИ NIST AI 600-1.

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

Время ответа также не стоит описывать одним средним. Сотрудник может терпимо относиться к обычным пяти секундам и терять рабочий ритм из-за регулярных минутных задержек. Покажите медиану и время, в которое укладываются 95% запросов, отдельно учитывая сбои и повторные попытки. Заранее решите, когда ожидание прекращается и задание передаётся в обычную очередь. Иначе технически успешный, но слишком поздний ответ ошибочно попадёт в полезные результаты.

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

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

Предположим, помощник предлагает результат для 800 операций. Для 600 из них проверка и завершение занимают три минуты, для 200 требуется восемь минут с исправлениями. Ещё 200 операций остаются полностью ручными и занимают те же восемь минут. Получаем 600 × 3 + 200 × 8 + 200 × 8 = 5000 минут. Высвобождается 3000 минут, то есть 50 часов в месяц.

Если полная стоимость часа специалиста для внутреннего расчёта составляет 1200 рублей, денежный эквивалент высвобождённого времени равен 60 000 рублей. Предположим также, что использование модели, инфраструктура и сопровождение стоят вместе 25 000 рублей в месяц. Остаток расчётного эффекта — 35 000 рублей. При первоначальных затратах 350 000 рублей простое деление даёт десять месяцев условной окупаемости после выхода на этот стабильный режим.

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

Проверьте чувствительность расчёта. Если ежемесячный объём уменьшится вдвое при прежних 25 000 рублей регулярных затрат, денежный эквивалент времени составит 30 000 рублей, а остаток — всего 5000. Такой проект гораздо сильнее зависит от загрузки, чем кажется на демонстрации.

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

Спроектируйте место ошибки в процессе

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

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

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

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

Проведите пилот в двух режимах

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

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

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

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

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

Заранее разрешите себе остановиться

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

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

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

Все материалы →