Comments 7
95% правильных ответов это отлично. Но
Что вы планируете делать с 5% пользователей которые получают галлюцинации? Это пользователи тратят время на попытки сделать невозможное. Или выбирают несуществущий продукт на основе ваших рекомендаций. Я бы предположил что эти люди могут быть, мягко скажем, недовольны, и будут отказываться от ваших продуктов и создавать негативный рейтинг. Есть какой-то план по детектированию галлюцинаций в ответах ИИ?
Может быть я проглядел, но по какой метрике ответы от ИИ лучше чем выборка ответов из упомянутой выше базы знаний? Пользователям действительно более важна вариативность и человечность ответов, чем точность? Ну то есть я предполагаю что это не так для меня, допускаю что это так для некоторой части людей - но интересно, есть ли разумная метрика для этого..
Согласен с вашими замечаниями, очень в точку. Отвечу по пунктам:
5% неправильных ответов в подавляющем большинстве связаны с неоднозначностью постановки вопроса. Например, клиент не уточняет продукт, по которому задаёт вопрос. Или может быть формулировка: "Хочу красиво."
Над улучшением "понимания" предстоит поработать довольно плотно. На пилоте во время тестирования в качестве быстрого решения мы добавили кнопки "нравится ответ" и "не нравится ответ". Когда не нравится, переключаем на оператора. Это наивно, и в продакшн выпускать это не собираемся, потому что слишком высок риск, как Вы сказали, испорченного пользовательского опыта.
Следующий шаг - это в качестве ответов писать не напрямую клиенту в чат, а в систему обработки обращений UseDesk. Так мы оставляем в процессе человеческую супервизию. Оператор в начале работы с обращением сразу видит предлагаемый моделью ответ. Если ответ правильный, просто нажимает кнопку "ответить". Если нет, пишет свой вариант, а мы собираем данные для выстраивания новых связей вопрос-ответ. Планируем следить за динамикой количества неправильных ответов. В какой-то момент или периодически будем возвращаться к оценке рисков с учётом вероятности неправильного ответа.
Ещё одна идея - в чат-боте сделать выбор категории вопроса или хотя бы продукта. Это позволит существенно снизить неоднозначность. Мы частично уже подтвердили эту гипотезу, но ещё работаем над оцифровкой результатов.ИИ в нашем решении, скорее, выполняет функцию семантического поиска по базе знаний. В Confluence либо ищет оператор глазами, либо наша система. Других способов, например, захардкоженных или алгоритмических ответов у нас нет. Пытались сделать, но увязли в экспоненциально растущем числе правил. В качестве метрики на первых порах мы использовали удовлетворённость отдела поддержки. Коллеги, которые непосредственно сами отвечают на вопросы клиентов, делают супервизию ответов модели в формате "правильно-неправильно".
Вопрос с выбором между точностью и вариативностью с человечностью, скорее, можно перевести в плоскость вопросов. Наше решение позволяет в довольно произвольной форме задать вопрос, и получить на него релевантный ответ "на языке" формулировки вопроса. В классических системах (на правилах), где есть алгоритм, в качестве движка для поиска обычно используется лексический поиск. Чуть изменится формулировка вопроса - получается промах мимо правила.
У меня есть интуиция, что в итоге наше решение придёт к гибридному формату. Когда правила срабатывают не по лексическому, а по семантическому поиску. Примером такого правила может быть: "Если клиент спрашивает про оформление ипотеки, уточнить, на вторичное или первичное жильё." Семантический поиск в вопросе легко вычленит смысл "про ипотеку", даже если в вопросе сказано "займ на приобретение жилья". Это будет на первых этапах общения. До тех пор, пока продукт и/или направление обсуждения не будет достаточно однозначно выяснено. Дальше, наверное, продолжать можно будет без правил.
В качестве метрики по фактологической точности, когда дойдёт до автоматизации, мы планируем использовать тот же семантический поиск. Точнее, "семантическую близость" как его результат. У нас сотни типовых вопросов от поддержки, на которые есть человеческие ответы. Всё это собрано в одном файле. Планируем расширить до тысяч. В качестве автотетста мы можем прогнать модель по всем этим вопросам. И каждый ответ модели сравнить с человеческим ответом на предмет схожести выраженного смысла.
Дальше можно играть со статистикой, чтобы получить некую "среднюю правильность". И решить, устравивает ли нас, или оставляем всё через человеческую супервизию.
Мне как раз запрос на оценку ответа вполне зашел бы. Надо думать с формулировкой такого запроса, но в целом - норм. А вот прогон через набор обязательных вопросов в начале чат-бота - не люблю. Потому что в поддержку часто идешь со сложным вопросом, который плохо категорируется. Типа "у меня проблема сопряжения А и Б, возможно из-за В. И кстати я использую Г, поэтому стандартные опции мне не подходят". И начинается угадайка в какой раздел это могли запихнуть...
Вариант "предлагать ответ бота живому оператору" - это действительно отличный вариант, позволяющий ускорить оператора при сохранении или улучшении качества.
Попробуйте Викуну ещё.
Исчерпывающий пейпер по RAG - методу работы с внешними базами знаний для LLM, - на базе которого строится подход, описанный в этой статье.
https://arxiv.org/pdf/2312.10997.pdf
Чат-бот на ChatGPT в энтерпрайз: чего нам это стоит?