Могут ли ИИ-агенты или RAG заменить службы поддержки? ── Причины застревания и реальные решения
Можно ли с уверенностью сказать, что идея «замены службы первичного реагирования на запросы/службы поддержки на ИИ» теперь является распространенной идеей? На самом деле, то, что я хочу сделать, ясно. Мы хотим сократить время ожидания, снизить нагрузку на операторов, сократить персонал и выровнять качество реагирования. Нет никаких возражений против этой цели.
Распространенной ошибкой является то, что в качестве метода часто выбирается метод «пусть RAG съест все». Я лично тестировал конфигурацию, которая одновременно вводит прошлые журналы, внутренние вики и историю чата, но я получил не ожидаемую эффективность, а массовое производство, казалось бы, мусорных ответов.
Вывод ясен. Возможна частичная замена, но замена ШД без проектирования сознательной эксплуатации имеет высокую вероятность отказа. И большинство неудач связано не с ошибками выбора модели. Качество входных данных и структура оперативных обязанностей являются неадекватными.
В сфере службы поддержки необходимы одновременно правильные ответы и проверяемость. Для достижения обеих этих целей единственный способ достичь обеих – это получить «официальные знания, одобренные и правильные для организации».
Сначала вывод
- Даже если вы введете весь прошлый лог, при низком качестве он будет просто искать мусор на большой скорости и возвращать мусороподобные ответы.
- Даже если вся информация внутри организации является входной, если граница между формальным и неформальным неоднозначна, это становится средством оправдания неверных ответов без учета официального контекста или правил организации.
- Структура, отвечающая только в общих чертах, противоречит правилам организации и не может использоваться в полевых условиях. — Реальное решение — запустить цикл KCS (Knowledge-Centered Service) с помощью ИИ и уточнить качество справочного источника и ответственного лица.
- ИИ, который не может ссылаться на утвержденные официальные знания, не может использоваться в работе службы поддержки.
Почему «поставить все на данный момент» не получается?
1. Журналы прошлой переписки не являются знаниями в первую очередь.
Многие журналы запросов записываются для закрытия заявок на местах. Хотя это само по себе правильно для деловых целей, этого часто недостаточно для многократного использования знаний.
- Отсутствует необходимая информация (используемое устройство, полномочия, маршрут подключения, разница в среде).
- Цель - завершить тикет, и в крайнем случае он может закончиться надписью “переписка завершена”. Не предназначен для повторного использования.
- Смесь сокращений и разговорных выражений, основанная на молчаливом знании ответственного лица.
- Основная причина и временное решение не разделены.
Если журнал в таком состоянии будет отправлен в RAG, даже если поиск будет успешным, ответ не будет точным. Это связано с тем, что ИИ может правдоподобно дополнять документы, которые являются двусмысленными или непонятными, даже если их читают люди, что приводит к созданию нереалистичных бредовых ответов. Это создает неприятную ситуацию, когда ответ приходит быстро, но проблема не решена. Даже если вы считаете, что подсказка плохая, и пытаетесь настроить ее как можно сильнее, скорее всего, это окажется напрасным. По крайней мере, это случилось со мной.
2. Полный ввод внутренней информации приводит к «официальному размыванию»
Конфигурация, которая позволяет пользователям читать «все внутренние вики», «все файловые серверы» и «все журналы чата», на первый взгляд является всеобъемлющей. Однако на самом деле это похоже на размещение на одном поисковом экране информации с разной степенью достоверности.
Обычно происходит следующее:
- Официальные процедуры (утвержденные) и личные заметки (неутвержденные) ищутся в одном столбце.
- Устаревшие процедуры остаются и противоречат новейшим процедурам.
- Временное ноу-хау ошибочно трактуется как постоянная процедура.
- Откат происходит, когда дата и время обновления статьи новые, но содержимое старое.
РАГ хорош в «поиске документов». Однако необходимо создать отдельную систему, чтобы гарантировать, что документ соответствует организации.
3. Обобщениями без знания организационных правил нельзя пользоваться, даже если они верны.
ИИ с недостаточными формальными знаниями часто возвращают ответы, которые технически верны, но практически неосуществимы.
- Предоставить права локального администратора.
- Временное ослабление настроек безопасности.
- Использование внешнего облака по индивидуальному усмотрению
- Прямой доступ к межфункциональным данным
Даже если ИИ вернет общее решение, его невозможно будет реализовать, если оно нарушает организационные правила. В настоящий момент ИИ службы поддержки может даже стать устройством, оправдывающим нарушение правил. Его нельзя использовать как решение бизнес-задач.
Примеры сбоев, возникающих на месте
Пример сбоя 1: неправильное направление из-за сбоя VPN-соединения.
- Симптом: «Невозможно подключиться к VPN из дома».
- Ответ ИИ: «Пожалуйста, инициализируйте сетевые настройки ОС и перезагрузите компьютер».
- Актуально: причиной является отзыв сертификата на стороне инфраструктуры аутентификации, и ее невозможно устранить на стороне пользователя.
почему ты проснулся? Это связано с тем, что в прошлых логах было много «временных неисправностей персональных устройств», и ИИ к ним обращался. Более того, согласно официальной информации, процедура «изолирования сбоев на стороне службы» была слабой, поэтому она не рассматривалась как лучший кандидат. Кроме того, при ответе не учитывается организационный контекст вопроса «Можно ли пользователям сбрасывать настройки NW без разрешения?».
Пример неудачи 2: Предложение о нарушении правил применения программного обеспечения
- Симптом: «Я хочу использовать инструменты анализа».
- Ответ ИИ: «Скачайте себе пробную версию и начните ею пользоваться».
- На практике: закупки, управление лицензиями и проверка ручной клади имеют важное значение для организаций.
почему ты проснулся? Это связано с тем, что официальные документы о закупках были похоронены под ссылками на внешние общие статьи и личные записки. Это типичный пример неспособности отделить «то, что можно сделать» от «то, что можно сделать».
Пример ошибки 3: один и тот же вопрос, ответ каждый раз меняется.
- Симптом: «Как настроить переадресацию электронной почты?»
- Ответ AI: Зависит от дня
- Фактически: старая страница процедуры операции и новая страница процедуры сосуществуют.
почему ты проснулся? Это связано с тем, что не было метаданных, указывающих на «действительную версию» (действительная дата начала, дата отмены, утверждающее лицо), а ответы различались в зависимости от поискового рейтинга. Когда смешиваются личные электронные письма и фрагменты чатов, вероятность того, что неформальное объяснение случайно получит более высокий рейтинг, возрастает.
Итак, что делать: запустить цикл KCS с помощью ИИ
Реальное решение — не заменять KCS искусственным интеллектом. Ускорение KCS с помощью ИИ.
Что такое ККС?
KCS (Knowledge-Centered Service) — это операционная концепция, которая записывает знания, полученные в области ответа на запросы, повторно использует их и продолжает совершенствовать. Важно не «написать документ после решения проблемы», а включить обновление знаний в сам процесс решения проблемы. Причина, по которой KCS переоценивается в эпоху RAG, проста: качество места поиска во многом определяет качество ответов.
Короткая история: старая история, но эффективная.
KCS — это идея, зародившаяся в 1992 году, намного старше AI. Однако причина его эффективности в настоящее время заключается в том, что проблемы на местах существенно не изменились.
- Лог есть, но я не могу его прочитать.
- Документ есть, но официальную версию я не знаю.
- Не обновляется и гниет
Когда вы включаете поколение ИИ, эти три вещи имеют тенденцию усиливаться, а не исчезать. Вот почему имеет смысл вернуться к простому, но нерушимому шаблону KCS, прежде чем бросаться в глаза новыми функциями.
Минимальная конфигурация для работы KCS
- «Захват»: Структурируйте и записывайте симптомы, причины, контрмеры и применимые условия при ответе на запросы.
- «Структура»: создайте шаблон и сделайте условия окружающей среды, целевой диапазон и запреты обязательными элементами.
- «Повторное использование»: обратитесь к следующему запросу и представьте ответ и базовый URL-адрес в виде набора.
- «Улучшение»: отражение различий в реальной работе и продолжение исправления двусмысленных слов и старых процедур.
Производственный цикл: подготовка ответов ИИ на основе официальных знаний
В полевых условиях вполне реально постепенно расширять сферу применения в следующем цикле.
- Пользователь сначала спрашивает ИИ
- Если AI не решает проблему, обратитесь в службу поддержки (SD).
- Преобразуйте записи корреспонденции SD в знания, используя шаблоны, подходящие для чтения ИИ.
- Добавляйте в источники справочных данных ИИ только утвержденные и проверенные официальные сведения.
- Частота первичных ответов ИИ и доля правильных ответов увеличиваются при использовании аналогичных запросов.
Ключевым моментом этого цикла является накопление знаний, которые можно использовать для «одобрения» или официальных ответов, а не для «количества». Сделайте источником данных для ИИ только «утвержденную информацию», а не «записанную информацию». Если это нарушить, диапазон ответов расширится, а точность — нет.
Области, которые можно оставить ИИ
- Кластеризация похожих запросов
- Генерация проектов ответов (с доказательствами)
- Укажите недостающие элементы («Целевая ОС неизвестна», «Не указаны необходимые полномочия» и т. д.)
- Представление кандидатов на интеграцию дублирующих знаний
Области, за которые люди должны нести ответственность
- Официальное/неофициальное решение
- Утверждение процедур и решение об их отмене.
- Разрешить обработку исключений
- Управление сроком годности знаний
Даже если вы попытаетесь предоставить это ИИ, ИИ не сможет отреагировать должным образом.
Практические моменты
На практике следует учитывать следующие моменты.
Сторона работы со знаниями
- Определить, кто и когда будет создавать и публиковать официальные знания, а также принимать решение о схеме создания и обеспечения качества.
- Определите, кто может просматривать знания и принимать решения об управлении доступом.
сторона ИИ
- Четко попросите учащихся обосновать свои ответы в подсказке.
- Не позволяйте использовать неофициальные/неавторизованные источники при формировании ответов.
Улучшена работа
- Определить способы сбора неправильных ответов ИИ и включить генерирование знаний для улучшения в нормальную работу.
Эти три пункта могут показаться абстрактными, но их реализация имеет значение. Команды, которые решают, «кто будет нести ответственность», сначала быстро совершенствуются, в то время как команды, которые не принимают решения неоднократно, совершают одни и те же ошибки.
Ответ на вопрос «Можно ли его заменить?»
Если вы спросите меня, может ли служба поддержки быть на 100% заменена агентом ИИ, текущий ответ — «нет». Однако если разбить типы запросов и установить операцию, уточняющую обязанности по информированию, Представление основных ответов, фиксированных указаний и стандартных процедур можно полностью заменить.
Другими словами, речь идет не об интеллекте самого ИИ.
- Какие знания принять в качестве официальных?
- Кто гарантирует качество?
- Кто остановит тебя, когда ты совершишь ошибку?
Только организации, которые смогут разработать эти три пункта, смогут превратить агентов ИИ из «просто инструмента быстрого чата» в «бизнес-силу». И наоборот, организация, не имеющая утвержденной официальной операции по информированию, не сможет обеспечить качество службы поддержки, какой бы сложной ни была модель.
краткое содержание
Идея о том, что «если вы включите все логи, вы станете умнее» — иллюзия. Настоящая причина, по которой ИИ службы поддержки застрял, заключается не в объеме знаний, а в отсутствии управления знаниями.
То, что нам нужно сделать сейчас, — это не тотальная автоматизация. Это скромная операция, в которой используется помощь ИИ для запуска цикла KCS и сбора официальных знаний.
Когда организации начинают принимать эту скромность, качество их ответов заметно меняется. При использовании ИИ в службе поддержки высший приоритет всегда один и тот же. **Постоянно развивать утвержденные и институционально правильные официальные знания. **
Справочные материалы
- Консорциум инноваций в сфере услуг: история KCS
- [Консорциум по инновациям в сфере услуг: Практическое руководство KCS v6] (https://library.serviceinnovation.org/KCS/KCS_v6/KCS_v6_Practices_Guide)
- [Консорциум по инновациям в сфере услуг: документация KCS v6] (https://library.serviceinnovation.org/KCS/KCS_v6)