我正在Microsoft Azure环境中开发一个机器人，它能够用四种语言回答问题。总体方案如下：用户的输入被提交到Azure TextAnalytics，在认知服务(LUIS和QnA Maker)的帮助下，使用推导出的语言将他们发送到知识库(用他们的语言)，为他们提供问题的答案。
Qna Maker通过Azure搜索服务管理KBs的数据。但是，一旦一个KB被分配给一个，就会在后者中创建一个索引(kbId)，该索引定义了将由该搜索服务管理的所有KB的语言。
资源的冗余和最重要的成本变得非常愚蠢：需要为每种语言创建一个QnA Maker；即为每种语言并行提供1个QnA认知服务、1个应用程序服务、1项搜索服务(以及可选的1项应用程序见解)是荒谬的。Azure中肯定存在替代方案。但我发现很难找到它们，因为kbId索引是唯一的，它只接受一种语言，并且一旦创建就无法更新。
我真的很想知道其他人是否遇到过这样的问题。如果存在解决方案，而不是昂贵的复制所有内容的解决方案，或者如果我可能错过了Azure QnA Maker的一些东西。。。
非常感谢你的帮助！
的确，QnA maker只支持您选择的一种语言来创建知识库。
但创建一个支持多种语言的聊天机器人是可能的。我们需要使用Azure文本翻译服务。因此，步骤是：
- 用户使用X语言与机器人聊天
- 使用翻译服务来检测X的语言
- 如果X是英语，请致电QnA制造商
- 如果X不是英语，请使用翻译服务将文本翻译成英语
- 调用QnA，获取答案，将答案转换回X语言并发送给用户
请使用以下有用的链接来实现这一点：
https://desflanagan.ie/2016/10/25/build-a-multi-language-bot/
https://learn.microsoft.com/en-us/azure/cognitive-services/translator/reference/v3-0-reference
微软提供的文档中有一篇关于这个主题的好文章。
上面写着：
QnAMaker支持多种语言的知识库内容。然而每个QnA Maker服务都应该为一种语言保留。这个针对特定QnA Maker服务创建的第一个知识库设置该服务的语言。请参阅此处以获取支持的列表语言。
根据数据内容自动识别语言正在提取的源。一旦您创建了一个新的QnA Maker Service和该服务中的新知识库，您可以验证该语言已正确设置。
所以我很抱歉，但是的，你说的是对的：
但一旦将KB分配给某个KB，就会创建索引(kbId)后者定义了——我想——所有知识库的语言将由该搜索服务管理。
>您必须在Azure中创建多个QnA Maker Service，每种语言一个。
链接：https://learn.microsoft.com/en-us/azure/cognitive-services/QnAMaker/how-to/language-knowledge-base
注意：此链接还提供了一种检查搜索服务检测到的语言的方法
在为三种不同的语言实现QnA时，我面临着完全相同的挑战。
文件中更明确地提到：
语言分析器一旦设置，就无法更改。此外，语言分析器适用于QnAMaker服务中的所有知识库。如果你计划拥有不同语言的知识库，你应该在单独的QnA Maker服务下创建它们。
来源：https://learn.microsoft.com/en-us/azure/cognitive-services/QnAMaker/overview/languages-supported
我还担心为每个QnA提供专用实例的成本。这就是我寻找解决方案的原因。
QnA Maker的大部分成本来自于这样一个事实，即每个实例下面都有自己的应用程序服务计划，而azure门户不允许您将新实例指向现有的应用服务计划。但是，您可以通过ARM模板来完成此操作。
这是我的方法：
- 创建一个新的资源组
- 在该资源组中创建新的应用程序服务计划(SKU:S1，推荐)
- 针对该资源组部署我的ARM模板(请参阅Deploy.ps1)。对每个参数文件(例如3种不同的语言)执行一次此操作，并将每个文件指向步骤2中创建的同一应用程序服务计划(请参阅参数appServicePlanName)
步骤1&2也可以通过简单地创建您的第一个QnA Maker实例来存档，该实例创建了一个新的资源组和应用程序服务计划，您可以在步骤3中指向它。
在我的示例场景中，这导致3个不同的QnA Maker实例在同一应用程序服务计划上运行，至少从UI的角度来看，节省了当前服务版本限制所带来的大部分成本。
免责声明：我不明白为什么微软会从UI中阻止这种情况，所以我的解决方案可能由于某种原因而不受支持。IMHO>如果API让我来做，它应该得到支持。
奖金：还有一个用于使用免费层的参数文件(每个租户只有一个)，您可以用于测试目的。在这里，我混合了我的知识库，不考虑语言问题，因为它只是为了快速而肮脏的测试。
如果你在使用我的样品时遇到问题，请告诉我。
我遇到了同样的问题，正如前面的答案所描述的那样，确认了这个限制。将多个知识库分配给同一Azure服务时，链接的Azure搜索服务中的Analyzer设置将取自新索引的第一个知识库。我看不出有什么变通办法。
主要问题是Azure搜索服务——每个租户只允许一个"免费"SKU，因此这强制要求每种语言都有一个付费实例。在我的环境中，这是一个关键问题，在许多情况下都无法解决(例如，通常您希望有单独的实例用于测试和生产)。
从技术角度来看，我不清楚为什么存在这种限制。每个知识库都有一个独立的索引，您可以随时向QnA Maker服务查询特定的知识库。因此，应该可以在Azure服务中定义每个索引的Analyzer配置。我为此创建了一个功能请求：https://feedback.azure.com/forums/34192--general-feedback/suggestions/38372725-qna-maker-support-knowledge-bases-for-different-l.请随意投票支持。
我不知道你是否找到了解决方案，但我所做的是创建一个新的QnA创客服务，并将该网络应用程序与另一个QnA众客服务计划合并，由于文档数量将被拆分，我可以将QnA认知应用程序的定价级别更改为免费，为了搜索，我建议保留搜索服务，根据微软的回复如下：
要使用多种语言和多种知识库，用户必须为每种语言创建一个QnA Maker资源。这将创建每个语言单独的Azure搜索服务。混合不同的语言单个Azure搜索服务中的知识库将导致结果相关性降低。
总之，定价是现收现付，所以现在额外的部分将是文档数量和10美元。