Расскажите про проект с чат-ботом
Что проверяют
Понимаете ли вы, что бота оценивают не точностью классификатора, а долей обращений, закрытых без человека, и тем, сколько людей ушло разочарованными. Смотрят, был ли реальный прод: разметка на живых данных, поведение при неуверенности, передача оператору, наблюдение за качеством после запуска.
Как отвечать
Ведите рассказ от задачи к эксплуатации:
- задача: какие обращения должен был закрывать бот и что считалось успехом;
- данные: откуда брали примеры (история переписок и обращений), как размечали, что делали с редкими темами и с запросами вне сценариев;
- устройство: распознавание намерения и извлечение сущностей, поиск по базе знаний через эмбеддинги, генеративная часть поверх найденных документов;
- поведение при неуверенности: порог, уточняющий вопрос, передача оператору с сохранением контекста. Это важнее качества классификатора;
- оценка: офлайн на отложенной выборке реальных обращений, затем онлайн-сравнение с контрольной группой;
- эксплуатация: персональные данные в логах, бюджет задержки и стоимость ответа, кэш частых вопросов, ловля деградации после изменений.
Отдельно стоит сказать, как собирали обратную связь и что делали с диалогами, где бот не справился. Разбор таких случаев обычно и даёт основной прирост качества.
Где спотыкаются
Рассказывают про фреймворк вместо задачи: выбрали такой-то инструмент, обучили модель. Непонятно, какую проблему бизнеса это решало и стало ли лучше.
Приносят метрику модели вместо продуктовой. Высокая точность распознавания намерений ничего не говорит, если бот уверенно отвечает не по адресу, а клиент всё равно уходит к оператору.
Не говорят, что происходит, когда бот не понял. Без явного порога и передачи человеку бот начинает придумывать ответы, и один такой ответ про деньги или сроки стоит дороже всей экономии на поддержке.