Когда Elasticsearch встречает интеллектуальных роботов для обслуживания клиентов

Нашими основными сервисными позициями являются приложения на MAC - продукты серии Dr.cleaner и Dr.X.

Dr.cleaner занимает первое место среди приложений для очистки MAC во многих странах и регионах, совершая почти миллион ежедневных действий.

Счастливые неприятности: обслуживание клиентов

Многоязычный, вне часовых поясов: наше приложение может быть не очень известно в Китае, его нынешние клиенты в основном находятся за границей, из которых Соединенные Штаты являются основным клиентом, а также есть пользователи из других стран и регионов.

Количество не поспевает: при резком увеличении числа пользователей количество служб поддержки клиентов не поспевает за увеличением числа пользователей.

Решение: робот для обслуживания клиентов

Робот обслуживания клиентов может, во-первых, решать проблемы, связанные с продуктом, а во-вторых, он может решать технические проблемы, связанные с MAC / IOS, Для многоязычных проблем его необходимо перевести на английский язык через API перевода, а затем попытаться дать решения.

Если какая-либо интеллектуальная служба поддержки клиентов не имеет достаточной поддержки базы знаний, то каким бы мощным ни был ее алгоритм, она не будет работать. Поэтому мы захватили множество веб-сайтов, связанных с MAC, и добавили их в нашу базу данных.

Подфорум StackExcangeApple (общедоступный источник данных), обсуждение Apple, мир Mac, WikiHow…

Как понять, что нам нужно из базы знаний по документации, когда возникают вопросы пользователей? Мы пробовали использовать ES непосредственно раньше, но это все еще слишком далеко от семантики, и эффект не очень хороший.

Есть у ОМП и очевидные недостатки, сложность его алгоритма очень высока, а скорость вычислений очень низкая. ОМП не панацея, даже после ОМП можно получить не очень хорошие результаты.

Наша база знаний сначала пройдет слой фильтрации ES. Исходная база знаний составляет около сотен тысяч, и если ее напрямую вычислить с помощью ОМП, скорость будет очень медленной. ES в определенной степени гарантирует, что его литералы не такие запредельные, и все же может что-то сопоставить, когда литералы похожи.

Это самое примитивное отображение, и мы будем шаг за шагом оптимизировать его на основе этого отображения.

После использования BM25, когда частота встречаемости слова выше и достигает определенного порога, его влияние очень мало.

Мы провели эксперимент и изменили сопоставление, чтобы использовать BM25 или TFIDF соответственно. Случайным образом выберите 100 вопросов и 10 ответов из базы знаний, дайте запрос ES, а затем сравните результаты с обеих сторон.

Всего у нас было 10 раундов, и в каждом раунде было 100 ответов. Как видно из приведенного выше рисунка, повторяемость двух алгоритмов составляет около 91%.

Согласно эксперименту, роль BM25 все еще относительно очевидна.В конце концов, мы использовали BM25 для выполнения алгоритма подобия.

Оптимизация: проверка орфографии и исправление ошибок

Наше решение: Term Suggester + Custom Analyzer

Использование предложения терминов

Поддерживает прямой ввод предложения: Как заменить macbookk SSD?

Термин Suggester настраивается сам

Установите минимальное количество вхождений на 3, измените «string_distance» и измените его на «jarowinkler». Его сходство по умолчанию основано на некоторой настройке расстояния редактирования, и расстояние редактирования по умолчанию выводит целое число.

Увеличьте поддержку данных о поведении пользователей. Большая часть алгоритма Google поддерживается данными о поведении пользователей.

«Глядя вперед и оглядываясь назад», с нашей точки зрения, мы должны учитывать отношения между двумя словами до и после.

Сначала используйте Gensim для создания фраз-кандидатов, а затем используйте правила для фильтрации более точных фраз-кандидатов. Когда мы получаем правильную фразу, мы можем генерировать распространенные орфографические ошибки на основе фраз-кандидатов. Наконец, пользовательский ввод обрабатывается в режиме реального времени, а база знаний, хранящаяся в ES, обрабатывается пакетами.

правило

Правила представляют собой чисто английские символы с удаленными цифрами. В основном название бренда и номер версии.

Вычислительная интенсивность WMD относительно велика.Если мы можем удалить некоторые неважные слова из входных слов, вычислительная интенсивность WMD может быть уменьшена.

В некоторых наших базах знаний это выражено иначе. Однако изменение выражения важных слов может повысить точность.

решение

В настоящее время наше решение использует Python NLTK для анализа и фильтрации, вывода части речи каждого слова, а ES сохраняет результат.

Что мы рекомендуем больше, так это использовать комплексное решение для анализа, фильтрации и хранения ES, но для этого решения необходимо написать подключаемый модуль Pos для ES.

Производительность: реализации Java обычно быстрее, чем реализации чистого Python, особенно при сравнении ресурсов ЦП.

Простота: логику не нужно поддерживать как на ES, так и на Python.

Экономия места: файлы моделей NLTK также относительно велики, а несколько образов Docker означают, что они занимают несколько дисков и памяти.

Оптимизация: синонимы

Искусственно определить синонимы сложно, мы генерируем «синонимы» на основе Word2vec.

Наша схема синонимов — переписывание запросов через синонимы.

На основе переупорядочивания машинного обучения модель переупорядочивается в соответствии с прогнозируемой вероятностью клика.

Вот и все на сегодняшнем обмене, спасибо всем!