Build your first agent in just a few minutes with [Rasa Copilot](https://hello.rasa.com/?utm_source=docs&utm_medium=referral&utm_campaign=docs_cta). ## Default Recipe or Graph Recipe? You will probably only need graph recipes if you're running ML experiments or ablation studies on an existing model. We recommend starting with the default recipe and for many applications that will be all that's needed. We now support graph recipes in addition to the default recipe. Graph recipes provide more granular control over how execution graph schemas are built. ### New in 3.1 This feature is experimental. We introduce experimental features to get feedback from our community, so we encourage you to try it out! However, the functionality might be changed or removed in the future. If you have feedback (positive or negative) please share it with us on the [Rasa Forum](https://forum.rasa.com/). ## Differences with Default Recipe There are some differences between the default recipe and the new graph recipe. Main differences are: - Default recipe is named `default.v1` in the config file whereas graph recipes are named `graph.v1`. - Default recipes provide an easy to use recipe structure whereas graph recipes are more advanced and powerful. - Default recipes are very opinionated and provide various defaults whereas graph recipes are more explicit. - Default recipes can auto-configure themselves and dump the defaults used to the file if some sections in `config.yml` are missing, whereas graph recipes do none of this and assume what you see is what you get. There are no surprises with graph recipes. - Default recipe divides graph configuration into mainly two parts: `pipeline` and `policies`. These can also be described as NLU and core (dialogue management) parts. For graph recipe on the other hand, the separation is between training (ie. `train_schema`) and prediction (ie. `predict_schema`). ### Starting from scratch? If you don't know which recipe to choose, use the default recipe to bootstrap your project fast. If later you find that you need more fine-grained control, you can always change your recipe to be a graph recipe. ## Graph Configuration File Structure Graph recipes share `recipe` and `language` keys with the same meaning. Similarities end there as graph recipes do not have `pipeline` or `policies` keys but they do have `train_schema` and `predict_schema` keys for determining the graph nodes during train and predict runs respectively. In addition to this, target nodes for NLU and core can be specified explicitly with graph recipes, these can be declared with `nlu_target` and `core_target`. If targets are omitted, node names used by default recipe will take over, and these are `run_RegexMessageHandler` and `select_prediction` for nlu and core respectively. Here's an example graph recipe: ```yaml # The config recipe. recipe: graph.v1 language: en core_target: custom_core_target nlu_target: custom_nlu_target train_schema: nodes: finetuning_validator: needs: importer: __importer__ uses: rasa.graph_components.validators.finetuning_validator.FinetuningValidator constructor_name: create fn: validate config: validate_core: true validate_nlu: true eager: false is_target: false is_input: true resource: null nlu_training_data_provider: needs: importer: finetuning_validator uses: rasa.graph_components.providers.nlu_training_data_provider.NLUTrainingDataProvider constructor_name: create fn: provide config: language: en persist: false eager: false is_target: false is_input: true resource: null domain_provider: needs: importer: finetuning_validator uses: rasa.graph_components.providers.domain_provider.DomainProvider constructor_name: create fn: provide_train config: { } eager: false is_target: true is_input: true resource: null domain_for_core_training_provider: needs: domain: domain_provider uses: rasa.graph_components.providers.domain_for_core_training_provider.DomainForCoreTrainingProvider constructor_name: create fn: provide config: { } eager: false is_target: false is_input: true resource: null story_graph_provider: needs: importer: finetuning_validator uses: rasa.graph_components.providers.story_graph_provider.StoryGraphProvider constructor_name: create fn: provide config: exclusion_percentage: null eager: false is_target: false is_input: true resource: null training_tracker_provider: needs: story_graph: story_graph_provider domain: domain_for_core_training_provider uses: rasa.graph_components.providers.training_tracker_provider.TrainingTrackerProvider constructor_name: create fn: provide config: { } eager: false is_target: false is_input: false resource: null train_MemoizationPolicy0: needs: training_trackers: training_tracker_provider domain: domain_for_core_training_provider uses: rasa.core.policies.memoization.MemoizationPolicy constructor_name: create fn: train config: { } eager: false is_target: true is_input: false resource: null predict_schema: nodes: nlu_message_converter: needs: messages: __message__ uses: rasa.graph_components.converters.nlu_message_converter.NLUMessageConverter constructor_name: load fn: convert_user_message config: {} eager: true is_target: false is_input: false resource: null custom_nlu_target: needs: messages: nlu_message_converter domain: domain_provider uses: rasa.nlu.classifiers.regex_message_handler.RegexMessageHandler constructor_name: load fn: process config: {} eager: true is_target: false is_input: false resource: null domain_provider: needs: {} uses: rasa.graph_components.providers.domain_provider.DomainProvider constructor_name: load fn: provide_inference config: {} eager: true is_target: false is_input: false resource: name: domain_provider run_MemoizationPolicy0: needs: domain: domain_provider tracker: __tracker__ rule_only_data: rule_only_data_provider uses: rasa.core.policies.memoization.MemoizationPolicy constructor_name: load fn: predict_action_probabilities config: {} eager: true is_target: false is_input: false resource: name: train_MemoizationPolicy0 rule_only_data_provider: needs: {} uses: rasa.graph_components.providers.rule_only_provider.RuleOnlyDataProvider constructor_name: load fn: provide config: {} eager: true is_target: false is_input: false resource: name: train_RulePolicy1 custom_core_target: needs: policy0: run_MemoizationPolicy0 domain: domain_provider tracker: __tracker__ uses: rasa.core.policies.ensemble.DefaultPolicyPredictionEnsemble constructor_name: load fn: combine_predictions_from_kwargs config: {} eager: true is_target: false is_input: false resource: null ``` ## Graph Node Configuration As you can see in the example above, graph recipes are very much explicit and you can configure each graph node as you would like. Here is an explanation of what some of the keys mean: - `needs`: You can define here what data your graph node requires and from which parent node. Key is the data name, whereas the value would refer to the node name. ```yaml needs: messages: nlu_message_converter ``` - `uses`: You can provide the class used to instantiate this node with this key. Please provide the full path in Python path syntax. ```yaml uses: rasa.graph_components.converters.nlu_message_converter.NLUMessageConverter ``` - `constructor_name`: This is the constructor used to instantiate your component. ```yaml constructor_name: load ``` - `fn`: This is the function used in executing the graph component. ```yaml fn: combine_predictions_from_kwargs ``` - `config`: You can provide any configuration parameters for your components using this key. ```yaml config: language: en persist: false ``` - `eager`: This determines if your component should be eagerly loaded when the graph is constructed or if it should wait until the runtime. ```yaml eager: true ``` - `resource`: If given, graph node is loaded from this resource instead of instantiated from scratch. ```yaml resource: name: train_RulePolicy1 ``` - `is_target`: Boolean value, if `True` then this node can't be pruned during fingerprinting. ```yaml is_target: false ``` - `is_input`: Boolean value; nodes with `is_input` are _always_ run. ```yaml is_input: false ```