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.v1in the config file whereas graph recipes are namedgraph.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.ymlare 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:
pipelineandpolicies. 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).
Graph Configuration File Structure
Graph recipes sharerecipe 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:
graph targetsFor NLU, default target name of
run_RegexMessageHandler will be used, while for core (dialogue management) the target will be called select_prediction if omitted. Make sure you have graph nodes with relevant names in your schema definitions.In a similar fashion, note that the default resource needed by the first graph node is fixed to be __importer__ (representing configuration, training data etc.) for training task and it is __message__ (representing the message received) for prediction task. Make sure your first nodes make use of these dependencies.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.
messages which is provided by nlu_message_converter node.
uses: You can provide the class used to instantiate this node with this key. Please provide the full path in Python path syntax, eg.
constructor_name: This is the constructor used to instantiate your component. Example:
fn: This is the function used in executing the graph component. Example:
config: You can provide any configuration parameters for your components using this key.
eager: This determines if your component should be eagerly loaded when the graph is constructed or if it should wait until the runtime (this is called lazy instantiation). Usually we always instantiate lazily during training and eagerly during inference (to avoid slow first prediction).
resource: If given, graph node is loaded from this resource instead of instantiated from scratch. This is e.g. used to load a trained component for predictions.
is_target: Boolean value, ifTruethen this node can’t be pruned during fingerprinting (it might be replaced with a cached value though). This is e.g. used for all components which train as their result always needs to be added to the model archive so that the data is available during inference.
is_input: Boolean value; nodes withis_inputare always run (also during the fingerprint run). This makes sure that we e.g. detect changes in file contents.