在用于构建LUIS应用程序的v3 API中，我注意到对机器学习实体的强调。与他们一起工作时，我注意到一些令我担忧的事情，我希望对此事有更多的了解。
想法是，当使用机器学习实体时，您可以将其绑定到短语列表或其他实体或列表实体的描述符，作为对该机器学习实体的约束。为什么不仅仅旨在自己提取列表实体？将其包装在加工的学习对象中的目的是什么？
我问这个，是因为我在列表方面一直很成功。尽管您需要注意拼写错误和变化以确保准确性，但它是非常可控的。但是，当我使用机器学习的实体时，我注意到您在单词顺序方面必须格外小心。如果存在差异，则无法选择该机器学习的实体。
现在培训可以解决此问题，但实际上，如果我知道我有想要的意图，而我仅需要实体，机器学习的实体真正提供了什么？
似乎您需要对此更加小心。
现在，我对此表示怀疑。答案就在于这样的事实：它将增加实体检测，而列表实体只会起到增加实体检测的作用。如果那是最合适的答案，我想我可以看到我所寻找的解决方案。
[我们应该在这里澄清一下，至少在您撰写问题的方式上，尚不清楚。
LUIS具有两个separate功能：短语列表和列表实体，它们是非常不同的东西。
简单实体（机器学习的实体）之所以出色，是因为它可以解释变化，并从您添加到意图中以更好地检测实体的不同示例话语中“学习”。简单实体通常与短语列表结合使用，以增强可能被识别为该实体的信号。如果构建正确，它将能够正确提取单词作为您甚至没有放入LUIS模型的实体，因为它是从您输入的数据中学到的。短语列表使您可以帮助建模实体看起来像什么其他单词，而无需输入过多的言语。
列表实体，但是是封闭列表，并且是精确文本匹配项-即不会利用机器学习（例如，如果输入了错误的内容并输入了“加利福尼亚”，则列表实体将无法将其识别为打算成为“加利福尼亚”，并且不会将其标记为实体）。如果您已经知道所有可以输入的值以及这些单词可以作为同义词，则列表实体非常有用（例如，您的应用程序具有用户可以单击的按钮）。
参考此Stack Overflow answer with an example of how to use phrase lists。它还合并了有关如何构建LUIS应用程序以产生正确的实体检测的其他Stack Overflow答案。您也可以看看this Stack Overflow post where the user first started out using a list entity，但是他的LUIS应用仍然表现出他不想要的方式，最终，简单的实体+短语列表组合更适合该用户的情况。