The advantage of an inverse model is that it can be used directly to build a controller. The desired behavior is treated as an input variable in the model, and the action is treated as an output variable. When a new desired behavior is given, the controller just asks the model to predict the action needed. It works just like any other learner prediction. The problem that can arise with inverse models is that the mapping from actions to behaviors is often non-invertible. This happens when more than one action results in the same behavior. Notice that the graph in fig. 28a has exactly that property. When the data from a system with this property is used to construct an inverse model (something that isn't really possible without extra constraints to resolve the ambiguity), the inverse model is often poor, or just plain wrong. If you look carefully at fig. 28b, you'll see that the function fit to the data for the inverse model is incorrect. We can see the problem by requesting the inverse model to find us an action that will produce behavior 0.4.
Edit -> Format -> action output
behavior input
Edit -> Metacode -> Q50:9
Edit -> Query -> 0.4
Model -> Predict
Model -> Analysis
The inverse model suggests action 0.25. This selection can be seen by looking at fig. 28b. To ask Vizier for a prediction only, use the Predict command. The analysis command provides gradients, noise estimates, and confidence intervals as well. We'll come back to the information from the analysis command shortly. Now, use the forward model to predict what behavior will result from this action.
Edit -> Format -> action input
behavior output
Edit -> Metacode -> Q50:9
Edit -> Query -> 0.25
Model -> Predict
The forward model predicts a resulting behavior of 0.82, as can be seen in fig. 28a. This is far from the intended behavior of 0.4. In fact, the problem is even worse than this. It is common for a model to have some inaccuracies. Because of that, it is often a good idea to make a closed loop controller that looks at derivatives and adjusts its controls to hone in on the desired behavior. If we wanted to use the inverse model for this purpose, we could look at the derivatives it gives us. Go back to the results of the analysis command on the inverse model (or look at the slope of the curve in fig. 28b). It says the derivative of the action with respect to the behavior is -1.62. We know that the behavior we got from the forward model was higher than what we wanted and thus we would like to lower it. The negative derivative given to us by the inverse model says that if we want to decrease the behavior value, we should increase the action value. So a closed loop controller might increase the action from 0.25 to 0.3. Now check the forward model to see what it predicts for action 0.3. It predicts 0.88, which is even further from the behavior we wanted! You can run the analysis command on the forward model to see that the predicted derivative between actions and behaviors is positive, which confirms the problem. So we see that not only is the inverse model inaccurate, but attempts to put it in a closed loop controller could make things even worse.
The problem is further illustrated by considering fig. 28c. It shows what the correct inverse function would be if you could exactly swap the axes and mirror the forward function appropriately. That graph was not produced by Vizier since the curve in it is not a function. It has more than one output for some of the inputs.