ИИ для техподдержки: ассистент первой линии по вашей базе знаний

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

• Ответ только из найденного. Текст собирается из фрагментов, которые поиск вернул по вашей базе знаний и документации. Знания самой модели о вашем продукте для фактов не используются.
• Нет ссылки — нет ответа. К каждому ответу прилагается источник: статья, раздел, дата редакции. Ответ без источника считается ошибкой, даже если он верный.
• Сомнение уходит человеку. Если подходящего фрагмента нет, он ниже порога уверенности или тема в списке запрещённых, ассистент не отвечает по существу, а передаёт обращение оператору. Вместе с ним уходит собранный контекст: краткое изложение, найденные статьи, версия продукта, что клиент уже пробовал. О пороге подробнее — в статье «Порог уверенности модели».
• Обращение — недоверенный ввод. Текст письма или чата может содержать чужие инструкции для модели. Права есть у кода вокруг модели, а не у самой модели.

Чем это отличается от чат-бота для техподдержки

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

Язык и тон ответа

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

Классификация: тема, срочность, продукт

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

Какой механизм классификации взять, решает замер на вашей выборке. Для небольшого набора устойчивых тем иногда хватает классического классификатора или небольшой модели, для разнородных писем с несколькими вопросами сразу нужна языковая модель. Редкие темы тонут среди частых, поэтому качество смотрим по каждому классу, а не в среднем по выборке. Выбор между поиском по документам и дообучением модели для таких задач разобран в статье «RAG или дообучение LLM».

Маршрутизация: куда передать и что приложить

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

Связь с системой заявок

Ассистент подключается к вашей системе заявок через её API, вебхуки или очередь сообщений. Сначала только чтение: новые обращения, история, статусы. Запись добавляется отдельно и позже, через отдельную учётную запись ассистента с ролью только на нужные действия; в базу системы заявок мы напрямую не пишем. Какие операции доступны, зависит от вашей системы и её версии, и что умеет интерфейс, выясняется на обследовании. Если интерфейса нет или он ограничен, остаётся панель подсказок рядом с заявкой без записи: режимы 1 и 2 это не отменяет.

Повторная доставка события (одно обращение пришло дважды) не должна создавать вторую заявку, поэтому у каждого действия есть ключ идемпотентности. Общий подход к правам, подтверждениям и откату описан в статье «Как ограничить ИИ-агента».

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

Что входит в выборку

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

Что считаем

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

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