在用于构建 LUIS 应用程序的 v3 api 中，我注意到机器学习实体的重点。与他们一起工作时，我注意到一些让我担心的事情，我希望能更深入地了解这个问题。
这个想法是，当使用机器学习实体时，您可以将其绑定到短语列表或其他实体或列表实体的描述符，作为对该机器学习实体的约束。为什么不只以自身提取列表实体为目标呢？将其包装在机器学习对象中的目的是什么？
我问这个是因为我在列表方面一直很成功。尽管您需要注意拼写错误和变化以确保准确性，但它非常可控。然而，当我使用机器学习实体时，我注意到你必须更加小心词序。如果存在变化，它就无法拾取该机器学习实体。
现在培训可以解决这个问题，但实际上，如果我知道我有我想要的意图并且我只需要其中的实体，机器学习实体到底提供了什么？
看来您需要更加小心。
现在我带着这种怀疑说这话。答案是否在于机器学习实体会增加意图检测，而列表实体只会增加实体检测。如果这是最适合的答案，我想我可以看到我正在寻找的解决方案。
已编辑：自从我休产假以来，我一直没有跟上 LUIS，你瞧，它正在从 V2 转移到 V3！
下面显示了来自 LUIS 团队文档作者的电子邮件对话。
LUIS 正在从不同类型的实体转向单个 ML 实体来封装一个概念。ML 实体可以有子实体，它们本身就是 ML 实体。一个 ML 实体可以有一个直接连接到它的特征，而不是作为一个全局特征。
此功能可以是短语列表，也可以是其他模型，例如预构建实体、reg ex 实体或列表实体。
因此，一年前，客户可能已经构建了一个复合实体并将功能投入到应用程序中。现在他们应该创建一个带有孩子的 ML 实体，并且这些孩子应该有特征。
现在（在//MS Build Conference 之前）任何非短语列表功能都可以成为约束（必需），因此具有受约束的正则表达式实体的子实体在正则表达式匹配之前不会触发。
在//Build 之后，这个概念在 UI 中被重新设计为一个必需的特性——相同的想法但不同的术语。
...
这是关于理解一个包含部分的整体概念，所以地址是一个典型的例子。地址有街道号码、街道名称、街道类型（街道/法院/大道）、城市、州/省、国家/地区、邮政编码。
每个子部分都是一个特征（强有力的指标），地址在话语中。
如果您使用列表实体但不是地址的必需功能，是的，它会触发，但这无助于您真正想要获得的地址实体。
但是，如果您真的只想匹配一个列表，那就去吧。但是当客户说应用程序没有像他们想象的那样预测时，团队将回到 ML 实体父级及其部分的概念，并建议对实体进行更改。