ensemble-engine/ensemble

What should we do about action salience?

meldckn opened this issue · 0 comments

Action scoring functions (getAction(), getActions()) return bound action objects with both weight and salience, but salience calculation isn't really implemented, at least as I would expect. See these lines in the function terminalFoundInRecursiveSearch(), in ActionLibrary.js line 309 of the uncompiled Ensemble Javascript (this is eventually called down-the-line from getAction(), etc):

//Because salience may come back someday, use the weight as our salience.
terminalAction.salience = terminalAction.weight + terminalAction.salience; 
// if there is a hard-coded salience, honor it.

So it does kind of work if you attach your own salience properties to individual action JSON definitions. But it gets summed with weight, and I would be very surprised if an Ensemble author actually did this and was able to use it in a way that made sense. —Although, CLIPS seems to use this user-defined notion of salience. I wonder how widely used it is, the original intent for using salience, or how people tutorialize it/recommend others use it.

Alternatively, there's a function, computeActionSalience() (also in ActionLibrary.js) that isn't called anywhere, that defines salience as the number of conditions an action has (multiplied by a hard-coded multiplier for some reason, and only applicable for terminal actions). That (without the multiplier) seems like a good first step for a computed notion of salience. I'm not sure why this wasn't used in terminalFoundInRecursiveSearch(). I might also edit it to account for the number of unique conditions in its parent action nodes? And, looking ahead, there might be more sophisticated things you can do to calculate salience. I bet there's rule systems AI literature on this.

Why would you even care about salience?
If you have enough actions defined in your domain, choosing the top n among possible actions randomly isn't very satisfying. Grabbing the n most salient possible actions should produce more context-aware and controllable results.

So I'm not sure what to do about this. Some options:

  • If we keep the current notion of salience, as only different from weight if you hand-specify a salience for individual actions, it should be explained better in the documentation (in both action definition and action scoring contexts). Define action saliences in an example domain. Give advice for choosing salience numbers (e.g., have a small number of levels of priority, and pick one for each rule according to how context-specific it is).
  • If we want to use a computed notion of salience (requiring less authoring overhead for users), add a call to computeActionSalience() from terminalFoundInRecursiveSearch(), and potentially edit it with the above changes. Explain in the action calculation documentation. Use calculated action saliences in an example project.
  • Would a combined approach be viable? Allow author control of salience mixed with computed salience? Or would this be super hard to use and author in?