Что показал кейс — и чего он пока не доказал

Небольшой хорватский дилер Adria P.A. обратился в EDIH Adria из-за знакомой сервисному бизнесу проблемы: обращения по продажам и обслуживанию приходят волнами, а вечером клиенту всё равно нужен ответ о наличии, цене или записи в сервис. Компания относится к малому бизнесу — 10–49 сотрудников — и до проекта не имела практического опыта с ИИ.

Команда провела проект по принципу test before invest. Сравнили готовую чат-бот-платформу и более гибкое решение на открытых технологиях, затем собрали RAG-ассистента: модель отвечает не только из своих параметров, а получает релевантные фрагменты из корпоративной базы знаний. В базу вошли интервью с сотрудниками, прайс-листы, описания процессов продаж и оцифрованные руководства по автомобилям.

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

Отделяем прогнозы от измеренного результата

В карточке кейса приведены привлекательные ориентиры: рост удовлетворённости на 10–20%, снижение затрат труда поддержки на 20–30% и повышение конверсии лидов на 10–15%. Там же ожидается сокращение ответа на частые вопросы с часов или дней до секунд. Это не подтверждённые результаты эксплуатации, а прогнозы для будущего внедрения.

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

Поэтому кейс полезнее читать как карту проверки гипотезы:

  • рутинные вопросы действительно подходят для автоматизации;
  • знания сотрудников нужно собирать отдельно, а не надеяться только на архив PDF;
  • текстовый канал следует доказать раньше голосового;
  • интеграция с CRM и ERP важна, но права на запись нужно выдавать после проверки качества;
  • финансовый эффект возникает только тогда, когда освобождённое время сотрудников превращается в измеримый результат.

Почему «загрузить инструкции» оказалось недостаточно

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

Для клиентского ассистента полезнее выделить управляемые сущности:

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

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

Интервью с сотрудниками в Adria P.A. оказались важны именно потому, что реальный процесс обычно шире регламента. Менеджер знает, какой уточняющий вопрос задать, когда обещание нельзя давать без проверки и в какой момент разговор должен перейти человеку. Эти знания нужно превращать в сценарии и критерии эскалации, а не оставлять в виде свободного конспекта.

Практичная архитектура для российского малого бизнеса

Для первого контура не нужен автономный агент с доступом ко всем системам. Безопаснее начать с ассистента, который читает разрешённые данные, готовит ответ и передаёт сложные случаи сотруднику.

Рабочая схема выглядит так:

1. Обращение приходит из сайта, мессенджера или формы обратной связи.
2. Классификатор определяет намерение, филиал, продукт и чувствительность запроса.
3. Поиск выбирает документы и записи только в рамках прав пользователя и канала.
4. Модель формирует короткий ответ со ссылками на внутренние источники и уровнем уверенности.
5. Проверки блокируют обещания, которых нет в источнике: окончательную цену, наличие, гарантийное решение или срок ремонта.
6. Низкая уверенность, конфликт источников и нестандартное намерение отправляют диалог сотруднику вместе с найденным контекстом.
7. В CRM сначала сохраняется черновик или событие через очередь, а не необратимое действие от имени модели.

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

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

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

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

Этот набор делят на разработочную и закрытую проверочную части. На нём измеряют не абстрактную «умность», а точность маршрутизации, полноту найденного контекста, подтверждённость ответа источниками, долю корректных отказов и качество передачи оператору. Инструменты оценки RAG предлагают метрики точности и полноты контекста, релевантности ответа и faithfulness — соответствия ответа извлечённому контексту. Автоматическую оценку полезно дополнять ручной проверкой профильного сотрудника.

Четыре недели теневого пилота

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

Минимальный протокол:

  • неделя 1: инвентаризация источников, владельцев и сроков актуальности;
  • неделя 2: сбор эталонного набора и настройка поиска;
  • неделя 3: теневой прогон на новых обращениях, разбор ошибок и правил эскалации;
  • неделя 4: ограниченный текстовый канал для одного типа частых вопросов с подтверждением сотрудника.

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

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

Как считать экономику без обещаний «минус 30%»

Соберите модель на своих данных. Пусть в месяц поступает 4 000 обращений, среднее активное время сотрудника — 6 минут, полная стоимость часа — 900 рублей. Базовая стоимость обработки равна 360 000 рублей в месяц. Если ассистент безопасно закрывает 25% обращений, а проверка и эскалации возвращают половину сэкономленного времени, чистый эффект по труду составит около 45 000 рублей в месяц.

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

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

Риски до подключения CRM и ERP

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

Для первого этапа нужны простые границы:

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

Голос добавляет ещё один слой ошибок: распознавание речи, имена, номера, акценты и шум. Опыт Adria P.A. показывает разумный порядок — сначала доказать текст, затем отдельно измерить качество распознавания на реальных звонках и только после этого объединять каналы.

Следующий шаг руководителя

Не начинайте с выбора «самой сильной» модели. Выберите один узкий поток частых обращений, назначьте владельца источников и соберите 100–200 реальных примеров. За четыре недели сравните ответы ассистента с работой сотрудников в теневом режиме. Если система подтверждает ответы источниками, корректно эскалирует сложное и даёт экономический эффект на ваших объёмах, подключайте один внешний текстовый канал. Права на запись в CRM или ERP оставьте следующему этапу.