«Конечно, вам вернут всю сумму». Если для такого обещания нет оснований, мало утешения в том, что чат-бот ответил быстро и дружелюбно. В клиентской поддержке важны точность информации и последствия, к которым она приводит.
Одним промптом нельзя надёжно исключить галлюцинации генеративной языковой модели. Полезно сочетать ограниченный круг задач, проверяемые сведения, технические ограничения и работающую передачу человеку. NIST выделяет убедительно сформулированные ложные утверждения как отдельный риск генеративного ИИ. Источник: NIST, Generative AI Profile.
Следующие шесть мер составляют практический план проверки. Они не означают, что конкретный продукт после их внедрения автоматически будет работать без ошибок.
1. Ограничьте круг вопросов до оптимизации ответов
Определите, какие обращения ассистент вправе обрабатывать. Объяснить часы работы, перечислить документы или направить заявку — не то же самое, что одобрить исключение, гарантировать срок или трактовать договор.
Для каждого направления запишите три пункта: допустимый ответ, необходимый источник информации и причина передачи специалисту. В примере с возвратом ассистент может объяснить общий порядок. Обещание конкретному клиенту требует проверенного дела и соответствующих полномочий.
Проверочный вопрос: что произойдёт, если клиент прямо потребует исключения? Хорошо установленная граница сохраняется и при повторных просьбах. Она не должна держаться только на том, что модель послушно выполняет инструкцию.
2. Требуйте источники и сравнивайте их с содержанием ответа
Как документы превращаются в доступные для поиска фрагменты, объясняет наш материал о RAG для неспециалистов. Успешный поиск сам по себе ещё не подтверждает утверждение, сформулированное на его основе.
Поиск по базе знаний может предоставить подходящие фрагменты утверждённых документов. Ответ должен оставаться в их границах и позволять проверить существенные утверждения. Однако ссылки под ответом недостаточно: её содержимое должно подтверждать именно сказанное.
OWASP рекомендует, в частности, подключать внешнюю информацию, проверять результаты и обеспечивать соразмерный контроль со стороны человека. Организация также предупреждает об избыточном доверии к правдоподобным ответам. Источник: OWASP о дезинформации от языковых моделей.
Проверочный вопрос: подтверждает ли процитированное правило также названное исключение, сумму или срок? Поручите ответственному сотруднику сверять такие утверждения с оригиналом. Если клиент не вправе открыть источник из-за ограничений доступа, у внутренней команды всё равно должна быть проверяемая ссылка на него.
3. Получайте цены, даты и статусы из основной системы
Языковая модель не должна восстанавливать текущий статус заказа по старому разговору. Если достоверные данные есть в рабочей системе, целевой запрос полезнее свободной догадки. Приложение при этом должно проверить права пользователя, соответствие нужному заказу и возможные ошибки.
Также разделяйте информацию и действие. «Заказ ещё не отправлен» — это информация. «Я отменил заказ» — утверждение о выполненном изменении. Второе допустимо говорить только после подтверждения операции. Неудачный вызов системы не означает успеха.
OWASP рекомендует ограничивать инструменты и права необходимым минимумом, а для действий с существенными последствиями предусматривать отдельное подтверждение. Источник: OWASP об избыточных полномочиях.
Проверочный вопрос: как отвечает ассистент, если рабочая система недоступна? Ожидается понятное объяснение ограничения и запасной способ решения, а не подтверждение наугад.
4. Привяжите правила остановки к проверяемым основаниям
Вопрос «Насколько ты уверен по шкале от нуля до ста?» не даёт надёжно откалиброванной вероятности ошибки. Высокая оценка поискового совпадения тоже не означает, что ответ фактически верен. Если система использует пороговые значения, их смысл и пригодность нужно проверить на представительных примерах.
Понятнее конкретные причины остановки: не найден утверждённый источник, два действующих источника противоречат друг другу, отсутствуют необходимые сведения о клиенте или вопрос выходит за разрешённый круг задач. Из этого можно вывести проверяемые правила для уточнений и передачи человеку.
Проверочный вопрос: отказывается ли система отвечать даже на соблазнительно простой вопрос, если необходимой информации нет? Осознанно включайте такие случаи в приёмку. Полезный уточняющий вопрос — это хороший сервис, а не техническая неудача.
5. Сделайте передачу человеку полноценным процессом
«Обратитесь в поддержку» лишь переносит проблему, если клиенту затем приходится объяснять всё заново. Определите, что передаётся сотруднику: запрос, уже установленные факты, открытый вопрос и использованные источники. Передавайте только то, что необходимо для обработки.
Распределение ответственности тоже должно работать. Кто получает обращение? Как сотрудник узнаёт причину передачи? Что видит клиент вне рабочих часов? Указывайте только те сроки ответа, которые команда действительно способна выдерживать.
Проверочный вопрос: предложите коллеге обработать переданное обращение, не разыскивая исходный чат самостоятельно. Если важной информации всё ещё не хватает, улучшите передачу, прежде чем автоматизировать больше запросов.
6. Считайте ошибки и последствия, а не только удачные ответы
Пять идеальных вопросов дают демонстрацию. Для допуска к работе нужен определённый и документированный набор с обычными случаями, исключениями, недостающей информацией и специально вызванными сбоями. Ожидаемую реакцию задайте до теста.
Мы предлагаем учитывать следующие показатели отдельно. Общая оценка может скрыть ошибки именно в самых важных вопросах.
| Показатель | Что он помогает понять |
|---|---|
| Фактически верные ответы | Решается ли содержательная задача |
| Утверждения с реальным подтверждением | Являются ли источники чем-то большим, чем украшение |
| Необоснованные обещания | Возникают ли коммерчески рискованные утверждения |
| Полезные уточнения и передачи человеку | Умеет ли система учитывать свои границы |
| Ненужные передачи человеку | Не делает ли контроль сервис непрактичным |
| Затраты команды на исправления | Облегчает ли помощник ежедневную работу |
Проверочный вопрос: проходит ли система те же критические сценарии после изменения модели, инструкций или базы знаний? Сохраните их как повторяемые тесты и добавляйте новые ошибки из эксплуатации, соблюдая свои правила защиты данных.
Реалистичное решение о запуске
Начните с узкой темы и открыто зафиксируйте, какие вопросы продолжат решать люди. Если ошибка может привести к неверному финансовому обещанию, такому процессу нужны другие проверки, чем объяснению общей услуги.
Для разговора об ИИ в клиентской поддержке особенно полезны десять сложных реальных вопросов. Предварительно удалите персональные сведения. На этой основе можно составить конкретный план проверки и определить, какие ответы допустимо автоматизировать, а где решение должно оставаться за человеком.