Azure Qna Maker多种语言

Question

我正在Microsoft Azure环境中开发一个机器人，它可以用四种语言回答问题。整个方案如下:用户的输入被提交到Azure TextAnalytics，并使用推导出的语言来路由他们-在认知服务(LUIS和QnA Maker)的帮助下-到知识库(以他们的语言)，给他们他们的问题的答案。

Qna Maker通过Azure搜索服务管理KBs的数据。但是，一旦将一个知识库分配给一个知识库，就会在后者中创建一个索引(kbId)，它定义了-我假设-将由该搜索服务管理的所有知识库的语言。

资源的冗余和最重要的成本变得越来越愚蠢:需要为每种语言创建一个QnA Maker；即为每种语言并行创建1个QnA认知服务、1个应用程序服务、1个搜索服务(以及可选的1个应用程序洞察)，这是荒谬的。当然，Azure中的替代方案肯定存在。但是我发现很难找到它们，因为kbId索引是唯一的，它只接受一种语言，并且一旦创建就不能更新。

我真的很想知道其他人是否遇到过这样的问题。如果存在解决方案而不是昂贵的复制所有东西的解决方案-或者如果我可能遗漏了Azure QnA Maker中的一些东西……

非常感谢你的帮助！

Answer 1

Microsoft提供的文档中有一篇关于此主题的很好的文章。

上面写着：

QnA Maker支持多种语言的知识库内容。但是，每个QnA Maker服务都应该为一种语言保留。针对特定QnA Maker服务创建的第一个知识库设置该服务的语言。有关支持的语言列表，请参阅此处。

从所提取的数据源的内容中自动识别该语言。一旦创建了新的QnA Maker服务和该服务中的新知识库，就可以验证语言设置是否正确。

所以我很抱歉，但是，当你说以下话时，你是对的：

，但一旦将一个知识库分配给一个知识库，就会在后者中创建一个索引(kbId)，它定义了-我假设-将由该搜索服务管理的所有知识库的语言。

你必须在=>中创建几个QnA Maker服务，每种语言一个。

链接：https://docs.microsoft.com/en-us/azure/cognitive-services/QnAMaker/how-to/language-knowledge-base

注意:此链接还提供了一种检查搜索服务的检测语言的方法

Answer 2

QnA maker确实只支持您选择的一种语言来创建知识库。

但是可以创建一个支持多种语言的聊天机器人。我们需要使用Azure文本翻译服务。因此，步骤如下：

1. 用户使用X语言与机器人聊天。
2. 使用翻译服务来检测X的语言。
3. 如果X是英语，则调用QnA maker。
4. 如果X不是英语，请使用translate bot QnA将文本翻译为英语，获得应答，将应答转换回X语言并发送给用户。

请使用以下有用的链接来实现这一点：

https://desflanagan.ie/2016/10/25/build-a-multi-language-bot/

https://docs.microsoft.com/en-us/azure/cognitive-services/translator/reference/v3-0-reference

Answer 3

在为三种不同的语言实现QnA时，我面临着完全相同的挑战。

在文档中有一个更明确的提到，它说：

语言分析器一旦设置，将无法更改。此外，语言分析器适用于QnA Maker服务中的所有知识库。如果您计划拥有不同语言的知识库，则应在单独的QnA Maker服务下创建它们。

来源：https://docs.microsoft.com/en-us/azure/cognitive-services/QnAMaker/overview/languages-supported

我还担心为每个QnA提供专用实例的成本。这就是我寻找解决方案的原因。

QnA Maker的大部分成本来自以下事实，即每个实例都有自己的应用服务计划，并且azure门户不允许您将新实例指向现有的应用服务计划。但是，您可以通过ARM模板执行此操作。

这里是我的方法：

1. 创建一个新的资源组
2. 在该资源组中创建一个新的应用程序服务计划(SKU: S1 as recommended)
3. Deploy my ARM template
4. that resource group )(请参见deploy.ps1)。对每个参数文件(例如，3种不同的语言)执行一次此操作，并将每个文件指向在步骤2中创建的相同应用服务计划(请参阅参数appServicePlanName)。

步骤1和2也可以通过创建您的第一个QnA Maker实例来归档，这将创建一个新的资源组和应用程序服务计划，您可以在步骤3中指向它。

在我的示例场景中，这将导致3个不同的QnA Maker实例运行在相同的应用服务计划上，从而节省了由于当前服务版本的限制而强制执行的大部分成本，至少从UI的角度来看是这样。

免责声明：我不明白为什么微软在UI中阻止了这个场景，所以我的解决方案可能因为某些原因而不受支持。IMHO >如果API让我来做，它应该被支持。

奖励：还有一个参数文件用于使用免费的层(每个租户只有一个)，您可以将其用于测试目的。在这里，我混合了我的知识库，没有考虑语言问题，因为它只是为了快速和肮脏的测试。

如果你在使用我的样品时遇到问题，请告诉我。