[Adaptive] Setting and managing recognizers for adaptive dialogs

Today, we support a variety of recognizer types that work with adaptive dialog. Composer provides UX for a limited set of recognizer types but there is a need for us to have a scalable design to onboard custom/ new recognizer types in both composer as well as in adaptive dialogs.

Requirements:

• Ability for a recognizer type to register to handle technology specific workflows as part of build/ publishing steps in composer.
• Ability to render a scalable UX in composer for the recognizer tied to an adaptive dialog including form UX to edit the properties for a recognizer selection.
• Simplify and streamline the myriad of possible recognizer configurations that are possible today.

Proposal:

1. A dialog will always have only one top level recognizer. It can either be a RecognizerSet or one of the available recognizer types.
2. In composer, for build/ publishing step, providers can register call backs with their $kind.

Implications:

• Proposal #1 means that we will author a new LuisQnACrossTrainedRecognizer that holds LUIS and QnA Maker recognizer configuration as properties on it.

	{
		"recognizer": {
			"$kind": "Microsoft.LuisQnACrossTrainedRecognizer",
			"qnaRecognizer": "dialogName.qna",
			"luisRecognizer": "dialogName.lu"
		}
	}

• You can never pick and choose separate recognizer for LU/ QnA. you are always taking both together. If a custom recognizer provides for only one of the functionality (e.g. Orchestrator with intent classification only) then the provider of that recognizer must register a recognizer type that works for both LU and QnA content and choose appropriate defaults/ customization for specific functionality that is not supported within that recognizer type.
• In composer, we will move the current LUIS, QnA Maker functionality into respective build/ publish call backs tied to Microsoft.LUISAdaptiveRecognizer and Microsoft.QnAMakerRecognizer etc.
  • For build/ publishing the library could get called with both ‘raw’ content as well as ‘cross-trained’ content for that dialog.
• The recognizer configuration provided by the build step is inlined in the .dialog file. prior to the build step, just the $kind is serialized inline.

      {
          "recognizer": {
              "$kind": "Microsoft.LuisQnACrossTrainedRecognizer"
          }
      }
  

• The ability to provide multi-lingual support and management need to be exposed as properties by the top level recognizer. E.g. LuisQnACrossTrainedRecognizer should internally use and abstract away the MultiLanguageRecognizer implementation.
• The proposal also means composer will expose the following top level recognizers (apart from any custom recognizers added by the user)
  • Regex Recognizer
  • Default Recognizer (LuisQnACrossTrainedRecognizer)
  • Any custom recognizer registered by the user.

New work (SDK):

• LuisQnACrossTrainedRecognizer
• OrchestratorCrossTrainedRecoginzer
• [Open] Do we need a multi-lingual RegexRecognizer and switch composer to using that instead?

@tomlm @chrimc62 @cwhitten @boydc2014 @taicchoumsft

[chrimc62]

I would suggest.

1. We are explicit in the recognizer structure we create, i.e. an explicit recognizer $kind everywhere we need recognizer.
2. We add an optional source attribute to each recognizer that points to the .lu file it consumes.
3. Build process is associated with the $kind. This would mean Composer can deal with any recognizer structure and customizing it. Today it is very confusing because you have to know of the magical connection from .lu reference to a generated recognizer.

[boydc2014]

Close this since it’s not in the plan