AI отвечает: «Возврат оформлен. Средства поступят в соответствии с условиями банка». Формально всё верно. Через двадцать минут клиент пишет снова: «А когда именно придут деньги и что делать, если их не будет?»
Мне нравится этот пример, потому что здесь модель ничего не выдумала. Проблема не в hallucination. Ответ просто не закрыл реальную неопределённость человека. Поэтому метрики клиентской поддержки должны видеть не только правильность ответа, но и то, пришлось ли человеку снова искать помощь.
Поэтому качество поддержки нельзя свести к factual correctness. Нужно ещё понять, был ли ответ полным, понятным и привёл ли он клиента к решению без повторного обращения.
Правильный факт и решённый вопрос — не одно и то же
Correctness отвечает на вопрос: верно ли утверждение. Resolution — получил ли клиент нужный результат или понятный следующий шаг. Между ними есть ещё полнота и ясность.
Ответ «заказ передан в доставку» может быть корректным, но бесполезным для человека, который спрашивает, успеет ли он изменить адрес. Чтобы решить вопрос, системе нужно понять цель, а не только найти релевантный факт.
Я бы оценивала ответ слоями: факты подтверждены, обязательные условия названы, действие понятно, ограничения не спрятаны, а следующий шаг соответствует текущему состоянию кейса.
Проверяемые источники: Microsoft — Dynamics 365 Contact Center overview
Повторный контакт часто показывает, чего не хватило в первом ответе
Если человек возвращается с тем же вопросом другими словами, это сильный сигнал. Но его нельзя считать провалом автоматически. Иногда ситуация действительно изменилась или клиент уточняет новый аспект.
Я бы связывала обращения по клиенту, теме, объекту и небольшому временному окну, а затем проверяла причину. Первый ответ не дал срок? Действие не выполнилось? Человек не понял инструкцию? Оператору пришлось заново собирать контекст?
Такая разметка полезнее общего показателя повторных обращений. Она показывает, где именно ломается помощь.
Проверяемые источники: Microsoft — Dynamics 365 Contact Center overview
Четыре причины формально хорошего, но бесполезного ответа
Первая — ответ сообщает факт, но не объясняет, что делать дальше. Вторая — пропускает важное условие: срок, ограничение, способ проверки. Третья — даёт инструкцию, которую клиент физически не может выполнить в текущем канале или статусе.
Четвёртая причина находится вообще вне текста. AI правильно сказал, что создаст действие, но workflow не выполнил его. Клиент возвращается, потому что обещанный результат не наступил. Если quality pipeline смотрит только на generated answer, такую ошибку он не увидит.
Мне поэтому важно связывать текст с фактическим outcome. Поддержка — это не конкурс формулировок.
- нет понятного следующего шага
- пропущено обязательное условие
- инструкция не подходит текущему состоянию
- обещанное действие не произошло
Проверяемые источники: Microsoft — Dynamics 365 Contact Center overview · NIST — AI Risk Management Framework
Не надо исправлять prompt, если сломано действие или знание
Повторный вопрос легко воспринимается как проблема формулировки. Команда переписывает prompt: «отвечай подробнее», «будь более полезным». Иногда это помогает. Часто делает ответы просто длиннее.
Я бы сначала определила источник провала. Если документ базы знаний не содержит нужного срока — обновить знание. Если retrieval выбрал старую статью — чинить поиск. Если внешнее действие не выполнилось — разбирать интеграцию. Если ответ был фактически верен, но человек не понял шаг — тогда уже работать с формулировкой.
Так повторный контакт становится диагностикой процесса, а не автоматическим обвинением модели.
Проверяемые источники: NIST — AI Risk Management Framework
Handoff тоже может решить проблему неполного ответа
Есть вопросы, где система быстро доходит до границы знаний. Мне важнее, чтобы она признала это вовремя, чем ещё два раза перефразировала тот же неполный ответ.
Если клиент уже повторил вопрос, данные конфликтуют или нужен доступ, которого у AI нет, повторная генерация редко улучшает опыт. В этот момент я бы передала разговор оператору вместе с тем, что уже выяснено.
Хороший handoff должен объяснить оператору, что клиент спрашивал и какие ответы уже получил. Человеку не нужно доказывать проблему заново.
Проверяемые источники: Microsoft — Dynamics 365 Contact Center overview
Метрика качества должна доходить до outcome
Я бы связывала три уровня: качество конкретного ответа, итог диалога и последующее поведение клиента. Correctness без повторного контакта и с выполненным действием — сильный результат. Correctness плюс новый тикет через час — повод посмотреть глубже.
Sentiment можно использовать как дополнительный сигнал, но он не заменяет resolution. Клиент может написать вежливое «спасибо» и всё равно вернуться, потому что вопрос остался открытым.
Самая полезная выборка для улучшения — именно такие скрытые провалы: ответ прошёл автоматическую проверку, но человек продолжил искать помощь. Они показывают то, что обычный QA пропускает.
Проверяемые источники: Microsoft — Dynamics 365 Contact Center overview · Microsoft — Analyze real-time customer sentiment
Иногда лучший ответ — короче, но конкретнее
После повторного вопроса есть соблазн сгенерировать более длинную версию. Но клиент мог не искать подробностей. Ему не хватало одной даты, кнопки или подтверждения, что действие действительно создано.
Я бы анализировала, какой элемент появился в успешном втором ответе. Если это почти всегда конкретный следующий шаг, его стоит добавить в шаблон качества для этого intent. Если помогает только операторское действие, не надо лечить проблему текстом.
Так повторные обращения постепенно улучшают сам сценарий. Мы добавляем недостающую помощь, а не увеличиваем объём ответа.
Проверяемые источники: Microsoft — Dynamics 365 Contact Center overview
Что обычно хочется уточнить
Почему клиент повторяет вопрос, если AI ответил правильно?
Чаще всего ответ не снял ближайшую неопределённость: не дал срок, действие, условие или понятный следующий шаг. Бывает и так, что текст верный, а обещанное системой действие не выполнилось.
Считать ли повторное обращение ошибкой AI?
Не автоматически. Нужно проверить, относится ли новый контакт к той же нерешённой причине. Повтор может быть естественным продолжением или следствием изменения ситуации.
Что важнее для QA: correctness или resolution?
Оба показателя. Correctness защищает от неверных фактов, resolution показывает, помог ли ответ закончить задачу. Один без другого даёт неполную картину.
Я бы считала хороший ответ не по тому, сколько правильных предложений он содержит. Хороший ответ уменьшает неопределённость человека и ведёт к решению. Если клиент вынужден спрашивать то же самое ещё раз, это полезный сигнал: где-то помощь остановилась раньше, чем закончилась его задача.
Если продолжать с точки зрения клиентского опыта для «метрики клиентской поддержки»: Почему AI отвечает уверенно, но неправильно · Как контролировать качество ответов AI в поддержке · Когда AI должен передать обращение оператору.