聊天机器人和 Rasa 2.0 的新增功能

聊天机器人和 Rasa 2.0 的新增功能

文章翻译自：Chatbots and What’s New in Rasa 2.0

图片由作者提供。 Rasa开源图标取自 Rasa Github.

Rasa开源是一种机器学习框架，用于构建基于文本和语音的聊天机器人。最近，其背后的团队成功地取得了显着的里程碑，并于 2020 年 10 月发布了他们的第一个正式版本 2.0。新版本旨在统一训练数据格式，配置文件和模型处理方式。因此，与以前的版本相比，存在许多重大更改。

在本教程中，我们将深入探讨 Rasa 1.10 与最新版本的候选版本之间的一些主要区别。在执行旧 Rasa 服务器的迁移之前，你应该先检查一下并确定是否值得努力。

文件夹和文件层次结构

文件夹和文件的结构与上一版本大致相似，但以下情况除外：

• actions.py 不再位于根目录下
• 有一个新的文件夹叫做 actions， actions.py 位于这个文件夹下
• 在 data 文件夹下有一个额外的文件叫 rules.yml

配置

config.yml

现在，版本 2.0 附带了管道和策略的默认配置。对于新用户而言，这更加方便。话虽如此，你仍然可以自定义它，并且格式与以前的版本完全相同。

Pipeline

现在，大多数内置的 tokenizers 已经标准化，具有以下特性：

• intent_tokenization_flag — 标记以检查是否切分意图
• intent_split_symbol — 意图分割符号
• token_pattern — 用于检测 token 的正则表达式

这些键用于多目标分类。目前，它仅与 DIETClassifier 一起使用。

看一下 WhiteSpaceTokenizer 的以下代码片段：

pipeline:
- name: "WhitespaceTokenizer"
  "intent_tokenization_flag": False
  "intent_split_symbol": "_"
  "token_pattern": None

此外，属性 case_sensitive(用于区分大小写) 已从 tokenizers 移至 featurizers。除非使用以下组件，否则可以放心地忽略此属性：

• KeywordIntentClassifier
• SpacyNLP
• RegexFeaturizer

Policies

新增了一个称为 RulePolicy 的新策略。对于始终具有固定行为的对话非常有用。它与故事略有不同，应与故事一起使用以提高性能。你需要在 config.yml 中具有 RulePolicy 才能使用规则和表单。在实现以下功能时，它非常有用：

• 单轮交互，例如 FAQs
• 后备行为
• 处理表单中的不良行为

此外，不推荐使用以下策略以支持 RulePolicy。你仍然可以使用 RulePolicy 及其各自的 `classifiers’ 实现相同的功能。

• Mapping policy
• Fallback policy
• Two-stage fallback policy
• Form policy

Importers

默认情况下，Rasa 使用 RasaFileImporter。现在，你可以创建自己的数据解析器，以其他格式加载训练数据。如果你的训练数据来自其他资源，这将很有用。

此外，还有一个名为 MultiProjectImporter 的实验功能，可以将来自多个 Rasa 项目的数据集合并为一个。例如，你可以将项目模块化为以下子项目：

• restaurant bot
• room booking bot
• chitchat bot

并在以后将它们组合在一起，以创建一个完整的聊天机器人。

Domain

domain.yml

domain.yml 的数据结构保持不变，只不过你需要在其顶部指定版本。你需要为所有训练数据文件指定此名称。如果省略，默认情况下 Rasa 会将其读取为 2.0 版。

version: "2.0"
intents:
  - greet
  - goodbye
  - affirm
  - deny
  - mood_great
  - mood_unhappy
  - bot_challenge

Training Data Format

2.0 版中的重大突破之一是训练数据格式。

NLU

对于 NLU 训练数据，版本 2.0 的新结构如下：

version: "2.0"
nlu:
- intent: greet
  examples: |
    - Hey
    - Hi
    - hello
- intent: goodbye
  examples: |
    - Goodbye
    - bye bye

NLU metadata

实际上，你现在可以声明其他包含任意键值对的 metadata。你可以通过自定义组件访问 metadata。例如，你可以声明如下：

nlu:
- intent: greet
  metadata:
    sentiment: neutral
  examples:
  - text: |
      hi
  - text: |
      hello

在上面给出的示例中，metadata 是在意图级别声明的。结果，所有示例都包含 metadata。你可以为每个示例分别声明 metadata。

nlu:
- intent: greet
  examples:
  - text: |
      hi
    metadata:
      sentiment: neutral
  - text: |
      hello

检索意图（Retrieval intents）

在旧版本中，检索意图是一种实验性功能，其中可以将意图分类为较小的子意图。在进行闲聊时，这很有帮助，因为它减少了故事的开销。你需要使用 / 符号来分隔主要意图及其子意图。请看下面的示例，其中包含两个子意图的 chitchat 意图：

• ask_name
• ask_weather

nlu:
- intent: chitchat/ask_name
  examples: |
    - What is your name?
    - May I know your name?
- intent: chitchat/ask_weather
  examples: |
    - What is the weather?
    - May I know the current weather outside?

与正常意图不同，answers 必须放置在 responses.yml 中而不是 domain.yml 中。该文件应位于 data 文件夹下，格式与 domain.yml 完全相同。这意味着你可以具有多个变体并指定不同的有效 payloads。

responses:
  utter_chitchat/ask_name:
    - text: "I don't have a name!"
  utter_chitchat/ask_weather:
    - text: "It is sunny"
    - text: "It is raining heavily outside"

实体（Entities）

实体的格式以及实验角色和组标签仍与以前的版本相同。如果你不了解，则可以使用角色和组标签来区分同一实体中的某些概念。考虑以下示例：

Book me a flight from [Malaysia]{"entity": "country"} to [Singapore]{"entity": "country"}.

从人的角度来看，即使两个实体都指国家，我们都知道第一个 entity 指出发，而第二个 entity 指目的地。我们可以使用以下实验功能为其添加标签：

Book me a flight from [Malaysia]{"entity": "country", "role": "departure"} to [Singapore]{"entity": "country", "role": "destination"}.

你需要提供足够的数据才能对其进行概括。在这种情况下，你应具有以下条件：

... from Malaysia to Singapore ...
... from Singapore to Malaysia ...

同义词（Synonyms）

声明同义词的方式与处理 NLU 数据相同，方法是将 intent 替换为 synonym。看下面的例子：

nlu:
# greet & goodbye intent
- synonym: credit
  examples: |
    - credit card account
    - credit account

正则（Regex）

同样，你可以使用相同的样式通过正则表达式捕获实体。下面的示例说明了一个正则表达式，用于精确捕获五位邮政编码。

nlu:
# greet & goodbye intent
- regex: zipcode
  examples: |
    - \b\d{5}\b

查找表（Lookup tables）

至于查找表，你应将它们编写如下：

nlu:
- lookup: fruits
  examples: |
    - apple
    - banana
    - papaya
    - watermelon

确保查找表中的数据干净，以防止出现不良行为。

故事（Stories）

你可以将故事和 NLU 合并为一个文件，但是强烈建议将它们分开。与旧版本相比，新格式更加冗长，但确实有助于区分意图和动作。结果，在构建故事时，你不太可能犯不必要的错误。

version: "2.0"
stories:
 - story: happy path
   steps:
   - intent: greet
   - action: utter_greet
   - intent: goodbye
   - action: utter_bye

与 NLU 类似，你可以在故事内部定义 metadata 来存储与故事相关的相关信息。metadata 不会用于训练，也不会影响你故事的表现。

stories:
 - story: happy path
   metadata:
     author: wfng
     key: value
   steps:
   - intent: greet
   - action: utter_greet
   - intent: goodbye
   - action: utter_bye

对于检索响应，它应该以 utter_ 开头，而不是旧的 respond_ 前缀。

stories:
 - story: story with a retrieval action
   steps:
   - intent: chitchat
   - action: utter_chitchat

表单（Forms）

现在，表单已成为训练数据的一部分，而不是 Rasa SDK。表单需要 RulePolicy，默认情况下已在配置中。首先，你应该按以下方式定义它：

forms:
  your_form:
    age:
    - type: from_entity
      entity: age

然后，你可以指定 action 和 active_loop 字段，Rasa 将在这些字段中循环并调用 utter_ask_{form_name}_{slot_name} 或 utter_ask_{slot_name}，直到实体 age 被填充为止。你需要在 responses 中定义它们。

stories:
 - story: form asking for age
   steps:
   - intent: intent_ask_age
   - action: your_form
   - active_loop: your_form

检查点（Checkpoints）和 OR 语句

你仍然可以同时使用检查点和 OR 语句。但是，强烈建议不要使用这些功能，因为过度使用它们会对训练时间产生很大影响。

规则（Rules）

规则描述了对话的一小部分，始终具有固定的路径。你可以将其视为单轮交互，其中将返回相同的答案。与故事不同，规则不会一概而论，主要用于回答常见问题（FAQs）。这类似于 Rasa 1.0 在 domain.yml 中通过 MappingPolicy 使用 trigger。假设机器人在用户打招呼时都应该始终以 utter_greet 回应。你可以使用以下规则轻松定义它：

rules:
 - rule: Say `hello` whenever users greet the bot
   steps:
   - intent: greet
   - action: utter_greet

此外，你可以在规则内指定以下键：

• conversation_started
• condition

通过将 conversation_started 键设置为 true，此规则在会话开始时只会触发一次。在这种情况下，bot 在稍后的对话中不会以 utter_greet 响应。

rules:
 - rule: Say `hello` when users greet the bot at the beginning
   conversation_start: true
   steps:
   - intent: greet
   - action: utter_greet

你可以根据条件是否已填充插槽或是否存在 active_loop 事件，使用 condition 约束规则。

rules:
 - rule: Say `hello` whenever users greet the bot and slot was set
   condition:
   - slot_was_set:
     - user_provided_name: true
   steps:
   - intent: greet
   - action: utter_greet

规则到达最后一步后，默认行为是等待用户输入。你可以通过将 wait_for_user_input 键设置为 false 来修改此功能。

rules:
 - rule: Rule which will not wait for user input
   steps:
   - intent: greet
   - action: utter_greet
   wait_for_user_input: false

测试

作为参考，你可以编写测试对话以测试聊天机器人的性能。旧版本的 Rasa 中已提供此功能。 2.0 版的测试故事应编写如下：

stories:
- story: happy path 1
  steps:
  - user: |
      hello there
    intent: greet
  - action: utter_greet
  - user: |
      see you later
    intent: goodbye
  - action: utter_bye

结论

让我们回顾一下我们今天学到的东西。我们首先介绍了 Rasa Open Source 2.0。在新版本中，文件夹结构和配置文件大致相同，只是做了一些小的更改。不推荐使用某些政策以支持“ RulesPolicy。然后我们继续研究 Rasa 1.10 和 2.0 之间的重要区别，这是训练数据格式。我们深入探讨了 NLU，故事，规则等的新数据格式。到目前为止，你应该对即将发布的Rasa 2.0 稳定发行版中的未来有一个简要的了解。感谢你阅读本文。希望在下一篇文章中再见！

参考资料

1. What’s Ahead in Rasa OpenSource 2.0
2. Rasa Documentation