Часто задаваемые вопросы по сопоставлению с RASA для большого набора данных (2000+)

Question

RASA состоит из RASA NLU + Core, я тестировал вокруг, я понимаю некоторую часть об этом. Я пытаюсь применить его на практике, и он работает идеально.

Я планирую вывести его на следующий уровень, я хочу создать систему часто задаваемых вопросов на основе стека RASA с помощью бэкэнда tenensflow.

Я получил более 1200+ пару вопросов и ответов. Во-первых, NLU будет играть роль, чтобы понять и классифицировать намерение наряду с извлечением объекта. Во-вторых, он передает ответ json ядру RASA, где ответы будут отображаться или отвечать пользователям. Это звучит просто, но когда я иду и проверяю RASA, это дает что-то другое. Обычно ядро ​​RASA отвечает пользователю обратно на основе предопределенной истории вместе с ==> "utter_". Предопределенная история хороша, но только для небольшого количества наборов данных. мы должны написать это вручную.

Как действовать, когда набор данных или основанный на знаниях становится все больше, например 1000+ или 5000+, мы не можем сопоставить его вручную. Я пытаюсь осмотреться, но пока не могу найти подходящий способ с этим справиться.

Ранее я использовал [Retrieval Model] Sklean Tfidf-vectorizer в качестве набора слов вместе с consine-similairy, чтобы сравнивать и возвращать наиболее похожий индекс вопроса, когда индекс найден. Ответ будет выбираться на основе индекса, но решение такого типа неэффективно. так как смысл будет потерян и намного больше проблем.

Кто-нибудь получил такое хорошее решение для этого?

Спасибо

Answer 1

Во-первых, я хочу уточнить для фактической архитектуры:

1. Пользователь отправляет свои сообщения в чатбот
2. Rasa Core получает эти сообщения и передает их в RLA Rasa, который распознает намерения (понимает цель пользователя) и извлекает объекты из входных данных.
3. Основываясь на признанном намерении, сущностях и истории разговора, Rasa Core предсказывает следующее действие бота

В вашем случае (часто задаваемые вопросы, много вопросов) вы можете попробовать следующее, что приведет к относительно простым историям:

## User asks for price
* ask_location{"place": "a entity which is extracted by NLU}
  - action_utter_place

# User asks for location
* ask_price{"item": "a entity which is extracted by NLU}
  - action_utter_price

[...]

Конечно, я бы добавил немного больше путей, например, если пользователь недоволен ответом, или пользователь пытается поговорить с вами и т. Д.

На следующем шаге я предоставлю все возможные вопросы в ваших данных обучения NLU и извлеку различные объекты, в зависимости от того, о чем идет речь. Например:

## intent:ask_location
- Where is the [cinema](place)
- How do I get to the next [supermarket](place)
- What's the closest [doctor](place)

## intent:ask_price
- How much is it
- What does it cost
- How much is a [ticket](item) for the [cinema](place)

Таким образом, я бы не делал одно намерение для каждого вопроса, а скорее сгруппировал несколько вопросов в одном намерении, а затем выделил сущность, которая сужает его до конкретного вопроса.

Затем вы можете использовать CMS для генерации ответов или пользовательских действий. Основываясь на извлеченных объектах (например, месте и позиции), вы можете запросить базу данных и сгенерировать ответ.

Answer 2

Я не совсем понимаю, что вы имеете в виду, говоря *but this kind of solution is not effective since the meaning will lost and much more problem.*. Для однооборотных вопросов / ответов официальный метод Rasa будет использовать действия по извлечению, как вы предложили. Нам это показалось немного громоздким, и мы реализовали простой классификатор поверх встраиваний универсального кодировщика.

т.е. у бота есть ask_faqнамерение, под которым сгруппированы все ~1000 однооборотных вопросов. Все это сопоставлено с действием action_answer_faq. В действии вторичный классификатор, который мы создали специально для этих ~1000 вопросов, будет использоваться для определения правильного идентификатора ответа. Внутренняя база данных будет содержать текст ответа (который может изменяться по желанию бизнес-пользователя, не требуя изменения модели) .