Transformer课程 业务对话机器人Rasa 3.x Testing Your Assistant（二）
Transformer课程 业务对话机器人Rasa 3.x Testing Your Assistant（二）
Rasa官网
Comparing NLU Performance
如果您对NLU训练数据进行了重大更改（例如，将一个意图拆分为两个意图或添加了大量训练示例），则应运行完整的NLU评估。您需要比较NLU模型的性能，而不需要对NLU模型进行更改。
您可以通过在交叉验证模式下运行NLU测试来实现这一点：
rasa test nlu --cross-validation
您还可以在训练集上训练模型并在测试集上进行测试。如果您使用训练测试集方法，最好使用rasa数据分割来洗牌和分割数据，而不是使用静态NLU测试集，后者很容易过时。
您可以在rasa测试的命令行文档中找到选项的完整列表。
要进一步改进模型，请查看此超参数优化教程。
Comparing NLU Pipelines
为了最大限度地利用训练数据，您应该在不同的管道和不同数量的训练数据上训练和评估您的模型。
为此，请将多个配置文件传递给rasa test命令：
rasa test nlu --nlu data/nlu.yml
--config config_1.yml config_2.yml
这将执行几个步骤：
从data/nlu.yml创建一个80%训练集 20%测试集。
从全局训练集中划分出一定百分比的数据。
根据剩余的训练数据，为每个配置提供训练模型。
在全局测试集中评估每个模型。
在步骤2中，使用不同百分比的训练数据重复上述过程，以了解如果增加训练数据量，每个管道将如何运行。由于训练不是完全确定的，因此针对每个指定配置，整个过程重复三次。
图中显示了所有训练中f1成绩的平均值和标准偏差。f1分数图以及所有训练/测试集、训练模型、分类和错误报告将保存到名为nlu_comparison_results的文件夹中。
检查f1分数图可以帮助您了解NLU模型是否有足够的数据。如果图表显示，当使用所有训练数据时，f1成绩仍在提高，则使用更多数据可能会进一步提高。但如果在使用所有训练数据的情况下，f1成绩保持稳定，添加更多数据可能没有帮助。
如果要更改运行次数或排除百分比，可以：
rasa test nlu --nlu data/nlu.yml
--config config_1.yml config_2.yml
--runs 4 --percentages 0 25 50 70 90
Interpreting the Output
Intent Classifiers
rasa测试脚本将为您的意图分类模型生成一个报告（intent_report.json）、混淆矩阵（intent_conflusion_matrix.png）和置信度直方图（intent_histogram.png）。
该报告记录了每个意图的准确度、召回率和f1分数，并提供了总体平均值。您可以使用–report参数将这些报告保存为JSON文件。
混淆矩阵显示哪些意图被误认为其他意图。任何被错误预测的样本都会被记录并保存到名为errors的文件中 ，errors.json更易于调试。
直方图允许您可视化所有预测的置信度，正确预测和错误预测分别以蓝色和红色条显示。提高训练数据的质量将使蓝色直方图条在绘图中上移，红色直方图条在绘图中下移。它还应有助于减少红色直方图条本身的数量。
Response Selectors
rasa测试评估响应选择器的方式与评估意图分类器的方式相同，生成一个报告（response_selection_report.json）、混淆矩阵（response.selection.conflusion.matrix.png）、置信度直方图（response.selection.histogram.png）和错误（response.selection.errors.json）。如果管道包含多个响应选择器，则将在单个报告中对其进行评估。
该报告记录检索意图的每个子意图的精度、召回率和f1度量，并提供总体平均值。您可以使用–report参数将这些报告保存为JSON文件。
Entity Extraction#
rasa测试报告可训练实体提取器训练识别的每个实体类型的召回率、精度和f1分数。
只有可训练的实体提取器（如DIETClassifier和CRFEntityExtractor）通过rasa测试进行评估。未对DucklingHTTPExtractor等预训练提取器进行评估。
如果任何实体的注释不正确，则评估可能会失败。一个常见的问题是实体不能在标记内停止或启动。例如，如果您有一个名称实体的示例，如[Brian]（名称）的房子，则只有当您的标记器将Brian的房子拆分为多个标记时，此示例才有效。
Entity Scoring
为了评估实体提取，我们采用了一种简单的基于标记的方法。我们不完全考虑BILUO标签，而只考虑每个标记基础上的实体类型标签。对于“near Alexanderplatz”等位置实体，我们希望标签为LOC LOC，而不是基于BILOU的B-LOC L-LOC。
当涉及到评估时，我们的方法更加宽松，因为它奖励部分提取，而不惩罚实体的分割。例如，鉴于上述实体“near Alexanderplatz”和提取“Alexanderplatz”的系统，我们的方法奖励提取“Alexanderplatz”，并惩罚遗漏的单词“near”。
然而，基于BILOU的方法会将此标记为完全失败，因为它期望Alexanderplatz标记为实体（L-LOC）中的最后一个标记，而不是单个标记实体（U-LOC）。还要注意的是，“near”和“Alexanderplatz”的分离提取在我们的方法上会得到满分，而在基于BILOU的方法上会得到零分。
下面是对“near Alexanderplatz tonight”两种得分机制的比较：
Evaluating a Dialogue Model
通过使用测试脚本，您可以在一组测试故事上评估经过训练的对话模型：
rasa test core --stories test_stories.yml --out results
这将把所有失败的故事打印到results/failed_test_stories.yml中 。如果至少有一个动作预测错误，故事就会失败。
测试脚本还将把混淆矩阵保存到名为results/story_confmat.pdf的文件中。 对于域中的每个操作，混淆矩阵显示正确预测操作的频率以及预测错误操作的频率。
Interpreting the generated warnings
解释生成的警告#
测试脚本还将生成一个名为results/stories_with_warnings.yml文件，其中包含 action_unlikely_intent。该文件包含所有测试故事，在任何对话回合中都预测了其行动意图，但原始故事中的所有行动都预测正确。但是，如果一个测试故事最初包含一个不太可能的动作意图，例如，确保一个规则被设计为在一个不太可能的动作意图之后触发对话路径，但是策略集合没有这样做，那么相应的故事将以结果/失败的测试故事结束。results/failed_test_stories.yml是一个失败的故事。
这些故事是根据action_unlikely_intent 的预测来排序的。此严重性在预测时由 UnexpecTEDIntentPolicy意外终止策略本身计算。严重性越高，意图就越不可能，因此审查特定对话路径就变得越关键。
请注意，不太可能的行动意图是由“未预料到的”策略预测的，该策略在引擎盖下采用了基于机器学习的模型，因此也可能导致错误警告。如果训练故事中已经存在这些故事中的对话路径，则可以选择忽略这些警告。
Comparing Policy Configurations
要为对话模型选择配置，或为特定策略选择超参数，您需要衡量对话模型对以前从未见过的对话的概括程度。特别是在项目开始时，当您没有太多的真实对话来训练您的机器人时，您可能不想排除一些对话来用作测试集。
Rasa开源有一些脚本可以帮助您选择和微调策略配置。一旦您对它满意，您就可以在完整的数据集上训练您的最终配置。
要做到这一点，您首先必须针对不同的配置训练模型。创建两个（或更多）配置文件，包括要比较的策略，然后将它们提供给训练脚本以训练模型：
rasa train core -c config_1.yml config_2.yml \
--out comparison_models --runs 3 --percentages 0 5 25 50 70 95
与NLU模型的评估方法类似，上述命令在多种配置和不同数量的训练数据上训练对话模型。对于提供的每个配置文件，Rasa开源将训练对话模型，其中0、5、25、50、70和95%的训练故事不包含在训练数据中。重复三次，以确保结果一致。
此脚本完成后，您可以将多个模型传递给测试脚本，以比较刚刚训练的模型：
rasa test core -m comparison_models --stories stories_folder
--out comparison_results --evaluate-model-directory
这将评估stories_文件夹中的故事（可以是训练集或测试集）中的每个模型，并绘制一些图表，向您显示哪个策略执行得最好。由于之前的训练命令排除了一些训练数据来训练每个模型，因此上面的测试命令可以测量您的模型预测已完成故事的程度。要比较单个策略，请创建每个策略只包含一个策略的配置文件。
这个训练过程可能需要很长时间，所以我们建议让它在后台的某个地方运行，这样它就不会被打断。
Testing Action Code
用于测试动作代码的方法将取决于它的实现方式。例如，如果您连接到外部API，则应该编写集成测试，以确保这些API按照预期响应公共输入。无论您如何测试操作代码，都应该将这些测试包括在管道中，以便在每次进行更改时运行这些测试。
如果您有任何疑问或问题，请在我们论坛的专用测试部分与我们分享！
