Support other recipes - starting with graph

[tayfun]

What problem are you trying to solve?

Currently we only have a single recipe type called default.v1 which fits most cases but falls short of advanced configuration. For research teams and other users who want customised recipes, we want to add a feature to modularly load different types of recipes.

This will be released with a minor version (merge to main branch), ie. released as a 3.x version.

What's your suggested solution?

For the minimum viable product, we want to support graph schemas so research can specify graph components/nodes as they like.

1. Move TrainingType into engine/recipes/recipe.py. This file has base recipe class and other classes common to other recipes.
2. Move everything else in the file shared/importers/autoconfig.py to default recipe at engine/recipes/default_recipe.py. Default recipe itself will know how to validate the recipe and correct it (dumping missing keys etc.) and every new recipe from now on too will hold that information - high cohesion, low coupling.
3. Change RasaFileImporter.get_config so that it instantiates correct recipe, ie.

def get_model_config(self, cli_par, training_type=training_type, is_finetuning=is_finetuning):
  # TODO: Need to read yaml config as dict here to be able to get recipe name, ie. default, graph etc
  config = ... # read yaml file as dict
  recipe = Recipe.recipe_for_name(config.get("recipe"))
  model_config = recipe.graph_config_for_recipe(
    config, kwargs, training_type=training_type, is_finetuning=is_finetuning
  )
  return model_config

4. Change model_training._train_graph so it can get model config directly:

model_config = file_importer.get_model_config(kwargs, training_type, is_finetuning)

5. Add new recipe option graph.v1 by adding new module engine.recipes.graph_recipe and in it class GraphV1Recipe. Add this class to the options recipesin Recipe.recipe_for_name method.

6. For the new GraphV1Recipe , don't worry about validation or dumping default values etc. as this is an experimental and advanced feature which will evolve over time. We can add validation in a later step; default policies or pipeline components are not needed because we want more control over the graph with this recipe. Mark as experimental so users know this feature can change.

7. GraphV1Recipe will read a single file which has graph schema defined and can be directly used (no need to transform into usable format like in the default recipe). File is simply:

recipe: graph.v1

language: en

train_schema:
  nodes:
    train_RegexFeaturizer1:
      needs:
        training_data: run_WhitespaceTokenizer0
      uses: rasa.nlu.featurizers.sparse_featurizer.regex_featurizer.RegexFeaturizer
      constructor_name: create
      fn: train
      ...

  ...

predict_schema:
  nodes:
    run_RegexFeaturizer1:
      needs:
        messages: run_WhitespaceTokenizer0
      uses: rasa.nlu.featurizers.sparse_featurizer.regex_featurizer.RegexFeaturizer
      constructor_name: load
      fn: process
      ...

Note we have language and recipe at the top and we have divided train and predict schema nodes.

In GraphV1Recipe class, simply load train and predict schemas from the recipe; nothing else is needed. Change graph_config_for_recipe so that it returns:

return GraphModelConfiguration(
      train_schema=GraphSchema.from_dict(train_schema_dict),
      predict_schema=GraphSchema.from_dict(predict_schema_dict),
      training_type=training_type,
      language=config.get("language"),
      core_target=core_target,
      nlu_target=f"run_{RegexMessageHandler.__name__}",
  )

Attributes other than train/predict schema can be shared between default and graph recipe, ie. training_type, language, core and nlu targets are used similarly in both recipes. For schemas, current default recipe will continue processing it while the new graph schema will use GraphSchema.from_dict to directly use what's in the graph schema file.

8. Add tests so make sure graph recipes work as expected.
9. Add documentation to describe how new graph schemas can be specified with examples.
10. No need to support CLI parameters, one can set those in the graph schema provided, so add a warning saying CLI parameters will be ignored when graph schema is used and ask user to add them to the schema instead. Continue executing as ignored.
11. Add telemetry so we know how many people use the new recipe.

Definition of Done

• We can use graph schemas and train and run models.

[kochede]

Waiting for this feature - we need it for custom NLU pipelines - hope it will be implemented sometime in Jan!

[m-vdb]

@tayfun are you taking this on this week?

[tayfun]

@m-vdb yes, I'll start working on this now.

[tayfun]

The steps in original ticket are deprecated as it doesn't work for the complex case we have in the codebase. I'll work on a solution that could work.