Не ломать поддержку,
чтобы внедрить ИИ

Траектория агента

От обучения — к автономной работе

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

Но между демонстрацией ИИ и реальной заменой первой линии поддержки лежит длинный путь.

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

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

Плановая оценка одного такого промышленного контура — с интеграцией в тикет-систему, подключением источников знаний, интерфейсом специалиста, обучением команды, дашбордом и последующим масштабированием — составила около 490 часов работы экспертов по внедрению подобных систем. Это дорогостоящий ресурс, который нужен ещё до выхода агента в полноценную эксплуатацию.

Мы в Ladcraft предлагаем более практичный путь:

Базовый принцип выглядит так:

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

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

Так поддержку не нужно останавливать и перестраивать одним большим проектом. Агент встраивается в процесс поэтапно, а границы его самостоятельности расширяются по мере накопления подтверждённого опыта.

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

Почему попытка сразу заменить первую линию часто проваливается

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

На практике между вопросом и ответом находится целая цепочка решений. Специалист должен:

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

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

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

Поэтому первый шаг — не автономная поддержка. Первый шаг — параллельный контур, в котором агент отвечает на те же вопросы, что и специалист, но пока не влияет на клиента.

Сначала агент работает в тени

На стартовом этапе клиент и специалист продолжают действовать как обычно.

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

Возникают три связанные записи:

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

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

Задача теневого режима — собрать материал и понять:

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

Компания получает карту реальной работы, не останавливая поддержку, не меняя клиентский путь и не расширяя команду.

Самообучение — не магия и не запоминание каждого ответа

Термин «самообучающийся агент» легко понять неправильно.

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

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

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

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

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

Поэтому основной цикл удобно запускать раз в неделю, а более крупный пересмотр паттернов — раз в месяц и квартал.

Регулярная задача проходит несколько этапов:

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

Так опыт команды постепенно превращается в воспроизводимую систему.

Почему без истории обращений самообучение не работает

Чтобы сравнивать ответы и видеть динамику, агенту нужна память процесса.

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

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

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

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

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

Иначе база быстро превратится в коллекцию фраз, которые невозможно безопасно использовать в новом контексте.

Агенту нужны не только ответы, но и инструменты проверки

Первая линия редко отвечает исключительно по текстовой базе знаний.

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

Через API он может получить разрешённые данные и выполнить диагностику по установленной последовательности. При этом в архитектуре должны быть жёсткие правила:

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

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

Светофор готовности: от ученика к автономной работе

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

Для этого подходит модель светофора.

Следующие шаги

Рабочая последовательность выглядит так.

Что измерять, кроме скорости ответа

Время обработки важно, но само по себе ничего не говорит о качестве.

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

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

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

Почему эта технология шире поддержки

У первой линии есть свойства, которые встречаются во многих бизнес-процессах:

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

Та же механика применима в работе с дебиторской задолженностью, продажах, закупках, бухгалтерском контуре, проверке документов и внутреннем сервисе.

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

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

Меняется предметная область, но технология остаётся той же:

В этом и состоит её ценность для ИИ-трансформации.

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